[issue6784] byte/unicode pickle incompatibilities between python2 and python3
RonnyPfannschmidt ronny.pfannschm...@gmx.de 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 rep...@bugs.python.org http://bugs.python.org/issue6784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6897] imaplib fails during login
Marcin Bachry hegel...@gmail.com added the comment: Looks like duplicate of #6734. -- nosy: +marcin.bachry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6906] Tkinter sets an unicode environment variable on win32
New submission from Michał Pasternak michal@gmail.com: 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 environment variable, which value is Unicode. Just have a look: C:\python ActivePython 2.6.2.2 (ActiveState Software Inc.) based on Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import Tkinter import os os.environ['TK_LIBRARY'] u'C:\\Python26\\tcl\\tk8.5' ^Z Why is it Unicode? Does it really have to be? Do we need that environment variable at all? On Linux, it is different: r...@foo:~# python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type help, copyright, credits or license for more information. import Tkinter import os os.environ['TK_LIBRARY'] Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.6/UserDict.py, line 22, in __getitem__ raise KeyError(key) KeyError: 'TK_LIBRARY' -- components: Tkinter messages: 92594 nosy: dotz severity: normal status: open title: Tkinter sets an unicode environment variable on win32 versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6905] inspect.getargspec(print) fails
Georg Brandl ge...@python.org 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 free to do what it wants with the args and kwargs. -- nosy: +georg.brandl resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6907] xmlrpclib.make_connection() is not thread safe
New submission from STINNER Victor victor.stin...@haypocalc.com: 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 worse when I use SSL (pyopenssl or m2crypto). A possible solution is to use a different socket for each thread. Note: I really love #6099, it was exactly what I needed :-) -- components: Extension Modules messages: 92596 nosy: haypo severity: normal status: open title: xmlrpclib.make_connection() is not thread safe type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6267] Cumulative patcc:h to http and xmlrpc
STINNER Victor victor.stin...@haypocalc.com added the comment: I opened a bug report introduced by this issue: #6907: xmlrpclib.make_connection() is not thread safe. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
STINNER Victor victor.stin...@haypocalc.com 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 rep...@bugs.python.org http://bugs.python.org/issue1767370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2076] xmlrpclib closes connection after each call
STINNER Victor victor.stin...@haypocalc.com 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 rep...@bugs.python.org http://bugs.python.org/issue2076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6267] Cumulative patcc:h to http and xmlrpc
STINNER Victor victor.stin...@haypocalc.com added the comment: There are duplicate issues about HTTP/1.1: #2076, #1767370. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1613573] xmlrpclib ServerProxy uses old httplib interface
STINNER Victor victor.stin...@haypocalc.com 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 rep...@bugs.python.org http://bugs.python.org/issue1613573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1613573] xmlrpclib ServerProxy uses old httplib interface
Changes by STINNER Victor victor.stin...@haypocalc.com: -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1613573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6267] Cumulative patcc:h to http and xmlrpc
STINNER Victor victor.stin...@haypocalc.com added the comment: Another duplicate: #1613573. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6791] httplib read status memory usage
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6791 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6907] xmlrpclib.make_connection() is not thread safe
Kristján Valur Jónsson krist...@ccpgames.com 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. In my own client code I use a pool of ServerProxy objects for each thread to claim and use one at a time. This way I can have many simultaneous requests to the same server going. You can also create your own lock and share a ServerProxy among threads. Also note that HTTPConnection is not thread safe either. And in general, class instances in the lib are not thread safe unless explicitly documented to be so. -- nosy: +krisvale resolution: - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Yes, it is indeed a duplicate. -- nosy: +krisvale resolution: - duplicate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1767370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6907] xmlrpclib.make_connection() is not thread safe
STINNER Victor victor.stin...@haypocalc.com 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 each XML-RPC request) was thread sae (even if it wasn't designed to be thread safe) :-) -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Changes by STINNER Victor victor.stin...@haypocalc.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1767370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6267] Cumulative patcc:h to http and xmlrpc
STINNER Victor victor.stin...@haypocalc.com added the comment: Ok, all duplicate issues are now closed (#1613573, #1767370, #2076). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6902] Built-in types format incorrectly with 0 padding.
Eric Smith e...@trueblade.com 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, 030) Traceback (most recent call last): File stdin, line 1, in module ValueError: Zero padding is not allowed in complex format specifier format(3-2j, 0=30) Traceback (most recent call last): File stdin, line 1, in module ValueError: Zero padding is not allowed in complex format specifier But this is correct: format(3-2j, =30) Traceback (most recent call last): File stdin, line 1, in module ValueError: '=' alignment flag is not allowed in complex format specifier It's not 0 padding that's not allowed, it's the implied sign alignment when using 0 (without a specified alignment). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1019715] distutils ignores configure's --includedir
Senthil orsent...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue1019715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6574] List the __future__ features in a table
Robert Lehmann lehman...@gmail.com 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/future.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6574 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6574] List the __future__ features in a table
Georg Brandl ge...@python.org 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 tracker rep...@bugs.python.org http://bugs.python.org/issue6574 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6574] List the __future__ features in a table
Changes by Robert Lehmann lehman...@gmail.com: Added file: http://bugs.python.org/file14886/future.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6574 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6910] 1-char typo in language reference doc of import
Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6909] python 3.1 - filecmp.cmp exception based on file name
jeff deifik j...@jeffunit.com added the comment: Oops, you are correct, my mistake. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6908] Minor markup error in hashlib docs
New submission from Robert Lehmann lehman...@gmail.com: 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: Documentation files: hashlib-docs.patch keywords: patch messages: 92611 nosy: georg.brandl, lehmannro severity: normal status: open title: Minor markup error in hashlib docs versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14887/hashlib-docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6908 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6909] python 3.1 - filecmp.cmp exception based on file name
New submission from jeff deifik j...@jeffunit.com: 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 range(128) I do not understand why filecmp.cmp cares what the encoding of the names of the files are, as long as they are valid files. I would think filecmp.cmp would only care about the content of the files. When I give it pure ascii names, filecmp.cmp works file, however some of my files have udce9 encoded names. This is on a windows xp machine running cygwin (linux emulation). I built and compiled python3.1 from source. -- messages: 92613 nosy: jdeifik severity: normal status: open title: python 3.1 - filecmp.cmp exception based on file name type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6909] python 3.1 - filecmp.cmp exception based on file name
Benjamin Peterson benja...@python.org added the comment: Could you paste your code? -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6911] Document changes in asynchat
Changes by Georg Brandl ge...@python.org: -- assignee: georg.brandl - josiahcarlson nosy: +josiahcarlson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6911 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6911] Document changes in asynchat
New submission from Robert Lehmann lehman...@gmail.com: 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_buffer was replaced by async_chat.incoming. These are internals and were never documented. A patch is attached. -- assignee: georg.brandl components: Documentation files: asynchat-docs.patch keywords: patch messages: 92616 nosy: georg.brandl, lehmannro severity: normal status: open title: Document changes in asynchat versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14888/asynchat-docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6911 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6909] python 3.1 - filecmp.cmp exception based on file name
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org http://bugs.python.org/issue6909 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6234] cgi.FieldStorage is broken when given POST data
Michal Hordecki mhorde...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue6234 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6908] Minor markup error in hashlib docs
Georg Brandl ge...@python.org added the comment: Fixed in r74793. -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6908 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6909] python 3.1 - filecmp.cmp exception based on file name
jeff deifik j...@jeffunit.com 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 than 1
i and j 0 1
two files 0 1
two files ./Jul /cygd
try two files 0 1
try two files (5) ./Jul /cygd
try two files exception = 'ascii' codec can't encode character '\udce9'
in position 37: ordinal not in range(128)
# Compare all files with the same size to each other
def look_through_table(the_tab):
global Options
# loop through file sizes that
for size in list(the_tab.keys()):
files = the_tab[size] # List of all files with same size
l = len(files)
print('floup:files are', files)
if l 1:
print('l is greater than 1')
for i in range(l):
for j in range(i + 1, l):
print('i and j', i, j)
print('two files', i, j)
print('two files', files[i][0:5], files[j][0:5])
if Options.name == False or \
os.path.basename(files[i]) ==
os.path.basename(files[j]):
# print 'cmp_two_files', files[i], files[j], \
#cmp_two_files(files[i], files[j])
try:
print('try two files', i, j)
print('try two files (5)', files[i][0:5],
files[j][0:5])
print('try two files', files[i], files[j])
if filecmp.cmp(files[i], files[j], False):
print('MATCHED')
print(files[i])
print( and , files[j])
else:
print('DID NOT MATCH')
except Exception as inst:
print('exception = ', inst)
pass
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6909
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6911] Document changes in asynchat
Robert Lehmann lehman...@gmail.com 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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6911 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6910] 1-char typo in language reference doc of import
New submission from Mitchell Model m...@acm.org: 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: open title: 1-char typo in language reference doc of import versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6912] Add 'with' block support to Tools/Scripts/pindent.py
New submission from Terry J. Reedy tjre...@udel.edu: 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'/'class'] lines, I suspect none is needed for 'with' either. -- components: Demos and Tools messages: 92622 nosy: tjreedy severity: normal status: open title: Add 'with' block support to Tools/Scripts/pindent.py type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Armin Ronacher armin.ronac...@active-4.com 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 rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Steven Bethard steven.beth...@gmail.com 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 particularly inappropriate about argparse? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Armin Ronacher armin.ronac...@active-4.com 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 keep applications platform independent. argparse adds zero value to x-platform development. Things I consider good for a stdlib: * portable filesystem notification hooks * stuff like os.path * distutils * socket library Stuff that should not go into the stdlib: * xml parsers * command line parsers (one is enough, and that should be *stable* not replaced later with something like argparse) 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6281] Bug in hashlib
Daniel Eloff dan.el...@gmail.com 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 python library or the process hosting python also had a dependency on libssl and had it loaded already. But there is also the issue that Python is a language with many implementations now, and in fact, it's unlikely that CPython will remain the defacto implementation forever. Having a more robust hashlib.py that can handle missing algorithm implementations makes a lot of sense (.NET for example has no implementation of some of the more esoteric SHA hashes.) I remember that in the early days of IronPython, hashlib.py had to be completely replaced to be used. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6281 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Steven Bethard steven.beth...@gmail.com 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 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 probably too drastic. Another option would be to add documentation to them warning that they're out of date and pointing users to alternative external libraries. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Armin Ronacher armin.ronac...@active-4.com 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 probably too drastic. Documentation and a new kind of deprecation warning. It's documentation-deprecated in one version, one later a real deprecation warning appears that sticks around for a couple of versions. The documentation would explain how to hide the deprecation warning and tells the user to better use more modern alternatives. This of course requires packaging to work flawlessly first which I consider to be high priority. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
R. David Murray rdmur...@bitdance.com 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 stuff in the stdlib that is no longer maintained is a different discussion, IMO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Michael Foord mich...@voidspace.org.uk 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 maintaining backwards compatibility, which is what prompted Steven to create argparse in the first place. Improvements that I am aware of include: - handling of standard Windows way of specifying options - sub-commands - handling of positional arguments I had to implement my own technique for handling a sub-command in recent unittest changes that would have been much simpler if argparse were in the standard library. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Nick Coghlan ncogh...@gmail.com 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 own purposes and also subsequently transfer those licenses to our customers, having things in the standard library is a *huge* benefit. This is the usual batteries included vs better packaging argument. For developers in an environment where adding new packages is a low overhead operation, adding something to the stdlib isn't a big gain for them while better packaging tools are awesome. For others (including me), the actual package installation is the least of our hassles and anything that helps us avoid dealing with the lawyers is a big gain. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Armin Ronacher armin.ronac...@active-4.com 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 with the lawyers is a big gain. So you're suggesting Python should suffer because some companies have a weird legal department? @Michael Foord: I totally agree that argument parsing is something that *should* be in the standard library because everybody needs it. However at the same time it's something I could imagine comes from an external source. I would rather maintain optparse myself for python.org than seeing another argument parsing library in the stdlib so that everybody has to switch over because the Python devs did not find someone to maintain it. The stdlib is very often unmaintained for large parts; we can't just replace a module because the developer got bored... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Georg Brandl ge...@python.org added the comment: I think optparse just got a new maintainer. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Michael Foord mich...@voidspace.org.uk added the comment: He has a few important feature requests to deal with as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6412] Titlecase as defined in Unicode Case Mappings not followed
Christoph Burgmer cburg...@ira.uka.de 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 -- Added file: http://bugs.python.org/file14890/unicodeobject.titlecase.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6412 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6412] Titlecase as defined in Unicode Case Mappings not followed
Christoph Burgmer cburg...@ira.uka.de added the comment: I should add that I didn't include the two header files generated by Tools/unicode/makeunicodedata.py -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6412 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Gregory P. Smith g...@krypto.org added the comment: On Mon, Sep 14, 2009 at 11:15 AM, Armin Ronacher rep...@bugs.python.org wrote: Armin Ronacher armin.ronac...@active-4.com 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 keep applications platform independent. argparse adds zero value to x-platform development. By that logic we should remove getopt and optparse, Things I consider good for a stdlib: * portable filesystem notification hooks * stuff like os.path * distutils * socket library Stuff that should not go into the stdlib: * xml parsers * command line parsers (one is enough, and that should be *stable* not replaced later with something like argparse) One is only enough if its a useful one. argparse can be that one. optparse and getopt are both sorely lacking. If anything deprecate getopt and optparse so that they're gone in 3.4. By your argument we shouldn't even have one command line parser because it does nothing to cross platform support. Please DO NOT drag an issue asking to add a useful library to the set of batteries included into the packaging decentralization flamewar. There are is a large python user base that can never code that does not come as part of python itself for one or more of legal and technical reasons. This issue is not the place to debate how stupid anyone thinks that concept is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1115886] os.path.splitext don't handle unix hidden file correctly
Senthil orsent...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue1115886 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Jesse Noller jnol...@gmail.com 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 modules that are growing long in the tooth and need help. -- nosy: +jnoller ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6913] Py_SetPythonHome incorrectly documented py3.x (rev 74792)
New submission from Campbell Barton ideasma...@gmail.com:
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 be documented...
void
Py_SetPythonHome(wchar_t *home)
{
default_home = home;
}
--
assignee: georg.brandl
components: Documentation
files: Py_SetPythonHome_doc.diff
keywords: patch
messages: 92640
nosy: georg.brandl, ideasman42
severity: normal
status: open
title: Py_SetPythonHome incorrectly documented py3.x (rev 74792)
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14891/Py_SetPythonHome_doc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6913
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6913] Py_SetPythonHome incorrectly documented py3.x (rev 74792)
Benjamin Peterson benja...@python.org added the comment: Fixed in r74794 and r74795. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6913 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6914] Py_SetPythonHome, undocumented behavoir
New submission from Campbell Barton ideasma...@gmail.com: 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: open title: Py_SetPythonHome, undocumented behavoir type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6915] os.listdir inconsistenly releases the GIL on win32
New submission from Ryan Kelly r...@rfk.id.au: 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 keywords: patch messages: 92643 nosy: rfk severity: normal status: open title: os.listdir inconsistenly releases the GIL on win32 type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14892/listdir_gil.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6911] Document changes in asynchat
Robert Lehmann lehman...@gmail.com 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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6911 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6916] Remove deprecated items from asynchat
New submission from Robert Lehmann lehman...@gmail.com: 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 issue6911 so I'd like that to settle first, otherwise this might result in a merge conflict. -- assignee: georg.brandl components: Documentation, Library (Lib), Tests files: asynchat.patch keywords: patch messages: 92645 nosy: georg.brandl, lehmannro severity: normal status: open title: Remove deprecated items from asynchat versions: Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14894/asynchat.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
