Mailman 3 October 2008 - Python-Dev

another test message - please ignore
by skip＠pobox.com Oct. 10, 2008

Oct. 10, 2008

still working on spam filter... Skip

1 0

test message - please ignore
by skip＠pobox.com Oct. 10, 2008

Oct. 10, 2008

(messing with the python.org spam filter - please ignore) Skip

1 0

__getattr__ and new style classes
by Kristján Valur Jónsson Oct. 10, 2008

Oct. 10, 2008

Hello there. I've just noticed what I consider a performance problem: Using new style classes to provide attribute-like access using __getattr__ is considerably slower than old style classes: Observe: s = """ class dude: def bar(self):pass def __getattr__(self, a): return a class dude2(object): def bar(self):pass def __getattr__(self, a): return a d = dude() d2 = dude2() d.a = d2.a = 1 """ timeit.Timer(´d.foo´, s).timeit() >0.32979211801421116 timeit.Timer(´d2.foo´, s).timeit() > 1.1119853719342245 The overhead is almost 3 times as high. I imagine that this is because new style classes must search further and harder before giving up and going to __getattr__. For the bound method the difference is less: timeit.Timer(´d.bar´, s).timeit() > 0.11835480370018558 timeit.Timer(´d2.bar´, s).timeit() > 0.17820851929263881 For fun, I also tested regular attributes, and see: timeit.Timer(´d.a´, s).timeit() > 0.069161394202183146 timeit.Timer(´d2.a´, s).timeit() > 0.17966275972594303 I'm surprised that accessing instance attributes like this is twice as slow using new style classes. Any thoughts on this? We are using a lot of low-level attribute access magic in EVE and so it would appear that we are best served by sticking with old-style classes. But these are going away eventually, so what to do? Where is this extra overhead coming from? And oh, it is no use using __getattribute__ instead, since it will always involve calls to object.__getattribute__ and become very slow. Cheers, Kristján

7 15

python dll no longer in system directory?
by Thomas Heller Oct. 9, 2008

Oct. 9, 2008

Is it intended that python30.dll and python26.dll are not longer installed in the \windows\system32 directory? This (pythonxy.dll not on $PATH) causes problems for COM objects implemented in Python. Thanks, Thomas

4 6

Subversion access down?
by Ulrich Eckhardt Oct. 9, 2008

Oct. 9, 2008

Hi! Is it only me or does it fail for other people, too? I'm getting | Server sent unexpected return value (503 Service | Unavailable) in response to OPTIONS request | for 'http://svn.python.org/projects/python/trunk' Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at <http://www.satorlaser.de/> ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. **************************************************************************************

3 3

effect of "exec" on local scope
by Willem Broekema Oct. 9, 2008

Oct. 9, 2008

The issue came up while trying to get some Sympy code running on CLPython. class C: exec "a = 3" print locals() 1. Is it guaranteed that class C gets an attribute "a", i.e. that the locals printed include {'a': 3}? 2. It it (also) guaranteed if it were in a function scope? The complete syntax of exec is: exec CODE in Y, Z where Y, Z are optional. The documentation of "exec" says "if the optional parts are omitted,the code is executed in the current scope." There are at least two different interpretations: a. The code is executed in the current class scope, so the assignment must have an effect on the class scope. b. The scope defaults to the local scope, by which is meant the mapping returned by locals(), and of locals() the documentation says that changes made to it may not influence the interpreter. (The documentation of exec suggests using globals() and locals() as arguments to exec, which seems hint at this interpretation.) The relevant documentation: exec: http://docs.python.org/reference/simple_stmts.html#grammar-token-exec_stmt locals: http://docs.python.org/library/functions.html#locals - Willem

5 5

Re: [Python-Dev] [Python-3000] Proposed Python 3.0 schedule
by Benjamin Peterson Oct. 8, 2008

Oct. 8, 2008

