My rewritten version of PEP 414 is now up
(http://www.python.org/dev/peps/pep-0414/). It describes in detail a
lot more of the historical background that was taken as read when
Guido accepted the PEP.
Can we let the interminable discussion die now?
Please?
Regards,
Nick.
P.S. If you find an act
04.03.12 00:12, "Martin v. Löwis" написав(ла):
2to3 should recognize the str(string_literal) (or nstr(), or native(),
etc) as a native string and does not add prefix "u" to it. And you
have to explicitly specify these tips.
That is already implemented. 2to3 *never* adds a u prefix anywhere,
i
On Sun, Mar 4, 2012 at 12:24 PM, Thomas Wouters wrote:
> (Let's not forget about tp_as_sequence.sq_concat, tp_as_number.nb_add,
> tp_as_sequence.sq_repeat and tp_as_number.nb_mul either.)
Indeed, let's not forget about those, which are a compatibility
problem in and of themselves: http://bugs.pyt
On Sat, Mar 3, 2012 at 6:51 PM, Guido van Rossum wrote:
> On Sat, Mar 3, 2012 at 6:02 PM, Maciej Fijalkowski wrote:
>> On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner
>> wrote:
>>> Hi,
>>>
>>> Le 03/03/2012 20:13, Armin Rigo a écrit :
>>>
>> I challenge anymore to break pysandbox! I would be
>> Thomas Wouters, 03.03.2012 21:59:
>> > Why even have separate tp_as_sequence and tp_as_mapping anymore? That
>> > particular distinction never existed for Python types, so why should it
>> > exist for C types at all? I forget if there was ever a real point to it,
>> > but all it seems to do now
On Sat, Mar 3, 2012 at 6:02 PM, Maciej Fijalkowski wrote:
> On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner
> wrote:
>> Hi,
>>
>> Le 03/03/2012 20:13, Armin Rigo a écrit :
>>
> I challenge anymore to break pysandbox! I would be happy if anyone
> breaks it because it would make it more str
On Sat, Mar 3, 2012 at 13:12, Stefan Behnel wrote:
> Thomas Wouters, 03.03.2012 21:59:
> > Why even have separate tp_as_sequence and tp_as_mapping anymore? That
> > particular distinction never existed for Python types, so why should it
> > exist for C types at all? I forget if there was ever a r
On Sat, Mar 3, 2012 at 13:02, Antoine Pitrou wrote:
> On Sat, 3 Mar 2012 12:59:13 -0800
> Thomas Wouters wrote:
> >
> > Why even have separate tp_as_sequence and tp_as_mapping anymore? That
> > particular distinction never existed for Python types, so why should it
> > exist for C types at all?
On Sat, Mar 3, 2012 at 4:11 PM, Victor Stinner wrote:
> Le 29/02/2012 19:21, Victor Stinner a écrit :
>>
>> Rationale
>> =
>>
>> (...) Use cases of frozendict: (...)
>
>
> I updated the PEP to list use cases described in the other related mailing
> list thread.
> ---
> Use cases:
>
> * fr
On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner wrote:
> Hi,
>
> Le 03/03/2012 20:13, Armin Rigo a écrit :
>
I challenge anymore to break pysandbox! I would be happy if anyone
breaks it because it would make it more stronger.
>>
>>
>> I tried to run the files from Lib/test/crashers and --
On 3 Mar 2012, at 21:57, Ned Deily wrote:
> In article <5a0e2490-a743-4729-a752-d94524ea9...@barrys-emacs.org>,
> Barry Scott wrote:
>> On my Mac OS X 10.7.3 System I have lots of python kits installed for
>> developing extensions.
>>
>> I'll just noticed that Python.org 2.7.2 uses the sames s
2012/3/3 Vinay Sajip
> Ejaj Hassan gmail.com> writes:
>
> > I was compiling Pcbuild.sln from cpython in vc++ 2008 and i got
> the
> error as "Solution folders are not supported in this version of
> application-Solution folder will be displayed as unavailable".
> > Could someone please
Le 29/02/2012 19:21, Victor Stinner a écrit :
Rationale
=
(...) Use cases of frozendict: (...)
I updated the PEP to list use cases described in the other related
mailing list thread.
---
Use cases:
* frozendict lookup can be done at compile time instead of runtime
because the mapp
> 2to3 should recognize the str(string_literal) (or nstr(), or native(),
> etc) as a native string and does not add prefix "u" to it. And you
> have to explicitly specify these tips.
That is already implemented. 2to3 *never* adds a u prefix anywhere,
including not for str(string_literal).
Regar
In article <5a0e2490-a743-4729-a752-d94524ea9...@barrys-emacs.org>,
Barry Scott wrote:
> On my Mac OS X 10.7.3 System I have lots of python kits installed for
> developing extensions.
>
> I'll just noticed that Python.org 2.7.2 uses the sames site-packages folder
> with Apple's
> 2.7.1.
>
> S
Hi,
Le 03/03/2012 20:13, Armin Rigo a écrit :
I challenge anymore to break pysandbox! I would be happy if anyone
breaks it because it would make it more stronger.
I tried to run the files from Lib/test/crashers and --- kind of
obviously --- I found at least two of them that still segfaults
exe
Thomas Wouters, 03.03.2012 21:59:
> Why even have separate tp_as_sequence and tp_as_mapping anymore? That
> particular distinction never existed for Python types, so why should it
> exist for C types at all? I forget if there was ever a real point to it,
> but all it seems to do now is create confu
On Sat, 3 Mar 2012 12:59:13 -0800
Thomas Wouters wrote:
>
> Why even have separate tp_as_sequence and tp_as_mapping anymore? That
> particular distinction never existed for Python types, so why should it
> exist for C types at all? I forget if there was ever a real point to it,
> but all it seems
On Sat, Mar 3, 2012 at 10:18, Eli Bendersky wrote:
> On Sat, Mar 3, 2012 at 19:58, Guido van Rossum wrote:
> > On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou
> wrote:
> >>> I'd expect slice subscripts to be part of the sequence interface, and
> >>> yet they are not. In fact, they are part of th
On Sat, Mar 3, 2012 at 03:08, Stefan Krah wrote:
> Stefan Behnel wrote:
> > > 1. assert() is the wrong tool for this job
> >
> > Absolutely.
>
> I disagree. This assert() is meant for extension authors and not end
> users. I
> can't see how a reasonable release procedure would fail to trigger th
Hi Victor,
On Thu, Mar 1, 2012 at 22:59, Victor Stinner wrote:
>> I challenge anymore to break pysandbox! I would be happy if anyone
>> breaks it because it would make it more stronger.
I tried to run the files from Lib/test/crashers and --- kind of
obviously --- I found at least two of them tha
On Sat, Mar 3, 2012 at 19:58, Guido van Rossum wrote:
> On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou wrote:
>>> I'd expect slice subscripts to be part of the sequence interface, and
>>> yet they are not. In fact, they are part of the mapping interface. For
>>> example, the list object has its s
On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou wrote:
>> I'd expect slice subscripts to be part of the sequence interface, and
>> yet they are not. In fact, they are part of the mapping interface. For
>> example, the list object has its slice get/set methods assigned to a
>> PyMappingMethods struc
Ejaj Hassan gmail.com> writes:
> I was compiling Pcbuild.sln from cpython in vc++ 2008 and i got the
error as "Solution folders are not supported in this version of
application-Solution folder will be displayed as unavailable".
> Could someone please tell me the source and reason for t
On my Mac OS X 10.7.3 System I have lots of python kits installed for
developing extensions.
I'll just noticed that Python.org 2.7.2 uses the sames site-packages folder
with Apple's
2.7.1.
Since extensions compiled against Apple's 2.7.1 segv when used by python.org's
2.7.2
this is at least unf
Le samedi 03 mars 2012 à 14:41 +0200, Eli Bendersky a écrit :
> >> I'd expect slice subscripts to be part of the sequence interface, and
> >> yet they are not. In fact, they are part of the mapping interface. For
> >> example, the list object has its slice get/set methods assigned to a
> >> PyMappi
Nick Coghlan wrote:
> 2. the current check is too strict (it should just check for obj !=
> NULL, not obj == &exporter)
Yes. For anyone who is interested, see issue #14181.
> 3. the current check is in the wrong place (it should be in
> PyObject_GetBuffer)
Agreed, since it's not memoryview sp
>> I'd expect slice subscripts to be part of the sequence interface, and
>> yet they are not. In fact, they are part of the mapping interface. For
>> example, the list object has its slice get/set methods assigned to a
>> PyMappingMethods struct. So does a bytes object, and pretty much every
>> oth
On Sat, Mar 3, 2012 at 11:39, Vinay Sajip wrote:
> Sorry, I didn't make myself clear. If you import unicode_literals, then in
> both
> 2.x and 3.x code, an unadorned literal string is text, and a b-adorned literal
> string is bytes. My assertion was based on that assumption - the text
> (Unicode
Hi,
> I'd expect slice subscripts to be part of the sequence interface, and
> yet they are not. In fact, they are part of the mapping interface. For
> example, the list object has its slice get/set methods assigned to a
> PyMappingMethods struct. So does a bytes object, and pretty much every
> ot
On Sat, Mar 3, 2012 at 11:24, Stefan Behnel wrote:
> Eli Bendersky, 03.03.2012 09:36:
>> I find a strange discrepancy in Python with regards to slice
>> subscripting of objects, at the C API level. I mean things like
>> obj[start:end:step].
>>
>> I'd expect slice subscripts to be part of the seque
Stefan Behnel wrote:
> > 1. assert() is the wrong tool for this job
>
> Absolutely.
I disagree. This assert() is meant for extension authors and not end users. I
can't see how a reasonable release procedure would fail to trigger the assert().
My procedure as a C extension author is to test agai
Lennart Regebro gmail.com> writes:
> I'm not sure that's true at all. In most cases where you support both
> Python 2 and Python 3, most strings will be "native", ie, without
> prefix in either Python 2 or Python 3. The native case is the most
> common case.
Sorry, I didn't make myself clear. If
On Sat, Mar 3, 2012 at 10:26, Vinay Sajip wrote:
> Lennart Regebro gmail.com> writes:
>
>> So the question is if you have any proposal that is *less* confusing
>> while still being practical. Because we do need to distinguish between
>> binary, Unicode and "native" strings. Isn't this the least c
Lennart Regebro gmail.com> writes:
> So the question is if you have any proposal that is *less* confusing
> while still being practical. Because we do need to distinguish between
> binary, Unicode and "native" strings. Isn't this the least confusing
> solution?
It's a matter of the degree of con
Eli Bendersky, 03.03.2012 09:36:
> I find a strange discrepancy in Python with regards to slice
> subscripting of objects, at the C API level. I mean things like
> obj[start:end:step].
>
> I'd expect slice subscripts to be part of the sequence interface, and
> yet they are not. In fact, they are p
Nick Coghlan, 03.03.2012 00:49:
> On Sat, Mar 3, 2012 at 3:14 AM, Stefan Behnel wrote:
>> Stefan Krah, 02.03.2012 17:42:
>>> The reason why this scheme was not chosen for a chain of memoryviews
>>> was that 'exporter' (in theory) could implement a slideshow of buffers,
>>> which means that in the f
> This doesn't align well with the documentation, in at least two places.
>
Another place is in http://docs.python.org/dev/reference/datamodel.html:
"
object.__getitem__(self, key)
Called to implement evaluation of self[key]. For sequence types,
the accepted keys should be integers and slic
Stefan Behnel wrote:
> Yes, that's a suitable example. It would take the ndarray out of the loop -
> after all, it has nothing to do with what the memoryview wants, and won't
> need to do any cleanup for the memoryview's buffer view either. Keeping it
> explicitly alive in the memoryview is just a
Hello,
I find a strange discrepancy in Python with regards to slice
subscripting of objects, at the C API level. I mean things like
obj[start:end:step].
I'd expect slice subscripts to be part of the sequence interface, and
yet they are not. In fact, they are part of the mapping interface. For
exa
40 matches
Mail list logo
