[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

Martin Mokrejs <[EMAIL PROTECTED]> added the comment: Could it be the name clashing problem between -lcrypt and -lcrypto? bash-3.00# ar x /usr/lib/libcrypt.a;nm -g des_crypt.o U ___errno 033c T _des_crypt 0274 T _des_encrypt U _des_encrypt1 01b0 T _des_setkey

[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: No. We are not linking with libcrypto at all, so there can't be clashes. ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

Martin Mokrejs <[EMAIL PROTECTED]> added the comment: You say "did always work"? http://mail.python.org/pipermail/python-list/2002-December/177479.html Maybe the reason why in ruby they forced to -shared flag because it was possible to link only with the shared library? I do not know from which

[issue3088] test_multiprocessing hangs on OS X 10.5.3

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The two tracebacks provided by Mark seem to correspond to the following python stack (innermost last): Lib/test/test_multiprocessing.py, line 1005, in _test_map_unordered self.assertEqual(sorted(it), map(sqr, range(1000))) Lib/multi

[issue3088] test_multiprocessing hangs on OS X 10.5.3

Ismail Donmez <[EMAIL PROTECTED]> added the comment: The test hanged for me at first try but worked fine on the second test, weird. ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Ah, ok. I completely missed the point of the error message (i.e. "relocations remain"), and misinterpreted it as missing symbols. So I still recommend doing what I recommended back then: Uncomment the line in Modules/Setup to build the crypt

[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available

Martin Mokrejs <[EMAIL PROTECTED]> added the comment: Confirming the enabling line 216 like below helped. Thanks. Maybe change "Resolution"? 204 # Socket module helper for SSL support; you must comment out the other 205 # socket line above, and possibly edit the SSL variable: 206 #SS

[issue3088] test_multiprocessing hangs on OS X 10.5.3

Paul Melis <[EMAIL PROTECTED]> added the comment: On a Linux system (FC4) with r64686 of the Py3k branch I also still get occassional hangs (with ./python -E -bb ./Lib/test/regrtest.py -v test_multiprocessing). Mostly this seems to occur with the very first test executed, i.e. before any of the "

[issue1322] platform.dist() has unpredictable result under Linux

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: Please see the top of platform.py: #This module is maintained by Marc-Andre Lemburg <[EMAIL PROTECTED]>. #If you find problems, please submit bug reports/patches via the #Python SourceForge Project Page and assign them to "lem

[issue1322] platform.dist() has unpredictable result under Linux

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: Also note that linux_distribution() will use the parsed distro name from the release file per default (full_distribution_name=1), so the problem described in the original ticket description should no longer be relevant: all release files p

[issue3088] test_multiprocessing hangs on OS X 10.5.3

Mark Dickinson <[EMAIL PROTECTED]> added the comment: > Are you sure that's right? That traceback has no mention of > PyObject_Malloc or obmalloc.c. So now I think that the traceback was right. There was no mention of PyObject_Malloc or obmalloc.c because the traceback only showed 1 of the 9

[issue3249] bug adding datetime.timedelta to datetime.date

Chris Withers <[EMAIL PROTECTED]> added the comment: This may be "as documented" but it's *extremely* counter intuitive and seems to go against the grain of where python is headed. (remember that whole struggle to get 3/2 = 1.5 rather 3/2=1? ;-) ) I've changed the "type" to "feature request", w

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

Nick Coghlan <[EMAIL PROTECTED]> added the comment: As far as deque goes, the following behaviour on the trunk is the problem I am trying to fix: Python 2.6b1+ (trunk:64655, Jul 2 2008, 22:48:24) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "cre

[issue3249] bug adding datetime.timedelta to datetime.date

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: To be valid, your analogy between dates and numbers suggests that a date should be convertible to the datetime with the same date, at midnight. And both objects compare equal, just like 42==42.0 But today this is not the case: it's hard

[issue3269] strptime() makes an error concerning second in arg

New submission from Neven Goršić <[EMAIL PROTECTED]>: strptime() allows 60 and 61 sec, but not 62 sec in arg. string >>> s='02/28/2000 12:33:61 AM' >>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p') (2000, 2, 28, 0, 33, 61, 0, 59, -1) >>> s='02/28/2000 12:33:62 AM' >>> time.strptime(s,'%m/%d/%Y %I:%M

[issue1622] zipfile hangs on certain zip files

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Thanks for the patch. This is now committed as r64688 -- resolution: -> accepted status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> _

[issue1526] DeprecationWarning in zipfile.py while zipping 113000 files

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: The patch for issue1622 was committed as r64688; closing this patch as outdated. -- nosy: +loewis resolution: -> out of date status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue3267] yield in list comprehensions possibly broken in 3.0

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: This is because list comprehensions are implemented as functions in 3.0 so their scope is not leaked out to the rest of the function. Here is the bytecode for 2.6: >>> dis.dis(f) 2 0 BUILD_LIST 0 3 D

[issue1746] ZIP files with archive comments longer than 4k not recognized as valid by zipfile module

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: The patch in #1622 was committed as r64688. -- nosy: +loewis resolution: duplicate -> fixed ___ Python tracker <[EMAIL PROTECTED]> __

[issue3270] test_multiprocessing: test_listener_client flakiness

New submission from Jesse Noller <[EMAIL PROTECTED]>: Per mail thread: http://mail.python.org/pipermail/python-dev/2008-June/080497.html Attached is the patch to connection.py to drop the fqdn call. Final suggestion from Trent: > This is a common problem. Binding to '127.0.0.1' will bind to *

[issue3269] strptime() makes an error concerning second in arg

Facundo Batista <[EMAIL PROTECTED]> added the comment: Minutes with 61 (0..60) and 62 (0..61) seconds are used to adjust the theoretical calendar because of small differences with real world rotation... Are you aware of any case where a minute with 63 seconds (0..62) should be used? --

[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.

Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Amaury, I was testing your patch and it turns out, that it will ignore any __sizeof__ attribute which may be available through getattr. I adapted it a bit, so now getsizeof will try to call the method on the passed object first, and if it

[issue3258] ctypes assertion failure in trunk

Changes by Kevin Watters <[EMAIL PROTECTED]>: -- nosy: +kevinwatters ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mai

[issue3269] strptime() makes an error concerning second in arg

Neven Goršić <[EMAIL PROTECTED]> added the comment: Thank you for your reply, although is not helpful for me. I use strptime() for datedate transformation and datatime boundaries checking and therefore I am not conserned in Reltivity theory. When someone in datetime table enter 02:61:38 it is s

[issue3269] strptime() makes an error concerning second in arg

Facundo Batista <[EMAIL PROTECTED]> added the comment: Closing as invalid, two reasons: - Your original issue was that time.strptime() didn't allow 62 seconds, not that it allowed 60 or 61. - If you use it to validate input... how do you actually know that 03/25/2012 17:13:61 AM' is an invalid

[issue3269] strptime() makes an error concerning second in arg

Neven Goršić <[EMAIL PROTECTED]> added the comment: - My original issue was that time.strptime() makes difference between 61 and 62 seconds - 17h AM, 78 s, 128min everyone can easly transform correctly, I just wanted to use function for boundarie checking: rising error for 62 sec and not for 61

[issue1555570] email parser incorrectly breaks headers with a CRLF at 8192

Changes by chris.eveleigh <[EMAIL PROTECTED]>: -- nosy: +chris.eveleigh ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue1690840] xmlrpclib methods submit call on __str__, __repr__

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: I think __str__ should also be implemented. I'm attaching a patch with unittests against current trunk. -- keywords: +patch Added file: http://bugs.python.org/file10805/xmlrpc_repr.diff ___ Python tr

[issue1690840] xmlrpclib methods submit call on __str__, __repr__

Ralf Schmitt <[EMAIL PROTECTED]> added the comment: this is how it looks: ~/pydev/trunk/ python [EMAIL PROTECTED] ok Python 2.6b1+ (trunk, Jul 3 2008, 12:43:37) [GCC 4.3.1] on linux2 Type "help", "copyright", "credits" or "license" for more informa

[issue3271] iter.next() or iter.__next__() ?

New submission from vizcayno <[EMAIL PROTECTED]>: For Win XP SP3 I do next in py30.b1: a=[9,8,1,2] it=iter(a) it.next() Traceback (most recent call last): File "", line 1, in AttributeError: 'list_iterator' object has no attribute 'next' but doing: it.__next__() 9 it.__next__() 8 it is ok.

[issue1641] asyncore delayed calls feature

Josiah Carlson <[EMAIL PROTECTED]> added the comment: Generally speaking, delayed calls, and/or a practical scheduling algorithm are useful for async servers. Since 2.6 and 3.0 are on feature freeze right now, this is going to have to wait for 2.7 and 3.1 . I'll make sure to get something like

[issue3272] Multiprocessing hangs when multiprocessing.Pool methods are called

New submission from Andrii V. Mishkovskyi <[EMAIL PROTECTED]>: `multiprocessing` hangs, when `multiprocessing.Pool` methods `map`, `imap`, `imap_unordered`, `apply`, `apply_async`, `map_async` are called. Here is an example: Python 3.0b1+ (py3k:64686M, Jul 3 2008, 13:06:13) [GCC 4.2.3 (Ubuntu 4

[issue3273] multiprocessing and meaningful errors

New submission from Andrii V. Mishkovskyi <[EMAIL PROTECTED]>: multiprocessing uses a lot of `assert` statements all over the code. I propose to change this way to a more readable and understandable. For example: Lib/multiprocessing/managers.py, line 136: assert isinstance(authkey, bytes) >From m

[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support

Facundo Batista <[EMAIL PROTECTED]> added the comment: What I don't understand here is... if gethostbyname() lacks of IPv6 support, instead of creating a new function why not to add the functionality to that same function? Right now gethostbyname() is implemented in C, which would be the drawbac

[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails

Changes by Facundo Batista <[EMAIL PROTECTED]>: ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails

Changes by Facundo Batista <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10632/unnamed ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3267] yield in list comprehensions possibly broken in 3.0

Brett Cannon <[EMAIL PROTECTED]> added the comment: Yes, this change in semantics is expected. Closing as "won't fix". -- nosy: +brett.cannon resolution: -> wont fix status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails

Facundo Batista <[EMAIL PROTECTED]> added the comment: I see that you're working on a final solution, this is great! What we would need also to incorporate this to the trunk is a patch for the test suite. Senthil, could you handle this? -- assignee: -> facundobatista nosy: +facundobati

[issue2916] urlgrabber.grabber calls setdefaulttimeout

Changes by Facundo Batista <[EMAIL PROTECTED]>: -- assignee: -> facundobatista nosy: +facundobatista, orsenthil ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2756] urllib2 add_header fails with existing unredirected_header

Facundo Batista <[EMAIL PROTECTED]> added the comment: BitTorment, what would increase the possibility of accepting this is a patch also for the test suite (test_urllib2.py), checking this behaviour, for us to be sure that does not break again in the future. Could you please submit also this? -

[issue2776] urllib2.urlopen() gets confused with path with // in it

Changes by Facundo Batista <[EMAIL PROTECTED]>: -- assignee: -> facundobatista nosy: +facundobatista, orsenthil ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3274] Py_CLEAR(tmp) seg faults

New submission from Daniel Stutzbach <[EMAIL PROTECTED]>: I'm writing a C extension module and discovered that Py_CLEAR() causes a crash if the programmer happened to name their variable "tmp". The Py_CLEAR() macro internally uses the name "tmp" in a new scope, hiding the callers "tmp", and call

[issue1063924] asyncore should handle ECONNRESET in send

Josiah Carlson <[EMAIL PROTECTED]> added the comment: We are actually closing the socket before returning in the latest version of asyncore. Closing as fixed. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue760475] asyncore.py and "handle_error"

Josiah Carlson <[EMAIL PROTECTED]> added the comment: I forgot to fix this in my most recent commits, but I'll fix it this weekend for Python 2.6 . ___ Python tracker <[EMAIL PROTECTED]>

[issue1736101] asyncore should handle also ECONNABORTED in recv

Josiah Carlson <[EMAIL PROTECTED]> added the comment: Fixed in trunk, will be fixed in 3.0 this weekend. ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue889153] asyncore.dispactcher: incorrect connect

Josiah Carlson <[EMAIL PROTECTED]> added the comment: Fixed in trunk, will be fixed in 3.0 this weekend. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> __

[issue1740572] asynchat should call "handle_close"

Josiah Carlson <[EMAIL PROTECTED]> added the comment: Fixed in trunk, will be fixed in 3.0 this weekend. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> _

[issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Martin, you seem to be the author of that module. -- nosy: +loewis ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3139] bytearrays are not thread safe

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Wow... Isn't this kind of code supposed to ask for a buffer on the bytearray object, together with an optional lock on it (or something like that)? -- nosy: +pitrou ___ Python tracker <[EMAIL PROTE

[issue909005] asyncore fixes and improvements

Josiah Carlson <[EMAIL PROTECTED]> added the comment: I have applied my variant patch to trunk, which will be in 3.0 this weekend. -- resolution: -> out of date status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue1025525] asyncore.file_dispatcher should not take fd as argument

