This discussion (not that it actually has been one) is over.

(5) “All I want to do is move the error to parse time.”

Fair enough. But this does not require specific syntax for definitions than assignments. Also, you can instead run pyflakes or similar as a part of your testing procedure, and it will also find most of these these errors before you actually encounter them. If you constantly find yourself assigning variables that already exist, and you really want variable definitions in the beginning of a method (I suspect this desire laso just is a part of you not being used to it), the pleas, go ahead and do so if you want. Nothing stops you.

You still want to have a language which hand you have to hold. But the things you percieve as problems are not problems in practice. Your suggestions only requires more syntax and opens up for more errors. Sure, the language will detect these errors quickly, but programming will be slower.

“There are already languages that do it that way!”

I’ve never said it’s impossible. I’m just saying that the befits you percieve aren’t really there.

Honestly, it’s just a matter of getting used to not having to babysit a compiler. Again, I’ve seen this before.

I guess we’ll just have to disagree about (2). I hate it.

For (3), once again you fail to understand that it has NOTHING to do with dynamicness. PHP is also fully dynamic but allows you to declare instance members with initializers in the class. And it’s way more readable. And it makes way easier to write documentation tool chains that documents which instance members exist, their purpose, their expected types, and so on, which does actually matter. If you don’t think so, ask yourself what happens on a class that has a method which calls another method on an instance member would do if you didn’t set that instance member to a compatible type: it’d throw an exception that the method shouldn’t throw, and you’d be left scratching your head trying to figure out why because the docs don’t in any way indicate that the instance member needs to exist, that it needs to be of a certain type (or compatible with the type, at least), etc. Lame.

For (5), no, it once again is not about types. Come on, this shouldn’t need explanation. Python ALREADY DOES THIS to an extent: if you try to use a variable that doesn’t exist, you get a runtime exception. All I want to do is move the error to parse time. I have NEVER in my life had any kind of problem with needing to move declarations around; you’re just making up theoretical problems that don’t in reality actually exist. If you’re moving code around that often, you need to step away from the computer for a minute and try to think before you write code. I don’t know about you, but I’d tend to prefer to write code once and move on to doing new things rather than rearranging incomplete code over and over and over just because I was too damn lazy or incompetent to do it right the first time.

For (6), you confuse “required” with “standard.” English, it works.

And dude, seriously, stop telling me I’ll get used to dynamic typing. I’ve been using dynamically typed languages for more years than some of the core Python folks have been using computers at all. YOU are the one who is confused here since you can’t seem to differentiate between dynamic/static typing and structure. Totally different things.

I mean, by your logic, Python has no use for classes at all. They serve no purpose. They’re needless complexity when Python could have just gone with a prototype model like JavaScript. Why define methods in a class at all when you can just add methods to the class? Why have a class at all when all a class is is just an object that holds class members and methods? Classes are there for a reason: for structure.

Types DO matter, even in a dynamic world, because you can’t call the someOtherClassMethod() on an object that doesn’t and never will have that method.

Structure does matter because the computer doesn’t have a fucking clue WHY I’m telling it anything; it only knows what I tell it. The computer doesn’t necessarily need to know why I’m telling it to do things, but other programmers reading my code do, and structure makes it easier for them to read it without requiring 30 line comments all over the place pointing to 20 different places because the language doesn’t make it possible to organize efficiently.

I mean, take the instance member definition issue. Sure, I can put them all in the __init__ method and document that. But that is harder to read, and you’re full of crap if you think otherwise. Why does Python force indentation? For readability. What happens when you put instance member initializers at the same indentation level as method bodies? They end up looking the damn same, making it just that much harder to find what you’re looking for.

You don’t have to remove dynamicness to make it freaking possible to define instance methods and initializers in a cleaner format. Seriously.

You also can still make it possible to disable dynamicness in some instances where the programmer actually knows better than the damn language (*gasp*!) and knows that one of the classes he is defining is not going to be used by external libraries, third-party code, or anything other than the sole specific purpose he defined that class for, and he knows that he does not want to allow dynamicness because it’s just a source of bugs with absolutely no fucking benefits in this particular case.

It’s not one or the other. It can be both. Really. There are already languages that do it that way! Please stop thinking of everything as either Python or Java, because those are just two little denizens within the very, very large world of programming languages.

3. Right, the difference between class members and instance members means you can’t set mutable objects like this, that’s true. I read what you arite again, and your complaint is really that you can’t just look at the top of the class definition to see it’s members because of this. Again, Python is dynamic. Once you have gotten used to that, you’ll love it.

