[issue34602] python3 resource.setrlimit strange behaviour under macOS
Jean-Paul Calderone added the comment: My understanding of the resolution of this ticket is that it is still not possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit. Is that correct? In that case, the original bug report still seems valid and unresolved (and indeed, I am porting a project from Python 2.7 to Python 3.9 and on macOS it fails because it cannot raise the stack limit). -- nosy: +exarkun ___ Python tracker <https://bugs.python.org/issue34602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598083] Top-level exception handler writes to stdout unsafely
Jean-Paul Calderone added the comment: Not likely, given the number of things on my plate already. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1598083> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1147] string exceptions inconsistently deprecated/disabled
New submission from Jean-Paul Calderone: Python 2.5 deprecated raising string exceptions. It also added the throw method to generator objects which can be used to raise an exception, including a string exception. Raising an exception with this method doesn't issue a deprecation warning. It looks like Python 2.6 will remove string exceptions entirely. Current trunk still allows strings to be passed to the throw method of generators though, and raises the string exception, again without a deprecation warning. -- components: Interpreter Core messages: 55825 nosy: exarkun severity: normal status: open title: string exceptions inconsistently deprecated/disabled type: behavior versions: Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1147> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1325] zipimport.zipimporter.archive undocumented and untested
New submission from Jean-Paul Calderone: zipimporter instances have a read-only "archive" attribute, but there is no documentation referring to it, nor any test coverage for its existence. It's quite useful to know what a zipimporter is pointed at (for debugging and other introspection). It'd be nice to know that this is a real feature and isn't going to disappear. -- components: Documentation, Library (Lib) messages: 56741 nosy: exarkun severity: normal status: open title: zipimport.zipimporter.archive undocumented and untested type: rfe __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1325> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326] "internal" zipimport.zipimporter feature untested
New submission from Jean-Paul Calderone: It's possible to construct a zipimporter with a "path" which points first to a zip file and then continues to refer to a file within that zip file. For example, /foo/bar.zip/baz where /foo/bar.zip is not a directory, but a zip file, and baz is a file or directory in the contents of the zip file. There is no test coverage for this functionality, though. -- components: Library (Lib) messages: 56742 nosy: exarkun severity: normal status: open title: "internal" zipimport.zipimporter feature untested type: rfe __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1326> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1325] zipimport.zipimporter.archive undocumented and untested
Changes by Jean-Paul Calderone: -- nosy: +fijal __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1325> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326] "internal" zipimport.zipimporter feature untested
Changes by Jean-Paul Calderone: -- nosy: +fijal __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1326> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue805194] Inappropriate error received using socket timeout
Jean-Paul Calderone added the comment: The APR comment is indeed correct, so this is probably a Python bug. -- nosy: +exarkun Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue805194> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1367] mkdir+chdir problem in multiple threads
Jean-Paul Calderone added the comment: This isn't a bug in Python. Working directory, which os.chdir modifies, is process-global. One of your threads makes a directory, then gets suspended while another one makes a different directory and changes into it, then the first tries to change into its directory and fails. -- nosy: +exarkun __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1367> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12944] Accept arbitrary files for packaging's upload command
Jean-Paul Calderone added the comment: > pysetup run upload -f dist/spam-0.2.tar.gz -f dist/spam-0.2.exe I'm not sure why it's "run upload" instead of just "upload", but maybe that's the convention in pysetup. Apart from that, this looks like a vast improvement to me. As far as not supporting globs goes, I guess I don't really care either way. If globs aren't supported, then I'll probably end up globbing somewhere else (or constructing the full upload list in some other automated way). The motivation for the complaint is that too many things require manual interaction; I'm not going to use a new, easily automated utility manually. :) -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue12944> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13556] When tzinfo.utcoffset is out-of-bounds, the exception message is misleading
New submission from Jean-Paul Calderone : When a timezone produces an out-of-bounds utc offset, the resulting exception always claims that the offset was 1440, rather than whatever it was. Example: from datetime import timedelta, datetime, tzinfo class X(tzinfo): def utcoffset(self, time): return timedelta(days=2) datetime.now(tz=X()) -- components: Library (Lib) messages: 149046 nosy: exarkun priority: normal severity: normal status: open title: When tzinfo.utcoffset is out-of-bounds, the exception message is misleading type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13556> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12443] locale.setlocale(locale.LC_ALL, locale.getlocale()) fails for some locales
New submission from Jean-Paul Calderone :
Consider this transcript from OS X 10.6:
>>> import locale
>>> locale.getlocale()
(None, None)
>>> locale.setlocale(locale.LC_ALL, _)
'C'
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
>>> locale.getlocale()
('en_US', 'UTF8')
>>> locale.setlocale(locale.LC_ALL, _)
Traceback (most recent call last):
File "", line 1, in
File
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/locale.py",
line 494, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>>
OS X does not recognize 'en_US.UTF8', only 'en_US.UTF-8'. However, when passed
a tuple, the locale module tries to normalize the values. It ends up turning
the result of getlocale from ('en_US', 'UTF-8') into 'en_US.UTF8'.
--
assignee: ronaldoussoren
components: Extension Modules, Library (Lib), Macintosh
messages: 139445
nosy: exarkun, ronaldoussoren
priority: normal
severity: normal
status: open
title: locale.setlocale(locale.LC_ALL, locale.getlocale()) fails for some
locales
type: behavior
versions: Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/issue12443>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Jean-Paul Calderone added the comment: Since the main argument for not fixing this bug seems to be that it doesn't affect many users, it seems like I should comment here that the issue is affecting me. A recently proposed addition to Twisted gets bitten by this case, resulting in a report of less than full test coverage when in fact the tests do exercise every line and branch of the change. Perhaps it is too hard to add and maintain a no-optimizations feature for Python (although I agree with Ned that this would be a useful feature for many reasons, not just to fix this bug). There are other possible solutions to the issue of inaccurate coverage reports though. For example, Python could provide an API for determining which lines have code that might be executed. coverage.py (and the stdlib trace.py) currently use the code object's lnotab to decide which lines might be executable. Maybe that should omit "continue" lines that get jumped over. If the line will never execute, it seems there is no need to have it in the lnotab. Using the lnotab is something of a hack though, so it might also make sense to leave it alone but introduce an API to get the same information, but corrected for whatever peephole optimizations the interpreter happens to have. As far as the "not a bug" arguments go, I don't think it matters much whether you ultimately decide to call it a bug or a feature request. It *is* clearly a useful feature to some people though, and rejecting the requested behavior as "not a bug" doesn't help anyone. So call it a feature request if that makes it more palletable. :) -- nosy: +exarkun resolution: wont fix -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue2506> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11657] multiprocessing_{send,recv}fd fail with fds > 256
Jean-Paul Calderone added the comment: Thanks for the patch Petri. Are you interested in writing a unit test for this as well? -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue11657> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9053] distutils compiles extensions so that Python.h cannot be found
Jean-Paul Calderone added the comment: exar...@boson:~/Projects/python-signalfd/trunk$ PYTHONPATH= ~/Projects/python/branches/py3k/python setup.py build_ext -i running build_ext building 'signalfd._signalfd' extension creating build creating build/temp.linux-i686-3.2 creating build/temp.linux-i686-3.2/signalfd gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/exarkun/Projects/python/branches/py3k/Include -I/home/exarkun/Projects/python/branches/py3k -c signalfd/_signalfd.c -o build/temp.linux-i686-3.2/signalfd/_signalfd.o gcc -pthread -shared build/temp.linux-i686-3.2/signalfd/_signalfd.o -o /home/exarkun/Projects/python-signalfd/trunk/signalfd/_signalfd.so exar...@boson:~/Projects/python-signalfd/trunk$ -- ___ Python tracker <http://bugs.python.org/issue9053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9053] distutils compiles extensions so that Python.h cannot be found
Changes by Jean-Paul Calderone : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue9053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Jean-Paul Calderone added the comment: > I'll be looking at it shortly. Py3.2 is still aways from release so there is > no hurry. I would consider reviewing and possibly apply this change, but I don't want to invade anyone's territory. -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Changes by Jean-Paul Calderone : -- nosy: -exarkun ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9875] Garbage output when running setup.py on Windows
New submission from Jean-Paul Calderone : The output of setup.py is polluted with this log message: Importing new compiler from distutils.msvc9compiler on Windows. For example, using pyOpenSSL's setup.py, running "setup.py --version" produces this output: Importing new compiler from distutils.msvc9compiler 0.10 But the version number of pyOpenSSL is "0.10", not "Importing new compiler from distutils.msvc9compiler\n0.10". The --quiet flag does not solve this problem, apparently because this log message is done at the top-level of msvccompiler.py, perhaps before --quiet is interpreted. This interferes with my build automation which depends on "setup.py --version" producing the version number of the project in order to properly compute certain filenames. -- assignee: tarek components: Distutils messages: 116552 nosy: eric.araujo, exarkun, tarek priority: normal severity: normal status: open title: Garbage output when running setup.py on Windows type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue9875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9881] PySSL_SSLRead loops until data is available, even in non-blocking mode
New submission from Jean-Paul Calderone :
Here's a transcript which demonstrates the blocking behavior:
>>> import socket
>>> import time
>>> import ssl
>>> s = ssl.wrap_socket(socket.socket())
>>> s.connect(('localhost', 8443))
>>> s.send('GET /async.rpy HTTP/1.1\r\n\r\n')
27
>>> s.setblocking(False)
>>> a = time.time(); s.recv(1024); b = time.time()
'HTTP/1.1 200 OK\r\nTransfer-Encoding: chunked\r\nDate: Thu, 02 Sep 2010
11:51:03 GMT\r\nContent-Type: text/html\r\nServer:
TwistedWeb/10.1.0+r29954\r\n\r\n4c\r\nSorry to keep you
waiting.\r\n0\r\n\r\n'
>>> print b - a
4.13403391838
>>>
(This can be reproduced using any web server which is a bit slow in responding;
it's very obvious here because I used a server that intentionally waits several
seconds before generating a response).
--
components: Library (Lib)
messages: 116629
nosy: exarkun
priority: normal
severity: normal
status: open
title: PySSL_SSLRead loops until data is available, even in non-blocking mode
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue9881>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9881] PySSL_SSLread loops until data is available, even in non-blocking mode
Changes by Jean-Paul Calderone : -- title: PySSL_SSLRead loops until data is available, even in non-blocking mode -> PySSL_SSLread loops until data is available, even in non-blocking mode ___ Python tracker <http://bugs.python.org/issue9881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9881] PySSL_SSLread loops until data is available, even in non-blocking mode
Jean-Paul Calderone added the comment: Hm. I must have been testing with old versions, since I can't reproduce this now. Sorry for the noise. -- resolution: out of date -> duplicate status: pending -> closed ___ Python tracker <http://bugs.python.org/issue9881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9875] Garbage output when running setup.py on Windows
Jean-Paul Calderone added the comment: This seems to have been caused by an ill-placed distutils.log.set_verbosity(3) call. With that removed, this output isn't generated by default. So perhaps this is invalid, feel free to close it as so if you agree. -- ___ Python tracker <http://bugs.python.org/issue9875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Jean-Paul Calderone added the comment: How about nss? As a bonus, this would also avoid making more work for Fedora (<http://fedoraproject.org/wiki/FedoraCryptoConsolidation>). -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Jean-Paul Calderone added the comment: What it will bring: APIs which aren't absolutely insane; full SSL support; RSA, DSA, ECDSA, Diffie-Hellman, EC Diffie-Hellman, AES, Triple DES, DES, RC2, RC4, SHA-1, SHA-256, SHA-384, SHA-512, MD2, MD5, HMAC: Common cryptographic algorithms used in public-key and symmetric-key cryptography; simplified FIPS 140 validation; better licensing (MPL). I'm interested in stuff based on nss, but I definitely won't promise to do the work. Fortunately dmalcolm seems to be on top of that. :) -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Jean-Paul Calderone added the comment: > I should note that I can't touch anything to do with Elliptic Curve crypto. > I don't know if I can comment on the reasons for that. Hopefully anything ECC related can be done separately. There's certainly no ECC APIs in Python now, so there would be no loss of functionality if any new crypto-related APIs didn't include ECC. Later if someone is sufficiently interesting, they could add it to the base library. -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9090] Error code 10035 calling socket.recv() on a socket with a timeout (WSAEWOULDBLOCK - A non-blocking socket operation could not be completed immediately)
Jean-Paul Calderone added the comment: > Unfortunately, select doesn't necessarily update the timeout variable with > the remaining time, so we can't rely on this. This would mean having the > select enclosed within gettimeofday and friends, which seems a bit overkill... How is it "overkill" to be correct? -- ___ Python tracker <http://bugs.python.org/issue9090> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9953] 2 scripts running from crontab simultaneously reference the same instance of a variable
Jean-Paul Calderone added the comment: You can't rely on id() to return distinct values across different processes. It guarantees uniqueness *within a single process* (at any particular moment). In other words, you're misusing id() here. This is not a Python bug. -- nosy: +exarkun resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue9953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9961] Identity Crisis! variable assignment using strftime fails comparison test.
Jean-Paul Calderone added the comment: You mistakenly used "is" for these comparisons, rather than "==". The strftime involvement is a red herring. The real problem is the use of an /identity/ comparison rather than an /equality/ comparison. -- nosy: +exarkun resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue9961> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9966] platform : a boolean to know easily when a system is posix
Jean-Paul Calderone added the comment: It could, but why introduce this redundancy with `os.name`? -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue9966> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9994] Python becoming orphaned over ssh
Jean-Paul Calderone added the comment: fwiw http://mail.python.org/pipermail/python-list/2010-September/1256545.html -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue9994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10093] Warn when files are not explicitly closed
Jean-Paul Calderone added the comment: If the warnings are emitted as usual with the warnings module, you can use -W to control this. -X isn't necessary. -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue10093> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10169] socket.sendto raises incorrect exception when passed incorrect types
New submission from Jean-Paul Calderone :
>>> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> s.bind(('', 0))
>>> s.sendto(u'hellé', s.getsockname())
Traceback (most recent call last):
File "", line 1, in
TypeError: sendto() takes exactly 3 arguments (2 given)
>>> s.sendto(3, s.getsockname())
Traceback (most recent call last):
File "", line 1, in
TypeError: sendto() takes exactly 3 arguments (2 given)
>>> s.sendto('hello', s.getsockname())
5
The TypeError gives the wrong explanation for what's wrong.
--
components: Library (Lib)
messages: 119320
nosy: exarkun
priority: normal
severity: normal
status: open
title: socket.sendto raises incorrect exception when passed incorrect types
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue10169>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10377] cProfile incorrectly labels its output
New submission from Jean-Paul Calderone :
Consider this transcript:
>>> cProfile.run("import time; time.sleep(1)")
4 function calls in 1.012 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
10.0110.0111.0121.012 :1()
10.0000.0001.0121.012 {built-in method exec}
11.0011.0011.0011.001 {built-in method sleep}
10.0000.0000.0000.000 {method 'disable' of
'_lsprof.Profiler' objects}
>>>
It is not the case that the profiled code uses >1 CPU seconds. It spends the
entire time sleeping. The default timer for cProfile is a wallclock timer.
The output should reflect this.
--
messages: 120890
nosy: exarkun
priority: normal
severity: normal
status: open
title: cProfile incorrectly labels its output
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue10377>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11798] Test cases not garbage collected after run
Jean-Paul Calderone added the comment: Trial lets test cases get garbaged collected. When we noticed this wasn't happening, we treated it as a bug and fixed it. No one ever complained about the change. I don't see any obvious way in which an application would even be able to tell the difference (a user can tell the difference by looking at top). In what case do you think this change would result in broken application code? -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue11798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11798] Test cases not garbage collected after run
Jean-Paul Calderone added the comment: > I thought unittest was just handed a bunch of TestCase instances and couldn't > do much about insuring they were garbage collected. True. But unittest could ensure that it doesn't keep a reference to each TestCase instance after it finishes running it. Then, if no one else has a reference either, it can be garbage collected. -- ___ Python tracker <http://bugs.python.org/issue11798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11798] Test cases not garbage collected after run
Jean-Paul Calderone added the comment: Here's Trial's implementation: http://twistedmatrix.com/trac/browser/trunk/twisted/trial/runner.py#L138 -- ___ Python tracker <http://bugs.python.org/issue11798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12126] incorrect select documentation
New submission from Jean-Paul Calderone :
http://docs.python.org/py3k/howto/sockets.html#non-blocking-sockets
"And if you put a socket in more than one input list, it will only be (at most)
in one output list."
>>> import socket
>>> s = socket.socket()
>>> s.connect(('localhost', 22))
>>> import select
>>> select.select([s], [s], [])
([], [], [])
>>>
--
assignee: docs@python
components: Documentation
messages: 136350
nosy: docs@python, exarkun
priority: normal
severity: normal
status: open
title: incorrect select documentation
type: behavior
___
Python tracker
<http://bugs.python.org/issue12126>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10661] ElementTree QName has a very uninformative repr()
New submission from Jean-Paul Calderone :
This is somewhat unfortunate behavior:
>>> from xml.etree.ElementTree import QName
>>> QName('foo')
>>>
It becomes even more apparent when encountered in a situation like this:
>>> print {QName('foo'): 'bar', QName('baz'): 'quux'}
{: 'bar',
: 'quux'}
>>>
I would like to see QName.__repr__ return something like '' % (text,)
--
messages: 123687
nosy: exarkun
priority: normal
severity: normal
status: open
title: ElementTree QName has a very uninformative repr()
type: behavior
___
Python tracker
<http://bugs.python.org/issue10661>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10935] wsgiref.handlers.BaseHandler and subclasses of str
Jean-Paul Calderone added the comment: > Phillip, your argument about interfacing with code written in C doesn't work > for built-in immutable types like str. Sure it does. Definitely-str is easier to handle in C than maybe-str-subclass. It doesn't matter that str.__new__ gets called. Other things might get called too, with who-knows-what side-effects. wsgi is right to demand str and only str and exactly str. -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue10935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3051] heapq change breaking compatibility
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: The heapq documentation isn't very clear about its requirements. It does explicitly say that "Heaps are arrays for which heap[k] <= heap[2*k+1] and heap[k] <= heap[2*k+2] for all k, counting elements from zero." (this in the module reference for the heapq module, both in the Python 2.5 version and the in-development version) which might lead one to believe that <= (__le__) is the important operation. I don't know where it is documented that heapq behaves the same as sort(). I think the documentation needs some improvement to avoid this kind of confusion. It's very hard, often impossible, to know what is an "accidental and erroneous implementation detail" and what is a stable, public API. Also, I'm not sure why the code is being changed to accomodate newly written applications which never could have worked, breaking existing applications which did work, but I suppose that's just the decision CPython developers want to make. -- nosy: +exarkun ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3051> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3051] heapq change breaking compatibility
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: I tried this too and then wrote a couple unit tests for this. The one for the Python implementation which tests the case where only __le__ is defined fails, though. Diff attached. -- keywords: +patch Added file: http://bugs.python.org/file10582/test_heapq.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3051> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3051] heapq change breaking compatibility
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: Thanks for the explanation. Unfortunately, even if we change our code to work with the new requirements, all the old code is still out there. Maybe this doesn't matter, since there are so many other incompatibilities between Python 2.5 and Python 2.6. And there aren't many cases where the extension module isn't available, anyway. It will be surprising and probably hard to debug if anyone runs into this, but I suppose it's possible that no one will. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3051> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3211] warnings.warn_explicit raises SystemError
New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>:
Python 2.6b1+ (trunk:64531M, Jun 26 2008, 10:40:14)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn_explicit(None, UserWarning, None, 0, None, {})
None:0: UserWarning: None
>>> warnings.warn_explicit(None, UserWarning, None, 0, None, None)
Traceback (most recent call last):
File "", line 1, in
SystemError: Objects/dictobject.c:677: bad argument to internal function
>>>
--
components: Library (Lib)
messages: 68791
nosy: exarkun
severity: normal
status: open
title: warnings.warn_explicit raises SystemError
versions: Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3211>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3383] ctypes.util fails to find libc in some environments
New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>: ctypes.util assumes several things of its environment which sometimes don't hold: * It depends on objdump being in $PATH. If it isn't, it will fail to read the SONAME from a library, even if it has determined the path to it. * If it uses ldconfig (which, unlike objdumb, it assumes it knows the full path to and doesn't rely on $PATH to find), it fails to interpret the results because the regular expression it applies doesn't define any groups. The attached patch is what I used to work around these issues in one particular environment. I don't claim the fixes to be general, and the patch includes no unit tests. -- assignee: theller components: ctypes files: ctypes-util.patch keywords: patch messages: 69814 nosy: exarkun, theller severity: normal status: open title: ctypes.util fails to find libc in some environments versions: Python 2.5 Added file: http://bugs.python.org/file10910/ctypes-util.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3383> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3500] unbound methods of different classes compare equal
New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>: If a method is inherited by two different classes, then the unbound method objects which can be retrieved from those classes compare equal to each other. For example: Python 2.6b2+ (trunk:65502M, Aug 4 2008, 15:05:07) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def y(self): ... pass ... >>> class A(X): ... pass ... >>> class B(X): ... pass ... >>> A.y == B.y True This is bad behavior because A.y and B.y are otherwise distinguishable (for example, they repr differently, they have different values for the `im_class´ attribute, they cannot be used interchangably for invoking the method because they place different type restrictions on the `self´ parameter, etc). -- components: Interpreter Core messages: 70714 nosy: exarkun severity: normal status: open title: unbound methods of different classes compare equal type: behavior versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3500] unbound methods of different classes compare equal
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: The reason I noticed this is that since they compare and hash equal, if you put two such methods into a set, you end up with a set with one method. Currently, this is preventing me from running two test methods because the method itself is defined on a base class and two subclasses which customize several other methods inherit it. I can only run one test at a time. Having them compare unequal means you can't actually trust unbound method comparison, nor using unbound methods as keys in a dictionary. This means some other mapping structure is required if you want to keep around a bunch of methods and arguments to pass to them. It also means that any time you want to check two methods against each other with the goal of eventually calling one or both of them, you need to use something other than `==´. It seems like calling methods is likely to be a more common use-case than anything else. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3500] unbound methods of different classes compare equal
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: > But you acknowledge they are really the same method attached to > different classes, right? The notion of "unbound method" is mostly an > implementation detail. The term occurs only 4 times in the whole Python > documentation (according to Google). And in py3k they are gone. (*) It's the same function attached to two different classes. I don't really buy the "implementation detail" argument - if Guido says it, then I don't have much choice but to accept it, but I'm going to argue about it with anyone else. :) In this case, I'd say it's definitely not an implementation detail because it has major consequences visible to applications. If I get method x from class A and try to call it with an instance of class B, then it's going to break. I have to know about this behavior in order to write a program that works. Py3k may be different, but I'm not going to talk about Py3k here because I'm only interested in the Python 2.x behavior. > Moreover, you say you want them to compare unequal because you > *explicitly* want the same method called separately for each class it is > defined on. Is there anything preventing you to have a set of (class, > method) tuples instead? Because it sounds like the logical thing to do > in your case. I could do that. I probably will, too, since this code needs to work on Python 2.3 through Python 2.5. I still want to make Python 2.6 better, though. It seems to me that an unbound method is already effectively a tuple of (class, function) - it has a reference to both of those. Requiring applications to tie it up with a class again is just redundant. > "Trust" is a strong word. You can trust the comparison operator if you > agree with its semantics, you cannot trust it if you want different > semantics. But that doesn't mean it is generally trustworthy or > untrustworthy. You're right. "trust" was a bad word to use there. > I don't think there are lots of use cases for comparing *unbound* > methods. One such use case is checking for redefinition of inherited > methods, and the current __eq__ semantics look fine for that. This use-case is already satisfied though - if an application wants to see if the function is the same, then the application can compare the im_func attribute of the method objects. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3383] ctypes.util fails to find libc in some environments
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: Any chance of getting this fixed? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3383> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3780] No way to write unit tests for warnings
New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>: In Python 2.5 and earlier, the `warnings.warn_explicit` function could be replaced in order to test what warnings were emitted by some code. This allowed unit tests for warnings to be written. Since much of the warnings module was re-implemented in C, replacing `warnings.warn_explicit` no longer has any effect. This, together with the fact that there are no other public APIs for hooking into the warning system with duplication suppression disabled means that there is no reliable way to write unit tests for warnings. This was previously discussed on python-dev, but no conclusion was reached. See http://mail.python.org/pipermail/python-dev/2008-June/080635.html and the follow-ups. For Twisted, the consequence of this is roughly 79 failing unit tests in Python 2.6b3 and no clear way to fix them, except to stop using the standard library warnings module. -- components: Library (Lib) messages: 72530 nosy: exarkun severity: normal status: open title: No way to write unit tests for warnings type: behavior versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3780> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>: This example shows the behavior: from warnings import catch_warnings def test(): with catch_warnings(True) as w: assert str(w.message) == "foo", "%r != %r" % (w.message, "foo") test() This fails with an IndexError from the `w.message`. That's a bit surprising, and since this is mostly an API useful for testing, it'd be much better if it had a well-defined, documented (ie, stable and likely to continue working in the next release of Python) error mode. -- components: Library (Lib) messages: 72533 nosy: exarkun severity: normal status: open title: warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted type: behavior versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3780] No way to write unit tests for warnings
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: I was aware of it, but I didn't realize adding an "always" filter would make sure all warnings always got noticed. I haven't tried changing Twisted's use of the warnings module yet, but it looks like `catch_warnings` will work here. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3780> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: The specific exception type isn't that important to me, as long as I can rely on it being something in particular. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: Exposing a list seems like a great low-level API to me. There are no [-1]s in the Twisted codebase as a result of using this API because we have a higher-level API built on top of it. Having this low-level API that doesn't try to make a specific application more convenient (at the cost of ambiguity) means anyone can write a better high-level API on top of it that makes a specific use-case convenient. For Twisted, we actually would have very little difficulty coming up with our own version of catch_warnings without copying the implementation from the test_support module. What we are *really* interested in is a public API. Copying the implementation from test_support doesn't give us that. I understand the concern with introducing changes like this into CPython so close to a release. I just want it to be clear that without a public API for this feature, the issue isn't resolved for Twisted. That may not have been clear by just looking at this ticket, but see also issue3780 which I filed before filing this one which was also marked as a release blocker and which was resolved only because of the existence of `warnings.catch_warnings` (therefore removing the public API would mean re-opening that ticket). ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: There was a discussion on python-dev about using things from the `test` package from code outside the `test` package: http://mail.python.org/pipermail/python-dev/2008-August/081860.html ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: Both M2Crypto and pyOpenSSL expose certificate and key objects and have seen lots of real-world use. Following their lead would be sensible. -- nosy: +exarkun ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: I'm just suggesting that if the ssl module *is* going to gain certificate and key objects, looking at existing APIs and perhaps emulating them, to the extent that they provide functionality which the ssl module is also going to provide, is a good idea. Perhaps we could actually get the various APIs to begin to converge (where they overlap) instead of producing further divergence. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: You can load a private key from a string by creating a memory BIO and using PEM_read_bio_PrivateKey or d2i_PrivateKey_bio. This is how pyOpenSSL implements its load_privatekey API. You can see the code here: http://bazaar.launchpad.net/~exarkun/pyopenssl/trunk/annotate/70?file_id=crypto.c-20080219014912-qyb7kjf196jhzlyv-128 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3933] presence of .pythonstartup.py causes __main__.__file__ to be set incorrectly
New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>: [EMAIL PROTECTED]:~$ ls .pythonstartup.py .pythonstartup.py [EMAIL PROTECTED]:~$ python Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __file__ '/home/exarkun/.pythonstartup.py' >>> [EMAIL PROTECTED]:~$ mv .pythonstartup.py .not-pythonstartup.py [EMAIL PROTECTED]:~$ python Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __file__ Traceback (most recent call last): File "", line 1, in NameError: name '__file__' is not defined >>> -- components: Library (Lib) messages: 73572 nosy: exarkun severity: normal status: open title: presence of .pythonstartup.py causes __main__.__file__ to be set incorrectly type: behavior versions: Python 2.4, Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3933] presence of .pythonstartup.py causes __main__.__file__ to be set incorrectly
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: Why wasn't it backported to 2.5? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3933] presence of .pythonstartup.py causes __main__.__file__ to be set incorrectly
Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: Any buggy behavior might be relied on by applications. Taken to the extreme, you can never have a bug-fix release of Python. __file__ from PYTHONSTARTUP breaks the warnings module. It would be difficult for an application to rely on __main__.__file__ being set, since $PYTHONSTARTUP is only read in interactive mode - when it's a human using Python, not a program. Of course another process could run Python interactively in a child process and then rely on __file__, sure. But why is that valid? It's not like __file__ *means* something there - it's just the value of PYTHONSTARTUP. But I guess I don't really care anymore. I understand why warnings are being reported incorrectly now, so I doubt this affects /me/ anymore. It seems like it'd be better to reduce confusion for other people too, but that's not up to me. Thanks for pointing out where it was fixed in 2.6. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7779] smtplib SASL PLAIN authentication error
Jean-Paul Calderone added the comment:
There's no bug here. You've misunderstood how the literal \0 syntax works.
Perhaps this will clarify things:
>>> list('\0123')
['\n', '3']
>>> list('\x00123')
['\x00', '1', '2', '3']
>>>
--
nosy: +exarkun
___
Python tracker
<http://bugs.python.org/issue7779>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7779] smtplib SASL PLAIN authentication error
Jean-Paul Calderone added the comment:
It doesn't matter whether \0 or \x00 is used. They mean the same thing. Maybe
this is the example I should have given:
>>> list('\0%s' % ('12',))
['\x00', '1', '2']
>>> list('\x00%s' % ('12',))
['\x00', '1', '2']
>>>
--
___
Python tracker
<http://bugs.python.org/issue7779>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7092] Test suite emits many DeprecationWarnings when -3 is enabled
Changes by Jean-Paul Calderone : -- nosy: -exarkun ___ Python tracker <http://bugs.python.org/issue7092> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7829] dis module documentation gives no indication of the dangers of bytecode inspection
New submission from Jean-Paul Calderone : >From python-dev: On Fri, Jan 29, 2010 at 15:04, wrote: > On 10:47 pm, tjre...@udel.edu wrote: >> >> On 1/29/2010 4:19 PM, Collin Winter wrote: >>> >>> On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: >> >>> Agreed. We originally switched Unladen Swallow to wordcode in our >>> 2009Q1 release, and saw a performance improvement from this across the >>> board. We switched back to bytecode for the JIT compiler to make >>> upstream merger easier. The Unladen Swallow benchmark suite should >>> provided a thorough assessment of the impact of the wordcode -> >>> bytecode switch. This would be complementary to a JIT compiler, rather >>> than a replacement for it. >>> >>> I would note that the switch will introduce incompatibilities with >>> libraries like Twisted. IIRC, Twisted has a traceback prettifier that >>> removes its trampoline functions from the traceback, parsing CPython's >>> bytecode in the process. If running under CPython, it assumes that the >>> bytecode is as it expects. We broke this in Unladen's wordcode switch. >>> I think parsing bytecode is a bad idea, but any switch to wordcode >>> should be advertised widely. >> >> Several years, there was serious consideration of switching to a >> registerbased vm, which would have been even more of a change. Since I >> learned 1.4, Guido has consistently insisted that the CPython vm is not part >> of the language definition and, as far as I know, he has rejected any byte- >> code hackery in the stdlib. While he is not one to, say, randomly permute >> the codes just to frustrate such hacks, I believe he has always considered >> vm details private and subject to change and any usage thereof 'at one's own >> risk'. > > Language to such effect might be a useful addition to this page (amongst > others, perhaps): > > http://docs.python.org/library/dis.html > > which very clearly and helpfully lays out quite a number of APIs which can > be used to get pretty deep into the bytecode. If all of this is subject to > be discarded at the first sign that doing so might be beneficial for some > reason, don't keep it a secret that people need to join python-dev to learn. > Can you file a bug and assign it to me? -Brett -- assignee: georg.brandl components: Documentation messages: 98661 nosy: exarkun, georg.brandl severity: normal status: open title: dis module documentation gives no indication of the dangers of bytecode inspection ___ Python tracker <http://bugs.python.org/issue7829> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7501] python -m unittest path_to_suite_function errors
Jean-Paul Calderone added the comment: Sounds like one. As far as the trial behavior goes, "trial foo.test_suite" won't work, but "trial foo" will call "foo.test_suite", if one is defined. -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue7501> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7588] unittest.TestCase.shortDescription isn't short anymore
Jean-Paul Calderone added the comment: I agree that changing the result object is a better way to implement this feature: if the results object wants to report things by *name*, not *description*, then it should get the test's *name*, not rely on changing the meaning of the test's description method. -- ___ Python tracker <http://bugs.python.org/issue7588> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Jean-Paul Calderone added the comment: > With paramterized tests *all* the tests are run and *all* failures reported. > With testing in a loop the tests stop at the first failure. +1 to this justification. Parameterized tests are a big win over a simple for loop in a test. (However, I haven't looked at the IPython code at all, and Antoine's objection seemed to have something in particular to do with the IPython code?) -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7910] immutability w/r to tuple.__add__
Jean-Paul Calderone added the comment: Your output looks fishy. Anyway, the behavior of += isn't a bug: >>> a = b = (1, 2) >>> a += (1, 2, 3) >>> a (1, 2, 1, 2, 3) >>> a is b False >>> It's confusing, to be sure, but no mutation is going on. += is only in-place if applied to something that supports mutation this way (by implementing __iadd__). -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue7910> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Jean-Paul Calderone added the comment: Something else I think it would be nice to consider is what the id() (and shortDescription(), heh) of the resulting tests will be. It would be great if the id were sufficient to identify a particular test *and* data combination. In trial, we're trying to use test ids to support distributed test running. If the above property holds for parameterized tests, then we'll be able to automatically distribute them to different processes or hosts to be run. -- ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8064] Large regex handling very slow on Linux
Jean-Paul Calderone added the comment: I think it's likely that the test program does drastically different things on Linux than it does on OS X: Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import regextest >>> len(regextest.makew()) 93455 >>> Compare to: Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import regextest >>> len(regextest.makew()) 47672 >>> If I modify it to use 65535 (sys.maxunicode on OS X) and then run it on Linux, it completes quite quickly. -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue8064> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8064] Large regex handling very slow on Linux
Jean-Paul Calderone added the comment: > So is it reasonable / unavoidable that UCS4 builds should be 1200 times > slower at regex handling? No, but it's probably reasonable / unavoidable that a more complex regex should be some number of times slower than a simpler regex. On Linux, the regex being constructed is more complex. On OS X, it's simpler. The reason for the difference is that the Linux build is UCS4, but that's only because the unicode character width is being used as part of the function that constructs the regular expression. If you take this variable out of that function, so that it returns the same string regardless of the width of a unicode character, then performance evens out. -- ___ Python tracker <http://bugs.python.org/issue8064> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8036] Interpreter crashes on invalid arg to spawnl on Windows
Jean-Paul Calderone added the comment: Why is the Microsoft CRT argument error handler no longer disabled? -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue8036> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7978] SocketServer doesn't handle syscall interruption
Jean-Paul Calderone added the comment:
> What kind of signals can be received in real-life?
There are lots of possible answers. Here's one. You launch a child process
with os.fork() (and perhaps os.exec*() as well). Eventually you'll get a
SIGCHLD in the parent when the child exits. If you've also installed a
Python-level SIGCHLD handler with signal.signal (and not flagged the handler
with SA_RESTART using signal.siginterrupt) then if you're in select.select()
when the SIGCHLD is received, select.select() will fail with select.error EINTR.
If your Python SIGCHLD handler deals with the SIGCHLD completely before
returning, then this lets you support child processes and use SocketServer at
the same time.
Changing the behavior of select.select() ("a fix at select level would be
better") should be *very* carefully considered, and probably rejected after
such consideration. There are completely legitimate use cases which require
select.select() to fail with EINTR, and these should remain supported (not to
mention that existing code relying on this behavior shouldn't be broken by a
Python upgrade in a quite insidious way).
--
___
Python tracker
<http://bugs.python.org/issue7978>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1103213] Adding the missing socket.recvall() method
Jean-Paul Calderone added the comment: Just a couple comments: * If MSG_WAITALL is defined and a signal interrupts recv, will a string shorter than requested will be returned by sock_recvall? * Since MSG_WAITALL is already exposed to Python (when the underlying platform provides it), I wonder if this could all be implemented more simply in pure Python. Can you elaborate on the motivation to use C? Someone should do another review when there are unit tests. -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue1103213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3081] Py_(X)SETREF macros
Jean-Paul Calderone added the comment: The name suggests a different behavior to me - I assumed it would set the reference count to a specific value. Maybe this is the kind of thing Raymond had in mind when he said "The mnemonic doesn't work for me". -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue3081> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8363] Lots of duplicate code between test_classify_oldstyle and test_classify_newstyle in test_inspect.py
New submission from Jean-Paul Calderone : There are two tests for the way inspect.classify_class_attrs handles various sorts of attributes. The tests are identical, except one uses a classic class and one a new-style class. The tests sources have actually begun to diverge, but so far only in whitespace. This code will be easier to maintain (not to mention shorter) if there is just one copy of the actual test parts. -- assignee: exarkun components: Library (Lib), Tests keywords: needs review, patch messages: 102776 nosy: exarkun severity: normal status: open title: Lots of duplicate code between test_classify_oldstyle and test_classify_newstyle in test_inspect.py versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue8363> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8363] Lots of duplicate code between test_classify_oldstyle and test_classify_newstyle in test_inspect.py
Changes by Jean-Paul Calderone : Added file: http://bugs.python.org/file16856/test_inspect.patch ___ Python tracker <http://bugs.python.org/issue8363> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8363] Lots of duplicate code between test_classify_oldstyle and test_classify_newstyle in test_inspect.py
Jean-Paul Calderone added the comment: Okay. I shouldn't commit until after trunk is unfrozen though, right? -- ___ Python tracker <http://bugs.python.org/issue8363> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8363] Lots of duplicate code between test_classify_oldstyle and test_classify_newstyle in test_inspect.py
Jean-Paul Calderone added the comment: Committed in r79935 -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue8363> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
New submission from Jean-Paul Calderone : Linux offers the signalfd syscall since 2.6.22 (with minor changes afterwards). This call allows signals to be handled as bytes read out of a file descriptor, rather than as interruptions to the flow of a program. Quite usefully, this file descriptor can be select()'d on (or poll()'d, epoll()'d, etc) alongside other "normal" file descriptors. In order to effectively use signalfd(), the signals in question must be blocked, though. So it makes sense to expose sigprocmask(2) at the same time, in order to allow this blocking to be set up. -- assignee: exarkun components: Extension Modules, Library (Lib) messages: 103182 nosy: exarkun priority: normal severity: normal status: open title: expose signalfd(2) and sigprocmask(2) in the signal module type: feature request versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue8407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
Jean-Paul Calderone added the comment: I've started on an implementation of this in /branches/signalfd-issue8407. -- ___ Python tracker <http://bugs.python.org/issue8407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8354] siginterrupt with flag=False is reset when signal received
Jean-Paul Calderone added the comment: > Will the modified test fail on platforms that don't define HAVE_SIGACTION? Only if they also have siginterrupt, which seems unlikely (as neologix explained). The implemented behavior on such platforms is unmodified from current trunk, while the test requires new behavior. I think it's probably worth testing this new behavior separately from the test for the existing behavior anyway, for the sake of clarity. If it turns out there's a platform with siginterrupt but not sigaction, then that'll also let the test be skipped there, which is nice (though this case seems unlikely to come up). I'm not exactly sure how we will know if it is expected to fail, though. I don't think `HAVE_SIGACTION` is exposed nicely to Python right now. Perhaps the signal module should make this information available (it's somewhat important now, as it will mean the difference between a nicely working signal.siginterrupt and a not-so-nicely working one). This quirk probably also bears a mention in the siginterrupt documentation. A few other thoughts on the code nearby: * There seems to be no good reason to special case SIGCHLD in signal_handler. The comment about infinite recursion has no obvious interpretation to me. Fortunately, this is irrelevant on platforms with sigaction, because the handler remains installed anyway! * The distance between the new #ifndef HAVE_SIGACTION check and the corresponding #ifdef HAVE_SIGACTION in pythonrun.c is somewhat unfortunate. Someone could very easily change the logic in PyOS_setsig and disturb this relationship. I'm not sure how this could best be fixed. A general idea which presents itself is that both of these pieces of code could use a new identifier to make this choice, and that identifier could be named/documented such that it is obvious that it is used in two different places which must be kept synchronized. Or, some more comments in both places might help. It seems likely that the remaining SIGCHLD check in handle_signal is only there because whoever updated PyOS_setsig to use sigaction didn't know about it/remember it. Aside from those points, the fix seems correct and good. -- ___ Python tracker <http://bugs.python.org/issue8354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
Jean-Paul Calderone added the comment: > The one big difference I can see is that set_wakeup_fd() doesn't transmit the > signal number, but this could be fixed if desired (instead of sending '\0', > send a byte containing the signal number). There's a lot more information than the signal number available as well. The signalfd_siginfo struct has 16 fields in it now and may have more in the future. Another advantage is that this approach allows all asynchronous preemption to be disabled. This side-steps the possibility of hitting any signal bugs in CPython itself. Of course, any such bugs that are found should be fixed, but fixing them is often quite challenging and involves lots of complex domain-specific knowledge. In comparison, the signalfd and sigprocmask extensions are quite straight-forward and self-contained. It's also possible to have several signalfds, each with a different signal mask. set_wakeup_fd is limited to a single fd per-process. sigprocmask has other uses all by itself, of course, like delaying the delivery of signals while some sensitive code runs. -- ___ Python tracker <http://bugs.python.org/issue8407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8489] smtplib.SMTP.login() breaks with unicode input
Jean-Paul Calderone added the comment: SMTP (RFC 2821) doesn't support non-ASCII envelope addresses. A better behavior here would be for connection.login to raise a ValueError or a TypeError whenever a non-str is passed in. RFC 5336, though, adds the UTF8SMTP extension, which adds support for UTF-8 encoded unicode mailboxes. If the server advertises the UTF8SMTP capability, then smtplib could encode unicode using UTF-8 and pass it on. This is really a feature request (RFC 5336 support), not a bug. -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue8489> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8498] Cannot use backlog = 0 for sockets
Jean-Paul Calderone added the comment: > Furthermore, python's socket documentation makes it clear: Why does CPython go out of its way to make it impossible to pass 0 to the platform listen() API? The part of the specification you quoted makes it very clear that 0 is a valid value for this argument. And 0 seems to have a very different meaning than 1, but for some reason CPython thinks that 1 is a better thing for 0 to mean. Perhaps there is a real reason someone thought to add this check in sock_listen, but if not, I think it's worth considering removing this check. Unfortunately the commit message for the revision which added this check (r3880) is not informative: sock_listen: ensure backlog argument is at least1 > If you really want to only accept 1 connection (I'm talking of sending back a > SYN-ACK, not an accept() call), you can just close the server socket This makes perfect sense, though, and is good advice in general. -- ___ Python tracker <http://bugs.python.org/issue8498> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8498] Cannot use backlog = 0 for sockets
Jean-Paul Calderone added the comment: It'd be nice to have a unit test that passes a small enough value to listen() to trigger the check. Since there's no way to reliably determine what the system backlog really is, there's probably no reason to actually try to determine that the "right" value was passed to listen. Just making sure the code actually goes through the success-case when this check is hit is probably enough. -- ___ Python tracker <http://bugs.python.org/issue8498> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8524] SSL sockets do not retain the parent socket's attributes
Jean-Paul Calderone added the comment: Well, at the risk of stating the obvious, perhaps the dup() thing should be eliminated. The justification for it seems less than clear, and apparently it causes some problems. That might be a direction to consider in the long term, though, rather than as a (different) immediate fix for this issue. -- nosy: +exarkun priority: high -> normal resolution: fixed -> stage: committed/rejected -> status: pending -> open type: behavior -> ___ Python tracker <http://bugs.python.org/issue8524> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall
Jean-Paul Calderone added the comment: > What is the mnemonic corresponding to errno 35 under OS X? EAGAIN -- ___ Python tracker <http://bugs.python.org/issue8493> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall
Jean-Paul Calderone added the comment: > But as I said, it's not reliable. I don't see any evidence in support of this statement. Did you notice that the FreeBSD thread you referenced is: * 6 years old * about UDP It's not obvious to me that it's actually relevant here. > Maybe it would help to have the sample code ? This seems to be an excellent idea, though. Without actually knowing what program triggers this behavior, any change is just a wild guess and probably a waste of time. -- ___ Python tracker <http://bugs.python.org/issue8493> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall
Jean-Paul Calderone added the comment: None of that has much relevance when the socket is in *non-blocking* mode. -- ___ Python tracker <http://bugs.python.org/issue8493> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall
Jean-Paul Calderone added the comment: > If there's something else that would be useful and I can provide it, I'd be > glad to. A minimal example which reproduces the behavior. :) -- ___ Python tracker <http://bugs.python.org/issue8493> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8493] socket's send can raise errno 35 under OS X, which causes problems in sendall
Jean-Paul Calderone added the comment: > But if someone can get me access to an FTP server on the other end of a slow > link, I'd be glad to do what I can . It's easy to get a slow FTP server. Twisted's FTP support lets you do all kinds of customization; making a server that doesn't read very fast (or at all!) would be a snap. Ultimately, I don't think you should actually need an FTP server to reproduce this, though. A discard server should work just as well. > Unfortunately the problem wasn't mine originally. I'm just the guy on > python-help who happened to figure out the answer. Perhaps you can encourage the OP to take a look at this issue and post some code. -- ___ Python tracker <http://bugs.python.org/issue8493> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8524] SSL sockets do not retain the parent socket's attributes
Jean-Paul Calderone added the comment: getpeername() "sometimes" failing "soon" after a socket is created is a semi-well-known Windows socket... feature. For whatever that's worth. -- ___ Python tracker <http://bugs.python.org/issue8524> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8550] Expose SSL contexts
Jean-Paul Calderone added the comment: For reference: http://pyopenssl.sourceforge.net/pyOpenSSL.html/openssl-context.html http://www.heikkitoivonen.net/m2crypto/api/M2Crypto.SSL.Context%27.Context-class.html and `man -k SSL_CTX_` -- nosy: +exarkun ___ Python tracker <http://bugs.python.org/issue8550> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8569] Upgrade OpenSSL in Windows builds
Jean-Paul Calderone added the comment: http://www.openssl.org/news/secadv_20100324.txt http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 New Windows builds of any versions of CPython which are still receiving security updates should be released. -- nosy: +exarkun priority: normal -> critical ___ Python tracker <http://bugs.python.org/issue8569> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
Jean-Paul Calderone added the comment: find_unused_port is the wrong approach altogether. Uses of it should be replaced by bind_port and then find_unused_port should be removed. -- ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue665761] reduce() masks exception
Changes by Jean-Paul Calderone : -- nosy: -exarkun ___ Python tracker <http://bugs.python.org/issue665761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
Jean-Paul Calderone added the comment: One open question regarding interaction with threading. sigprocmask's behavior in a multithreaded program is unspecified. pthread_sigmask should be used instead. I could either expose both of these and let the caller choose, or I could make signal.sigprocmask use pthread_sigmask if it's available, and fall back to sigprocmask. I don't see any disadvantages of doing the latter, and the former seems like it would create an attractive nuisance. However, I don't have much experience with sigprocmask; I'm only interested in it because of its use in combination with signalfd. -- ___ Python tracker <http://bugs.python.org/issue8407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
Changes by Jean-Paul Calderone : -- nosy: +gps ___ Python tracker <http://bugs.python.org/issue8407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
