Mailman 3 September 2008 - Python-Dev

Re: [Python-Dev] [Python-3000] bsddb finished for 2.6/3.0 (and "<class 'BytesWarning'>: str() on a bytes instance")
by Barry Warsaw 04 Sep '08

04 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 3, 2008, at 7:01 PM, Jesus Cea wrote: > Barry Warsaw wrote: >> and I know Brett agrees, so that's it. On IRC, I've just asked >> Benjamin >> to do the honors for 3.0 and Brett will add the deprecations for 2.6. > > I just committed the fix for bsddb testsuite in Python 3.0 branch: > http://www.python.org/dev/buildbot/3.0.stable/changes/2687 > > Can I do anything to revert this decision?. If not, what can I do to > be > reconsidered in 3.1?. Start raising some pitchforks. It looks like Raymond will join the march :). Really, this is about what's best for Python and pybsddb. In this article, Guido unambiguously states his opinion: http://mail.python.org/pipermail/python-dev/2008-July/081362.html "+1. In my recollection maintaining bsddb has been nothing but trouble right from the start when we were all sitting together at "Zope Corp North" in a rented office in McLean... We can remove it from 3.0. We can't really remove it from 2.6, but we can certainly start end-of-lifing it in 2.6." Jesus, let me stress that IMO this is not a reflection on your work at all. On the contrary, keeping it alive in 2.x and providing a really solid independent package for 3.0 is critical for its continued relevance to Python programmers. I completely agree with Guido that bsddb (not pybsddb) has been a headache since forever. For example, IIRC Sleepycat was notorious for changing the API in micro releases, though I don't know if that's still the case with the current maintainers. I personally believe that Python and pybsddb are both better off with their own maintenance lifecycles so I stand by my decision that pulling it out of 3.0 is the right thing to do. 3.1 is far enough away that any decision we make in 3.0 can be re-evaluated. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSL85BnEjvBPtnXfVAQLfkwQAtoagOP37uAwL1r2H7w73erTsWBYHf4VH KcTZsjeQ/mEvmaaJIG86ylAtpxmDmMF5x7OClR66bXXxf0oTnWV4KMC9rLdQW8R/ KpMIfuQw/501AQgFmcB0M6SQ6CYyJHU5K+K6X+ScOPHOJoG8usPK1pk8XFGOXBZK UGXCEHVvlrk= =7AOQ -----END PGP SIGNATURE-----

1 0

Further PEP 8 compliance issues in threading and multiprocessing
by Nick Coghlan 03 Sep '08

03 Sep '08

I've been taking a close look at the API for multiprocessing and threading, and have discovered a somewhat strange pattern that occurs multiple times in both interfaces: factory functions with names that start with a capital letter so they look like they're actually a class. At first I thought it was a quirk of the multiprocessing implementation, but then I discovered that the threading module also does it for all of the synchronisation objects as well as threading.Timer, with examples like: def Event(*args, **kwds): return _Event(*args, **kwds) Is this just intended to discourage subclassing? If so, why give the misleading impression that these things can be subclassed by naming them as if they were classes? How should this be handled when it comes to the addition of PEP 8 compliant aliases? Add aliases for the factory functions that start with a lower case letter, but otherwise leave the structure of the modules unchanged? Or should the trivial functions like the one above be dropped and made direct aliases for the classes they are currently wrapping? Option 1 has the virtue of being perfectly backwards compatible in the threading case, while option 2 is a little riskier, so I'm inclined to go with option 1 (keeping the factory functions, but giving them non-class like names in the case of multiprocessing, or aliases in the case of threading). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

11 21

fileobj.read(float): warning or error?
by Victor Stinner 03 Sep '08

03 Sep '08

Hi, Since Python 2.4 (maybe 2.2 or older), fileobj.read(4.2) displays an error and works as fileobj.read(4). >>> i=open('/etc/issue') >>> i.read(4.2) __main__:1: DeprecationWarning: integer argument expected, got float It should raises an error instead of a warning, it has no sense to read a partial byte :-) But that should breaks some applications? Well, the real problem is os.urandom(4.2) which goes to an unlimited loop: while len(bytes) < n: bytes += read(_urandomfd, n - len(bytes)) because read(0.2) works as read(0) :-/ Victor

11 23

Re: [Python-Dev] Add python.exe to PATH environment variable
by Curt Hagenlocher 03 Sep '08