Josiah Carlson <[EMAIL PROTECTED]> added the comment: Fixed in trunk, will be fixed in 3.0 this weekend. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> _

[issue1736190] asyncore/asynchat patches

Josiah Carlson <[EMAIL PROTECTED]> added the comment: Committed to trunk a bit ago, will be in 3.0 this weekend. -- resolution: -> accepted status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> __

[issue2464] urllib2 can't handle http://www.wikispaces.com

Changes by Facundo Batista <[EMAIL PROTECTED]>: -- assignee: -> facundobatista nosy: +facundobatista ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3250] datetime.time does not support arithmetic

George Boutsioukis <[EMAIL PROTECTED]> added the comment: I have also come across this in the past. Although I sense that some obscure reason might prevent time arithmetic from being included, here's a patch to add time/timedelta addition and subtraction. It closely follows the datetime arithmeti

[issue2808] asynchat forgets packets when push is called from a thread

Changes by Josiah Carlson <[EMAIL PROTECTED]>: -- status: pending -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-l

[issue2275] urllib2 header capitalization

Facundo Batista <[EMAIL PROTECTED]> added the comment: Senthil: We would need some tests to assure this will keep working ok in the future Also as this is (somehow) a new functionality, we'd need to modify the NEWS file and maybe even the docs (a comment about this case insensitivity? Could you

