Re: [Python-Dev] backported Enum
On 16 June 2013 15:58, Donald Stufft wrote: > > On Jun 16, 2013, at 1:52 AM, Ben Finney wrote: > > Donald Stufft writes: > > On Jun 15, 2013, at 10:45 PM, Ben Finney wrote: > > Is there anything I can do to keep the ‘enum’ package online for > continuity but make it clear, to automated tools, that this is > end-of-life and obsoleted by another package? > > > Right now the best you can do is make a note of it. Pep 426 let's you > do what you want. > > > Thanks. What specifically in PEP 426 do you mean; how would I make a > note of “this package is end-of-life as is, please migrate to > ‘flufl.enum’ instead” using PEP 426 metadata? > > > http://www.python.org/dev/peps/pep-0426/#obsoleted-by > > Note PEP426 isn't completed and isn't implemented :) That specific bit is stable, though :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
On 06/15/2013 06:50 PM, Donald Stufft wrote: I claimed backport.enum, but you're welcome to the name. I was going to try and backport this PEP under that name anyways. Thank you for the offer, but I think I'll go with GPS's idea of calling it enum34. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
On 06/15/2013 10:52 PM, Ben Finney wrote: Donald Stufft writes: On Jun 15, 2013, at 10:45 PM, Ben Finney wrote: Is there anything I can do to keep the ‘enum’ package online for continuity but make it clear, to automated tools, that this is end-of-life and obsoleted by another package? Right now the best you can do is make a note of it. Pep 426 let's you do what you want. Thanks. What specifically in PEP 426 do you mean; how would I make a note of “this package is end-of-life as is, please migrate to ‘flufl.enum’ instead” using PEP 426 metadata? Note that while flufl.enum was the inspiration, it is not the version that went into 3.4. Differences include: Enum does not allow subclassing when members have been defined int(Enum.member) is an error Similarities include: different Enum enumerations do not compare to each other members in an Enum enumeration are not ordered There may be (and probably are) other differences from flufl.enum, but it's late and I'm not remembering them. So to cut a long story short, your note should say: "migrate to enum34 instead." Oh, and I'm still learning the intricacies of distutils -- you should be able to ignore any errors if you try to install using `easy_install enum34`; I'll hopefully get those kinks worked out in the next few days. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backports galore
Now we have (at least) the following libraries backported from 3.2+ to older versions of Python by members of the core team: - configparser - enum34 - singledispatch - subprocess32 - unittest2 There are also unofficial backports like billiard (multiprocessing). I would be happy if all those were more discoverable by the community at large. Having a single namespace for backports would be great but my spidey sense forebodes large flocks of bike sheds flying that way. Can we put links to those backports in the docs of older versions of Python? Most users would be better off using the updated packages while still deploying on an older release of Python. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #3329: Add new APIs to customize memory allocators
On Sun, 16 Jun 2013 01:48:06 +0200 Victor Stinner wrote: > 2013/6/15 Christian Heimes : > > Am 15.06.2013 14:22, schrieb Nick Coghlan: > >> However, it's still desirable to be able to monitor those direct > >> allocations in debug mode, thus it makes sense to have a GIL protected > >> direct allocation API as well. You could try to hide the existence of > >> the latter behaviour and treat it as a private API, but why? For > >> custom allocators, it's useful to be able to *ensure* you can bypass > >> CPython's small object allocator, rather than having to rely on it > >> being bypassed for allocations above a certain size. > > > > There is even more to it. We like to keep track of memory allocations in > > libraries that are wrapped by Python's extension modules, e.g. expat, > > openssl etc. Almost every library has a hook to set a custom memory > > allocator, either globally (CRYPTO_set_mem_functions) or for each object > > (XML_ParserCreate_MM's XML_Memory_Handling_Suite). > > I just create the issue http://bugs.python.org/issue18227: "Use Python > memory allocators in external libraries like zlib or OpenSSL". > > Is it possible to detect if Python is used as a standalone application > (the classic "python" program) or if Python is embedded? If it is > possible, we can modify the "global" memory allocators of a library. The question is why you want to do so, not how/whether to do it. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #3329: Add new APIs to customize memory allocators
On Sun, 16 Jun 2013 02:18:32 +0200 Victor Stinner wrote: > 2013/6/15 Antoine Pitrou : > > On Sat, 15 Jun 2013 03:54:50 +0200 > > Victor Stinner wrote: > >> The addition of PyMem_RawMalloc() is motivated by the issue #18203 > >> (Replace calls to malloc() with PyMem_Malloc()). The goal is to be > >> able to setup a custom allocator for *all* allocation made by Python, > >> so malloc() should not be called directly. PyMem_RawMalloc() is > >> required in places where the GIL is not held (ex: in os.getcwd() on > >> Windows). > > > > We already had this discussion on IRC and this argument isn't very > > convincing to me. If os.getcwd() doesn't hold the GIL while allocating > > memory, then you should fix it to hold the GIL while allocating memory. > > The GIL is released for best performances, holding the GIL would have > an impact on performances. Well, do you have benchmark numbers? Do you have a workload where getcwd() is performance-critical to the point that a single GIL-protected allocation may slow down your program? > "Private" functions can be used by applications, it's just that Python > doesn't give any backward compatibility warranty. Am I right? Anyone "can" use anything obviously, but when it's private, it can be changed or removed in any release. If the only goal for these functions is to be used by applications, though, it's quite a bad idea to make them private. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #3329: Add new APIs to customize memory allocators
On 16 June 2013 19:50, Antoine Pitrou wrote: > On Sun, 16 Jun 2013 01:48:06 +0200 > Victor Stinner wrote: > >> 2013/6/15 Christian Heimes : >> > Am 15.06.2013 14:22, schrieb Nick Coghlan: >> >> However, it's still desirable to be able to monitor those direct >> >> allocations in debug mode, thus it makes sense to have a GIL protected >> >> direct allocation API as well. You could try to hide the existence of >> >> the latter behaviour and treat it as a private API, but why? For >> >> custom allocators, it's useful to be able to *ensure* you can bypass >> >> CPython's small object allocator, rather than having to rely on it >> >> being bypassed for allocations above a certain size. >> > >> > There is even more to it. We like to keep track of memory allocations in >> > libraries that are wrapped by Python's extension modules, e.g. expat, >> > openssl etc. Almost every library has a hook to set a custom memory >> > allocator, either globally (CRYPTO_set_mem_functions) or for each object >> > (XML_ParserCreate_MM's XML_Memory_Handling_Suite). >> >> I just create the issue http://bugs.python.org/issue18227: "Use Python >> memory allocators in external libraries like zlib or OpenSSL". >> >> Is it possible to detect if Python is used as a standalone application >> (the classic "python" program) or if Python is embedded? If it is >> possible, we can modify the "global" memory allocators of a library. > > The question is why you want to do so, not how/whether to do it. I don't think we should be doing that ourselves - it's up to system integrators/embedders to configure those libraries if they want to, we shouldn't be doing it on their behalf. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backports galore
On 16 June 2013 19:30, Łukasz Langa wrote: > Now we have (at least) the following libraries backported from 3.2+ to > older versions of Python by members of the core team: > > - configparser > - enum34 > - singledispatch > - subprocess32 > - unittest2 > > There are also unofficial backports like billiard (multiprocessing). Step one is compiling a list. I started a page for that here: http://wiki.python.org/moin/StandardLibraryBackports (It's reachable from the front page of the wiki via the Useful Modules page) > I would be happy if all those were more discoverable by the community > at large. Having a single namespace for backports would be great but > my spidey sense forebodes large flocks of bike sheds flying that way. > > Can we put links to those backports in the docs of older versions of > Python? Most users would be better off using the updated packages > while still deploying on an older release of Python. It's probably better to start with a list anyone can edit, rather than links that can only be updated by core developers. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
Ethan Furman writes: > Thank you for the offer, but I think I'll go with GPS's idea of > calling it enum34. That name will be confusing once Python 3.5 exists (even as a development version). I'd argue that it is confusing even now, since this is a backport for Python version *earlier* than Python 3.4. The name ‘stdlib.enum’ avoids these problems, do you think that is suitable? -- \ “If trees could scream, would we be so cavalier about cutting | `\ them down? We might, if they screamed all the time, for no good | _o__)reason.” —Jack Handey | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
On Jun 15, 2013, at 11:53 PM, Ethan Furman wrote: >Note that while flufl.enum was the inspiration, it is not the version that >went into 3.4. I haven't yet decided whether to continue with development of flufl.enum or not. I think there's a lot of value in promoting a standard enum library and having PEP 435 in both the 3.4 stdlib and in a good backport may outweigh the differences. I mostly agree with everything in PEP 435 . One big test will be porting Mailman 3 to enum34. I expect that to mostly Just Work and I don't think the differences will affect it (I've already adjusted for the lack of inheritance - mostly I have to see what effect it will have on the database layer). OTOH, if folks really depend on the differences in flufl.enum, I will probably at least continue to maintain it, but not add any new features. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backports galore
There is also faulthandler on PyPI. It is not really a backport since the project developement started on PyPI. Victor Le dimanche 16 juin 2013, Łukasz Langa a écrit : > Now we have (at least) the following libraries backported from 3.2+ to > older versions of Python by members of the core team: > > - configparser > - enum34 > - singledispatch > - subprocess32 > - unittest2 > > There are also unofficial backports like billiard (multiprocessing). > > I would be happy if all those were more discoverable by the community > at large. Having a single namespace for backports would be great but > my spidey sense forebodes large flocks of bike sheds flying that way. > > Can we put links to those backports in the docs of older versions of > Python? Most users would be better off using the updated packages > while still deploying on an older release of Python. > > -- > Best regards, > Łukasz Langa > > WWW: http://lukasz.langa.pl/ > Twitter: @llanga > IRC: ambv on #python-dev > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
On Sun, Jun 16, 2013 at 8:19 AM, Barry Warsaw wrote: > On Jun 15, 2013, at 11:53 PM, Ethan Furman wrote: > > >Note that while flufl.enum was the inspiration, it is not the version that > >went into 3.4. > > I haven't yet decided whether to continue with development of flufl.enum or > not. I think there's a lot of value in promoting a standard enum library > and > having PEP 435 in both the 3.4 stdlib and in a good backport may outweigh > the > differences. I mostly agree with everything in PEP 435 . > > One big test will be porting Mailman 3 to enum34. I expect that to mostly > Just Work and I don't think the differences will affect it (I've already > adjusted for the lack of inheritance - mostly I have to see what effect it > will have on the database layer). > > OTOH, if folks really depend on the differences in flufl.enum, I will > probably > at least continue to maintain it, but not add any new features. > If you write down the process of porting mailmain from flufl to stdlib.enum in some place, it can make the process much easier for others, and even encourage them to follow the same path. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
