[issue2459] speedup loops with better bytecode

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: This new patch also updates the code generation for list comprehensions. Here are some micro-benchmarks: ./python -m timeit -s "l = range(100)" "[x for x in l]" Before: 10 loops, best of 3: 14.9 usec per loop After: 10 loops, best of

[issue2486] Consider using bytes type instead of str to store Decimal coefficients

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Hmm, I forgot there wasn't currently a direct path back from int -> bytes. I think your numbers *do* show that we need to do something about the performance of the Python 3.0 version of decimal. A 25% increase in runtime is a pretty big performa

[issue2490] Assertion failure in datetime.strftime()

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Can you give us an example of the data that caused the failure? -- nosy: +benjamin.peterson type: -> behavior __ Tracker <[EMAIL PROTECTED]> _

[issue2491] io.open() handles errors differently on different platforms

New submission from Neal Norwitz <[EMAIL PROTECTED]>: The attached file has a snapshot of the python.org homepage that was causing test_urllibnet to fail on some platforms (2 sparc, and ia64 at least), but not other platforms. This should be handled consistently. I don't know if there are reall

[issue2484] Cosmetic patch for warning "unused variable"

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: I've confirmed trunk doesn't have this problem. Probably this is merge issue. r57928 changed the position of "int i,j" in py3k, but not changed in trunk, so when r61864 was merged into py3k some kind of conflict happened.

[issue2483] int and float accept bytes, complex does not

Gabriel Genellina <[EMAIL PROTECTED]> added the comment: Are numbers so special to break the rules? why stopping here? what about other types that may want to accept ASCII bytes instead of characters? Isn't this like going back to the 2.x world? The protocol with embedded ASCII numbers is

<    1   2