[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
[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 <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=... 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 <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 <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 <http://bugs.python.org/issue28423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46734] Add Maildir.get_flags() to access message flags without opening the file
New submission from Stephen Gildea : A message's flags are stored in its filename by Maildir, so the flags are available without reading the message file itself. The structured message file name makes it efficient to scan a large mailbox to select only messages that are, for example, not Trashed. The mailbox.Maildir interface does not expose these flags, however. The only way to access the flags through the mailbox library is to create a mailbox.MaildirMessage object, which has a get_flags() method. But creating a MaildirMessage requires opening the message file, which is slow. I propose adding a parallel get_flags(key) method to mailbox.Maildir, so that the flags are available without having to create a MaildirMessage object. In iterating through a mailbox with thousands of messages, I find that this proposed Maildir.get_flags() method is 50 times faster than MaildirMessage.get_flags(). -- components: Library (Lib) messages: 413145 nosy: gildea priority: normal severity: normal status: open title: Add Maildir.get_flags() to access message flags without opening the file type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46734> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46734] Add Maildir.get_flags() to access message flags without opening the file
Change by Stephen Gildea : -- keywords: +patch pull_requests: +29463 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31302 ___ Python tracker <https://bugs.python.org/issue46734> ___ ___ Python-bugs-list mailing list Unsubscribe: https://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
[issue13006] bug in core python variable binding
New submission from Stephen Vavasis :
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
<http://bugs.python.org/issue13006>
___
___
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 : 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 <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 added the comment: Patch looks good to me. -- ___ Python tracker <http://bugs.python.org/issue13666> ___ ___ 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 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 <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 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 <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 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 <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 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
<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 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 <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 added the comment: Oh! I didn't see any notification that there was a review done. Thanks, I'll attend to that. -- ___ Python tracker <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 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 <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 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
<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 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 <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 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 <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 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 <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 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
<http://bugs.python.org/issue12431>
___
___
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 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 <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 added the comment: This issue seems to be the cause of issue4388 -- and cmdline_encoding-2.patch fixes it, fwiw. -- nosy: +ixokai ___ Python tracker <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 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 <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 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 <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 added the comment: For the record, everything (2.7, 3.1, and 3.x) runs this test successfully now. :) -- ___ Python tracker <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 : 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 <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 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 <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 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 <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 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 <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 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 <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 :
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 "", line 1, in
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
<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 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
<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 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 <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 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 <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 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 <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 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 <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 added the comment: New patch, sans trailing whitespace. Ahem. -- Added file: http://bugs.python.org/file19398/issue10116-nowhitespace.patch ___ Python tracker <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 : Removed file: http://bugs.python.org/file19390/issue10116.patch ___ Python tracker <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 : 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 <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 : -- components: +Library (Lib), Tests type: -> behavior ___ Python tracker <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 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 <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 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 <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 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 <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 : -- status: closed -> open ___ Python tracker <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 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 <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 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 <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 added the comment:
On 11/16/10 5:44 AM, Ronald Oussoren wrote:
> Ronald Oussoren 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
<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 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 <http://bugs.python.org/issue2901> ___ ___ 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 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 <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 :
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
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
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
<http://bugs.python.org/issue12032>
___
___
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 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 <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 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 <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 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 <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 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 <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 : 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 <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 added the comment: ... oops! Apparently dupe. Forgot to search first. Ignore. -- resolution: -> duplicate status: open -> closed ___ Python tracker <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 : -- superseder: -> pep-0370 on osx duplicates existing functionality ___ Python tracker <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 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 <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 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 <http://bugs.python.org/issue7108> ___ ___ 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 0660<<16, if not 0666<<16, since group permissions are pretty typically set, but even 0666<<16 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
[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 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 <http://bugs.python.org/issue6792> ___ ___ 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
[issue5183] wsgiref.simple_server not working
New submission from Stephen Day :
The attached application doesn't work. I think the value of self.headers
(see line 114) has a blank line at the end that it did not in Python 2.5
Here is the error message that occurs when it gets a request
(http://127.0.0.1:8080/):
Exception happened during processing of request from ('127.0.0.1',
60549)
Traceback (most recent call last):
File "C:\Python30\lib\socketserver.py", line 281, in
_handle_request_noblock
self.process_request(request, client_address)
File "C:\Python30\lib\socketserver.py", line 307, in process_request
self.finish_request(request, client_address)
File "C:\Python30\lib\socketserver.py", line 320, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "C:\Python30\lib\socketserver.py", line 614, in __init__
self.handle()
File "C:\Python30\lib\wsgiref\simple_server.py", line 136, in handle
self.rfile, self.wfile, self.get_stderr(), self.get_environ()
File "C:\Python30\lib\wsgiref\simple_server.py", line 115, in
get_environ
k,v = h.split(':',1)
ValueError: need more than 1 value to unpack
--
components: Library (Lib)
files: test_server.py
messages: 81366
nosy: StephenDay
severity: normal
status: open
title: wsgiref.simple_server not working
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12976/test_server.py
___
Python tracker
<http://bugs.python.org/issue5183>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5183] wsgiref.simple_server not working
Stephen Day added the comment: This seems to be fixed already (see Issue4718). Next time I'll search more... ___ Python tracker <http://bugs.python.org/issue5183> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5261] with lock fails on multiprocessing
New submission from Stephen Lynch : the following code gives a system error under python 2.6.1 import multiprocessing with multiprocessing.Lock(): pass SystemError: ..\Python\getargs.c:1413: bad argument to internal function -- components: Library (Lib) messages: 82106 nosy: stepheng.lynch severity: normal status: open title: with lock fails on multiprocessing versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5261> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38363] No Module named ..." and UTF-8 Byte Order Marks
New submission from Stephen Tucker : Hi, I am running Python 2.7.10 on Windows 10. I have discovered that if a .py source text file (that is, a Module text file) starts with a UTF-8 Byte Order Mark, the module does not get "found" by the import statement. I have just spent an inordinate amount of time reaching this conclusion. I realise that 2.7.10 is probably not being supported any more, however, please let me ask the questions anyway: Could ... Either: ... the error message please be more helpful? (Like, for example, "Module begins with a Byte Order Mark") Or:... the BOM be allowed at the start of a Module? Thanks. Stephen Tucker. -- messages: 353841 nosy: Stephen_Tucker priority: normal severity: normal status: open title: No Module named ..." and UTF-8 Byte Order Marks ___ Python tracker <https://bugs.python.org/issue38363> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38365] Issue 38363 - False Alarm - Sorry!
New submission from Stephen Tucker : Hi, Issue 38363 is a false alarm - I am sorry to have wasted your time. My mistake was that the file that had the BOM in it also had a space at the end of the filename. I removed the space and the module was found OK. Sorry again. Stephen Tucker. -- messages: 353854 nosy: Stephen_Tucker priority: normal severity: normal status: open title: Issue 38363 - False Alarm - Sorry! ___ Python tracker <https://bugs.python.org/issue38365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17519] unittest should not try to run abstract classes
Stephen Thorne added the comment: I have done some experimentation here and thought through this feature request. The concept we are trying to deliver is: "I would like to share functionality between test classes, by having an abstract parent, with concrete leaves" The metaclass abc.ABCMeta provides functionality that means two things: - any class with this metaclass (so the class and all its subclasses, typically) that have @abc.abstractmethod or @abc.abstractproperty decorated methods will be treated as abstract - any class that is treated as abstract will raise an exception immediately, to make it clear to the programmer (and unit tests) that a programming error has occured. Following this through, we end up with two ways in which this can go wrong in unit testing if we ask our unit testing framework to not test abstract classes. This is a complete example, with both failure modes illustrated: Consider: class AbstractTestCase(unittest.TestCase, metaclass=abc.ABCMeta): ... class FooTest(AbstractTestCase): def foo(self): return 1 In this case, AbstractTestCase will not be skipped: this is because without any abstract methods inside it: it's not actually considered 'abstract', and is a concrete class. In the second case: class AbstractTestCase(unittest.TestCase, metaclass=abc.ABCMeta): @abc.abstractmethod def foo(self): ... @abc.abstractmethod def bar(self): ... class FooTest(AbstractTestCase): def foo(self): return 1 In this case, because AbstractTestCase has 2 abstract methods, it will be skipped. No tests run. But also FooTest will be skipped because it has 1 abstract method, and is therefore also abstract. If this were a 'normal' program, we would see an exception raised when FooTest is instanciated, but because we're skipping tests in abstract classes, we skip all the tests and exit with success. My gut feeling on this is that what we really want is a decorator that says: Skip this class, and only this class, explicitly. All subclasses are concrete, only this one is abstract. -- nosy: +sthorne ___ Python tracker <https://bugs.python.org/issue17519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43972] Simple HTTP Request Handler in http.server does not set a content-length and does not close connections on 301s
New submission from Stephen Rosen :
If you use the `http.server` simple server and handler to serve a directory,
navigating to a directory name without a trailing slash will trigger a 301 to
add the trailing slash.
For example, if "foo/" is a directory under the file server, a GET for "/foo"
will receive a 301 Moved Permanently response with a Location header pointing
at "/foo/".
However, the response is sent without a "Content-Length: 0" and the connection
is not closed. Unfortunately, certain clients will hang indefinitely and wait
under these conditions, without processing the redirect. In my testing, curl
7.68 and Firefox 87 both exhibted this behavior.
If a Content-Length header is set, these clients behave correctly.
For example, subclass the handler and add
def send_response(self, code):
super().send_response(code)
if code == HTTPStatus.MOVED_PERMANENTLY:
self.send_header("Content-Length", "0")
--
components: Library (Lib)
messages: 392272
nosy: sirosen
priority: normal
severity: normal
status: open
title: Simple HTTP Request Handler in http.server does not set a content-length
and does not close connections on 301s
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43972>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43972] Simple HTTP Request Handler in http.server does not set a content-length and does not close connections on 301s
Change by Stephen Rosen : -- keywords: +patch pull_requests: +24395 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25705 ___ Python tracker <https://bugs.python.org/issue43972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43972] Simple HTTP Request Handler in http.server does not set a content-length and does not close connections on 301s
Stephen Rosen added the comment:
Ach! Sorry! I didn't even realize this but the issue only arises when you are
modifying the handler to set the protocol to HTTP/1.1 .
In HTTP/1.0 , there's no notion of persistent connections, so the issue does
not arise.
But when the protocol version changes to 1.1 , persistent connections are the
norm, and curl will wait indefinitely.
The following short script is sufficient to reproduce:
```
import http.server
class CustomRequestHandler(http.server.SimpleHTTPRequestHandler):
protocol_version = "HTTP/1.1"
with http.server.HTTPServer(("", 8000), CustomRequestHandler) as httpd:
try:
httpd.serve_forever()
except KeyboardInterrupt:
print("\nKeyboard interrupt received, exiting.")
```
After double-checking the docs, the current doc for `protocol_version` [1] is
quite clear about this:
"your server must then include an accurate Content-Length header (using
send_header()) in all of its responses to clients"
I still think the fix I proposed is an improvement. Setting a Content-Length
isn't forbidden in HTTP/1.0 , and it guarantees good behavior when HTTP/1.1 is
used.
[1]
https://docs.python.org/3/library/http.server.html#http.server.BaseHTTPRequestHandler.protocol_version
--
___
Python tracker
<https://bugs.python.org/issue43972>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43972] Simple HTTP Request Handler in http.server does not set a content-length and does not close connections on 301s
Stephen Rosen added the comment: Thanks for working with me to reproduce and understand the issue. I'm a little surprised that with the sample which sets the protocol version you're still not seeing the issue. If I create a directory tree, e.g. repro ├── foo/ └── server.py where `server.py` is the sample I gave, and run `server.py`, I find that `curl localhost:8000/foo` hangs. `curl -v` includes a message as part of its output which states that it's waiting for the connection to close. Full verbose output: ``` $ curl localhost:8000/foo -v * Trying 127.0.0.1:8000... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 8000 (#0) > GET /foo HTTP/1.1 > Host: localhost:8000 > User-Agent: curl/7.68.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 301 Moved Permanently < Server: SimpleHTTP/0.6 Python/3.8.5 < Date: Thu, 06 May 2021 15:53:13 GMT < Location: /foo/ * no chunk, no close, no size. Assume close to signal end < ^C ``` This holds over a few python versions: 3.6.12, 3.8.5, and 3.9.1 . That's probably a good enough sample since the relevant code hasn't changed in the stdlib. It's doubtful that the exact version of curl matters for this. I can also see the issue with Firefox opening `localhost:8000/foo`. It hangs without processing the redirect. Running the sample I gave, you're seeing curl exit cleanly? I wonder, with verbose output, maybe there's some useful message that will tell us why it's exiting. Does it not print the message, "no chunk, no close, no size. Assume close to signal end" ? > Note: the existing behavior is 10+ year old and don't want to introduce > changes if it is not a bug. I completely understand this stance. I believe it is a bug, but that it's rare enough that hasn't been filed or resolved, in spite of its age. Some browsers (e.g. Chrome) process redirects without waiting for a payload, so they would mask the issue. Plus, it only shows up when the protocol_version is set. I had a script at work with this issue for over a year without anyone running into the hangs. A coworker who prefers Firefox noticed the issue only recently, and I traced that back to this behavior. So even in my case, I didn't stumble across this issue until we'd been using the same test script with the bug in it for a long time. -- ___ Python tracker <https://bugs.python.org/issue43972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30256] Adding a SyncManager Queue proxy to a SyncManager dict or Namespace proxy raises an exception
Stephen Carboni added the comment: Just chiming in to say that this is still broken for me on Python 3.9.6, Win10/64: https://pastebin.com/64F2iKaj But, works for 3.10.0b4. -- nosy: +stephen.entropy ___ Python tracker <https://bugs.python.org/issue30256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45356] Calling `help` executes @classmethod @property decorated methods
Stephen Rosen added the comment: Probably >90% of the use-cases for chaining classmethod are a read-only class property. It's important enough that some tools (e.g. sphinx) even have special-cased support for classmethod(property(...)). Perhaps the general case of classmethod(descriptor(...)) should be treated separately from the common case? > I propose deprecating classmethod chaining. It has become clear that it > doesn't really do what people wanted and can't easily be made to work. If classmethod(property(f)) is going to be removed, can an implementation of classproperty be considered as a replacement? Or perhaps support via the other ordering, property(classmethod(f))? -- nosy: +sirosen2 ___ Python tracker <https://bugs.python.org/issue45356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39548] Request fails when 'WWW-Authenticate' header for Digest Authentication does not contain 'qop'
New submission from Stephen Balousek :
When making an HTTP request using an opener with an attached
HTTPDigestAuthHandler, the request causes a crash when the returned
'WWW-Authenticate' header for the 'Digest' domain does not return the optional
'qop' value.
Response headers:
=
Content-Type: application/json
Content-Security-Policy: default-src 'self' 'unsafe-eval'
'unsafe-inline';img-src 'self' data:
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Length: 600
WWW-Authenticate: Digest realm="ServiceManager", nonce="1580815098100956"
WWW-Authenticate: Basic realm="ServiceManager", charset="UTF-8"
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Expires: 0
Pragma: no-cache
Crash:
==
Error: Exception: 'NoneType' object has no attribute 'split'
Traceback (most recent call last):
...
File "/home/sbalousek/bin/restap.py", line 1317, in RunTest
status, payload, contentType = ExecuteRequest(baseUrl, test, tap);
File "/home/sbalousek/bin/restap.py", line 1398, in ExecuteRequest
response= opener.open(request, payload, timeout);
File "/usr/lib/python3.8/urllib/request.py", line 523, in open
response = meth(req, response)
File "/home/sbalousek/bin/restap.py", line 1065, in http_response
return self.process_response(request, response,
HTTPErrorProcessor.http_response);
File "/home/sbalousek/bin/restap.py", line 1056, in process_response
return handler(self, request, response);
File "/usr/lib/python3.8/urllib/request.py", line 632, in http_response
response = self.parent.error(
File "/usr/lib/python3.8/urllib/request.py", line 555, in error
result = self._call_chain(*args)
File "/usr/lib/python3.8/urllib/request.py", line 494, in _call_chain
result = func(*args)
File "/usr/lib/python3.8/urllib/request.py", line 1203, in http_error_401
retry = self.http_error_auth_reqed('www-authenticate',
File "/usr/lib/python3.8/urllib/request.py", line 1082, in
http_error_auth_reqed
return self.retry_http_digest_auth(req, authreq)
File "/usr/lib/python3.8/urllib/request.py", line 1090, in
retry_http_digest_auth
auth = self.get_authorization(req, chal)
File "/usr/lib/python3.8/urllib/request.py", line 1143, in get_authorization
if 'auth' in qop.split(','):
AttributeError: 'NoneType' object has no attribute 'split'
Diagnosis:
==
The crash is a result of an optional 'qop' value missing from the
'WWW-Authenticate' header.
This bug was introduced in changes for issue 38686.
--
components: Library (Lib)
messages: 361330
nosy: Stephen Balousek
priority: normal
severity: normal
status: open
title: Request fails when 'WWW-Authenticate' header for Digest Authentication
does not contain 'qop'
type: crash
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39548>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39548] Request fails when 'WWW-Authenticate' header for Digest Authentication does not contain 'qop'
Change by Stephen Balousek : -- keywords: +patch pull_requests: +17711 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18338 ___ Python tracker <https://bugs.python.org/issue39548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
Change by Stephen Balousek : -- pull_requests: +17752 pull_request: https://github.com/python/cpython/pull/18338 ___ Python tracker <https://bugs.python.org/issue38686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39548] Request fails when 'WWW-Authenticate' header for Digest Authentication does not contain 'qop'
Change by Stephen Balousek : -- versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue39548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40219] ttk LabeledScale: label covered by hidden element
New submission from Stephen Bell : The LabeledScale in tkinter.ttk seems to have some kind of hidden element that covers the LabeledScale's label when the value is set to mid-scale. Tested on Windows 10, Python 3.6 See below code to reproduce: import tkinter from tkinter import ttk master = tkinter.Tk() _out1Value = tkinter.IntVar(master) out1Slider = ttk.LabeledScale(master, from_=-100, to=100, variable=_out1Value, compound="bottom") _out1Value.set(0) # uncomment to "fix" # out1Slider.label.lift() out1Slider.pack() master.mainloop() -- components: Tkinter messages: 365940 nosy: Stephen Bell priority: normal severity: normal status: open title: ttk LabeledScale: label covered by hidden element versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue40219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40219] ttk LabeledScale: label covered by hidden element
Change by Stephen Bell : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue40219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40932] subprocess docs don't qualify the instruction to use shlex.quote by OS
Change by Stephen Farris : -- type: -> security ___ Python tracker <https://bugs.python.org/issue40932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40932] subprocess docs don't qualify the instruction to use shlex.quote by OS
New submission from Stephen Farris :
The subprocess docs state: "When using shell=True, the shlex.quote() function
can be used to properly escape whitespace and shell metacharacters in strings
that are going to be used to construct shell commands." While this is true on
Unix, it is not true on Windows. On Windows it is easy to create scenarios
where shell injection still exists despite using shlex.quote properly (e.g.
subprocess.run(shlex.quote("'&calc '"), shell=True) launches the Windows
calculator, which it wouldn't do if shlex.quote was able to prevent shell
injection on Windows). While the shlex docs state that shlex is for Unix, the
subprocess docs imply that shlex.quote will work on Windows too, possibly
leading some developers to erroneously use shlex.quote on Windows to try to
prevent shell injection. Recommend: 1) qualifying the above section in the
subprocess docs to make it clear that this only works on Unix, and 2) updating
the shlex docs with warnings that shlex.quote in particular is not for use on
Window
s.
--
assignee: docs@python
components: Documentation
messages: 371140
nosy: Stephen Farris, docs@python
priority: normal
severity: normal
status: open
title: subprocess docs don't qualify the instruction to use shlex.quote by OS
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue40932>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41092] Report actual size from 'os.path.getsize'
New submission from Stephen Finucane : The 'os.path.getsize' API returns the apparent size of the file at *path*, that is, the number of bytes the file reports itself as consuming. However, it's often useful to get the actual size of the file, or the size of file on disk. It would be helpful if one could get this same information from 'os.path.getsize'. -- components: Library (Lib) messages: 372183 nosy: stephenfin priority: normal severity: normal status: open title: Report actual size from 'os.path.getsize' type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
