[issue46807] Wrong class __annotations__ when field name and type are equal
New submission from Konstantin :
In [18]: class Str(str):
...: pass
In [19]: class Class:
...: Str: str
...:
...:
...: Class.__annotations__
Out[19]: {'Str': str}
In [20]: class Class:
...: Str: str = ""
...:
...:
...: Class.__annotations__
Out[20]: {'Str': str}
In [21]: class Class:
...: Str: Str = ""
...:
...:
...: Class.__annotations__ # Wrong!
Out[21]: {'Str': ''}
In [22]: class Class:
...: Str: Str
...:
...:
...: Class.__annotations__
Out[22]: {'Str': __main__.Str}
It reproduced all the version which support annotations as part of the core (I
tested python 3.6..3.10.2)
--
components: Parser
messages: 413586
nosy: kgubaev, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Wrong class __annotations__ when field name and type are equal
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46807>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44395] email.message as_string() not writing unixfrom
New submission from Konstantin Ryabitsev :
When using as_string(unixfrom=True), the "From " line is not always printed.
The behaviour is correct for as_bytes().
Test case:
import email.message
msg = email.message.EmailMessage()
msg.set_payload('Hello World\n')
msg.set_unixfrom('From foo@bar Thu Jan 1 00:00:00 1970')
msg['Subject'] = 'Hello'
msg['From'] = 'Me '
print('as_string:')
print(msg.as_string(unixfrom=True))
print('as_bytes:')
print(msg.as_bytes(unixfrom=True).decode())
Results (3.5 and 3.9):
as_string:
Subject: Hello
From: Me
Hello World
as_bytes:
>From foo@bar Thu Jan 1 00:00:00 1970
Subject: Hello
From: Me
Hello World
--
components: email
messages: 395635
nosy: barry, konstantin2, r.david.murray
priority: normal
severity: normal
status: open
title: email.message as_string() not writing unixfrom
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44395>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42787] email.utils.getaddresses improper parsing of unicode realnames
New submission from Konstantin Ryabitsev :
What it currently does:
>>> import email.utils
>>> email.utils.getaddresses(['Shuming [范書銘] '])
[('', 'Shuming'), ('', ''), ('', '范書銘'), ('', ''), ('', 'shumi...@realtek.com')]
What it should do:
>>> import email.utils
>>> email.utils.getaddresses(['Shuming [范書銘] '])
[('Shuming [范書銘]'), 'shumi...@realtek.com')]
--
components: email
messages: 384069
nosy: barry, konstantin2, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.getaddresses improper parsing of unicode realnames
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42787>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37402] Fatal Python error: Cannot recover from stack overflow issues on Python 3.6 and 3.7
konstantin danilov added the comment: Same error, python3.7. I have attached minifyed code version. It runs into infinite recursion due to __setattr__ call inside 'with' statement on top of same object. As result: > python /tmp/text.py Fatal Python error: Cannot recover from stack overflow. Current thread 0x7f6bb073d740 (most recent call first): File "/tmp/text.py", line 10 in __getattr__ ... File "/tmp/text.py", line 11 in __getattr__ File "/tmp/text.py", line 28 in __exit__ File "/tmp/text.py", line 13 in __getattr__ ... File "/tmp/text.py", line 11 in __getattr__ ... [2]22121 abort (core dumped) python /tmp/text.py -- components: +Interpreter Core -asyncio nosy: +konstantin danilov versions: -Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48439/text.py ___ Python tracker <https://bugs.python.org/issue37402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37277] http.cookies.SimpleCookie does not parse attribute without value (rfc2109)
New submission from Konstantin Enchant :
Very strange case but https://www.ietf.org/rfc/rfc2109.txt (see 4.1 Syntax:
General) defines that "= value" is optional for attribute-value pairs for
header Cookie.
And SimpleCookie fully broken if meets attribute without value, example:
```
>>> from http.cookies import SimpleCookie
# all ok
>>> SimpleCookie('a=1')
# parse fully broken and does not parse not only `test` but `a` too
>>> SimpleCookie('test; a=1')
# or
>>> SimpleCookie('a=1; test; b=2')
```
I think the problem hasn't been noticed for so long because people usually use
frameworks, for example, Django parse it correctly because has workaround -
https://github.com/django/django/blob/master/django/http/cookie.py#L20.
Also Go Lang handle that case too, example -
https://play.golang.org/p/y0eFXVq6byK
(How can you see Go Lang and Django has different behavior for that case and I
think Go Lang more better do it.)
The problem seems minor not but aiohttp use SimpleCookie as is
(https://github.com/aio-libs/aiohttp/blob/3.5/aiohttp/web_request.py#L482) and
if request has that strange cookie value mixed with other normal values - all
cookies can not be parsed by aiohttp (just request.cookies is empty).
In real world in my web application (based on aiohttp) it fully break
authentication for request based on cookies.
I hope that will be fixed for SimpleCookie without implement workaround for
aiohttp like Django.
--
messages: 345563
nosy: sirkonst
priority: normal
severity: normal
status: open
title: http.cookies.SimpleCookie does not parse attribute without value
(rfc2109)
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37277>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20042] Python Launcher, Windows, fails on scripts w/ non-latin names
Konstantin Zemlyak added the comment: Terry J. Reedy wrote: > Is this still relevant or should it be closed? Should be closed. > On Win10, I created a short script юникод.py using Save As from IDLE. > > py -2 юникод.py produces > C:\Programs\Python27\python.exe: can't open file '??.py': [Errno 22] > Invalid argument > If the patch fixes 2.7 and looks okay, maybe we should apply. If 'no' or > 'no', maybe we should forget 2.7 running files with such names. This outcome is expected and error comes from python itself, not from launcher. > On 3.5 and 3.6, the file runs without issue. The issue was opened with 3.3; > 3.5 switched to a much more recent compiler, and I did not see any indication > in the messages that this was tested on 3.5 before it was added. So perhaps > for 3.5+, this is out-of-date. Launcher works fine now from my testing. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25973] Segmentation fault with nonlocal and two underscores
Konstantin Enchant added the comment: The problem happens only when "nonlocal __something" in a class method. In your case f2() isn't class method. More interesting behavior with underscores - https://gist.github.com/sirkonst/6eff694c4546700417ea -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25973] Segmentation fault with nonlocal and two underscores
New submission from Konstantin Enchant: Code: # --- __obj = object() class Foo: def f1(self): nonlocal __obj f = Foo() f.f1() # <-- segmentation fault # --- -- messages: 257174 nosy: Konstantin Enchant priority: normal severity: normal status: open title: Segmentation fault with nonlocal and two underscores type: crash versions: Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25973] Segmentation fault with nonlocal and two underscores
Konstantin Enchant added the comment: Yes. Case: # --- class A: def f(self): nonlocal __x # --- must raises SyntaxError like case: # --- class A: def f(self): nonlocal x >> SyntaxError: no binding for nonlocal 'x' found # --- but doesn't crash with SegFault as it is now. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24754] argparse add_argument with action=store_true, type=bool should not crash
Konstantin Molchanov added the comment: Although I agree that specifying type with store_true or store_false is unnecessary, this shouldn't really be an error like this. Why not just ignore type if it can't be utilized? The error message implies the usage of add_argument is erroneous, however it is fully compatible with the spec give in the docs. Alternatively, the docs should be updated. -- nosy: +moigagoo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24754 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24136] document PEP 448: unpacking generalization
Changes by Konstantin Molchanov moiga...@live.com: Added file: http://bugs.python.org/file39919/replace_sequence_with_iterable.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24136] document PEP 448: unpacking generalization
Konstantin Molchanov added the comment: I've updated the Calls syntax reference in reference/expressions and the assignment object description in reference/simple_stmts. Please tell me if I'm generally doing OK. If I'm not, please guide me to the right direction. -- Added file: http://bugs.python.org/file39918/reference_calls_syntax_update.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24136] document PEP 448: unpacking generalization
Konstantin Molchanov added the comment: @vadmium thanks for the assistance! I'll kick off with the reference then. P.S. Am I the only one who doesn't receive any emails from the tracker? I never got the registration link or a follow-up notification from this issue. Am I missing something? P.P.S. I'm not yet familiar with the local etiquette, so please forgive me if I'm unintentionally breaking some rules. Is @mentioning OK? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21323] CGI HTTP server not running scripts from subdirectories
Konstantin S. Solnushkin added the comment: Hi, I am curious about the fate of this issue -- whether it will be recognised as a bug (possibly a regression bug). Remember, it worked in Python 3.3 but stopped working in 3.4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21323 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21785] __getitem__ and __setitem__ try to be smart when invoked with negative slice indices
Konstantin Tretyakov added the comment: Do note that things are not as simple as slices with negative indices are treated differently from scalar negative indicies. Namely, behaviour differs whether you use [] or .__getitem__, and whether you use [a:b] or [slice(a,b)]. This does not make sense from a specification perspective, but has to be made clear in the docs then. Besides, Jython does not have this problem and I presume other Python implementations might also be fine (e.g. PyPy or whatever else there exists, couldn't test now). Hence, although fixing the docs does seem like a simple solution, if you want to regard the docs as a specification of the Python language rather than a list of particular CPython features, this won't be reasonable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21785 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21785] __getitem__ and __setitem__ try to be smart when invoked with negative slice indices
Konstantin Tretyakov added the comment: Aha, I see. I knew I'd get bitten by not explicitly subclassing (object) one day. In any case, adding a reference to this issue into the docs of __getitem__ and __setitem__ would probably save someone some hours of utter confusion in the future. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21785 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21785] __getitem__ and __setitem__ try to be smart when invoked with negative slice indices
New submission from Konstantin Tretyakov: Consider the following example: class A: def __getitem__(self, index): return True If you invoke A()[-1], everything is fine. However, if you invoke A()[-1:2], you get an AttributeError: A instance has no attribute '__len__'. Moreover, if you define __len__ for your class, you will discover that __getitem__ will act smart and modify slice you are passing into the function. Check this out: class A: def __getitem__(self, index): return index.start def __len__(self): return 10 Now A()[-1:10] outputs 9. The same kind of argument-mangling happens within __setitem__. This is completely unintuitive and contrary to what I read in the docs (https://docs.python.org/2/reference/datamodel.html#object.__getitem__): Note that the special interpretation of negative indexes (if the class wishes to emulate a sequence type) is up to the __getitem__() method.. Especially intuitive is the fact that if you do A()[slice(-1,10)] or A().__getitem__(slice(-1,10)), no special treatment is done for the -1, everything works fine and the __len__ method is not invoked. As far as I understand, the root cause is the behaviour of STORE_SLICE+3 command, which tries to be too smart. I have discovered this within code where slice indexing was used to insert arbitrary intervals into a data structure (hence using negative numbers would be totally fine), and obviuosly such behaviour broke the whole idea, albeit it was nontrivial to debug and discover. This does not seem to be a problem for Python 3.3, however I believe fixing this in Python 2.7 is important as well. -- components: Interpreter Core messages: 220792 nosy: kt priority: normal severity: normal status: open title: __getitem__ and __setitem__ try to be smart when invoked with negative slice indices type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21785 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21323] CGI HTTP server not running scripts from subdirectories
New submission from Konstantin S. Solnushkin:
Somewhere between Python 3.3 and 3.4, a bug was introduced that forbids the
http.server module, working in CGI server mode, to run scripts residing in
subdirectories.
This will break existing software that relies on this feature.
How to reproduce the bug:
1. Create a temporary directory and enter it.
2. Create a directory cgi-bin, and then directory test inside cgi-bin.
3. Create a file test.py in cgi-bin/test with the following contents (see
also attachment to this bug report):
print(Content-type: text/plain
CGI script executed successfully!
)
4. When run, it should print the following:
Content-type: text/plain
CGI script executed successfully!
5. Now, run Python 3.3 in CGI HTTP server mode:
c:\Python33\python.exe -m http.server --cgi 8000
A request to http://localhost:8000/cgi-bin/test/test.py; then produces the
following in the HTTP server log:
Serving HTTP on 0.0.0.0 port 8000 ...
127.0.0.1 - - [21/Apr/2014 22:59:11] GET /cgi-bin/test/test.py HTTP/1.0 200 -
127.0.0.1 - - [21/Apr/2014 22:59:11] command: c:\Python33\python.exe -u
C:\TMP\cgi-bin\test\test.py
127.0.0.1 - - [21/Apr/2014 22:59:11] CGI script exited OK
6. Now, try this with Python 3.4, and the request will fail with the following
in the log:
C:\TMPc:\Python34\python.exe -m http.server --cgi 8000
Serving HTTP on 0.0.0.0 port 8000 ...
127.0.0.1 - - [21/Apr/2014 23:02:38] code 403, message CGI script is not a
plain file ('/cgi-bin/test')
127.0.0.1 - - [21/Apr/2014 23:02:38] GET /cgi-bin/test/test.py HTTP/1.0 403 -
This _could_ be related to the change introduced by issue 19435, although I am
not sure.
Tested with Windows XP SP3.
--
files: test.py
messages: 216960
nosy: k.s.solnushkin
priority: normal
severity: normal
status: open
title: CGI HTTP server not running scripts from subdirectories
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34993/test.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21323
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21177] ValueError: byte must be in range(0, 256)
Konstantin Zemlyak added the comment: To clarify few things: - Yes, I know that 256 doesn't fit into byte. I was checking how bytes/bytearray are handling overflow. - I know that range() is a half-open interval. Yet this error message still gave me a wtf moment because I didn't realize it was talking about python's range() builtin and not about mathematical term. So even though this message is technically 100% correct it still doesn't feel right. May I propose a message byte must be in range [0-255] instead? This won't be confused with either python's range() nor [] list notation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21177 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21177] ValueError: byte must be in range(0, 256)
New submission from Konstantin Zemlyak: Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. bytearray([256]) Traceback (most recent call last): File stdin, line 1, in module ValueError: byte must be in range(0, 256) bytes([256]) Traceback (most recent call last): File stdin, line 1, in module ValueError: bytes must be in range(0, 256) Tested on 2.7, 3.2, 3.3, 3.4. Frankly, this looks like an off-by-one error to me. -- components: Interpreter Core messages: 215744 nosy: zart priority: normal severity: normal status: open title: ValueError: byte must be in range(0, 256) type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21177 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20042] Python Launcher for Windows fails to invoke scripts with non-latin names
New submission from Konstantin Zemlyak: Running `py.exe юникод.py` in cmd window fails: E:\set PYLAUNCH_DEBUG=1 E:\py юникод.py launcher build: 32bit launcher executable: Console File 'C:\Users\Zart\AppData\Local\py.ini' non-existent Using global configuration file 'C:\Windows\py.ini' Called with command line: .pymaybe_handle_shebang: read 211 bytes maybe_handle_shebang: BOM not found, using UTF-8 parse_shebang: found command: python3 locating Pythons in 64bit registry locate_pythons_for_key: unable to open PythonCore key in HKCU locate_pythons_for_key: C:\Program Files\Python27\python.exe is a 64bit executable locate_pythons_for_key: C:\Program Files\Python2\PCBuild\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files\Python2\PCBuild\amd64\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files\Python32\python.exe is a 64bit executable locate_pythons_for_key: C:\Program Files\Python3\PCBuild\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files\Python3\PCBuild\amd64\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files\Python33\python.exe is a 64bit executable locate_pythons_for_key: C:\Program Files\Python3\PCBuild\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files\Python3\PCBuild\amd64\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locating Pythons in native registry locate_pythons_for_key: unable to open PythonCore key in HKCU locate_pythons_for_key: C:\Program Files (x86)\Python27\python.exe is a 32bit executable locate_pythons_for_key: C:\Program Files (x86)\Python2\PCBuild\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files (x86)\Python2\PCBuild\amd64\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files (x86)\Python32\python.exe is a 32bit executable locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files (x86)\Python33\python.exe is a 32bit executable locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\python.exe: ?? ?? ? ? ?, ? ? ??? ? . locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?? ?? ? ? ?, ? ? ??? ? . found configured value 'python3=3.2-32' in environment search for Python version '3.2-32' found 'C:\Program Files (x86)\Python32\python.exe' run_child: about to run 'C:\Program Files (x86)\Python32\python.exe .py' C:\Program Files (x86)\Python32\python.exe: can't open file '.py': [Errno 2] No such file or directory child process exit code: 2 Note Called with command line: .py in output shows that filename was mangled very early on. Invoking `юникод.py` (which is associated with py.exe) directly works fine though. The problem lies in Windows handling of command-line arguments and fix to this is simple but non-obvious. Patch attached. -- components: Unicode, Windows files: pylauncher-fix-launcing-unicode-filenames.patch keywords: patch messages: 206741 nosy: ezio.melotti, haypo, zart priority: normal severity: normal status: open title: Python Launcher for Windows fails to invoke scripts with non-latin names type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file33247/pylauncher-fix-launcing-unicode-filenames.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20042 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20042] Python Launcher for Windows fails to invoke scripts with non-latin names
Changes by Konstantin Zemlyak z...@zartsoft.ru: Removed file: http://bugs.python.org/file33247/pylauncher-fix-launcing-unicode-filenames.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20042 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20042] Python Launcher for Windows fails to invoke scripts with non-latin names
Konstantin Zemlyak added the comment: Sorry, fixed whitespaces in the patch. -- Added file: http://bugs.python.org/file33248/pylauncher-fix-launcing-unicode-filenames.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20042 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20042] Python Launcher for Windows fails to invoke scripts with non-latin names
Konstantin Zemlyak added the comment: I don't care much about debug output though it probably should be fixed. The point is that changing text mode of stdout has a weird side effect of fixing command-line arguments when invoking interactively from cmd.exe. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20042 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20042] Python Launcher for Windows fails to invoke scripts with non-latin names
Konstantin Zemlyak added the comment: There is something weird with my proposed fix. Right after submitting a bug with patch I've updated pythons on my system - 2.7.5 to 2.7.6, 3.3.2 to 3.3.3, and installed 3.4.0b1 - both 32- and 64-bit. Then my fixed py.exe stopped working. Then I've added _setmode for stdin/stdout/stderr and rebuilt both debug/release and x86/x64 versions: E:\set PYLAUNCH_DEBUG=1 E:\e:\cpython\PCbuild\py.exe юникод.py launcher build: 32bit launcher executable: Console launcher charset: Multi-byte File 'C:\Users\Zart\AppData\Local\py.ini' non-existent File 'e:\cpython\PCbuild\py.ini' non-existent Called with command line: .py maybe_handle_shebang: read 211 bytes maybe_handle_shebang: BOM not found, using UTF-8 parse_shebang: found command: python3 locating Pythons in 64bit registry locate_pythons_for_key: unable to open PythonCore key in HKCU locate_pythons_for_key: C:\Program Files\Python27\python.exe is a 64bit executable locate_pythons_for_key: C:\Program Files\Python2\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files\Python2\PCBuild\amd64\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files\Python32\python.exe is a 64bit executable locate_pythons_for_key: C:\Program Files\Python3\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files\Python3\PCBuild\amd64\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files\Python33\python.exe is a 64bit executable locate_pythons_for_key: C:\Program Files\Python3\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files\Python3\PCBuild\amd64\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files\Python34\python.exe is a 64bit executable locate_pythons_for_key: C:\Program Files\Python3\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files\Python3\PCBuild\amd64\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locating Pythons in native registry locate_pythons_for_key: unable to open PythonCore key in HKCU locate_pythons_for_key: C:\Program Files (x86)\Python27\python.exe is a 32bit executable locate_pythons_for_key: C:\Program Files (x86)\Python2\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files (x86)\Python2\PCBuild\amd64\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files (x86)\Python32\python.exe is a 32bit executable locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files (x86)\Python33\python.exe is a 32bit executable locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files (x86)\Python34\python.exe is a 32bit executable locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. locate_pythons_for_key: C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома. found configured value 'python3=3.3-32' in environment search for Python version '3.3-32' found 'C:\Program Files (x86)\Python33\python.exe' run_child: about to run 'C:\Program Files (x86)\Python33\python.exe .py' C:\Program Files (x86)\Python33\python.exe: can't open file '.py': [Errno 2] No such file or directory child process exit code: 2 E:\e:\cpython\PCbuild\py_d.exe юникод.py launcher build: 32bit launcher executable: Console launcher charset: Multi-byte File 'C:\Users\Zart\AppData\Local\py.ini' non-existent File 'e:\cpython\PCbuild\py.ini' non-existent Called with command line: юникод.py maybe_handle_shebang: read 211 bytes maybe_handle_shebang: BOM not found, using UTF-8 parse_shebang: found command: python3 locating Pythons in 64bit registry locate_pythons_for_key: unable to open PythonCore key in HKCU locate_pythons_for_key: C:\Program Files\Python27\python.exe is a 64bit executable locate_pythons_for_key: C:\Program Files\Python2\PCBuild\python.exe: Синтаксическая ошибка в имени файла, имени папки или метке тома
[issue20042] Python Launcher for Windows fails to invoke scripts with non-latin names
Konstantin Zemlyak added the comment: Some more fun stuff with command-line (I'm cutting output to few essential lines for easier reading): e:\cpython\PCbuild\py.exe юникод.py ... Called with command line: .py run_child: about to run 'C:\Program Files (x86)\Python33\python.exe .py' C:\Program Files (x86)\Python33\python.exe: can't open file '.py': [Errno 2] No such file or directory child process exit code: 2 e:\cpython\PCbuild\py.exe e:\юникод.py ... Called with command line: e:\юникод.py run_child: about to run 'C:\Program Files (x86)\Python33\python.exe e:\юникод.py' child process exit code: 0 E:\e:\cpython\PCbuild\py.exe тест\unicode.py ... Called with command line: ест\unicode.py run_child: about to run 'C:\Program Files (x86)\Python33\python.exe ест\unicode.py' C:\Program Files (x86)\Python33\python.exe: can't open file 'unprintable file name': [Errno 2] No such file or directory child process exit code: 2 E:\e:\cpython\PCbuild\py.exe e:\тест\unicode.py ... Called with command line: e:\тест\unicode.py run_child: about to run 'C:\Program Files (x86)\Python33\python.exe e:\тест\unicode.py' child process exit code: 0 E:\e:\cpython\PCbuild\py.exe юникод.py Called with command line: юникод.py run_child: about to run 'C:\Program Files (x86)\Python33\python.exe юникод.py' child process exit code: 0 IOW, so long as command-line starts with ASCII character everything is fine. If not, then one or more characters gets mangled. Now I'm not sure whether it's a cmd.exe bug or C runtime one, and whether it's possible to workaround about it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20042 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17562] Invitation to connect on LinkedIn
New submission from Konstantin: LinkedIn I'd like to add you to my professional network on LinkedIn. - Konstantin Konstantin Aslanidi Author of opentradingsystem.com Greater New York City Area Confirm that you know Konstantin Aslanidi: https://www.linkedin.com/e/-3qcne3-hesyzdls-6z/isd/11993347706/dmPEJwhm/?hs=falsetok=1F_d-YPz94_lE1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-3qcne3-hesyzdls-6z/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I3977399171_1/?hs=falsetok=3pdPq6KFR4_lE1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. -- messages: 185376 nosy: Aslanidi priority: normal severity: normal status: open title: Invitation to connect on LinkedIn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17562 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16340] Decoding error due to byte-compiling venv scripts at install time
Changes by Konstantin Zemlyak z...@zartsoft.ru: -- title: Decoding error at install time when byte-compiling venv scripts - Decoding error due to byte-compiling venv scripts at install time ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16340] Error: 'utf-8' codec can't decode byte 0x9e in position 0: invalid start byte
New submission from Konstantin Zemlyak: When installing python 3.3 under windows and checking Compile .py files to byte code after installation Lib/venv/scripts/nt/pydoc.py gets precompiled as well. This causes venv module to abort with Error: 'utf-8' codec can't decode byte 0x9e in position 0: invalid start byte while copying scripts from Lib/venv/scripts/nt since only .exe files are copied verbatim, and rest are treated as utf-8 text: http://hg.python.org/cpython/file/b20e473157b8/Lib/venv/__init__.py#l314 The solution is to add another exception to compileargs at Tools/msi/msi.py: http://hg.python.org/cpython/file/b20e473157b8/Tools/msi/msi.py#l419 This issue doesn't affect non-windows systems, since Lib/venv/scripts/posix doesn't contain .py files. -- components: Installation messages: 173955 nosy: zart priority: normal severity: normal status: open title: Error: 'utf-8' codec can't decode byte 0x9e in position 0: invalid start byte type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16340] Decoding error in venv when byte-compiling stdlib
Konstantin Zemlyak added the comment: If option to precompile python files is checked in installer, pydoc.py gets compiled into binary files Lib\venv\scripts\nt\__pycache__\pydoc.cpython33.pyc and Lib\venv\scripts\nt\__pycache__\pydoc.cpython33.pyo. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16340] Decoding error in venv when byte-compiling stdlib
Konstantin Zemlyak added the comment: Also current title is a bit wrong, since decoding error happens in runtime each time venv is invoked, while the source of the problem happens while byte-compiling stdlib at install time once. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16340] Decoding error at install time when byte-compiling venv scripts
Konstantin Zemlyak added the comment: Not at all. I have installed Python into C:\Program Files (x86)\Python33. Also made a copy into D:\Python33 and got the same results. The problem is in file contents (pyc/pyo files are binary, utf-8 fails to decode them), not in filenames. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11397] os.path.realpath() may produce incorrect results
Changes by Konstantin Nikitin n...@ya.ru: -- nosy: +stromsund ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11039] Use of 'L' specifier is inconsistent when printing long integers
New submission from Konstantin Osipov kostja.osi...@gmail.com: I'm using a 64 bit system, but the issue is as well repeatable on 32 bit systems: kostja@shmita:~$ python Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. 0x 18446744073709551615L [0x] [18446744073709551615L] str(0x) '18446744073709551615' str([0x]) '[18446744073709551615L]' Notice the 'L' specifier disappears when creating a string from an integer. I.e. depending on conversion order, 'L' specifier is present or absent in the resulting string representation. I don't know the reason why 'L' specifier is necessary at all when printing integers, rather, I'd say it's very harmful, because makes Python program platform-dependent (since int is mapped to C long, 32-bit systems print 'L' where 64-bit systems don't), but please at least make the output consistent! Thanks, -- kostja -- components: None messages: 127284 nosy: kostja priority: normal severity: normal status: open title: Use of 'L' specifier is inconsistent when printing long integers versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3766] socket.socket.recv broken (unbearably slow)
Konstantin Osipov kostja.osi...@gmail.com added the comment: I was able to observe the same issue: I'm using Python 2.6.5 on Ubuntu 10.0.4 LTS. My system is 64 bit Intel Core I7, Quad core, Linux kernel 2.6.32-generic x86_64, Ubuntu EGLIBC 2.11.1-0ubuntu7.5. A simple client TCP socket, which sends 35 bytes over to a server on localhost and receives 20 bytes in response, produces only 22 RPS. An identical application written in C gives me 7000 RPS. TCP_NODELAY is on on the server side. Turning on TCP_NODELAY on the client gives me ~500 RPS in Python (which I'm satisfied with, 'cause I think I then hit other bottlenecks). Still, such low performance on by default can be surprising and hard to debug. -- nosy: +kostja ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
Konstantin Svist fry@gmail.com added the comment: This issue sounds very interesting to me for a somewhat different reason. My problem is that I'm trying to run multiple processes on separate CPUs/cores with os.fork(). In short, the data set is the same (~2GB) and the separate processes do whatever they need, although each fork treats the data set as read-only. Right after the fork, data is shared and fits in RAM nicely, but after a few minutes each child process runs over a bunch of the data set (thereby modifying the ref counters) and the data is copied for each process. RAM usage jumps from 15GB to 30GB and the advantage of a fork is gone. It would be great if there was an option to separate out the ref counters for specific data structures, since it's obviously a bad idea to turn it on by default for everything and everyone. -- nosy: +Fry-kun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9320] os.environ is global for threads
Konstantin Zemlyak z...@zartsoft.ru added the comment: Environment variables have always been process-wide. It doesn't deserve any special mention in threads documentation. -- nosy: +zart ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9320 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9092] static behavior of local variables
New submission from Konstantin kaslan...@yahoo.com:
In [12]: def func(x=[]) :
: L=x
: L.append('a')
: return L
:
In [13]: func()
Out[13]: ['a']
In [14]: func()
Out[14]: ['a', 'a']
In [15]: func()
Out[15]: ['a', 'a', 'a']
In [16]: func()
Out[16]: ['a', 'a', 'a', 'a']
In [17]: x
---
NameError Traceback (most recent call last)
C:\Users\konstantin\ipython console in module()
NameError: name 'x' is not defined
In [18]:
In [19]: L
---
NameError Traceback (most recent call last)
C:\Users\konstantin\ipython console in module()
NameError: name 'L' is not defined
--
components: None
messages: 108789
nosy: Aslanidi
priority: normal
severity: normal
status: open
title: static behavior of local variables
type: behavior
versions: Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9092
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Konstantin Pelepelin konstantin.pelepe...@gmail.com added the comment: Did you test it against server-side form-data parser implementation? It will be useless if it won't work with most widespread implementations: PHP's and at least some others (consider some popular python web frameworks). MIME-compliance is not enough, because browsers send only subset of MIME format and server-side parsers don't expect bodies full of MIME features. Particularly, I believe, most implementations don't expect any Content-Transfer-Encoding, except binary, because only 8-bit transfers are implemented in browsers, also you should check there will be no line-splitting and header-folding in headers and content, and make sure CR+LF (not plain LF, which is in patch) is always used. -- nosy: +checat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with VS2008 on Windows x64
Konstantin Zemlyak z...@zartsoft.ru added the comment: Win2003 x64, VS2008, vanilla python 2.7rc1 amd64 from python.org. Building python packages with C extensions works fine. Tested on simplejson, jinja2 (with enabled speedups) and PIL. -- nosy: +zart ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with VS2008 on Windows x64
Konstantin Zemlyak z...@zartsoft.ru added the comment: 64-bit Windows, 64-bit cmd.exe, 64-bit python, not patched:: D:\c:\Program Files\Python27\python.exe Python 2.7rc1 (r27rc1:81787, Jun 6 2010, 20:03:36) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import distutils.msvc9compiler distutils.msvc9compiler.get_build_version() 9.0 distutils.msvc9compiler.find_vcvarsall(9.0) 'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat' How did you test? Maybe it's some difference in setup. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with VS2008 on Windows x64
Konstantin Zemlyak z...@zartsoft.ru added the comment: Tried msvc9compiler-py27.patch. find_vcvarsall() still works with the same result, while distutils.msvc9compiler.VS_BASE has been changed. :: distutils.msvc9compiler.find_vcvarsall(9.0) u'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat' distutils.msvc9compiler.VS_BASE 'Software\\Wow6432Node\\Microsoft\\VisualStudio\\%0.1f' Checked registry, 9.0 is only under Wow6432Node. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with VS2008 on Windows x64
Konstantin Zemlyak z...@zartsoft.ru added the comment: Using the remote shell, those VS2008 env vars are not set and so the build fails. Seems it doesn't load user profile. The output is: VS2008 product dir: None - Software\Microsoft\VisualStudio\9.0 VS2008 product dir: None - Software\Microsoft\VCExpress\9.0 Same for me. Your patch fixes registry lookup. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
