[issue16479] Can't install Python 3 on Redhat Linux, make failed
New submission from Stephen: Machine is Redhat Linux 6.2. Tried to install Python3.3 build failed in the make step. --- [sliu@wtl-build-1 Python-3.3.0]$ uname -a Linux wtl-build-1 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [sliu@wtl-build-1 Python-3.3.0]$ pwd /tmp/Python-3.3.0 [snip] config.status: pyconfig.h is unchanged creating Modules/Setup creating Modules/Setup.local creating Makefile [sliu@wtl-build-1 Python-3.3.0]$ make Wrapping make for user sliu on hostname wtl-build-1... gcc: Parser/acceler.o: No such file or directory gcc: Parser/grammar1.o: No such file or directory gcc: Parser/listnode.o: No such file or directory gcc: Parser/node.o: No such file or directory gcc: Parser/parser.o: No such file or directory gcc: Parser/bitset.o: No such file or directory gcc: Parser/metagrammar.o: No such file or directory gcc: Parser/firstsets.o: No such file or directory gcc: Parser/grammar.o: No such file or directory gcc: Parser/pgen.o: No such file or directory gcc: Objects/obmalloc.o: No such file or directory gcc: Python/dynamic_annotations.o: No such file or directory gcc: Python/mysnprintf.o: No such file or directory gcc: Python/pyctype.o: No such file or directory gcc: Parser/tokenizer_pgen.o: No such file or directory gcc: Parser/printgrammar.o: No such file or directory gcc: Parser/parsetok_pgen.o: No such file or directory gcc: Parser/pgenmain.o: No such file or directory make[1]: *** [Parser/pgen] Error 1 make: *** [Include/graminit.h] Error 2 Build with args took 0 seconds, status complete [sliu@wtl-build-1 Python-3.3.0]$ --- Tried different Linux machines, same error. Tried Python 3.3, 3.1 and 3.0, same error. Any idea? Stephen -- components: Installation messages: 175623 nosy: stephen...@gmail.com priority: normal severity: normal status: open title: Can't install Python 3 on Redhat Linux, make failed type: compile error versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16479] Can't install Python 3 on Redhat Linux, make failed
Stephen added the comment: Sorry, missed the configure command in the previous message. It should have been: --- [sliu@wtl-build-1 Python-3.3.0]$ uname -a Linux wtl-build-1 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [sliu@wtl-build-1 Python-3.3.0]$ pwd /tmp/Python-3.3.0 [sliu@wtl-build-1 Python-3.3.0]$ ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for --enable-universalsdk... no checking for --with-universal-archs... 32-bit checking MACHDEP... linux checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for --with-cxx-main=compiler... no checking for g++... no configure: WARNING: By default, distutils will build C++ extension modules with g++. If this is not intended, then set CXX on the configure command line. checking for -Wl,--no-as-needed... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E [snip] config.status: pyconfig.h is unchanged creating Modules/Setup creating Modules/Setup.local creating Makefile [sliu@wtl-build-1 Python-3.3.0]$ make Wrapping make for user sliu on hostname wtl-build-1... gcc: Parser/acceler.o: No such file or directory gcc: Parser/grammar1.o: No such file or directory gcc: Parser/listnode.o: No such file or directory gcc: Parser/node.o: No such file or directory gcc: Parser/parser.o: No such file or directory gcc: Parser/bitset.o: No such file or directory gcc: Parser/metagrammar.o: No such file or directory gcc: Parser/firstsets.o: No such file or directory gcc: Parser/grammar.o: No such file or directory gcc: Parser/pgen.o: No such file or directory gcc: Objects/obmalloc.o: No such file or directory gcc: Python/dynamic_annotations.o: No such file or directory gcc: Python/mysnprintf.o: No such file or directory gcc: Python/pyctype.o: No such file or directory gcc: Parser/tokenizer_pgen.o: No such file or directory gcc: Parser/printgrammar.o: No such file or directory gcc: Parser/parsetok_pgen.o: No such file or directory gcc: Parser/pgenmain.o: No such file or directory make[1]: *** [Parser/pgen] Error 1 make: *** [Include/graminit.h] Error 2 Build with args took 0 seconds, status complete [sliu@wtl-build-1 Python-3.3.0]$ --- -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16479] Can't install Python 3 on Redhat Linux, make failed
Stephen added the comment: Please ignore this. I have figured out it was caused by our company's make wrapper. Using native make works like a charm. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28423] list.insert(-1,value) is wrong!
New submission from stephen: python3.4.3 on linux mint 17.3 interactive mode on terminal >>> fred=[0,1,2,3,4] >>> fred.insert(-1,9) >>> fred [0, 1, 2, 3, 9, 4] We should get [0,1,2,3,4,9]. Embarrassing error! -- messages: 278541 nosy: unklestephen priority: normal severity: normal status: open title: list.insert(-1,value) is wrong! type: behavior versions: Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42844] Turtle Module -- "onclick" arguments enchancement
New submission from Stephen : I have created an enhancement in the Turtle module. When a programmer wants to have an action performed after clicking on a Turtle object, the programmer is currently unable to supply any arguments into the method that is run when "on_clicked" which is extremely limiting, especially to beginners who are looking to modify multiple objects on the screen at one time, such as in a game. I have modified the implementation of the “on_clicked” method to be able to provide keyword arguments into the method through a dictionary that is later unpacked into the target method. Attached is an example of the benefits of this enhancement to the turtle module. -- components: Library (Lib) files: on_click_arguments_example.py messages: 384513 nosy: sc1341 priority: normal severity: normal status: open title: Turtle Module -- "onclick" arguments enchancement type: enhancement versions: Python 3.10 Added file: https://bugs.python.org/file49723/on_click_arguments_example.py ___ Python tracker <https://bugs.python.org/issue42844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42844] Turtle Module -- "onclick" arguments enchancement
Change by Stephen : -- keywords: +patch pull_requests: +22972 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24143 ___ Python tracker <https://bugs.python.org/issue42844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10500] Palevo.DZ worm msix86 installer 3.x installer
Stephen Hansen me+pyt...@ixokai.io added the comment: Latest Norton 360 fully updated has it clean; further, File Insight has it marked as Trusted (thousands of Norton users have had the same file installed for over a month with no reported trouble). Seems clean to me. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10500] Palevo.DZ worm msix86 installer 3.x installer
Stephen Hansen me+pyt...@ixokai.io added the comment: I downloaded that linked MSI again (as its different from the one originally reported)-- and it too is still coming up as clean. I would suggest that its clearly either a false positive as Jesús is suggesting... or something on your side or between you and python.org is infecting it as or right after you download it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10092] calendar does not restore locale properly
Stephen Hansen me+pyt...@ixokai.io added the comment: On windows, France may work and fr_FR may not; yet on OSX its exactly the opposite. Its not consistant across platforms. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10820] 3.2 Makefile changes for versioned scripts break OS X framework installs
Stephen Hansen me+pyt...@ixokai.io added the comment: FYI, The patch applied cleanly to branches/py3k; I then built a framework build (universal), installed it and ran the test-suite. I had two failures, but I don't know if either is related. The first was the tk tests didn't pass, but I'm not sure if there was something special I need to do to get tk compiled universal in a framework build-- I'll look into it. But this one perplexes me: Wimp:build pythonbuildbot$ ./python.exe -m test.regrtest test_site [1/1] test_site test test_site failed -- Traceback (most recent call last): File /Users/pythonbuildbot/32test/build/Lib/test/test_site.py, line 225, in test_getsitepackages self.assertEqual(len(dirs), 2) AssertionError: 3 != 2 1 test failed: test_site Wimp:build pythonbuildbot$ ./python.exe Python 3.2b2+ (py3k:87899M, Jan 10 2011, 11:08:48) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. import site site.getsitepackages() ['/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages', '/Library/Frameworks/Python.framework/Versions/3.2/lib/site-python', '/Library/Python/3.2/site-packages'] This machine fwiw never had any Python 3.x installed anywhere: in fact it was an almost pure stock 10.5 with buildbots put on it. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10881] test_site and macframework builds fails
New submission from Stephen Hansen me+pyt...@ixokai.io: With the latest from branches/py3k, in a framework build, I get: Wimp:build pythonbuildbot$ ./python.exe -m test.regrtest test_site [1/1] test_site test test_site failed -- Traceback (most recent call last): File /Users/pythonbuildbot/32test/build/Lib/test/test_site.py, line 225, in test_getsitepackages self.assertEqual(len(dirs), 2) AssertionError: 3 != 2 1 test failed: test_site Wimp:build pythonbuildbot$ ./python.exe Python 3.2b2+ (py3k:87899M, Jan 10 2011, 11:08:48) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. import site site.getsitepackages() ['/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages', '/Library/Frameworks/Python.framework/Versions/3.2/lib/site-python', '/Library/Python/3.2/site-packages'] Those three dirs look correct for me, but the test is written to find exactly two from site.getsitepackages() -- the code, however, adds an extra in the event of framework builds. -- assignee: ronaldoussoren components: Macintosh, Tests messages: 125919 nosy: ixokai, ronaldoussoren priority: normal severity: normal status: open title: test_site and macframework builds fails versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10881 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10881] test_site and macframework builds fails
Stephen Hansen me+pyt...@ixokai.io added the comment: ... oops! Apparently dupe. Forgot to search first. Ignore. -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10881 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10881] test_site and macframework builds fails
Changes by Stephen Hansen me+pyt...@ixokai.io: -- superseder: - pep-0370 on osx duplicates existing functionality ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10881 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11124] test_posix failure on the Leopard buildbot
Stephen Hansen me+pyt...@ixokai.io added the comment: This is just http://bugs.python.org/issue7900 all over again. In the meantime, I restarted the buildslave and re-submitted the jobs so the failures should go away. (I still advocate that the test is fundamentally wrong/flawed on Mac and should be disabled at least -- but that discussion is over on issue7900). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls output
Stephen Hansen me+pyt...@ixokai.io added the comment: I can confirm that this test has been failing on my slave, and that the patch fixes it. Recommend commit. Red is bad. -- assignee: - ronaldoussoren components: +Macintosh nosy: +ixokai, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7108 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1578269] Add os.link() and os.symlink() support for Windows
Stephen Warren added the comment: I'd say that junction points were a great way to expose this feature under Win32 - after all, isn't it specifically what they were designed for? Incidentally, at least one other application uses them for exactly this purpose; a commercial source control tool named Accurev supports checked-in symlinks on Windows as well as *nix etc. The added advantage of junction points over whatever new API Vista exposes is that it'll work on at least XP (maybe even Win2K?) -- nosy: +swarren _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1578269 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1704287] must run make before make install
Stephen Warren added the comment: I can confirm this happens for me too, also on CentOS 5, with SVN 2.5 HEAD as of now. It seems that this problem occurs, whilst running the first compileall command for the libinstall target: Compiling /somewhere/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: (\\N escapes not supported (can't load unicodedatamodule),) -- nosy: +swarren _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1704287 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1704287] UnicodeError in compileall if make install is run before make.
Stephen Warren added the comment: The attached patch should solve the problem by adding appropriate dependencies to the libinstall target. I have tested: ./configure; make install but not yet: ./configure; make all install ./configure; make all; make install Note: I introduced a new build_all phony target so that both all and libinstall could depend on this, rather than making libinstall either: * depend on all (which I guess would cause nasty looping dependencies if one were to run make all install) * duplicate all the dependencies of all, thus causing a maintenance issue Possibly, the new dependencies should be added to install instead of libinstall? Alternatively, I guess one could make all touch a file, and install or libinstall validate that the file exists, and error out if it doesn't. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1704287 _ py_1704287.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1704287] UnicodeError in compileall if make install is run before make.
Stephen Warren added the comment: Now, I have also tested: ./configure; make all install ./configure; make all; make install The install piece of each of the above doesn't seem to accidentally duplicate any of the building work, so the patch seems to check out OK - no negative side-effects. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1704287 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1578269] Add os.link() and os.symlink() support for Windows
Stephen Warren added the comment: Hmm. I just tested Accurev - whatever it does, it works for files too. That said, it could be making hard-links, which I guess could be different. Additionally, the sysinternals junction utility doesn't find any junction points when probing the link files. I'll see if I can find out how they implemented it... _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1578269 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1578269] Add os.link() and os.symlink() support for Windows
Stephen Warren added the comment: It seems that Accurev uses junction points for directories, and hard-links for files. That's probably a little to disparate to implement in Python? Also, I tried sysinternals' junction.exe and whilst it allows one to create junction points that point at files, you can't actually read the file via the junction point - so it does seem that they only work for directories:-( Oh well, lets hope whatever new Vista API exists works better... _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1578269 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1923] meaningful whitespace can be lost in rfc822_escape
New submission from Stephen Emslie: distutils.util.rfc822_escape strips each line of its whitespace before indenting, but this can mean losing meaningful whitespace, such as in reStructuredText. distutils uses rfc822_escape to escape fields in metadata, such as PKG-INFO. This unfortunately means that you cant use reStructuredText formatting in your long description (suggested in PEP345), or are limited to a set that doesn't require indentation (no block quotes, etc.). for example: rest = ... a literal python block:: ... import this ... print distutils.util.rfc822_escape(rest) a literal python block:: import this I would be expecting this to look something like: a literal python block:: import this It looks like this behavior was intentionally added in rev 20099, but that was about 7 years ago - before reStructuredText and eggs. I wonder if it makes sense to re-think that implementation with this sort of metadata in mind, assuming this behavior isn't required to be rfc822 compliant. I think it would certainly be a shame to miss out on a good thing like proper (renderable) reST in our metadata. Is distutils being over-cautious in flattening out all whitespace? A w3c discussion on multiple lines in rfc822 [1] seems to suggest that whitespace can be 'unfolded' safely, so it seems a shame to be throwing it away when it can have important meaning. http://www.w3.org/Protocols/rfc822/3_Lexical.html -- components: Library (Lib) messages: 61633 nosy: stephenemslie severity: normal status: open title: meaningful whitespace can be lost in rfc822_escape type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1923 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1923] meaningful whitespace can be lost in rfc822_escape
Stephen Emslie added the comment: Here's that keeps the whitespace in tact, along with a simple test. This doesn't patch docs as the existing documentation_ already describes the long string as multiple lines of plain text in reStructuredText format, which is what this fixes. .. _documentation: http://docs.python.org/dev/distutils/setupscript.html#additional-meta-data Added file: http://bugs.python.org/file9310/distutils_metadata_whitespace.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1923 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4388] test_cmd_line fails on MacOS X
Stephen Hansen me+pyt...@ixokai.io added the comment: FWIW, this still happens on the latest of /branches/py3k, when LANG does not match up to the enforced fs encoding-- which for me happened when I ran the buildslave under launchd. I was finally able to reproduce it, and after doing so, verified that cmdline_encoding-2.patch on issue9992 fixed it. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9992] Command line arguments are not correctly decodedif locale and fileystem encodings aredifferent
Stephen Hansen me+pyt...@ixokai.io added the comment: This issue seems to be the cause of issue4388 -- and cmdline_encoding-2.patch fixes it, fwiw. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Stephen Hansen me+pyt...@ixokai.io added the comment: I'm still getting this error on the release27-maint branch on my Snow Leopard slave, and the issue8445.diff fixes it: will this fix be backported? I tested issue8445.diff and it applies cleanly, and fixes the issue. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Stephen Hansen me+pyt...@ixokai.io added the comment: BTW, release31-maint appears to have the same issue, its fouling up that build on my slave too. I tried applying the ttk3k.patch but it didn't apply cleanly, and I'm completely ignorant of TK so can't really figure out what's different between the 3.1-3.2 version to try to adjust the fix and test it out. Then again I'm not sure if there's still going to be test-fixes applied to 3.1. So its possible you can just ignore this comment :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Stephen Hansen me+pyt...@ixokai.io added the comment: For the record, everything (2.7, 3.1, and 3.x) runs this test successfully now. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
New submission from Stephen Hansen me+pyt...@ixokai.io: Ever since running the snow leopard buildslave, I've had sporadic failures in test_urllibnet. At first I thought it was just a net glitch on my machine or something, as immediately re-running the tests made it go away: but this most recent one: http://www.python.org/dev//buildbot/builders/x86%20Snow%20Leopard%203.1/builds/20/steps/test/logs/stdio happened while I was very much monitoring and using the network on the machine for other purposes, and everything was fine in general. So, I went and looked into test_urllibnet to try to figure out why, and I notice that some of the tests use code to retry on IOErrors, and some don't-- and this test that failed in particular is one that doesn't. So: anyone have a better idea of what's going wrong, or is it just that hey, the active network tests are a bit flaky and all should use _open_with_retry instead of just some as is the case now? [If the latter, I can do a patch] FWIW, I've only seen this on the 3.1 and 3.x buildslaves, but have seen it on both of those more then once. But I don't know that its a 3.x specific issue: those builds get run more often then the 2.7 one, so have more chances to run into a sporadic issue. -- components: Tests messages: 118772 nosy: ixokai priority: normal severity: normal status: open title: Sporadic failures in test_urllibnet versions: Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Stephen Hansen me+pyt...@ixokai.io added the comment: I'll run the test in -F mode for a few hours to see if it comes up or not: but its hard for me to say one way or the other if anything has fixed or not fixed it, as the failure only came up every once in awhile. But I'll look. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Stephen Hansen me+pyt...@ixokai.io added the comment: Okay, at -r85630 on branches/py3k, I ran: ./python.exe -m test.regrtest -uall -F test_urllibnet And after 158 retries, got the same error I had before: test test_urllibnet failed -- Traceback (most recent call last): File /Users/pythonbuildbot/test/build/Lib/urllib/request.py, line 1504, in open return getattr(self, name)(url) File /Users/pythonbuildbot/test/build/Lib/urllib/request.py, line 1676, in open_http return self._open_generic_http(http.client.HTTPConnection, url, data) File /Users/pythonbuildbot/test/build/Lib/urllib/request.py, line 1659, in _open_generic_http response = http_conn.getresponse() File /Users/pythonbuildbot/test/build/Lib/http/client.py, line 1027, in getresponse response.begin() File /Users/pythonbuildbot/test/build/Lib/http/client.py, line 347, in begin version, status, reason = self._read_status() File /Users/pythonbuildbot/test/build/Lib/http/client.py, line 303, in _read_status line = str(self.fp.readline(), iso-8859-1) File /Users/pythonbuildbot/test/build/Lib/socket.py, line 267, in readinto return self._sock.recv_into(b) socket.error: [Errno 9] Bad file descriptor -- resolution: fixed - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5117] os.path.relpath problem with root directory
Stephen Hansen me+pyt...@ixokai.io added the comment: FYI, this fix broke some buildbots: http://www.python.org/dev/buildbot/all/builders/x86%20Snow%20Leopard%202.7/builds/50 for instance. Gentoo too. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10092] calendar does not restore locale properly
Stephen Hansen me+pyt...@ixokai.io added the comment: I can't be entirely sure, because a) I have never even glanced at the calendar module, and b) my locale-fu is very weak, but my buildbot has consistently failed on this test since this commit: == ERROR: test_localecalendars (test.test_calendar.CalendarTestCase) -- Traceback (most recent call last): File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_calendar.py, line 264, in test_localecalendars locale=def_locale).formatmonthname(2010, 10, 10) File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/calendar.py, line 520, in formatmonthname with different_locale(self.locale): File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/calendar.py, line 490, in __enter__ _locale.setlocale(_locale.LC_TIME, self.locale) File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/locale.py, line 538, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting I will look into it in more detail tomorrow to try to provide more meaningful feedback, but I think this fix has introduced a problem. If someone sees what before I have time to dig into this unfamiliar territory, yay. :) -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10154] locale.normalize strips - from UTF-8, which fails on Mac
New submission from Stephen Hansen me+pyt...@ixokai.io: In the course of investigating issue10092, Georg discovered that the behavior of locale.normalize() on Mac is bad. Basically, en_US.UTF-8 is how the correct locale string should be spelled on the Mac. If you drop the dash, it fails: which locale.normalize does, so you can't pass the return value of the function to setlocale, even though that's what its documented to be for. If that isn't clear, this should demonstrate (from /branches/py3k): Top-2:build pythonbuildbot$ ./python.exe Python 3.2a3+ (py3k:85631, Oct 17 2010, 06:45:22) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type help, copyright, credits or license for more information. import locale [51767 refs] locale.normalize(en_US.UTF-8) 'en_US.UTF8' [51770 refs] locale.setlocale(locale.LC_TIME, 'en_US.UTF8') Traceback (most recent call last): File stdin, line 1, in module File /Users/pythonbuildbot/test/build/Lib/locale.py, line 538, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting [51816 refs] locale.setlocale(locale.LC_TIME, 'en_US.UTF-8') 'en_US.UTF-8' [51816 refs] The precise same behavior exists on my stock/system Python 2.6, too, fwiw. (Not that it can be fixed on 2.6, but maybe 2.7?) -- assignee: ronaldoussoren components: Library (Lib), Macintosh messages: 119213 nosy: ixokai, ronaldoussoren priority: normal severity: normal status: open title: locale.normalize strips - from UTF-8, which fails on Mac type: behavior versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10154] locale.normalize strips - from UTF-8, which fails on Mac
Stephen Hansen me+pyt...@ixokai.io added the comment:
Mark, the locals() right before if encoding: (line 399) are:
locale.normalize(en_US.UTF-8)
{'code': 'en_US.ISO8859-1', 'langname': 'en_US', 'encoding': 'UTF8',
'norm_encoding': 'utf_8', 'defenc': 'ISO8859-1', 'localename': 'en_US.UTF-8',
'lookup_name': 'en_us.utf-8', 'fullname': 'en_us.utf-8'}
'en_US.UTF8'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10154
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7351] Rename BadZipfile to BadZipFile for consistency
Stephen Hansen me+pyt...@ixokai.io added the comment: You may not care about backwards compatibility, but introducing a breaking change in 3.2 for mere style-conformity is not OK, IMO. If the patcher insists on it being a breaking change, it should be rejected. FWIW, this casing is sufficiently bizarre and inconsistent in the module itself, that it seems clearly wrong and likely to produce difficulties for people using it-- so although I'm not upgrading to Python3 anytime soon, I'd really like to change my code to be BadZipFile when I do, so I'd be +1 with an alias. :) -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7351] Rename BadZipfile to BadZipFile for consistency
Stephen Hansen me+pyt...@ixokai.io added the comment: Considering I do use zipfiles a lot, I slightly care about this (at least, eventually)-- I'm attaching a new patch, with doc and test changes as well (and the compatibility alias). What convinced me was looking at test_zipfile, and noticing how often it actually confused the issue in comments at least, between typing BadZipfile and BadZipFile. Dunno if I worded the doc-change well, so you may want to adjust that. -- Added file: http://bugs.python.org/file19389/issue7351-complete.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7351] Rename BadZipfile to BadZipFile for consistency
Stephen Hansen me+pyt...@ixokai.io added the comment: Oh: and I tested it against branches/py3k in the head, it applies cleanly and builds, and test_zipfile runs without error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Stephen Hansen me+pyt...@ixokai.io added the comment: The attached patch wraps all the calls to the internet in support.transient_internet; I ran it against 3.x and it passed, and then I ran it for quite awhile with the -F option, and encountered one event that I believe would previously had resulted in one of these sporadic failures, and it resulted in a skipped 'resource not available' message. I left in the previous 'retry' code, just by virtue of changing as little as possible. I can adjust if its desired. I believe that transient_internet won't capture EBADF: so if that particular sporadic failure happens again, I'll post up a new issue about it. -- keywords: +patch Added file: http://bugs.python.org/file19390/issue10116.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Stephen Hansen me+pyt...@ixokai.io added the comment: New patch, sans trailing whitespace. Ahem. -- Added file: http://bugs.python.org/file19398/issue10116-nowhitespace.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10116] Sporadic failures in test_urllibnet
Changes by Stephen Hansen me+pyt...@ixokai.io: Removed file: http://bugs.python.org/file19390/issue10116.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10236] Sporadic failures of test_ssl
New submission from Stephen Hansen me+pyt...@ixokai.io: Another sporadic failure I've noticed since setting up my buildbot; test_ssl keeps going down. This one I have a hard time analyzing with the tests output, but the latest is: http://www.python.org/dev/buildbot/all/builders/x86%20Snow%20Leopard%203.x/builds/250 There's this part in the log: test_get_server_certificate (test.test_ssl.NetworkedTests) ... [Errno 1] _ssl.c:390: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Verified certificate for svn.python.org:443 is [...pem...] ok There's an errno printed there, but then more debugging for that same test-- and an 'ok'-- so I don't see the FAIL message I'm expecting. So to my naive reading, it seems that it is running once and failing, then re-running in verbose and /not/ failing (and that the error-like message there may not be an error). So, the original problem is a mystery. Or I'm totally reading it wrong. Either way, I've seen this several times and am not sure how to further debug it. Any suggestions or pointers are welcome. Or fixes :) -- messages: 119932 nosy: ixokai priority: normal severity: normal status: open title: Sporadic failures of test_ssl versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10236] Sporadic failures of test_ssl
Changes by Stephen Hansen me+pyt...@ixokai.io: -- components: +Library (Lib), Tests type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10237] failure in Barrier tests
Stephen Hansen me+pyt...@ixokai.io added the comment: FWIW, my snow leopard slave isn't slow at all so I doubt there's a timeout related to machine speed going on here, as its failing thus: test test_threading failed -- Traceback (most recent call last): File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py, line 784, in test_default_timeout self.run_threads(f) File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py, line 615, in run_threads f() File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py, line 783, in f self.assertRaises(threading.BrokenBarrierError, self.barrier.wait) AssertionError: BrokenBarrierError not raised by wait Its actually a really spammy sort of failure with a lot of errors before it, which may or may not shed more light on the situation: http://www.python.org/dev//buildbot/3.x.stable/builders/x86%20Snow%20Leopard%203.x/builds/267/steps/test/logs/stdio This was r85883, so after the increase in the timeout. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10340] asyncore doesn't properly handle EINVAL on OSX
Stephen Hansen me+pyt...@ixokai.io added the comment: I can verify the problem exists in asyncore at release27-maint on the mac, and that the below patch fixes it. After applying, I ran a full regrtest and nothing new broke. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: This test is failing again, and IIUC, largely due to the same sort of issues: http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.1/builds/65 I was able to track down what exactly caused it to fail in this case on my box, though. Whatever posix.getgroups() ends up calling, appears to be tied to the current users login -- or at least, doesn't get updated when new groups are added to the user. This failure happened because at some point after the buildbot was up and running, I added a new user to the machine (totally unconnected to the existing buildbot runner): this caused a new group to be added to the buildbot runner's user. id -G starts returning that group immediately, but posix.getgroups() returns the same list as it had before. I was able to further reproduce it in Terminal, by having a console open, and compiling 3.1 there then adding a user, and running the test. It fails. Opening up a new terminal window, running the test-- and it succeeds. The original console continues to fail. -- nosy: +ixokai versions: +Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Changes by Stephen Hansen me+pyt...@ixokai.io: -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: Well, yes: the result of posix.getgroups is not a bug in Python, but is it a bug in the test? Should it be skipped on OSX, or some other solution? Having buildbots fail because of something that's expected behavior is bad, isn't it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: The test is clearly verifying a *wrong* assumption: that id -G will match posix.getgroups() which simply does not hold on OSX. I can reproduce this reliably on a completely clean, brand new installation of 10.5: from there the only things that have been done to the box is updating to 10.5.8, and then downloading the latest XCode tools that run on Leopard. From here, launch Terminal: leave the console open. Run id -G; then run python and look at posix.getgroups(). Now, go into System Preferences and add a new user. Don't do anything else. Don't change anything with existing user. In the console that was already open, do id -G again. Now run python again, and do posix.getgroups() -- those no longer match. Clearly IMHO the assumption that the test is declaring to be an expected result simply is not true in a OSX-Unix environment. Yes, if I go and *edit the actual slave user* then surely I can expect failures until I restarted the buildslave. But, if by merely adding a user causes a change to the buildslaves user by no action of my own, and that causes this test to be invalid... the test itself seems to be founded on assumptions which simply are not reliably true. I understand disabling the test means os.getgroups() will no longer be tested on OSX: and yet, the current situation is a specific behavior of os.getgroups() is tested which is *not* actually the guaranteed behavior of that operation. There is at least one very easy to reproduce situation in which id -G and posix.getgroups() do not match: I don't know if there are more. But for the test to assert the truth that its only correct when they match seems to be a mistake. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7900] posix.getgroups() failure on Mac OS X
Stephen Hansen me+pyt...@ixokai.io added the comment: On 11/16/10 5:44 AM, Ronald Oussoren wrote: Ronald Oussoren ronaldousso...@mac.com added the comment: Please explain how the failure can be reproduced. I have. But to do so more directly: 1. Launch Terminal.app; leave the window console open. 2. Run: id -G 3. Run: python 4. Type: import posix; posix.getgroups() 5. Go into System Preferences, add a user. 6. Type again, posix.getgroups(): notice, the values have not changed. 7. Either os.system(id -G) or ^D and type id -G: in either case, these values *have* changed. Tested both. I've done some testing on my machine using Apple's copy of python 2.6.1 (on OSX 10.6), which has the same getgroups implementation as the current heads of the active branches. As I said, the slave is running the latest on 10.5. Perhaps its a platform bug which is fixed in 10.6: either way, the test is declaring behavior is true that it shouldn't, I think. Perhaps the test should only be skipped on 10.5? I am happy to provide a patch which tests sys.platform == darwin and then runs sw_vars to make only skip 10.6. I verified posix.getgroups() on 10.6 does not appear to exhibit this behavior on my SL slave. However, that box does a LOT, so I can't vouch for its 'purity' like the 10.5 box. Was the buildbot started using launchd (the recipe at http://buildbot.net/trac/wiki/UsingLaunchd seems correct)? If not, how is it started? It was started with launchd, yes: with a variation of that recipe. However as I stated, the behavior can be readily reproduced directly in Terminal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2901] error: can't allocate region from mmap() when receiving big chunk of data
Stephen Hansen me+pyt...@ixokai.io added the comment: I can try to do some testing to reproduce w/ 2.7: 2.5 was IIRC 32-bit on leopard by default though, so should I force a non-64-bit build to test this? I'm not entirely sure if that'll change things, but want to make sure. I can test with both 2.5 and 2.7 on leopard. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2901 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3841] IDLE: quirky behavior when displaying strings longer than 4093 characters
Stephen McInerney [EMAIL PROTECTED] added the comment: Other people have reported it does NOT occur with either: Win XP / Python 2.5 / Idle 1.2 Mac OS X 10.5.4 / Python 2.5.2 / IDLE 1.2.2 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
Stephen White stephen-python@randomstuff.org.uk added the comment: 32bit apps can query the 64bit registry, using the appropriate security and access rights options such as KEY_WOW64_64KEY (0x0100). Similarly KEY_WOW64_32KEY can be used for 64bit apps to read/write the 32bit registry without having to have knowledge of how the Wow6432Nodes are arranged . These mean that a 64bit aware app, whether compiled as 64 or 32 bits, can access the alternative view of the registry. http://msdn.microsoft.com/en-us/library/ms724897(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms724878(VS.85).aspx For example if you have both 64 and 32 bit copies of Python installed then a Python app running under the 32bit copy of Python can query the location of the 64bit copy of Python using code like: key64 = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, Software\\Python\\PythonCore\\2.6\\PythonPath, 0, _winreg.KEY_READ + 0x0100) _winreg.QueryValue(key, ) C code can do similarly. -- nosy: +Stephen.White ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6792 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3157] sqlite3 minor documentation issues
New submission from Stephen Lewis [EMAIL PROTECTED]: The documentation for several methods in the sqlite3 library seems to be at odds with the function names: sqlite3.Cursor.fetchone -- Fetches several rows from the resultset. sqlite3.Cursor.fetchmany -- Fetches all rows from the resultset. sqlite3.Cursor.fetchall -- Fetches one row from the resultset. This is apparent on Ubuntu's packaged version 2.5.2-2ubuntu4, and a quick glance at the online SVN repository implies that its present in the trunk. Also, it might be helpful the documentation for sqlite3.connect were to mention that it takes a file name as a parameter :) -- assignee: georg.brandl components: Documentation messages: 68488 nosy: georg.brandl, slewis severity: normal status: open title: sqlite3 minor documentation issues versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix
New submission from Stephen Warren [EMAIL PROTECTED]:
Run the following Python script, on Unix/Linux:
==
import zipfile
z = zipfile.ZipFile('zipbad.zip', 'w')
z.writestr('filebad.txt', 'Some content')
z.close()
z = zipfile.ZipFile('zipgood.zip', 'w')
zi = zipfile.ZipInfo('filegood.txt')
zi.external_attr = 0660 16L
z.writestr(zi, 'Some content')
z.close()
==
Like this:
python testzip.py unzip zipbad.zip unzip zipgood.zip ls -l
file*.txt
You'll see:
-- 1 swarren swarren 12 2008-07-17 12:54 filebad.txt
-rw-rw 1 swarren swarren 12 1980-01-01 00:00 filegood.txt
Note that filebad.txt is extracted with mode 000.
The WAR (used for filegood.txt) is to pass writestr a ZipInfo class with
external_attr pre-initialized. However, writestr should perform this
assignment itself, to be consistent with write. I haven't checked, but
there's probably a bunch of other stuff in write that writestr should do
too.
--
components: Extension Modules
messages: 69898
nosy: swarren
severity: normal
status: open
title: zipfile.writestr doesn't set external attributes, so files are extracted
mode 000 on Unix
versions: Python 2.5
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3394
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix
Stephen Warren [EMAIL PROTECTED] added the comment: Oops. Forgot to set type field. -- type: - behavior ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix
Stephen Warren [EMAIL PROTECTED] added the comment: I'd probably argue for at least 066016, if not 066616, since group permissions are pretty typically set, but even 066616 would be OK, since the umask on extraction would take away any permissions the extracting user didn't want. But, as long as the chosen mask includes at least 0600, I'd consider the issue fixed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3841] IDLE: quirky behavior when displaying strings longer than 4093 characters
New submission from Stephen McInerney [EMAIL PROTECTED]: IDLE exhibits quirky behavior when displaying strings longer than 4093 characters Python versions: believed to be all. I found this on Python 2.5 / IDLE 1.2.2 OS: Windows Vista; let me know if it repros on others. Testcase attached has a length-4094 string. IDLE will not display this unless your cursor is inside the string. If you delete characters so length = 4093, IDLE displays it ok again. -- components: IDLE messages: 73049 nosy: spmcinerney severity: normal status: open title: IDLE: quirky behavior when displaying strings longer than 4093 characters type: behavior versions: Python 2.5, Python 2.6, Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3841] IDLE: quirky behavior when displaying strings longer than 4093 characters
Stephen McInerney [EMAIL PROTECTED] added the comment: (I previously attached testcase with the web form, but it doesn't seem to work. So I'm pasting it here:) # Generate a length-4094 string. # IDLE will not display this unless your cursor is inside the string. # If you delete characters so length = 4093, IDLE displays it ok. # Python versions: believed to be all # OS: Windows Vista (maybe others) #verylongstring = 1 3 5 7 9 * 409 + 1 3 verylongstring = 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 print len(verylongstring) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3841] IDLE: quirky behavior when displaying strings longer than 4093 characters
Stephen McInerney [EMAIL PROTECTED] added the comment: This may well be Windows-only or maybe even Windows Vista-only. I don't have ready access to other OS installs so could someone who does please try to repro? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6761] Class calling
New submission from Stephen Fairchild signupaddr...@bethere.co.uk: From: http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy Class instances Class instances are described below. Class instances are callable only when the class has a __call__() method; x(arguments) is a shorthand for x.__call__(arguments). The following program demonstrates otherwise regarding that last statement. def call(self): print inserted __call__ in object of class A class A(object): def __call__(self): print __call__ method in class A x = A() # Equates: x = type(A).__call__(A) x.__call__ = call x() # Calls the method of class A. x.__call__(x) # Calls function call. type(x).__call__(x) # The correct longhand of x() IMHO If I were to rephrase the documentation: Class instances Class instances are described below. Class instances are callable only when the class has a __call__() method; x(arguments) is a shorthand for type(x).__call__(x, arguments). -- assignee: georg.brandl components: Documentation messages: 91864 nosy: georg.brandl, onlyme severity: normal status: open title: Class calling type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6761] Class calling
Stephen Fairchild signupaddr...@bethere.co.uk added the comment: On further reading it seems my objections only apply to new style classes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9802] Document 'stability' of builtin min() and max()
Stephen Evans step...@recombinant.co.uk added the comment: As suggested by Mark following my post on comp.lang.python I am adding further comments to the discussion on this (closed) issue. For a more mathematical consideration of the issue: Stepanov, Alexander and Paul McJones. 2009. Elements of Programming. Addison Wesley. Pages 52-53 The problem with the builtin max() is with weak comparisons. Consider two python objects a and b that are equivalent and where the following are True: a is not b repr([a, b]) == repr(sorted([a, b])) repr([a, b]) == repr(sorted([a, b], reverse=True)) repr([b, a]) == repr(sorted([b, a])) repr([b, a]) == repr(sorted([b, a], reverse=True)) Assuming repr() implemented correctly for a and b. The only Python rich comparison required is (weak) __lt__. If (weak) __eq__ is implemented then the following are True: a == b b == a In bltinmodule.c builtin_max() uses Py_GT. For correctness this should use the converse of builtin_min() i.e. the boolean negation of PyObject_RichCompare using Py_LT (for valid results). If using Python rich comparisions then only __lt__ would be required for both min() and max() as with list.sort(). The following will then be True: min([a, b]) is a max([a, b]) is b min([b, a]) is b max([b, a]) is a min([a, b]) is max([b, a]) min([a, b]) is not min([b, a]) max([a, b]) is min([b, a]) max([a, b]) is not max([b, a]) The above will work if Py_GE is subtituted for Py_GT in builtin_max(), though this will require the implementation of __ge__ which is inconsistent with list.sort() and is a point of potential failure if the implementation of __ge__ is not the converse of the implementation __lt__. To reiterate - builtin max() should be the converse of builtin min(). -- components: +None -Documentation nosy: +Stephen.Evans versions: +Python 2.7, Python 3.3 Added file: http://bugs.python.org/file20996/min_max.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12032] Tools/Scripts/crlv.py needs updating for python 3+
New submission from Stephen Ferg zuuli...@ferg.org: I think this is a consequence of the new Unicode support in Python 3+ Here is code copied from C:\Python32\Tools\Scripts\crlf.py (on windows) == for filename in os.listdir(.): if os.path.isdir(filename): print(filename, Directory!) continue data = open(filename, rb).read() if '\0' in data: print(filename, Binary!) continue newdata = data.replace(\r\n, \n) if newdata != data: print(filename) === When run, it produces this (run under the PyCharm debugger) === C:\Python32\python.exe C:/pydev/zob/zobtest.py Traceback (most recent call last): File C:/pydev/zob/zobtest.py, line 134, in module x() File C:/pydev/zob/zobtest.py, line 126, in x if '\0' in data: TypeError: Type str doesn't support the buffer API Process finished with exit code 1 === Removing the test for \0 produces this: === C:\Python32\python.exe C:/pydev/zob/zobtest.py Traceback (most recent call last): File C:/pydev/zob/zobtest.py, line 131, in module x() File C:/pydev/zob/zobtest.py, line 126, in x newdata = data.replace(\r\n, \n) TypeError: expected an object with the buffer interface Process finished with exit code 1 === -- components: Demos and Tools messages: 135531 nosy: stephen_ferg priority: normal severity: normal status: open title: Tools/Scripts/crlv.py needs updating for python 3+ type: crash versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12032 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
New submission from Stephen Kelly steve...@gmail.com: There are several bugs on http://docs.python.org/library/datetime.html Section 8.1.6 references the method rzinfo.dst(), which does not exist. Presumably this should be tzinfo.dst(). Section 8.1.4 contains an implementation of a GMT2 timezone. There seems to be a bug in the utcoffset() and dst() implementations. The timedelta(hours=2) is in the dst() implementation, but it should be in the uctoffset() implementation. The docs for tzinfo.utcoffset() start with 'Return offset of local time from UTC, in minutes east of UTC'. Other methods (eg dst()) also document that the unit to return should be 'minutes'. However, all code samples instead return a timedelta. The documentation I quoted should instead read 'Return offset of local time from UTC as a timedelta, or None'. -- assignee: docs@python components: Documentation messages: 150272 nosy: docs@python, steveire priority: normal severity: normal status: open title: datetime documentation typos versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13666 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
Stephen Kelly steve...@gmail.com added the comment: Patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13666 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13864] Python 2.7.2 refuses to open
New submission from stephen Andel elden.an...@gmail.com: I recently changed one of the keybindings in python to just control. Python did not like this and, when I tried to fix this by swapping back to the default settings it closed itself and now will not open. Th program will attempt to open then stop, and the process with cancel. I have reinstalled and deleted all apparent files associated with python but this was not enough and continues to fail, badly. Sorry for the informal dialogue I'm just a bit peeved right now. -- components: IDLE messages: 151971 nosy: stephen.Andel priority: normal severity: normal status: open title: Python 2.7.2 refuses to open versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus
New submission from Stephen Day stevv...@gmail.com:
The current behavior of the urlencode function (2.7: urllib, 3.x: urllib.parse)
encodes spaces as pluses:
from urllib import urlencode
urlencode({'a': 'some param'})
'a=some+param'
However, in most instances, it would be desirable to merely encode spaces using
percent encoding:
urlencode({'a': 'some param'})
'a=some%20param'
But there is no way to get this behavior in the standard library.
It would probably best to change this so it defaults to use the regular quote
function, but allows callers who need the legacy quote_plus behavior to pass
that in as a function parameter.
An acceptable fix would be to have the quote function taken as a keyword
parameter, so legacy behavior remains:
urlencode({'a': 'some param'})
'a=some+param'
Then the behavior could be adjusted where needed:
from urllib import quote
urlencode({'a': 'some param'}, quote=quote)
'a=some%20param'
--
components: Library (Lib)
messages: 151980
nosy: Stephen.Day
priority: normal
severity: normal
status: open
title: {urllib,urllib.parse}.urlencode should not use quote_plus
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13866
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
Stephen Kelly steve...@gmail.com added the comment: There are actually other bugs in the same code example: ... def __init__(self): # DST starts last Sunday in March ... d = datetime(dt.year, 4, 1) # ends last Sunday in October ... self.dston = d - timedelta(days=d.weekday() + 1) ... d = datetime(dt.year, 11, 1) ... self.dstoff = d - timedelta(days=d.weekday() + 1) where does dt come from? this fragment should be in the implementation of dst (in both the GMT1 and GMT2 classes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13666 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13817] deadlock in subprocess while running several threads using Popen
Changes by Stephen White stephen-python@randomstuff.org.uk: -- nosy: +Stephen.White ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13817 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11104] distutils sdist ignores MANIFEST
Stephen Thorne step...@thorne.id.au added the comment: I've taken the sdist.patch and wrote some tests for it. The resulting patch is attached as 'manifest-respect.patch'. -- nosy: +jerub Added file: http://bugs.python.org/file22242/manifest-respect.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11104] distutils sdist ignores MANIFEST
Stephen Thorne step...@thorne.id.au added the comment: This patch is tested against the 3.1 and default branches, the previous patch attached was against the 2.7 branch. -- Added file: http://bugs.python.org/file22243/manifest-respect-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue762963] timemodule.c: Python loses current timezone
Stephen White stephen-python@randomstuff.org.uk added the comment: Debian appear to have applied this patch, and it seems to be causing problems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593461 -- nosy: +Stephen.White ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue762963 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue762963] timemodule.c: Python loses current timezone
Stephen White stephen-python@randomstuff.org.uk added the comment: The patch, issue762963.diff, is broken. It is calling mktime on a struct tm that is initialized to zeros. This means that it should be filling in the missing fields based on their correct values for the date 1st Jan 1900, which is incorrect behaviour as the whole method should be choosing appropriate values based on the date provided by the user. However in practice this call to mktime is effectively a no-op on 32bit systems. The reason for this is: The mktime(p) call is at the top of the method, straight after the memset(p, '\0', ...) call. This means p-tm_year is zero. According to the definition of struct tm a zero in the year field means 1900. On a 32bit system the earliest date handled by libc is 2**31 seconds before the Epoch (1st Jan 1970); time.strftime(%Y-%m-%d %H:%M:%S %Z, time.localtime(-2**31))'1901-12-13 20:45:52 GMT' So dates in the year 1900 cannot be handled by libc, and in this situation the mktime(p) call makes no attempt to normalise the provided data (or fill in missing values). The situation is different on 64bit systems. Here there is no problem with a much wider range of dates. This means that dates during 1900 *are* handled by libc, and so it does attempt to normalise the data and fill in missing values. For most of the fields in the structure whether or not mktime fills in or alters their value is of little consequence, as they're immediately overwritten by the call to PyArg_Parse. However the contents of the tm_gmtoff tm_zone fields are not overwritten. If the mktime call does nothing (as on a 32bit system) then tm_zone remains NULL throughout. If the mktime call does fill in missing values (as on 64bit systems) then tm_zone is set to the appropriate timezone for the zero time (the beginning of the year 1900). In our case this is always GMT, because the beginning of the year is in winter (when we use GMT). If tm_zone is set when the structure is passed into strftime then it is honoured. So if it has been set by mktime to be GMT then strftime will output GMT, regardless of the correct timezone string for the actual time provided. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue762963 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11104] distutils sdist ignores MANIFEST
Stephen Thorne step...@thorne.id.au added the comment: I have 2 patches, with tests, that applies on python2.7 and the python3 series of branches, attached this ticket. I have also got a signed contributor agreement lodged with the PSF. Can I please have someone either apply my patches or tell me what I need to do in order to change them if they are being rejected. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11104] distutils sdist ignores MANIFEST
Stephen Thorne step...@thorne.id.au added the comment: Oh! I didn't see any notification that there was a review done. Thanks, I'll attend to that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11104] distutils sdist ignores MANIFEST
Stephen Thorne step...@thorne.id.au added the comment: This patch is an updated patch that fixes the things noted in the review from eric.araujo. -- Added file: http://bugs.python.org/file22437/manifest-respect-3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11104] distutils sdist ignores MANIFEST
Stephen Thorne step...@thorne.id.au added the comment:
Updated the patch to address the 'why not use .strip()' question. I used
.rstrip('\r\n') on the basis that filenames may have leading or trailing
spaces, and if you need that, you need to be able to specify that in a
MANIFEST, but it is perfectly logical to disallow them, so here's a patch that
doesn't support them.
It also reduces the line count by 2 because I'm composing the 'comment' and
'blank line' cases.
--
Added file: http://bugs.python.org/file22449/manifest-respect-3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11104
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11104] distutils sdist ignores MANIFEST
Stephen Thorne step...@thorne.id.au added the comment: Éric mentioned that i should check that this behaviour matches the documentation. I have gone and looked for all instances of MANIFEST in the documentation and found one place which was inconsistent. I've added the doc patch to the patch. Please review this new version. -- Added file: http://bugs.python.org/file22463/manifest-respect-3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Stephen Thorne step...@thorne.id.au added the comment: I'm having a look at this ticket now. It looks like this can be rewritten to use common code, and it would probably be good to use the 'email' module for creating the MIME segements properly. -- nosy: +jerub ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Stephen Thorne step...@thorne.id.au added the comment: Okay, I looked at this, then I ran into str/byte type problems with the email module. Will wait until 'email' is sorted out before I consider a ticket like this one again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12431] urllib2.Request.get_full_url() broken in newer versions of Python
Stephen White stephen-python@randomstuff.org.uk added the comment: Just to confirm that it was a release, but 2.7.1 so not the current. Doesn't appear to happen in Python 2.7 (as shipped with Fedora Core 14) or in Python 2.7.2. C:\\Python27\python.exe Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import urllib2 urllib2.Request(http://host/path#fragment;).get_full_url() 'http://host/path' Upgrading our affected Windows boxes to Python 2.7.2 seems to solve the problem. We're happy for this bug to remain closed. -- nosy: +Stephen.White ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13006] bug in core python variable binding
New submission from Stephen Vavasis vava...@uwaterloo.ca:
There seems to be a serious bug in how python 2.7.2 binds variables to values.
In the attached function buildfunclist, you see that there is a variable called
'funclist' that is initialized to [], and then is modified only with 'append'
calls. This means that once append is called 46 times, one expects that
funclist[45] is defined and will not change? And yet funclist[45] changes
several times as more data items are appended. The same bug is present in
3.2.2. My operating system is Windows 7 64-bit on a Lenovo Thinkpad T410. I'm
guessing that there is a problem with python's lazy copying-- it is a bit too
lazy and failing to make copies when lists are changed.
To exhibit this bug, proceed as follows:
import pickle
h = open('combined_oplists_pickle','r')
combined_oplists = pickle.Unpickler(h).load()
import pybugreport
funclist,funcdist = pybugreport.buildfunclist(combined_oplists)
and then you will see funclist[45] printed out on two successive iterations.
It has changed as a result of an append operation, which should not happen.
(It's 6th entry is longer.)
Here is the output:
funclist[45] = [0, 22973, '$FUNC', 'splitBoxInterior', [['InArg', [[['',
'ActiveBoxVectorI', '::', 'iterator', ''], ['thisboxdata_p', '']], [['',
'FaceIndex', ''], ['faceind', '', ['InOutArg', [[['', 'ActiveBoxVectorI',
''], ['interiorOrbitNextLev', '', ['RefGlobal', [[['', 'MIndex', ''],
['guiActiveBoxCount', '', ['Workspace', [[['', 'QMGVector', '', '',
'BoxCreationData', '', ' ', ''], ['boxCreationVec', ''], [], [[0, 23017],
[0, 23048], [0, 23068], [0, 23069]], [[0, 23001]]]
funclist[45] = [0, 22973, '$FUNC', 'splitBoxInterior', [['InArg', [[['',
'ActiveBoxVectorI', '::', 'iterator', ''], ['thisboxdata_p', '']], [['',
'FaceIndex', ''], ['faceind', '', ['InOutArg', [[['', 'ActiveBoxVectorI',
''], ['interiorOrbitNextLev', '', ['RefGlobal', [[['', 'MIndex', ''],
['guiActiveBoxCount', '', ['Workspace', [[['', 'QMGVector', '', '',
'BoxCreationData', '', ' ', ''], ['boxCreationVec', ''], [[0, 23115], [0,
23116], [0, 23117], [0, 23118], [0, 23119], [0, 23120], [0, 23121], [0, 23122],
[0, 23123], [0, 23124], [0, 23125], [0, 23126], [0, 23127], [0, 23128], [0,
23129], [0, 23130], [0, 23131], [0, 23132], [0, 23133], [0, 23134], [0, 23135],
[0, 23136], [0, 23139], [0, 23140], [0, 23141], [0, 23142], [0, 23143], [0,
23144], [0, 23145], [0, 23146]], [[0, 23017], [0, 23048], [0, 23068], [0,
23069], [0, 23137], [0, 23138], [0, 23147], [0, 23148], [0, 23149], [0,
23161]], [[0, 23001]]]
--
components: Interpreter Core
files: pybugreport.zip
messages: 144261
nosy: vavasis
priority: normal
severity: normal
status: open
title: bug in core python variable binding
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23190/pybugreport.zip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13006
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14878] send statement from PEP342 is poorly documented.
New submission from Stephen Lacy sl...@slacy.com: There's reasonable documentation of the yield statement for most python versions under Section 6: Simple Statements, particularly 6.8 The Yield Statement (http://docs.python.org/release/2.7/reference/simple_stmts.html#the-yield-statement) But, there's no mention of the return value of the yield statement, or that the send statement even exists. It's mentioned in passing here under PEP342 New Generator Features (http://docs.python.org/whatsnew/2.5.html#pep-342-new-generator-features) but should be given fuller explanation and cross-linking from the yield statement documentation. It's also mentioned a bit here: http://docs.python.org/howto/functional.html#passing-values-into-a-generator but again, not under the language documentation itself. -- assignee: docs@python components: Documentation messages: 161320 nosy: Stephen.Lacy, docs@python priority: normal severity: normal status: open title: send statement from PEP342 is poorly documented. versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14878 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14878] send statement from PEP342 is poorly documented.
Stephen Lacy sl...@slacy.com added the comment: okay, found the documentation I was looking for here: http://docs.python.org/reference/expressions.html#yield-expressions which appears to be copied and pasted and modified version of the docs here: http://docs.python.org/reference/simple_stmts.html#grammar-token-yield_stmt At the very least these should cross-reference each other, but I would guess that the text should be unified, but I'm not sure where. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14878 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists
Stephen Thorne step...@thorne.id.au added the comment: Here is a patch that synthesises the directory names at the point where file names are read in. The unit test now passes, and has had the expected failure removed. Patch collaboration with Diarmuid Bourke diarmuidbou...@gmail.com at the europython sprint. -- keywords: +patch nosy: +jerub Added file: http://bugs.python.org/file26302/zipimport-issue14905.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11319] Command line option -t (and -tt) does not work for a particular case
Stephen Thorne step...@thorne.id.au added the comment: In discussion with GvR, we've decided we're not interested in intentionally rejecting code that is valid for tab width values between 1 and 8 inclusive. Thanks for the bug report! -- nosy: +jerub ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11319 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1508475] transparent gzip compression in urllib
Changes by Stephen Thorne step...@thorne.id.au: -- nosy: +jerub ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1508475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14988] _elementtree: Raise ImportError when importing of pyexpat fails
Stephen Thorne step...@thorne.id.au added the comment: With the attached patch, with python3.3(trunk) I instead get: ./python.exe -c 'import _elementtree' Traceback (most recent call last): File string, line 1, in module File frozen importlib._bootstrap, line 1294, in _find_and_load File frozen importlib._bootstrap, line 1261, in _find_and_load_unlocked File frozen importlib._bootstrap, line 432, in _check_name_wrapper File frozen importlib._bootstrap, line 347, in set_package_wrapper File frozen importlib._bootstrap, line 360, in set_loader_wrapper File frozen importlib._bootstrap, line 872, in load_module ImportError: PyCapsule_Import could not import module pyexpat (I have deleted pyexpat.so out of the build for the purposes of testing) RuntimeError will continue to be raised in the case the version is wrong. -- keywords: +patch nosy: +jerub Added file: http://bugs.python.org/file26310/elementtree_importerror.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14826] urllib2.urlopen fails to load URL
Stephen Thorne step...@thorne.id.au added the comment: Here is a patch that uses the same quoting logic in urllib.request.Request.__init__ as is used by urllib.request.URLopener.open() -- keywords: +patch nosy: +jerub versions: +Python 3.3 -Python 2.7 Added file: http://bugs.python.org/file26311/urllib-quote-14826.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14826] urllib2.urlopen fails to load URL
Stephen Thorne step...@thorne.id.au added the comment: Here's a followup patch that fixes the trunk build for me. This will unbreak the builds as well as fixing this bug, but it should be investigated why URLopener calls to_bytes() and Request does not. Ideally this interface should be consistent. -- Added file: http://bugs.python.org/file26314/urllib-request.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Stephen Webber added the comment: This is intentional handling of non-existant variables, and is not resticted to '==' operations. Returning the value of a Counter parameter that has not yet been set returns 0 by default. See the documentation here: http://docs.python.org/library/collections.html Counter objects have a dictionary interface except that they return a zero count for missing items instead of raising a KeyError: Since this is intended behavior, I recommend this bug become closed. -- nosy: +ForeverBacchus ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Stephen Webber added the comment:
Hmm, that is odd behavior indeed.
I think having keys that point to zero values is important for iterating over a
set. For example:
x = Counter(a=10, b=0)
for k in set(x):
... x[k] += 1
...
x
Counter({'a': 11, 'b': 1})
is probably preferable to
x = Counter(a=10, b=0)
for k in set(x):
... x[k] += 1
...
x
Counter({'a': 11})
Perhaps to ensure intuitive behavior we could ensure that
Counter(a = 3) + Counter(b = 0) == Counter(a = 3, b = 0)
True
by aggregating all keys into the new Counter object, even those with zero
values? I would be happy to make such a patch, as it would be good experience
for me to learn. Would this be an acceptable solution, and is there other odd
behavior at work here?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14182
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists
Stephen Thorne added the comment: Please see attached new patch, based on review comments. -- Added file: http://bugs.python.org/file26894/zipimport-issue14905-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11104] distutils sdist ignores MANIFEST
Stephen Thorne step...@thorne.id.au added the comment: Yep - 2.7.2 was released 11th June 2011, the fix was committed Aug 1st 2011. So it won't be in the current 2.7 release. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11104 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus
Stephen Day stevv...@gmail.com added the comment:
I apologize for reopening this bug, but I find your interpretation to be
inaccurate. While technically valid, the combination of the documentation, the
function name and the main use cases yields pathological invocations of
urlencode. My bug report is to help mitigate these problems.
The main use case for url encoding of mapping types is not for posting form
data; the main use case is appending url parameters to a url:
from urllib import urlencode
from urlparse import urlunparse
urlunparse(('http', 'example.com', '/', None, urlencode({'a': 'some
string'}), None))
'http://example.com/?a=some+string'
Any sane person would naturally gravitate to a function called urlencode to
url encode a mapping type. If the urllib.urlencode function is indeed intended
for form-encoding, as I agree is hinted in the documentation, it should
indicate that its result is 'application/x-www-form-urlencoded' or it should be
called formencode.
The quote or quote_plus is not at all what I am looking for; I am quite
familiar with these library functions. These functions are for encoding
component strings; they don't meet the use case described at all:
quote({'a': 1})
Traceback (most recent call last):
File stdin, line 1, in module
File
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py,
line 1248, in quote
if not s.rstrip(safe):
AttributeError: 'dict' object has no attribute 'rstrip'
In addition, Java's URLEncoder implementation is hardly a good example of
standards compliant URL manipulation. Python is not Java. The Python community
needs to make its own, independent, mature language decisions. In general, the
use of '+' to encode spaces in content, even if it is compliant against an
arbitrary standard, is pathological, especially when used in urls. Even though
python's quote_plus function works symmetrically on its own, when pluses are
used in a multi-language environment it can become impossible to tell whether a
plus is a literal '+' or an encoded space. In addition, the usage of '%20' for
spaces will work in almost all cases.
RFC3986, Section 2 [1] describes the use of percent-encoding as a solution to
representing reserved characters. In practice, percent-encoding is used on the
value component of 'key=value' productions and this works in nearly all cases.
The referenced standard [2], while relevant to the implied use case, is not
applicable to url assembly.
Given your interpretation, it seems that there is no function in the python
standard library to meet the use case of correctly assembling url parameter
values, leaving application developers to come up with something like this:
''.join(['='.join((quote(k), quote(v))) for k,v in {'a': '1', 'b': 'with
spaces'}.iteritems()])
'a=1b=with%20spaces'
In most cases, people will just use urlencode, which uses pluses for spaces,
yielding pathological, noncompliant urls.
In deference to this bug closure, there are a few options:
1. Close this issue and keep polluting the world's urls with pluses for spaces.
2. Make urlencode target path/query parameter encoding and then create a new
function, formencode, for use in encoding form data, breaking backwards
compatibility.
3. Simply add a keyword argument to urlencode to allow the caller to specify
the encoding function and separator, retaining compatibility and satisfying all
of the above use cases.
Naturally, 3 seems to be a very reasonable solution to this bug.
[1] http://tools.ietf.org/html/rfc3986#section-2 explicitly covers
[2] http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
--
resolution: invalid -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13866
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus
Stephen Day stevv...@gmail.com added the comment:
While it's likely that adding a `quote`/`quote_plus` function paramater to
urlencode is the right solution, I want to ensure that the key point is
communicated clearly: encoding a space as a '+' is pathological, in that in the
common case, an unescaped encoded character is indistinguishable from a literal
'+'. Take the case of the literal string '+ '. If one uses the javascript
encodeURI function to encode the string in a browser console, one gets the
following:
encodeURI('+ ')
+%20
Now, we have a string that will not decode symmetrically. In other words, we
cannot tell if this string should decode to ' ' or '+ '. And while use of
encodeURI is discouraged, application developers still use it places,
introducing these kinds of errors.
Conversely, we can see that the behavior of encodeURIComponent, is unambiguous:
encodeURIComponent('+ ')
%2B%20
And while these are analogues to quote and quote_plus (there exists now
analogue to javascripts urlencode), it's easy to see that disambiguating the
encoding of the resulting output of urlencode would be desirable.
There is a similar situation with php library functions.
Furthermore, it is agreed that urlencode does follow the rules, but the rules,
as they are, introduce an asymmetrical, pathological encoding. Most services
accept '%20' as space in lieu of '+' when data is encoded as
'application/x-www-form-urlencoded' anyway.
Concluding, I know it seems a little silly to spend time filing this bug and
provide relevant cases, but I'd like to cite professional experience in this
matter; I have seen pluses-for-spaces introduce errors time and time again.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13866
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14308] '_DummyThread' object has no attribute '_Thread__block'
Stephen White stephen-python@randomstuff.org.uk added the comment: Glad this is fixed. Attached is a Python 2.7 file that demonstrates the problem in a pretty minimal way in case it is of any use to anyone. -- nosy: +Stephen.White Added file: http://bugs.python.org/file25511/bad-thread.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19210] Unicode Objects in Tuples
New submission from Stephen Tucker: If a tuple consists of a single unicode object with non-ASCII characters in it, the printing of the tuple causes the non-ASCII characters to appear correctly as characters. If the tuple contains such a unicode object and anything else (even if it contains nothing else but two or more such unicode objects), the printing of the tuple causes all non-ASCII characters in the objects to appear as their \u escapes instead of as their characters. The same thing happens when writing such tuples to a file that has been opened using codecs.open (filename, 'w', 'utf-8'). -- components: Windows messages: 199308 nosy: Stephen_Tucker priority: normal severity: normal status: open title: Unicode Objects in Tuples type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19210 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19210] Unicode Objects in Tuples
Stephen Tucker added the comment: Dear All (Eric Smith in particular), I see the issue has been closed - I guess that I have to use e-mail to continue this discussion. I attach a source file that demonstrates the feature, and the output from IDLE that it generated. Yours, Stephen Tucker. On Wed, Oct 9, 2013 at 6:10 PM, Eric V. Smith rep...@bugs.python.orgwrote: Eric V. Smith added the comment: Can you provide some code which demonstrates this? It's easier to address this if we have known working (or non-working) examples. Thanks. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19210 ___ -- Added file: http://bugs.python.org/file32027/UnicodeTupleTestIDLEOutput.txt Added file: http://bugs.python.org/file32028/UnicodeTupleTest.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19210 ___Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32 Type copyright, credits or license() for more information. import UnicodeTupleTest (u'\u2021',) (u'\u2021', u'\u2021') # # Set a unicode string with a non-ASCII character mystring = u'\u2021' # # Print the string print mystring # # Print the string enclosed in parentheses print (mystring) # # Print the string as the first item in a tuple whose second item is None print (mystring,) # # Set a tuple consisting of two instances of this string mytuple = (mystring, mystring) # # Print the tuple print mytuple ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
