Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Antoine Pitrou, 24.08.2013 15:00: > On Sat, 24 Aug 2013 14:51:42 +0200 > Stefan Behnel wrote: >> Antoine Pitrou, 24.08.2013 13:53: >>> This would also imply extension module have to be subclasses of the >>> built-in module type. They can't be arbitrary object

Re: [Python-Dev] Pre-PEP: Redesigning extension modules

Antoine Pitrou, 24.08.2013 13:53: > This would also imply extension module have to be subclasses of the > built-in module type. They can't be arbitrary objects like Stefan > proposed. I'm not sure what the latter enables, but it would probably > make things more difficult internally. My line of th

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Antoine Pitrou, 24.08.2013 12:58: > By the way, just know that Stefan tried to provide a patch that would > better suit his API desires, and failed because ElementTree's current > implementation makes it difficult to do so. Absolutely. I agree that your current implementation is a hack that works

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

Antoine Pitrou, 24.08.2013 01:26: > On Sat, 24 Aug 2013 00:57:48 +0200 > Stefan Behnel wrote: >> ticket 17741 has introduced a new feature in the xml.etree.ElementTree >> module that was added without any major review. >> >> http://bugs.python.org/issue17741 > &

[Python-Dev] please back out changeset f903cf864191 before alpha-2

Hi, ticket 17741 has introduced a new feature in the xml.etree.ElementTree module that was added without any major review. http://bugs.python.org/issue17741 http://hg.python.org/cpython/rev/f903cf864191 I only recently learned about this addition and after taking a couple of closer looks, I fou

[Python-Dev] Pre-PEP: Redesigning extension modules

Title: Redesigning extension modules Version: $Revision$ Last-Modified: $Date$ Author: Stefan Behnel BDFL-Delegate: ??? Discussions-To: ??? Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-Aug-2013 Python-Version: 3.4 Post-History: 23-Aug-2013 Resolution: Abstract Thi

Re: [Python-Dev] redesigning the extension module initialisation protocol

Nick Coghlan, 12.08.2013 00:41: > On 11 Aug 2013 09:55, "Stefan Behnel" wrote: >>>>> this already suggests a simple module initialisation interface. >>>>> The >>>>> extension module would expose a function that returns a module t

Re: [Python-Dev] redesigning the extension module initialisation protocol

Eli Bendersky, 11.08.2013 19:43: > Out of curiosity - can we list actual use cases for this new design? The > previous thread, admittedly, deals with an isoteric corner-cases that comes > up in overly-clever tests. If we plan to serious consider these changes - > and this appears to be worth a PEP

[Python-Dev] redesigning the extension module initialisation protocol (was: Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others))

Nick Coghlan, 11.08.2013 15:19: > On 11 Aug 2013 09:02, "Stefan Behnel" wrote: >>> BTW, this already suggests a simple module initialisation interface. The >>> extension module would expose a function that returns a module type, and >>> the loader/imp

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

