[Python-Dev] DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15 (original) (raw)

Tony Meyer tony.meyer at gmail.com
Thu Jan 12 05:03:35 CET 2006

============= Announcements

Reminder: plain text documentation fixes are accepted

Want to help out with the Python documentation? Don't know LaTeX? No problem! Plain text or ReST fixes are also welcome. You won't be able to produce a diff file like with a normal patch, but comments that explain how to fix the docs are just as good. A form like "in section XXX right before the paragraph starting with YYY, the documentation should say ZZZ" will make it easy for the doc maintainers to apply your fix.

Contributing thread:

[SJB]

New-style exceptions patch requesting review

With PEP 352_ ready_ for Guido's pronouncement, Michael Hudson has asked for a few more developers to review his patch_ to make all exceptions new-style. It should be basically ready, but it would be nice to have a few eyes for sanity checks, documentation, and compilations on the various platforms.

.. _PEP 352: http://www.python.org/peps/pep-0352.html .. _ready: http://www.python.org/dev/summary/2005-10-16_2005-10-31.html#required-superclass-for-exceptions .. _patch: http://bugs.python.org/1104669

Contributing threads:

[SJB]

Debugging lib available from ActiveState

Trent Mick confirmed that ActiveState do distribute a separate distribution of debug DLLs for each Python release. These can be found by filling in the version number in the URL ftp://ftp.activestate.com/ActivePython/etc/ActivePython-<version>-win32-ix86-debug.zip

Contributing thread:

[TAM]

========= Summaries

Updating the Python style guide

Ian Bicking kicked off a lengthy discussion about updating various aspects of PEP 8_ (the Python code style guide), which resulted in a substantial revision of the PEP.

PEP 8 stated that if a module defines a single exception raised for all sorts of conditions, it is generally called "error" or "Error". Ian noted that other than some outlying cases (e.g. os.error, socket.error), CapWords are always used. He also wondered if exceptions should have names that are relatively unique, or simply unique within their namespace. Finally, he requested a position be taken on acronyms (e.g. HHTPRedirect or HttpRedirect).

Barry Warsaw pointed out that since exceptions are now classes, the rules for naming classes should really apply; his preference is CapWordsEndingInError rather than Error or error. He also suggested that acronym letters should be capitalised. There was mostly consensus on this, although some prefer shorter exception class names.

Guido wondered whether the function/method naming convention (lower_case, mixedCase, or CapWords) was so controversial that the PEP should not make a recommendation other than of consistency. In the end, however, the status quo (lower_case except for consistency reasons) won out. He was definite about module, package, and class names, however, which should be all-lowercase without underscores (modules/packages), or CapWords (class names). (He noted that standard library modules such as StringIO.py and UserDict.py that break this rule should be changed).

PEP 8 recommended appending an underscore rather than corrupted spelling when a name conflicts with a reserved word e.g. class_ rather than klass). Ian suggested that a specific recommendation for the class argument to classmethods be made; out of cls, klass and class_ he preferred cls. He further suggested that, as self is not used outside of the first argument of instance methods, whatever spelling of the class argument is used should not be used elsewhere (e.g. cls for the class argument, and class_ elsewhere). This was generally accepted.

A further suggestion from Barry's Mailman style guide_ was also made, that from-imports should follow non-from imports, and dotted imports should follow non-dotted imports. Non-dotted imports should be grouped by increasing length, while dotted imports should be grouped roughly alphabetically. However, this was felt to be too prescriptive; users should follow their own aesthetic taste.

Various other small modifications and improvements were suggested and made, such as::

There was also a sub-thread that considered when when to use normal instance variables and when to use accessor methods. Jim Fulton suggested that attributes should be used if the accessors are trivial, whereas Skip Montanaro preferred more frequent use of accessor methods, to avoid incorrect usage of classes. Phillip J. Eby's opinion was that normal instance variables should be used, until there is a need to do something when they change, at which point properties should be introduced. PEP 8 now recommends simple attribute access over accessors.

