Hi! > The reading I've done so far on Python 3 (alpha announcement, meta-PEP, > some other PEPs) is generally encouraging, but there doesn't seem to be > much on cleaning up the syntax, which has become uglier over time as > features have been added on to an original syntax that wasn't designed > to support them. It seems to me (from what little I've read--I admit > that it's impossible to know for sure without experimenting quite a bit, > for which I don't currently have the time) that new features such as > multimethods might just make things more confusing (especially for > newbies) in a lot of ways, without appropriate syntactic support.
There are some cleanups, such as the new class decorators and function annotation syntax. Both of them provides a common, much better solution instead of current weird solutions, such as metaclasses and specially formatted docstrings. Since Python currenty has a very nice syntax it cannot be cleaned up much further. > Currently the most obvious example of this is Python 2.5's way of > defining properties, which is ugly. leads often to writing of > unnecessary code, and certainly doesn't make property code clear to a > reader. Contrast this to the way properties (things that look like an > instance variable but are actually bound to methods) are handled in Ruby > and (IIRC, this also does a decent job) C#. > On the other hand, it does seem that some new syntactic support for > other features will be added, so perhaps I'm just missing whichever PEPs > talk about going back and adding cleaner syntax for existing features...? Class decorators allows clean implementation of properties. Detailed description: http://www.python.org/dev/peps/pep-3129/ Lets use a hypothetic library providing properties, for example: from property_support import hasProperties, Property @hasProperties class Sphere(object): def setRadius(self, value): ... some setter implementation ... radius=Property(default=1.0, set=setRadius, type=(int, float)) color=Property(default='black', allowNone=True) This is a cleaner syntax if you need automatic default setter/getter implementations with type checking, default values, etc. You can optionally override/extend some of the default implementations. This could be implemented by a third party library using class decorators and need not be restricted by a strict syntax in the language itself. This is a good design choice from my point of view, since it does not require the introduction of new symbols into the syntax, fully dynamic and inspected at runtime. > Finally, another thing I've perhaps missed, but I can't see anything in > what I've gone through, about correcting of of what I see to be one of > Python's most long-standing really serious flaws, which is the lack of > an official standard documentation markup syntax for writing > documentation in code. This isn't even a matter of getting something > developed, it's simply a matter of Guido and the Powers That Be > bestowing their benediction on one of the several adequate or better > documentation toolsets out there, so that more of us (slowly) start > using it. Eventually this will result in work on the toolset itself, > more people will be willing to use it, and there'll be a nice virtuous > circle. Given how much more capable D'Oxygen is than any of the > Python-specific solutions, I'd vote for D'Oxygen myself, but I'd prefer > to have almost anything fill in this vacuum, rather than continue things > the way they are. Maybe the community should ask Guido to suggest a "preferred" tool for documenting Python code. Regars, Viktor -- http://mail.python.org/mailman/listinfo/python-list
