Mailman 3 March 2012 - Python-Dev

Undocumented view==NULL argument in PyObject_GetBuffer()
by Stefan Krah March 6, 2012

March 6, 2012

Hello, PyObject_GetBuffer() had an undocumented variant that was used internally: PyObject_GetBuffer(obj, NULL, flags) view==NULL has never been allowed by either PEP-3118 or the documentation: PEP: "The first variable is the "exporting" object. The second argument is the address to a bufferinfo structure. Both arguments must never be NULL." 3.2 docs: "view must point to an existing Py_buffer structure allocated by the caller." The internal use was to bump up the export count of e.g. a bytearray without bothering to have it fill in a complete Py_buffer. The increased export count would then prevent the bytearray from being resized. However, this feature appears to be unused in the source tree. The last traces of a middle NULL argument that I found are here: http://hg.python.org/cpython/file/df3b2b5db900/Modules/posixmodule.c#l561 So, currently the checks for NULL just slow down bytearray_getbuffer() and a couple of other getbufferprocs. Also, due to the absence of a use case it takes some VCS history digging to find out why the feature was there in the first place. The obvious question is: Will anyone need view==NULL in the future or can we remove the special case? Stefan Krah

3 3

Re: [Python-Dev] [Python-checkins] cpython: Fix a comment: PySequence_Fast() creates a list, not a tuple.
by Eli Bendersky March 6, 2012

March 6, 2012

