Re: [Python-Dev] PEP 414
[quoting Armin from Reddit] "Because in all honesty, because string wrappers make a codebase horrible to work with. I will have to continue maintaining 2.x versions for at least another four or five years. The idea if having to use string wrappers for that long makes me puke." Reading this led me to think the following: * 2.5 is now available basically everywhere, and it was released almost 5 years ago (Sep 2006); * if it takes the same time for 3.3, it will be widespread after 4-5 years (i.e. 2016-2017) [0]; * if you want to target a Python 3 version that is widespread [1], you will want to support 3.1/3.2 too in the meanwhile; * therefore you will have to use the hook on 3.1/3.2; * in 2016-2017 you'll finally be able to drop 3.1/3.2 and use only 3.3 without hooks; * in 2016-2017 you'll also stop maintaining the 2.x version (according to that quote); * if you are not maintaining 2.x anymore, you won't need u'' -- right when you could finally stop using the hook; Now, if the hook doesn't get in the way (AFAIU you just have to "install" it and it will do its work automatically), wouldn't it be better to use it in 3.3 too (especially considering that you will probably have to use it already for 3.1/3.2)? If my reasoning is correct, by the time you will be able to use u without problems you will have to start phasing it out because you won't need to support 2.x anymore. Is this hook available somewhere? How difficult is the installation? Does it strip the u automatically or is there a further step that developers should do before testing on 3.1/3.2? Best Regards, Ezio Melotti [0]: ISTM that people think "once you decide to switch to 3.x, there's really no reason to pick an older release, just pick the latest (3.3)". While this might be true for single developers that install it by hand, I don't think it's the same for distros and I expect for 3.x the same time span between release and widespread availability that we have with 2.x (i.e. 4-5 years). However this is just an assumption, if you have more accurate information that can show that the time span will indeed be shorter for 3.x (e.g. 2-3 year), feel free to prove me wrong. [1]: I think most projects still support 2.5, some support even older versions, some support only newer ones, but 2.5 as minimum support version seems a good average to me. Targeting the same use base seems reasonable to me (albeit not strictly necessary). I know that this was just a comment on Reddit and was not in the PEP, but it smacks of you throwing all your toys out of the pram. It certainly wasn't a reasoned response to my point. And some of that toys-pram attitude bleeds through into the language of the PEP, leading others to make the criticisms that they have. A PEP is supposed to be balanced, reasonable and thought through. It's not supposed to gloss over things in a hand-wavy sort of way - there's still uncertainty in my mind, for example, whether the 3.2 hook will be a 2to3-style tool that runs over a chunk of the whole project's codebase between editing and running a test, or whether it's an import-time hook which only kicks in on files that have just been edited in a development session. Which of these it is might affect crucially the experience of someone wanting to support 3.2 and 3.3 and 2.6+ - but that clearly isn't you, and you don't seem to have much sympathy or patience with that constituency - we're all stick-in-the-muds who want to work with Ubuntu LTS, rather than people subject to constraints imposed by employers, clients, projects we depend on etc. In contrast, Nick made a more reasonable case when commenting ion my preference for unicode_literals (on this list, not on Reddit), by reminding me about how unicode_literals changes the semantics of string literals, and this increases the cognitive burden on developers. I'm not whinging about the PEP in this post - I've said elsewhere that I wasn't opposed to it. I'm just trying to respond to your apparent bewilderment at some of the reaction to the PEP. I have confidence that with your continued input and Nick's input, the wording of the PEP can be made such that it doesn't ruffle quite so many feathers. I'm looking forward to seeing the updates. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ezio.melotti%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] PEP 414
Yury Selivanov writes: > Otherwise, many of its points are moot, and we need to raise a > question of rejecting it somehow. Yury, that's not going to happen. Guido made it quite clear that he agrees with those who consider this PEP useful, obvious, and safe, and the PEP *is* approved. There has been no hint of second thoughts, and AFAICS no reason why there would be. Please be patient, as Nick has taken on the next revision of this PEP with Armin's approval, and has indicated multiple times that he may take some time to actually do it because of other personal commitments. Regards, ___ 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] PEP 414
Wiadomość napisana przez Ezio Melotti w dniu 2 mar 2012, o godz. 10:33: > Now, if the hook doesn't get in the way (AFAIU you just have to "install" it > and it will do its work automatically), wouldn't it be better to use it in > 3.3 too (especially considering that you will probably have to use it already > for 3.1/3.2)? +1 -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. ___ 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] Add a frozendict builtin type
Mark Janssen writes: > Since there's no way (even theoretical way) to completely secure anything > (remember the DVD protection wars?), there's no way there should be any > liability if reasonable diligence is performed to provide security where > expected (which is probably calculable to some %-age of assets > protected). That's not how the law works, sorry. Look up "consequential damages," "contributory negligence," and "attractive nuisance." I'm not saying that anybody will lose *in* court, but one can surely be taken *to* court. If that happens to you, you've already lost (even if the other side can't win). > Open sourcing code could be said to be a disclaimer on any liability as > your letting people know that you've got nothing your trying to > conceal. Again, you seem to be revealing your ignorance of the law (not to mention security -- a safe is supposed to be secure even if the burglar has the blueprints). A comprehensive and presumably effective disclaimer is part of the license, but it's not clear that even that works. AFAIK such disclaimers are not well-tested in court. Guido is absolutely right. There is a risk here (not in the frozendict type, of course), but in distributing an allegedly effective sandbox. I doubt Victor as an individual doing research has a problem; the PSF is another matter. BTW, Larry Rosen's book on Open Source Licensing is a good reference. Andrew St. Laurent also has a book out, I like Larry's better but YMMV. ___ 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] Assertion in _PyManagedBuffer_FromObject()
Hi,
I just stumbled over this assertion in _PyManagedBuffer_FromObject() in the
latest Py3.3 branch:
"""
static PyObject *
_PyManagedBuffer_FromObject(PyObject *base)
{
_PyManagedBufferObject *mbuf;
mbuf = mbuf_alloc();
if (mbuf == NULL)
return NULL;
if (PyObject_GetBuffer(base, &mbuf->master, PyBUF_FULL_RO) < 0) {
/* mbuf->master.obj must be NULL. */
Py_DECREF(mbuf);
return NULL;
}
/* Assume that master.obj is a new reference to base. */
assert(mbuf->master.obj == base);
return (PyObject *)mbuf;
}
"""
I'm not saying that this is likely to happen, but I could imagine code that
wants to use a different object for the cleanup than itself, possibly for
keeping a certain kind of state when it delivers more than one buffer, or
for remembering what kind of allocation was used, or ...
Given that the buffer will eventually get released by the object pointed to
by the view->obj field in the Py_buffer struct, is there a reason why it
should be asserted that this is the same as the object that originally
provided the buffer?
Stefan
___
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] Compiling Python on Linux with Intel's icc
Stefan Krah wrote: > Alex Leach wrote: > > I've managed to compile everything in the python distribution except for > > Modules/_ctypes/libffi/src/x86/ffi64.c. > > There is an issue for this: > > http://bugs.python.org/issue4130 Yes, I saw that bug report, but it looked dormant. It is. In 4 years it's only had one post (from you I see), and no proposed fix. The link you posted there is the same link I posted (somewhere) in my previous email... > > After compilation, there's a few tests that are consistently failing, mainly > > involved with floating point precision: test_cmath, test_math and test_float. > > I think you have to compile with "-fp-model strict". > Thanks, I'll give that a go and will report back! > > In general, please submit suspected bugs on http://bugs.python.org/ > (after searching the archives) and post things like speed comparisons on> python-list at python.org. > Thanks again. My only other concern is with distutils, as it doesn't support icc on a Xeon. However, numpy.distutils is almost compatible. I've had to make some mods to the flags in numpy.distutils.intelccompiler and numpy.distutils.fcompiler.intel, but it would be nice if this support was also included in the global distutils... Can the numpy version be used in place of the standard distutils? Again, there's probably a more proper place to ask... I'll suggest patches for these numpy modules to the numpy devs, but it would be nice if the core python distutils supported icc too. Thanks for your time! Kind regards, Alex ___ 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] Compiling Python on Linux with Intel's icc
Stefan Krah wrote: > Alex Leach wrote: > > I've managed to compile everything in the python distribution except for > > Modules/_ctypes/libffi/src/x86/ffi64.c. > > There is an issue for this: > > http://bugs.python.org/issue4130 Yes, I saw that bug report, but it looked dormant. It is. In 4 years it's only had one post (from you I see), and no proposed fix. The link you posted there is the same link I posted (somewhere) in my previous email... > > After compilation, there's a few tests that are consistently failing, mainly > > involved with floating point precision: test_cmath, test_math and test_float. > > I think you have to compile with "-fp-model strict". > Thanks, I'll give that a go and will report back! > > In general, please submit suspected bugs on http://bugs.python.org/ > (after searching the archives) and post things like speed comparisons on> python-list at python.org. > Thanks again. My only other concern is with distutils, as it doesn't support icc on a Xeon. However, numpy.distutils is almost compatible. I've had to make some mods to the flags in numpy.distutils.intelccompiler and numpy.distutils.fcompiler.intel, but it would be nice if this support was also included in the standard distutils... Can the numpy version be used in place of the standard distutils? Again, there's probably a more proper place to ask... I'll suggest patches for these numpy modules to the numpy devs, but it would be nice if the core python distutils supported icc too. Thanks for your time! Kind regards, Alex ___ 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] Compiling Python on Linux with Intel's icc
Hi, Le 02/03/2012 11:55, Alex Leach a écrit : > My only other concern is with distutils, as it doesn't support > icc on a Xeon. Could you expand on that? distutils is supposed to support all unix-like C compilers. Regards ___ 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] Compiling Python on Linux with Intel's icc
> Éric Araujo wrote: > > Could you expand on that? distutils is supposed to support all > unix-like C compilers. Packages that use the numpy distutils can be built with the following options:- $ python setup.py config --compiler=intelem --fcompiler=intelem build -- compiler=intelem install This allows distutils to set the appropriate compile flags. Modules built with the normal distutils always raise warnings about unsupported flags, e.g. -fwrapv. icc needs to calm down a bit on certain floating point arithmetic optimisations, needing some option like '-fp-model strict', as Stefan suggested. '-xHost' is a good flag to use too, allowing icc to detect the CPU type, and use appropriate optimisations. The only way I can build modules now is by using environment variables, e.g:- $ CC=icc CXX=icpc LD=xild AR=xiar python setup.py config build build_ext But this then uses gcc-specific flags when compiling. Cheers, Alex ___ 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] Add a frozendict builtin type
> I think you should provide stronger arguments in each case why the > data needs to be truly immutable or read-only, rather than just using > a convention or an "advisory" API (like __private can be circumvented > but clearly indicates intent to the reader). I only know one use case for "truly immutable or read-only" object (frozendict, "read-only" type, read-only proxy, etc.): security. I know three modules using a C extension to implement read only objects: zope.proxy, zope.security and mxProxy. pysandbox uses more ugly tricks to implement read-only proxies :-) Such modules are used to secure web applications for example. A frozendict type doesn't replace these modules but help to implement security modules. http://www.egenix.com/products/python/mxBase/mxProxy/ http://pypi.python.org/pypi/zope.proxy http://pypi.python.org/pypi/zope.security Victor ___ 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] Compiling Python on Linux with Intel's icc
Stefan Krah wrote: > Alex Leach wrote: > > I've managed to compile everything in the python distribution except for > > Modules/_ctypes/libffi/src/x86/ffi64.c. > > There is an issue for this: > > http://bugs.python.org/issue4130 Yes, I saw that bug report, but it looked dormant. It is. In 4 years it's only had one post (from you I see), and no proposed fix. The link you posted there is the same link I posted (somewhere) in my previous email... > > After compilation, there's a few tests that are consistently failing, mainly > > involved with floating point precision: test_cmath, test_math and > > test_float. > > I think you have to compile with "-fp-model strict". > Thanks, I'll give that a go and will report back! > > In general, please submit suspected bugs on http://bugs.python.org/ > (after searching the archives) and post things like speed comparisons on> > python-list at python.org. > Thanks again. My only other concern is with distutils, as it doesn't support icc on a Xeon. However, numpy.distutils is almost compatible. I've had to make some mods to the flags in numpy.distutils.intelccompiler and numpy.distutils.fcompiler.intel, but it would be nice if this support was also included in the standard distutils... Can the numpy version be used in place of the standard distutils? Again, there's probably a more proper place to ask... I'll suggest patches for these numpy modules to the numpy devs, but it would be nice if the core python distutils supported icc too. Thanks for your time! Kind regards, Alex ___ 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] Assertion in _PyManagedBuffer_FromObject()
Stefan Behnel wrote:
> if (PyObject_GetBuffer(base, &mbuf->master, PyBUF_FULL_RO) < 0) {
> /* mbuf->master.obj must be NULL. */
> Py_DECREF(mbuf);
> return NULL;
> }
>
> /* Assume that master.obj is a new reference to base. */
> assert(mbuf->master.obj == base);
> I'm not saying that this is likely to happen, but I could imagine code that
> wants to use a different object for the cleanup than itself, possibly for
> keeping a certain kind of state when it delivers more than one buffer, or
> for remembering what kind of allocation was used, or ...
I /think/ a different cleanup object would be possible, but memoryview now
has the m.obj attribute that let's you see easily which object the view
actually references. That attribute would then point to the cleanup handler.
Note that the complexity is such that I would have to go through the whole
code again to be *sure* that it's possible.
So I'd rather see that people just don't use such schemes (unless there
is a storm of protest).
The assumption is clearly documented in:
http://docs.python.org/dev/c-api/buffer.html#Py_buffer
http://docs.python.org/dev/c-api/typeobj.html#buffer-object-structures
Since the Py_buffer.obj filed was undocumented in 3.2, I think we're within
out rights to restrict the field to the exporter.
Stefan Krah
___
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] PEP 414
Hi Ezio, Am 02.03.2012 um 10:33 schrieb Ezio Melotti: >> [quoting Armin from Reddit] >> "Because in all honesty, because string wrappers make a codebase horrible to >> work with. I will have to continue maintaining 2.x versions for at least >> another >> four or five years. The idea if having to use string wrappers for that long >> makes me puke." > Reading this led me to think the following: > * 2.5 is now available basically everywhere, and it was released almost 5 > years ago (Sep 2006); > * if it takes the same time for 3.3, it will be widespread after 4-5 years > (i.e. 2016-2017) [0]; > * if you want to target a Python 3 version that is widespread [1], you will > want to support 3.1/3.2 too in the meanwhile; > * therefore you will have to use the hook on 3.1/3.2; > * in 2016-2017 you'll finally be able to drop 3.1/3.2 and use only 3.3 > without hooks; > * in 2016-2017 you'll also stop maintaining the 2.x version (according to > that quote); > * if you are not maintaining 2.x anymore, you won't need u'' -- right when > you could finally stop using the hook; I don't think you can compare 2.5 and 3.2 like that. Although 3.2 is/will be shipped with some distributions, it never has, and never will have, the adoption of 2.5 that was "mainstream" for a quite long time. 3.3 is the IMHO the first 3.x release that brings really cool stuff to the table and might be the tipping point for people to start embracing Python 3 – despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I hope for some half-official back port there. :) Re the language thingie (not directed towards Ezio): It's true that Armin tends to be opinionated – maybe even polemic. However I can't recall a case where he personally attacked people like it happened here. Regards, Hynek ___ 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] Compiling Python on Linux with Intel's icc
Alex Leach wrote: > > http://bugs.python.org/issue4130 > > Yes, I saw that bug report, but it looked dormant. If a bug report is dormant, you have to wake it up by subscribing to the issue and leaving a comment. The particular case is a low priority issue since icc defines __GNUC__ and should therefore support the types in question. Stefan Krah ___ 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] Assertion in _PyManagedBuffer_FromObject()
On Fri, Mar 2, 2012 at 8:19 PM, Stefan Behnel wrote: > I'm not saying that this is likely to happen, but I could imagine code that > wants to use a different object for the cleanup than itself, possibly for > keeping a certain kind of state when it delivers more than one buffer, or > for remembering what kind of allocation was used, or ... Supporting that kind of behaviour is what the "internal" field is for. However, given the lack of control, an assert() isn't the appropriate tool here - PyObject_GetBuffer itself should be *checking* the constraint and then reporting an error if the check fails. Otherwise a misbehaving extension module could trivially crash the Python interpreter by returning a bad Py_buffer. Regards, 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] Assertion in _PyManagedBuffer_FromObject()
Stefan Krah, 02.03.2012 12:53:
> Stefan Behnel wrote:
>> if (PyObject_GetBuffer(base, &mbuf->master, PyBUF_FULL_RO) < 0) {
>> /* mbuf->master.obj must be NULL. */
>> Py_DECREF(mbuf);
>> return NULL;
>> }
>>
>> /* Assume that master.obj is a new reference to base. */
>> assert(mbuf->master.obj == base);
>
>
>> I'm not saying that this is likely to happen, but I could imagine code that
>> wants to use a different object for the cleanup than itself, possibly for
>> keeping a certain kind of state when it delivers more than one buffer, or
>> for remembering what kind of allocation was used, or ...
>
> I /think/ a different cleanup object would be possible, but memoryview now
> has the m.obj attribute that let's you see easily which object the view
> actually references. That attribute would then point to the cleanup handler.
>
> Note that the complexity is such that I would have to go through the whole
> code again to be *sure* that it's possible.
>
> So I'd rather see that people just don't use such schemes (unless there
> is a storm of protest).
>
> The assumption is clearly documented in:
>
> http://docs.python.org/dev/c-api/buffer.html#Py_buffer
> http://docs.python.org/dev/c-api/typeobj.html#buffer-object-structures
>
> Since the Py_buffer.obj filed was undocumented in 3.2, I think we're within
> out rights to restrict the field to the exporter.
Careful. There are tons of code out there that use the buffer interface,
and the "obj" field has been the way to handle the buffer release ever
since the interface actually worked (somewhere around the release of Py3.0,
IIRC).
Personally, I never read the documentation above (which was written way
after the design and implementation of the buffer interface). I initially
looked at the (outdated) PEP, and then switched to reading the code once it
started to divert substantially from the PEP. I'm sure there are many users
out there who have never seen the second link above, and still some who
aren't aware that the "exporting object" in the first link is required to
be identical with the one that "__getbuffer__()" was called on. Just think
of an object that acts as a façade to different buffers.
I'm well aware of the complexity of the implementation. However, even if
the assert was (appropriately, as Nick noted) replaced by an exception,
it's still not all that unlikely that it breaks user code (assuming that it
currently works). The decision to enforce this restriction should not be
taken lightly.
Stefan
___
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] Assertion in _PyManagedBuffer_FromObject()
Nick Coghlan wrote: > However, given the lack of control, an assert() isn't the appropriate > tool here - PyObject_GetBuffer itself should be *checking* the > constraint and then reporting an error if the check fails. Otherwise a > misbehaving extension module could trivially crash the Python > interpreter by returning a bad Py_buffer. I'm not so sure. Extension modules that use the C-API in wrong or undocumented ways can always crash the interpreter. This assert() should be triggered in the first unit test of the module. Now, if the module does not have unit tests or they don't test against a new Python version is that really our problem? Modules do need to be recompiled anyway due to the removal of Py_buffer.smalltable, otherwise they will almost certainly crash. Perhaps an addition to whatsnew/3.3 would be sufficient. Stefan Krah ___ 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] Assertion in _PyManagedBuffer_FromObject()
On Fri, Mar 2, 2012 at 10:55 PM, Stefan Krah wrote: > Nick Coghlan wrote: >> However, given the lack of control, an assert() isn't the appropriate >> tool here - PyObject_GetBuffer itself should be *checking* the >> constraint and then reporting an error if the check fails. Otherwise a >> misbehaving extension module could trivially crash the Python >> interpreter by returning a bad Py_buffer. > > I'm not so sure. Extension modules that use the C-API in wrong or > undocumented ways can always crash the interpreter. This assert() > should be triggered in the first unit test of the module. Now, if > the module does not have unit tests or they don't test against a > new Python version is that really our problem? Crashing out with a C assert when we can easily give them a nice Python traceback instead is unnecessarily unfriendly. As Stefan Behnel pointed out, by tightening up the API semantics, we're already running the risk of breaking applications that relied on looking at what the old code *did*, since it clearly deviated from both spec (the PEP) and the documentation (which didn't explain how ReleaseBuffer works at all). > Modules do need to be recompiled anyway due to the removal of > Py_buffer.smalltable, otherwise they will almost certainly crash. > Perhaps an addition to whatsnew/3.3 would be sufficient. That, updating the 2.7 and 3.2 docs with a reference to the fleshed out 3.3 semantics and converting the assert() to a Python exception should cover it. 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] Assertion in _PyManagedBuffer_FromObject()
Stefan Behnel wrote: > > http://docs.python.org/dev/c-api/buffer.html#Py_buffer > > http://docs.python.org/dev/c-api/typeobj.html#buffer-object-structures > > > > Since the Py_buffer.obj filed was undocumented in 3.2, I think we're within > > out rights to restrict the field to the exporter. > > Careful. There are tons of code out there that use the buffer interface, > and the "obj" field has been the way to handle the buffer release ever > since the interface actually worked (somewhere around the release of Py3.0, > IIRC). > > Personally, I never read the documentation above (which was written way > after the design and implementation of the buffer interface). The documentation has been largely re-written for 3.3. > looked at the (outdated) PEP, and then switched to reading the code once it > started to divert substantially from the PEP. I'm sure there are many users > out there who have never seen the second link above, and still some who > aren't aware that the "exporting object" in the first link is required to > be identical with the one that "__getbuffer__()" was called on. Just think > of an object that acts as a fa??ade to different buffers. That's exactly what the ndarray test object from Modules/_testbuffer.c can do. You can push new buffers onto a linked list and present different ones to each consumer. [Note that IMO that's a questionable design, but it's a test object.] The recommended way of keeping track of resources is to use Py_buffer.internal. I think that part is also appropriately mentioned in the original PEP, though I can perfectly understand if someone misses it due to the huge amount of information that needs to be absorbed. > it's still not all that unlikely that it breaks user code (assuming that it > currently works). The decision to enforce this restriction should not be > taken lightly. As I said, user code using the (also undocumented) Py_buffer.smalltable will also be broken. Stefan Krah ___ 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] PEP 414
Hi Ezio, Am 02.03.2012 um 10:33 schrieb Ezio Melotti: Reading this led me to think the following: * 2.5 is now available basically everywhere, and it was released almost 5 years ago (Sep 2006); * if it takes the same time for 3.3, it will be widespread after 4-5 years (i.e. 2016-2017) [0]; * if you want to target a Python 3 version that is widespread [1], you will want to support 3.1/3.2 too in the meanwhile; * therefore you will have to use the hook on 3.1/3.2; * in 2016-2017 you'll finally be able to drop 3.1/3.2 and use only 3.3 without hooks; * in 2016-2017 you'll also stop maintaining the 2.x version (according to that quote); * if you are not maintaining 2.x anymore, you won't need u'' -- right when you could finally stop using the hook; I don't think you can compare 2.5 and 3.2 like that. Although 3.2 is/will be shipped with some distributions, it never has, and never will have, the adoption of 2.5 that was "mainstream" for a quite long time. But I don't think the adoption of 3.2 will affect the decisions that distros will take about 3.3. Even in the unlikely case that e.g. Debian/RHEL make Python 3.3 available as soon as it's released, not everyone will immediately upload to the latest Debian or RHEL version. The point is that regardless the current Python 3 situation, it will take a few years before 3.3 will be widely available on most of the machine. For example I work on a server where I have 3.1. When/if it will be updated it will probably get 3.2, not 3.3 -- and this might happen in a couple of years. If I want 3.3 I will probably have to wait another couple of years. Other people might have to wait less time, others more. 3.3 is the IMHO the first 3.x release that brings really cool stuff to the table and might be the tipping point for people to start embracing Python 3 – despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I hope for some half-official back port there. :) I heard this about 3.1 and 3.2 too, and indeed they are both perfectly valid releases. The fact that 3.3 is even cooler doesn't mean that 3.1/3.2 are not cool. (I'm perfectly fine with the aforementioned server and 3.1, and currently I don't miss anything that is new in 3.2/3.3.) Best Regards, Ezio Melotti ___ 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] PEP 414
Just my 2 cents on the PEP rewrite: u'' support is not just if you want to write code that doesn't use 2to3. Even when you use 2to3 it is useful to be able to flag strings s binary, unicode or "native". //Lennart ___ 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] Assertion in _PyManagedBuffer_FromObject()
Stefan Krah wrote: > > Careful. There are tons of code out there that use the buffer interface, > > and the "obj" field has been the way to handle the buffer release ever > > since the interface actually worked (somewhere around the release of Py3.0, > > IIRC). > > > > Personally, I never read the documentation above (which was written way > > after the design and implementation of the buffer interface). > > The documentation has been largely re-written for 3.3. But even for 3.0 it's not obvious to me why 'obj' should refer to anything but the exporter: http://docs.python.org/release/3.0/c-api/typeobj.html "obj is the object to export ..." Stefan Krah ___ 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] PEP 414
02.03.12 15:49, Lennart Regebro написав(ла): Just my 2 cents on the PEP rewrite: u'' support is not just if you want to write code that doesn't use 2to3. Even when you use 2to3 it is useful to be able to flag strings s binary, unicode or "native". What "native" means in context Python 3 only? "Native" strings only have meaning if we consider Python 2 and Python 3 together. "Native" string is a text string, which was binary in Python 2. There is a flag for such strings -- str(). ___ 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] Assertion in _PyManagedBuffer_FromObject()
Nick Coghlan, 02.03.2012 14:22: > On Fri, Mar 2, 2012 at 10:55 PM, Stefan Krah wrote: >> Nick Coghlan wrote: >>> However, given the lack of control, an assert() isn't the appropriate >>> tool here - PyObject_GetBuffer itself should be *checking* the >>> constraint and then reporting an error if the check fails. Otherwise a >>> misbehaving extension module could trivially crash the Python >>> interpreter by returning a bad Py_buffer. >> >> I'm not so sure. Extension modules that use the C-API in wrong or >> undocumented ways can always crash the interpreter. This assert() >> should be triggered in the first unit test of the module. Now, if >> the module does not have unit tests or they don't test against a >> new Python version is that really our problem? > > Crashing out with a C assert when we can easily give them a nice > Python traceback instead is unnecessarily unfriendly. As Stefan Behnel > pointed out, by tightening up the API semantics, we're already running > the risk of breaking applications that relied on looking at what the > old code *did*, since it clearly deviated from both spec (the PEP) and > the documentation (which didn't explain how ReleaseBuffer works at > all). > >> Modules do need to be recompiled anyway due to the removal of >> Py_buffer.smalltable, otherwise they will almost certainly crash. > >> Perhaps an addition to whatsnew/3.3 would be sufficient. > > That, updating the 2.7 and 3.2 docs with a reference to the fleshed > out 3.3 semantics and converting the assert() to a Python exception > should cover it. One problem here: if the code raises an exception, it should properly clean up after itself. Meaning that it must call PyBuffer_Release() on the already acquired buffer - thus proving that the code actually works, except that it decides to raise an exception. I keep failing to see the interest in making this an error in the first place. Why would the object that bf_getbuffer() is being called on have to be identical with the one that exports the buffer? Stefan ___ 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] Assertion in _PyManagedBuffer_FromObject()
On Sat, Mar 3, 2012 at 12:39 AM, Stefan Behnel wrote: >> I keep failing to see the interest in making this an error in the first > place. Why would the object that bf_getbuffer() is being called on have to > be identical with the one that exports the buffer? OK, I misunderstood your suggestion. So you actually want to just remove the assert altogether, thus allowing delegation of the buffer API by defining *only* the getbuffer slot and setting obj to point to a different object? I don't see any obvious problems with that, either. It would need new test cases and some documentation updates, 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] Compiling Python on Linux with Intel's icc
On Thu, 01 Mar 2012 18:39:19 +
Alex Leach wrote:
>
> Obviously, I was hoping to get a faster python, but the size of the final
> binary is almost twice the size of the default Ubuntu version (5.2MB cf.
> 2.7MB), which I thought might cause a startup overhead that leads to slower
> execution times when running such a basic script.
Did you compare the actual code sizes? The `size` command can help you
with that.
> *** TEST SCRIPT ***
> $ cat ~/bin/timetest.py
>
> RANGE = 1
>
> print "running {0}^2 = {1} for loop iterations".format( RANGE,RANGE**2 )
>
> for i in xrange(RANGE):
> for j in xrange(RANGE):
> i * j
That's an extremely silly benchmark, unlikely to be representative of
any actual Python workload. I suggest you try a less-trivial benchmark
suite, such as: http://hg.python.org/benchmarks/
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] Assertion in _PyManagedBuffer_FromObject()
Stefan Behnel wrote: > I keep failing to see the interest in making this an error in the first > place. First, it is meant to guard against random pointers in the view.obj field, precisely because view.obj was undocumented and exporters might not fill in the field. Then, as I said, the exporter is exposed on the Python level now: >>> exporter = b'123' >>> x = memoryview(exporter) >>> x.obj == exporter True >>> x.obj b'123' > Why would the object that bf_getbuffer() is being called on have to > be identical with the one that exports the buffer? It doesn't have to be. This is now possible: >>> from _testbuffer import * >>> exporter = b'123' >>> nd = ndarray(exporter) >>> m = memoryview(nd) >>> nd.obj b'123' >>> m.obj Stefan Krah ___ 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] Compiling Python on Linux with Intel's icc
On 02/03/2012 14:52, "Antoine Pitrou" wrote: > >Did you compare the actual code sizes? The `size` command can help you >with that. I'd never used `size` before... Thanks for the tip; looks like the Intel build is actually smaller..? :/ # ICC version (`ls -lh` ==> 4.7MB) $ size ./python textdata bss dec hex filename 1659760 276904 63760 2000424 1e8628 ./python # System version (`ls -lhH` ==>2.7MB) $ size /usr/bin/python textdata bss dec hex filename 2303805 427728 74808 2806341 2ad245 /usr/bin/python I definitely don't get what's going on here! Does this information relate to linked objects being in shared or static libs? Is this indicative anything, either good or bad? > >That's an extremely silly benchmark, unlikely to be representative of >any actual Python workload. I suggest you try a less-trivial benchmark >suite, such as: http://hg.python.org/benchmarks/ lol, yes it is a silly benchmark! Still, when I first started compiling python, without any optimisation options, this silly little script took up to 6-8x more time to process than the default GCC version. (~17s cf. <3s). And the script hardly took that long to write! Thanks for the benchmark recommendation; I'll use that on the next build - hopefully after passing the math tests! Cheers, Alex > ___ 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] Assertion in _PyManagedBuffer_FromObject()
Stefan Krah wrote: > > Why would the object that bf_getbuffer() is being called on have to > > be identical with the one that exports the buffer? > > It doesn't have to be. This is now possible: > > >>> from _testbuffer import * > >>> exporter = b'123' > >>> nd = ndarray(exporter) > >>> m = memoryview(nd) > >>> nd.obj > b'123' > >>> m.obj > Stefan (Behnel), do you have an existing example object that does what you described? If I understand correctly, in the above example the ndarray would redirect the buffer request to 'exporter' and set m.obj to 'exporter'. It would be nice to know if people are actually using this. 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 redirecting requests m might not be equal to nd. Stefan Krah ___ 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] Compiling Python on Linux with Intel's icc
On Fri, 02 Mar 2012 16:29:39 + Alex Leach wrote: > > > >Did you compare the actual code sizes? The `size` command can help you > >with that. > > I'd never used `size` before... Thanks for the tip; looks like the Intel > build is actually smaller..? :/ > > # ICC version (`ls -lh` ==> 4.7MB) > $ size ./python >textdata bss dec hex filename > 1659760 276904 63760 2000424 1e8628 ./python > > # System version (`ls -lhH` ==>2.7MB) > $ size /usr/bin/python >textdata bss dec hex filename > 2303805 427728 74808 2806341 2ad245 /usr/bin/python > > I definitely don't get what's going on here! Does this information relate > to linked objects being in shared or static libs? Is this indicative > anything, either good or bad? Mmmh, your system version might have been compiled with different options, so you may want to compare with a hand-compiled gcc build. The "text" column gives you the code size. Arguably, a smaller code size will make the instruction cache more efficient. cheers 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] Compiling Python on Linux with Intel's icc
Alex Leach wrote: > Can you translate Intel's suggestion into a patch for ffi64? Well probably, but this really belongs on the bug tracker. Also, as I said, there are many issues with higher priority. Stefan Krah ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-02-24 - 2012-03-02) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3299 (+22) closed 22660 (+49) total 25959 (+71) Open issues with patches: 1409 Issues opened (57) == #12151: test_logging fails sometimes http://bugs.python.org/issue12151 reopened by nadeem.vawda #14080: Sporadic test_imp failure http://bugs.python.org/issue14080 reopened by skrah #14110: FreeBSD: test_os fails if user is in the wheel group http://bugs.python.org/issue14110 opened by skrah #14111: IDLE Debugger should handle interrupts http://bugs.python.org/issue14111 opened by ltaylor934 #14112: tutorial intro talks of "shallow copy" concept without explana http://bugs.python.org/issue14112 opened by tshepang #14114: 2.7.3rc1 chm gives JS error http://bugs.python.org/issue14114 opened by loewis #14115: 2.7.3rc hangs on test_asynchat on 32-bit Windows http://bugs.python.org/issue14115 opened by loewis #14116: Lock.__enter__() method returns True instead of self http://bugs.python.org/issue14116 opened by sbt #14117: Turtledemo: exception and minor glitches. http://bugs.python.org/issue14117 opened by terry.reedy #14119: Ability to adjust queue size in Executors http://bugs.python.org/issue14119 opened by Nam.Nguyen #14120: ARM Ubuntu 3.x buildbot failing test_dbm http://bugs.python.org/issue14120 opened by nadeem.vawda #14121: add a convenience C-API function for unpacking iterables http://bugs.python.org/issue14121 opened by scoder #14122: operator: div() instead of truediv() in documention since 3.1. http://bugs.python.org/issue14122 opened by felixantoinefortin #14123: Indicate that there are no current plans to deprecate printf-s http://bugs.python.org/issue14123 opened by telephonebook #14124: _pickle.c comment/documentation improvement http://bugs.python.org/issue14124 opened by valhallasw #14126: Speed up list comprehensions by preallocating the list where p http://bugs.python.org/issue14126 opened by alex #14127: os.stat and os.utime: allow preserving exact metadata http://bugs.python.org/issue14127 opened by larry #14128: _elementtree should expose types and factory functions consist http://bugs.python.org/issue14128 opened by eli.bendersky #14130: memoryview: add multi-dimensional indexing and slicing http://bugs.python.org/issue14130 opened by skrah #14131: test_threading failure on WIndows 7 3.x buildbot http://bugs.python.org/issue14131 opened by ncoghlan #14132: Redirect is not working correctly in urllib2 http://bugs.python.org/issue14132 opened by janik #14133: improved PEP 409 implementation http://bugs.python.org/issue14133 opened by benjamin.peterson #14134: xmlrpc.client.ServerProxy needs timeout parameter http://bugs.python.org/issue14134 opened by polymorphm #14135: check for locale changes in test.regrtest http://bugs.python.org/issue14135 opened by brett.cannon #14136: Simplify PEP 409 command line test and move it to test_cmd_lin http://bugs.python.org/issue14136 opened by ncoghlan #14139: test_ftplib: segfault http://bugs.python.org/issue14139 opened by skrah #14140: packaging tests: add helpers to create and inspect a tree of f http://bugs.python.org/issue14140 opened by eric.araujo #14141: 2.7.2 64-bit Windows library has __impt_Py* for several symbol http://bugs.python.org/issue14141 opened by Steve.McConnel #14142: getlocale(LC_ALL) behavior http://bugs.python.org/issue14142 opened by skrah #14143: test_ntpath failure on Windows http://bugs.python.org/issue14143 opened by nadeem.vawda #14144: urllib2 HTTPRedirectHandler not forwarding POST data in redire http://bugs.python.org/issue14144 opened by crustymonkey #14146: IDLE: source line in editor doesn't highlight when debugging http://bugs.python.org/issue14146 opened by Rich.Rauenzahn #14148: Option to kill "stuck" workers in a multiprocessing pool http://bugs.python.org/issue14148 opened by pmoore #14149: argparse: Document how to use argument names that are not Pyth http://bugs.python.org/issue14149 opened by Joseph.Birr-Pixton #14150: AIX, crash loading shared module into another process than pyt http://bugs.python.org/issue14150 opened by Jan.Stürtz #14151: multiprocessing.connection.Listener fails with invalid address http://bugs.python.org/issue14151 opened by Popa.Claudiu #14154: reimplement the bigmem test memory watchdog as a subprocess http://bugs.python.org/issue14154 opened by neologix #14156: argparse.FileType for '-' doesn't work for a mode of 'rb' http://bugs.python.org/issue14156 opened by anacrolix #14157: time.strptime without a year fails on Feb 29 http://bugs.python.org/issue14157 opened by Martin.Morrison #14158: test_mailbox fails if file or dir named by support.TESTFN exis http://bugs.python.org/issue14158 opened by vinay.sajip #14160: TarFile.extractfile fails to extrac
Re: [Python-Dev] Assertion in _PyManagedBuffer_FromObject()
Stefan Krah, 02.03.2012 17:42: > Stefan Krah wrote: >>> Why would the object that bf_getbuffer() is being called on have to >>> be identical with the one that exports the buffer? >> >> It doesn't have to be. This is now possible: >> >> >>> from _testbuffer import * >> >>> exporter = b'123' >> >>> nd = ndarray(exporter) >> >>> m = memoryview(nd) >> >>> nd.obj >> b'123' >> >>> m.obj >> > > Stefan (Behnel), do you have an existing example object that does > what you described? If I understand correctly, in the above example > the ndarray would redirect the buffer request to 'exporter' and > set m.obj to 'exporter'. 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 waste of resources. It's also related to this issue, which asks for an equivalent at the Python level: http://bugs.python.org/issue13797 > It would be nice to know if people are actually using this. I'm not using this anywhere. My guess is that it would be more of a feature than something to provide legacy code support for, but I can't speak for anyone else. In general, the NumPy mailing list is a good place to ask about these things. > 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 redirecting requests m might not be > equal to nd. Right. Then it's only safe when the intermediate provider knows what the underlying buffer providers do. Not unlikely in an application setting, though, and it could just be an option at creation time to activate the delegation for the ndarray above. Stefan ___ 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] Assertion in _PyManagedBuffer_FromObject()
On Fri, Mar 2, 2012 at 05:22, Nick Coghlan wrote: > On Fri, Mar 2, 2012 at 10:55 PM, Stefan Krah wrote: > > Nick Coghlan wrote: > >> However, given the lack of control, an assert() isn't the appropriate > >> tool here - PyObject_GetBuffer itself should be *checking* the > >> constraint and then reporting an error if the check fails. Otherwise a > >> misbehaving extension module could trivially crash the Python > >> interpreter by returning a bad Py_buffer. > > > > I'm not so sure. Extension modules that use the C-API in wrong or > > undocumented ways can always crash the interpreter. This assert() > > should be triggered in the first unit test of the module. Now, if > > the module does not have unit tests or they don't test against a > > new Python version is that really our problem? > > Crashing out with a C assert when we can easily give them a nice > Python traceback instead is unnecessarily unfriendly. But you should keep in mind that for non-debug builds, asserts are generally off. So the behaviour most people see isn't actually a crash, but silent acceptance. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] PEP 414
On Mar 02, 2012, at 02:48 PM, Nick Coghlan wrote: >Consider: an application that uses 8-bit strings everywhere and blows up on >non-ASCII data in Python 2 has at least a fighting chance to run unmodified >*and* handle Unicode properly on Python 3. Because unicode literals are gone, >a Unicode-aware Python 2 application currently has *no* chance to run >unmodified on Python 3. On its face, this statement is incorrect. It *might* be accurate if qualified by saying "a Unicode-aware Python 2 *web* application". I say "might" because I'm not an expert on web frameworks so I defer to those who are. It certainly can't be applied to the entire universe of Unicode-aware Python 2 applications. >Accordingly, I'd like to ask folks not to stress too much about the >precise wording until I get a chance to update it over the weekend :) /me takes a deep breath. :) -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] PEP 414
On Mar 02, 2012, at 12:58 PM, Hynek Schlawack wrote: >3.3 is the IMHO the first 3.x release that brings really cool stuff to the >table and might be the tipping point for people to start embracing Python 3 – >despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I >hope for some half-official back port there. :) Although I disagree with the premise (I think Python 3.2 is a fine platform to build many applications on) it's probably likely what we'll have backports of stable Python 3 releases to 12.04, at the very least in semi-official PPAs. Just like today we're trying to provide a smoother path for LTS->LTS upgrades where 10.04 had only Python 2.6 but 12.04 has only Python 2.7. We have a semi-official Lucid PPA providing Python 2.7, though afaict very few people have actually used or tested it. Cheers, -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] PEP 414
On Fri, 2012-03-02 at 14:41 -0500, Barry Warsaw wrote: > On Mar 02, 2012, at 02:48 PM, Nick Coghlan wrote: > > >Consider: an application that uses 8-bit strings everywhere and blows up on > >non-ASCII data in Python 2 has at least a fighting chance to run unmodified > >*and* handle Unicode properly on Python 3. Because unicode literals are gone, > >a Unicode-aware Python 2 application currently has *no* chance to run > >unmodified on Python 3. > > On its face, this statement is incorrect. > > It *might* be accurate if qualified by saying "a Unicode-aware Python 2 *web* > application". I say "might" because I'm not an expert on web frameworks so I > defer to those who are. It certainly can't be applied to the entire universe > of Unicode-aware Python 2 applications. FWIW, I think this issue's webness may be overestimated. There happens to be lots and lots of existing UI code which contains complex interactions between unicode literals and nonliterals in web apps, but there's also likely lots of nonweb code that has the same issue. If e.g. wxPython had already been ported, I think you'd be hearing the same sorts of things from folks that had investments in existing Python-2-compatible code when trying to port stuff to Py3 (at least if they wanted to run on both Python 2 and Python 3 within the same codebase). - C ___ 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] PEP 414
Am 02.03.2012 um 20:44 schrieb Barry Warsaw: >> 3.3 is the IMHO the first 3.x release that brings really cool stuff to the >> table and might be the tipping point for people to start embracing Python 3 – >> despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I >> hope for some half-official back port there. :) > Although I disagree with the premise (I think Python 3.2 is a fine platform to > build many applications on) Just to be clear: I didn't say 3.2 is “bad” or “not fine”. It's just the fact that people need more than “fine” to feel urged to switch to Python 3. I sincerely hope 3.3 fulfills that and if PEP 414 even makes porting easier we might have a perfect storm. :) > it's probably likely what we'll have backports of > stable Python 3 releases to 12.04, at the very least in semi-official PPAs. That's what I've been hoping for. Maybe it will work the other way around too: People like 3.3, target it first and port back later to reach more users. It's all about encouraging people to try the nectar of Python 3 – once they're caught it's sticky sweetness[1]… ;) Cheers, Hynek [1] disclaimer: sticky sweetness only applies if you're not a maintainer of wsgi-related middleware/framework ___ 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] PEP 414
On Mar 02, 2012, at 03:13 PM, Chris McDonough wrote: >FWIW, I think this issue's webness may be overestimated. There happens to be >lots and lots of existing UI code which contains complex interactions between >unicode literals and nonliterals in web apps, but there's also likely lots of >nonweb code that has the same issue. If e.g. wxPython had already been >ported, I think you'd be hearing the same sorts of things from folks that had >investments in existing Python-2-compatible code when trying to port stuff to >Py3 (at least if they wanted to run on both Python 2 and Python 3 within the >same codebase). Okay, I just want to be very careful about the message we're sending here, because I think many libraries and applications will work fine with the facilities available in today's stable releases, i.e. unicode_literals and b-prefixes. For these, there's no need to define "native strings", nor do they require language constructs above what's already available. -Barry signature.asc Description: PGP signature ___ 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] PEP 414
On Mar 02, 2012, at 09:23 PM, Hynek Schlawack wrote: >Just to be clear: I didn't say 3.2 is “bad” or “not fine”. It's just the fact >that people need more than “fine” to feel urged to switch to Python 3. I >sincerely hope 3.3 fulfills that and if PEP 414 even makes porting easier we >might have a perfect storm. :) Cool, and yes reaching that tipping point is what it's all about. :) >> it's probably likely what we'll have backports of >> stable Python 3 releases to 12.04, at the very least in semi-official PPAs. > >That's what I've been hoping for. Maybe it will work the other way around >too: People like 3.3, target it first and port back later to reach more >users. It's all about encouraging people to try the nectar of Python 3 – once >they're caught it's sticky sweetness[1]… ;) Indeed! -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] PEP 414
On Fri, 2012-03-02 at 15:39 -0500, Barry Warsaw wrote: > On Mar 02, 2012, at 03:13 PM, Chris McDonough wrote: > > >FWIW, I think this issue's webness may be overestimated. There happens to be > >lots and lots of existing UI code which contains complex interactions between > >unicode literals and nonliterals in web apps, but there's also likely lots of > >nonweb code that has the same issue. If e.g. wxPython had already been > >ported, I think you'd be hearing the same sorts of things from folks that had > >investments in existing Python-2-compatible code when trying to port stuff to > >Py3 (at least if they wanted to run on both Python 2 and Python 3 within the > >same codebase). > > Okay, I just want to be very careful about the message we're sending here, > because I think many libraries and applications will work fine with the > facilities available in today's stable releases, i.e. unicode_literals and > b-prefixes. For these, there's no need to define "native strings", nor do > they require language constructs above what's already available. Although the change makes it possible, and it is very useful for very low level WSGI apps, the issue this change addresses really isn't really 100% about "needing to define native strings". It's also just preservation of a resource in pretty short supply: developer energy. You will probably need to modify less code when taking piece of software that currently runs on Python 2 and changing it so that it runs on both Python 2 and Python 3, without needing to worry over the unintended consequences of using a unicode_literals future import or replacing existing u'' with a function call. This, IMO, can only be a good thing, because the nominal impact of some future user who must now understand u'' syntax is (again IMO) not as consequential as that user having less software to choose from because porting to Python 3 was just that much harder for existing Python 2 developers. - C ___ 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] PEP 414
On Fri, Mar 2, 2012 at 15:26, Serhiy Storchaka wrote: > 02.03.12 15:49, Lennart Regebro написав(ла): > >> Just my 2 cents on the PEP rewrite: >> >> u'' support is not just if you want to write code that doesn't use >> 2to3. Even when you use 2to3 it is useful to be able to flag strings s >> binary, unicode or "native". > > > What "native" means in context Python 3 only? I don't understand your question. > "Native" strings only have > meaning if we consider Python 2 and Python 3 together. "Native" string is a > text string, which was binary in Python 2. There is a flag for such strings > -- str(). Yes. ___ 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] odd "tuple does not support assignment" confusion...
Hi everyone, Just stumbled on a fun little thing: We create a simple structure... l = ([],) Now modify the list, and... l[0] += [1] ...we fail: ## Traceback (most recent call last): ## File "F:\work\ImageGrid\cur\ImageGrid\src\test\python-bug.py", line 17, in ## l[0] += [1] ## TypeError: 'tuple' object does not support item assignment Tested on 2.5, 2.7, 3.1, PyPy1.8 on win32 and 2.7 on x86-64 Debian (just in case). I was expecting this to succeed, is this picture wrong or am I missing something? ...am I really the first one to try and modify a list within a tuple directly?! It's even more odd that I did not try this myself since first started with Python back in 99 :) I could not google this "feature" out either... BTW, It is quite trivial (and obvious) to trick the interpreter to get the desired result... e = l[0] e += [1] P.S. the attachment is runnable version of the above code... -- Thanks! Alex. ___ 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] odd "tuple does not support assignment" confusion...
l[0] += [1] is the same as l[0] = l[0] + [1] Does that make the reason for the error clearer? The problem is the attempt to assign a value to l[0]. It is not the same as e = l[0] e += [1] which is the equivalent to e = l[0] e = e + [1] This never assigns a value to l[0]. Schiavo Simon ___ 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] odd "tuple does not support assignment" confusion...
On Sat, 03 Mar 2012 03:06:33 +0400, "Alex A. Naanou" wrote: > Hi everyone, > > Just stumbled on a fun little thing: > > We create a simple structure... > > l = ([],) > > > Now modify the list, and... > > l[0] += [1] > > > ...we fail: > ## Traceback (most recent call last): > ## File "F:\work\ImageGrid\cur\ImageGrid\src\test\python-bug.py", > line 17, in > ## l[0] += [1] > ## TypeError: 'tuple' object does not support item assignment What is even more fun is that the append actually worked (try printing l). This is not a bug, it is a quirk of how extended assignment works. I think there's an issue report in the tracker somewhere that discusses it. --David ___ 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] odd "tuple does not support assignment" confusion...
On Sat, Mar 3, 2012 at 1:38 AM, R. David Murray wrote: > What is even more fun is that the append actually worked (try printing > l). Now that is just weird. :) ___ 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] Assertion in _PyManagedBuffer_FromObject()
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 redirecting requests m might not be >> equal to nd. > > Right. Then it's only safe when the intermediate provider knows what the > underlying buffer providers do. Not unlikely in an application setting, > though, and it could just be an option at creation time to activate the > delegation for the ndarray above. OK, my take on the discussion so far: 1. assert() is the wrong tool for this job (it should trigger a Python error message) 2. the current check is too strict (it should just check for obj != NULL, not obj == &exporter) 3. the current check is in the wrong place (it should be in PyObject_GetBuffer) Sound about right? 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] odd "tuple does not support assignment" confusion...
On 3/2/2012 6:06 PM, Alex A. Naanou wrote: Just stumbled on a fun little thing: The place for 'fun little things' is python-list, mirrored as gmane.comp.python.general. We create a simple structure... l = ([],) Now modify the list, and... l[0] += [1] ...we fail: This has been discussed several times on python-list. Searching group gmane.comp.python.general for 'augmented assignment tuple' at search.gmane.com returns about 50 matches. -- Terry Jan Reedy ___ 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] PEP 414
Zitat von Lennart Regebro : Just my 2 cents on the PEP rewrite: u'' support is not just if you want to write code that doesn't use 2to3. Even when you use 2to3 it is useful to be able to flag strings s binary, unicode or "native". How so? In the Python 3 code, the u"" prefix would not appear, even if appears in the original source, as 2to3 eliminates it. So you surely need the u"" prefix to distinguish binary, unicode, or native strings in your source - but with 2to3, the PEP 414 change is unnecessary. Regards, Martin ___ 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] PEP 414
Chris McDonough plope.com> writes:
> FWIW, I think this issue's webness may be overestimated. There happens
> to be lots and lots of existing UI code which contains complex
> interactions between unicode literals and nonliterals in web apps, but
> there's also likely lots of nonweb code that has the same issue. If
> e.g. wxPython had already been ported, I think you'd be hearing the same
> sorts of things from folks that had investments in existing
> Python-2-compatible code when trying to port stuff to Py3 (at least if
> they wanted to run on both Python 2 and Python 3 within the same
> codebase).
As I understand it, WSGI happens to explicitly expect str in certain places,
even places where conceptually text should be acceptable. The perception of
webness seems to be substantiated by Nick's comment about endorsement from you,
Armin, Jacob Kaplan-Moss, and Kenneth Reitz for this change. Not that webness is
a bad thing, of course - it's a very important part of the ecosystem.
It would be good to hear from other constituencies about where else (apart from
WSGI and the other uses mentioned in the "APIs and Concepts Using Native
Strings" section of the PEP) native strings are needed. I have encountered such
needs sometimes, but not uncommonly, they appear to be broken APIs that just
expect str even though text should be OK (e.g. cookie APIs, or the sqlite
adapter's insisting on accepting datetimes in text format, but only as native
strings). It would be a shame to leave these APIs as they are indefinitely, and
perhaps using a marker like n('xxx') for native strings would help to remind us
that these areas need addressing at some point.
Regards,
Vinay Sajip
___
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] PEP 414 - some numbers from the Django port
PEP 414 mentions the use of function wrappers and talks about both their
obtrusiveness and performance impact on Python code. In the Django Python 3
port, I've used unicode_literals, and hence have no u prefixes in the ported
code, and use a function wrapper to adorn native strings where they are needed.
Though the port is still work in progress, it passes all tests on 2.x and 3.x
with the SQLite adapter, with only a small number skipped specifically during
the porting exercise (generally due to representational differences).
I'd like to share some numbers from this port to see what people here think
about them.
Firstly, on obtrusiveness: Out of a total of 1872 source files, the native
string marker only appears in 30 files - 18 files in Django itself, and 12
files in the test suite. This is less than 2% of files, so the native string
markers are not especially invasive when looking at code. There are only 76
lines in the ported Django which contain native string markers.
Secondly, on performance. I ran the following steps 6 times:
Run the test suite on unported Django using Python 2.7.2 ("vanilla")
Run the test suite on the ported Django using Python 2.7.2 ("ported")
Run the test suite on the ported Django using Python 3.2.2 ("ported3")
Django skips some tests because dependencies aren't installed (e.g. PIL for
Python 3.2). The raw numbers, in seconds elapsed for the test run, are given
below:
vanilla (4659 tests): 468.586 486.231 467.584 464.916 480.530 475.457
ported (4655 tests): 467.350 480.902 479.276 478.748 478.115 486.044
ported3 (4609 tests): 463.161 470.423 463.833 448.097 456.727 504.402
If we allow for the different numbers of tests run by dividing by the number
of tests and multiplying by 100, we get:
vanilla-weighted: 10.057 10.436 10.036 9.979 10.314 10.205
ported-weighted: 10.040 10.331 10.296 10.285 10.271 10.441
ported3-weighted: 10.049 10.207 10.064 9.722 9.909 10.944
If I run these through ministat, it tells me there is no significant
difference in these data sets, with a 95% confidence level:
$ ministat -w 74 vanilla-weighted ported-weighted ported3-weighted
x vanilla-weighted
+ ported-weighted
* ported3-weighted
+--+
|* + |
|* * x *** ++x+ * *|
||___|___M|AA_M___AM___|__|_| |
+--+
N Min MaxMedian AvgStddev
x 6 9.97910.43610.205 10.1711670.17883782
+ 6 10.0410.44110.296 10.2773330.13148485
No difference proven at 95.0% confidence
* 6 9.72210.94410.064 10.1491670.42250274
No difference proven at 95.0% confidence
So, looking at a large project in a relevant problem domain, unicode_literals
and native string markers would appear not to adversely impact readability or
performance.
Your comments would be appreciated.
Regards,
Vinay Sajip
___
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] PEP 414
Chris McDonough plope.com> writes: > Although the change makes it possible, and it is very useful for very > low level WSGI apps, the issue this change addresses really isn't really > 100% about "needing to define native strings". It's also just > preservation of a resource in pretty short supply: developer energy. Apparently developer energy is a limitless resource when it comes to arguing over PEPs ;-) > This, IMO, can only be a good thing, because the nominal impact of some It can also have some downsides, at least according to some points of view. For example, I regard elevating "native strings" to undue prominence, and the continued use of u'xxx' in Python 3 code, as unfortunate consequences. For example, with PEP 414, it will be possible to mix Unicode with and without prefix - how would that not be at least a little confusing for users new to Python? Remember, "native strings" are a Python-only concept. > future user who must now understand u'' syntax is (again IMO) not as > consequential as that user having less software to choose from because > porting to Python 3 was just that much harder for existing Python 2 > developers. I don't believe it's because porting to Python 3 is especially hard. I'm not saying it's trivial, but it isn't rocket surgery ;-) Even if porting were trivially easy to do technically at the level the PEP addresses, there would still be additional tests, and perhaps documentation, and perhaps release-related work to be done. Since Python 2.x is a very good platform for software development, where's the incentive to move over to 3.x? It's the chicken and egg effect. Many people are waiting for other people to move over (perhaps projects they depend upon), and while the transition is happening, it's not as quick as it could be. I think a lot of it is down to inertia. Possibly another factor was the "just use 2to3 message", which we now know doesn't work well in all scenarios. However, I don't believe that the "use a single codebase, use six or six-like techniques, use unicode_literals, use the 2to3 fixer to remove unicode prefixes, and use native string markers where you need to" message has received anything like the same level of airplay. If you talk to people who have *actually tried* this approach (say Barry, or me) you'll hear that it's not been all that rough a ride. Regards, Vinay Sajip ___ 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] PEP 414
On Fri, Mar 2, 2012 at 7:22 PM, Vinay Sajip wrote: > Apparently developer energy is a limitless resource when it comes to arguing > over PEPs ;-) Aren't *you* the one who keeps kicking this dead horse? -- --Guido van Rossum (python.org/~guido) ___ 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] PEP 414
Guido van Rossum python.org> writes: > > Aren't *you* the one who keeps kicking this dead horse? > >From looking at the overall thread, I'm just one of many people posting on it. Which dead horse am I kicking? It's not as if I'm opposing anything or anyone - just putting my point of view forward about porting from 2.x -> 3.x, as others have done - that's not OT, is it? Regards, Vinay Sajip ___ 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] PEP 414
On Sat, Mar 3, 2012 at 01:49, wrote: > > Zitat von Lennart Regebro : > > >> Just my 2 cents on the PEP rewrite: >> >> u'' support is not just if you want to write code that doesn't use >> 2to3. Even when you use 2to3 it is useful to be able to flag strings s >> binary, unicode or "native". > > How so? In the Python 3 code, the u"" prefix would not appear, even if > appears in the original source, as 2to3 eliminates it. Well, not if you disable that fixer. ;-) But you are right, it isn't necessary. I was thinking of 3to2, actually. That was one of the objections I had to the usefulness of 3to2, there is no way to make the distinction between unicode and native strings. (The u'' prefix hence actually makes 3to2 a realistic option, and that's good.) So everyone can ignore this, I mixed up two issues. :-) //Lennart ___ 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] PEP 414
On Sat, Mar 3, 2012 at 04:22, Vinay Sajip wrote: > It can also have some downsides, at least according to some points of view. > For > example, I regard elevating "native strings" to undue prominence, and the > continued use of u'xxx' in Python 3 code, as unfortunate consequences. For > example, with PEP 414, it will be possible to mix Unicode with and without > prefix - how would that not be at least a little confusing for users new to > Python? Remember, "native strings" are a Python-only concept. This is true, new users will see 'foo', r'foo', b'foo', and will naturally assume u'foo' is something special too, and will have to be told it is not. But that's an unfortunate effect of Python 3 making the change to Unicode strings, a change that *removed* a lot of other much more confusing things. 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? The only way we could have avoided this "three strings" situation is by actually removing native strings from Python for at least five years, and only used b'' or u''. That would not have been any less confusing. //Lennart ___ 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] PEP 414
Chris McDonough writes: > FWIW, I think this issue's webness may be overestimated. There happens > to be lots and lots of existing UI code which contains complex > interactions between unicode literals and nonliterals in web apps, but > there's also likely lots of nonweb code that has the same issue. If we generalize "web" to "wire protocols", I would say that nonweb code that has the same issue is poorly coded. I suppose there may be some similar issues in say XML handling, because XML can be used in binary applications as well as for structuring text (ie, XML is really a wire protocol too). But pure user interface modules like wxPython? Text should be handled as text, not as bytes that "probably" are ASCII-encoded or locale-specifically-encoded (or are magic numbers that happen to be mnemonic when interpreted as ASCII). I don't say that we should ignore the pain of the nonweb users -- but it is a different issue, with different solutions. In particular, using "native strings" (and distinguishing them by the absence of u'') is usually a non-solution for non-web applications, because it propagates the bad practice of pretending that unknown encodings can be assumed to be well-behaved into an environment where good practice is designed in. This is quite different from the case for webby usage, where it often makes sense to handle many low-level operations without ever converting to text, while the same literal strings may be useful in both wire and text contexts (and so should be present only once according to DRY). (N.B. I suspect that it is probably also generally possible for webby applications to avoid native strings without much cost, as Nick showed in urlparse. But at least manipulations of the wire protocol without conversion to text are a plausible optimization.) ___ 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] odd "tuple does not support assignment" confusion...
I knew this was a feature!!! features such as these should be fixed! %) On Sat, Mar 3, 2012 at 03:38, R. David Murray wrote: > On Sat, 03 Mar 2012 03:06:33 +0400, "Alex A. Naanou" > wrote: >> Hi everyone, >> >> Just stumbled on a fun little thing: >> >> We create a simple structure... >> >> l = ([],) >> >> >> Now modify the list, and... >> >> l[0] += [1] >> >> >> ...we fail: >> ## Traceback (most recent call last): >> ## File "F:\work\ImageGrid\cur\ImageGrid\src\test\python-bug.py", >> line 17, in >> ## l[0] += [1] >> ## TypeError: 'tuple' object does not support item assignment > > What is even more fun is that the append actually worked (try printing > l). > > This is not a bug, it is a quirk of how extended assignment works. > I think there's an issue report in the tracker somewhere that > discusses it. > > --David -- Alex. ___ 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] PEP 414
03.03.12 08:20, Lennart Regebro написав(ла): But you are right, it isn't necessary. I was thinking of 3to2, actually. That was one of the objections I had to the usefulness of 3to2, there is no way to make the distinction between unicode and native strings. (The u'' prefix hence actually makes 3to2 a realistic option, and that's good.) 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. ___ 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
