[issue6916] Remove deprecated items from asynchat

New submission from Robert Lehmann : The patches in issue1736190 deprecated fifo and simple_producers. These are safe for removal in Python 3.0. I attached a patch purging fifo and simple_producers from py3k code and tests. The docs are mostly trivial as well but also touched by my other issue i

[issue6911] Document changes in asynchat

Robert Lehmann added the comment: I found another bug: async_chat.push still talks about automatically creating a simple_producer, which is no longer true. I added a fix to the patch. -- Added file: http://bugs.python.org/file14893/asynchat-docs.patch

[issue6915] os.listdir inconsistenly releases the GIL on win32

New submission from Ryan Kelly : The win32 implementation of os.listdir() releases the GIL around calls to FindNextFile, but not around calls to FindFirstFile. Attached is a simple patch to consistently release the GIL around any such calls. -- components: None files: listdir_gil.patch

[issue6914] Py_SetPythonHome, undocumented behavoir

New submission from Campbell Barton : Py_SetPythonHome holds a pointer to the variable passed, this is not documented so passing a variable on the stack will not work as expected unless its static or allocated. -- components: None messages: 92642 nosy: ideasman42 severity: normal status:

[issue6913] Py_SetPythonHome incorrectly documented py3.x (rev 74792)

Benjamin Peterson added the comment: Fixed in r74794 and r74795. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue6913] Py_SetPythonHome incorrectly documented py3.x (rev 74792)

New submission from Campbell Barton : Py_SetPythonHome takes a *wchar_t not a *char, this is obvious from looking at the header, However I tried using this function and couldn't get it working until I made the home variable a static string. when looking at the source this is obvious, but should

[issue6247] should we include argparse

