Mailman 3 September 2010 - Python-Dev

C API doc question
by Nick Coghlan Sept. 3, 2010

Sept. 3, 2010

Due to the Unicode API discussion, I happened to be looking at the C API docs at http://docs.python.org/dev/c-api/unicode.html#plain-py-unicode and noticed that out of: PyUnicode_FromUnicode PyUnicode_FromStringAndSize PyUnicode_FromString PyUnicode_FromFormat PyUnicode_FromFormatV PyUnicode_FromEncodedObject PyUnicode_FromObject only the first and the last two are flagged in the online docs as returning a new reference. The other 4 are not (but probably should be). However, I can't see anything in the markup which is even causing those "Return value: New reference" markings to appear in the first place, nor any clues in the Documenting Python info. What am I missing? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 3

Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
by Georg Brandl Sept. 3, 2010

Sept. 3, 2010

Hi Victor, 1. This function and PyUnicode_strcat are missing documentation. 2. Are you sure they need to be public APIs? What are they going to be used for? (I'm not sure myself, but I think we usually have a short notice here when new C APIs are added.) Georg Am 02.09.2010 01:43, schrieb victor.stinner: > Author: victor.stinner > Date: Thu Sep 2 01:43:53 2010 > New Revision: 84430 > > Log: > Create PyUnicode_strdup() function > > Modified: > python/branches/py3k/Include/unicodeobject.h > python/branches/py3k/Objects/unicodeobject.c > > Modified: python/branches/py3k/Include/unicodeobject.h > ============================================================================== > --- python/branches/py3k/Include/unicodeobject.h (original) > +++ python/branches/py3k/Include/unicodeobject.h Thu Sep 2 01:43:53 2010 > @@ -220,6 +220,7 @@ > # define _PyUnicode_AsDefaultEncodedString _PyUnicodeUCS2_AsDefaultEncodedString > # define _PyUnicode_Fini _PyUnicodeUCS2_Fini > # define _PyUnicode_Init _PyUnicodeUCS2_Init > +# define PyUnicode_strdup PyUnicodeUCS2_strdup > > #else > > @@ -302,7 +303,7 @@ > # define _PyUnicode_AsDefaultEncodedString _PyUnicodeUCS4_AsDefaultEncodedString > # define _PyUnicode_Fini _PyUnicodeUCS4_Fini > # define _PyUnicode_Init _PyUnicodeUCS4_Init > - > +# define PyUnicode_strdup PyUnicodeUCS4_strdup > > #endif > > @@ -1602,6 +1603,14 @@ > Py_UNICODE c > ); > > +/* Create a copy of a unicode string ending with a nul character. Return NULL > + and raise a MemoryError exception on memory allocation failure, otherwise > + return a new allocated buffer (use PyMem_Free() to free the buffer). */ > + > +PyAPI_FUNC(Py_UNICODE*) PyUnicode_strdup( > + PyObject *unicode > + ); > + > #ifdef __cplusplus > } > #endif > > Modified: python/branches/py3k/Objects/unicodeobject.c > ============================================================================== > --- python/branches/py3k/Objects/unicodeobject.c (original) > +++ python/branches/py3k/Objects/unicodeobject.c Thu Sep 2 01:43:53 2010 > @@ -10014,6 +10014,28 @@ > return NULL; > } > > +Py_UNICODE* > +PyUnicode_strdup(PyObject *object) > +{ > + PyUnicodeObject *unicode = (PyUnicodeObject *)object; > + Py_UNICODE *copy; > + Py_ssize_t size; > + > + /* Ensure we won't overflow the size. */ > + if (PyUnicode_GET_SIZE(unicode) > ((PY_SSIZE_T_MAX / sizeof(Py_UNICODE)) - 1)) { > + PyErr_NoMemory(); > + return NULL; > + } > + size = PyUnicode_GET_SIZE(unicode) + 1; /* copy the nul character */ > + size *= sizeof(Py_UNICODE); > + copy = PyMem_Malloc(size); > + if (copy == NULL) { > + PyErr_NoMemory(); > + return NULL; > + } > + memcpy(copy, PyUnicode_AS_UNICODE(unicode), size); > + return copy; > +} > > #ifdef __cplusplus > } -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

5 13

Re: [Python-Dev] r84456 - python/branches/py3k/Doc/c-api/unicode.rst
by Georg Brandl Sept. 3, 2010

Sept. 3, 2010

Please add a "versionadded" tag. Georg Am 03.09.2010 18:23, schrieb victor.stinner: > Author: victor.stinner > Date: Fri Sep 3 18:23:29 2010 > New Revision: 84456 > > Log: > Document PyUnicode_AsUnicodeCopy() > > > Modified: > python/branches/py3k/Doc/c-api/unicode.rst > > Modified: python/branches/py3k/Doc/c-api/unicode.rst > ============================================================================== > --- python/branches/py3k/Doc/c-api/unicode.rst (original) > +++ python/branches/py3k/Doc/c-api/unicode.rst Fri Sep 3 18:23:29 2010 > @@ -335,6 +335,14 @@ > buffer, *NULL* if *unicode* is not a Unicode object. > > > +.. cfunction:: Py_UNICODE* PyUnicode_AsUnicodeCopy(PyObject *unicode) > + > + Create a copy of a unicode string ending with a nul character. Return *NULL* > + and raise a :exc:`MemoryError` exception on memory allocation failure, > + otherwise return a new allocated buffer (use :cfunc:`PyMem_Free` to free the > + buffer). > + > + > .. cfunction:: Py_ssize_t PyUnicode_GetSize(PyObject *unicode) > > Return the length of the Unicode object. -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

