[issue7188] optionxform documentation confusing

New submission from Martin v. Löwis : In http://stackoverflow.com/questions/1611799/preserve-case-in-configparser, somebody is confused about adjusting ConfigParser.optionxform. The documentation is indeed confusing, in particular by claiming that you should "set" it to "str()". Even if you get

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

Georg Brandl added the comment: Not really, that was the last thing to get this issue closed. -- ___ Python tracker ___ ___ Python-bug

[issue7188] optionxform documentation confusing

Georg Brandl added the comment: Thanks, fixed in r75623. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Py

[issue6670] Printing the 'The Python Tutorial'

brimac added the comment: Georg, Ezio Many Thanks brimac 2009/10/22 Georg Brandl > > Georg Brandl added the comment: > > OK, fixed in Sphinx, and in the Python stylesheet in r75617. > > -- > resolution: -> fixed > status: open -> closed > > ___ >

[issue7189] struct.calcsize returns strange size

New submission from Igor Mikushkin : I think in second case struct size should be 53. In [31]: struct.calcsize('ihhi35scc') Out[31]: 49 In [32]: struct.calcsize('ihhi35scci') Out[32]: 56 -- components: Library (Lib) messages: 94379 nosy: igor.mikushkin severity: normal status: open tit

[issue7189] struct.calcsize returns strange size

Mark Dickinson added the comment: I think the calcsize result is correct here. With the native struct format, padding is included in the struct. In the second case, there are three bytes of padding after the 'cc' and before the 'i'. This keeps the 'i' aligned on a 4-byte boundary. If you

[issue7187] importlib/_bootstrap.py write_bytecode raises an IOError if it can't open the .pyc file for writing

Antoine Pitrou added the comment: Wouldn't the problem disappear, though, if tkinter/__init__.py didn't claim to be fresher than tkinter/__init__.pyc? Also, it would make the pyc/pyo files actually useful, rather than having Python recompile the source files again and again. (see the modificatio

[issue3488] Provide compress/uncompress functions on the gzip module

Anand B Pillai added the comment: Can we include this for the next release ? -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue3488] Provide compress/uncompress functions on the gzip module

Changes by Antoine Pitrou : -- priority: -> normal stage: -> patch review versions: +Python 3.2 -Python 3.0 ___ Python tracker ___ __

[issue6882] uuid creates zombies

Eric Smith added the comment: Changed py3k version to use contextlib.closing in r75625. -- status: open -> closed ___ Python tracker ___ _

[issue6882] uuid creates zombies

Changes by Eric Smith : -- priority: -> normal type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue7150] datetime operations spanning MINYEAR give bad results

