[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
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
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
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
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
Stefan Krah stefan at bytereef.org wrote:
Alex Leach albl500 at york.ac.uk 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,
Stefan Krah stefan at bytereef.org wrote:
Alex Leach albl500 at york.ac.uk 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,
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
Éric Araujo merwok at netwok.org 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 --
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
Stefan Krah stefan at bytereef.org wrote:
Alex Leach albl500 at york.ac.uk 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,
Stefan Behnel stefan...@behnel.de 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. */
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
Alex Leach albl...@york.ac.uk 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
On Fri, Mar 2, 2012 at 8:19 PM, Stefan Behnel stefan...@behnel.de 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,
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. */
Nick Coghlan ncogh...@gmail.com 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
On Fri, Mar 2, 2012 at 10:55 PM, Stefan Krah ste...@bytereef.org wrote:
Nick Coghlan ncogh...@gmail.com 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
Stefan Behnel stefan...@behnel.de 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
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];
*
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
Stefan Krah ste...@bytereef.org 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
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?
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
On Sat, Mar 3, 2012 at 12:39 AM, Stefan Behnel stefan...@behnel.de 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
On Thu, 01 Mar 2012 18:39:19 +
Alex Leach albl...@york.ac.uk 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
Stefan Behnel stefan...@behnel.de 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
On 02/03/2012 14:52, Antoine Pitrou solip...@pitrou.net 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
Stefan Krah ste...@bytereef.org 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 =
On Fri, 02 Mar 2012 16:29:39 +
Alex Leach albl...@york.ac.uk 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` ==
Alex Leach albl...@york.ac.uk 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
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
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 =
On Fri, Mar 2, 2012 at 05:22, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Mar 2, 2012 at 10:55 PM, Stefan Krah ste...@bytereef.org wrote:
Nick Coghlan ncogh...@gmail.com wrote:
However, given the lack of control, an assert() isn't the appropriate
tool here - PyObject_GetBuffer itself
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
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
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
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
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
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 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 Fri, Mar 2, 2012 at 15:26, Serhiy Storchaka storch...@gmail.com 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
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 module
## l[0] += [1]
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
On Sat, 03 Mar 2012 03:06:33 +0400, Alex A. Naanou alex.na...@gmail.com
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):
##
On Sat, Mar 3, 2012 at 1:38 AM, R. David Murray rdmur...@bitdance.com 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
On Sat, Mar 3, 2012 at 3:14 AM, Stefan Behnel stefan...@behnel.de 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
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
Zitat von Lennart Regebro rege...@gmail.com:
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
Chris McDonough chrism at 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
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
Chris McDonough chrism at 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
On Fri, Mar 2, 2012 at 7:22 PM, Vinay Sajip vinay_sa...@yahoo.co.uk 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)
Guido van Rossum guido at 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
On Sat, Mar 3, 2012 at 01:49, mar...@v.loewis.de wrote:
Zitat von Lennart Regebro rege...@gmail.com:
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 Sat, Mar 3, 2012 at 04:22, Vinay Sajip vinay_sa...@yahoo.co.uk 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
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
I knew this was a feature!!!
features such as these should be fixed! %)
On Sat, Mar 3, 2012 at 03:38, R. David Murray rdmur...@bitdance.com wrote:
On Sat, 03 Mar 2012 03:06:33 +0400, Alex A. Naanou alex.na...@gmail.com
wrote:
Hi everyone,
Just stumbled on a fun little thing:
We
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
59 matches
Mail list logo