Stefan Behnel, 11.08.2013 14:53: > Stefan Behnel, 11.08.2013 14:48: >> Antoine Pitrou, 11.08.2013 14:32: >>> On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote: >>>>> We >>>>> just need to devise a convenience API for that (perhaps by

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

Stefan Behnel, 11.08.2013 14:48: > Antoine Pitrou, 11.08.2013 14:32: >> On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote: >>>> We >>>> just need to devise a convenience API for that (perhaps by allowing to >>>> create both the subclass *and* in

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

Antoine Pitrou, 11.08.2013 14:32: > On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote: >>> We >>> just need to devise a convenience API for that (perhaps by allowing to >>> create both the subclass *and* instantiate it in a single call). >> >&g

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

Antoine Pitrou, 11.08.2013 13:48: > On Sun, 11 Aug 2013 07:04:40 -0400 Nick Coghlan wrote: >> On 11 August 2013 06:33, Antoine Pitrou wrote: >>> So code can be written like: >>> >>> PyObject *dialects = PyState_GetModuleAttr( >>> &_csvmodule, "dialects", &PyDict_Type); >>> if (dialects ==

Re: [Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others)

Antoine Pitrou, 11.08.2013 12:33: > On Sat, 10 Aug 2013 17:12:53 -0700 Eli Bendersky wrote: >> Note how doing some sys.modules acrobatics and re-importing suddenly >> changes the internal state of a previously imported module. This happens >> because: >> >> 1. The first import of 'csv' (which then

Re: [Python-Dev] xml.etree.ElementTree.IncrementalParser

Antoine Pitrou, 09.08.2013 14:50: > Le Fri, 09 Aug 2013 13:11:11 +0200, > Stefan Behnel a écrit : >> I attached it to the ticket that seems to have been the source of this >> addition. >> >> http://bugs.python.org/issue17741 >> >> Please note that the tuli

Re: [Python-Dev] xml.etree.ElementTree.IncrementalParser

Antoine Pitrou, 08.08.2013 10:20: > Le Thu, 08 Aug 2013 06:33:42 +0200, > Stefan Behnel a écrit : >> Antoine Pitrou, 07.08.2013 08:04: >>> http://docs.python.org/dev/library/xml.etree.elementtree.html#incremental-parsing >> >> I don't like the fact that i

[Python-Dev] xml.etree.ElementTree.IncrementalParser (was: ElementTree iterparse string)

[from python-ideas] Antoine Pitrou, 07.08.2013 08:04: > Take a look at IncrementalParser: > http://docs.python.org/dev/library/xml.etree.elementtree.html#incremental-parsing Hmm, that seems to be a somewhat recent addition (April 2013). I would have preferred hearing about it before it got added.

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Stefan Behnel, 06.08.2013 18:38: > Antoine Pitrou, 06.08.2013 17:49: >> Le Tue, 06 Aug 2013 17:18:59 +0200, >> Stefan Behnel a écrit : >>> If a Python class with a >>> __del__ inherits from an extension type that implements >>> tp_finalize(), then

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Antoine Pitrou, 06.08.2013 17:49: > Le Tue, 06 Aug 2013 17:18:59 +0200, > Stefan Behnel a écrit : >> If a Python class with a >> __del__ inherits from an extension type that implements >> tp_finalize(), then whose tp_finalize() will be executed first? > > Then only

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

Ryan, 06.08.2013 17:02: > Nice idea, but some of those may break 3rd party libraries like Boost. > Python that have their own equilavent of the Python/C API. Or Even SWIG > might experience trouble in one or two of those. Te idea is that this will be an alternative way of initialising a module tha

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Antoine Pitrou, 06.08.2013 14:12: > Le Mon, 05 Aug 2013 22:30:29 +0200, > Stefan Behnel a écrit : >> >> Hmm, it's a bit unfortunate that tp_finalize() maps so directly to >> __del__(), but I think this can be fixed. In any case, each >> tp_finalize() function mus

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

Nick Coghlan, 06.08.2013 07:35: > If you wanted to reboot this thread on import-sig, that would probably > be a good thing :) Sigh. Yet another list to know about and temporarily follow... The import-sig list doesn't seem to be mirrored on Gmane yet. Also, it claims to be dead w.r.t. Py3.4: """

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

Hi, let me revive and summarize this old thread. Stefan Behnel, 08.11.2012 13:47: > I suspect that this will be put into a proper PEP at some point, but I'd > like to bring this up for discussion first. This came out of issues 13429 > and 16392. > > http://bugs.python.org/

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Antoine Pitrou, 05.08.2013 21:26: > On Mon, 05 Aug 2013 21:03:33 +0200 > Stefan Behnel wrote: >> I think the main problem I have with the PEP is this part: >> >> """ >> The PEP doesn't change the semantics of: >> * C extension types with a

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Antoine Pitrou, 05.08.2013 20:56: > On Sun, 04 Aug 2013 17:59:57 +0200 > Stefan Behnel wrote: >>> I continued my implementation and found that calling up the base type >>> hierarchy is essentially the same code as calling up the hierarchy for >>> tp_dealloc()

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Hi, I was just continuing in my monologue when you replied, so I'll just drop my response below. Antoine Pitrou, 05.08.2013 20:51: > On Sun, 04 Aug 2013 09:23:41 +0200 > Stefan Behnel wrote: >> I'm currently catching up on PEP 442, which managed to fly completely below >

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Stefan Behnel, 04.08.2013 15:24: > Stefan Behnel, 04.08.2013 09:23: >> I'm currently catching up on PEP 442, which managed to fly completely below >> my radar so far. It's a really helpful change that could end up fixing a >> major usability problem that Cython wa

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Stefan Behnel, 04.08.2013 09:23: > I'm currently catching up on PEP 442, which managed to fly completely below > my radar so far. It's a really helpful change that could end up fixing a > major usability problem that Cython was suffering from: user provided > deallocati

[Python-Dev] PEP 442 clarification for type hierarchies

Hi, I'm currently catching up on PEP 442, which managed to fly completely below my radar so far. It's a really helpful change that could end up fixing a major usability problem that Cython was suffering from: user provided deallocation code now has a safe execution environment (well, at least in P

Re: [Python-Dev] Python 3 as a Default in Linux Distros

Gustavo Carneiro, 24.07.2013 19:16: > On Wed, Jul 24, 2013 at 6:04 PM, Terry Reedy wrote: >> On 7/24/2013 5:12 AM, Bohuslav Kabrda wrote: >>> Hi all, in recent days, there has been a discussion on fedora-devel >>> (see thread [1]) about moving to Python 3 as a default. >> >> Not being a current *ni

Re: [Python-Dev] PEP 435 - requesting pronouncement

Antoine Pitrou, 05.05.2013 12:05: > On Sat, 4 May 2013 15:04:49 -0700 > Eli Bendersky wrote: >> PEP 435 is ready for final review. A lot of the feedback from the last few >> weeks of discussions has been incorporated. > > I still would like to see Nick's class-based API preferred over the > functi

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

Ethan Furman, 02.05.2013 21:07: > In order for the Enum convenience function to be pickleable, we have this > line of code in the metaclass: > > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] What a hack. And fragile, too. > This works fine for Cpython, but what about the ot

Re: [Python-Dev] libffi inclusion in python

Maciej Fijalkowski, 18.04.2013 13:41: > PyPy gets along relying on the system library Depends on what systems you want to support, I guess. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Uns

Re: [Python-Dev] The end of 2.7

Christian Tismer, 07.04.2013 15:53: > But I think every employee (including you) can quite easily put some pressure > on his company by claiming that Python 2.x is a dead end, and everybody is > about to move on to 3.x. > This does not have to be true, I just recognize that by claiming it and > do

Re: [Python-Dev] The end of 2.7

Maciej Fijalkowski, 07.04.2013 10:45: > On Sun, Apr 7, 2013 at 10:42 AM, Stefan Behnel wrote: >> Maciej Fijalkowski, 07.04.2013 10:37: >>> On Sun, Apr 7, 2013 at 10:32 AM, Stefan Behnel wrote: >>>> Maciej Fijalkowski, 07.04.2013 10:12: >>>>> On Sun, Ap

Re: [Python-Dev] The end of 2.7

Maciej Fijalkowski, 07.04.2013 10:37: > On Sun, Apr 7, 2013 at 10:32 AM, Stefan Behnel wrote: >> Maciej Fijalkowski, 07.04.2013 10:12: >>> On Sun, Apr 7, 2013 at 9:51 AM, wrote: >>>> Quoting Lennart Regebro: >>>>> On Sun, Apr 7, 2013 at 7:11 AM, wr

Re: [Python-Dev] The end of 2.7

Maciej Fijalkowski, 07.04.2013 10:12: > On Sun, Apr 7, 2013 at 9:51 AM, wrote: >> Quoting Lennart Regebro: >>> On Sun, Apr 7, 2013 at 7:11 AM, wrote: Wrt. to the 3.x migration rate: I think this is a self-fulfilling prophecy. Migration rate will certainly increase once we announce >>>

Re: [Python-Dev] The end of 2.7

Maciej Fijalkowski, 07.04.2013 09:52: > As far as I remember python 3 was supposed to be a better language, > not just "the maintained version". It's such a bad idea to force > people to go through porting because 2.x is not maintained any more. > If they never migrate on the premises of python 3 b

Re: [Python-Dev] Semantics of __int__(), __index__()

Guido van Rossum, 04.04.2013 23:14: > On Thu, Apr 4, 2013 at 1:50 PM, Tim Delaney wrote: >> I fall into: >> >> 1. int(), float(), str() etc should return that exact class (and >> operator.index() should return exactly an int). >> >> 2. It could sometimes be useful for __int__() and __index__() to r

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

Brett Cannon, 02.04.2013 19:28: > On Tue, Apr 2, 2013 at 1:20 PM, Steve Dower wrote: > >>> python -m pyzaa pack [-o path/name] [-m module.submodule:callable] [-c] >> [-w] [-p interpreter] directory: >>> >>>ZIP the contents of directory as directory.pyz or [-w] >> directory.pyzw. Adds the execu

Re: [Python-Dev] Safely importing zip files with C extensions

Vinay Sajip, 27.03.2013 20:38: > >>> w = Wheel('/tmp/simplejson-3.1.2-cp27-none-linux_x86_64.whl') > >>> w.mount() > >>> import simplejson._speedups > >>> dir(simplejson._speedups) > ['__doc__', '__file__', '__loader__', '__name__', '__package__', > 'encode_basestring_ascii', 'make_encoder', 'make

Re: [Python-Dev] astoptimizer: static optimizer working on the AST

Victor Stinner, 26.03.2013 22:56: > * what should be the name of "pyc" files? > * how to handle different configuration of astoptimizer: generate > different "pyc" files? You could use (a part of) a crypto hash of the serialised options as part of the filename. One drawback of a .pyc duplication

Re: [Python-Dev] Rough idea for adding introspection information for builtins

Larry Hastings, 19.03.2013 05:45: > The original impetus for Argument Clinic was adding introspection > information for builtins [...] > On to the representation. Consider the function > >def foo(arg, b=3, *, kwonly='a'): > pass > [...] > 4. Store a string that looks like the Python d

Re: [Python-Dev] Status of XML fixes

Eli Bendersky, 17.03.2013 19:25: > IMHO Benjamin is right, given that this attack has been known to exist > since 2003. Moreover, as it appears that no changes whatsoever are going to > make it into 2.7, I don't see why patching of 3.1, 3.2 and 3.3 is needed. > As for 3.4, it can't hurt to add an o

[Python-Dev] Add PyDict_GetItemSetDefault() as C-API for dict.setdefault()

Hi, I've written a patch that adds a new C-API call for dict.setdefault(). The reason is that there is currently no way to test for a key and insert a fallback value for it without either evaluating the hash function twice or calling through the Python function. Both may involve considerable overh

Re: [Python-Dev] VC++ 2008 Express Edition now locked away?

Chris Angelico, 06.03.2013 17:30: > On Thu, Mar 7, 2013 at 1:40 AM, Ezio Melotti wrote: >> I did try a few weeks ago, when I had to download a copy of Windows >> for a project. Long story short, after 30+ minutes and a number of >> confirmation emails I reached a point where I had a couple of new

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

Stefan Krah, 02.03.2013 21:01: > Stefan Behnel wrote: >>>> I'm not so happy with the argument clinic, but that's certainly also >>>> because I'm biased. I've written the argument unpacking code for Cython >>>> some years ago, so it'

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

Hi Nick, thanks for the feedback. Nick Coghlan, 02.03.2013 17:58: > On Fri, Mar 1, 2013 at 7:41 PM, Stefan Behnel wrote: >> Michael Foord, 27.02.2013 17:51: >> It's also true that many of the topics above aren't really interesting for >> us, because we just inherit

Re: [Python-Dev] cffi in stdlib

Hi, looks like no-one's taken over the role of the Advocatus Diaboli yet. =) Maciej Fijalkowski, 26.02.2013 16:13: > I would like to discuss on the language summit a potential inclusion > of cffi[1] into stdlib. This is a project Armin Rigo has been working > for a while, with some input from oth

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

Michael Foord, 27.02.2013 17:51: > PyCon, and the Python Language Summit, is nearly upon us. We have a good > number of people confirmed to attend. If you are intending to come to the > language summit but haven't let me know please do so. > > The agenda of topics for discussion so far includes

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Maciej Fijalkowski, 20.02.2013 21:17: > On Wed, Feb 20, 2013 at 8:24 PM, Christian Heimes wrote: >> Am 20.02.2013 17:25, schrieb Benjamin Peterson: >>> Are these going to become patches for Python, too? >> >> I'm working on it. The patches need to be discussed as they break >> backward compatibilit

Re: [Python-Dev] Point of building without threads?

Yury V. Zaytsev, 08.01.2013 10:28: > Moreover, these days there is a clear trend towards OpenMP, so it has > become even harder to pressure the manufacturers to fix threads, because > they have 101 argument why you should port your code to OpenMP instead. I can't see OpenMP being an *alternative*

Re: [Python-Dev] A new webpage promoting Compiler technology for CPython

Nick Coghlan, 16.02.2013 08:49: > Yes, the PyPy team and scientific users of Python have a long history > of talking past each other (and abusing each other for the mutual lack > of understanding). However, that's no excuse for deliberately ignoring > the advantages JIT compilation can bring No-on

Re: [Python-Dev] A new webpage promoting Compiler technology for CPython

Steven D'Aprano, 16.02.2013 07:13: > On 16/02/13 16:41, Stefan Behnel wrote: > >>> PyPy is indeed a work in progress in this area, but that doesn't >>> necessarily preclude it from being included. >> >> That may be a matter of POV, but as long as P

Re: [Python-Dev] A new webpage promoting Compiler technology for CPython

Philip Jenvey, 16.02.2013 01:01: > On Fri, Feb 15, 2013 at 2:36 PM, Stefan Behnel wrote: >> So, while I agree that PyPy is worth a try in certain application areas, >> and can be helpful for some special needs, also in the field of scientific >> computing, it's lightye

Re: [Python-Dev] A new webpage promoting Compiler technology for CPython

Paul Boddie, 15.02.2013 22:44: > Travis Oliphant wrote: >> This page is specifically for Compiler projects that either integrate with >> or work directly with the CPython run-time which is why PyPy is not >> presently listed. The PyPy project is a great project but we just felt >> that we wanted t

Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython

Hi, this reply seems to have drowned, so here it is again. Stefan Behnel, 04.12.2012 16:36: > Why not provide a constructor for signature objects that parses the > signature from a string? For a signature like > >def func(int arg1, float arg2, ExtType arg3, *, > o

Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement

Antoine Pitrou, 10.02.2013 15:28: > On Mon, 11 Feb 2013 00:09:55 +1000 Nick Coghlan wrote: >> As far as the maintenance burden goes, the patch to enable PEP 422 for >> types.new_class() is trivial: >> >> -return meta(name, bases, ns, **kwds) >> +cls = meta(name, bases, ns, **kwds) >> +t

Re: [Python-Dev] Why does Signature.from_function() have to check the type of its argument?

Stefan Behnel, 08.02.2013 22:14: > PJ Eby, 08.02.2013 19:46: >> On Fri, Feb 8, 2013 at 10:54 AM, Stefan Behnel wrote: >>> Nick Coghlan, 08.02.2013 16:20: >>>> On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote: >>>>> 2013/2/8 Stefan Behnel: >&g

Re: [Python-Dev] Why does Signature.from_function() have to check the type of its argument?

PJ Eby, 08.02.2013 19:46: > On Fri, Feb 8, 2013 at 10:54 AM, Stefan Behnel wrote: >> Nick Coghlan, 08.02.2013 16:20: >>> On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote: >>>> 2013/2/8 Stefan Behnel: >>>>> I'm wondering about the purpose of

Re: [Python-Dev] Why does Signature.from_function() have to check the type of its argument?

Nick Coghlan, 08.02.2013 16:20: > On Sat, Feb 9, 2013 at 1:06 AM, Benjamin Peterson wrote: >> 2013/2/8 Stefan Behnel: >>> I'm wondering about the purpose of this code in >>> inspect.Signature.from_function(): >>> >>> """ >&

Re: [Python-Dev] Why does Signature.from_function() have to check the type of its argument?

Nick Coghlan, 08.02.2013 16:08: > On Sat, Feb 9, 2013 at 12:09 AM, Stefan Behnel wrote: >> I'm wondering about the purpose of this code in >> inspect.Signature.from_function(): >> >> """ >> if not isinstance(func, types.FunctionType): >

[Python-Dev] Why does Signature.from_function() have to check the type of its argument?

Hi, I'm wondering about the purpose of this code in inspect.Signature.from_function(): """ if not isinstance(func, types.FunctionType): raise TypeError('{!r} is not a Python function'.format(func)) """ Is there any reason why this method would have to explicitly check the type of its

Re: [Python-Dev] Boost Software License

Serhiy Storchaka, 27.01.2013 17:52: > Is Boost Software License [1] compatible with Python license? Can I steal > some code from Boost library [2]? > > [1] http://www.boost.org/LICENSE_1_0.txt > [2] http://www.boost.org/ Depends on what you want to do with it after stealing it. Assuming you want

Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython

Larry Hastings, 03.12.2012 23:29: > Say there, the Python core development community! Have I got > a question for you! > > *ahem* > > Which of the following four options do you dislike least? ;-) > > 1) CPython continues to provide no "function signature" >objects (PEP 362) or inspect.getf

Re: [Python-Dev] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)