[issue3271] iter.next() or iter.__next__() ?

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Where in the 3.0 docs do you see it.next() used? It should be changed. -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]> _

[issue1462525] URI parsing library

Facundo Batista <[EMAIL PROTECTED]> added the comment: Senthil, we should incorporate the tests from RFC 3986 to the test suite, what do you think? Coul we integrate the effort from Paul Jimenez and the current urlparse and achieve a RFC compliant library? Should we handle this compliance in thi

[issue3271] iter.next() or iter.__next__() ?

vizcayno <[EMAIL PROTECTED]> added the comment: Please, go to python 3.0 -> python manuals and search with word: iter then select first line of found titles, i.e. Functional Programming HOWTO. Into this title you will find some samples. Regards, ___ Python tr

[issue3271] iter.next() or iter.__next__() ?

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: fixed in r64696. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue3271] iter.next() or iter.__next__() ?

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3275] Control flow not optimized

New submission from Daniel Colascione <[EMAIL PROTECTED]>: Consider: import dis def foo(): if 0 and 1: return "hi" dis.dis(foo) What I get is 2 0 LOAD_CONST 1 (0) 3 JUMP_IF_FALSE 15 (to 21) 6 POP_TOP

[issue3275] Control flow not optimized

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: A patch for this was just recently rejected. See #1394. -- nosy: +benjamin.peterson resolution: -> rejected status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue1580] Use shorter float repr when possible

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'd like to reopen this. I'm still in favor of something like to this algorithm: def float_repr(x): s = "%.16g" % x if float(s) != x: s = "%.17g" % x s1 = s if s1.startswith('-'): s1 = s[1:] if s1.isdigit(): s += '.0'

