[issue2940] Building Python fails on SunOS
Adrian M [EMAIL PROTECTED] added the comment: Also, please check: http://bugs.python.org/issue1544306 (exactly the same issue that has just been closed because of the lack of feedback from the original reporter) Here is another (old) report referring to the very same issue happening on Solaris: http://bugs.python.org/issue1234473 (an issue that doesn't seem to be solved) I have no idea whether this is a real Python bug or not. I'm just reporting a build issue that I'm experiencing when trying to compile python on this particular (non-typical) platform. So, I have the access to this SunOS machine and the you (the Python developers) have the knowledge. Let's just work together and try to discover why the building process is not working out-of-the-box on SunOS, rather that imply that it's not a real python bug. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2940 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2891] urllib not handling ftp servers that do not support REST
daggett [EMAIL PROTECTED] added the comment: ok, I've chatted IRC with some Python devs on #python and it seems that it's a python-urlgrabber (yum package manager) issue so I'll reassign my redhat bug report. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2891 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2948] Unicode support for hashing algorithms
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: On 2008-05-23 05:38, Raymond Hettinger wrote: Raymond Hettinger [EMAIL PROTECTED] added the comment: I don't think this is the right thing to do. The hash algorithms are defined in terms of bytes, but Unicode is an abstracted from a byte level encoding. It doesn't make sense to convert using an arbitrary encoding (such as UTF-8) because someone else might hash the same text using a different encoding. Marc, do you concur? Yes. While we could fix an encoding to use for converting Unicode to bytes, e.g. UTF-8, you clearly want hash functions to be portable across platforms, programming languages and implementations. Other languages or implementations might choose UTF-16 or some other encoding, so it's not clear which encoding to choose and there doesn't seem to be a standard for this either. -1 on the idea. Martin already closed and rejected the idea for me. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 23 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2948 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue643841] New class special method lookup change
Nick Coghlan [EMAIL PROTECTED] added the comment: Specialised? What's specialised about it? It's designed to serve as a replacement for the simple delegation use cases that are currently met quite adequately by classic classes, since those are no longer available in 3.0. Tracker [EMAIL PROTECTED] http://bugs.python.org/issue643841 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue643841] New class special method lookup change
Nick Coghlan [EMAIL PROTECTED] added the comment: As to the rationale for having it in the standard library: it's because of the coupling with the implementation of the type() builtin. If a new slot is added to type() that the interpreter may access without consulting __getattribute__, then ProxyMixin can be updated to correctly delegate that slot. If alternate implementations such as Jython or IronPython have additional such slots, they can also provide their own version of ProxyMixin. If ProxyMixin doesn't become the development responsibility of the same group that is responsible for the implementation of the type object then it may as well not exist (since it can't be trusted to be kept up to date with the development process). Tracker [EMAIL PROTECTED] http://bugs.python.org/issue643841 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2663] shutil.copytree glob-style filtering [patch]
Georg Brandl [EMAIL PROTECTED] added the comment: Hi Tarek, here's a review: * The new docs are not very clear about ignore_patterns being a function factory. E.g.: The callable must return a list of folder and file names relative to the path, that will be ignored in the copy process. :func:`ignore_patterns` is an example of such callable. Rather, the *return value* of ignore_patterns is an example of such a callable. * The new docs should also note that copytree is called recursively, and therefore the ignore callable will be called once for each directory that is copied. * Instead of path and its elements the terminology should be directory and the list of its contents, as returned by os.listdir(). Likewise, folder should be directory. * The second new example makes me wonder if *ignore* is the correct name for the parameter. Is *filter* better? * A nit; the signature should be copytree(src, dst[, symlinks[, ignore]]). * The patch adds a space in the definition of rmtree(). -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2663 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2904] Cross-referencing to a method using an alternate title don't work with add_function_parentheses=True
Georg Brandl [EMAIL PROTECTED] added the comment: You're right; I'll fix this ASAP. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2904 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller [EMAIL PROTECTED] added the comment: That's a great idea. Just before doing a C library function call, ctypes would copy this variable into the real C-level errno; and Is the ctypes.set_errno(...) function really needed? Wouldn't it be sufficient if errno is simply set to zero before each function call? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2949] Windows installer doesn't include OpenSSL license and notice
New submission from Marc-Andre Lemburg [EMAIL PROTECTED]: The _ssl module is built against OpenSSL. Since I couldn't find any OpenSSL DLLs in my Python install dir and due to the size of the _ssl.pyd, I assume that it is statically linked against OpenSSL. That's all fine, but then I'm missing the OpenSSL license and attribution notice somewhere in the installer, the README of the installation or elsewhere. The download page should also include a hint that the Windows installer does include crypto software, since in some countries it is illegal to download and/or use crypto software, see e.g. http://rechten.uvt.nl/koops/cryptolaw/cls-sum.htm -- components: Build, Installation, Windows messages: 67228 nosy: lemburg severity: normal status: open title: Windows installer doesn't include OpenSSL license and notice versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2949 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2872] Remove commands for PEP 3108
Quentin Gallet-Gilles [EMAIL PROTECTED] added the comment: Ok, here are the patches. Since it's a combination of renaming and removing, I had to improvize a little, particularly in the 2.6 documentation. Hope it's done correctly. I still have doubts about the following issue, as commented in test_commands.py : # The module says: # NB This only works (and is only relevant) for UNIX. # # Actually, getoutput should work on any platform with an os.popen, but # I'll take the comment as given, and skip this suite. I played it safe as well and didn't change the platform test (both in trunk/test_py3kwarn and py3k/test_subprocess). Should this restriction remain ? -- keywords: +patch Added file: http://bugs.python.org/file10412/remove_commands.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2872 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2872] Remove commands for PEP 3108
Quentin Gallet-Gilles [EMAIL PROTECTED] added the comment: Ok, here are the patches. Since it's a combination of renaming and removing, I had to improvise a little (particularly in the 2.6 documentation). Hope it's done correctly. I still have doubts about the following issue. As commented in test_commands.py: # The module says: # NB This only works (and is only relevant) for UNIX. # # Actually, getoutput should work on any platform with an os.popen, but # I'll take the comment as given, and skip this suite. I also decided to play it safe and didn't change the test (both in trunk/test_py3kwarn and py3k/test_subprocess). Should this restriction remain? Added file: http://bugs.python.org/file10413/remove_commands.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2872 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2872] Remove commands for PEP 3108
Changes by Quentin Gallet-Gilles [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10412/remove_commands.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2872 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2872] Remove commands for PEP 3108
Quentin Gallet-Gilles [EMAIL PROTECTED] added the comment: Sorry for the double post Added file: http://bugs.python.org/file10414/commands_2.6.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2872 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2949] Windows installer doesn't include OpenSSL license and notice
Martin v. Löwis [EMAIL PROTECTED] added the comment: Would you like to work on a patch? -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2949 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2872] Remove commands for PEP 3108
Changes by Quentin Gallet-Gilles [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10415/commands_import_fixer.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2872 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Martin v. Löwis [EMAIL PROTECTED] added the comment: I also think that there should be explicit set_errno/get_errno calls. If you are interfacing to C, things should be as they are in C, i.e. you have to explicitly set errno to zero if you want to read it afterwards in a reliable manner (unless you can find out whether an error occurred by different means, e.g. a -1 return value - which is fairly common). -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Quentin Gallet-Gilles [EMAIL PROTECTED] added the comment: While working on the commands module removal, I found two missed import renaming in the py3k branch that made regrtest skip some tests. The attached patch corrects them. Added file: http://bugs.python.org/file10416/import_renames_py3k.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2949] Windows installer doesn't include OpenSSL license and notice
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: On 2008-05-23 14:32, Martin v. Löwis wrote: Martin v. Löwis [EMAIL PROTECTED] added the comment: Would you like to work on a patch? No - I don't know anything about the Windows MSI installer for Python. Just wanted to bring the obvious breach of the OpenSSL license to your attention. -- title: Windows installer doesn't include OpenSSL license and notice - Windows installer doesn't include OpenSSL license andnotice __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2949 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2950] silly readline module problem
New submission from Andy Novocin [EMAIL PROTECTED]: I installed python 2.5.2 on my SUSE 10.3 system which came with 2.4.4 and when you type import readline it returns No module named readline. When installing I just unzipped, ./configure, make, sudo make install. Im brand new to Linux and Python (probably clearly). -- components: Extension Modules messages: 67236 nosy: AndyNovo severity: normal status: open title: silly readline module problem versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2950 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller [EMAIL PROTECTED] added the comment: But would it hurt to set errno to zero before *any* function call? My experiments show that it is faster to clear errno always instead of trying to get a previously set value from tls storage in a ctypes-global object created by calling threading.local(). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Martin v. Löwis [EMAIL PROTECTED] added the comment: People might get confused that errno is modified without reason. I don't understand the need for the TLS, either - can't you just read and write the true errno (which will also be thread-local)? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller [EMAIL PROTECTED] added the comment: This does not work because Python can run arbitrary code, even in the same thread, between the call to a function in a shared library and the call to get_errno(). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2940] Building Python fails on SunOS
Martin v. Löwis [EMAIL PROTECTED] added the comment: Please take a look at the config.log, and locate the lines In file included from /usr/GNU/lib/gcc-lib/sparc-sun-solaris2.4/2.6.3/include/time.h:90, from /usr/include/sys/time.h:418, from /usr/include/sys/termios.h:23, from /usr/include/sys/termio.h:13, from /usr/include/termio.h:13, from /usr/GNU/lib/gcc-lib/sparc-sun-solaris2.4/2.6.3/include/curses.h:48, from conftest.c:47: /usr/include/sys/siginfo.h:74: parse error before `pthread_attr_t' Then please take a look at line 90 of /usr/GNU/lib/gcc-lib/sparc-sun-solaris2.4/2.6.3/include/time.h and confirm that it indeed includes siginfo.h at that line. Then please compare /usr/include/time.h with /usr/GNU/lib/gcc-lib/sparc-sun-solaris2.4/2.6.3/include/time.h and report any differences that you see. To me, it seems that your compiler's header files don't match your system's header files. This is not surprising, as gcc 2.6.3 was released in 1994, years before Solaris 9 was released; your gcc was build for Solaris 2.4. You probably need to run fixincludes again (i.e. rebuild gcc for your system), or install a newer version of gcc entirely. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2940 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Martin v. Löwis [EMAIL PROTECTED] added the comment: Can you please file a contributor agreement? This would be a prerequisite for including the module. Also, is there any progress on the open issues? I really would like to see a single zip file that unpacks on top of the Python tree, replaces the turtle module, and works just fine in all respects out of the box. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1513695 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2111] mmap segfaults when trying to write a block opened with PROT_READ
Martin v. Löwis [EMAIL PROTECTED] added the comment: Committed to 2.5 as r63561 -- status: pending - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2111 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Maciek Fijalkowski [EMAIL PROTECTED] added the comment: On the one hand, no it does not hurt when we're resetting errno before any call. On the other hand if we try hard to be like C, it's a bit strange that we always reset errno (which is on the other hand very good practice anyway). IMO it's fine to reset errno before any call, until someone can find example where it's not good. Cheers, fijal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Martin v. Löwis [EMAIL PROTECTED] added the comment: Alan, it appears that the patch doesn't apply anymore, in r63553. Can you please update it? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1622 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1622] zipfile hangs on certain zip files
Alan McIntyre [EMAIL PROTECTED] added the comment: Sure, I'll look at it later today or over the weekend. I should probably break out the parts that apply to other issues and update those patches as well. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1622 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX 6
Martin v. Löwis [EMAIL PROTECTED] added the comment: Thanks for the patch. Committed as r63562. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue175 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1390] toxml generates output that is not well formed
Martin v. Löwis [EMAIL PROTECTED] added the comment: Thanks for the patch. Committed as r63563. Because of the new exception, I won't backport the change to 2.5. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2871] store thread.get_ident() thread identifier inside threading.Thread objects
Antoine Pitrou [EMAIL PROTECTED] added the comment: Currently, when creating a new Thread object, there is no good way of getting that thread's get_ident() value. Well, how about doing it at the beginning of its run() method, e.g. in a Thread subclass: class MyThread(threading.Thread): def run(self): self.thread_ident = thread.get_ident() threading.Thread.run(self) # or any other stuff Also, I don't think get_ident() is often useful when using the Threading module, since you can just use the id() of the current Thread object instead. -- nosy: +pitrou __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2871 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Martin v. Löwis [EMAIL PROTECTED] added the comment: How can Python run arbitrary code between the return from a ctypes method and the next Python instruction? None of the code should have any effect on errno. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller [EMAIL PROTECTED] added the comment: How can Python run arbitrary code between the return from a ctypes method and the next Python instruction? None of the code should have any effect on errno. By freeing objects because their refcount has reached zero? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2799] Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
Martin v. Löwis [EMAIL PROTECTED] added the comment: I don't agree that PyUnicode_AsString is useless. There are many cases where you don't need the length of the string, e.g. when relying on NULL termination when passing stuff to some C library. I suggest to close this report as works for me. As for the unrelated issue of PyUnicode_AsStringAndSize: AFAICT, PyString_AsStringAndSize doesn't support Unicode objects (and IMO shouldn't, either). Making PyUnicode_AsStringAndSize and PyString_AsStringAndSize similar is probably a good idea. -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2799 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Armin Rigo [EMAIL PROTECTED] added the comment: I'm in favor of keeping set_errno(). Not only is it more like C, but it's also future-proof against a user that will end up really needing the feature. If we go for always setting errno to zero, we cannot change that later any more, because everybody's code will rely on it. (An example of possible usage of set_errno(): the user might need to save and restore the value around a subfunction call that may call more C function via ctypes.) I personally don't care if this means a few percents of performance loss; I don't see how ctypes can be performance-critical in the first place given its huge overhead compared to e.g. rewriting the code in C. I imagine that the same approach could work with GetLastError() on Windows. (But is there a SetLastError() on Windows?) Using the native errno instead of a custom TLS value is bad because a lot of things can occur; for example, adding debugging prints or a pdb breakpoint between the function return and the call to get_errno() is very likely to end up overwriting the C-level errno value. For all I know, on some platforms errno could even be overwritten by the calls to the unlock/lock operation that CPython does at regular intervals in order to let other threads run. (For example I can easily imagine that GetLastError() is overridden by the lock/unlock operations on Windows.) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2909] struct.Struct.unpack to return a namedtuple for easier attribute access
Raymond Hettinger [EMAIL PROTECTED] added the comment: Added example to docs. See r63564. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2909 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Martin v. Löwis [EMAIL PROTECTED] added the comment:
How can Python run arbitrary code between the return from a ctypes
method and the next Python instruction? None of the code should have any
effect on errno.
By freeing objects because their refcount has reached zero?
No, that should not set errno. Free cannot fail, and will not modify
errno. Try running
#include errno.h
int main()
{
errno = 117;
free(malloc(100));
printf(%d\n, errno);
}
malloc might set errno, but only if it fails (in which case you'll get
a Python exception, anyway).
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1798
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Martin v. Löwis [EMAIL PROTECTED] added the comment: [...] Using the native errno instead of a custom TLS value is bad because a lot of things can occur So what's the semantics of set_errno then? Set the real errno? If so, what if it gets changed between the call to set_errno, and the actual invocation of API function? Set the TLS errno? If so, when does it get copied into the real errno? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller [EMAIL PROTECTED] added the comment:
Using the native errno instead of a custom TLS value is bad because a
lot of things can occur
So what's the semantics of set_errno then? Set the real errno? If so,
what if it gets changed between the call to set_errno, and the actual
invocation of API function? Set the TLS errno? If so, when does it get
copied into the real errno?
AFAIU, set_errno/get_errno should provide a ctypes-private copy of the real
errno.
The copy is copied into the 'real' errno just before ffi_call (in
Modules/_ctypes/callproc.c),
and the real errno is copied in to ctypes copy right after the call.
Probably the real errno from before this action should be restored at the end.
Code that I have in mind:
__thread int _ctypes_errno; /* ctypes-private global error number in thread
local storage */
static int _call_function_pointer(...)
{
int old_errno;
.
.
old_errno = errno;
errno = _ctypes_errno;
ffi_call();
_ctypes_errno = errno;
errno = old_errno;
.
.
}
static PyObject *
_ctypes_set_errno(PyObject *self, Pyobject *args)
{
.
_ctypes_errno = parsed_argument;
.
}
static PyObject *
_ctypes_get_errno(PyObject *self, Pyobject *args)
{
return PyInt_FromLong(_ctypes_errno);
}
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1798
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue643841] New class special method lookup change
Adam Olsen [EMAIL PROTECTED] added the comment: Surely remote proxies fall under what would be expected for a proxy mixin? If it's in the stdlib it should be a canonical implementation, NOT a reference implementation. At the moment I can think up 3 use cases: * weakref proxies * lazy load proxy * distributed object The first two could be done if _deref were made overridable. The third needs to turn everything into a message, which would could either do directly, or we could do by turning everything into normal method lookups which then get handled through __getattribute__. Tracker [EMAIL PROTECTED] http://bugs.python.org/issue643841 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2946] setuptools: bdist_wininst adds duplicate entry to dist_files
Hartmut Goebel [EMAIL PROTECTED] added the comment: Yes. I've coincidently found the setptools bugtracker today and filed a bug-report there. Please Close. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2946 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2951] ElementTree parsing bus error (but only from mod_python)
New submission from Kathy Van Stone [EMAIL PROTECTED]: The follow code works fine when run directly. It crashes (with a bus error) if used as a mod_python handler. It doesn't crash if ElementTree is replaced with cElementTree. from xml.etree import ElementTree as eltree def handler(req): body = ?xml version='1.0' encoding='utf-8'? collection uuid=~01edc22c1628e711ddb20220296b032019 href=http://localhost:/ws/dataset/~01edc22c1628e711ddb20220296b032019; nameService_offerings query at 2008-05-23 12:47:28.038233/name /collection response_elem = eltree.XML(body) return 0 I don't know if this a mod_python or ElementTree issue, but it looks more like an ElementTree problem. -- components: Library (Lib), Macintosh messages: 67259 nosy: kathyvs severity: normal status: open title: ElementTree parsing bus error (but only from mod_python) type: crash versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2951 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Martin v. Löwis [EMAIL PROTECTED] added the comment: AFAIU, set_errno/get_errno should provide a ctypes-private copy of the real errno. The copy is copied into the 'real' errno just before ffi_call (in Modules/_ctypes/callproc.c), and the real errno is copied in to ctypes copy right after the call. If you clear errno, anyway, you can also drop the set_errno call, and zero-initialize errno before each call. The point of set_errno would be that you have the choice of *not* calling it, i.e. passing into the function the errno value that was there before you made the API call. If you fill something else into errno always, the application has no way of not modifying errno before the API call. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2946] setuptools: bdist_wininst adds duplicate entry to dist_files
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- resolution: - invalid status: open - closed versions: +3rd party -Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2946 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2952] List comprehensions are leaking variables
New submission from Ismail Donmez [EMAIL PROTECTED]:
Originally found at
http://www.randombit.net/weblog/programming/variable_leak_in_list_compre
hensions.html
First example :
[~] python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
x=1
[x for x in [1,2,3]]
[1, 2, 3]
x
3
whoops x changed.
Another example from original post:
$ python
Python 2.4.4 (#1, Mar 7 2008, 14:54:19)
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2
Type help, copyright, credits or license for more information.
x = { 1:2, 3:4 }
nothere
Traceback (most recent call last):
File , line 1, in ?
NameError: name 'nothere' is not defined
[nothere for nothere in x.keys()]
[1, 3]
nothere
3
This bug doesn't seem to affect py3k but it does python 2.4/2.5. Either
this should be fixed or documented as a caveat.
--
components: Library (Lib)
messages: 67261
nosy: cartman
severity: normal
status: open
title: List comprehensions are leaking variables
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2952
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2952] List comprehensions are leaking variables
Changes by Ismail Donmez [EMAIL PROTECTED]: -- components: +Interpreter Core -Library (Lib) type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2952 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2952] List comprehensions are leaking variables
Martin v. Löwis [EMAIL PROTECTED] added the comment: The behaviour is documented, e.g. in footnote 5.1 of http://docs.python.org/ref/lists.html It is fixed in Python 3. -- nosy: +loewis resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2952 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2952] List comprehensions are leaking variables
Ismail Donmez [EMAIL PROTECTED] added the comment: But it only mentions python 2.3, time to update the footnote. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2952 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2952] List comprehensions are leaking variables
Martin v. Löwis [EMAIL PROTECTED] added the comment: This is now fixed in r63569 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2952 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller [EMAIL PROTECTED] added the comment: AFAIU, set_errno/get_errno should provide a ctypes-private copy of the real errno. The copy is copied into the 'real' errno just before ffi_call (in Modules/_ctypes/callproc.c), and the real errno is copied in to ctypes copy right after the call. If you clear errno, anyway, you can also drop the set_errno call, and My code sample did not intend to clear errno, it was intended to set errno to the last value that the ctypes-copy had before the call. zero-initialize errno before each call. The point of set_errno would be that you have the choice of *not* calling it, i.e. passing into the function the errno value that was there before you made the API call. If you fill something else into errno always, the application has no way of not modifying errno before the API call. To make my point clear (in case is isn't already): In the code sample that Armin posted, it is impossible to guarantee that no stdlib function is called between the readdir() and the get_errno() call: dirent = linux_c_lib.readdir(byref(dir)) if not dirent: if ctypes.get_errno() == 0: Consider the garbage collector free some objects that release resources they have, in other words call functions different from free(3). Similarly for calling set_errno() or not calling it; other stdlib function calls in the meantime may have changed errno and that might not be what the Python programmer expects. Anyway, how can we proceed? Do you have a suggestion? Should set_errno() set a flag that is examined and consumed before call_function_pointer() is called? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Martin v. Löwis [EMAIL PROTECTED] added the comment: My code sample did not intend to clear errno, it was intended to set errno to the last value that the ctypes-copy had before the call. It's the same thing (to me): you change errno. To make my point clear (in case is isn't already): In the code sample that Armin posted, it is impossible to guarantee that no stdlib function is called between the readdir() and the get_errno() call: dirent = linux_c_lib.readdir(byref(dir)) if not dirent: if ctypes.get_errno() == 0: Consider the garbage collector free some objects that release resources they have, in other words call functions different from free(3). However, even the TLS copy of errno may change because of this, if the finalizer of some object invokes ctypes, right? Anyway, how can we proceed? Do you have a suggestion? I'll leave it up to you to decide - you'll take both blame and praise, anyway, so I don't want to talk you into coming up with an API that you don't like. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2953] _zip_directory_cache untested and undocumented
New submission from Maciek Fijalkowski [EMAIL PROTECTED]: _zip_directory_cache has no single test nor piece of documentation. The only place where it's mentioned is a call to method .clear() on it in tests. Besides, it can be whatever. Despite _ prefix, which I would consider to be private, distutils crash obscurely if it's not there or does not contain sequences as keys. -- assignee: georg.brandl components: Distutils, Documentation, Extension Modules messages: 67267 nosy: fijal, georg.brandl severity: normal status: open title: _zip_directory_cache untested and undocumented type: behavior versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2953 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2222] Memory leak in os.rename?
Changes by Hirokazu Yamamoto [EMAIL PROTECTED]: -- components: +Windows -Extension Modules __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Fri, May 23, 2008 at 7:49 AM, Quentin Gallet-Gilles [EMAIL PROTECTED] wrote: Quentin Gallet-Gilles [EMAIL PROTECTED] added the comment: While working on the commands module removal, I found two missed import renaming in the py3k branch that made regrtest skip some tests. The attached patch corrects them. The test_tcl one was fixed in 2.6 (when we were renaming) and will be merged into Py3k. I will catch the test_1413192.py. Thanks! Added file: http://bugs.python.org/file10416/import_renames_py3k.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2775 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2663] shutil.copytree glob-style filtering [patch]
Tarek Ziadé [EMAIL PROTECTED] added the comment: Thanks Georg, I have changed the patch accordingly. There's one issue left: the name of the parameter (ignore) I have renamed it like this on Alexander suggestion, for consistency with filecmp.dircmp which uses ignore. By the way, I was wondering: do we need to used reStructuredText as well in function doctstrings ? Added file: http://bugs.python.org/file10417/copytree.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2663 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2663] shutil.copytree glob-style filtering [patch]
Changes by Tarek Ziadé [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10392/copytree2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2663 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Steve Baker [EMAIL PROTECTED] added the comment: I'm also hitting this problem. I'm including a demo script. The minimal condition for me to reproduce this bug is that the subject contain at least 76 characters of any kind, followed by a space, followed by at least 3 characters of any kind. -- nosy: +splorgdar Added file: http://bugs.python.org/file10418/test __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1974 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Changes by Steve Baker [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10419/test.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1974 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Changes by Steve Baker [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10418/test __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1974 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2954] [PATCH] Make bisect module functions accept an optional comparison callable
New submission from Leandro Lucarella [EMAIL PROTECTED]: bisect module functions should accept a comparison callable to customize the way items are compared to do the binary search. Attached is a patch to the Python implementation of bisect module. -- components: Library (Lib) files: bisect.py.cmp.patch keywords: patch messages: 67271 nosy: llucax severity: normal status: open title: [PATCH] Make bisect module functions accept an optional comparison callable type: feature request versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file10420/bisect.py.cmp.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2954 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2954] [PATCH] Make bisect module functions accept an optional comparison callable
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- assignee: - rhettinger nosy: +rhettinger versions: +Python 3.0 -Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2954 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2538] memoryview of bytes is not readonly
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- priority: - critical type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2538 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2538] memoryview of bytes is not readonly
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- nosy: +benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2538 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2619] Document PEP 3118
Benjamin Peterson [EMAIL PROTECTED] added the comment: Upon further inspection, it seems none of the new buffer protocol is documented. (The old functions are still present in the 3.0 docs.) -- title: Document memoryview - Document PEP 3118 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2619 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2871] store thread.get_ident() thread identifier inside threading.Thread objects
Irmen de Jong [EMAIL PROTECTED] added the comment: Adding it in the run method would only work for threads that I create in my own code. The thing is: I need to be able to get the tread identification from threads created by third party code. So I cannot rely on that code putting it in the thread object themselves like that. Hence my wish of letting the standard library module take care of it. And using the id() of the current thread object has a rather obscure problem. I was using it as a matter of fact, until people reported problems in my code when used with certain atexit handling. (Sometimes the wrong id() is returned). Because of that I wanted to switch to the more low-level thread.get_ident() identification of different threads, because that is supposed to return a stable os-level thread identification, right? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2871 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2926] Revert SocketServer rename in 2.6
Brett Cannon [EMAIL PROTECTED] added the comment: I am attaching a patch that (should) revert all references to socketserver back to SocketServer. Because I am on OS X I can't do the actual ``svn rename`` on Lib/socketserver.py to Lib/SocketServer.py so someone else (PLEASE!) will need to do the ``svn rename`` apply the patch, run the test suite, and then commit. -- keywords: +patch Added file: http://bugs.python.org/file10421/revert_socketserver.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2926 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue643841] New class special method lookup change
Nick Coghlan [EMAIL PROTECTED] added the comment: The way to override _deref/_unwrap is to make _target a property on a ProxyMixin subclass (which reminds me, I want to put in an explicit test case to make sure that works as intended - I'll use the weakref-proxy-in-Python as the example, so I'll also need to fix the docs to indicate that such a thing doesn't actually require rewriting the whole class). And there are a lot more use cases than just the ones you listed, primarily in the area of interface adaptation (i.e. the programmer just wants to fiddle with the visible API of the object a bit, rather than doing anything clever with the way the proxy's target is referenced). The reason I'm wary of attempting to provide direct support for the distributed communications use case, is that distributed computing needs to deal with all sorts of issues in relation to serialisation and transport of arguments and return values, that a local proxy of any kind simply doesn't have to deal with (since it can just pass direct references around). Note that merely diverting everything through __getattribute__ isn't even close to enough, due to the argument and return value transport problem - the RPC mechanism needs to understand the methods that are being invoked as well. So I'm quite happy leaving all those issues to tools that are actually designed to handle them (CORBA, XML-RPC, etc). Tracker [EMAIL PROTECTED] http://bugs.python.org/issue643841 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2925] Revert Queue rename in 2.6
Brett Cannon [EMAIL PROTECTED] added the comment: r63248 contains various import and docs changes done in the name of configparser. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2925 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2923] Revert ConfigParser rename in 2.6
Brett Cannon [EMAIL PROTECTED] added the comment: r63248 contains various import and doc changes in the name of configparser. r63242 contains the rename, but ``svn rename`` should be used in order to not lose the history on the file. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2923 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2923] Revert ConfigParser rename in 2.6
Brett Cannon [EMAIL PROTECTED] added the comment: r63247 has some doc changes. r63249 added the old name stub. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2923 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2888] pprint produces different output in 2.6 and 3.0
Manuel Kaufmann [EMAIL PROTECTED] added the comment: If the correct way is the first option, we can use this patch to solve that error. I attached diff file. I use Lib/test/test_pprint.py to ensure that's works. -- keywords: +patch nosy: +humitos Added file: http://bugs.python.org/file10422/pprint.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2888 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2950] silly readline module problem
Buck Golemon [EMAIL PROTECTED] added the comment: I'm not sure what your problem is, but comp.lang.python might be a better place to ask. It's not clear that this is a bug yet. http://groups.google.com/group/comp.lang.python/topics -- nosy: +bgolemon __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2950 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1858] Make .pypirc handle multiple servers
Martin v. Löwis [EMAIL PROTECTED] added the comment: This patch has broken test_distutils, which now reports test_distutils test test_distutils produced unexpected output: ** Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc ** -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1858 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