One distinction is how people interpret "public" and "private". Skip's opinion is that just because an attribute doesn't start with an underscore doesn't mean that it is implicitly declared public, and that people should familiarise themselves with the callable methods of an object and only use direct access if the necessary methods aren't provided. Jim felt that the API should be documented, and people should use that API (he considered that prepending an underscore documents that the attribute is internal; although this does not cover the "subclassing API").

Ian also brought up the section of PEP 8 that discussed private attributes and double leading underscores. PEP 8 was unclear whether double leading attributes should only be used to avoid name conflicts when subclassing, or whether indicating that an attribute was meant to be private was a valid use. This spun off a very long discussion about private variables.

Several people spoke up against double-underscore prefixes. On the other hand, Raymond Hettinger felt that the PEP should not dictate how variables should be named, especially for a convention with a long history and language support. Jim Fulton went so far as to suggest that __private be deprecated, which gained some support. However, Guido stated that he not only liked __private, he liked the current implementation. Specifically, he felt that the typically-shallow class hierarchies found in Python reduces the likelihood of accidental reuse of class names (he also advocated that subclasses should not share names with parent classes), and he liked that the name-mangling algorithm was well-defined and simple (e.g. so that when in the debugger it is easy to manually mangle/unmangle names). Interestingly, this is the main reason that Jeremy Hylton dislikes mangled names: because the debugger is unaware of the names and he can't remember how to type them, and also because it's annoying to have to change every instance of __var to _var if the intended usage changes (as compared to C++ private variables, where only the declaration of visibility must change). He noted, though, that these are problems that tools (debuggers, editors, IDEs) could solve.

Others felt that keeping mangling was fine, but that it should be changed so that collisions were harder (e.g. use a GUID instead of the class name). However, this violates one of Guido's reasons for liking the current implementation (although it's possible that having better support for the feature in common tools would remove this necessity).

Tim Peters gave a nice explanation of why the name mangling is provided::

If your utility or mixin base class A has a data member named n, nobody deriving from A dare name one of their data members n too, and it's unreasonable to expect everyone deriving from A to learn and avoid all the names A uses internally. It's even more unreasonable for A's author to have to promise, after A's first release, never to change the name of, or introduce any new, attribute (A's author dare not, lest the new name conflict with a name someone else's subclass used). If A's author names the attribute __n instead, all those problems go away, provided only that some subclass doesn't also name itself A.

Contributing threads:

.. _PEP 8: http://www.python.org/dev/peps/pep-0008.html .. _Mailman style guide: http://barry.warsaw.us/software/STYLEGUIDE.txt

[TAM]

ElementTree in the Python 2.5 stdlib

Skip Montanaro forwarded to python-dev a bit of a comp.lang.python thread asking why ElementTree wasn't part of the standard library. He and others argued that it was "best of breed" with a wide user base, and that it met the other requirements_ for stdlib inclusion like having an active maintainer, Fredrik Lundh. After a relatively brief discussion, Fredrik got the ball rolling, setting things up so that:

Mike Brown started a brief follow-up thread concerned that the XML-SIG hadn't been consulted on this inclusion. Martin v. Löwis and others indicated that sidestepping XML-SIG had not been intensional, but also that carrying the discussion on XML-SIG as well would not likely have changed the outcome due to the strong community support for ElementTree.

As a side effect of this discussion, magic in xml/__init__ was removed in favor of introducing an xmlcore package containing all the xml modules found in the basic standard library, and an xml module which imports things from xmlcore or PyXML if it's available.

.. _requirements: http://mail.python.org/pipermail/python-dev/2003-April/034881.html

Contributing threads:

[SJB]

More work on the AST

This fortnight saw implementations for the two main models proposed for revamping the AST memory management. Martin v. Löwis created a branch_ that converted all AST objects to PyObjects and used the normal Python reference counting to manage them. This requires that AST code:

Jeremy Hylton worked up a separate version of the AST code using an arena API. This requires that AST code:

The arena code was merged into the trunk, though it seemed that work on the PyObject branch would continue in order to be able to compare the final outcomes of both strategies.

In a related issue, because the AST code is generated from Parser/asdl_c.py, and because subversion sets the timestamp for each file to the checkout time, trying to build the current trunk on a machine without Python installed failed even when the AST C files had been checked into subversion. It looked like the best solution would be to introduce a separate make rule for generating the AST code.