Jesse Noller added the comment: Armin; if you are serious in wanting to help out with the stdlib and core work, feel free to help us discuss this over on the stdlib-sig (http://mail.python.org/pipermail/stdlib-sig/2009-September/000398.html) or help commit patches and fixes for all of the mod

[issue1115886] os.path.splitext don't handle unix hidden file correctly

Senthil added the comment: Alexandru: You commented on a closed issue. If you see any problem with mimetypes.guess_type() w.r.t to .ogg files, please open a new open stating your problem. -- nosy: +orsenthil ___ Python tracker

[issue6247] should we include argparse

Gregory P. Smith added the comment: On Mon, Sep 14, 2009 at 11:15 AM, Armin Ronacher wrote: > > Armin Ronacher added the comment: > >> @Armin: Doesn't that argument apply to *any* library proposed for >> inclusion in the standard library? By which logic we should never add >> anything to the s

[issue6412] Titlecase as defined in Unicode Case Mappings not followed

Christoph Burgmer added the comment: I should add that I didn't include the two header files generated by Tools/unicode/makeunicodedata.py -- ___ Python tracker ___ _

[issue6412] Titlecase as defined in Unicode Case Mappings not followed

Christoph Burgmer added the comment: Implementing full patch solving it the old way (UTR#21). The correct way for the latest Unicode version would be to implement the word breaking algorithm described in (UAX#29) [1] first. [1] http://www.unicode.org/reports/tr29/#Word_Boundaries -- A

[issue6247] should we include argparse

Michael Foord added the comment: He has a few important feature requests to deal with as well. -- ___ Python tracker ___ ___ Python-bu

[issue6247] should we include argparse

Georg Brandl added the comment: I think optparse just got a new maintainer. -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-b

[issue6247] should we include argparse

Armin Ronacher added the comment: > It must be convenient to operate in an environment where you can > install new software so easily Armin. Trust me, it is. > For others (including me), the actual package installation is the > least of our hassles and anything that helps us avoid dealing wit

[issue6247] should we include argparse

Nick Coghlan added the comment: It must be convenient to operate in an environment where you can install new software so easily Armin. For those of us that operate in environments where every new piece of software has to go through contracts review to ensure that we can both license it for our

[issue6247] should we include argparse

Michael Foord added the comment: Command line parsing is a basic need, including amongst other standard library modules. argparse has many advantages over optparse (not the least of which is that it has an active maintainer). Several of these features *can't* be added to optparse whilst maintain

[issue6247] should we include argparse

R. David Murray added the comment: I disagree. I think option and argument parsing belongs in the standard (batteries included) library, regardless of how well external package management works. argparse has the advantage over optparse that it has an active maintainer. What we do about the

[issue6247] should we include argparse

Armin Ronacher added the comment: > I can respect that viewpoint. So what do you propose to do with > existing modules like optparse that aren't required to make platform > independent applications and are out of date and basically > unmaintained? One option would be to remove them, but that's p

[issue6247] should we include argparse

Steven Bethard added the comment: [snip] > Fix packaging and do not dump useless stuff into the standard library to > make it appear more modern. Decentralization is modern, not replacing > modules in the stdlib. I can respect that viewpoint. So what do you propose to do with existing modules l

[issue6281] Bug in hashlib

Daniel Eloff added the comment: I have indeed seen __get_builtin_constructor fail in practice, in the python build in the Ubuntu repository if IIRC. I seem to recall the problem was that python was using a version of openssl that didn't include all of hash algorithms, probably because a pytho

[issue6247] should we include argparse

Armin Ronacher added the comment: > @Armin: Doesn't that argument apply to *any* library proposed for > inclusion in the standard library? By which logic we should never add > anything to the standard library ever again. That's what I say. Do not add anything to the stdlib that is not needed to

[issue6247] should we include argparse

Steven Bethard added the comment: @Armin: Doesn't that argument apply to *any* library proposed for inclusion in the standard library? By which logic we should never add anything to the standard library ever again. Surely you don't mean that, so could you be more specific on what you think is pa

[issue6247] should we include argparse

Armin Ronacher added the comment: Why does this have to go into the standard library? People that want to use it can still install it from PyPI. -sys.maxint from me. -- nosy: +aronacher ___ Python tracker _

[issue6912] Add 'with' block support to Tools/Scripts/pindent.py

New submission from Terry J. Reedy : As reported by Miles Kaufmann on python-list, Tools/Scripts/pindent.py has not been updated to support 'with' blocks. I suspect that it would be sufficient to add ",'with'" to start = 'if', 'while', 'for', 'try', 'def', 'class' Since there are no "next['def

[issue6234] cgi.FieldStorage is broken when given POST data

Michal Hordecki added the comment: It is because FieldStorage requires str, whereas wsgi.input gives bytes. You can always wrap environ['wsgi.input'] in TextIOWrapper. -- nosy: +MHordecki ___ Python tracker __

[issue6909] python 3.1 - filecmp.cmp exception based on file name

R. David Murray added the comment: You should try removing the try/except to find out which line is actually throwing the error. I think you will find that it is the print statement. -- nosy: +r.david.murray ___ Python tracker

[issue6909] python 3.1 - filecmp.cmp exception based on file name

jeff deifik added the comment: Forgive all the print statements. Here is the result of running this: floup:files are ['./Julio_Iglesias-Un_Hombre_Solo-05-Qu\udce9_no_se_rompa_la_noche.mp3', '/cygdrive/j/music/bea/Julio_Iglesias-Un_Hombre_Solo-05-Qu\udce9_no_se_rompa_la_noche.mp3'] l is greater

[issue6911] Document changes in asynchat

Robert Lehmann added the comment: Excuse me -- fifo and simple_producer are indeed documented and need a deprecation notice. New patch attached (plus reworded paragraph about async_chat.__init__). -- Added file: http://bugs.python.org/file14889/asynchat-docs.patch _

[issue6911] Document changes in asynchat

Changes by Georg Brandl : -- assignee: georg.brandl -> josiahcarlson nosy: +josiahcarlson ___ Python tracker ___ ___ Python-bugs-list m

[issue6911] Document changes in asynchat

New submission from Robert Lehmann : asynchat.async_chat grew a _collect_incoming and a _get_data method in 2.6. The constructor has been extended to conform to asyncore.dispatcher's. This should be documented. Apart from that, fifo and simple_producer have been deprecated, and async_chat.ac_out

[issue6909] python 3.1 - filecmp.cmp exception based on file name

Benjamin Peterson added the comment: Could you paste your code? -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-lis

[issue6908] Minor markup error in hashlib docs

Georg Brandl added the comment: Fixed in r74793. -- resolution: -> accepted status: open -> closed ___ Python tracker ___ ___ Python-

[issue6910] 1-char typo in language reference doc of import

New submission from Mitchell Model : Just before 6.11.1 of the Language Reference: "Attempting to use it in class for function definitions" should be "or" not "for" -- assignee: georg.brandl components: Documentation messages: 92614 nosy: MLModel, georg.brandl severity: normal status:

[issue6909] python 3.1 - filecmp.cmp exception based on file name

New submission from jeff deifik : I am calling filecmp.cmp on a two files, one of which has a name of './Julio_Iglesias-Un_Hombre_Solo-05-Qu\udce9_no_se_rompa_la_noche.mp3' I get an exception from filecmp.cmp saying: 'ascii' codec can't encode character '\udce9' in position 37: ordinal not in

[issue6908] Minor markup error in hashlib docs

New submission from Robert Lehmann : The documentation for hashlib.hash.digest_size/block_size (notice the hash) renders as documentation for hashlib.*_size, which does not exist. Fixed by explicitly declaring membership; patch attached. -- assignee: georg.brandl components: Documentati

[issue6909] python 3.1 - filecmp.cmp exception based on file name

Changes by R. David Murray : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list maili

[issue6909] python 3.1 - filecmp.cmp exception based on file name

jeff deifik added the comment: Oops, you are correct, my mistake. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-lis

[issue6910] 1-char typo in language reference doc of import

Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue6574] List the __future__ features in a table

Changes by Robert Lehmann : Added file: http://bugs.python.org/file14886/future.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue6574] List the __future__ features in a table

Georg Brandl added the comment: I added a reference in line 13, changed the table header not to use colspans (the latex writer doesn't support that), and committed as r74791. -- assignee: ezio.melotti -> georg.brandl status: open -> closed ___ Python

[issue6574] List the __future__ features in a table

Robert Lehmann added the comment: Implemented proposed changes. Additionally, I'd change line 13 to state either "future statements" or "`future`:ref:" instead of "future_statements", which does not make sense in normal, unmarked text. -- Added file: http://bugs.python.org/file14885/fu

[issue1019715] distutils ignores configure's --includedir

Senthil added the comment: Yes, this is a duplicate of issue858809 and tarek is assigned to that one too. -- nosy: +orsenthil resolution: -> duplicate status: open -> closed ___ Python tracker _

[issue6902] Built-in types format incorrectly with 0 padding.

Eric Smith added the comment: complex will also need to be addressed. The second error message is misleading, for the same reason the formatting on float and int is incorrect: >> format(3-2j, "0<30") Traceback (most recent call last): File "", line 1, in ValueError: Zero padding is not allow

[issue6267] Cumulative patcc:h to http and xmlrpc

STINNER Victor added the comment: Ok, all duplicate issues are now closed (#1613573, #1767370, #2076). -- ___ Python tracker ___ ___ P

[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive

Changes by STINNER Victor : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue6907] xmlrpclib.make_connection() is not thread safe

STINNER Victor added the comment: @krisvale: You changed the resolution to invalid, but you leaved the state unchanged (open). Ok, I agree that the stdlib is not thread safe, and so I closed this issue. I saw this issue as a regression because the previous version (using a different socket for

[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive

Kristján Valur Jónsson added the comment: Yes, it is indeed a duplicate. -- nosy: +krisvale resolution: -> duplicate ___ Python tracker ___ __

[issue6907] xmlrpclib.make_connection() is not thread safe

Kristján Valur Jónsson added the comment: the xmlrpclib.ServerProxy is not thread safe, no. Nor is it designed to be. the documentation never claims that it is and the fact that the old version was (due to a new HTTPConnection being created each time) is a coincidence than a design feature.

[issue6791] httplib read status memory usage

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue6267] Cumulative patcc:h to http and xmlrpc

STINNER Victor added the comment: Another duplicate: #1613573. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue1613573] xmlrpclib ServerProxy uses old httplib interface

Changes by STINNER Victor : -- resolution: -> duplicate status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue1613573] xmlrpclib ServerProxy uses old httplib interface

STINNER Victor added the comment: I consider this issue as a duplicate of #6267 which is already fixed (commited). Reopen the issue if I'm wrong ;-) See also #2076 and #1767370 (other duplicates). -- nosy: +haypo ___ Python tracker

[issue6267] Cumulative patcc:h to http and xmlrpc

STINNER Victor added the comment: There are duplicate issues about HTTP/1.1: #2076, #1767370. -- ___ Python tracker ___ ___ Python-bug

[issue2076] xmlrpclib closes connection after each call

STINNER Victor added the comment: I think that xmlrpclib is already fixed in Python trunk. See #6267. I consider this issue as a duplicate of #6267. -- nosy: +haypo resolution: -> duplicate status: open -> closed ___ Python tracker

[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive

STINNER Victor added the comment: I think that this issue is a duplicate of #6267 which is already commited to Python trunk. #6267 is a superset of #6099. See also #2076 (another duplicate of #6267 ?). -- nosy: +haypo ___ Python tracker

[issue6267] Cumulative patcc:h to http and xmlrpc

STINNER Victor added the comment: I opened a bug report introduced by this issue: #6907: xmlrpclib.make_connection() is not thread safe. -- nosy: +haypo ___ Python tracker ___ __

[issue6907] xmlrpclib.make_connection() is not thread safe

New submission from STINNER Victor : The issue #6099 (part of #6267 superset) introduced a regression: xmlrpclib.make_connection() is not thread safe. If xmlrpclib is used in two threads, the socket is shared, but it doesn't any lock, and so data will be mixed between the two requets. It becomes

[issue6905] inspect.getargspec(print) fails

Georg Brandl added the comment: This is not an issue, but a fundamental restriction of what getargspec() can do. C function signatures are not introspectable, because basically every C function can be thought of as defined as either def func(*args) or def func(*args, **kwargs) and is f

[issue6906] Tkinter sets an unicode environment variable on win32

New submission from Michał Pasternak : Hi, I was recently playing with txAmpoule & Twisted on win32. When Twisted spawns processess, the environment is checked for unicode variables (and an exception is raised in case of). Then it came to my attention, that importing Tkinter on win32 sets an

[issue6897] imaplib fails during login

Marcin Bachry added the comment: Looks like duplicate of #6734. -- nosy: +marcin.bachry ___ Python tracker ___ ___ Python-bugs-list ma

[issue6784] byte/unicode pickle incompatibilities between python2 and python3

RonnyPfannschmidt added the comment: i'll try to add some tests now hopefully i can get rid of the implicit badness like trying to coerce bytes to unicode in unpickle and storing bytes as list in pickle for protocol < 3 -- ___ Python tracker