[issue6595] Make Decimal constructor accept all unicode decimal digits in input.
Mark Dickinson dicki...@gmail.com added the comment: Committed to py3k in r74279, release31-maint in r74280. Leaving open for backport to 2.x. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6595 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6595] Make Decimal constructor accept all unicode decimal digits in input.
Mark Dickinson dicki...@gmail.com added the comment: Backported to trunk and release26-maint in r74281 and r74282. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6595 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6625] UnicodeEncodeError on pydoc's CLI
New submission from Christoph Burgmer cburg...@ira.uka.de: pydoc fails with a UnicodeEncodeError for properly specified Unicode docstrings (u...) on the command line interface. See attached patch that encodes the output with the system's encoding. -- components: Extension Modules files: unicode.patch keywords: patch messages: 91182 nosy: christoph severity: normal status: open title: UnicodeEncodeError on pydoc's CLI versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file14626/unicode.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6625 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2053] IDLE - standardize dialogs
Guilherme Polo ggp...@gmail.com added the comment: I have reviewed the latest patch now, it is nice in general but I dislike the idea of increasing even more EditorWindow. I would really prefer to put this somewhere else, like.. idlelib/dialogs.py. Also, I'm inclined to remove this master/parent hiding and continue making it explicit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6619] Remove duplicated function in Lib/inspect.py
Mark Dickinson dicki...@gmail.com added the comment: Thanks for the report! Fixed in r74285 (trunk), r74286 (release26-maint), r74287 (py3k) and r74288 (release31-maint). -- nosy: +marketdickinson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6604] test_distutils subtest test_get_exe_bytes fails depending on execution order
Tarek Ziadé ziade.ta...@gmail.com added the comment: This was fixed in r71759 and backported in the 2.6 branch in r71765, thanks for the feedback! -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6604 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6620] Variable may be used before first being assigned to in Lib/locale.py
Mark Dickinson dicki...@gmail.com added the comment: So this can happen only if grouping is [0] (or an equivalent iterable). Since this is an invalid grouping, I think the appropriate response would be for _grouping_intervals([0]) to raise an exception (which is what it currently does as soon as you iterate over the result, though this is possibly not by design. :) Vincent, does the attached patch (_grouping_intervals.patch, against py3k) silence the pylint warning? -- nosy: +marketdickinson Added file: http://bugs.python.org/file14627/_grouping_intervals.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Tarek Ziadé ziade.ta...@gmail.com added the comment: The vcvarsall.bat eror is unrelated to the error James and Eric are mentioned, which is another error fixed in the revision Hagen points. Lenard, could you re-run it under the latest 2.6 version with the global option --verbose please ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2698 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6555] distutils config file should have the same name on both platforms and all scopes
Tarek Ziadé ziade.ta...@gmail.com added the comment:
The mac/win difference is with the starting dot because it's impossible
under windows to name a file under the directory browser UI that starts
with a .. You have to be a power-user to do so. (pydistutils.cfg
versus .pydistutils.cfg)
Now for pydistutils.cfg vs distutils.cfg I don't know why it's like
that. It should be distutils.cfg everywhere imho. Even if the global
and local one are eventually merged. I'll launch a thread about it on
distutils-sig.
Next, setup.cfg is for the current directory because this how you
operate with packages that have setup.py+setup.cfg files : you chdir in
the directory then run a distutils command.
Last, under windows, it should use os.path.expanduser('~') instead of
looking for a HOME variable. this will be fix in any case.
--
nosy: +exarkun
priority: - normal
resolution: - accepted
type: - behavior
versions: +Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6555
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6622] [RFC] wrong variable used in Lib/poplib.py
Mark Dickinson dicki...@gmail.com added the comment: Comparing with trunk, I agree that it seems very likely that 'password' is intended here. It's unfortunate that the test-suite doesn't expose this bug; it would be good to come up with a test that covers this. -- nosy: +marketdickinson stage: - test needed type: - behavior versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6621] [RFC] Remove leftover use of Carbon module from Lib/binhex.py
Mark Dickinson dicki...@gmail.com added the comment: As far as I can tell, it looks safe to just remove these two blocks. There's a third block that should be removed as well (the second if os.name == 'mac': ... in the hexbin function. -- nosy: +marketdickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6621 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6621] [RFC] Remove leftover use of Carbon module from Lib/binhex.py
Mark Dickinson dicki...@gmail.com added the comment: This should be fixed in the 3.1 maintenance branch as well. -- versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6621 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6621] [RFC] Remove leftover use of Carbon module from Lib/binhex.py
Mark Dickinson dicki...@gmail.com added the comment: See also issue 2715. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6621 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2715] Remove carbon-specific code from binhex
Mark Dickinson dicki...@gmail.com added the comment: This came up again recently in issue 6621. What's the current status of the binhex module in py3k? It looks as though the Carbon-specific code has been *partially* but not completely removed. In particular, there are references to FSSpec remaining, but no FSSpec is imported anywhere. The references to FSSpec are all inside if os.name == 'mac': ... blocks. On my 10.5/Intel and 10.4/PPC systems os.name gives 'posix', so these blocks never get executed. Is it safe to simply remove these blocks? -- nosy: +marketdickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6621] [RFC] Remove leftover use of Carbon module from Lib/binhex.py
Mark Dickinson dicki...@gmail.com added the comment: Closing as a duplicate of issue 2715. -- resolution: - duplicate status: open - closed superseder: - Remove carbon-specific code from binhex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6621 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2715] Remove carbon-specific code from binhex
Brett Cannon br...@python.org added the comment: From my understanding the mac platform is OS 9, so that code in those 'if' blocks can go. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6626] show Python mimetypes module some love
New submission from Jacob Rus jacobo...@gmail.com: See discussion started right at the end of the month at http://mail.python.org/pipermail/python-dev/2009-July/090928.html And continued at http://mail.python.org/pipermail/python-dev/2009-August/thread.html Basically, the mimetypes module is fragile and very confusing code, built up over years of feature creep without refactoring or careful overall design. I'd like to cut it down to a more manageable code size, fix some bugs, update the included list of mime types, and use some nice Python features of versions 2.2+. Ideally someone reading the module once through would be able to understand what it does. Patches to be attached shortly. -- components: Library (Lib) messages: 91196 nosy: jrus severity: normal status: open title: show Python mimetypes module some love type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2053] IDLE - standardize dialogs
Tal Einat talei...@users.sourceforge.net added the comment: The whole point of this patch is to make the EditorWindow's Text widget the default master/parent for its dialogs! IMO this makes sense, since this is a reasonable and intuitive default for such methods of the EditorWindow object. I understand the explicit is better than implicit argument, but that doesn't mean that having a reasonable default value is always wrong. In this case having a default value both simplifies the code considerably and makes sense, so IMO it is justified. Also, please note that the patch actually reduces the size of EditorWindow.py (both character and line counts) and cleans up the code in many places. Yes, the definition of the relevant methods is not trivial, but it is in just one area of the code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6627] threading.local() does not work with C-created threads
New submission from Nikolaus Rath nikol...@rath.org: When threads are created by a C extension loaded with ctypes, threading.local() objects are always empty. If one uses _threading_local.local() instead of threading.local(), the problem does not occur. More information and example program showing the behaviour: http://code.google.com/p/fusepy/issues/detail?id=15 -- components: Library (Lib) messages: 91198 nosy: Nikratio severity: normal status: open title: threading.local() does not work with C-created threads type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6627 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6608] asctime causing python to crash
James Abbatiello abb...@gmail.com added the comment: Further investigation shows that MS asctime() doesn't like leap seconds and causes an assertion when passing (2008, 12, 31, 23, 59, 60, 2, 366, -1) - 'Wed Dec 31 23:59:60 2008'. Given that and since asctime() is such a simple function I think it makes more sense to roll our own. Attached is a rough patch which does this. It pulls the bounds checking used in strftime() out into its own function so it can be used in both places. Overriding ctime() is necessary because Windows decided to use %02d instead of %3d to print the day of the month. Without overriding ctime() the output of ctime(t) would be different from asctime(localtime(t)) and cause test_conversion() to fail. There is a USE_SYSTEM_ASCTIME switch to decide whether to use the system asctime() or the internal one. -- keywords: +patch Added file: http://bugs.python.org/file14628/asctime.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6626] show Python mimetypes module some love
Jacob Rus jacobo...@gmail.com added the comment: This diff should leave the semantics of the module essentially unchanged (including lazy-loading of default files), and also leave the particular MIME types used unchanged, even though these are out of date and should be updated; a subsequent suggested version will address that, perhaps after some discussion. -- keywords: +patch Added file: http://bugs.python.org/file14629/mimetypes-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2715] Remove carbon-specific code from binhex
Mark Dickinson dicki...@gmail.com added the comment: Thanks, Brett. I've removed those blocks in r74289 (py3k) and r74290 (release31-maint). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2715] Remove carbon-specific code from binhex
Mark Dickinson dicki...@gmail.com added the comment: It looks to me as though this issue can now be closed. Ronald, any comments? -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6626] show Python mimetypes module some love
Jacob Rus jacobo...@gmail.com added the comment: Here is a version of the patch which does away with the lazy loading: these are a small handful of easy-to-parse ~40k files; if the import takes an extra eye-blink, it shouldn't be too big a deal. -- Added file: http://bugs.python.org/file14630/mimetypes3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6626] show Python mimetypes module some love
Jacob Rus jacobo...@gmail.com added the comment: A fixed version of the patch from msg91200, 2009-08-02 20:08 -- Added file: http://bugs.python.org/file14631/mimetypes2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6626] show Python mimetypes module some love
Jacob Rus jacobo...@gmail.com added the comment: This version (#4) switches to expressing the default types as a list of tuples instead of as a dict, so that we can include duplicate rows so that reverse type - extension lookups will behave properly, once we start changing the actual content of the defaults. The types_map and common_types dictionaries (aliases to the singleton MimeTypes object's types_map property) have been left behaving as before for backwards compatibility. The tests still pass. -- Added file: http://bugs.python.org/file14632/mimetypes4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2053] IDLE - standardize dialogs
Guilherme Polo ggp...@gmail.com added the comment: I thought the main point of this issue was to define standard functions, methods, classes (or something in that sense), in order to make the creation of tk dialogs uniform across IDLE. Right now it seems reasonable to keep the parent hidden, but I think it may not help much for maintaining. I really consider a good idea to define explicitly who is the parent of a dialog, it wasn't an attempt to refer to the phrase you cited. I trust you it reduces the size on that file, I really didn't count how many lines were removed and how many were added, but these dialogs can be used anywhere around IDLE so I don't see why keeping them inside EditorWindow is a good idea. It would reduce even more (some few lines) EditorWindow's size doing so, and it would make more sense as I see. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6616] PyList_APPEND (append without incref)
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I know the API well enough (with manipulating dicts/lists etc) and I still want this function for the sake of convenience. Given that your level of skill is higher than the average user, I recommend adding this to your own standard libraries or headers. No need to muck-up the environment for everyone else. -- assignee: - rhettinger resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6616 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6626] show Python mimetypes module some love
Jacob Rus jacobo...@gmail.com added the comment: Here is a list I generated of all the current Apache mime.types: I would just as soon include this in the python standard library, either just the Apache file as is, or even these python object literals (maybe in a file outside of mimetypes.py), and then *not* import from Apache files by default, to cut down on external dependencies. There are several alternate MIME types for various types that should be added to this list (in earlier positions so they only are used in the type - extension map). The only issue is that some users may have added to their Apache mime.types files for the sake of getting mailman or other python programs to do what they want. So I'm not entirely sure to what extent we should be 100% backwards compatible in such edge cases. My personal opinion is that the 'strict' option is unnecessary and should be set to do nothing, because users are more likely to want the predictable behavior where an unorthodox type gives back the proper extension, than the behavior where their code fails unless they pass a flag in: I don't see any reason for a user to want a 'type doesn't exist' message back for non-registered types. This isn't a test for IANA registration module. -- Added file: http://bugs.python.org/file14633/apache_mimetypes.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628205] socket.readline() interface doesn't handle EINTR properly
Rhett Garber rhe...@gmail.com added the comment: I've hit this issue as well. Attached is an updated patch to 2.6 branch and a test case. I wrote up more details here: http://nullhole.com/2009/08/02/anatomy-of-a-regression-test/ -- nosy: +rhettg Added file: http://bugs.python.org/file14634/diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6628] IDLE freezes after encountering a syntax error
New submission from brian omniscient.br...@gmail.com: Running Python 3.1/ IDLE, which was installed on top of a Python 2.5.4 install, Mac OSX 10.4 This seems like such an obvious bug, but I can't find it in the current list of issues - so I suspect that it may not be reproducible on other computers, but it's certainly reproducible on my laptop. If I run a module with (any?) syntax error (for example, for i in range(10) #missing semicolon print i the interpreter will catch it and send you to fix it. Then, any subsequent attempts to run that same module will freeze IDLE. The problem doesn't occur if you run a different module. -- components: IDLE messages: 91210 nosy: brian89 severity: normal status: open title: IDLE freezes after encountering a syntax error type: crash versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6628 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