2 1

Two small PEP ideas
by Barry Warsaw Sept. 3, 2010

Sept. 3, 2010

I have two somewhat unrelated thoughts about PEPs. * Accepted: header When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email. I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted. I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted. I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147: http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections. * EOL schedule for older releases. We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs. However, we have release schedule PEPs going back to Python 1.6. It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode. I would not mandate that we go back and update all previous PEPs for either of these ideas. We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically. Thoughts? -Barry

18 51

PEP 3149 accepted
by Georg Brandl Sept. 3, 2010

Sept. 3, 2010

This is to let you all know that PEP 3149 is accepted. Benjamin and I decided that on the basis that * strong precedent is set with PEP 3147 * it is not mutually exclusive with PEP 384; should PEP 384 become widely accepted, its use can fade out again * it is a strictly optional feature Barry promised the code will go in before this weekend's alpha2, so that distributors can subject the new code to proper testing, should they choose to use PEP 3149 features. cheers, Georg

2 2

Internal counter to debug leaking file descriptors
by anatoly techtonik Sept. 3, 2010

Sept. 3, 2010

Hi, Is there any kind of internal file descriptor counter that can be queried to debug issues with leaking resources? It can be used in tests to check that all tests are finish with 0 opened descriptors. It will be very useful while porting Python applications from Unix to Windows. Unix is more tolerant to open files and can overwrite them and do other nasty things. See the thread from comment #17 - https://bugs.edge.launchpad.net/dulwich/+bug/557585/ - there is an example of mmap that starts holding file descriptor somewhere long before an error occurs. How could one debug this? Right now I have to use FileMon. It includes information about operated filenames, but no info about source code where this happens. It will be nice to have some kind of counter with filename information inside Python, so that it can be possible to get the full log of events without manually messing with external system-specific tools like FileMon. -- anatoly t.

7 8

Buffer protocol for io.BytesIO?
by Antoine Pitrou Sept. 3, 2010

Sept. 3, 2010

Hello all, In issue #5506, I originally proposed that io.BytesIO objects support the buffer protocol, to make it possible to access the internal buffer without intermediate copies. Then it came to me then perhaps it would be too automatic. So I'm currently floating between: - add implicit buffer protocol support to BytesIO objects - add explicit buffer protocol support through the call of a getbuffer() method, which would return a small intermediate object supporting the buffer protocol on behalf of the original BytesIO object What do you think would be better? Thank you Antoine.

6 13

Re: [Python-Dev] r84447 - in python/branches/py3k: Lib/test/test_set.py Objects/setobject.c
by Antoine Pitrou Sept. 3, 2010

Sept. 3, 2010

On Fri, 3 Sep 2010 12:00:51 +0200 (CEST) raymond.hettinger <python-checkins(a)python.org> wrote: > rv = set_discard_entry(so, &an_entry); > - if (rv == -1) > + if (rv == -1) { > + Py_DECREF(key); > return NULL; > + } > if (rv == DISCARD_NOTFOUND) { > - if (set_add_entry(so, &an_entry) == -1) > + if (set_add_entry(so, &an_entry) == -1) { > + Py_DECREF(key); > return NULL; > + } > } > + Py_DECREF(key); > } You have some misindented code here. Regards Antoine.

1 0

Re: [Python-Dev] [Python-checkins] r84391 - in python/branches/py3k: Include/abstract.h Misc/NEWS Objects/abstract.c Objects/memoryobject.c
by Nick Coghlan Sept. 1, 2010

Sept. 1, 2010

On Wed, Sep 1, 2010 at 10:58 PM, antoine.pitrou <python-checkins(a)python.org> wrote: > Modified: python/branches/py3k/Misc/NEWS > ============================================================================== > --- python/branches/py3k/Misc/NEWS (original) > +++ python/branches/py3k/Misc/NEWS Wed Sep 1 14:58:21 2010 > @@ -354,6 +354,9 @@ > Build > ----- > > +- Issue #3101: Helper functions _add_one_to_C() and _add_one_to_F() become > + _Py_add_one_to_C() and _Py_add_one_to_F(), respectively. > + Minor point: the names are actually *_index_C and *_index_F. (the patch is right, just NEWS and the checkin comment are off) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

'hasattr' is broken by design
by Yury Selivanov Sept. 1, 2010

Sept. 1, 2010

Hello, I know the issue has been discussed several times already, however I couldn't find any reasonable explanation of its strange behaviour. The main problem with 'hasattr' function is that is swallows all exceptions derived from Exception class. It's a good thing that it doesn't do that with BaseException as it was fixed not a long time ago, but it's definitely not enough. First of all, this behaviour of 'hasattr' contradicts with the very core principle of python: "Errors should never pass silently." And since 'hasattr' function is in builtins module and is a widely used function it impacts the whole language. Secondly, take a look at the following: >>> class Test: ... @property ... def attr(self): ... self['foo'] ... >>> hasattr(Test(), 'attr') False There can be any exception instead of KeyError in the above snippet of code, but this small example shows how 'hasattr': misleadingly breaks the code logic (1) and masks bug (2). And that's the simplest possible example, there are much more in real life. While (1) is maybe acceptable for someone, there is no excuse for the (2). Moreover, current 'hasattr' behaviour tremendously complicates use of '__getattribute__' magic. And forget about importlib magic with LazyImports, one 'hasattr' ruins everything by catching ImportError. To conclude: 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr'). Probably, Python 3.2 release is our last chance. 2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline. This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected. - Yury Selivanov, Sprymix Inc. +1-416-509-2807

18 77