Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Am 03.09.2010 01:26, schrieb Victor Stinner: Hi, Le jeudi 02 septembre 2010 11:13:22, vous avez écrit : 1. This function and PyUnicode_strcat are missing documentation. It's Py_UNICODE_strcat(), not PyUnicode_strcat(). But yes, Py_UNICODE_strcat() is not documented. But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. Does it mean that we should write a document for all these functions? They mimic the str*() C API. Yes. All public functions should be documented. I know that some existing functions are not; that should not be a guideline for new functions though. If PyUnicode_strdup() is kept public, it should be documented, yes. If you want to make this a public API function, it also needs to be renamed to fit the rest of the API. PyUnicode_strdup(): I don't like this name. In my first patch, it was called Py_UNICODE_strdup() but all Py_UNICODE_*() functions take Py_UNICODE* arguments, no PyUnicodeObject* argument. I'll leave the naming decisions to Marc-Andre. What are they going to be used for? I am not able to merge my huge work on unicode import (see #8611, #9425 and the import_unicode svn branch) at once, so I'm splitting it into atomic commits. PyUnicode_strdup() and Py_UNICODE_strcat() are not used yet, but I plan to use them for the import machinery (Python/import.c) to replace char* by Py_UNICODE*. 2. Are you sure they need to be public APIs? About Py_UNICODE_strcat(): yes, why not? Other Py_UNICODE_str*() functions are pratical but also required to manipulate Py_UNICODE* strings. For public APIs, the question is not why not, but why. If they are needed for the import machinery in Unicode, sure they are useful, but that's no reason to make them public. I'd recommend to start out with _Py prefixes, and avoid any new public APIs unless they are asked for. About PyUnicode_strdup() (PyUnicode_AsUnicodeCopy): I don't know. It is possible to rewrite it in few lines. Why don't you want to add them to the public API? For my work, it doesn't matter if it's public or not. This function uses PyMem_xxx API, I don't know if a third part library would like to rely on PyMem_xxx. cheers, Georg -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3149 accepted
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On 09/02/2010 10:35 PM, Antoine Pitrou wrote: 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? getbuffer() sounds better. Accessing buffer contents is a nice feature, but one shouldn't be able to do it by accident. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Victor Stinner wrote: Hi, Le jeudi 02 septembre 2010 11:13:22, vous avez écrit : 1. This function and PyUnicode_strcat are missing documentation. It's Py_UNICODE_strcat(), not PyUnicode_strcat(). But yes, Py_UNICODE_strcat() is not documented. But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. Does it mean that we should write a document for all these functions? They mimic the str*() C API. If PyUnicode_strdup() is kept public, it should be documented, yes. As for naming, I think Py_UNICODE_strdup() is fine, since these functions work directly on Py_UNICODE buffers and they mimic the C functions. They should be documented, though, even if the documentation is terse and refers to the C API of a similar name. -- If you want to make this a public API function, it also needs to be renamed to fit the rest of the API. PyUnicode_strdup(): I don't like this name. In my first patch, it was called Py_UNICODE_strdup() but all Py_UNICODE_*() functions take Py_UNICODE* arguments, no PyUnicodeObject* argument. See above: the current naming is fine. I'd suggest PyUnicode_AsUnicodeCopy() which then corresponds to PyUnicode_FromUnicode(), but I'm not sure whether we should have such a public API in the first place. PyUnicode_AsUnicodeCopy() is maybe a better name, I like it. For APIs that work on PyUnicodeObjects, we should stick to the naming convention used by the Unicode and string/bytes API. It's a little more verbose, but also provides more clarity than the C API function names. -- What are they going to be used for? I am not able to merge my huge work on unicode import (see #8611, #9425 and the import_unicode svn branch) at once, so I'm splitting it into atomic commits. PyUnicode_strdup() and Py_UNICODE_strcat() are not used yet, but I plan to use them for the import machinery (Python/import.c) to replace char* by Py_UNICODE*. 2. Are you sure they need to be public APIs? About Py_UNICODE_strcat(): yes, why not? Other Py_UNICODE_str*() functions are pratical but also required to manipulate Py_UNICODE* strings. About PyUnicode_strdup() (PyUnicode_AsUnicodeCopy): I don't know. It is possible to rewrite it in few lines. Why don't you want to add them to the public API? For my work, it doesn't matter if it's public or not. This function uses PyMem_xxx API, I don't know if a third part library would like to rely on PyMem_xxx. This will have to be documented (see PEP 384 for some reasoning on malloc() use in DLLs). Other than that, ok, let's have them. They do provide some use to other tools working on Py_UNICODE, just like the macros we have for these. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 03 2010) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/ 2010-09-15: DZUG Tagung, Dresden, Germany 11 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
Antoine Pitrou, 02.09.2010 22:35: 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 Hmm, given that you actually have to *explicitly* call the getbuffer operation on the BytesIO object, I don't have the impression that this would be *implicit* support. What would be the advantage of having to do two operations? Is it just that you want to make the internal buffer joining step more visible? (thinking in terms of good-old Py2 StringIO here, not sure how io.BytesIO works these days) Also, note that the BytesIO object must not be modified while someone reads the buffer. That would be a less obvious side effect if the returned buffer object was different from the BytesIO object itself. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, 03 Sep 2010 10:04:12 +0200 Stefan Behnel stefan...@behnel.de wrote: Antoine Pitrou, 02.09.2010 22:35: 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 Hmm, given that you actually have to *explicitly* call the getbuffer operation on the BytesIO object, I don't have the impression that this would be *implicit* support. That's the other alternative, precisely. What would be the advantage of having to do two operations? Is it just that you want to make the internal buffer joining step more visible? I was just wondering if it's a good thing to let people, e.g., concatenate a bytes object and a BytesIO by using '+'. Also, note that the BytesIO object must not be modified while someone reads the buffer. That would be a less obvious side effect if the returned buffer object was different from the BytesIO object itself. It could not be resized, but it could be modified (same as what happens with bytearrays today). Actually, the buffer itself would be writable, and allow modifying the BytesIO contents. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
On Thu, Sep 2, 2010 at 6:26 PM, Victor Stinner victor.stin...@haypocalc.com wrote: But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. http://bugs.python.org/issue8649 - Py_UNICODE_* functions are undocumented -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Internal counter to debug leaking file descriptors
On Tue, Aug 31, 2010 at 5:03 PM, Guido van Rossum gu...@python.org wrote: If you wanted to do something like this in the Python stdlib, you'd have to monkey-patch (with a proxy/wrapper) all places that can open or close a filedescriptor -- os.open, os.popen, os.close, file open/close, socket open/close, and probably a bunch more that I've forgotten. Also some extension modules may open file descriptors directly through the C interfaces. Actually I monkey-patched fdopen and open, but it appeared that it is not enough. Extensions cause the biggest problem. How can I monkey-patch opening of file descriptor deep inside mmap module? How can I know that a file descriptor is opened there at all? I thought that maybe Python has internal API for opening file descriptors and it is possible to intercept the operation on this level. Is it feasible to route all file descriptor open operations through such API that allows to audit open/close operations and filenames through callback? On Linux you can look somewhere in /proc, but I don't know that it would help you find where a file was opened. If I can query FD counter - I can automate the process of walking through the code line by line to find places where this descriptor incremented or decremented. Of course it would be nice to get access to FD stack so that a full filename can also be retrieved in this case. It would be nice if at least Linux implementation provided a way to detect leaking descriptors, thanks for suggestions, but my expertise and available resources are limited to Windows machines, so for now I won't be able to try anything more complicated than an unpack-and-launch Linux solution. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Internal counter to debug leaking file descriptors
Of course it would be nice to get access to FD stack so that a
full filename can also be retrieved in this case.
On Linux, this can be easily achieved by using /proc.
You can take a look at how this is done in the current development
version of psutil:
http://code.google.com/p/psutil/source/browse/trunk/psutil/_pslinux.py?spec=svn633r=630#266
Usage:
import psutil, os
this_process = psutil.Process(os.getpid())
f = open('file.ext', 'w')
this_process.get_open_files()
['/home/giampaolo/svn/psutil/file.ext']
Same for sockets, a bunch of lines later:
http://code.google.com/p/psutil/source/browse/trunk/psutil/_pslinux.py?spec=svn633r=630#284
import socket
s = socket.create_connection(('google.com', 80))
this_process.get_connections()
[connection(family=2, type=1, local_address=('192.168.1.43', 38067),
remote_address=('72.14.234.104', 80), status='ESTABLISHED')]
Hope this helps
--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Le vendredi 03 septembre 2010 11:20:04, vous avez écrit : But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. http://bugs.python.org/issue8649 - Py_UNICODE_* functions are undocumented Opened since 3 months. It looks like programmers don't like writing documentation :-) -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org 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 384 status
On Fri, Sep 3, 2010 at 12:44 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: On 02/09/10 09:04, Nick Coghlan wrote: I think it would be better if everything dealing with FILE* was a macro rather than a function, yes. How would that help? Macros (and, as Antoine pointed out, inline functions) will never cross C runtime boundaries, even on Windows. They'll get compiled in when the extension module is built and linked to a C runtime library from there, so it won't matter if that differs from the one that is linked to the Python binary. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84447 - in python/branches/py3k: Lib/test/test_set.py Objects/setobject.c
On Fri, 3 Sep 2010 12:00:51 +0200 (CEST)
raymond.hettinger python-check...@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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, Sep 3, 2010 at 6:54 PM, Antoine Pitrou solip...@pitrou.net wrote: What would be the advantage of having to do two operations? Is it just that you want to make the internal buffer joining step more visible? I was just wondering if it's a good thing to let people, e.g., concatenate a bytes object and a BytesIO by using '+'. It actually strikes me as a fairly bad thing, so I think you're right to distrust it. Better to follow the precedent set with getvalue() and require an explicit call to getbuffer(). The fact there are two options (immutable copy via getvalue() or mutable accessor via getbuffer()) is all the more reason not to make either conversion implicit. Also, note that the BytesIO object must not be modified while someone reads the buffer. That would be a less obvious side effect if the returned buffer object was different from the BytesIO object itself. It could not be resized, but it could be modified (same as what happens with bytearrays today). Actually, the buffer itself would be writable, and allow modifying the BytesIO contents. You may need to be careful with reads and writes while the buffer is exposed (e.g. throwing an exception until the buffer is released again). Perhaps the buffer accessor should be a context manager so it is easy to enforce prompt release? That is: with datastream.getbuffer() as buf: ... # any resizing operations on datastream, including read/write raise until the buffer is released Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
On Fri, Sep 3, 2010 at 8:14 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Le vendredi 03 septembre 2010 11:20:04, vous avez écrit : But I didn't found any doc for other Py_UNICODE_str*() functions in Doc/c-api/*.rst. http://bugs.python.org/issue8649 - Py_UNICODE_* functions are undocumented Opened since 3 months. It looks like programmers don't like writing documentation :-) In this case, C programmers think C stdlib function names are intuitive may be closer to the mark ;) Cheers, Nick. P.S. More seriously, these particular functions really are just like the standard C function of the same name, only operating on Py_UNICODE* rather than char*, so I can understand documentation being skipped when they were added. However, they may as well be mentioned in http://docs.python.org/dev/c-api/unicode.html#plain-py-unicode -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, 3 Sep 2010 20:44:01 +1000 Nick Coghlan ncogh...@gmail.com wrote: It actually strikes me as a fairly bad thing, so I think you're right to distrust it. Better to follow the precedent set with getvalue() and require an explicit call to getbuffer(). The fact there are two options (immutable copy via getvalue() or mutable accessor via getbuffer()) is all the more reason not to make either conversion implicit. Thank you for the advice. I think getbuffer() it will be :) It could not be resized, but it could be modified (same as what happens with bytearrays today). Actually, the buffer itself would be writable, and allow modifying the BytesIO contents. You may need to be careful with reads and writes while the buffer is exposed (e.g. throwing an exception until the buffer is released again). Perhaps the buffer accessor should be a context manager so it is easy to enforce prompt release? That's an interesting idea. I was planning to return a memoryview object (in order to hide the intermediate object, and make it really minimal), so perhaps the context protocol should be enabled on memoryviews? (__enter__ would be a no-op, and __exit__ would release the internal buffer and render it invalid, a bit like closing a file) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
On Fri, Sep 3, 2010 at 6:01 PM, M.-A. Lemburg m...@egenix.com wrote: About PyUnicode_strdup() (PyUnicode_AsUnicodeCopy): I don't know. It is possible to rewrite it in few lines. Why don't you want to add them to the public API? For my work, it doesn't matter if it's public or not. This function uses PyMem_xxx API, I don't know if a third part library would like to rely on PyMem_xxx. This will have to be documented (see PEP 384 for some reasoning on malloc() use in DLLs). PyUnicode_AsUnicodeCopy is indeed a better name. As far as the need to call PyMem_Free goes, a similar requirement already exists for argument parsing via es and es# (see http://docs.python.org/dev/c-api/arg.html#strings-and-buffers), so just documenting it is fine. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
Antoine Pitrou, 03.09.2010 12:56: On Fri, 3 Sep 2010 20:44:01 +1000 Nick Coghlan wrote: It actually strikes me as a fairly bad thing, so I think you're right to distrust it. +1 It could not be resized, but it could be modified (same as what happens with bytearrays today). Actually, the buffer itself would be writable, and allow modifying the BytesIO contents. You may need to be careful with reads and writes while the buffer is exposed (e.g. throwing an exception until the buffer is released again). Perhaps the buffer accessor should be a context manager so it is easy to enforce prompt release? That's an interesting idea. I was planning to return a memoryview object (in order to hide the intermediate object, and make it really minimal), so perhaps the context protocol should be enabled on memoryviews? (__enter__ would be a no-op, and __exit__ would release the internal buffer and render it invalid, a bit like closing a file) I can't see a reason not to support that. Sounds a lot simpler than requiring to set the memory view reference to None in order to trigger a cleanup at an undefined point in time. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] C API doc question
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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, Sep 3, 2010 at 8:56 PM, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 3 Sep 2010 20:44:01 +1000 Nick Coghlan ncogh...@gmail.com wrote: That's an interesting idea. I was planning to return a memoryview object (in order to hide the intermediate object, and make it really minimal), so perhaps the context protocol should be enabled on memoryviews? (__enter__ would be a no-op, and __exit__ would release the internal buffer and render it invalid, a bit like closing a file) Yep, sounds good (with no-op in this case meaning just return self). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C API doc question
2010/9/3 Nick Coghlan ncogh...@gmail.com: 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? This information is in the file: Doc/data/refcounts.dat There is a extension to sphinx that reads this file and generates the annotation in the documentation. This file is not very well known, even by core developers... -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C API doc question
On Fri, Sep 3, 2010 at 9:19 PM, Amaury Forgeot d'Arc amaur...@gmail.com wrote: 2010/9/3 Nick Coghlan ncogh...@gmail.com: 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? This information is in the file: Doc/data/refcounts.dat There is a extension to sphinx that reads this file and generates the annotation in the documentation. This file is not very well known, even by core developers... Nope, never knew it existed until just now :) Since it does exist, how hard would it be to get the extension to emit a warning if a C API function isn't listed in that file, or if a function listed in that file doesn't appear anywhere in the docs? Currently it appears to default to reporting no effect on references if a function isn't mentioned, which is potentially misleading (as the above examples show, this file completely missed out on the PyString-PyUnicode rename). From a more wish-list point of view, how hard would it be to modify the extension to support having this markup inline with the function documentation rather than having it off in a separate file? Or addressing Skip's comment by allowing -0 to indicate cases where item references are stolen? I created http://bugs.python.org/issue9755 to cover these questions. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 3149 accepted
On Sep 03, 2010, at 09:36 AM, Georg Brandl wrote: 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. Thanks very much Georg and Benjamin. I am going to merge the code in the next hour or so. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, 3 Sep 2010 21:16:13 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Fri, Sep 3, 2010 at 8:56 PM, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 3 Sep 2010 20:44:01 +1000 Nick Coghlan ncogh...@gmail.com wrote: That's an interesting idea. I was planning to return a memoryview object (in order to hide the intermediate object, and make it really minimal), so perhaps the context protocol should be enabled on memoryviews? (__enter__ would be a no-op, and __exit__ would release the internal buffer and render it invalid, a bit like closing a file) Yep, sounds good (with no-op in this case meaning just return self). It just occurred to me that it could be interpreted as a breach of the moratorium. On the other hand, according to PEP 3003: “The case for adding a method to a built-in object can be made.” This case seems even lighter than adding a new method. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
On Sep 02, 2010, at 09:08 PM, Raymond Hettinger wrote: On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote: Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers. I like Guido's idea. Just appoint have one of the experienced developers who is independent of the proposal and have them be the final arbiter. For example, Guido had earlier suggested that I decide the fate of the yield from proposal because I had experience in the topic but was not not personally involved in the proposal. Guido has set a good example for others to follow: * let a conversation evolve until an outcome is self-evident * or kill it early if it has no chance * or if discussion teases out all of the meaningful thinking but doesn't reach a clear conclusion, just make a choice based on instinct * have biases toward real-world use cases, towards ideas proven in other languages (category killers), towards slow rates of language evolution, and think about the long-term. It is better to have one experienced developer decide than to have a committee. I completely agree that it's good we're beginning to give Guido a break so that he doesn't have to follow every thread, think hard about every PEP and make every decision. Having just gone through this as a PEP author with 3149, I have a couple of thoughts on how we might begin to formalize this process. Of course, we want to keep it lightweight, but also effective and as always in the best interest of Python. One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision. This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible. As Raymond says, it should be someone independent of the proposal, but with the interest, time, and experience necessary to make an informed decision. We might even want to capture the arbiter selection in a PEP header (similar to the new Resolution header for capturing the final decision reference). While I agree that we don't want decision by committee, I think we should consider a preference for paired arbiters. I have the highest respect for all the senior developers who would likely make up the pool of PEP deciders, but it gave me great confidence to have both Benjamin and Georg decide the fate of PEP 3149. As someone who might serve a similar role in the future, I would value a second person to sanity check my own thoughts on the matter and to identify any holes in my understanding (or shudder missed emails :). I'd say, let's state a preference (not a requirement) for two arbiters for any PEP that's not decided by Guido. We'd talked before about allowing the RM for the target version to make the decision. Maybe the RM can serve as that second arbiter when no other obvious candidate is available. Raymond, you identified a great set of criteria that the arbiters should use to guide them to a decision. I'm willing to write up an informational PEP that codifies this and any other guidelines we come up with for non-BDFL PEP decisions. Finally a reminder to PEP authors that it is your responsibility to shepherd your PEP through the process. Don't be a pest, but do keep an eye on the release calendar so that you're not scrambling for a snap decision at the last minute. 18 months can go by quickly. :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
On Fri, Sep 3, 2010 at 8:15 AM, Barry Warsaw ba...@python.org wrote: One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision. Hey! I'm still here! :-) More to the point, you can assume that I'm happy to have every PEP decision made by someone else *except* if you see me participate in the thread. If I don't show up in the thread, you can assume that either (a) I don't care or know enough about the topic, or (b) I am confident that it's going in the right direction. This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible. I prefer acronyms derived from BDFL, like BDFM (BD for the moment) or perhaps BDFP (BD for the PEP). (BDFM sounds better but BDFP is more accurate. I'll leave it up to the FLUFL to pick one.) As Raymond says, it should be someone independent of the proposal, but with the interest, time, and experience necessary to make an informed decision. We might even want to capture the arbiter selection in a PEP header (similar to the new Resolution header for capturing the final decision reference). While I agree that we don't want decision by committee, I think we should consider a preference for paired arbiters. I have the highest respect for all the senior developers who would likely make up the pool of PEP deciders, but it gave me great confidence to have both Benjamin and Georg decide the fate of PEP 3149. As someone who might serve a similar role in the future, I would value a second person to sanity check my own thoughts on the matter and to identify any holes in my understanding (or shudder missed emails :). I'd say, let's state a preference (not a requirement) for two arbiters for any PEP that's not decided by Guido. Hm... As long as we can make sure not to pick the same pair all the time this makes sense. (Not that I have any objections to how the Georg+Benjamin pair decided PEP 3149 -- to the contrary -- but I think it would be good to spread the power.) But if a pair can't be found I think a single BDFM/BDFP will work too. We'd talked before about allowing the RM for the target version to make the decision. Maybe the RM can serve as that second arbiter when no other obvious candidate is available. Good fallback plan. Raymond, you identified a great set of criteria that the arbiters should use to guide them to a decision. I'm willing to write up an informational PEP that codifies this and any other guidelines we come up with for non-BDFL PEP decisions. Finally a reminder to PEP authors that it is your responsibility to shepherd your PEP through the process. Don't be a pest, but do keep an eye on the release calendar so that you're not scrambling for a snap decision at the last minute. 18 months can go by quickly. :) Well, realistically, there's only so much grief that anyone PEP author can be expected to put up with. I expect that a lot of PEPs won't be written or will be withdrawn in the face of prolonged discussion. Early selection of a BDFM (maybe the M can also refer to mentorship) ought to help in encouraging where encouragement would help -- and of course sometimes the best thing to do is to encourage the PEP author to drop the idea, if no consensus is in view (or if the author is particularly hard-headed). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
It just occurred to me that it could be interpreted as a breach of the moratorium. On the other hand, according to PEP 3003: “The case for adding a method to a built-in object can be made.” This case seems even lighter than adding a new method. I’ve been satisfied to see other proposals breaking the moratorium being refused. Respecting rules set by ourselves for the benefit of other VMs sends a good signal. In this case, the PEP leaves an opening (quoted line above), the change should be very easy to implement in other VMs, and it’s an elegant way of adding a useful feature. +1 from me. Regards ___ Python-Dev mailing list Python-Dev@python.org 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 (2010-08-27 - 2010-09-03)
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 stats:
open2569 (+41)
closed 18970 (+40)
total 21539 (+55)
Open issues with patches: 1091
Issues opened (41)
==
#5217: testExtractDir (test.test_zipfile.TestWithDirectory) fails whe
http://bugs.python.org/issue5217 reopened by eric.araujo
#9706: ssl errors checking
http://bugs.python.org/issue9706 opened by giampaolo.rodola
#9707: Reworked threading.local reference implementation
http://bugs.python.org/issue9707 opened by pitrou
#9708: cElementTree iterparse does not support parser argument
http://bugs.python.org/issue9708 opened by adrian_nye
#9709: test_distutils warning: initfunc exported twice on Windows
http://bugs.python.org/issue9709 opened by skrah
#9713: Py_CompileString fails on non decode-able paths.
http://bugs.python.org/issue9713 opened by ideasman42
#9714: urllib2 digest authentication doesn't work when connecting to
http://bugs.python.org/issue9714 opened by warpr
#9716: The inittab modules cannot be packages
http://bugs.python.org/issue9716 opened by kayhayen
#9717: operator module - in place operators documentation
http://bugs.python.org/issue9717 opened by arno
#9719: build_ssl.py: cannot find 'asm64/*.*'
http://bugs.python.org/issue9719 opened by srid
#9720: zipfile writes incorrect local file header for large files in
http://bugs.python.org/issue9720 opened by craigds
#9721: urlparse.urljoin() cuts off last base character with semicolon
http://bugs.python.org/issue9721 opened by calvin
#9722: PyObject_Print with Visual Studio 2010
http://bugs.python.org/issue9722 opened by Krauzi
#9723: pipes.quote() needs to be documented
http://bugs.python.org/issue9723 opened by brandon-rhodes
#9725: urllib.request.FancyURLopener won't connect to pages requiring
http://bugs.python.org/issue9725 opened by petr6.6
#9727: Add callbacks to be invoked when locale changes
http://bugs.python.org/issue9727 opened by ncoghlan
#9728: Docs point to FAQ Section 3, but FAQs are not numbered
http://bugs.python.org/issue9728 opened by stutzbach
#9729: Unconnected SSLSocket.{send,recv} raises TypeError: 'member_de
http://bugs.python.org/issue9729 opened by spiv
#9730: base64 docs refers to strings instead of bytes
http://bugs.python.org/issue9730 opened by JingCheng.LIU
#9731: Add ABCMeta.has_methods and tests that use it
http://bugs.python.org/issue9731 opened by stutzbach
#9732: Addition of getattr_static for inspect module
http://bugs.python.org/issue9732 opened by michael.foord
#9733: Can't iterate over multiprocessing.managers.DictProxy
http://bugs.python.org/issue9733 opened by jjconti
#9736: doctest.DocTestSuite doesn't handle test globs correctly
http://bugs.python.org/issue9736 opened by j1m
#9738: Document the encoding of functions bytes arguments of the C AP
http://bugs.python.org/issue9738 opened by haypo
#9739: Output of help(...) is wider than 80 characters
http://bugs.python.org/issue9739 opened by casevh
#9740: Support for HTTP 1.1 persistent connections throughout the sta
http://bugs.python.org/issue9740 opened by ipatrol
#9741: msgfmt.py generates invalid mo because msgfmt.make() does not
http://bugs.python.org/issue9741 opened by timothy.ty.lee
#9742: Python 2.7: math module fails to build on Solaris 9
http://bugs.python.org/issue9742 opened by mhenriq
#9743: __call__.__call__ chain cause crash when long enough
http://bugs.python.org/issue9743 opened by modchan
#9745: MSVC .pdb files not created by python 2.7 distutils
http://bugs.python.org/issue9745 opened by jpe
#9746: All sequence types support .index and .count
http://bugs.python.org/issue9746 opened by stutzbach
#9747: os.getresgid() documentation mentions user ids, not group i
http://bugs.python.org/issue9747 opened by Red HamsterX
#9748: .inputrc magic-space breaks interactive mode
http://bugs.python.org/issue9748 opened by stephenk
#9750: sqlite3 iterdump fails on column with reserved name
http://bugs.python.org/issue9750 opened by Marko.Kohtala
#9751: _PyInstance_Lookup() defeats its purpose
http://bugs.python.org/issue9751 opened by arigo
#9752: MSVC Compiler warning in Python\import.c
http://bugs.python.org/issue9752 opened by stutzbach
#9754: assertWarns and assertWarnsRegexp
http://bugs.python.org/issue9754 opened by pitrou
#9755: Fix refcounting details in Py3k C API documentation
http://bugs.python.org/issue9755 opened by ncoghlan
#9756: Crash with custom __getattribute__
http://bugs.python.org/issue9756 opened by flox
#9757: Add context manager protocol to memoryviews
http://bugs.python.org/issue9757 opened by pitrou
#1367631: maximum length not enforced in cgi.parse()
http://bugs.python.org/issue1367631 reopened by r.david.murray
Most recent 15 issues with no replies (15)
==
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Le vendredi 03 septembre 2010 10:01:12, vous avez écrit : (...) About PyUnicode_strdup() (PyUnicode_AsUnicodeCopy): I don't know. It is possible to rewrite it in few lines. Why don't you want to add them to the public API? For my work, it doesn't matter if it's public or not. This function uses PyMem_xxx API, I don't know if a third part library would like to rely on PyMem_xxx. This will have to be documented (see PEP 384 for some reasoning on malloc() use in DLLs). It is already documented in unicodeobject.h. Other than that, ok, let's have them. Ok. r84455 renames PyUnicode_strdup() to PyUnicode_AsUnicodeCopy(), and r84456 document it: -- .. 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). -- Thanks all for your review and advices ;-) -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Le vendredi 03 septembre 2010 18:07:45, Python tracker a écrit : ACTIVITY SUMMARY (2010-08-27 - 2010-09-03) Python tracker at http://bugs.python.org/ Remember also the buildbot report: http://code.google.com/p/bbreport/wiki/PythonBuildbotReport Eg. there are some no space left on device on x86 XP-5 * build slaves. -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, Sep 3, 2010 at 3:56 AM, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 3 Sep 2010 20:44:01 +1000 Nick Coghlan ncogh...@gmail.com wrote: It actually strikes me as a fairly bad thing, so I think you're right to distrust it. Better to follow the precedent set with getvalue() and require an explicit call to getbuffer(). The fact there are two options (immutable copy via getvalue() or mutable accessor via getbuffer()) is all the more reason not to make either conversion implicit. Thank you for the advice. I think getbuffer() it will be :) +1 It could not be resized, but it could be modified (same as what happens with bytearrays today). Actually, the buffer itself would be writable, and allow modifying the BytesIO contents. You may need to be careful with reads and writes while the buffer is exposed (e.g. throwing an exception until the buffer is released again). Perhaps the buffer accessor should be a context manager so it is easy to enforce prompt release? That's an interesting idea. I was planning to return a memoryview object (in order to hide the intermediate object, and make it really minimal), so perhaps the context protocol should be enabled on memoryviews? (__enter__ would be a no-op, and __exit__ would release the internal buffer and render it invalid, a bit like closing a file) So far I'm -0 on this. I'm not sure if it solves a real problem, and I think that if we were to add a way to define the scope of a buffer operation using a with-statement, it should work for all objects that support the buffer protocol (which IIUC means more than just memoryview). I'd be more enthusiastic about a separate context manager to wrap any such object. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
On 3 September 2010 17:30, Victor Stinner victor.stin...@haypocalc.com wrote: Remember also the buildbot report: http://code.google.com/p/bbreport/wiki/PythonBuildbotReport Eg. there are some no space left on device on x86 XP-5 * build slaves. Thanks, I wasn't aware of that. I'll look into those issues. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, 3 Sep 2010 09:32:22 -0700 Guido van Rossum gu...@python.org wrote: It could not be resized, but it could be modified (same as what happens with bytearrays today). Actually, the buffer itself would be writable, and allow modifying the BytesIO contents. You may need to be careful with reads and writes while the buffer is exposed (e.g. throwing an exception until the buffer is released again). Perhaps the buffer accessor should be a context manager so it is easy to enforce prompt release? That's an interesting idea. I was planning to return a memoryview object (in order to hide the intermediate object, and make it really minimal), so perhaps the context protocol should be enabled on memoryviews? (__enter__ would be a no-op, and __exit__ would release the internal buffer and render it invalid, a bit like closing a file) So far I'm -0 on this. I'm not sure if it solves a real problem, and I think that if we were to add a way to define the scope of a buffer operation using a with-statement, it should work for all objects that support the buffer protocol (which IIUC means more than just memoryview). I'd be more enthusiastic about a separate context manager to wrap any such object. Most objects don't have a dedicated Python method to return a buffer, because they implement the buffer API implicitly at the C level, using stack-allocated Py_buffer structs. Therefore, there would be no point in a context manager for these objects (the buffer is released timely by the consuming function). It's only when creating a persistent Python-level wrapper for the Py_buffer struct (that is, a memoryview) that heap memory management issues could come into play. You are right that it's probably not a very important issue. Mutating an object's buffer from several threads isn't recommended anyway. As for resource consumption, what matters is when the original object (which owns the memory area) gets deallocated, and there's little chance that creating an additional memoryview makes a significant difference. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buffer protocol for io.BytesIO?
On Fri, Sep 3, 2010 at 10:03 AM, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 3 Sep 2010 09:32:22 -0700 Guido van Rossum gu...@python.org wrote: It could not be resized, but it could be modified (same as what happens with bytearrays today). Actually, the buffer itself would be writable, and allow modifying the BytesIO contents. You may need to be careful with reads and writes while the buffer is exposed (e.g. throwing an exception until the buffer is released again). Perhaps the buffer accessor should be a context manager so it is easy to enforce prompt release? That's an interesting idea. I was planning to return a memoryview object (in order to hide the intermediate object, and make it really minimal), so perhaps the context protocol should be enabled on memoryviews? (__enter__ would be a no-op, and __exit__ would release the internal buffer and render it invalid, a bit like closing a file) So far I'm -0 on this. I'm not sure if it solves a real problem, and I think that if we were to add a way to define the scope of a buffer operation using a with-statement, it should work for all objects that support the buffer protocol (which IIUC means more than just memoryview). I'd be more enthusiastic about a separate context manager to wrap any such object. Most objects don't have a dedicated Python method to return a buffer, because they implement the buffer API implicitly at the C level, using stack-allocated Py_buffer structs. Therefore, there would be no point in a context manager for these objects (the buffer is released timely by the consuming function). It's only when creating a persistent Python-level wrapper for the Py_buffer struct (that is, a memoryview) that heap memory management issues could come into play. You are right that it's probably not a very important issue. Mutating an object's buffer from several threads isn't recommended anyway. As for resource consumption, what matters is when the original object (which owns the memory area) gets deallocated, and there's little chance that creating an additional memoryview makes a significant difference. Thanks for the explanation. Still -0. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Internal counter to debug leaking file descriptors
On 9/3/2010 6:09 AM, Giampaolo Rodolà wrote:
Of course it would be nice to get access to FD stack so that a
full filename can also be retrieved in this case.
On Linux, this can be easily achieved by using /proc.
You can take a look at how this is done in the current development
version of psutil:
http://code.google.com/p/psutil/source/browse/trunk/psutil/_pslinux.py?spec=svn633r=630#266
Usage:
import psutil, os
this_process = psutil.Process(os.getpid())
f = open('file.ext', 'w')
this_process.get_open_files()
['/home/giampaolo/svn/psutil/file.ext']
Same for sockets, a bunch of lines later:
http://code.google.com/p/psutil/source/browse/trunk/psutil/_pslinux.py?spec=svn633r=630#284
import socket
s = socket.create_connection(('google.com', 80))
this_process.get_connections()
[connection(family=2, type=1, local_address=('192.168.1.43', 38067),
remote_address=('72.14.234.104', 80), status='ESTABLISHED')]
If you can use psutil itself, it has compiled Windows versions for 2.7
and 3.1
https://code.google.com/p/psutil/
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Internal counter to debug leaking file descriptors
The Windows part slipped under my radar. =)
Unfortunately the Windows binaries still refer to the current version
which doesn't include open files and open connections functionalities.
To have those he'll have to get the latest code from svn and compile
it with mingw32.
--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
2010/9/3 Terry Reedy tjre...@udel.edu:
On 9/3/2010 6:09 AM, Giampaolo Rodolà wrote:
Of course it would be nice to get access to FD stack so that a
full filename can also be retrieved in this case.
On Linux, this can be easily achieved by using /proc.
You can take a look at how this is done in the current development
version of psutil:
http://code.google.com/p/psutil/source/browse/trunk/psutil/_pslinux.py?spec=svn633r=630#266
Usage:
import psutil, os
this_process = psutil.Process(os.getpid())
f = open('file.ext', 'w')
this_process.get_open_files()
['/home/giampaolo/svn/psutil/file.ext']
Same for sockets, a bunch of lines later:
http://code.google.com/p/psutil/source/browse/trunk/psutil/_pslinux.py?spec=svn633r=630#284
import socket
s = socket.create_connection(('google.com', 80))
this_process.get_connections()
[connection(family=2, type=1, local_address=('192.168.1.43', 38067),
remote_address=('72.14.234.104', 80), status='ESTABLISHED')]
If you can use psutil itself, it has compiled Windows versions for 2.7 and
3.1
https://code.google.com/p/psutil/
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84456 - python/branches/py3k/Doc/c-api/unicode.rst
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.rstFri 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. ___ Python-Dev mailing list Python-Dev@python.org 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 3149 accepted
On Sep 03, 2010, at 09:36 AM, Georg Brandl wrote: 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. Once again, thanks. Committed in r84458. You'll want to 'make distclean' and reconfigure your py3k tree. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
On Fri, Sep 3, 2010 at 08:45, Guido van Rossum gu...@python.org wrote: On Fri, Sep 3, 2010 at 8:15 AM, Barry Warsaw ba...@python.org wrote: One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision. Hey! I'm still here! :-) More to the point, you can assume that I'm happy to have every PEP decision made by someone else *except* if you see me participate in the thread. If I don't show up in the thread, you can assume that either (a) I don't care or know enough about the topic, or (b) I am confident that it's going in the right direction. I guess the real question comes down to whether you want us to bug you to select the temp dictator or just make a call amongst ourselves? This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible. I prefer acronyms derived from BDFL, like BDFM (BD for the moment) or perhaps BDFP (BD for the PEP). (BDFM sounds better but BDFP is more accurate. I'll leave it up to the FLUFL to pick one.) I personally like BDFN (BD for now) or BDAGW (BD at Guido's whim), but this will bikeshed into eternity, so I am happy with the FLUFL being the dictator for the new acronym choice. =) As Raymond says, it should be someone independent of the proposal, but with the interest, time, and experience necessary to make an informed decision. We might even want to capture the arbiter selection in a PEP header (similar to the new Resolution header for capturing the final decision reference). While I agree that we don't want decision by committee, I think we should consider a preference for paired arbiters. I have the highest respect for all the senior developers who would likely make up the pool of PEP deciders, but it gave me great confidence to have both Benjamin and Georg decide the fate of PEP 3149. As someone who might serve a similar role in the future, I would value a second person to sanity check my own thoughts on the matter and to identify any holes in my understanding (or shudder missed emails :). I'd say, let's state a preference (not a requirement) for two arbiters for any PEP that's not decided by Guido. Hm... As long as we can make sure not to pick the same pair all the time this makes sense. (Not that I have any objections to how the Georg+Benjamin pair decided PEP 3149 -- to the contrary -- but I think it would be good to spread the power.) I agree, and a RM as the backup/sanity check would not spread it out. Considering the position is held for 1.5 years (or more) and has in the past been held sequentially by the same person, that wouldn't exactly spread it about. It also limits trying to bring new people into the process as RMs tend to be old-hands and not new blood. Plus we are not about to make the lead on a PEP decision be a new person either. But if a pair can't be found I think a single BDFM/BDFP will work too. I agree. I would trust anyone who is given the ability to make a call to listen to reason enough to not necessarily need the sanity check. But a duopoly is not a bad thing overall either. We'd talked before about allowing the RM for the target version to make the decision. Maybe the RM can serve as that second arbiter when no other obvious candidate is available. Good fallback plan. As long as it gets spread around and the fallback is not the default, I agree. Raymond, you identified a great set of criteria that the arbiters should use to guide them to a decision. I'm willing to write up an informational PEP that codifies this and any other guidelines we come up with for non-BDFL PEP decisions. Finally a reminder to PEP authors that it is your responsibility to shepherd your PEP through the process. Don't be a pest, but do keep an eye on the release calendar so that you're not scrambling for a snap decision at the last minute. 18 months can go by quickly. :) Well, realistically, there's only so much grief that anyone PEP author can be expected to put up with. I expect that a lot of PEPs won't be written or will be withdrawn in the face of prolonged discussion. Early selection of a BDFM (maybe the M can also refer to mentorship) ought to help in encouraging where encouragement would help -- and of course sometimes the best thing to do is to encourage the PEP author to drop the idea, if no consensus is in view (or if the author is particularly hard-headed). Hopefully PEPs like this will get stopped before they even get checked in. The PEP editors have been sending PEPs back to their authors to share on python-ideas first for a little while now and that seems to have helped make sure the PEPs that do reach us are of sufficient quality. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
On Fri, Sep 3, 2010 at 12:50 PM, Brett Cannon br...@python.org wrote: I guess the real question comes down to whether you want us to bug you to select the temp dictator or just make a call amongst ourselves? It's okay to bug me only if you can't find or agree on a temp dictator. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Am 03.09.2010 18:24, schrieb Victor Stinner: Other than that, ok, let's have them. Ok. r84455 renames PyUnicode_strdup() to PyUnicode_AsUnicodeCopy(), and r84456 document it: -- ... 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). -- Thanks all for your review and advices ;-) What about Py_UNICODE_strcat? If it remains, it needs to be documented as well. Georg -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84456 - python/branches/py3k/Doc/c-api/unicode.rst
Le vendredi 03 septembre 2010 20:07:54, Georg Brandl a écrit : Please add a versionadded tag. Oh no, I always forget this one. Done in r84475. -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84430 - in python/branches/py3k: Include/unicodeobject.h Objects/unicodeobject.c
Le samedi 04 septembre 2010 00:02:59, Georg Brandl a écrit : What about Py_UNICODE_strcat? If it remains, it needs to be documented as well. There is already an issue for that: http://bugs.python.org/issue8649 -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C API doc question
Am 03.09.2010 13:44, schrieb Nick Coghlan: On Fri, Sep 3, 2010 at 9:19 PM, Amaury Forgeot d'Arc amaur...@gmail.com wrote: 2010/9/3 Nick Coghlan ncogh...@gmail.com: 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? This information is in the file: Doc/data/refcounts.dat There is a extension to sphinx that reads this file and generates the annotation in the documentation. This file is not very well known, even by core developers... Nope, never knew it existed until just now :) Since it does exist, how hard would it be to get the extension to emit a warning if a C API function isn't listed in that file, or if a function listed in that file doesn't appear anywhere in the docs? Currently it appears to default to reporting no effect on references if a function isn't mentioned, which is potentially misleading (as the above examples show, this file completely missed out on the PyString-PyUnicode rename). From a more wish-list point of view, how hard would it be to modify the extension to support having this markup inline with the function documentation rather than having it off in a separate file? Or addressing Skip's comment by allowing -0 to indicate cases where item references are stolen? I created http://bugs.python.org/issue9755 to cover these questions. Thanks, I will handle that at some point; I intended to overhaul the refcounting extension anyway, and add data for the missing functions. Georg -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.2 What's New
Hi, I'm not sure what the arrangement for the What's New in Python 3.2 document is; especially if either Andrew or Raymond still feel in charge for it. For this weekend's 3.2a2, it would be rather nice to have some more coverage of changes in the document, since it is the main thing people will look at when determining whether to download and test the alpha. You'll have about 1.4 days to commit changes yourself; I'll freeze the branch on early Sunday morning UTC. Thanks, Georg -- 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.2 What's New
On Sep 3, 2010, at 3:52 PM, Georg Brandl wrote: Hi, I'm not sure what the arrangement for the What's New in Python 3.2 document is; especially if either Andrew or Raymond still feel in charge for it. I'm already working on it. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.2 What's New
Le samedi 04 septembre 2010 00:52:38, Georg Brandl a écrit : For this weekend's 3.2a2, it would be rather nice to have some more coverage of changes in the document, since it is the main thing people will look at when determining whether to download and test the alpha. About unicode, Python 3.2 has a better support of undecodable strings, especially filenames (PEP 383): - bytes version of os.environ: os.environb and os.getenvb() - better support of undecodable data, eg. in tarfile, pickle, bz2 and subprocess - os.exec*() and subprocess.Popen() accept bytes arguments - mbcs encoding (default Windows encoding) is not more strict, eg. don't encode Ł as L in codepage 1252 I have a list of the related issues, do you need it? -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