Greg Ewing, 15.11.2012 11:48: > mar...@v.loewis.de wrote: >> It's faster than calling dict() because the dict code will >> create a second dictionary, and discard the keywords dictionary. > > Perhaps in the case where dict() is called with keyword > args only, it could just return the passed-in ke

Re: [Python-Dev] performance of {} versus dict()

Chris Withers, 15.11.2012 08:14: > On 15/11/2012 06:32, Stefan Behnel wrote: >> Donald Stufft, 15.11.2012 00:00: >>> $ pypy -m timeit 'dict()' >>> 10 loops, best of 3: 0.000811 usec per loop >>> >>> $ pypy -m timeit '

Re: [Python-Dev] performance of {} versus dict()

Donald Stufft, 15.11.2012 00:00: > $ pypy -m timeit 'dict()' > 10 loops, best of 3: 0.000811 usec per loop > > $ pypy -m timeit '{}' > 10 loops, best of 3: 0.000809 usec per loop > > $ pypy -m timeit 'def md(**kw): return kw; md()' > 1 loops, best of 3: 0.0182 usec per

Re: [Python-Dev] performance of {} versus dict()

Chris Angelico, 14.11.2012 14:18: > On Wed, Nov 14, 2012 at 8:12 PM, Chris Withers wrote: >> I suspect I'm not the only one who finds: >> >> a_dict = dict( >> x = 1, >> y = 2, >> z = 3, >> ... >> ) >> >> ...easier to read than: >> >> a_dict = { >> 'x':1, >> 'y':2, >>

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