[issue3008] Let bin/oct/hex show floats

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Raymond, Mark? Is a new patch with tests and docs forthcoming? Have you decided on the API yet? I'm willing to approve this for beta 2, which will be around July 15. -- assignee: gvanrossum -> rhettinger

[issue3276] httplib.HTTPConnection._send_request should not blindly assume dicts for headers

New submission from toxik <[EMAIL PROTECTED]>: Presently it's impossible to use httplib.HTTPConnection.request and send the several headers with the same name. This is because _send_request assumes a dict is passed in, or a dict-like interface. Obviously one could make a list subclass or some

[issue1580] Use shorter float repr when possible

Tim Peters <[EMAIL PROTECTED]> added the comment: If you think using 16 (when possible) will stop complaints, think again ;-) For example, >>> for x in 0.07, 0.56: ... putatively_improved_repr = "%.16g" % x ... assert float(putatively_improved_repr) == x ... print putatively_improve

[issue3277] socket's OOB data management is broken on FreeBSD

New submission from Giampaolo Rodola' <[EMAIL PROTECTED]>: I've tried to run the code below on Windows XP and Linux Ubuntu and it works as expected. Here is the output: expt -> o read -> fo On FreeBSD 7.0 it raises the following exception: expt -> o read -> fo Exception in thread Thread-1: Tr