03 Sep '08

One of these days, I'm actually going to remember that I need to click "Reply All" when posting to this list... . Sorry for the duplicate, Greg. On Tue, Sep 2, 2008 at 6:45 PM, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > > A better way would be to start a command process with > the Python directory added to PATH just for that > process. This is similar to what Visual Studio or the Windows SDK do to give you a command prompt with the PATH and other environmental variables setup "correctly" -- they add a shortcut to a batch file that's set to keep the command prompt open after the batch file runs. > How easy would that be to do on Windows? Do environment > variables get inherited by child processes the way > they do on Unix? Generally, yes. I think there's a catch in that there are ways to start processes that don't make them children of your process, but I don't remember why I think that. One other reason not to mess with the PATH -- at least by default -- is that the user may have multiple copies of Python installed. I know I have at least one machine with 2.4.5, 2.5.2, 2.6b2 and 3.0b2 installed -- and I don't want *any* of them in my path. -- Curt Hagenlocher curt(a)hagenlocher.org

2 1

2.6b3 Windows installers
by M.-A. Lemburg 02 Sep '08

02 Sep '08

The download page doesn't list any Windows installer for 2.6b3: http://www.python.org/download/releases/2.6/ I suppose this is due to Martin building the installers and him not be available at the moment. Since Python on Windows will likely only get very few beta testers without a Windows installer build, I'd suggest to postpone the RC1 release that's planned for tomorrow to get more feedback for the Windows builds. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 02 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611

3 3

Re: [Python-Dev] Things to Know About Super
by average 02 Sep '08

02 Sep '08

It seems that the frustration with super revolves around how Python currently conflates (as well as many users) two very different types of inheritance, both "is-a" and "has-a" (or compositional) inheritance. Unfortunately, Python assists this confusion because the language doesn't provide a distinct enough way to differentiate between them. For the former (i.e. is-a inheritance), users should not have to explicitly make a call to the super class (via super() or otherwise)--this should be automatic for every method held in common so as to guarantee the invariants of the simpler class. For this type of inheritance it makes more sense to be explicit about *bypassing* a call to the parent class--IF necessary (perhaps to take advantage of an optimization available only in the subclass)--rather than explicit about *making* one. This would remove many of the bugs, misuses, and frustrations with super(). No more ambiguity and confusion because the language now guarantees certain behavior. Super() would then be limited to cooperative mixin classes; for all others, explicit naming of the class would be required. But perhaps that there is some language abstraction that has yet to be fully invented that would tie it all together nicely. By the way, regarding your trait implementation, it may be worthwhile revisiting the discussion surrounding the Prothon language discussed a few years ago on comp.lang.python which got rid of classes and metaclasses and replaced them with prototypes. Regards, zipher

2 1

Proposal: add odict to collections
by Armin Ronacher 01 Sep '08

01 Sep '08

Hi, I noticed lately that quite a few projects are implementing their own subclasses of `dict` that retain the order of the key/value pairs. However half of the implementations I came across are not implementing the whole dict interface which leads to weird bugs, also the performance of a Python implementation is not that great. To fight that problem I want to proposed a new class in "collections" called odict which is a dict that keeps the items sorted, similar to a PHP array. The interface would be fully compatible with dict and implemented as dict subclass. Updates to existing keys does not change the order of a key but new keys are inserted at the end. Additionally it would support slicing where a list of key, value tuples is returned and sort/reverse/index methods that work like their list equivalents. Index based lookup could work via odict.byindex(). An implementation of that exists as part of the ordereddict implementation which however goes beyond that and is pretty much a fork of the python dict[1]. Some reasons why ordered dicts are a useful feature: - in XML/HTML processing it's often desired to keep the attributes of an tag ordered during processing. So that input ordering is the same as the output ordering. - Form data transmitted via HTTP is usually ordered by the position of the input/textarea/select field in the HTML document. That information is currently lost in most Python web applications / frameworks. - Eaiser transition of code from Ruby/PHP which have sorted associative arrays / hashmaps. - Having an ordered dict in the standard library would allow other libraries support them. For example a PHP serializer could return odicts rather then dicts which drops the ordering information. XML libraries such as etree could add support for it when creating elements or return attribute dicts. Regards, Armin [1]: http://www.xs4all.nl/~anthon/Python/ordereddict/

28 52