On Wed, Oct 8, 2008 at 12:51 AM, Dmitry Vasiliev <dima(a)hlabs.spb.ru> wrote: > > BTW, I think the following issues should be also marked as release blockers: Agreed and done. > > - http://bugs.python.org/issue3714 (nntplib module broken by str to > unicode conversion) > - http://bugs.python.org/issue3725 (telnetlib module broken by str to > unicode conversion) > - http://bugs.python.org/issue3727 (poplib module broken by str to > unicode conversion) > > -- > Dmitry Vasiliev <dima at hlabs.spb.ru> > http://hlabs.spb.ru > -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."

1 0

2.5.3: assessing commits
by A.M. Kuchling Oct. 8, 2008

Oct. 8, 2008

I've begun the task of assessing the 2.6 commits, but the job is unexpectedly large. What I did: * Took the output of 'svn log -r60999:66717'. (2.5.2 was branched from rev. 60999, so I'm ignoring commits to the trunk before 2.5.2 was branch, which may miss some things.) * Wrote a little script to explode the log into a separate file for each commit. This resulted in about 2200 files. * Did a long series of 'grep' and 'rm' commands to remove irrelevant files. For example, if the commit touches abc.py, bytesobject.c, bytearrayobject.c, etc. it was removed. * Wrote a little script to find commits that only touch the docs, and moved them aside. At this point I still have 1191 files left. Many of these commits are still irrelevant, but this is a lot for me to look through. A tarball with the remaining commits is at http://www.amk.ca/files/python/2.6-changes.tgz Can we parallelize the job? One person could take commits starting with '01', another with '02', etc. Or each person could assess the commits they made. --amk

1 2

Proposed Python 3.0 schedule
by Barry Warsaw Oct. 8, 2008

Oct. 8, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, we need to come up with a new release schedule for Python 3.0. My suggestion: 15-Oct-2008 3.0 beta 4 05-Nov-2008 3.0 rc 2 19-Nov-2008 3.0 rc 3 03-Dec-2008 3.0 final Given what still needs to be done, is this a reasonable schedule? Do we need two more betas? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSOqxvnEjvBPtnXfVAQIR5QP/coSi2ltsZSpE2dyUg7Y35QcSk/+4ZbGK zF0AgLaOkGs+DFnxRH9vy9kN3JaEkp1MhEpDjkomE7kNpnJB7bWotTrHI67HD9ma ZDqqmaCc02IeUtLm7HuELvofjCgh+gryKWvRc71ErRHmn/YxMGr1OcEirPpx4nZ9 DeDV0OeUtTE= =RchU -----END PGP SIGNATURE-----

14 28

[Fwd: In Python 2.6, bytes is str]
by Steve Holden Oct. 8, 2008

Oct. 8, 2008

This does make it look rather as though bytes == str was a decision whose consequences weren't fully appreciated before implementation. Was this horror anticipated? regards Steve -------- Original Message -------- Subject: In Python 2.6, bytes is str Date: Sun, 05 Oct 2008 22:30:17 -0700 From: Bryan Olson <fakeaddress(a)nowhere.org> Organization: at&t http://my.att.net/ To: python-list(a)python.org Newsgroups: gmane.comp.python.general Python 3 has the 'bytes' type, which the string type I've long wanted in various languages. Among other advantages, it is immutable, and therefore bytes objects can be dict keys. There's a mutable version too, called "bytearray". In Python 2.6, the name 'bytes' is defined, and bound to str. The 2.6 assignment presents some pitfalls. Be aware. Consider constructing a bytes object as: b = bytes([68, 255, 0]) In Python 3.x, len(b) will be 3, which feels right. In Python 2.6, len(b) will be 12, because b is the str, '[68, 255, 0]'. I'm thinking I should just avoid using 'bytes' in Python 2.6. If there's another Python release between 2.6 and 3.gold, I'd advocate removing the pre-defined 'bytes', or maybe defining it as something else. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

5 5