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
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 m
On 6/15/2013 5:45 PM, Tres Seaver wrote:
Given that strings are implemented in C,
That is a current implementation detail. String functions were
originally written in python in string.py. Some used 'for c in s:'. The
functions only because methods after 2.2. I presume Pypy starts from
Pytho
On Jun 15, 2013, at 10:45 PM, Ben Finney wrote:
> Ethan Furman writes:
>
>> So I have the stdlb 3.4 Enum backported for both earlier 3.x and back
>> to 2.4 in the 2.x series.
>>
>> I would like to put this on PyPI, but the `enum` name is already
>> taken.
>
> I have for a long time approved
Ethan Furman writes:
> So I have the stdlb 3.4 Enum backported for both earlier 3.x and back
> to 2.4 in the 2.x series.
>
> I would like to put this on PyPI, but the `enum` name is already
> taken.
I have for a long time approved of ‘flufl.enum’ becoming the One Obvious
Way to do enumerations,
On 16 Jun 2013 10:54, "Victor Stinner" wrote:
>
> 2013/6/15 Antoine Pitrou :
> > Moreover, I think you are conflating two issues: the ability to add
> > memory allocation hooks (for tracing/debugging purposes), and the
> > adaptation to "non-traditional" memory models (whatever that means).
> > Th
On 06/15/2013 03:23 PM, Guido van Rossum wrote:
The semantics of raw strings are clear. I don't see that they should be
called out especially in any context. (Except for regexps.) Usually exec()
is not used with a literal anyway (what would be the point).
There are about a hundred instances
On Jun 15, 2013, at 5:43 PM, Ethan Furman wrote:
> On 06/15/2013 01:53 PM, Antoine Pitrou wrote:
>> On Sat, 15 Jun 2013 12:46:32 -0700
>> Ethan Furman wrote:
>>> So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to
>>> 2.4 in the 2.x series.
>>>
>>> I would like to put thi
2013/6/15 Antoine Pitrou :
> Moreover, I think you are conflating two issues: the ability to add
> memory allocation hooks (for tracing/debugging purposes), and the
> adaptation to "non-traditional" memory models (whatever that means).
> Those concerns don't necessarily come together.
In my implem
2013/6/15 Nick Coghlan :
> The only reason for the small object allocator to exist is because
> operating system allocators generally aren't optimised for frequent
> allocation and deallocation of small objects. You can gain a *lot* of
> speed from handling those inside the application. As the allo
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 Pytho
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 lat
I tend to just pick a name and stick with it. subprocess32 is subprocess
backported from 3.2 (with the 3.3 timeout feature also in it). unittest2
is unittest from 2.7.
It tends to work. and it also emphasizes that i'm unlikely to backport
future non-bugfix updates beyond the release mentioned a
On 06/15/2013 01:53 PM, Antoine Pitrou wrote:
On Sat, 15 Jun 2013 12:46:32 -0700
Ethan Furman wrote:
So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4 in
the 2.x series.
I would like to put this on PyPI, but the `enum` name is already taken.
Would it be inappropria
What if there's some obscure PyPi module that requires that `enum` package, or
some other project (not hosted on PyPI) that requires Ben Finney's original
`enum` package? Is there anyway to get usage data to make sure nobody's been
using it recently?
ML
On Jun 15, 2013, at 5:14 PM, Barry Warsa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2013 05:14 PM, Barry Warsaw wrote:
> On Jun 15, 2013, at 12:46 PM, Ethan Furman wrote:
>
>> So I have the stdlb 3.4 Enum backported for both earlier 3.x and
>> back to 2.4 in the 2.x series.
>>
>> I would like to put this on PyPI, but the `e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2013 04:11 PM, Terry Reedy wrote:
> On 6/15/2013 8:53 AM, Tres Seaver wrote:
>
>> In fifteen years of Python programming, I have literally *never*
>> wanted to iterate over 'str' (or now 'bytes').
>
> If so, it is because you have always be
On Jun 15, 2013, at 12:46 PM, Ethan Furman wrote:
>So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4
>in the 2.x series.
>
>I would like to put this on PyPI, but the `enum` name is already taken.
>
>Would it be inappropriate to call it `stdlib.enum`?
The last upload was
On Sat, 15 Jun 2013 12:46:32 -0700
Ethan Furman wrote:
> So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4
> in the 2.x series.
>
> I would like to put this on PyPI, but the `enum` name is already taken.
>
> Would it be inappropriate to call it `stdlib.enum`?
`backpo
So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4 in
the 2.x series.
I would like to put this on PyPI, but the `enum` name is already taken.
Would it be inappropriate to call it `stdlib.enum`?
--
~Ethan~
___
Python-Dev mail
The semantics of raw strings are clear. I don't see that they should be
called out especially in any context. (Except for regexps.) Usually exec()
is not used with a literal anyway (what would be the point).
--Guido van Rossum (sent from Android phone)
On Jun 15, 2013 1:03 PM, "Ron Adam" wrote:
On 6/15/2013 8:53 AM, Tres Seaver wrote:
In fifteen years of Python programming, I have literally *never* wanted
to iterate over 'str' (or now 'bytes').
If so, it is because you have always been able to use pre-written
methods and functions that internally do the iteration for you.
> I've a
On 06/14/2013 04:03 PM, PJ Eby wrote:
>Should this be the same?
>
>
>python3 -c 'print(bytes("""\r\n""", "utf8"))'
>b'\r\n'
>
>
eval('print(bytes("""\r\n""", "utf8"))')
>b'\n'
No, but:
eval(r'print(bytes("""\r\n""", "utf8"))')
should be. (And is.)
What I believe you and Walter are mi
Am 15.06.2013 14:57, schrieb Victor Stinner:
> Le 15 juin 2013 03:54, "Victor Stinner" > a écrit :
>
>> Ok, I reverted my commit.
>>
>> I will work on a PEP to explain all these new functions and their use
> cases.
>
> I created the PEP 445 to reserve the number. It is ready for a review
> but a
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 pri
Your questions/suggestions are off-topic for this list. This belongs
on python-ideas.
On 14 June 2013 20:12, Martin Schultz wrote:
>
> 2. Testing for empty lists or empty ndarrays:
> 4. Finding the number of elements in an object:
> 6. Detecting None values in a list:
Each of the problems above
On Sun, 16 Jun 2013 00:12:02 +1000
Nick Coghlan wrote:
> On 15 June 2013 22:41, Antoine Pitrou wrote:
> > On Sat, 15 Jun 2013 22:22:33 +1000
> > Nick Coghlan wrote:
> >> For
> >> custom allocators, it's useful to be able to *ensure* you can bypass
> >> CPython's small object allocator, rather th
On 15 June 2013 22:41, Antoine Pitrou wrote:
> On Sat, 15 Jun 2013 22:22:33 +1000
> Nick Coghlan wrote:
>> 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 ce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/15/2013 09:15 AM, Donald Stufft wrote:
> I never want to iterate, but I love slice syntax and indexing. Don't
> think you can have that w/o being able to loop over it can you? Maybe
> I'm just thinking slow since I just woke up.
You could if '
I never want to iterate, but I love slice syntax and indexing. Don't think you
can have that w/o being able to loop over it can you? Maybe I'm just thinking
slow since I just woke up.
On Jun 15, 2013, at 8:53 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/
Le 15 juin 2013 03:54, "Victor Stinner"
>
a écrit :
> Ok, I reverted my commit.
>
> I will work on a PEP to explain all these new functions and their use
cases.
I created the PEP 445 to reserve the number. It is ready for a review but
already contains some explanation of the new API.
http://www.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/2013 04:55 PM, R. David Murray wrote:
> This I sort of agree with. I've often enough wanted to know if
> something is a non-string iterable. But you'd have to decide if
> bytes/bytearray is a sequence of integers or a scaler...
In fifteen y
On Sat, 15 Jun 2013 22:22:33 +1000
Nick Coghlan wrote:
> On 15 June 2013 21:01, Antoine Pitrou wrote:
> > 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
On 15 June 2013 21:01, Antoine Pitrou wrote:
> 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* alloc
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 cal
On Sat, 15 Jun 2013 14:57:49 +1000
Nick Coghlan wrote:
> On 15 June 2013 03:34, Antoine Pitrou wrote:
> > On Wed, 5 Jun 2013 09:10:54 -0700
> > Benjamin Peterson wrote:
> >> I (and Guido) are accepting PEP 442 (Safe object finalization) on the
> >> condition that finalizers are only ever called
fwiw i'm also supportive of adding these apis. Lets PEP away to iron out
any details or document disagreements but overall I'd also like to see
something a lot like these go in.
-gps
On Fri, Jun 14, 2013 at 10:50 PM, Nick Coghlan wrote:
> On 15 June 2013 11:54, Victor Stinner wrote:
> > 2013
37 matches
Mail list logo