Brett Cannon, 08.11.2012 16:06: > On Thu, Nov 8, 2012 at 10:00 AM, Stefan Behnel wrote: > >> Hi Brett, >> >> thanks for the feedback. >> >> Brett Cannon, 08.11.2012 15:41: >>> On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote: >>>> I

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

Hi Brett, thanks for the feedback. Brett Cannon, 08.11.2012 15:41: > On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote: >> I propose to split the extension module initialisation into two steps in >> Python 3.4, in a backwards compatible way. >> >> Step 1: The curre

[Python-Dev] Update - Re: Make extension module initialisation more like Python module initialisation

Hi, here's an updated proposal, adopting Marc-Andre's improvement that uses a new field in the PyModuleDef struct to register the callback. Note that this change no longer keeps up binary compatibility, which may or may not be acceptable for Python 3.4. Stefan The problem === Python mo

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

Stefan Behnel, 08.11.2012 14:20: > M.-A. Lemburg, 08.11.2012 14:01: >> On 08.11.2012 13:47, Stefan Behnel wrote: >>> I suspect that this will be put into a proper PEP at some point, but I'd >>> like to bring this up for discussion first. This came out of issues 1

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

M.-A. Lemburg, 08.11.2012 14:01: > On 08.11.2012 13:47, Stefan Behnel wrote: >> I suspect that this will be put into a proper PEP at some point, but I'd >> like to bring this up for discussion first. This came out of issues 13429 >> and 16392. >> >> http:/

