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 thin
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:
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
h
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 Pyth
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 b
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
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
>
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 allo
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
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
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~
_
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, t
12 matches
Mail list logo