.. _branch: http://svn.python.org/projects/python/branches/ast-objects/

Contributing threads:

[SJB]

Python GC Refresher

Gregoire Weber asked for a little more information on Python's garbage collector since the links in Modules/gcmodule.c were broken. Python's garbage collector is a combination of reference counting and the periodic invocation of a cyclic garbage collector. Python's reference counting means that each time an object P is referenced by another object, P's refcount is incremented, and each time one of the references to P is removed, P's refcount is decremented. When P's refcount reaches zero, the interpreter pauses to reclaim P and all objects that were reachable only from P. In addition to this reference counting, Python's cyclic garbage collector means that after a large number of objects have been allocated (and not deallocated though reference counting), the interpreter will pause to try to clear out any unreferenced cycles.

Contributing thread:

[SJB]

Improving the documentation process

Skip Montanaro suggested that, in order to lower the barrier for submitting documentation patches, it might be worth allowing anonymous bug reports. Guido was against this, indicating that he thought the problem was more the sourceforge sign-up hassle than the need to provide an email address, and suggested that it might be time to switch to roundup_. Martin v. Löwis was concerned about the transition process - whether or not roundup could properly import the sourceforge bug reports, and whether or not the python.org/sf/ redirect would continue to work. The discussion trailed off before any final decisions were made.

.. _roundup: http://roundup.sourceforge.net/

Contributing threads:

[SJB]

hasattr() and properties

Thomas Lotze noticed that when applied to a class instance (but not an object of that class), hasattr calls getattr and decides that the attribute doesn't exist if the call raises any exception. For example::

class Foo(object): ... def get(self): ... raise Exception ... bar = property(get) ... hasattr(Foo, "bar") True hasattr(Foo(), "bar") False

He asked whether it would make more sense to only report a missing attribute if an AttributeError is raised. Greg Ewing agreed that this would be an improvement, but felt that calling the property access code as a side effect of hasattr seems like a misfeature.

Thomas also wondered whether it would make sense for properties to look up the attribute in the same way that getattr would rather than calling getattr. Greg wondered if descripters need a forth slot for hasattr customisation, removing the need to rely on catching exceptions, so that the logic would be::

if there is a descriptor for the attribute: if the descriptor's hasattr slot is populated: return the result of calling it else: return True else: look in the instance dict for the attribute

Guido indicated that he believes that a property that has a side effect (other than caching, statistics, logging, and so forth) is a misfeature anyway, so he doesn't have a problem with hasattr() trying getattr() and reporting False if that raises an exception. Discussion died out before anything was resolved.

Contributing thread:

[TAM]

Supporting iterables in xmlrpclib

Skip Montanaro presented a patch_ to allow all currently supported iterables (e.g. sets and arrays) to be marshalled as lists with xmlrpclib. The goals are to extend the set of sequences that can be marshalled transparently, and keep the caller from caring as much about the limitations of the XML-RPC datatypes. Guido felt that this was a bad idea, however; he feels that it's better to be aware of the limitations in what XML-RPC can handle and try to handle it.

Contributing thread:

[TAM]

Checking Jython support code into CPython

Fredrik Lundh asked what the policy with respect to Jython-specific modules in the standard library was. Guido felt that as long as it didn't do any harm (likely causing unit tests to fail) to CPython, it would be fine. He noted that traditionally Jython-specific code has been checked into Jython's own source control, however, and Martin v. Löwis indicated that this is what he would prefer.

[TAM]

Getting rid of builtins in Python 3.0

Neal Norwitz asked Guido whether improving the confusing system of having both builtins and builtin could be begun. Guido clarified that having both is clearly a bad idea, that he's not sure that renaming builtin to builtin was correct (and that perhaps it should be changed back), that builtins always being a dict would simplify some code but need special handling of vars() in interactive mode, and that another alternative might be to merge the builtin and builtins functionality (under the builtin name).

Guido asked that people mull this over, but hasn't had any responses so far.

[TAM]

================ Deferred Threads

=============== Skipped Threads

More information about the Python-Dev mailing list