[Python-Dev] Make extension module initialisation more like Python module initialisation

Hi, I suspect that this will be put into a proper PEP at some point, but I'd like to bring this up for discussion first. This came out of issues 13429 and 16392. http://bugs.python.org/issue13429 http://bugs.python.org/issue16392 Stefan The problem === Python modules and extension mo

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

Tim Delaney, 28.10.2012 20:48: On 28 October 2012 18:22, Stefan Behnel wrote: How much of an effect would it have on startup times and these benchmarks if Cython-compiled extensions were used? Depends on what and how much code you use. If you compile everything into one big module that

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

Stefan Behnel, 28.10.2012 08:22: Tim Delaney, 27.10.2012 22:53: How much of an effect would it have on startup times and these benchmarks if Cython-compiled extensions were used? Depends on what and how much code you use. If you compile everything into one big module that "imports"

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

Tim Delaney, 27.10.2012 22:53: On 28 October 2012 07:40, Mark Shannon wrote: I suspect that stating and loading the .pyc files is responsible for most of the overhead. PyRun starts up quite a lot faster thanks to embedding all the modules in the executable: http://www.egenix.com/**products/pyth

Re: [Python-Dev] [Python-checkins] cpython: Add a few entries to whatsnew/3.3.rst.

Ezio Melotti, 26.09.2012 18:30: > """ > The problem is that the standard allows some charref to end without a > ';', but not all of them. > > So both "Éric" and Éric" will be parsed as "Éric", but > only "αcentauri" will result in "αcentauri" -- "&alphacentauri" > will be returned unchanged. > """

