[issue1740] use unittest for test_logging

Thomas Herve added the comment: I have just one comment: I have recently modified the initialization of LogRecordSocketReceiver to not use a stupid loop to get a free port, but instead use port 0 and get the port number once bound. I think this modification should stay. -- nosy: +therve

[issue1152248] Enhance file.readlines by making line separator selectable

Raymond Hettinger added the comment: For the record, I thought it was a reasonable request. AWK has a similar feature. The AWK book shows a number of example uses. Google's codesearch shows that the feature does get used in the field: http://www.google.com/codesearch?q=lang%3Aawk+RS&hl=en

[issue1152248] Enhance file.readlines by making line separator selectable

Facundo Batista added the comment: Sorry, I misunderstood you. I assign this to myself to give it a try. -- assignee: -> facundobatista _ Tracker <[EMAIL PROTECTED]> _

[issue1170] shlex have problems with parsing unicode

Changes by Matej Cepl: -- nosy: +mcepl __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue1740] use unittest for test_logging

Christian Heimes added the comment: Thomas Herve wrote: > I have just one comment: I have recently modified the initialization of > LogRecordSocketReceiver to not use a stupid loop to get a free port, but > instead use port 0 and get the port number once bound. I think this > modification should

[issue2195] urlparse() does not handle URLs with port numbers properly

Χρήστος Γεωργίου (Christos Georgiou) added the comment: RFC1808 §2.1 suggests a generic RL syntax that specifies '://' as the separator, so Gawain's suggestion makes practical sense. However, also as Gawain says, the RFC specifies that '//' is considered as the first part of a "net_path" and is n

[issue2197] Further simplify dict literal bytecode

Alexander Belopolsky added the comment: I did not think of the insertion after creation change of semantics. Do I understand that this is important when keys have custom comparison/hash methods with side-effects. If it is important for the language to guarantee the create/insert order in bui

[issue2195] urlparse() does not handle URLs with port numbers properly

Senthil added the comment: I don't think this is a valid issue. If you browse through the RFC 1808 you will find that. 1) For net_loc information it refers to a broad section 1738 and we wont specifically find any information on port number in that. 2) But, have a look at the BNF Representation o

[issue2181] optimize out local variables at end of function

Armin Rigo added the comment: I suppose you are aware that performing this optimization in general would break a lot of existing code that uses inspect.getstack() or sys._getframe() to peek at the caller's local variables. I know this because it's one thing that Psyco doesn't do correctly, and o

[issue2181] optimize out local variables at end of function

Neal Norwitz added the comment: > I suppose you are aware that performing this optimization in general > would break a lot of existing code that uses inspect.getstack() or > sys._getframe() to peek at the caller's local variables. I know this Yes, with this optimization the variable might ne

[issue2193] Cookie Colon Name Bug

Jerry Seutter added the comment: Heh, I think I should not have gotten involved in this bug. :) I have a few comments: In response to 2.: David M. Kristol in that article is referring to the original Netscape cookie implementation which is somewhat different from what is set out in the RFC's.

[issue2193] Cookie Colon Name Bug

Changes by Jerry Seutter: -- type: -> behavior __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue2157] sqlite numeric type conversion problems

Gerhard Häring added the comment: The same question came up in the external pysqlite project once. My answer is the same here: this won't be fixed because of backwards compatibility reasons. The current behaviour is well documented. I acknowledge that it would be nice to be able to use declarato

[issue1546263] Segfaults with concurrent sqlite db access and schema change

Gerhard Häring added the comment: See http://initd.org/tracker/pysqlite/ticket/170 and http://initd.org/tracker/pysqlite/changeset/301 _ Tracker <[EMAIL PROTECTED]> _ ___

[issue2127] sqlite3 docs should mention utf8 requirement

Changes by Gerhard Häring: -- nosy: +ghaering __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue2127] sqlite3 docs should mention utf8 requirement

Gerhard Häring added the comment: I'll assign this one to me. The "sqlite3" module cannot be just "refreshed" with the externally maintained pysqlite, I'll have to do merging anyway. Don't worry here ;-) -- assignee: -> ghaering keywords: +easy priority: -> low severity: normal -> mino

[issue2152] make sqlite.Row hashable correctly

Changes by Gerhard Häring: -- assignee: -> ghaering nosy: +ghaering priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list

[issue2157] sqlite numeric type conversion problems

wrobell added the comment: fair enough, but... 1. i really do not see that behaviour documented, i.e. http://docs.python.org/lib/node347.html says nothing about types being broken on space character. 2. i am bit missing the point about backward compability. when looking on intern

[issue2157] sqlite numeric type conversion problems

Gerhard Häring added the comment: It's mentioned here: http://docs.python.org/lib/sqlite3-Module-Contents.html __ Tracker <[EMAIL PROTECTED]> __ ___ Pyth

[issue2157] sqlite numeric type conversion problems

Gerhard Häring added the comment: Yes, I acknowledge the backwards incompatibility is rather a one in a billion case than a one in a million case. I'll reopen this one and integrate your patch or something similar for Python 2.6 and 3.0. -- resolution: wont fix -> status: closed -> ope

[issue2183] optimize list comprehensions

Alexander Belopolsky added the comment: The patch looks reasonable to me. Bytecode docs need to be changed. At minimum like this: === --- Doc/library/dis.rst (revision 61097) +++ Doc/library/dis.rst (working copy) @@ -463,9 +463,9

[issue2198] code_hash() can be the same for different code objects

New submission from Stephan R.A. Deibel: The algorithm in code_hash() in codeobject.c can return the same hash value for different code objects. Presumably distinct code objects should be very unlikely to have the same hash value. This bug affected our debugger before we worked around it, and

[issue2198] code_hash() can be the same for different code objects

Stephan R.A. Deibel added the comment: I should have noted that adding co_firstlineno as well to the hash would be necessary to distinguish like code objects within the same file. The example has them on the same lines in different files but changing the first line of the defs doesn't matter. _

[issue2185] code objects should conserve memory

Alexander Belopolsky added the comment: Since names and varnames are known to be tuples of interned strings, they can be compared without calling abstract API. Just compare sizes and then compare item pointers in a loop. What are the cases when co_names == co_varnames? How often is this the

[issue2193] Cookie Colon Name Bug

BM added the comment: Well, as D.M.Kristol says: there are no any standard for this particular topic. And RFC is not any standard but a request for comments... Personally I've been added a colon in Cookie.py for let Trac and other Python-based software stop crashing, because such sort of cooki

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

Mark Dickinson added the comment: I'm wondering what there is left to do here. Are we close to being able to close this issue? Some thoughts: (1) I think the docs could use a little work (just expanding, and giving a few examples). But it doesn't seem urgent that this gets done before the

[issue1762] Inheriting from ABCs makes classes slower.

Jeffrey Yasskin added the comment: Since there were no comments, I submitted the patch as r61098. I think we're done here. :) -- resolution: -> fixed status: open -> closed type: -> behavior versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]>

[issue2184] Speed up Thread.start()

Jeffrey Yasskin added the comment: Submitted as r61100. -- assignee: -> jyasskin resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___