Mailman 3 November 2012 - Python-Dev

Re: [Python-Dev] performance of {} versus dict()
by Chris Withers Nov. 14, 2012

Nov. 14, 2012

On 14/11/2012 09:58, Merlijn van Deen wrote: > On 14 November 2012 10:12, Chris Withers <chris(a)simplistix.co.uk> wrote: >> ...which made me a little sad > > Why did it make you sad? dict() takes 0.2µs, {} takes 0.04µs. In other > words: you can run dict() _five million_ times per second, and {} > twenty-five million times per second. That is 'a lot' and 'a lot'. It > also means you are unlikely to notice the difference in real-world > code. Just use the one you feel is clearer in the situation, and don't > worry about micro-optimalization. I'm inclined to agree, but it makes me sad for two reasons: - it's something that people get hung up on, for better or worse. (if it wasn't, Doug wouldn't have written his article) - it can make a difference, for example setting up a dict with many keys at the core of a type loop. Without looking at implementation, they should logically perform the same... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

3 2

Re: [Python-Dev] Python-Dev Digest, Vol 112, Issue 23
by Peter Harris Nov. 14, 2012

Nov. 14, 2012

Chris Withers wrote: > On 14/11/2012 09:58, Merlijn van Deen wrote: > > On 14 November 2012 10:12, Chris Withers <chris(a)simplistix.co.uk> wrote: > >> ...which made me a little sad > > > > Why did it make you sad? dict() takes 0.2?s, {} takes 0.04?s. In other > > words: you can run dict() _five million_ times per second, and {} > > twenty-five million times per second. That is 'a lot' and 'a lot'. It > > also means you are unlikely to notice the difference in real-world > > code. Just use the one you feel is clearer in the situation, and don't > > worry about micro-optimalization. > > I'm inclined to agree, but it makes me sad for two reasons: > > - it's something that people get hung up on, for better or worse. (if it > wasn't, Doug wouldn't have written his article) > > - it can make a difference, for example setting up a dict with many keys > at the core of a type loop. > > Without looking at implementation, they should logically perform the > same... > > Well, without looking at the implementation, you could form any opinion you like about how they should perform. Still you could speculate that dict() will require a builtins name lookup, and that the process of passing keyword arguments might itself involve constructing a dictionary, so must inherently take at least a little longer than compiling a {} literal. Peter

1 0

Re: [Python-Dev] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427
by a.cavallo＠cavallinux.eu Nov. 14, 2012

Nov. 14, 2012

+1 Distutils is good enough: it could be better but for what is required (essentially copying files and creating packages installers) is fine. The only corner case is an absolute pain in the neck is in the cross compile scenario. Currently I don't have *any* need for "auto" tools (setuptools and descendants). As an example I always advice to avoid like a plague anything that depends on setuptools... with all the due respect I think is the poor's developer attempt to play the sys admin game. Even virtual env is a poor work around on the python interpreter not being relocatable (as in a portable app fashion). thanks On Tue 13/11/12 16:10, "Ronald Oussoren" ronaldoussoren(a)mac.com wrote: > > On 13 Nov, 2012, at 16:00, Daniel Holth <dholth@gmail > .com> wrote: > > > I want to remove distutils from the standard > library. > Why? Distutils may not be perfect, but is usable for basic packages. It > could even be enhanced to support these peps and be even more useable, > although patches for that would run into the self-imposed freeze of > distutils development. > Ronald > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://mail.python.org/mailman/listinfo/distutils-sig > >

6 5

Re: [Python-Dev] cpython (3.2): add gc_collects to weakref tests
by Antoine Pitrou Nov. 13, 2012

Nov. 13, 2012

On Tue, 13 Nov 2012 21:26:51 +0100 (CET) philip.jenvey <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/a580cf4ab940 > changeset: 80418:a580cf4ab940 > branch: 3.2 > parent: 80397:8a28c974f903 > user: Philip Jenvey <pjenvey(a)underboss.org> > date: Tue Nov 13 12:26:31 2012 -0800 > summary: > add gc_collects to weakref tests > > files: > Lib/test/test_exceptions.py | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) While this is necessary for non-refcounted implementations, it does relax the requirement quite a bit for CPython (absence of reference cycles can be a significant feature). I think perhaps gc_collect() should be called only for non-CPython implementations. Regards Antoine.