5. Yes it has to do with static typing, since variable declaration is pointless unless they have a static type. Now you say you want something to declare that this is the first time a variable is used. That means that the first time you assign to a variable, you have to write something extra there. Say:
define foo = “345″
and the next time you assign foo you just write:
foo = “76767″
But if you now remove the first assignment, then the second one would fail. And if you insert a “define foo = None” before the first “define foo”, then that would fail. You now have a lot of “define” statements you have to move around and get in the correct place. For absolutely no reason.

6. So you want a required formatting that isn’t required. Hoookay…

“I’m not saying I want static typing.”

Yeah, that’s in fact exactly what you are saying. But you’ll get used to dynamic typing soon enough. Most of your complaints are the same reaction that I had when switching to python, and I’ve seen it happen in several of my friends too, when I’ve convinced them to try out Python. It goes away.

You call it “helping you do do your job”, I call it “forcing you to go through useless hoops”. You call it holding the languages hand. Well, I think it’s the other way around. When I need to constantly tell the language everything. What type everything should be, when a variable is declared for the first time, etc. Why should I tell it these things? It already *knows*! THAT is holding the languages hand.

Gabriel

For (1), I can say without a doubt that Python’s documentation is the worst of every major language I’ve used (and I’ve used a lot). Java, C++, Ruby, Perl, and PHP are what I’ve used the most over the last few years, and the docuementation for all of these is more easily searchable, more explicit, full of more examples, and better presented.

For (2), I don’t know what you’re getting at. My complaint is that the Python “file is a module whether you like it or not” is a pain in the ass.

For (3), no, you cannot define instance members. Try this:

class Foo:
member = []
def method(self, value):
self.member.append(value)

The member variable is a CLASS variable, not an INSTANCE variable. So, if you create two instances of Foo, and call method(”bar”) on both, then both instances will see ["bar","bar"] inside of self.member. You can declare members if they are value types (strings, ints, bools, None), but for anything else you have to define them in the __init__ method.

On (4), I’m not asking that all declarators take the empty (). I just want consistency. That could just as easily make it such that a a declarator without any parenthesis behaves identically to one that has an explicit().

For (5), it has nothing to do with being statically typed. Python DOES force you to define variables! Try accessing a variable that you haven’t defined yet: you get a runtime exception. What I’d like is a way to make it clear to the reader whether a variable is being declared for the first time or not. I don’t want static typing, that is entirely a different topic than declaring variable names.

And on (6), I never asked that Python error-out if the docstring was poorly formatted. Java doesn’t error out if the javadoc comments are poorly formatted, nor PHP error out if the phpDocumentor comments are poorly formatted, etc. Mostly I suppose this is a complaint that the pydoc tool that ships with Python is useless (it makes the hard to read, hard to browse, easy to screw up documentation that is seen in the Python standard library). I’ve looked around at tools like epydoc and a few others, which show that it’s possible to have nice markup in your doc strings and to generate far more readable, complete, and consistent documentation. I’d be happy if Python 3 just shipped a documentation tool like that — optional, but it’s actually there if you want it without having to grab a ton of third-party code and tools.

So far as the tests argument, yes, weakly typed code DOES need more tests. There are two things you can test: behavior of implementation and enforcement of interface. All languages need tests for behavior of implementation. The difference is pretty key. For behavior, it is generally pretty easy to test individual modules. If I have a module that handles some particular data structure, for example, I write tests that use that module’s public interface to make sure it does what it’s supposed to do.

The problem is when you have a lot of code using a lot of modules. If you pass the wrong type to a method, it might not be until an entirely different part of the program that that type becomes critical and causes an exception or incorrect behavior. Writing tests for scenarios like that is a pain, and then tracking down those errors is even more of a pain, and it’s a pain that you NEVER have to deal with in a language that actually helps you do your job instead of expecting you to hand-hold the language through everything.

I’m not saying I want static typing. I just want to ensure that if I define an interface or a class that the language enforce that definition for me. If I didn’t want it defined I wouldn’t have bothered taking the time to define it. PHP is a dynamically, weakly typed language that allows you to (optionally) define the types of function parameters, so ifyou pass in the wrong type you get a run-time error _directly at the point of call_. That’s damn handy. It also makes the code self-documenting in more cases, making the fancy documentation comments somewhat less necessary (though still useful enough to use for larger modules).