[issue3277] socket's OOB data management is broken on FreeBSD

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- components: +Library (Lib) type: -> behavior ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3278] socket's SO_REUSEADDR option does not work on FreeBSD

New submission from Giampaolo Rodola' <[EMAIL PROTECTED]>: When the SO_OOBINLINE option is used against a socket, out-of-band data should be placed in the normal data input stream as it is received. In fact this is what happens on Windows and Linux by using the script below. On FreeBSD this does

[issue3278] socket's SO_REUSEADDR option does not work on FreeBSD

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment: This bug should be strictly related with issue 3277: http://bugs.python.org/issue3277 ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3277] socket's OOB data management is broken on FreeBSD

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment: This bug should be strictly related with issue 3278: http://bugs.python.org/issue3278 ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3279] import of site.py fails on startup

New submission from Roger Upole <[EMAIL PROTECTED]>: In pythonrun.c, initstdio injects 'open' into builtins. However, initsite is called before initstdio and site.py uses open. Running with -v, this traceback is printed: Traceback (most recent call last): File "j:\python30\lib\site.py", line

[issue3008] Let bin/oct/hex show floats

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Mark, I'm tied-up with EuroPython until the 14th. Do you have time to take a crack at this? -- assignee: rhettinger -> marketdickinson ___ Python tracker <[EMAIL PROTECTED]>

[issue1580] Use shorter float repr when possible

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Here's a rough-and-tumble implementation of that idea, for Py3k. Added file: http://bugs.python.org/file10808/float.diff ___ Python tracker <[EMAIL PROTECTED]>

[issue1580] Use shorter float repr when possible

Guido van Rossum <[EMAIL PROTECTED]> added the comment: That is truly maddening! :-( I guess Noam's proposal to return str(x) if float(str(x)) == x makes more sense then. I don't really care as much about 1.234567890123 vs. 1.234567890122 as I care about 1.2345 vs. 1.2344. (Thi

[issue3277] socket's OOB data management is broken on FreeBSD

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Why do you think this is a bug in Python, and not in FreeBSD? -- nosy: +loewis ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3139] bytearrays are not thread safe

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Probably, but this affects all PyArg_ParseTuple("s#") calls that release the GIL afterwards. How many of them are there? ___ Python tracker <[EMAIL PROTECTED]> _