1 0

accept the wheel PEPs 425, 426, 427
by Daniel Holth Nov. 13, 2012

Nov. 13, 2012

I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer. Wheel is a binary packaging format that is mostly based on the phenomenal work done by 'packaging' as PEP 376 et al. The resulting packages solve packaging problems by being installable without setup.py or any variation of distutils, lxml can be installed in 0.7 seconds, and a simple installer is just "unzip" inside site-packages. Wheel installers know about the major version number of the spec itself, and will refuse to install version 2.0 wheels if they do not understand them, so the format can be changed down the line. Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP. Thanks, Daniel Holth

12 42

Re: [Python-Dev] [Distutils] [Catalog-sig] accept the wheel PEPs425, 426, 427
by a.cavallo＠cavallinux.eu Nov. 13, 2012

Nov. 13, 2012

I'll give you that number(?) but ... mercurial, docutils, jinjia2 pygments, sphinx, lxml, nose, cherrypy, django, pyqt ... all they don't need/use setuptools: that 25% left is quite an interesting field to play in. If setuptools was "significant packaging innovation" do you think people wouldn't have embraced already? Allow me to call *that* a nonsense. thanks ps. my experience is on the field, so please give me the credit of many years of experience if I'm say I'm not that keen on "auto" tools: in this kiss rules. On Tue 13/11/12 17:35, "Daniel Holth" dholth(a)gmail.com wrote: > Setuptools! You would avoid 75% of pypi. It is nonsense to pretend > that setuptools is not a significant packaging innovation. Its main > flaw is that it is based on distutils, a non-extensible design. > distutils2 is a lot of setuptools and distutils code with the > plug-ability taken out. > > Perhaps I should say that I would like distutils to become as > relevant to packaging as the cgi module is to web development. It is > not a short-term goal. > >

1 0

Improve error message "UnboundLocalError: local variable referenced before assignment"
by anatoly techtonik Nov. 12, 2012

Nov. 12, 2012

Here is the code: ---[cut]----------------------------- DEBUG = [] FONT_NAMES = [] def names(): if len(DEBUG): print(len(DEBUG)) if len(FONT_NAMES): print(len(FONT_NAMES)) if len(FONT_NAMES)==0: FONT_NAMES = "query()" names() ---[cut]----------------------------- Here is the output: Traceback (most recent call last): File "globalocal.py", line 13, in <module> names() File "globalocal.py", line 8, in names if len(FONT_NAMES): UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment As you may see there is inconsistency between handling of line 6 - "if len(DEBUG):" and line 8 - "if len(FONT_NAMES):". This is very magical and hard to troubleshoot. I wonder if this message can be improved with a pointer to the concept on when global variables become local? -- anatoly t.

12 14

Okay to document the "exec tuple" form of the exec statement in Python 2.7?
by Mark Dickinson Nov. 12, 2012

Nov. 12, 2012

In Python 2, the 'exec' statement supports 'exec'-ing a (statement, globals, locals) tuple: >>> exec("print 2", {}, {}) 2 This isn't currently documented at: http://docs.python.org/reference/simple_stmts.html#the-exec-statement. It's easy to fix the docs, but in doing so we'd effectively be blessing this form of exec as an official part of the language. Do people think it's acceptable to add this to the docs, or are there good reasons for the 'exec tuple' form of the exec statement to remain an undocumented feature? See also http://bugs.python.org/issue16339. Mark

5 5

Re: [Python-Dev] cpython: Issue #16416: OS data are now always encoded/decoded to/from
by Antoine Pitrou Nov. 12, 2012

Nov. 12, 2012

On Mon, 12 Nov 2012 23:03:45 +0100 (CET) victor.stinner <python-checkins(a)python.org> wrote: > > +- Issue #16416: OS data are now always encoded/decoded to/from > + UTF-8/surrogateescape, instead of the locale encoding (which may be ASCII if > + no locale environment variable is set), to avoid inconsistencies with > + os.fsencode() and os.fsdecode() functions which are already using > + UTF-8/surrogateescape. I believe you mean "OS X", not "OS". Regards Antoine.

1 0

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fixes issue #16409: The reporthook callback made by the legacy
by Nadeem Vawda Nov. 10, 2012

Nov. 10, 2012

This change appears to have broken test_urllib. See, for example: http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/47… - Nadeem

1 0