[issue10606] Misspelling of Jamie Zawinski's surname in urllib.parse docstring

Michal Božoň added the comment: this is still unfixed in Python 2.x -- nosy: +mykhal versions: +Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue10

[issue8643] incorrect timedelta yielded by two on-the-fly nows subtraction

Michal Božoň added the comment: ok, my fault, i should have tried >>> (abs(datetime.datetime.now() - datetime.datetime.now())).seconds 0 sorry :) -- ___ Python tracker <http://bugs.python.o

[issue8643] incorrect timedelta yielded by two on-the-fly nows subtraction

Changes by Michal Božoň : -- title: incorrect timedelta yielded by two on-the-fly nows -> incorrect timedelta yielded by two on-the-fly nows subtraction ___ Python tracker <http://bugs.python.org/iss

[issue8643] incorrect timedelta yielded by two on-the-fly nows

New submission from Michal Božoň : now() - now() from datetime.datetime produces not-nearly-zero timedelta: >>> import datetime >>> (datetime.datetime.now() - datetime.datetime.now()).seconds 86399 (i can't in the moment figure out why this is happening, sice the datet

[issue6312] httplib fails with HEAD requests to pages with "transfer-encoding: chunked"

Michal Božoň added the comment: i confirm.. in my case, the bug manifestated when calling HEAD method on a different server with chunked transfer encoding (http://obrazky.cz) my workaround is to call response.read() always, except from cases when method == 'HEAD' and resp

[issue1395552] add support for thread function result storage

Michal Božoň added the comment: i still do not agree, it will always feel somehow incomplete, being able to easily "threadize" the function: >>> t = threading.Thread(target=func) and then not being able to get the target func

[issue1395552] add support for thread function result storage

Michal Božoň added the comment: why would we throw the thread function result out of the window? because there is a another way, to do it? there are always many ways, how to do it, so why would we want to do it very difficult way? i think that not having the result stored somewhere is a bug

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: interesting. I'm not sure I've read anywhere that it is allowed to place a whitespace between object and attributes. Thanks __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. I remember.. it came onto my mind when I tried also -1.__str__() and found out that the dot has higher priority than unary minus :) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: I don't know it's in docs, it came into my mind, maybe logically (but later) to put 1 into parentheses __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: (finally now I get it.. I have forgotten that complex numbers can be float.. :) sorry ) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. however, fixing this is not necessary - because no one would probably use it, it's just a syntax inconsistency __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: I don't understand why 1.j is 1j .. because there's no int.j .. why then 1.L is not 1L ? __ Tracker <[EMAIL PROTECTED]> <http://bugs.p

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. OK, now I see than (1).__str__() works.. however, could be the parser fixed to 1.__str__() work too ? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1413] int literal methods inaccessible

New submission from Michal Božoň: It's impossible to call methods of int literals directly e.g. 1.__str__() (the same for oct literals). Even through it works for float, hex, literals, etc.. >>> 0x1.__str__() '1' >>> 1e0.__str__() '1.0' >>&g