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 3t
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...
>>
>
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 sam
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,
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".
>
> Ho
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 forwa
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)
___
Pyt
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 supp
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 n
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
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
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 discu
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 n
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
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
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
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]
## Ty
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
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
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
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
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 s
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 properl
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 so
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-awar
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
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'
>> >>> n
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 wit
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
Python-D
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)
>
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 = memo
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
tex
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
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
> executio
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. S
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
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?
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 th
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
Python-Dev@p
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];
* i
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.
>
>
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
>> misbeha
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
> in
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.
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 rememberi
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 th
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
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 == b
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 y
> 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 im
> É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
T
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
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 y
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 y
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_GetBuff
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
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
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 h
[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 m
59 matches
Mail list logo