Re: [Python-Dev] Release of astoptimizer 0.3

Serhiy Storchaka, 11.09.2012 20:48: > set([1, 2, 3]) => {1, 2, 3} > set([x for ...]) => {x for ...} > dict([(k, v) for ...]) => {k: v for ...} > dict((k, v) for ...) => {k: v for ...} > ''.join([s for ...]) => ''.join(s for ...) > a.extend([s for ...]) => a.extend(s for ...) > (f(x) for x in a) =>

Re: [Python-Dev] Release of astoptimizer 0.3

Nick Coghlan, 11.09.2012 14:57: > On Tue, Sep 11, 2012 at 8:41 PM, Victor Stinner wrote: >> * Loop: replace range() with xrange() on Python 2, and list with >> tuple. Examples: >> >> - for x in range(n): ... => for x in xrange(n): ... >> - for x in [1, 2, 3]: ... => for x in (1, 2, 3): ... >

Re: [Python-Dev] 3.3 str timings

Xavier Morel, 21.08.2012 19:56: > On 21 août 2012, at 19:25, Steven D'Aprano wrote: >> On 21/08/12 23:04, Victor Stinner wrote: >>> I don't like the timeit module for micro benchmarks, it is really >>> unstable (default settings are not written for micro benchmarks). >> [...] >>> I wrote my own be

