[issue512981] readline /dev/tty problem
Pierre added the comment:
I suggest to reopen this issue as there was a regression with python3.
import sys
sys.stdin = open("/dev/tty", "r")
import readline
print(input())
Write some text and press left.
Expected: the cursor goes left.
Actual: prints '^[[D' as is readline had not been imported.
bltinmodule.c checks that the current sys.stdin filno matches the C stdin
fileno. When they are different, it falls back to the default input
implementation.
https://github.com/python/cpython/blob/1e7b858575d0ad782939f86aae4a2fa1c29e9f14/Python/bltinmodule.c#L2097
I noticed that PyFile_AsFile no longer exists. Would calling `fdopen` be
acceptable?
--
nosy: +pierre.labatut
type: -> behavior
versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue512981>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue512981] readline /dev/tty problem
Pierre added the comment: Please, let me know if I should re-open a new bug for this one. -- ___ Python tracker <https://bugs.python.org/issue512981> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue512981] readline /dev/tty problem
Pierre added the comment:
A workaround consists in replacing fd(0) with /dev/tty without modifying
sys.stdin
import os
stdin = os.dup(0)
os.close(0)
tty = os.open("/dev/tty", os.O_RDONLY)
assert tty == 0
import readline
print("input:", input())
print("in:", os.read(stdin, 128))
--
___
Python tracker
<https://bugs.python.org/issue512981>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46302] IndexError inside list comprehension + workaround
New submission from Pierre Fortin : var = "u2" var.strip()[0] Works as expected, except that it returns IndexError (instead of "u") if used in a list comprehension -- at least, that's where I found it. Attached example script illustrates the issue. Call it with "mytest N" where N is 1 (fails), 2 (works), 3 (fails). mytest 1 -- KeyError expected; this was due to infile design change adding a digit to previously single char code mytest 2 -- workaround to actual issue in next test mytest 3 -- adding [0] fails when used in list comprehension -- components: Interpreter Core files: mytest messages: 410054 nosy: NetAlien priority: normal severity: normal status: open title: IndexError inside list comprehension + workaround type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file50548/mytest ___ Python tracker <https://bugs.python.org/issue46302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46302] IndexError inside list comprehension + workaround
Pierre Fortin added the comment:
[Thanks for the replies! I was trying to post this before seeing them.]
Major egg on face...
The more complex the code becomes, the more likely you will be burned by a
rookie mistake...
var = ''
var[0] WILL give IndexError -- Duh!
It was buried in the each.split('=') returning an empty string -- that's what
you get for making things easier for the user.
The easier code is to use, the more complex it must be...
Sorry for the noise.
--
___
Python tracker
<https://bugs.python.org/issue46302>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46767] [Doc] sqlite3 Cursor.execute() return value is unspecified
New submission from Pierre Thierry : In the documentation of the sqlite3 module, the return value for Connection.execute() is told to be the Cursor that was implicitly created, but nothing is said about the return value/type when using Cursor.execute(). -- components: Library (Lib) messages: 413327 nosy: kephas priority: normal severity: normal status: open title: [Doc] sqlite3 Cursor.execute() return value is unspecified type: enhancement versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12411] cgi.parse_multipart is broken on 3.x
Pierre Quentel added the comment: When the FieldStorage class was fixed there was a discussion in issue 4953 about the module-level functions parse() and parse_multipart(). The code was very similar to methods of the FieldStorage class so the idea was to use FieldStorage inside the functions The patch proposed in issue 11066 replaced the code in parse_multipart by just : def parse_multipart(fp, pdict): return FieldStorage(fp,environ=pdict) Did anyone test it ? -- ___ Python tracker <http://bugs.python.org/issue12411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12922] StringIO and seek()
Changes by Pierre Quentel : -- nosy: +quentel ___ Python tracker <http://bugs.python.org/issue12922> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11352] Buf in cgi module doc
New submission from Pierre Quentel : Hi, I wrote a patch for the cgi module in version 3.2rc1 (#4953). Small changes should be done to the documentation of this module to reflect the changes in the module API : - in section "20.2.2. Using the cgi module" original text : "If a field represents an uploaded file, accessing the value via the value attribute or the getvalue() method reads the entire file in memory as a string. This may not be what you want. You can test for an uploaded file by testing either the filename attribute or the file attribute. You can then read the data at leisure from the file attribute:" proposed new text (for files, value is bytes, not string, and the read() method on file also returns bytes) : "If a field represents an uploaded file, accessing the value via the value attribute or the getvalue() method reads the entire file in memory as bytes. This may not be what you want. You can test for an uploaded file by testing either the filename attribute or the file attribute. You can then read the data at leisure from the file attribute (the read() and readline() methods will return bytes) :" - version 3.2 introduced a parameter "encoding" for the FieldStorage constructor, used to decode the bytes received on the HTTP connection for fields other than files. This encoding must the one defined in the HTML document holding the form submitted to the CGI script ; it is usually defined by a meta tag : or by the Content-Type header for this document I'm not sure where this should be mentioned in the module documentation. Maybe in "20.2.9. Common problems and solutions" for the moment. But there are plans (#11066) to introduce another interface to change the encoding of sys.stdout in the CGI script itself, so another option would be to open a specific section about encodings Hope it's clear enough Pierre -- assignee: docs@python components: Documentation messages: 129691 nosy: docs@python, quentel priority: normal severity: normal status: open title: Buf in cgi module doc type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11352] Bug in cgi module doc
Pierre Quentel added the comment: "bug", not "buf"... -- title: Buf in cgi module doc -> Bug in cgi module doc ___ Python tracker <http://bugs.python.org/issue11352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11916] A few errnos from OSX
New submission from Pierre Carrier : A few errnos from OSX are missing in the eponymous module. --- 8< --- #ifdef EAUTH inscode(d, ds, de, "EAUTH", EAUTH, "Authentication error"); #endif #ifdef EBADARCH inscode(d, ds, de, "EBADARCH", EBADARCH, "Bad CPU type in executable"); #endif #ifdef EBADEXEC inscode(d, ds, de, "EBADEXEC", EBADEXEC, "Bad executable (or shared library)"); #endif #ifdef EBADMACHO inscode(d, ds, de, "EBADMACHO", EBADMACHO, "Malformed Mach-o file"); #endif #ifdef EBADRPC inscode(d, ds, de, "EBADRPC", EBADRPC, "RPC struct is bad"); #endif #ifdef ECANCELED inscode(d, ds, de, "ECANCELED", ECANCELED, "Operation canceled"); #endif #ifdef EDEVERR inscode(d, ds, de, "EDEVERR", EDEVERR, "Device error"); #endif #ifdef EFTYPE inscode(d, ds, de, "EFTYPE", EFTYPE, "Inappropriate file type or format"); #endif #ifdef ENEEDAUTH inscode(d, ds, de, "ENEEDAUTH", ENEEDAUTH, "Need authenticator"); #endif #ifdef ENOATTR inscode(d, ds, de, "ENOATTR", ENOATTR, "Attribute not found"); #endif #ifdef ENOPOLICY inscode(d, ds, de, "ENOPOLICY", ENOPOLICY, "Policy not found"); #endif #ifdef ENOTSUP inscode(d, ds, de, "ENOTSUP", ENOTSUP, "Operation not supported"); #endif #ifdef EPROCLIM inscode(d, ds, de, "EPROCLIM", EPROCLIM, "Too many processes"); #endif #ifdef EPROCUNAVAIL inscode(d, ds, de, "EPROCUNAVAIL", EPROCUNAVAIL, "Bad procedure for program"); #endif #ifdef EPROGMISMATCH inscode(d, ds, de, "EPROGMISMATCH", EPROGMISMATCH, "Program version wrong"); #endif #ifdef EPROGUNAVAIL inscode(d, ds, de, "EPROGUNAVAIL", EPROGUNAVAIL, "RPC prog. not avail"); #endif #ifdef EPWROFF inscode(d, ds, de, "EPWROFF", EPWROFF, "Device power is off"); #endif #ifdef ERPCMISMATCH inscode(d, ds, de, "ERPCMISMATCH", ERPCMISMATCH, "RPC version wrong"); #endif #ifdef ESHLIBVERS inscode(d, ds, de, "ESHLIBVERS", ESHLIBVERS, "Shared library version mismatch"); #endif --- >8 --- (PS: catched by scripting around https://github.com/pcarrier/stuff/blob/master/sys/errnos.c if someone wants to play with other "exotic" architectures) -- components: Extension Modules messages: 134351 nosy: pcarrier priority: normal severity: normal status: open title: A few errnos from OSX type: feature request versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue11916> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10689] _scproxy extension is NOT build
New submission from Pierre Vinet : >From Python 2.7 http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tar.bz2 >released on November 27th, 2010. At compile time : $ ../Python-2.7.1/configure --enable-framework $ make we obtain within standard output: building '_scproxy' extension creating build/Python-2.7.1 creating build/Python-2.7.1/Mac creating build/Python-2.7.1/Mac/Modules /sw/lib/gcc4.2/bin/gcc -fno-strict-aliasing -fno-common -dynamic -O2 -Wall -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/Python-2.7.1/Mac/Include -I. -IInclude -I../Python-2.7.1/Include -I/sw/include -I/opt/macports/include -I/opt/include -I/usr/X11R6/include -I/usr/include -I/usr/local/include -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/Python-2.7.1/Include -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/objet_fwk -c ../Python-2.7.1/Mac/Modules/_scproxy.c -o build/temp.macosx-10.3-ppc-2.7/../Python-2.7.1/Mac/Modules/_scproxy.o ../Python-2.7.1/Mac/Modules/_scproxy.c: In function ‘get_proxy_settings’: ../Python-2.7.1/Mac/Modules/_scproxy.c:67: error: lvalue required as unary ‘&’ operand Then the module _scproxy is not build, which yield to 35 tests crashes: test_SimpleHTTPServer test___all__ test_cgi test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_cookielib test_distutils test_email test_email_codecs test_email_renamed test_httpservers test_mailbox test_mimetypes test_normalization test_old_mailbox test_pyclbr test_robotparser test_sax test_site test_smtplib test_smtpnet test_ssl test_sundry test_urllib test_urllib2 test_urllib2_localnet test_urllib2net test_urllibnet test_wsgiref test_xml_etree test_xml_etree_c test_xmlrpc $ uname -a Darwin ts-77.rmkipqxaas02.globetrotter.net 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc Compiler gcc (GCC) is 4.2.4 (2007) Thanks, Pierre Vinet -- assignee: ronaldoussoren components: Build, Macintosh, Tests messages: 123857 nosy: ronaldoussoren, vinp priority: normal severity: normal status: open title: _scproxy extension is NOT build type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue10689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10768] Bug in scrolledtext
New submission from Pierre Quentel : The scrolledtext example crashes with this message : TypeError: unsupported operand type(s) for +: 'dict_keys' and 'dict_keys' It works if keys() are converted to lists in line 33 : methods = list(vars(Pack).keys()) + list(vars(Grid).keys()) + \list(vars(Place).keys()) Configuration : Python 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] on win32 -- components: Tkinter messages: 124593 nosy: quentel priority: normal severity: normal status: open title: Bug in scrolledtext type: crash versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue10768> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10768] Bug in scrolledtext
Pierre Quentel added the comment: The function example(), line 44 of the module - Pierre 2010/12/24 R. David Murray > > R. David Murray added the comment: > > Where is this example? > > -- > assignee: -> d...@python > components: +Documentation > nosy: +d...@python, r.david.murray > type: crash -> behavior > > ___ > Python tracker > <http://bugs.python.org/issue10768> > ___ > -- Added file: http://bugs.python.org/file20161/unnamed ___ Python tracker <http://bugs.python.org/issue10768> ___The function example(), line 44 of the module- Pierre2010/12/24 R. David Murray <mailto:[email protected]";>[email protected]> R. David Murray <mailto:[email protected]";>[email protected]> added the comment: Where is this example? -- assignee: Â -> d...@python components: +Documentation nosy: +d...@python, r.david.murray type: crash -> behavior ___ Python tracker <mailto:[email protected]";>[email protected]> <http://bugs.python.org/issue10768"; target="_blank">http://bugs.python.org/issue10768> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: Hi, I have started working on the port of a simplified version of Karrigell (a web framework) to Python3. I experienced the same problem as the other posters : in the current version, file upload doesn't work. So I've been working on the cgi module for a few days and now have a version which correctly manages file uploads in the tests I made The problem in the current version (3.2b2) is that all data is read from sys.stdin, which reads strings, not bytes. This obviously can't work properly to upload binary files. In the proposed version, for multipart/form-data type, all data is read as bytes from sys.stdin.buffer ; in the CGI script, the Python interpreter must be launched with the -u option, as suggested by Amaury, otherwise sys.stdin.buffer.read() only returns the beginning of the data stream The headers inside the multipart/form-data are decoded to a string using sys.stdin.encoding and passed to a FeedParser (which requires strings) ; then the data is read from sys.stdin.buffer (bytes) until a boundary is found If the field is a file, the file object in self.file stores bytes, and the attribute "value" is a byte string. If it is not a file, the value is decoded to a string, always using sys.stdin.encoding, as for all other fields for other types of forms Other cosmetic changes : - replaced "while 1" by "while True" - replaced "if type(value) == type([])" by "if isintance(value,list)" Attached file : zip with cgi_new.py and tests in a folder called "http" Tested with Python 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] on win32 ; files and CGI scripts served by Apache 2.2 -- nosy: +quentel Added file: http://bugs.python.org/file20217/http.zip ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: I attach the svn diff file against the present version (generated by Tortoise SVN), hope it's what you expect -- Added file: http://bugs.python.org/file20229/cgi_diff.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: Please ignore previous post. I worked on the version of cgi.py included in version 3.2b2, and I just realized there were changes commited to the svn repository since this version. I will post the diff file later, but you can always test the files in the zip file -- ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: Here is the correct diff file I also introduced a test to exit from the loop in read_multi() if the total number of bytes read reaches "content-length". It was necessary for my framework, which uses cgi.FieldStorage to read from the attribute rfile defined in socketserver. Without this patch, the program hangs after receiving the number of bytes specified in content length. I work on a Windows XP PC so it might be related to the bug #427345 handled by server.CGIHTTPRequestHandler.run_cgi() -- Added file: http://bugs.python.org/file20235/cgi_diff.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: Other version of the diff file. Nothing changed but I'm afraid I had left duplicate definitions of some methods in the FieldStorage class I follow the discussion on this thread, but would like to know if the patch has been tested and works -- Added file: http://bugs.python.org/file20244/cgi_diff.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment:
I agree that the only consistent solution is to impose that the attribute
self.fp must read bytes in all cases, all required conversions should occur
inside FieldStorage, using "some" encoding (not sure how to define it...)
If no argument fp is passed to __init__(), the instance uses the binary version
of sys.stdin. In my patch I use sys.stdin.buffer, but it also works if I set it
to sys.stdin.detach()
In all cases the interpreter must be launched with the -u option. As stated in
the documentation, the effect of this option is to "force the binary layer of
the stdin, stdout and stderr streams (which is available as their buffer
attribute) to be unbuffered. The text I/O layer will still be line-buffered.".
On my PC (Windows XP) this is required to be able to read all the data stream ;
otherwise, only the beginning is read. I tried Glenn's suggestion with mscvrt,
with no effect
I am working on the cgi.py module so that all tests (test_cgi and cgi_test)
pass with binary streams. It's almost finished ; I had to adapt the tests, and
sometimes fix bugs in them
Problems in test_cgi.py :
- in testQSAndFormData() string "data" should not begin with a line feed
- in testQSAndFormDataFile() : same thing as above + the argument to update
result should be {'upload': b'this is the content of the fake file\n'} : bytes,
ending with a line feed as in the string "data"
- in do_test(), for POST method, fp must be a BytesIO
- in test_fieldstorage_multipart(), expected value should be b'Testing 123.\n'
for the third case (filename is not None, bytes expected, there is a line feed
in string "data")
Problems in cgi_test.py
- data files mix headers (which should be strings) and POST data which should
be read as bytes. In setup(), the file is opened in binary mode, the first two
lines are read to initialize Content-Length and Content-Type, and an attribute
encoding = 'latin-1' is set
- the tests showed warnings "ResourceWarning: unclosed file <_io.BufferedReader
name='zenASCII.txt'>", I changed the code to avoid these warnings
I will send the results (diff for new version of cgi + tests) hopefully tomorrow
--
___
Python tracker
<http://bugs.python.org/issue4953>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: Option 1 is impossible, because the CGI script sometimes has no control on the stream : for instance on a shared web host, it will receive sys.stdin as a text stream I also vote for option 3 ; explaining that if no argument is passed, the program will use sys.stdin.buffer (or the result of sys.stdin.detach() : I guess it's the same ?), and that if an argument is passed, it must provide an attribute "buffer" (or a method detach() ?) as the binary layer of the stream BTW, I didn't have time to finish the versions of cgi.py and tests, my next slot is this week-end -- ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: Here is the diff file for the revised version of cgi.py FieldStorage tests if the stream is an instance of (a subclass of) io.TextIOBase. If true, data is read from its attribute buffer ; if it hasn't one (eg for StringIO instances), an AttributeException is raised. Should we have a more specific exception ? If false, the stream's method read() is supposed to return bytes ; an exception will be raised if it's not the case The encoding used to decode keys and values to strings is the attribute "encoding" of the stream, or "latin-1" if this attribute doesn't exist Besides FieldStorage, I modified the parse() function at module level, but not parse_multipart (should it be kept at all ?) I leave the code to set sys.stdin to binary on Windows for the moment, but it can be removed in the final version thanks to Victor's fix of issue 10841 I modified cgi_test.py and test_cgi.py (sent in a next post), all the tests pass with the revised version of cgi.py on my PC While testing the patch I found other related things that I suppose should be changed (but need to check again - perhaps there are already tracker issues about them) : - in http.server.CGIHTPPRequestHandler, the -u option should be removed (line 1123) - on Windows, http.server.SimpleHTTPRequestHandler.list_directory() fails with Arabic characters (mbcs encoding fails, utf-8 works) - in urllib.parse.unquote(), default encoding should be latin-1, not utf-8 (submitting a simple form with French accented characters raises a UnicodeEncodeError when trying to print the submitted value) -- Added file: http://bugs.python.org/file20322/cgi_diff_20110109.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: cgi tests -- Added file: http://bugs.python.org/file20323/cgi_tests.zip ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: @Glenn "Also, the use of FeedParser could be replaced by BytesFeedParser, thus eliminating the need to decode header lines in that loop." BytesFeedParser only uses the ascii codec ; if the header has non ASCII characters (filename in a multipart/form-data), they are replaced by ? : the original file name is lost. So for the moment I leave the text version of FeedParser @Victor : "you should use qs.encode(locale.getpreferredencoding(), 'surrogateescape')" Ok, I changed the code to that "Maybe a DeprecationWarning if we would like to drop support of TextIOWrapper later :-)" Maybe I'm missing something here, but sys.stdin is always a TextIOWrapper instance, even if set to binary mode "For the else case: you should maybe add a strict test on the type, eg. check for RawIOBase or BufferedIOBase subclass, isinstance(fp, (io.RawIOBase, io.BufferedIOBase)). It would avoid to check that fp.read() returns a bytes object (or get an ugly error later)." Rejecting non-instances of RawIOBase or BufferedIOBase is too much, I think. Any class whose instances have a read() method that return bytes should be accepted, like the TestReadLine class in test_cgi.py "Set sys.stdin.buffer.encoding attribute is not a good idea. Why do you modify fp, instead of using a separated attribute on FieldStorage (eg. self.fp_encoding)?" I set an attribute encoding to self.fp because, for each part of a multipart/form-data, a new instance of FieldStorage is created, and this instance needs to know how to decode bytes. So, either an attribute must be set to one of the arguments of the FieldStorage constructor, and fp comes to mind, or an extra argument has to be passed to this constructor, i.e. the encoding of the original stream -- ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment:
@Glenn
" The _defined_ encoding of the original stream is irrelevant, in the same
manner that if it is a text stream, that is irrelevant. The stream is binary,
and latin-1, or it is non-standard"
I wish it could be as simple, but I'm afraid it's not. On my PC,
sys.stdin.encoding is cp-1252. I tested a multipart/form-data with an INPUT
field, and I entered the euro character, which is encoded \x80 in cp-1252
If I use the encoding defined for sys.stdin (cp-1252) to decode the bytes
received on sys.stdin.buffer, I get the correct value in the cgi script ; if I
set the encoding to latin-1 in FieldStorage, since \x80 maps to undefined in
latin-1, I get a UnicodeEncodeError if I try to print the value ("character
maps to ")
--
___
Python tracker
<http://bugs.python.org/issue4953>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: @Glenn "I'm curious what your system (probably Windows since you mention cp-) and browser, and HTTP server is, that you used for that test. Is it possible to capture the data stream for that test? Describe how, and at what stage the data stream was captured, if you can capture it. Most interesting would be on the interface between browser and HTTP server." I tested it on Windows XP Family Edition 2020, Service Pack 3, with Python 3.2b2 Browsers : Mozilla Firefox 3.6.13 and Internet Explorer 7.0 Servers : Apache 2.2, and the built-in server started by : import http.server http.server.test(HandlerClass=http.server.CGIHTTPRequestHandler) I print the bytes received in the multipart/form-data part by "print(odelim+line)" at the end of method read_lines_to_outerboundary() of FieldStorage. The bytes sent when I enter the string "a"+"n tilde" + the euro sign are : b'a\xf1\x80' - that is, the cp-1252 encoding of the string Since it works the same with 2 browsers and 2 web servers, I'm almost sure it's not dependant on the configuration - but if others can tests on different configurations I'd like to know the result Basically, this behaviour is not surprising : if sys.stdin.encoding is set to a certain value, it's natural that the bytes sent on the binary layer are encoded with this encoding, not with latin-1 I attach the diff file for an updated version of cgi.py : - new argument stream_encoding instead of setting an attribute "encoding" to fp - use locale.getpreferredencoding() to decode the query string -- Added file: http://bugs.python.org/file20356/cgi_diff_20110111.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: Many thoughts and tests after... Glenn, the both of us were wrong : the encoding to use in FieldStorage is neither latin-1, nor sys.stdin.encoding : I tested form fields with characters whose utf-8 encoding has bytes that map to undefined in cp1252, the calls to the decode() method with sys.stdin.encoding failed The encoding used by the browser is defined in the Content-Type meta tag, or the content-type header ; if not, the default seems to vary for different browsers. So it's definitely better to define it The argument stream_encoding used in FieldStorage *must* be this encoding ; in this version, it is set to utf-8 by default But this raises another problem, when the CGI script has to print the data received. The built-in print() function encodes the string with sys.stdout.encoding, and this will fail if the string can't be encoded with it. It is the case on my PC, where sys.stdout.encoding is cp1252 : it can't handle Arabic or Chinese characters The solution I have tried is to pass another argument, charset, to the FieldStorage contructor, defaulting to utf-8. It must be the same as the charset defined in the CGI script in the Content-Type header FieldStorage uses this argument to override the built-in print() function : - flush the text layer of sys.stdin, in case calls to print() have been made before calling FieldStorage - get the binary layer of stdout : out = sys.stdout.detach() - define a function _print this way: def _print(*strings): for item in strings: out.write(str(item).encode(charset)) out.write(b'\r\n') - override print() : import builtins builtins.print = _print The function print() in the CGI script now sends the strings encoded with "charset" to the binary layer of sys.stdout. All the tests I made with Arabic or Chinese input fileds, or file names, succed when using this patch ; so do test_cgi and cgi_test (slightly modified) -- Added file: http://bugs.python.org/file20382/cgi_diff_20110112.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: I knew the builtins hack was terrible, thanks for the replies... I changed cgi.py with Glenn's IOMix class, and included the changes in make_file(). The patch is attached to this message Is it really too late to include it in 3.2 ? Missing a working cgi module is really a problem for a wider 3.x adoption -- Added file: http://bugs.python.org/file20383/cgi_20110113.diff ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: diff for the updated version of test_cgi.py, compatible with cgi.py -- Added file: http://bugs.python.org/file20384/test_cgi_20111013.diff ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0
Pierre Quentel added the comment: zip file with the updated cgi_test.py and associated files -- Added file: http://bugs.python.org/file20385/cgi_tests.zip ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20229/cgi_diff.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20235/cgi_diff.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20322/cgi_diff_20110109.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20323/cgi_tests.zip ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20356/cgi_diff_20110111.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20382/cgi_diff_20110112.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20383/cgi_20110113.diff ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20384/test_cgi_20111013.diff ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20244/cgi_diff.txt ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Pierre Quentel added the comment: Ok Eric, thanks for the tips I attach the diff for the 2 modified modules (cgi.py and test_cgi.py). For the other tests, they are not in the branch and there are many test files so I leave the zip file I removed outdated diffs -- Added file: http://bugs.python.org/file20387/cgi_32.patch ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Pierre Quentel added the comment: Ok, thanks. Here is a summary of the API changes : - the argument fp passed to FieldStorage is either an instance of (a subclass of) io.TextIOBase with a "buffer" attribute for the underlying binary layer (thus, it can't be a StringIO instance) ; or an object with read() and readline() methods that return bytes Defaults to sys.stdin - 2 additional arguments can be passed to the FieldStorage constructor : . stream_encoding : the encoding used by the user agent to encode submitted data. It must be the same as the content-type of the HTML page where the form stands. Defaults to utf-8 . charset : the encoding used by the CGI script (the one used by the print() function to encode and send to sys.stdout). It must be the same as the charset in the content-type header sent by this script. Defaults to None, in which case the default encoding of sys.stdout is used - the only change in the object returned by FieldStorage() is that, if a field represents a file (its argument filename is not None), the read() method on this field returns bytes, and its attribute "value" is a bytestring, not a string -- ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7936] sys.argv contains only scriptname
Pierre Bourgault added the comment: I had the same problem with another version of python on Windows 7. We are using python 2.4.2 for production and it is installed in D:\Tools\Python. For experimentation purpose, I installed Python 2.7 in the usual location. It broke a few things and I uninstalled both python, and reinstalled only 2.4.2. After that, using python 2.4.2, I got the problem described by this issue. None of my colleagues (who did not install Python 2.7) had the issue. The registry entry HKEY_CLASSES_ROOT\py_auto_file\shell\open\command was reading: D:\Tools\Python\python.exe "%1" It was missing %*. I added it and my issue went away. -- nosy: +pierrebourgault ___ Python tracker <http://bugs.python.org/issue7936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Pierre Quentel added the comment: Comment ça, no up to date patch ? cgi_32.patch is up to date, the API changes are documented, the unittests work, what else do you want ? -- ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Pierre Quentel added the comment: @Victor Thanks for the comments "- I don't understand why FieldStorage changes sys.stdout and sys.stderr (see remarks about IOMix above): please remove the charset argument (it is also confusing to have two encoding arguments). it should be done somewhere else" done "please remove the O_BINARY hack: the patch is for Python 3.2 and I closed issue #10841. If you would like a backport, another patch should be written later" done ""encoding = 'latin-1' # ?": write a real comment or remove it" I removed this part "'self.fp.read(...) # bytes': you should add a test on the type if you are not sure that fp.read() gives bytes" added tests in read_urlencoded(), read_multi() and read_binary() "file: the file(-like) object from which you can read the data *as bytes*": you should mention that TextIOWrapper is also tolerated (accepted?)" not done : here "file" is not the argument passed to the FieldStorage constructor, but the attribute of values returned from calls to FieldStorage. In the new implementation, its read() method always returns bytes "you may set fp directly to sys.stdin.buffer (instead of sys.stdin) if fp is None (it will be easier after removing the O_BINARY thing)" done "the patch adds a tab in an empty line, please don't do that :-)" done (hopefully :-) "you should add a (private?) attribute to FieldStorage to decide if it works on bytes or unicode, instead of using "self.filename is not None" test (eg. self._use_bytes = (self.filename is not None)" done "i don't like the idea of having a generic self.__write() method supporting bytes and unicode. it would prefer two methods, eg. self.__write_text() and self.__write_binary() (they can share a third private method)" not done, the argument of __write is always bytes "i don't like "stream_encoding" name: what is the "stream" here? do you process a "file", a "string" or a "stream"? why not just "self.encoding"?" done - "import email.parser,email.feedparser" one import is useless here. I prefer "from email.feedparser import FeedParser" because you get directly a ImportError if the symbol is missing. And it's already faster to get FeedParser instead of email.feedparser.FeedParser in a loop (dummy micro-optimization) done " even I like the following change, please do it in a separated patch: -if type(value) is type([]): +if isinstance(value,list):" not done "I really don't like the IOMix thing:" removed "I vote +0 to commit the patch now (if the release manager agrees), and +1 if all of my remarks are fixed." should be close to +0.8 now ;-) -- Added file: http://bugs.python.org/file20402/cgi_32.patch ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20387/cgi_32.patch ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Pierre Quentel added the comment: Glenn, you read my mind ;-) Thanks for mentioning the O_BINARY thing. New (last !) patch attached -- Added file: http://bugs.python.org/file20403/cgi_32.patch ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20402/cgi_32.patch ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Pierre Quentel added the comment: Thanks a lot Victor ! I wrote the patch : Pierre Quentel ([email protected]) with many inputs by Glenn Linderman 2011/1/14 STINNER Victor > > STINNER Victor added the comment: > > Oh, I forgot to credit the author(s): who wrote the patch? > > -- > > ___ > Python tracker > <http://bugs.python.org/issue4953> > ___ > -- title: cgi module cannot handle POST with multipart/form-data in3.x -> cgi module cannot handle POST with multipart/form-data in 3.x Added file: http://bugs.python.org/file20405/unnamed ___ Python tracker <http://bugs.python.org/issue4953> ___Thanks a lot Victor !I wrote the patch : Pierre Quentel (mailto:[email protected]";>[email protected]) with many inputs by Glenn Linderman2011/1/14 STINNER Victor <mailto:[email protected]";>[email protected]> STINNER Victor <mailto:[email protected]";>[email protected]> added the comment: Oh, I forgot to credit the author(s): who wrote the patch? -- ___ Python tracker <mailto:[email protected]";>[email protected]> <http://bugs.python.org/issue4953"; target="_blank">http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Pierre Quentel : Removed file: http://bugs.python.org/file20405/unnamed ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Pierre Quentel added the comment: My latest patch for test_cgi is in cgi_32.patch I will try to add more tests later -- ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10911] cgi: add more tests
Pierre Quentel added the comment: Hi, I have written more tests, but also propose changes to cgi.py : - rewrite the parse_qs() and parse_multipart() functions so that they use FieldStorage methods instead of duplicating them - add a function set_stdout_encoding(encoding), using the IOMix class proposed by Glen Linderman in issue #4953 Should I post the new version of test_cgi.py here and open another issue for the other proposed changes to cgi.py, or use this issue to discuss both ? -- nosy: +quentel ___ Python tracker <http://bugs.python.org/issue10911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10911] cgi: add more tests
Pierre Quentel added the comment: Here is the diff file for test_cgi.py I added a test for a multipart/form-data form with non ASCII data to test the "encoding" parameter of FieldStorage -- keywords: +patch Added file: http://bugs.python.org/file20611/test_cgi.diff ___ Python tracker <http://bugs.python.org/issue10911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11066] cgi.py proposals : sys.stdout encoding + rewriting of parsing functions
New submission from Pierre Quentel : Python 3.2rc1 introduced a new version of cgi.py that handles correctly file uploads In this version, the FieldStorage constructor receives an argument "encoding" which is the encoding used by the document holding the submitted form On the CGI script side, there is currently no easy way to print the received form fields with another encoding than sys.stdout.encoding. The proposed version introduces a function, set_stdout_encoding(charset), which can be used in the CGI script to set sys.stdout to an instance of a class that uses the charset encoding. This way, print() will use this encoding. "charset" must be the encoding defined in the content-type header sent by the CGI scrpt This class (IOMix) was written by Glen Linderman and proposed in the 3.2rc1 version, but no consensus could be reached on time for the release Another proposed change is a rewriting of the module-level functions parse() and parse_multipart() : they now use the FieldStorage methods instead -- components: Library (Lib) files: cgi_20110129.diff keywords: patch messages: 127487 nosy: quentel priority: normal severity: normal status: open title: cgi.py proposals : sys.stdout encoding + rewriting of parsing functions type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file20612/cgi_20110129.diff ___ Python tracker <http://bugs.python.org/issue11066> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10911] cgi: add more tests
Pierre Quentel added the comment: I opened issue #11066 for the code refactoring -- ___ Python tracker <http://bugs.python.org/issue10911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3062] Turtle speed() function has no effect under Mac OS X
New submission from Pierre Bourdon <[EMAIL PROTECTED]>: When using the speed() function of the turtle module under Mac OS X, it has no effect : the turtle always draws lines with the same speed. An easy fix is to replace line 553 of the turtle.py file by "sleep(self._delay / 1000.0)", however I don't know if it is the best solution. -- components: Tkinter messages: 67831 nosy: delroth severity: normal status: open title: Turtle speed() function has no effect under Mac OS X type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2490] Assertion failure in datetime.strftime()
New submission from Pierre Metras <[EMAIL PROTECTED]>: datetime.strftime(pattern) fails in assertion if pattern is big enough (> 100 chars) while time.strftime(pattern) gives the expected result. This occurs on Python 2.5 (tested on OLPC XO laptop, Fedora 9). Python 2.4 (Debian Etch) does not exhibit this bug. -- components: Extension Modules files: test.py messages: 64536 nosy: genepi severity: normal status: open title: Assertion failure in datetime.strftime() versions: Python 2.5 Added file: http://bugs.python.org/file9862/test.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2490> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2490] Assertion failure in datetime.strftime()
Pierre Metras <[EMAIL PROTECTED]> added the comment: There is an example of a long strftime pattern in the test.py file attached to that issue. Just change the length of the pattern to see that it works for smaller patterns in Python 2.5. The pattern where it occured in my application is a Pango markup string used for localization: "%H:%M:%S" __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2490> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2490] Assertion failure in datetime.strftime()
Pierre Metras <[EMAIL PROTECTED]> added the comment: I did a mistake: OLPC XO is based on Fedora 7 and not 9. They plan to upgrade to 9 later this year (http://wiki.laptop.org/go/Fedora), so this bug will disappear by itself if it's confirmed that test.py runs correctly on Python 2.5.x and Fedora 9 ships with the latest version. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2490> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
New submission from Pierre Metras <[EMAIL PROTECTED]>: Please add support for pgettext(msgctxt, msgid) and variants (dpgettext, dcpgettext...) in the gettext module. I will not rephrase the justification for these functions and why contexts are essential for good localization: http://www.gnu.org/software/gettext/manual/gettext.html#Contexts -- components: Extension Modules messages: 64675 nosy: genepi severity: normal status: open title: Add gettext.pgettext() and variants support type: feature request versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2504> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4825] TypeError with complex.real() and complex.imag()
Pierre Bourdon added the comment: I don't think this is a valid issue : real and imag are just properties of complex objects, not methods ! -- nosy: +delroth ___ Python tracker <http://bugs.python.org/issue4825> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47259] string sorting often incorrect
New submission from Pierre Ossman : There is a big gotcha in Python that is easily overlooked and should at the very least be more prominently pointed out in the documentation. Sorting strings will produce results that is very confusing for humans. I happens to work for ASCII, but will generally produce bad results for other things as code points do not always follow the alphabetical order. The expressions chapter¹ mentions this fact, but you have to dig quite a bit to reach that. It also mentions that normalization is an issue, but it never mentions the issue about code point order versus alphabetical order. The sorting tutorial mentions under "Odds and ends"² that you need to use a special key or comparison function to get locale aware sorting. It doesn't mention that this also includes respecting alphabetical order, which might be overlooked unless you are very familiar with how the sorting works. The tutorial is also something you have to dig a bit to reach. Ideally string comparison would always be locale aware in a high level language such as Python. However, a smaller step would be a note on sorted()³ that extra care needs to be taken for strings as the default behaviour will produce unexpected results once your strings include anything outside the English alphabet. ¹ https://docs.python.org/3/reference/expressions.html ² https://docs.python.org/3/howto/sorting.html#odd-and-ends ³ https://docs.python.org/3/library/functions.html#sorted -- components: Interpreter Core messages: 416972 nosy: CendioOssman priority: normal severity: normal status: open title: string sorting often incorrect ___ Python tracker <https://bugs.python.org/issue47259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38092] environment variables not passed correctly using new virtualenv launching in windows and python3.7+
New submission from Pierre Glaser : If I am not mistaken, when creating a new process on Python3.7 and later on Windows, if using a virtualenv, Python now uses a launcher. The launcher is being notified that it must create a virtual-environment Python (and not a system Python) program using the __PYVENV_LAUNCHER__ environment variable, passed as part of the environment of launcher process created using in _winapi.CreateProcess (see https://github.com/python/cpython/blob/9008be303a89bfab8c3314c6a42330b5523adc8b/Lib/multiprocessing/popen_spawn_win32.py#L73-L75) However, if I am not mistaken `env` is not passed at the right position (https://github.com/python/cpython/blob/9008be303a89bfab8c3314c6a42330b5523adc8b/Modules/_winapi.c#L1062-L1068). These lines were part of a bugfix patch (see https://bugs.python.org/issue35797), solving an issue for multiprocessing-based packages. We ended trying to backport to loky (https://github.com/tomMoral/loky, a multiprocessing-based package) but the bug was not fixed. Passing 'env' correctly fixed the bug. Two things: - It is hard to provide a reproducer for this issue as it requires patching the CPython source code. - I don't understand why env being not passed correctly does not manifest itself in the test-suite. What is even more troubling is that even with this bug, the virtualenv launcher seems to get that a virtualenv is used when creating processes in multiprocessing (at least, sys.path includes the path/to/venv/lib/python3.x/site-packages). However, I am not familiar with the virtualenv launcher for python3.7+ and windows. -- components: Windows messages: 351650 nosy: paul.moore, pierreglaser, pitrou, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: environment variables not passed correctly using new virtualenv launching in windows and python3.7+ type: crash versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38092] environment variables not passed correctly using new virtualenv launching in windows and python3.7+
Pierre Glaser added the comment: > Dropping this into Lib/multiprocessing/spawn.py should cause a repro: if WINSERVICE: _python_exe = os.path.join(sys.exec_prefix, 'python.exe') else: _python_exe = getattr(sys, '_base_executable', sys.executable) In this case, spawn.get_executable() will return (sys._base_executable), and `env` will be set to None anyways no? (see these lines: https://github.com/python/cpython/blob/9008be303a89bfab8c3314c6a42330b5523adc8b/Lib/multiprocessing/popen_spawn_win32.py#L59-L68) We need to trigger the if clause of these lines instead, which happens by default in a virtual env -- this is why it is so troubling: even though a very simple case (launching a new process from within a virtualenv) should trigger a bug, it does not. > And maybe submit a PR with the fix? Will do. -- ___ Python tracker <https://bugs.python.org/issue38092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38082] datetime.time object incorrectly shows associated date in strftime() output
Change by Pierre Glaser : -- pull_requests: +15523 pull_request: https://github.com/python/cpython/pull/15882 ___ Python tracker <https://bugs.python.org/issue38082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38092] environment variables not passed correctly using new virtualenv launching in windows and python3.7+
Change by Pierre Glaser : -- keywords: +patch pull_requests: +15524 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15883 ___ Python tracker <https://bugs.python.org/issue38092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21705] cgi.py: Multipart with more than one file is misparsed
Pierre Quentel added the comment: The patch has been applied some time ago (I couldn't find the exact commit), cf. https://github.com/python/cpython/blob/master/Lib/cgi.py#L750 I think we can close the issue. -- nosy: +quentel ___ Python tracker <https://bugs.python.org/issue21705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21705] cgi.py: Multipart with more than one file is misparsed
Pierre Quentel added the comment: @ethan.furman Yes, in test_cgi.py, the method test_fieldstorage_multipart_w3c https://github.com/python/cpython/blob/master/Lib/test/test_cgi.py#L316) uses a multipart content with 2 files in it (https://github.com/python/cpython/blob/master/Lib/test/test_cgi.py#L579) -- ___ Python tracker <https://bugs.python.org/issue21705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20504] cgi.FieldStorage, multipart, missing Content-Length
Pierre Quentel added the comment: Now that the PR has been merged, can someone close the issue ? -- ___ Python tracker <https://bugs.python.org/issue20504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38469] PEP 572 : assignment expression to a global variable in a comprehension
New submission from Pierre Quentel : PEP 572 says that "an assignment expression occurring in a (...) comprehension (...) binds the target in the containing scope, honoring a nonlocal or global declaration for the target in that scope, if one exists." In Appendix B, the PEP shows this example : def f(): global TARGET a = [TARGET := EXPR for VAR in ITERABLE] So I don't understand why this fails: Python 3.8.0rc1 (tags/v3.8.0rc1:34214de, Oct 1 2019, 18:42:37) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = 0 >>> def f(): ... global x ... [x := i for i in range(5)] ... File "", line 3 SyntaxError: no binding for nonlocal 'x' found >>> Is this a bug or am I missing something ? -- components: Interpreter Core messages: 354601 nosy: quentel priority: normal severity: normal status: open title: PEP 572 : assignment expression to a global variable in a comprehension type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38469] PEP 572 : assignment expression to a global variable in a comprehension
Pierre Quentel added the comment: That was a quick fix, thanks ! -- ___ Python tracker <https://bugs.python.org/issue38469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44052] patch object as argument should be explicit
New submission from Pierre Ossman :
Right now if you use unittest.mock.patch() as a decorator it may or may not
pass the object as an argument to the test function. The behaviour is a side
effect of the argument "new" rather than something the caller can explicitly
control.
In many cases this gives the desired behaviour, but not in all. So this
behaviour should be possible to explicitly controlled.
One common case is when using patch() as a class decorator. If you want to
avoid getting extra arguments to every test function, then "new" has to be
specified. But that means that it will be the same object that will be used for
every test, not a fresh one.
E.g.
@patch('foo.bar.baz', [])
class TestCases(unittest.TestCase):
def test_a(self):
...
def test_b(self):
...
def test_c(self):
...
The tests will now be running with the same list in "foo.bar.baz" rather than a
fresh empty list for each run. Ideally we could instead specify:
@patch('foo.bar.baz', new_callable=list, as_arg=False)
class TestCases(unittest.TestCase):
def test_a(self):
...
def test_b(self):
...
def test_c(self):
...
Or something along those lines.
--
components: Library (Lib)
messages: 393062
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: patch object as argument should be explicit
___
Python tracker
<https://bugs.python.org/issue44052>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44052] patch object as argument should be explicit
Pierre Ossman added the comment: I've always been cautious about running patch() manually since it was easy to miss the cleanup. But those fears might be irrelevant these days when we have addCleanup(). Still, decorators are a more robust in more complex setups since you don't have to worry about setUp() being properly called in every base class. So I still think this would be interesting. A different function might be an option to avoid adding arguments. Just like there are a few special patch.*() already. -- ___ Python tracker <https://bugs.python.org/issue44052> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44085] Remaining invalid rules in simplified grammar
New submission from Pierre Quentel :
In the simplified version of Python grammar at
https://docs.python.org/3.10/reference/grammar.html, most 'invalid_' from
the complete grammar at
https://github.com/python/cpython/blob/3.10/Grammar/python.gram have been
removed, but 2 of them remain :
primary:
| invalid_primary # must be before 'primay genexp' because of
invalid_genexp
dict:
| '{' invalid_double_starred_kvpairs '}'
I suppose that the simplified version is extracted from the complete grammar
with a program, and this program doesn't detect the 'invalid_' that don't
end the line, since these 2 occurrences correspond to the only such lines in
the complete grammar
primary[expr_ty]:
| invalid_primary # must be before 'primay genexp' because of
invalid_genexp
dict[expr_ty]:
| '{' invalid_double_starred_kvpairs '}'
Also note the typo in the comment : 'primay genexp' instead of 'primary genexp'
--
assignee: docs@python
components: Documentation
messages: 393306
nosy: docs@python, quentel
priority: normal
severity: normal
status: open
title: Remaining invalid rules in simplified grammar
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44085>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44185] mock_open file handle __exit__ does not call close
Change by Pierre Ossman : -- nosy: +CendioOssman ___ Python tracker <https://bugs.python.org/issue44185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44503] Hide __enter__ calls in mock_open
New submission from Pierre Ossman :
I'd like to write this test case:
with patch('builtins.open') as pyopen:
mock_open(pyopen, read_data="foo")
run()
pyopen.assert_has_calls([call("filename", "wt"),
call().write("gazonk"),
call().close()])
and I shouldn't have to care if the code is written like this:
def run():
f = open("filename", "wt")
try:
write("gazonk")
finally:
f.close()
or like this:
def run():
with open("filename", "wt") as f:
write("gazonk")
--
components: Library (Lib)
messages: 396469
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: Hide __enter__ calls in mock_open
type: enhancement
___
Python tracker
<https://bugs.python.org/issue44503>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44503] Hide __enter__ calls in mock_open
Pierre Ossman added the comment: Also see Issue44185 for __exit__. -- ___ Python tracker <https://bugs.python.org/issue44503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44589] Pattern Matching - duplicate keys in mapping patterns
New submission from Pierre Quentel :
PEP 634 specifies that
"A mapping pattern may not contain duplicate key values. (If all key patterns
are literal patterns this is considered a syntax error; otherwise this is a
runtime error and will raise ValueError.)"
but this is not what happens with the latest release:
Python 3.10.0b3 (tags/v3.10.0b3:865714a, Jun 17 2021, 20:39:25) [MSC v.1929 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = {'a': 1}
>>> match x:
... case {'a': 1, 'a': 2}: # (A)
... print('ok')
...
>>> x = {'a': 3}
>>> match x:
... case {'a': 1, 'a': 2}: # (B)
... print('ok')
...
>>> x = {'a': 1, 'b': 2}
>>> match x:
... case {'a': 1, 'a': 2}: # (C)
... print('ok')
...
Traceback (most recent call last):
File "", line 2, in
ValueError: mapping pattern checks duplicate key ('a')
>>>
If I understand the PEP correctly, all these examples should raise a
SyntaxError for the line
case {'a': 1, 'a': 2}:
since all key patterns are literal patterns, and the key 'a' is duplicated.
Cases (A) where the subject matches one of the key-value patterns, and (B) when
it doesn't, fail without raising SyntaxError.
Case (C) where one of the keys in the subject is not present in the mapping
pattern raises a ValueError at runtime instead of SyntaxError.
This behaviour is tested in test_patma.py:
def test_patma_251(self):
x = {"a": 0, "b": 1}
w = y = z = None
with self.assertRaises(ValueError):
match x:
case {"a": y, "a": z}:
w = 0
self.assertIs(w, None)
self.assertIs(y, None)
self.assertIs(z, None)
but this doesn't seem compliant with the specification.
BTW, it's not clear to me why the SyntaxError should be limited to the case
when all keys are literal patterns; it could be raised whenever a literal
pattern is repeated, even when there are value patterns or a double-star
pattern, like in
case {'a': 1, 'a': 2, c.imag, **rest}:
--
components: Interpreter Core
messages: 397195
nosy: quentel
priority: normal
severity: normal
status: open
title: Pattern Matching - duplicate keys in mapping patterns
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44589>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44589] Pattern Matching - duplicate keys in mapping patterns
Pierre Quentel added the comment: Sorry, I don't know C so I can't write a PR for this change. -- ___ Python tracker <https://bugs.python.org/issue44589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence
New submission from Pierre Quentel :
This code
match range(42):
case [x, *w, y]:
z = 0
sets w to a list with 40 items : the length of the subject, minus the number of
non-star subpatterns.
But this code (adapted from test_patma_186) enters an infinite loop
import collections.abc
class Seq(collections.abc.Sequence):
def __getitem__(self, i):
print('get item', i)
return i
def __len__(self):
return 42
match Seq():
case [x, *w, y]:
z = 0
__getitem__ gets called forever, instead of stopping when the expected number
of items in w is reached.
--
components: Interpreter Core
messages: 398226
nosy: quentel
priority: normal
severity: normal
status: open
title: Pattern Matching - star subpattern with a subject derived from
collections.abc.Sequence
type: crash
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue44741>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence
Pierre Quentel added the comment:
Thanks for the explanations, but I feel unconfortable with the fact that
variable-length sequence patterns are implemented the same as unpacking. (sorry
if this has been discussed before, I can't find references to the discussions
that lead to the current version of the PEP).
There are obvious similarities between
[x, *y, z] = A
and
match A:
case [x, *y, z]:
print('ok')
but a big difference, put forward in PEP 634 : the classes supported for
pattern matching are limited (unpacking a generator expression is possible, but
they are not supported as subjects for sequence patterns), and the PEP
explicitely refers to them having a len().
It seems to me that this implies that the algorithms should be different:
- for unpacking, the iterable must be completely consumed before binding the
names on the left-hand side. If it is infinite, unpacking fails
- for variable-length sequence pattern matching (this is how I understand the
last paragraph about them in PEP 634):
. get the subject length
. iterate one by one before the star pattern
. iterate (len(subject) - number of non-star patterns) times for the star
pattern
. iterate one by one after the star pattern
In the second case, even if the subject never raises StopIteration, the match
succeeds.
Does this make sense ?
--
___
Python tracker
<https://bugs.python.org/issue44741>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence
Pierre Quentel added the comment: Oh, I did not invent this class, it is in the test script for pattern matching : https://github.com/python/cpython/blob/6948964ecf94e858448dd28eea634317226d2913/Lib/test/test_patma.py#L1932 With this class, [x, *_, y] matches, but not [x, *w, y] : this is what made me create this issue. Maybe it would be a good idea to change this class in test_patma.py ? OTOH, if the current implementation remains the same, why does the PEP insist on subjects having a len() ? Could sequence patterns match a wider range of subjects that can be unpacked ? -- ___ Python tracker <https://bugs.python.org/issue44741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44741] Pattern Matching - star subpattern with a subject derived from collections.abc.Sequence
Pierre Quentel added the comment: I found why len() is required, it's to avoid trying to match the subject (thus consuming a part of it) if its length is less than the number of non-star patterns, as explained in the PEP. My mistake, sorry. -- ___ Python tracker <https://bugs.python.org/issue44741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44774] incorrect sys.stdout.encoding within a io.StringIO buffer
New submission from Pierre Carbonnelle :
The following code
print("outside:", sys.stdout.encoding)
with redirect_stdout(io.StringIO()) as f:
print("inside: ", sys.stdout.encoding)
print(f.getvalue())
yields:
outside: utf-8
inside: None
Because StringIO is a string buffer, the expected result is:
outside: utf-8
inside: utf-8
This creates problem when using packages whose output depends on the
sys.stdout.encoding, such as z3-solver.
--
components: Library (Lib)
messages: 398528
nosy: pcarbonn
priority: normal
severity: normal
status: open
title: incorrect sys.stdout.encoding within a io.StringIO buffer
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44774>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44774] incorrect sys.stdout.encoding within a io.StringIO buffer
Pierre Carbonnelle added the comment: I expect sys.stdout to have utf-8 encoding inside the redirect because the buffer accepts unicode code points (not bytes), just as it does outside of the redirect. In other words, I expect the 'encoding' attribute of sys.stdout to have the same value inside and outside this redirect. It so happens that sys.stdout is an io.StringIO() object inside the redirect. The getvalue() method on this object returns a string (not a bytes), i.e. a sequence of unicode points. StringIO inherits from TextIOBase, which has an 'encoding' attribute. For some reason, the encoding of a StringIO object is None, which is inconsistent with its semantics: it should be 'uft-8'. -- ___ Python tracker <https://bugs.python.org/issue44774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44774] incorrect sys.stdout.encoding within a io.StringIO buffer
Pierre Carbonnelle added the comment:
As a work around, I had to use a temporary file (instead of a memory buffer):
print("outside:", sys.stdout.encoding)
with open("/tmp/log.txt", mode='w', encoding='utf-8') as buf:
with redirect_stdout(buf) as f:
print("inside: ", sys.stdout.encoding)
with open("/tmp/log.txt", mode='r', encoding='utf-8') as f:
print(f.read())
and get:
outside: utf-8
inside: utf-8
as expected.
--
___
Python tracker
<https://bugs.python.org/issue44774>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44774] incorrect sys.stdout.encoding within a io.StringIO buffer
Pierre Carbonnelle added the comment: I can live with the workaround, so, you can close the issue if you wish. As you say, maybe it's an issue with z3. Thank you for your time. -- ___ Python tracker <https://bugs.python.org/issue44774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45807] Strange SyntaxError message / suggestions for "@x = 123"
New submission from Pierre Quentel : In CPython 3.10 : Python 3.10.0 (tags/v3.10.0:b494f59, Oct 4 2021, 19:00:18) [MSC v.1929 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> @x = 123 File "", line 1 @x = 123 ^^^ SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='? but both suggestions lead to a SyntaxError : >>> @x == 123 ... File "", line 2 ^ SyntaxError: invalid syntax >>> @x := 123 ... File "", line 2 ^ SyntaxError: invalid syntax >>> Maybe an error message such as "cannot assign to decorator" would be more appropriate ? -- components: Parser messages: 406351 nosy: lys.nikolaou, pablogsal, quentel priority: normal severity: normal status: open title: Strange SyntaxError message / suggestions for "@x = 123" type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32371] Delay-loading of python dll is impossible when using some C macros
Pierre Chatelier added the comment: Can't reproduce any more. It might have been specific to the Visual Studio version I used at that time. -- ___ Python tracker <https://bugs.python.org/issue32371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32371] Delay-loading of python dll is impossible when using some C macros
Pierre Chatelier added the comment: Just reproduced and solved it at the same time ! It happened with Debug build, where I linked to pythonxx.lib instead of pythonxx_d.lib, because I did not download the debug binaries. Ultimately : my fault. -- ___ Python tracker <https://bugs.python.org/issue32371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32371] Delay-loading of python dll is impossible when using some C macros
Change by Pierre Chatelier : -- versions: +Python 3.8 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue32371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32371] Delay-loading of python dll is impossible when using some C macros
Pierre Chatelier added the comment: Aaand finally there is still something : it depends on the call context. Once in a C++/CLI class, the link bug occurs again. Here is attached a minimal project. -- status: closed -> open Added file: https://bugs.python.org/file48721/PythonFromC.zip ___ Python tracker <https://bugs.python.org/issue32371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39492] reference cycle affecting Pickler instances (Python3.8+)
New submission from Pierre Glaser :
The new Pickler reducer_override mechanism introduced in `Python3.8` generates
a reference cycle: for optimization purposes, a the pickler.reducer_override
bound method is referenced into the reducer_override attribute of the Pickler's
struct. Thus, until as a gc.collect call is performed, both the Pickler and all
the elements it pickled (as they are part of its memo), wont be collected.
We should break this cycle a the end of the dump() method.
See reproducer below:
```
import threading
import weakref
import pickle
import io
class MyClass:
pass
my_object = MyClass()
collect = threading.Event()
_ = weakref.ref(my_object, lambda obj: collect.set()) # noqa
class MyPickler(pickle.Pickler):
def reducer_override(self, obj):
return NotImplemented
my_pickler = MyPickler(io.BytesIO())
my_pickler.dump(my_object)
del my_object
del my_pickler
# import gc
# gc.collect()
for i in range(5):
collected = collect.wait(timeout=0.1)
if collected:
print('my_object was successfully collected')
break
```
--
components: Library (Lib)
messages: 360995
nosy: pierreglaser, pitrou
priority: normal
severity: normal
status: open
title: reference cycle affecting Pickler instances (Python3.8+)
type: resource usage
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39492>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39492] reference cycle affecting Pickler instances (Python3.8+)
Change by Pierre Glaser : -- keywords: +patch pull_requests: +17643 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18266 ___ Python tracker <https://bugs.python.org/issue39492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42556] unittest.mock.patch() cannot properly mock methods
New submission from Pierre Ossman : unittest.mock.patch() as it currently works cannot properly mock a method as it currently replaces it with something more mimicking a function. I.e. the descriptor magic that includes "self" isn't properly set up. In most cases this doesn't really matter, but there are a few use cases where this is important: 1. Calling base classes where you need to make sure it works regardless of super() or direct reference to the base class. 2. Multiple objects calling the same base class using super(). Without the self argument you can't tell the calls apart. 3. Setting up a side_effect that needs access to the object. In some cases you can pass the object using some side channel, but not all. E.g. not when mocking a base class' __init__(). (already reported as Issue35577). Right now you can work around this by using autospec, as that has the undocumented side-effect of properly setting up methods. So don't fix Issue41915 before this one or we lose that workaround. :) -- components: Library (Lib) messages: 382415 nosy: CendioOssman priority: normal severity: normal status: open title: unittest.mock.patch() cannot properly mock methods versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41915] unittest.mock.create_autospec(Obj, instance=True) has self keyword in _spec_signature if Obj implements __call__
Pierre Ossman added the comment: autospec's behaviour for methods is currently needed to work around Issue42556, so be careful with any fixes here so they don't break that workaround. -- nosy: +CendioOssman ___ Python tracker <https://bugs.python.org/issue41915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42833] Lib/urllib/request.py: digest algorithm should be case insensitive
Change by Pierre Tardy : -- components: +Library (Lib) status: open -> pending ___ Python tracker <https://bugs.python.org/issue42833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42833] Lib/urllib/request.py: digest algorithm should be case insensitive
New submission from Pierre Tardy : original bug report: https://github.com/buildbot/buildbot/issues/5743 Twisted by default advertises its algorithm in lowercase, which is uncommon, but allowed by the spec. https://tools.ietf.org/html/rfc3230#section-4.1.1 python's request.py is only supporting MD5 or SHA as algorithm, and not lowercase equivalent. This is an easy and harmless fix. -- messages: 384409 nosy: Pierre.Tardy priority: normal severity: normal status: open title: Lib/urllib/request.py: digest algorithm should be case insensitive type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42833] Lib/urllib/request.py: digest algorithm should be case insensitive
Change by Pierre Tardy : -- pull_requests: +22953 status: pending -> open pull_request: https://github.com/python/cpython/pull/24122 ___ Python tracker <https://bugs.python.org/issue42833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14317] index.simple module licking in distutils2
New submission from Pierre Lecointre : Got an error, in debian squeeze (python 2.6) and Ubuntu 11.10 (python 2.7) : plec@cezoffsrv04:~$ python Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from distutils2.index.simple import Crawler Traceback (most recent call last): File "", line 1, in ImportError: No module named index.simple >>> -- assignee: eric.araujo components: Distutils2 messages: 155893 nosy: Pierre.Lecointre, alexis, eric.araujo, tarek priority: normal severity: normal status: open title: index.simple module licking in distutils2 type: behavior ___ Python tracker <http://bugs.python.org/issue14317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14317] index.simple module lacking in distutils2
Changes by Pierre Lecointre : -- title: index.simple module licking in distutils2 -> index.simple module lacking in distutils2 versions: +Python 2.6 ___ Python tracker <http://bugs.python.org/issue14317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
