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
Stefan Behnel stefan...@behnel.de 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
This doesn't align well with the documentation, in at least two places.
snip
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
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 face of
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 part
Lennart Regebro regebro at 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
On Sat, Mar 3, 2012 at 10:26, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Lennart Regebro regebro at 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.
Lennart Regebro regebro at 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
Stefan Behnel stefan...@behnel.de 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
On Sat, Mar 3, 2012 at 11:24, Stefan Behnel stefan...@behnel.de 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
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
other
On Sat, Mar 3, 2012 at 11:39, Vinay Sajip vinay_sa...@yahoo.co.uk 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 -
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
other object
Nick Coghlan ncogh...@gmail.com 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
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
PyMappingMethods
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
Ejaj Hassan ejjyrex at 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
On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou solip...@pitrou.net 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
On Sat, Mar 3, 2012 at 19:58, Guido van Rossum gu...@python.org wrote:
On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou solip...@pitrou.net 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,
Hi Victor,
On Thu, Mar 1, 2012 at 22:59, Victor Stinner victor.stin...@gmail.com 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
On Sat, Mar 3, 2012 at 03:08, Stefan Krah ste...@bytereef.org wrote:
Stefan Behnel stefan...@behnel.de 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
On Sat, Mar 3, 2012 at 10:18, Eli Bendersky eli...@gmail.com wrote:
On Sat, Mar 3, 2012 at 19:58, Guido van Rossum gu...@python.org wrote:
On Sat, Mar 3, 2012 at 4:20 AM, Antoine Pitrou solip...@pitrou.net
wrote:
I'd expect slice subscripts to be part of the sequence interface, and
yet
On Sat, 3 Mar 2012 12:59:13 -0800
Thomas Wouters tho...@python.org 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
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
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
In article 5a0e2490-a743-4729-a752-d94524ea9...@barrys-emacs.org,
Barry Scott ba...@barrys-emacs.org 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
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).
Regards,
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
2012/3/3 Vinay Sajip vinay_sa...@yahoo.co.uk
Ejaj Hassan ejjyrex at 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.
On 3 Mar 2012, at 21:57, Ned Deily wrote:
In article 5a0e2490-a743-4729-a752-d94524ea9...@barrys-emacs.org,
Barry Scott ba...@barrys-emacs.org 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
On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner victor.stin...@gmail.com 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
On Sat, Mar 3, 2012 at 4:11 PM, Victor Stinner victor.stin...@gmail.com 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:
On Sat, Mar 3, 2012 at 13:02, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 3 Mar 2012 12:59:13 -0800
Thomas Wouters tho...@python.org 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
On Sat, Mar 3, 2012 at 13:12, Stefan Behnel stefan...@behnel.de 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
On Sat, Mar 3, 2012 at 6:02 PM, Maciej Fijalkowski fij...@gmail.com wrote:
On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner victor.stin...@gmail.com
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
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
On Sat, Mar 3, 2012 at 6:51 PM, Guido van Rossum gu...@python.org wrote:
On Sat, Mar 3, 2012 at 6:02 PM, Maciej Fijalkowski fij...@gmail.com wrote:
On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner victor.stin...@gmail.com
wrote:
Hi,
Le 03/03/2012 20:13, Armin Rigo a écrit :
I challenge
On Sun, Mar 4, 2012 at 12:24 PM, Thomas Wouters tho...@python.org 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:
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,
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
40 matches
Mail list logo