It’s unfortunate that people such as yourself see the extreme end of dynamically typed and the extreme end of statically typed as two opposing and incompatible language design methodologies. That just isn’t the case. It is entirely possible to offer a language with both, such as can be seen with Boo, PHP, some versions of BASIC, ECMAScript 4, and dozens of other languages I’m forgetting.

Some code is just easier and quicker to develop without having to think about typing. Other code is easier and quicker to develop when you can count on the language backing you up with your interfaces. Why force programmers to choose one or the other, or force them to code in two completely different and incompatible languages and then waste immense amounts of time bridging them together just in order to get the best of both worlds?

Does “from app.module.submodule import Class” count as a clever trick?

Lennart: For 3, you missed

If a variable is set in a class, that actually defines a class variable, not a member. This works out fine for numbers, booleans, and strings, but not so well for hashes, arrays, objects.

- each Test() should be a new object: class Test:
a=[1,3,4,5]
>>> Test().a
[1, 3, 4, 5]
>>> Test().a.pop()
5
>>> Test().a
[1, 3, 4]

Don’t Abstract Base Classes in Py3K help make classes mean something?

2. Your complaint here are incorrect. Python *is* explicit. What it doesn’t do is hide everything by default, instead ot shows everything by default, and that’s how Python works. And it’s a good thing too.

3. Your complaints here are incorrect. You *can* declare members and default variables in the definition. I don’t know how you missed that one, it’s trivial. Classes do mean something. Yes, they are “weak”. Python is a dynamically typed language. That is also a Good Thing.

4. It’s a matter of opinion I guess. Most decorators don’t take parameters, so I guess they didn’t want to have the empty () in the end for those.

5. Yes, variables aren’t declared. Again, Python is dynamically typed. It’s a Good Thing. Your grivence on this and point 3 is completely normal when you go from staticly typed to dynamically typed languages. It feels weird in the beginning. However, it’s not a problem.

6. True, there is no forced syntax in docstrings. And honestly, would you really want Python to break everytime it encounters a docstring that doesn’t have a dot in the correct place? It would just make people stop using them altogether.

All in all, you seem to want Python to force you do things that are not necessary, probably because you are used to be forced by other languages. However, it turns out that this is not necessary. It works fine without it. And the idea that you need more tests because the language is weakly typed is a myth. Weakly typed programming does not need more tests. Python people do not say “you should have tests because the language is weakly typed”. We say “you should have tests, and the tets will find these errors too”. You need tests anyway. Untested code is broken code. Even in C++.

You can add your own namespacing solution over the top of the standard importing system. So first it looks to your system, then falls back on the standard Python system.

In my code reloading project, I use a module structure based solely on directories. For instance, given a file “stuff/otherstuff/foo.py”, all the contents of ‘foo.py’ appear in ’stuff.otherstuff’. The same goes for all the other files in that directory.

I’d also add:

- you probably want to make aliases to your submodules. I.E. if you had defined foobar.utils.settings.reset_all_logs but this function is used so often that you just want to to write:

from foobar import reset_all_logs
reset_all_logs()

then inside foobar/__init__.py you put:

from utils import *

and inside foobar/utils/__init__.py you put:

from settings import *

and inside foobar/utils/settings.py you declare

def reset_all_logs():
# …

Once I got used to this idea it made Python’s auto namespacing one of its most important features. In fact, since Ruby is very similar to Python there are only subtle differences. The Python auto-namespacing, to me, is one thing that makes Python much easier to program in vs. Ruby. Otherwise, you have to type module “blah” … end all time. Ouch! And trying to read someone’s Ruby code to figure out where the objects are defined? Forget about it.

As for “weak classes” — I think what you want is :

class Special:
__slots__ = ['bar', 'foo']

s = Special()
s.barr = 1 # typo <– raises an error

But, seriously, don’t use slots!
http://groups.google.com/group/comp.lang.python/msg/0f2e859b9c002b28

You’ll get used to life without them. Yes, you’ll need a good set of tests if you want to be sure that your code doesn’t have typos in the variables it is assigning to objects.

I agree about the need for an easier way to declare instance methods. As for now, I have given in to declaring these in __init__() to the point where it doesn’t bother me anymore.

As for decorators, yes they are confusing. They make your head explode as soon as you try to write one. But they make a lot of sense when you are using them ;)

unstructured docstrings. I agree here too. And I don’t like epydoc so I have not embraced their java-style structured doctests. Once Sphinx supports some kind of syntax then I will start using it. FYI: python 3000 will add annotations and I think we will once and for all get access to the meta data you are [rightfully] looking for.