Anand B Pillai added the comment: The issue is present in Python 3.0 and 2.5 as well. Python 2.5.1 (r251:54863, Jul 17 2008, 13:21:31) [GCC 4.3.1 20080708 (Red Hat 4.3.1-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> t0=datetime.date

[issue7190] TCP/IP?

New submission from Justin : Mac OS X IBook G4 PowerPC when running target.py it works fine until i close the app without ending the process. (before 'q' is entered by the user). sometimes python will not allow the user to click in the window and have the ability to type after running the target

[issue7191] Odd behaviour with zlib.decompressobj optional parameter "wbits"

New submission from Anand B Pillai : >>> import zlib >>> help(zlib.decompressobj) Help on built-in function decompressobj in module zlib: decompressobj(...) decompressobj([wbits]) -- Return a decompressor object. Optional arg wbits is the window buffer size. I experimented with this pa

[issue7192] webbrowser.get("firefox") does not work on Mac with installed Firefox

New submission from Andrew Dalke : I have Firefox and Safari installed on my Mac. Safari is the default. I wanted to try out Crunchy (http://code.google.com/p/crunchy/). It's developed under Firefox and does not work under Safari. I tried. ;) It starts the web browser with the following.

[issue7187] importlib/_bootstrap.py write_bytecode raises an IOError if it can't open the .pyc file for writing

Dave Malcolm added the comment: Aha! Thanks pitrou, looks like I managed to mess up my packaging (I was wondering why no no-one else had run into this, looks like no-one else made this mistake!). -- ___ Python tracker

[issue7193] Popen blocks program from another thread

New submission from Dan Griffin : When I create a thread that does a Popen it blocks the entire program. I have attached a simple sample program. Whether I do Popen.wait or Popen.poll the program blocks. I have done this on OSX 10.5 and 10.6. I have not yet tried ussing the multiprocessing module

[issue7193] Popen blocks program from another thread

R. David Murray added the comment: You are calling the 'run' method of your test class, which runs the subprocess in the main thread. Try calling t.start() instead. -- nosy: +r.david.murray priority: -> low resolution: -> invalid stage: -> committed/rejected status: open -> closed

[issue7193] Popen blocks program from another thread

Dan Griffin added the comment: You are right, sorry to waste your time. -- status: closed -> open ___ Python tracker ___ ___ Python-bu

[issue7193] Popen blocks program from another thread

Changes by Dan Griffin : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue7194] test_thread is flaky

New submission from Antoine Pitrou : test_thread sometimes tries to release an unacquired mutex. It is easier to reproduce when using the "-j" option (on trunk and py3k, since the option doesn't exist on 2.6/3.1): ./python -m test.regrtest -j4 test_thread test_thread test_thread test_thread test

[issue7194] test_thread is flaky

Antoine Pitrou added the comment: Fixed in trunk, py3k and 3.1. Waiting for 2.6 to unfreeze before merging there. -- assignee: -> pitrou resolution: -> accepted stage: needs patch -> committed/rejected versions: -Python 2.7, Python 3.1, Python 3.2 ___

[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath

New submission from Jason R. Coombs : A simple test fails: Python 2.6.3 (r263rc1:75186, Oct 2, 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32 >>> import os >>> os.path.relpath('\\bar', 'd:\\') Traceback (most recent call last): File "", line 1, in File "C:\python\lib\ntpath.py", line

[issue1578269] Add os.link() and os.symlink() and os.path.islink() support for Windows

Jason R. Coombs added the comment: After some in-depth analysis, I determined the following: 1) The new symlink-aware os.stat has to find the target of a symlink to properly function. 2) The previously-proposed patch uses GetFilenameByHandle in os.stat to find the target, but this fails when a

[issue6986] _json crash on scanner/encoder initialization error

STINNER Victor added the comment: pitrou> Unit tests are definitely desireable! done pitou> I would also like the "alternate approach" fix, pitou> it would probably be cleaner. done. See the new patch. -- Added file: http://bugs.python.org/file15190/json-crash.patch ___

[issue1087418] long int bitwise ops speedup (patch included)

Changes by Tracy Poff : -- nosy: +sopoforic ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue6986] _json crash on scanner/encoder initialization error

Antoine Pitrou added the comment: There is actually a Lib/json/tests/ directory contain all JSON tests, you should add yours there. -- ___ Python tracker ___

[issue6986] _json crash on scanner/encoder initialization error

STINNER Victor added the comment: pitrou> There is actually a Lib/json/tests/ directory contain all pitrou> JSON tests, you should add yours there. My patch creates the file Lib/json/tests/test__json.py. Do you mean that I should add the new tests to an existing file? Which one? -- _

[issue6986] _json crash on scanner/encoder initialization error

Antoine Pitrou added the comment: Ah, my bad, I thought it created the file in Lib/test. The tests probably need to be skipped if _json can't be imported, though. (the _json accelerators are just an implementation detail) -- ___ Python tracker

[issue1087418] long int bitwise ops speedup (patch included)

Gregory Smith added the comment: Actually, my view for 3.x is this: I do agree hugely with the 'top level' decision to only have one type that handles everything, and obviously the easiest way to get there is to just use the existing long type. However, though the rad-2^15 implementation of the

[issue7196] Clarify str.split() behavior

New submission from Gabriel Genellina : Clarify str.split() behavior; see discussion at http:// comments.gmane.org/gmane.comp.python.general/641120 -- assignee: georg.brandl components: Documentation files: stdtypes.diff keywords: patch messages: 94401 nosy: gagenellina, georg.brandl sev

[issue7196] Clarify str.split() behavior

Changes by Raymond Hettinger : -- assignee: georg.brandl -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list ma

[issue1087418] long int bitwise ops speedup (patch included)

Antoine Pitrou added the comment: The type is an important performance factor but most uses of it are for small ints (< 2**32 or 2**64), so your approach wouldn't make much of a difference. Besides, there are already some improvements in the py3k branch (for example, longs now use 30-bit "digits