This fix should be applied to the documentation as well. On Tue, Mar 6, 2012 at 08:59, larry.hastings <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/d8f68195210e > changeset: 75448:d8f68195210e > user: Larry Hastings <larry(a)hastings.org> > date: Mon Mar 05 22:59:13 2012 -0800 > summary: > Fix a comment: PySequence_Fast() creates a list, not a tuple. > > files: > Include/abstract.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > diff --git a/Include/abstract.h b/Include/abstract.h > --- a/Include/abstract.h > +++ b/Include/abstract.h > @@ -1026,7 +1026,7 @@ > > PyAPI_FUNC(PyObject *) PySequence_Fast(PyObject *o, const char* m); > /* > - Returns the sequence, o, as a tuple, unless it's already a > + Returns the sequence, o, as a list, unless it's already a > tuple or list. Use PySequence_Fast_GET_ITEM to access the > members of this list, and PySequence_Fast_GET_SIZE to get its length. > > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins >

1 0

Re: [Python-Dev] Sandboxing Python
by Victor Stinner March 5, 2012

March 5, 2012

2012/3/5 Serhiy Storchaka <storchaka(a)gmail.com>: > 05.03.12 11:09, Victor Stinner написав(ла): > >> pysandbox uses SIGALRM with a timeout of 5 seconds by default. You can >> change this timeout or disable it completly. >> >> pysandbox doesn't provide a function to limit the memory yet, you have >> to do it manually. It's not automatic because there is no portable way >> to implement such limit and it's difficult to configure it. For my IRC >> bot using pysandbox, setrlimit() is used with RLIMIT_AS. > > > But it does not work for extensive C-calculations. `sum(xrange(1000000000))` > runs 2.5 minutes on my computer instead of 5 seconds, and `map(sum, > [xrange(1000000000)] * 1000000)` -- almost infinity time. pysandbox doesn't > provide a reliable time limit too, it is also necessary to mention. Ah yes, I realized that SIGALRM is handled by the C signal handler, but Python only handles the signal later. sum() doesn't call PyErr_CheckSignals() to check for pending signals. Apply the timeout would require to modify the sum() function. A more generic solution would be to use a subprocess. Victor

3 4

Misc/NEWS in 2.7 and 3.2
by Éric Araujo March 5, 2012

March 5, 2012

Hi, I noticed that the top-level section in Misc/NEWS (i.e. the section where we add entries) for 3.3 is for 3.3.0a2 (the next release), but in 2.7 and 3.2 we’re still adding entries to the sections corresponding to the last RCs. Will the RMs move things when they merge back their release clones, or should we start new sections and move the latest entries there? Cheers

1 0

PEP 414 updated
by Nick Coghlan March 4, 2012

March 4, 2012

My rewritten version of PEP 414 is now up (http://www.python.org/dev/peps/pep-0414/). It describes in detail a lot more of the historical background that was taken as read when Guido accepted the PEP. Can we let the interminable discussion die now? Please? Regards, Nick. P.S. If you find an actual factual *error* in the PEP, let me know by private email. If you just disagree with Guido's acceptance of the PEP, or want to quibble about my personal choice of wording on a particular point, please just let it rest. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

7 17

slice subscripts for sequences and mappings
by Eli Bendersky March 4, 2012

March 4, 2012

Hello, I find a strange discrepancy in Python with regards to slice subscripting of objects, at the C API level. I mean things like obj[start:end:step]. I'd expect slice subscripts to be part of the sequence interface, and yet they are not. In fact, they are part of the mapping interface. For example, the list object has its slice get/set methods assigned to a PyMappingMethods struct. So does a bytes object, and pretty much every other object that wants to support subscripts. This doesn't align well with the documentation, in at least two places. 1) The library documentation (http://docs.python.org/dev/library/stdtypes.html) in 4.8 says: "Mappings are mutable objects. There is currently only one standard mapping type, the dictionary" Why then does a list implement the mapping interface? Moreover, why does bytes, an immutable object, implement the mapping interface? 2) The same documentation page in 4.6 says, in the operation table: s[i:j] slice of s from i to j s[i:j:k] slice of s from i to j with step k But in the implementation, the slice subscripts are part of the mapping, not the sequence inteface. The PySequenceMethods structure does have fields for slice accessors, but their naming (was_sq_slice, was_sq_ass_slice) suggests they're just deprecated placeholders. This also doesn't align well with logic, since mappings like dict have no real meaning for slice subscripts. These logically belong to a sequence. Moreover, it takes subscripts for single a single numeric index away from subscripts for a slice into a different protocol (the former in sequence, the latter in mapping). I realize I must be missing some piece of the history here and not suggesting to change anything. I do think that the documentation, especially in the area of the type object that defines the sequence and mapping protocols, could be clarified to express what is expected of a new type that wants to act as a sequence. In particular, it should be said explicitly that such a type must implement the mapping protocol if it wants slice subscripting. If this makes any sense at all, I will open an issue. Eli

7 17

Re: [Python-Dev] PEP 414
by Vinay Sajip March 4, 2012

March 4, 2012

Nick Coghlan <ncoghlan <at> gmail.com> writes: > It reduces the problem (compared to omitting the import and using a > u() function), but it's still ugly and still involves the "action at a > distance" of the unicode literals import. I agree about the action-at-a-distance leading to non-obvious bugs and wasted head-scratching time caused by such. It could be mitigated somewhat by project-level conventions, e.g. that all string literals are Unicode on that project. Then, if you put yourself in the relevant mindset when working on that project, there are fewer surprises. It's probably a matter of choosing the lesser among evils, since the proposal seems to allow mixing of literals with and without u prefixes in 3.x code - doesn't that also seem ugly? When this came up earlier (when I think Chris McDonough raised it) the issue of what to do on 3.2 came up, and though it has been addressed somewhat in the PEP, it would be nice to see the suggested on-installation hook fleshed out a little more. Regards, Vinay Sajip

22 61

Assertion in _PyManagedBuffer_FromObject()
by Stefan Behnel March 4, 2012

March 4, 2012

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

4 21

cpython compilation error
by Ejaj Hassan March 3, 2012

March 3, 2012

Hello, I was compiling Pcbuild.sln from cpython in vc++ 2008 and i got the error as "Solution folders are not supported in this version of application-Solution folder will be displayed as unavailable". Could someone please tell me the source and reason for this error. Thanks in advance. Regards, Ejaj

3 2

odd "tuple does not support assignment" confusion...
by Alex A. Naanou March 3, 2012

March 3, 2012

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] ## 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.

4 5