Re: [Python-Dev] AST optimizer implemented in Python

Stefan Behnel, 12.08.2012 08:00: > Victor Stinner, 11.08.2012 20:30: >> I started to implement an AST optimizer in Python. It's easy to create >> a new AST tree, so I'm surprised that I didn't find any existing >> project. >> >> https://bitbucke

Re: [Python-Dev] AST optimizer implemented in Python

"Martin v. Löwis", 11.08.2012 23:27: >>> +1 We should add some form of setastoptimizer API in 3.4. Please start a >>> PEP for this. It would be nice to include the ability to properly cache >>> the >>> ast optimizer output so that it does not have to run every time (in pyc >>> files or similar,

Re: [Python-Dev] AST optimizer implemented in Python

Victor Stinner, 11.08.2012 20:30: > I started to implement an AST optimizer in Python. It's easy to create > a new AST tree, so I'm surprised that I didn't find any existing > project. > > https://bitbucket.org/haypo/misc/src/tip/python/ast_optimizer.py Since you're about to do pretty much the sa

Re: [Python-Dev] AST optimizer implemented in Python

Stefan Behnel, 12.08.2012 06:42: > Chris Angelico, 12.08.2012 01:22: >>> Other idea to improve this optimizer: >>> - move invariant out of loops. Example: "x=[]; for i in range(10): >>> x.append(i)" => "x=[]; x_append=x.append; for i in range(10)

Re: [Python-Dev] AST optimizer implemented in Python

Chris Angelico, 12.08.2012 01:22: >> Other idea to improve this optimizer: >> - move invariant out of loops. Example: "x=[]; for i in range(10): >> x.append(i)" => "x=[]; x_append=x.append; for i in range(10): >> x_append(i)". Require to infer the type of variables. > > But this is risky. It's th

[Python-Dev] PEP 366 is unclear about what it specifies

Hi, could someone please add a sentence to PEP 366 that describes the actual content of the new "__package__" attribute (and thus, the PEP)? http://www.python.org/dev/peps/pep-0366/ I had to read through almost the entire document to be assured that "__package__" is really supposed to contain a

Re: [Python-Dev] A new JIT compiler for a faster CPython?

mar...@v.loewis.de, 18.07.2012 07:53: > [Victor Stinner] >> I don't want to write my own library to generate machine code. > > I plan to use nanojit. As I said, generating machine code is the uninteresting part of it and won't give you much of a win. The changes you make to the way the code works

Re: [Python-Dev] A new JIT compiler for a faster CPython?

Alex Gaynor, 18.07.2012 03:24: > Victor Stinner writes: >> Example: >> >> a = GETLOCAL(0); # "a" >> if (a == NULL) /* error */ >> b = GETLOCAL(1); # "b" >> if (b == NULL) /* error */ >> return PyNumber_Add(a, b); >> >> >> I don't expect to run a program 10x faster, but I would be happy if

Re: [Python-Dev] A new JIT compiler for a faster CPython?

Victor Stinner, 18.07.2012 00:15: >> Personally, I like the idea of having a JIT compiler more or less as an >> extension module at hand. Sort-of like a co-processor, just in software. >> Lets you run your code either interpreter or JITed, just as you need. > > Me too, so something like psyco. In

Re: [Python-Dev] A new JIT compiler for a faster CPython?

Maciej Fijalkowski, 17.07.2012 21:16: > It would be much better to concentrate efforts rather than write > yet another half-finished JIT (because reading code is hard). +1 Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/

Re: [Python-Dev] A new JIT compiler for a faster CPython?

Victor Stinner, 17.07.2012 20:38: > -- Subset of Python -- > > * `pymothoa `_: use LLVM; don't > support classes nor exceptions. > * `unpython `_: Python to C > * `Perthon `_: Python to Perl

Re: [Python-Dev] Do we need __length_hint__ at all? (Was PEP 0424: A method for exposing a length hint)

Maciej Fijalkowski, 16.07.2012 11:14: > On Mon, Jul 16, 2012 at 11:02 AM, Stefan Behnel wrote: >> Mark Shannon, 16.07.2012 10:37: >>> If resizing of lists is too slow, then we should reconsider the 9/8 >>> factor and/or look to tweak the resizing code. >> >&g

Re: [Python-Dev] Do we need __length_hint__ at all? (Was PEP 0424: A method for exposing a length hint)

Mark Shannon, 16.07.2012 10:37: > If resizing of lists is too slow, then we should reconsider the 9/8 factor > and/or look to tweak the resizing code. The thing is that the performance is platform specific. On systems with a fast memory allocator, especially on Linux, the difference is negligible.

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Nick Coghlan, 16.07.2012 10:26: > Proposing anything substantially more complicated than what is currently > implemented in CPython will just get the idea rejected. The substantial > immediate gain for PyPy is in skipping the memory resizing when building > containers from itertools iterators, not

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Alex Gaynor, 15.07.2012 00:11: > CPython currently defines an ``__length_hint__`` method on several types, such > as various iterators. This method is then used by various other functions > (such > as ``map``) to presize lists based on the estimated returned by > ``__length_hint__``. Types can th

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Antoine Pitrou, 15.07.2012 17:06: > On Sun, 15 Jul 2012 16:33:23 +0200 > Christian Heimes wrote: >> Am 15.07.2012 16:22, schrieb Antoine Pitrou: >>> On Mon, 16 Jul 2012 00:08:41 +1000 >>> Nick Coghlan wrote: Right, I agree on the value in being able to return something to say "this cannot

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Mark Shannon, 15.07.2012 16:14: > Alex Gaynor wrote: >> CPython currently defines an ``__length_hint__`` method on several types, >> such >> as various iterators. This method is then used by various other functions >> (such as ``map``) to presize lists based on the estimated returned by > > Don't

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Alex Gaynor, 15.07.2012 07:20: > there's no way for the __lenght_hint__ to specify that > that particular instance can't have a length hint computed. e.g. imagine > some sort of lazy stream that cached itself, and only wanted to offer a > length hint if it had already been evaluated. Without an e

<    1   2   3   4   5   6   7   >