[issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
Richard added the comment: Sorry to be obscure, Ronald. I mistook my configuration problem, described below for the original problem. But I can reproduce the problem with opening an existing file under IDLE, which is a segmentation fault. When opening a new window, I get a blank screen but no >>> prompt. I should have done this before on my two boxes. It shows pretty clearly that the abort trap problem in 2.6.x is my configuration problem. On the development box, I have mutliple Pythons, with varying degrees of IDLE success; on the production box I have only the factory installed 2.6.1 with no IDLE problem other than the one originally reported. Both boxes are under 10.6.4. Development: Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin $ /usr/bin/idle2.6 CGColor with 1 components Abort trap # This is probably due to paths crossed with 2.6.6 $ sudo /usr/bin/idle2.6 2010-10-20 10:12:16.329 Python[11954:1707] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs 2010-10-20 10:12:31.868 Python[11954:1707] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs 0 #IDLE works, otherwise, except for the segmentation issue Production: Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin #IDLE works, except for the segmentation issue for completeness: Development: Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin $ idle3 Floating point exception Development: Python 2.7 (r27:82508, Jul 3 2010, 21:12:11) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin ** IDLE can't import Tkinter. Your Python may not be configured for Tk. ** Development: Python 2.6.6 (r266:84292, Aug 28 2010, 10:17:47) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin #IDLE hangs -- ___ Python tracker <http://bugs.python.org/issue6864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10537] IDLE crashes when you paste something.
New submission from Richard : Whenever I paste anything into the IDLE shell, the program freezes, and then crashes. I'm using Python 2.7.1rcl with a Version 10.6.4 Mac OSX -- components: IDLE messages: 122441 nosy: 5ragar5 priority: normal severity: normal status: open title: IDLE crashes when you paste something. type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue10537> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3961] Arrows key do not browse in the IDLE
New submission from Richard <[EMAIL PROTECTED]>: I open python3.0 (rc1) IDLE from command line and it works fine, but when i press the arrows key they writes: ^[[A ^[[B ^[[C ^[[D also pagUP and pagDOWN writes: ^[[5~ ^[[6~ so I'm not able to browse the history and the all things with arrows key. More Info: my OS is Ubuntu 8.04 upgrade from 7.10 It's the first time that I have an issue with keyboard I have look for my international settings of keyboard but I don't note nothing of relevant. (my country is Italy-Europe) I have installed as main python 2.5 with I have no problem (works perfect) I made a standard alt-installation ./configure make make test # 1error with urllib2 and some skip (see attach txt) sudo make altinstall I have no other kind of problems with python3.0rc1 Is there someone has an idea?? -- Richard (excuse my English) -- components: IDLE files: maketestpython30_log.txt messages: 73788 nosy: italian-boy severity: normal status: open title: Arrows key do not browse in the IDLE type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11599/maketestpython30_log.txt ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3961> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44401] const kwlist for PyArg_ParseTupleAndKeywords and PyArg_VaParseTupleAndKeywords
Change by Richard : -- keywords: +patch nosy: +immortalplants nosy_count: 1.0 -> 2.0 pull_requests: +25274 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26686 ___ Python tracker <https://bugs.python.org/issue44401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45130] shlex.join() does not accept pathlib.Path objects
New submission from Richard :
When one of the items in the iterable passed to shlex.join() is a pathlib.Path
object, it throws an exception saying it must be str or bytes. I believe it
should accept Path objects just like other parts of the standard library such
as subprocess.run() already do.
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> from pathlib import Path
>>> shlex.join(['foo', Path('bar baz')])
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.9/shlex.py", line 320, in join
return ' '.join(quote(arg) for arg in split_command)
File "/usr/lib/python3.9/shlex.py", line 320, in
return ' '.join(quote(arg) for arg in split_command)
File "/usr/lib/python3.9/shlex.py", line 329, in quote
if _find_unsafe(s) is None:
TypeError: expected string or bytes-like object
>>> shlex.join(['foo', str(Path('bar baz'))])
"foo 'bar baz'"
Python 3.11.0a0 (heads/main:fa15df77f0, Sep 7 2021, 18:22:35) [GCC 10.2.1
20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> from pathlib import Path
>>> shlex.join(['foo', Path('bar baz')])
Traceback (most recent call last):
File "", line 1, in
File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/shlex.py",
line 320, in join
return ' '.join(quote(arg) for arg in split_command)
^
File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/shlex.py",
line 320, in
return ' '.join(quote(arg) for arg in split_command)
^^
File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/shlex.py",
line 329, in quote
if _find_unsafe(s) is None:
^^^
TypeError: expected string or bytes-like object, got 'PosixPath'
>>> shlex.join(['foo', str(Path('bar baz'))])
"foo 'bar baz'"
--
components: Library (Lib)
messages: 401301
nosy: nyuszika7h
priority: normal
severity: normal
status: open
title: shlex.join() does not accept pathlib.Path objects
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45130>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45130] shlex.join() does not accept pathlib.Path objects
Richard added the comment: While it may be primarily intended to combine output from shlex.split() again, IMO it's useful for manually constructed command lines as well, for example displaying instructions to a user where a path may contain spaces and special characters and needs to be properly escaped. As for converting int to str, since subprocess.run() does not do that, shlex.split() does not need to do so either. I never mentioned that, and while I could see that being useful as well, that would have to be a separate discussion. There's more of a case for automatic conversion for Path objects, which are supposed to work seamlessly in most places where strings are accepted. But such quirks of certain functions not accepting them and being forced to convert to str manually makes pathlib a little annoying to use compared to os.path. -- ___ Python tracker <https://bugs.python.org/issue45130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45130] shlex.join() does not accept pathlib.Path objects
Richard added the comment: IMO comparing shlex.join() to str.join() is a mistake. Comparing it to subprocess.run() is more appropriate. What do you mean by "proposal"? subprocess.run() already converts Path arguments to str since Python 3.6 (though IIRC this was broken on Windows until 3.7 or so). It indeed does not convert int arguments, but like I said that's irrelevant here, you're the one who brought it up. -- ___ Python tracker <https://bugs.python.org/issue45130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38222] pathlib Path objects should support __format__
Richard added the comment:
I would like for this to be reconsidered. Yes, you can use str(), but
converting back and forth becomes really clunky:
log_dir = 'logs/{date}'
log_file = Path(str(path).format(time.strftime('%Y-%m-%d')) / 'log.txt'
--
nosy: +nyuszika7h
___
Python tracker
<https://bugs.python.org/issue38222>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38222] pathlib Path objects should support __format__
Richard added the comment:
Sorry, that should have been:
log_dir = Path('logs/{date}')
--
___
Python tracker
<https://bugs.python.org/issue38222>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24132] Direct sub-classing of pathlib.Path
Richard added the comment: I agree this would be nice. For now, I'm doing this as a hack: class Path(type(pathlib.Path())): ... -- nosy: +nyuszika7h ___ Python tracker <https://bugs.python.org/issue24132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45487] SSLEOFError regression with certain servers in Python 3.10
New submission from Richard :
Starting in Python 3.10, TLS connections to certain servers (e.g.
websocket-cs.vudu.com:443) are failing when it worked fine on Python 3.9 and
earlier on the same system.
Minimal working example:
```
#!/usr/bin/env python3
import socket
import ssl
HOST = 'websocket-cs.vudu.com'
PORT = 443
sock = socket.create_connection((HOST, PORT))
ctx = ssl.create_default_context()
ssock = ctx.wrap_socket(sock, server_hostname=HOST)
print("Connection successful")
```
Output:
```
❯ python3.9 ssl_eof_test.py
Connection successful
❯ python3.10 ssl_eof_test.py
Traceback (most recent call last):
File "/home/nyuszika7h/ssl_eof_test.py", line 11, in
ssock = ctx.wrap_socket(sock, server_hostname=HOST)
File "/home/nyuszika7h/.pyenv/versions/3.10.0/lib/python3.10/ssl.py", line
512, in wrap_socket
return self.sslsocket_class._create(
File "/home/nyuszika7h/.pyenv/versions/3.10.0/lib/python3.10/ssl.py", line
1070, in _create
self.do_handshake()
File "/home/nyuszika7h/.pyenv/versions/3.10.0/lib/python3.10/ssl.py", line
1341, in do_handshake
self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:997)
❯ python3.11 ssl_eof_test.py
Traceback (most recent call last):
File "/home/nyuszika7h/ssl_eof_test.py", line 11, in
ssock = ctx.wrap_socket(sock, server_hostname=HOST)
^^^
File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/ssl.py", line
517, in wrap_socket
return self.sslsocket_class._create(
^
File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/ssl.py", line
1075, in _create
self.do_handshake()
^^^
File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/ssl.py", line
1346, in do_handshake
self._sslobj.do_handshake()
^^^
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:998)
```
System information:
```
❯ uname -a
Linux cadoth 5.10.0-8-amd64 #1 SMP Debian 5.10.46-5 (2021-09-23) x86_64
GNU/Linux
❯ lsb_release -d
Description:Debian GNU/Linux 11 (bullseye)
❯ openssl version
OpenSSL 1.1.1k 25 Mar 2021
❯ python3.9 -VV
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110]
❯ python3.10 -VV
Python 3.10.0 (default, Oct 5 2021, 00:24:29) [GCC 10.2.1 20210110]
❯ python3.11 -VV
Python 3.11.0a1+ (heads/main:547d26aa08, Oct 15 2021, 17:35:52) [GCC 10.2.1
20210110]
❯ python3.9 -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.1.1k 25 Mar 2021
❯ python3.10 -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.1.1k 25 Mar 2021
❯ python3.11 -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.1.1k 25 Mar 2021
```
--
assignee: christian.heimes
components: SSL
messages: 404033
nosy: christian.heimes, nyuszika7h
priority: normal
severity: normal
status: open
title: SSLEOFError regression with certain servers in Python 3.10
type: behavior
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue45487>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45487] SSLEOFError regression with certain servers in Python 3.10
Richard added the comment: Note that the same happens with pyenv-compiled Python 3.9.7 (same way as I compiled 3.10 and 3.11), to rule out issues with different installation methods: ``` ❯ python3.9 -VV Python 3.9.7 (default, Oct 8 2021, 10:30:22) [GCC 10.2.1 20210110] ``` -- ___ Python tracker <https://bugs.python.org/issue45487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45487] SSLEOFError regression with certain servers in Python 3.10
Richard added the comment: Sorry, I mean it works fine with Python 3.9.2 from apt as well as Python 3.9.7 from pyenv. But 3.10.0 and 3.11-dev from pyenv are broken. -- ___ Python tracker <https://bugs.python.org/issue45487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45487] SSLEOFError regression with certain servers in Python 3.10
Richard added the comment: Never mind, I found the root cause after some debugging. Adding AES256-GCM-SHA384 to the cipher string resolved the issue. And now I see that the release notes say this: > The ssl module now has more secure default settings. Ciphers without forward > secrecy or SHA-1 MAC are disabled by default. Security level 2 prohibits weak > RSA, DH, and ECC keys with less than 112 bits of security. SSLContext > defaults to minimum protocol version TLS 1.2. Settings are based on Hynek > Schlawack’s research. (Contributed by Christian Heimes in bpo-43998.) -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25024] Allow passing "delete=False" to TemporaryDirectory
Richard added the comment: Sorry for reviving a 9 months old issue, but IMO there was no good reason to reject this especially when a patch was provided. Even if the context manager can be replaced with 3 lines of code, I still don't consider that very user-friendly. My use case would be passing `delete=False` temporarily while debugging my script, it would be much simpler than using a whole different hacky method when the end goal is to change it back to `delete=True` once it is completed anyway. What issues exactly does the addition of a simple option cause? I don't think something as trivial as this causes a maintenance burden, and you can't call it feature creep either when TemporaryDirectory doesn't have *any* other optional keyword arguments. -- nosy: +nyuszika7h ___ Python tracker <https://bugs.python.org/issue25024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31290] segfault on missing library symbol
New submission from Richard:
I'm building a Python library with a C++ component composed of a number of
source .cpp files.
After some changes today, compiling and loading in Python3 resulted in a
segfault:
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mymodule
Segmentation fault (core dumped)
As you might imagine, this is not the funnest thing ever to debug.
Thankfully, when I compiled the module for Python2 and tried to load, a much
more helpful and informative error message was displayed.
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mymodule
Traceback (most recent call last):
File "", line 1, in
File "mymodule/__init__.py", line 1, in
import _mymodule
ImportError: ./_mymodule.so: undefined symbol: DBFGetRecordCount
>>>
And indeed, it seems that in my setup.py file where I had
setuptools.Extension(
"_mymodule",
glob.glob('src/*.cpp') + glob.glob('lib/mylib/*.cpp') +
glob.glob('lib/mylib/sublib/*.c'),
I should have had 'lib/mylib/sublib/*.cpp'.
I think the current behaviour can be improved:
1. Python3 should provide a helpful error message, like Python2 does.
2. setup.py should fail or at least provide a warning if there are missing
symbols. (Perhaps this suggestion should be aimed at one of the setup
utilities, but I'm not sure where to send it.)
--
messages: 300942
nosy: immortalplants
priority: normal
severity: normal
status: open
title: segfault on missing library symbol
versions: Python 2.7, Python 3.5
___
Python tracker
<http://bugs.python.org/issue31290>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
Richard added the comment: I'm thinking that the Snow Leopard abort trap when invoking IDLE from the command line is a permissions problem somewhere because it works ok when invoked with sudo. The console displays an odd message "2010-08-07 20:38:23.375 Python[25858:170b] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs" is the only thing out of the ordinary. This is out-of-the-box 2.6.1 -- nosy: +Careaga ___ Python tracker <http://bugs.python.org/issue6864> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27493] logging module fails with unclear error when supplied a (Posix)Path
New submission from Richard:
No idea if I should be reporting this here, but it came with the default
installation, so here goes:
On a mac, I supplied a basicConfig object to the logging class that contains a
PosixPath instance for the "filename" attribute.
consequently, it fails with the error message "'PosixPath' object has no
attribute 'startswith'" without specifying where the issue lies.
offending value:
STATUSLOG_PATH = Path('~/logFiles/Reseller/').expanduser()
Relevant part of the traceback (which didn't print by default):
File
"/Users/rhendrikse/Documents/PythonScripts/Reseller/Reseller/application/application.py",
line 41, in __setup_logger
logging.basicConfig(level=logging.DEBUG, format=DEFS.RUNLOG_FORMAT,
filename=DEFS.RUNLOG_PATH)
File
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/logging/__init__.py",
line 1744, in basicConfig
h = FileHandler(filename, mode)
File
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/logging/__init__.py",
line 998, in __init__
self.baseFilename = os.path.abspath(filename)
File
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/posixpath.py",
line 357, in abspath
if not isabs(path):
File
"/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/posixpath.py",
line 64, in isabs
return s.startswith(sep)
AttributeError: 'PosixPath' object has no attribute 'startswith'
--
components: Library (Lib)
messages: 270233
nosy: rhendrikse
priority: normal
severity: normal
status: open
title: logging module fails with unclear error when supplied a (Posix)Path
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue27493>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27493] logging module fails with unclear error when supplied a (Posix)Path
Richard added the comment: Yeah, figured as much. But thanks:) I'm kind of new to Python and was having some problems determining whether this is as it should be, or if it should be improved. After all, I could not find any documentation that states what the permitted variable-types are (for pretty much any function, actually), yet print() does cast the Path()s to a string... Kind of used to the documentation format on php.net :P -- ___ Python tracker <http://bugs.python.org/issue27493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27882] Python docs on 3.52 Math module lists math.log2 as function but it does not exist
Changes by Richard : -- assignee: docs@python components: Documentation nosy: PyRW, docs@python priority: normal severity: normal status: open title: Python docs on 3.52 Math module lists math.log2 as function but it does not exist versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue27882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27882] Python docs on 9.52 Math module lists math.log2 as function but it does not exist
Changes by Richard : -- title: Python docs on 3.52 Math module lists math.log2 as function but it does not exist -> Python docs on 9.52 Math module lists math.log2 as function but it does not exist ___ Python tracker <https://bugs.python.org/issue27882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27882] Python docs on 9.2 Math module lists math.log2 as function but it does not exist
Changes by Richard : -- title: Python docs on 9.52 Math module lists math.log2 as function but it does not exist -> Python docs on 9.2 Math module lists math.log2 as function but it does not exist ___ Python tracker <https://bugs.python.org/issue27882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27882] Python docs on 9.2 Math module lists math.log2 as function but it does not exist
Changes by Richard : Added file: https://bugs.python.org/file44244/docbugmathlog2.jpg ___ Python tracker <https://bugs.python.org/issue27882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1101] Is there just no PRINT statement any more? Or it just doesn't work.
New submission from Richard Katz: Is there supposed to be a way to do for x in 1,2,3: print x, If so, it's appears to be not working. Is it just not in this release? If not, I would think that leaving out the print statement (just because there is a print function) would represent a major problem for cross-platform books and training materials. Just a thought. How would one achieve this capability in Python 3.0? Was it the intention to remove this capability? Thank you. Regards, Rich -- components: Interpreter Core messages: 55643 nosy: richkatz severity: major status: open title: Is there just no PRINT statement any more? Or it just doesn't work. type: behavior versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1101> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1101] Is there just no PRINT statement any more? Or it just doesn't work.
Richard Katz added the comment: "What's wrong with py> for x in 1,2,3:print(x,end=" ")" - I'd like to suggest (for those of us just now focusing on Python 3.0) replacing the last 3 bullet points of the paragraph "Common Stumbling Blocks?" http://docs.python.org/dev/3.0/whatsnew/3.0.html With the following simple reference: "The print statement has been REMOVED and is replaced by a print() function. SEE PEP 3105." Rather than burying 3105 in the middle of "other language changes." That would do a lot to clear it up. A) Especially I'd like to suggest getting rid of the quite cryptic: "You’ll be finding yourself typing print x a lot in interactive mode." I had no idea that was a *warning message - meaning "it won't work..." And B) The rather misleading - "Also, print and print (x, y) behave differently without warning:" They certainly do... But not in the way explained. "print" now displays "" since it's a function...What they probably meant was print()? Where would I suggest (or make) these changes to What's New? Is there a Doc Wiki? Thanks! Regards, Rich -Original Message- >From: "=?utf-8?q?Martin_v._L=C3=B6wis?=" <[EMAIL PROTECTED]> >Sent: Sep 4, 2007 5:31 PM >To: [EMAIL PROTECTED] >Subject: [issue1101] Is there just no PRINT statement any more? Or it just >doesn't work. > > >Martin v. Löwis added the comment: > >What's wrong with > >py> for x in 1,2,3:print(x,end=" ") >... >1 2 3 > >Closing as invalid. > >-- >nosy: +loewis >resolution: -> invalid >status: open -> closed > >__ >Tracker <[EMAIL PROTECTED]> ><http://bugs.python.org/issue1101> >__ __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1101> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13279] Add memcmp into unicode_compare for optimizing compares
New submission from Richard Saunders : In discussions of memcmp performance, (http://www.picklingtools.com/study.pdf) it was noted how well Python 2.7 can take advantage of faster memcmps (indeed, the rich comparisons are all memcmp calls). There have been some discussion on python-...@python.org as well. With unicode and Python 3.3 (and anyPython 3.x) there are a few places we could call memcmp to make string comparisons faster, but they are not completely trivial. Basically, if the unicode strings are "1 byte kind", then memcmp can be used almost as is. If the unicode strings are the same kind, they can at least use memcmp to compare for equality or inequality. There is also a minor optimization laying in unicode_compare: if you are comparing two strings for equality/inequality, there is no reason to look at the entire string if the lengths are different. These 3 minor optimizations can make unicode_compare faster. -- components: Interpreter Core messages: 146508 nosy: RichIsMyName, asmodai, loewis, pitrou, scoder priority: normal severity: normal status: open title: Add memcmp into unicode_compare for optimizing compares type: performance versions: Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13279] Add memcmp into unicode_compare for optimizing comparisons
Richard Saunders added the comment: This is a potential patch: I believe it follows the C-style of PEP 7 There is a test as well, testing 1 and 2 byte kinds. I have run it through the python tests and have added no new breakages (there were some tests that failed, but they failed with and without the patch) -- keywords: +patch title: Add memcmp into unicode_compare for optimizing compares -> Add memcmp into unicode_compare for optimizing comparisons Added file: http://bugs.python.org/file23537/unicode_with_memcmp.patch ___ Python tracker <http://bugs.python.org/issue13279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13279] Add memcmp into unicode_compare for optimizing comparisons
Richard Saunders added the comment:
Here's a test demonstrating the memcmp optimization effect:
---
more ~/PickTest5/Python/string_test3.py
a = []
b = []
c = []
d = []
for x in range(0,1000) :
a.append("the quick brown fox"+str(x))
b.append("the wuick brown fox"+str(x))
c.append("the quick brown fox"+str(x))
d.append("the wuick brown fox"+str(x))
count = 0
for x in range(0,20) :
if a==c : count += 1
if a==c : count += 2
if a==d : count += 3
if b==c : count += 5
if b==d : count += 7
if c==d : count += 11
print(count)
-
# plain Python 3.3 no memcmp, no UCS specialization
% time ./python ~/PickTest5/Python/string_test3.py
200
28.918u 0.014s 0:29.02 99.6%0+0k 0+0io 0pf+0w
% setenv CFLAGS -fno-builtin-memcmp # (reconfigure and remake)
% time ./python ~/PickTest5/Python/string_test3.py
200
29.783u 0.017s 0:29.88 99.6%0+0k 0+0io 0pf+0w
-
# Python 3.3 with memcmp optimizations and UCS2/4 specialization (no CFLAGS)
% time ./python ~/PickTest5/Python/string_test3.py
200
37.126u 0.046s 0:37.35 99.4%0+0k 0+0io 0pf+0w
% setenv CFLAGS -fno-builtin-memcmp # (reconfigure and remake)
% time ./python ~/PickTest5/Python/string_test3.py
200
18.621u 0.013s 0:18.69 99.6%0+0k 0+0io 0pf+0w
-
Note we only really see the effect if we make sure that gcc
isn't emitting its "special" memcmp: that's why the -fno-builtin-memcmp
is SO important on gcc builds!
See http://www.picklingtools.com/study.pdf
I am currently working with Bob Arendt (a colleague who works
frequently with Fedora) to try to put the
-fno-builtin-memcmp in the .spec file for their Python
--
___
Python tracker
<http://bugs.python.org/issue13279>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13279] Add memcmp into unicode_compare for optimizing comparisons
Richard Saunders added the comment: Added branches for specializing for UCS2 and UCS4 types -- Added file: http://bugs.python.org/file23574/unicode_with_memcmp_and_ucs_specialization.patch ___ Python tracker <http://bugs.python.org/issue13279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13279] Add memcmp into unicode_compare for optimizing comparisons
Richard Saunders added the comment: Some more information: Bob Arendt and I have been playing with the Fedora Core .spec file for python on Fedora Core 15: the compile options we found seem to automatically (as we did non invoke this option) invoke '-fno-builtin-memcmp' somehow? We disassembled the Python binary we built for the machine ourselves (via the spec file) code and saw, yes, it was calling memcmp on the system, even though we didn't bypass it explicitly. Our conjecture is that the -m32 or -mtune=atom automatically turns the builtin memcmp off, but we're not sure (we're still playing with it). However, perhaps Fedora builds on a more generic machine: that generic build keeps the 'rep cmbsb'? Frustrating. -- ___ Python tracker <http://bugs.python.org/issue13279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9619] test_ssl freezes
Richard Jones added the comment: Thanks for the investigation Antoine. In r84088 I've added a call to asyncore.close_all in the smtpd test tearDown methods. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue9619> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10378] Typo in results of help(divmod)
New submission from Richard Fuhr : When running Python 2.7 if you invoke help(divmod) the first line of the resulting help displays Help on built-in function divmod in module __builtin__: but I believe that the name of the module is __builtins__ so the line should say Help on built-in function divmod in module __builtinsq__: -- assignee: d...@python components: Documentation messages: 120900 nosy: d...@python, rdfuhr priority: normal severity: normal status: open title: Typo in results of help(divmod) type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue10378> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10378] Typo in results of help(divmod)
Richard Fuhr added the comment: I had a typo in my own bug report that was reporting a typo; what I intended to say was the following ( the q should not have been there at the end ) When running Python 2.7 if you invoke help(divmod) the first line of the resulting help displays Help on built-in function divmod in module __builtin__: but I believe that the name of the module is __builtins__ so the line should say Help on built-in function divmod in module __builtins__: -- ___ Python tracker <http://bugs.python.org/issue10378> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10378] Typo in results of help(divmod)
Richard Fuhr added the comment: OK, thanks for the clarification. I am new to Python. Sent from my iPod On Nov 9, 2010, at 3:54 PM, Andreas Stührk wrote: > > Andreas Stührk added the comment: > > __builtin__ is the correct name for the module (see > http://docs.python.org/library/__builtin__.html, especially the note at the > end which is the cause of the confusion), hence this is not a bug. > > -- > nosy: +Trundle > > ___ > Python tracker > <http://bugs.python.org/issue10378> > ___ -- ___ Python tracker <http://bugs.python.org/issue10378> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11362] image/webp missing from mimetypes.py
New submission from Richard Rabbat : image/webp is missing from the mimetypes.py list of valid mimetypes. webp is an open-source image format and uses vp8 as a codec. -- components: Library (Lib) messages: 129786 nosy: Richard.Rabbat priority: normal severity: normal status: open title: image/webp missing from mimetypes.py type: feature request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue11362> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8841] GetoptError strings should be localized
Richard Lowe added the comment: I don't find anything lacking about the error messages, I meant that there were no more specific exceptions, or fields in GetoptError to allow the caller to tell what was specifically wrong and provide its own localized messages. So while the defaults are unlocalized, all an application can do is interpret the error string to provide a localized message. The solution I was thinking of is getopt raising sub-types of GetoptError for each specific error case (unknown option, option requires argument, etc), and the message text of each of those being localized through gettext(). I'm not sure what problems that could cause with compatibility however, beyond obviously anyone who's already resorted to interpreting the string would have problems. -- ___ Python tracker <http://bugs.python.org/issue8841> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8841] GetoptError strings should be localized
Richard Lowe added the comment: Sure, just localizing them in the getopt implementation would be fine. I suggested subclassing to solve the more general problem of the caller being able to tell one getopt error from another, for which it is a pretty common solution. -- ___ Python tracker <http://bugs.python.org/issue8841> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10919] Environment variables are not expanded in _winreg when using REG_EXPAND_SZ.
New submission from Richard Nienaber : According to Microsoft documentation (http://msdn.microsoft.com/en-us/library/ms724884(v=vs.85).aspx) when using the REG_EXPAND_SZ value type, environment variables (e.g. %programfiles%) should be expanded to their values (e.g. 'C:\Program Files'). I've added a test case that reproduces this error. -- components: Library (Lib) files: testcase-24042.py messages: 126368 nosy: rjnienaber priority: normal severity: normal status: open title: Environment variables are not expanded in _winreg when using REG_EXPAND_SZ. versions: Python 2.7 Added file: http://bugs.python.org/file20418/testcase-24042.py ___ Python tracker <http://bugs.python.org/issue10919> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10919] Environment variables are not expanded in _winreg when using REG_EXPAND_SZ.
Richard Nienaber added the comment: Further documentation on the RegEnumValue function (used by the _winreg module): http://msdn.microsoft.com/en-us/library/ms724865(v=vs.85).aspx. The documentation doesn't say whether the string is expanded or not on retrieval. Given the current behaviour plus the ExpandEnvironmentStrings function, this seems like a non-issue. -- ___ Python tracker <http://bugs.python.org/issue10919> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2571] cmd.py always uses raw_input, even when another stdin is specified
Richard King <[EMAIL PROTECTED]> added the comment: There were some other things I wanted too so I just made my own cmd.py. -Rick Raghuram Devarakonda wrote: > Raghuram Devarakonda <[EMAIL PROTECTED]> added the comment: > > Richard, I see the following very clearly mentioned in the doc: > > "If you want a given stdin to be used, make sure to set the instance’s > use_rawinput attribute to False, otherwise stdin will be ignored." > > Even though this seems like unnecessary, at least it is documented. If > you want to push for automatically setting use_rawinput when 'stdin' is > not None, you will need to submit a patch and convince some core > developer to agree with you. > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2571> > ___ > > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 270.4.0/1506 - Release Date: 6/17/2008 > 4:30 PM > ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3441] Regression in "module as a script" command-line option
New submission from Richard Jones <[EMAIL PROTECTED]>: The Python 2.5 "-m" command-line option allowed execution of a package directly, by invoking the __init__.py module. Python 2.6 no longer allows this. This is a quite unfortunate regression, and I would urge the decision to hobble it to be reconsidered. -- messages: 70240 nosy: richard severity: normal status: open title: Regression in "module as a script" command-line option versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3441> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3441] Regression in "module as a script" command-line option
Changes by Richard Jones <[EMAIL PROTECTED]>: -- type: -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3441> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3441] Regression in "module as a script" command-line option
Richard Jones <[EMAIL PROTECTED]> added the comment: I'm afraid it's all a bit opaque to an outsider like me. I've no idea what subtle breakage the feature was causing. I just saw it working quite nicely for me in 2.5 :) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3441> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3208] function annotation for builtin and C function
Richard Boulton <[EMAIL PROTECTED]> added the comment: I don't think it's reasonable not to support multiple interpreters in a single process - they're quite widely used by mod_python and mod_wsgi, and probably by others. I'm not sure whether that's a problem here or not, though. If we need to allow function annotations to be arbitrary PyObjects, these PyObject pointers can't (in general) refer to statically allocated python objects, so some extension modules will have to allocate them in the module initialisation function (and presumably deallocate them again when the module is unloaded). I would have thought that any such PyObjects are going to be valid only from within a single interpreter. Perhaps I'm wrong. Certainly it would be unpleasant if a change to one of the objects in one interpreter was reflected in other interpreters, but if that didn't risk causing a crash due to the memory allocation going wrong, or something equally nasty, it might be acceptable. -- nosy: +richardb ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7615] unicode_escape codec does not escape quotes
Richard Hansen added the comment: Any comments on the patches? I'd love to see at least patches 1-3 make it into Python 2.7. :) -- ___ Python tracker <http://bugs.python.org/issue7615> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1702] Word "alias" used in confusing way to compare open() and file()
Changes by Richard Cohen: -- nosy: +vmlinuz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1702> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1389051] imaplib causes excessive fragmentation for large documents
Richard Cooper added the comment: I think I was just bitten by the non-SSL version of this bug on Python 2.5.1 (r251:54863) on Mac OS 10.5. It manifested itself as a "malloc error: can't allocate region" while downloading a message using imaplib. As suggested by effbot I changed "data = self._sock.recv(recv_size)" to "data = self._sock.recv(min(recv_size, 16384))" in both places that line appears in socket.py. Making that change fixed the problem for me. Note that http://bugs.python.org/issue1092502 seems to be a duplicate of this issue. That issue contains a slightly different fix proposed by a_lauer, which I've not tried. -- nosy: +rich _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1389051> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2038] win32pdh.EnumObjects fails on Windows Server 2003 R2
New submission from Richard Mason: The following test script works OK on all windows platforms apart from Windows Server 2003 R2: import win32pdh win32pdh.EnumObjects(None, None, 0, 1) When I run on Windows Server 2003 R2 get the following dump: E:\fusiondx\lib>test.py Traceback (most recent call last): File "E:\fusiondx\lib\test.py", line 2, in win32pdh.EnumObjects(None, None, 0, 1) pywintypes.error: (-2147481648, 'EnumObjects for buffer size', 'No error message is available') -- components: Extension Modules messages: 62152 nosy: rmason severity: critical status: open title: win32pdh.EnumObjects fails on Windows Server 2003 R2 type: crash versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2038> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2571] cmd.py always uses raw_input, even when another stdin is specified
New submission from Richard King <[EMAIL PROTECTED]>: The module global value use_rawinput is initialized to 1 but not reset when stdin is replaced with a passed-in value. -- components: Extension Modules messages: 65094 nosy: rickbking severity: normal status: open title: cmd.py always uses raw_input, even when another stdin is specified type: behavior versions: Python 2.4 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2571> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2577] cmd.py should track input file objects so macros with submacros can be easily written
New submission from Richard King <[EMAIL PROTECTED]>: Add an "input" method or property that saves the current input file object and resets the input file object; when input results in an "EOF", the input file object stack is popped and reading continues from there. A modified cmd.py is attached. -- components: Extension Modules files: cmd.py messages: 65128 nosy: rickbking severity: normal status: open title: cmd.py should track input file objects so macros with submacros can be easily written type: feature request versions: Python 2.4 Added file: http://bugs.python.org/file9974/cmd.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2577> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2571] cmd.py always uses raw_input, even when another stdin is specified
Richard King <[EMAIL PROTECTED]> added the comment:
(this is really 2 mails because my home email address was not registered so
they were rejected at first)
Right - I wasn't too clear. The module stashes stdin, whether from sys
or passed in, in self.stdin. When it reads input it uses a flag
"raw_input" to determine whether to use raw_input or
self.stdin.readline(), but the flag is not reset when a different stdin
is passed in, so raw_input is always true.
The flag should be True/False, and I didn't think of setting it directly
to be honest because it never occurred to me that I should have to do that to
get a cmd class that i just instantiated with a different input object to use
the one it was created with. I think the flag should be eliminated and replaced
with the test self.stdin == sys.stdin anyway.
I also entered a feature request to add a stack of stdin's which are
stacked when you want to process lines in a file, and then pop off the
stack automatically at end of file. This would make it easy to write a
command-line tool, like i'm doing, so that any input object could enter
commands that change to other input objects and then restore the previous input
objectthis would allow for nesting of command files. There would be special
conditions for
sys.stdin (sys.stdin can only be used if there are no items on the
stack). This could all be done outside the module, but it's so easy when
it's integrated right in there.
I think I understand better what you are getting at, but it makes more
sense to me to be explicit in the code and not take advantage of the
fact the raw_input always works off sys.stdin. Also, I see now that
maybe the idea was to have raw_input be changeable so that you could
switch back and forth between "stdin" (whatever that is), and some other
input object - I'm having a hard time seeing the usefulness of that,
though. Anyway, instantiating a cmd class with a non-stdin input object
and then having to set raw_input to False to get it to use that input
object seems wrong.
does this make sense?
-Rick King
Daniel Diniz wrote:
> Daniel Diniz <[EMAIL PROTECTED]> added the comment:
>
> I don't think it should stop using raw_input just because you changed
> stdin, as you can change it to something that will work with raw_input.
> Consider:
>
>>>> import sys
>>>> sys.stdin = open("/dev/tty")
>>>> raw_input()
>>>>
> a
> 'a'
>
> You can tie it to any object (e.g. a GUI input) that supports the file
> protocol and keep using raw_input. Or change Cmd.use_rawinput to 0 to
> use stdin.readline directly.
>
> On a related issue. Cmd.use_rawinput should be "True", not 1...
>
> --
> nosy: +ajaksu2
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue2571>
> __
>
>
>
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2571>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2647] XML munges apos entity in tag content
New submission from Richard Esplin <[EMAIL PROTECTED]>:
I would like it to leave my ' alone, just like it does with my <
and >
Python 2.5.1 (r251:54863, Sep 21 2007, 22:46:31)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.dom import minidom
>>> doc = minidom.parseString("<a'b>")
>>> doc.toxml()
u'<a\'b>'
>>>
--
components: XML
messages: 65570
nosy: resplin
severity: normal
status: open
title: XML munges apos entity in tag content
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2647>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4184] Remove use of private attributes in smtpd
New submission from Richard Jones <[EMAIL PROTECTED]>: Executive summary of the patch: The attached patch removes the use of __private attributes in the smtpd module allowing it to be extensible without needing to use the "___" hack. Summary of the patch's changes: 1. removes the unused __conn and __addr attributes 2. renames __server to smtp_server 3. renames __lines to received_lines 4. renames __state to smtp_state 5. renames __greeting to seen_greeting, and alters the default to empty string to match the anticipated data 6. renames __mailfrom to mailfrom 7. renames __date to received_data 8. renames __fqdn to fqdn 9. removes __peer and uses base class' addr attribute The existing unit tests contained within test_smtplib pass. Additional tests could be written if it's deemed necessary. There is a chance this patch will break backward compatibility with programs that use the private-variable-access hack. A more complex patch could be written providing greater compatibility if it's deemed necessary. -- components: Library (Lib) files: smtpd.py-patch messages: 75132 nosy: richard severity: normal status: open title: Remove use of private attributes in smtpd versions: Python 2.6 Added file: http://bugs.python.org/file11867/smtpd.py-patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4184> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767933] Badly formed XML using etree and utf-16
Richard urwin <[EMAIL PROTECTED]> added the comment: This is a bug in two halves. 1. Not all characters in the file are UTF-16. The initial xml header isn't, and the individual < > etc characters are not. This is just a matter of extending the methodology to encode all characters and not just the textual bits. There is no work-around except a five-minute hack of the ElementTree.write() method. 2. Every write has a BOM, so corrupting the file in a manner analogous to bug 555360. This is a result of using string.encode() and is a well-known feature. It can be worked around by using UTF-16LE or UTF-16BE which do not prepend a BOM, but then the file doesn't have any BOM. A complete solution would be to rewrite ElementTree.write() to use a different encoding methodology such as StreamWriter. I have made the above hack and work-around for my own use, and I can report that it produces perfect UTF-16. -- nosy: +rurwin versions: +Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1767933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767933] Badly formed XML using etree and utf-16
Richard urwin <[EMAIL PROTECTED]> added the comment: Here is a patch of my quick hack, more for interest than any suggestion it gets used. Although it does produce good output so long as you avoid the BOM. The full solution is beyond my (very weak) Python skills. The character encoding is tied in with XML character substitution (& etc. and hexadecimal representation of multibyte characters). I could disentangle it, but I probably wouldn't produce optimal Python, or indeed anything that wouldn't inspire mirth and/or incredulity. NB. The workaround suggested by Fredrik Lundh doesn't solve our particular problems, since the downsize to UTF-8 causes the multi-byte characters to be represented in hex. Our software doesn't read those. (I know that's our problem.) Added file: http://bugs.python.org/file12009/patch.txt ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1767933> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4928] Problem with tempfile.NamedTemporaryFile on Solaris 10
New submission from Richard Philips : On Solaris 10 (Solaris 10 5/08 s10x_u5wos_10 X86), with python 2.5 (Python 2.5.2 (r252:60911, Sep 8 2008, 16:53:36) [C] on sunos5), tempfile.NamedTemporaryFile creates - as advertised - a temporary file. After closing this file object (e.g. by exiting the python process), the temporary file is indeed removed. But if you just kill the python process, the temporary file is not destroyed. This behavior is different on Red Hat Linux and MS Vista, on these OSes the temporary file is removed. A snapshot to illustrate the behavior: [moto /]# python Python 2.5.2 (r252:60911, Sep 8 2008, 16:53:36) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os, tempfile >>> f = tempfile.NamedTemporaryFile() >>> f.name '/tmp/tmpfHraUd' >>> os.getpid() 4403 >>> x = "With root priveleges, I execute: 'kill 4403'" >>> >>> Terminated [moto /]# -- components: Library (Lib) messages: 79727 nosy: rphilips severity: normal status: open title: Problem with tempfile.NamedTemporaryFile on Solaris 10 type: behavior versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue4928> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4928] Problem with tempfile.NamedTemporaryFile on Solaris 10
Richard Philips added the comment: [Replaces msg 79727] On Solaris 10 (Solaris 10 5/08 s10x_u5wos_10 X86), with python 2.5 (Python 2.5.2 (r252:60911, Sep 8 2008, 16:53:36) [C] on sunos5), tempfile.NamedTemporaryFile creates - as advertised - a temporary file. After closing this file object (e.g. by exiting the python process), the temporary file is indeed removed. But if you just kill the python process, the temporary file is not destroyed. This behavior is different on Red Hat Linux and MS Vista, on these OSes the temporary file is removed. A snapshot to illustrate the behavior: [moto /]# python Python 2.5.2 (r252:60911, Sep 8 2008, 16:53:36) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os, tempfile >>> f = tempfile.NamedTemporaryFile() >>> f.name '/tmp/tmpfHraUd' >>> os.getpid() 4403 >>> x = "With root priveleges, I execute: 'kill 4403'" >>> >>> Terminated [moto /]# ls /tmp/tmpfHraUd /tmp/tmpfHraUd [moto /]# ___ Python tracker <http://bugs.python.org/issue4928> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47139] pthread_sigmask needs SIG_BLOCK behaviour explaination
New submission from Richard Purdie : I've been struggling to get signal.pthread_sigmask to do what I expected it to do from the documentation. Having looked at the core python code handling signals I now (think?!) I understand what is happening. It might be possible for python to improve the behaviour, or it might just be something to document, I'm not sure but I though I'd mention it. I'd added pthread_sigmask(SIG_BLOCK, (SIGTERM,)) and pthread_sigmask(SIG_UNBLOCK, (SIGTERM,)) calls around a critical section I wanted to protect from the SIGTERM signal. I was still seeing SIGTERM inside that section. Using SIGMASK to restore the mask instead of SIG_UNBLOCK behaves the same. What I hadn't realised is that firstly python defers signals to a convenient point and secondly that signals are processed in the main thread regardless of the thread they arrived in. This means that I can see SIGTERM arrive in my critical section as one of my other threads created in the background by the core python libs helpfully handles it. This makes SIG_BLOCK rather ineffective in any threaded code. To work around it, I can add my own handlers and have them track whether a signal arrived, then handle any signals after my critical section by re-raising them. It is possible python itself could defer processing signals masked with SIG_BLOCK until they're unblocked. Alternatively, a note in the documentation warning of the pitfalls here might be helpful to save someone else from wondering what is going on! -- components: Interpreter Core messages: 416154 nosy: rpurdie priority: normal severity: normal status: open title: pthread_sigmask needs SIG_BLOCK behaviour explaination versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue47139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47195] importlib lock race issue in deadlock handling code
New submission from Richard Purdie : We've seen tracebacks in production like: File "", line 1004, in _find_and_load(name='oe.gpg_sign', import_=) File "", line 158, in _ModuleLockManager.__enter__() File "", line 110, in _ModuleLock.acquire() KeyError: 139622474778432 and File "", line 1004, in _find_and_load(name='oe.path', import_=) File "", line 158, in _ModuleLockManager.__enter__() File "", line 110, in _ModuleLock.acquire() KeyError: 140438942700992 I've attached a reproduction script which shows that if an import XXX is in progress and waiting at the wrong point when an interrupt arrives (in this case a signal) and triggers it's own import YYY, _blocking_on[tid] in importlib/_bootstrap.py gets overwritten and lost, triggering the traceback we see above upon exit from the second import. I'm using a signal handler here as the interrupt, I don't know what our production source is as yet but this reproducer proves it is possible. -- components: Interpreter Core files: testit2.py messages: 416517 nosy: rpurdie priority: normal severity: normal status: open title: importlib lock race issue in deadlock handling code versions: Python 3.10 Added file: https://bugs.python.org/file50714/testit2.py ___ Python tracker <https://bugs.python.org/issue47195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47195] importlib lock race issue in deadlock handling code
Richard Purdie added the comment:
This is a production backtrace after I inserted code to traceback if tid was
already in _blocking_on. It is being triggered by a warning about an unclosed
asyncio event loop and confirms my theory about nested imports, in the
production case I'd guess being triggered by gc given the __del__.
File
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/classes/base.bbclass",
line 26, in oe_import
import oe.data
File "", line 1024, in _find_and_load
File "", line 171, in __enter__
File
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/cooker.py",
line 168, in acquire
return orig_acquire(self)
File "", line 110, in acquire
File "/usr/lib64/python3.10/asyncio/base_events.py", line 685, in __del__
_warn(f"unclosed event loop {self!r}", ResourceWarning, source=self)
File "/usr/lib64/python3.10/warnings.py", line 112, in _showwarnmsg
_showwarnmsg_impl(msg)
File "/usr/lib64/python3.10/warnings.py", line 28, in _showwarnmsg_impl
text = _formatwarnmsg(msg)
File "/usr/lib64/python3.10/warnings.py", line 128, in _formatwarnmsg
return _formatwarnmsg_impl(msg)
File "/usr/lib64/python3.10/warnings.py", line 56, in _formatwarnmsg_impl
import tracemalloc
File "", line 1024, in _find_and_load
File "", line 171, in __enter__
File
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/cooker.py",
line 167, in acquire
bb.warn("\n".join(traceback.format_stack()))
--
___
Python tracker
<https://bugs.python.org/issue47195>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47139] pthread_sigmask needs SIG_BLOCK behaviour explaination
Richard Purdie added the comment: I think the python code implementing pthread_sigmask already does trigger interrupts if any have been queued before the function returns from blocking or unblocking. The key subtlety which I initially missed is that if you have another thread in your python script, any interrupt it receives can be raised in the main thread whilst you're in the SIGBLOCK section. This obviously isn't what you expect at all as those interrupts are supposed to be blocked! It isn't really practical to try and SIGBLOCK on all your individual threads. What I'd wondered is what you mention, specifically checking if a signal is masked in the python signal raising code with something like the "pthread_sigmask(SIG_UNBLOCK, NULL /* set */, &oldset)" before it raises it and if there is blocked, just leave it queued. The current code would trigger the interrupts when it was unmasked. This would effectively only apply on the main thread where all the signals/interrupts are raised. This would certainly give the behaviour that would be expected from the calls and save everyone implementing the workarounds as I have. Due to the threads issue, I'm not sure SIGBLOCK is actually useful in the real world with the current implementation unfortunately. Equally, if that isn't an acceptable fix, documenting it would definitely be good too. -- ___ Python tracker <https://bugs.python.org/issue47139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47258] Python 3.10 hang at exit in drop_gil() (due to resource warning at exit?)
New submission from Richard Purdie : We had a python hang at shutdown. The gdb python backtrace and C backtraces are below. It is hung in the COND_WAIT(gil->switch_cond, gil->switch_mutex) call in drop_gil(). Py_FinalizeEx -> handle_system_exit() -> PyGC_Collect -> handle_weakrefs -> drop_gil I think from the stack trace it may have been printing the warning: sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1560250/bitbake-cookerdaemon.log' mode='a+' encoding='UTF-8'> however I'm not sure if it was that or trying to show a different exception. Even if we have a resource leak, it shouldn't really hang! (gdb) py-bt Traceback (most recent call first): File "/usr/lib64/python3.10/weakref.py", line 106, in remove def remove(wr, selfref=ref(self), _atomic_removal=_remove_dead_weakref): Garbage-collecting #0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7f0f7bd54b20 <_PyRuntime+512>) at futex-internal.c:57 #1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f0f7bd54b20 <_PyRuntime+512>, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87 #2 0x7f0f7b88979f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7f0f7bd54b20 <_PyRuntime+512>, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139 #3 0x7f0f7b88beb0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f0f7bd54b28 <_PyRuntime+520>, cond=0x7f0f7bd54af8 <_PyRuntime+472>) at pthread_cond_wait.c:504 #4 ___pthread_cond_wait (cond=cond@entry=0x7f0f7bd54af8 <_PyRuntime+472>, mutex=mutex@entry=0x7f0f7bd54b28 <_PyRuntime+520>) at pthread_cond_wait.c:619 #5 0x7f0f7bb388d8 in drop_gil (ceval=0x7f0f7bd54a78 <_PyRuntime+344>, ceval2=, tstate=0x558744ef7c10) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/ceval_gil.h:182 #6 0x7f0f7bb223e8 in eval_frame_handle_pending (tstate=) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/ceval.c:1185 #7 _PyEval_EvalFrameDefault (tstate=, f=, throwflag=) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/ceval.c:1775 #8 0x7f0f7bb19600 in _PyEval_EvalFrame (throwflag=0, f=Frame 0x7f0f7a0c8a60, for file /usr/lib64/python3.10/weakref.py, line 106, in remove (wr=, selfref=, _atomic_removal=), tstate=0x558744ef7c10) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Include/internal/pycore_ceval.h:46 #9 _PyEval_Vector (tstate=, con=, locals=, args=, argcount=1, kwnames=) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/ceval.c:5065 #10 0x7f0f7bb989a8 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=9223372036854775809, args=0x7fff8b815bc8, callable=, tstate=0x558744ef7c10) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Include/cpython/abstract.h:114 #11 PyObject_CallOneArg (func=, arg=) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Include/cpython/abstract.h:184 #12 0x7f0f7bb0fce1 in handle_weakrefs (old=0x558744edbd30, unreachable=0x7fff8b815c70) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Modules/gcmodule.c:887 #13 gc_collect_main (tstate=0x558744ef7c10, generation=2, n_collected=0x7fff8b815d50, n_uncollectable=0x7fff8b815d48, nofail=0) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Modules/gcmodule.c:1281 #14 0x7f0f7bb9194e in gc_collect_with_callback (tstate=tstate@entry=0x558744ef7c10, generation=generation@entry=2) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Modules/gcmodule.c:1413 #15 0x7f0f7bbc827e in PyGC_Collect () at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Modules/gcmodule.c:2099 #16 0x7f0f7bbc7bc2 in Py_FinalizeEx () at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/pylifecycle.c:1781 #17 0x7f0f7bbc7d7c in Py_Exit (sts=0) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/pylifecycle.c:2858 #18 0x7f0f7bbc4fbb in handle_system_exit () at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/pythonrun.c:775 #19 0x7f0f7bbc4f3d in _PyErr_PrintEx (set_sys_last_vars=1, tstate=0x558744ef7c10) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/pythonrun.c:785 #20 PyErr_PrintEx (set_sys_last_vars=1) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/pythonrun.c:880 #21 0x7f0f7bbbcece in PyErr_Print () at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/pythonrun.c:886 #22 _PyRun_SimpleFileObject (fp=, filename=, closeit=1, flags=0x7fff8b815f18) at /usr/src/debug/python3.10-3.10.4-1.fc35.x86_64/Python/pythonrun.c:462 #23 0x7f0f7bbbcc57 in _PyRun_AnyFileObject (fp=0x558744ed9370, filename='/home/pokybuild/y
[issue37843] CGIHTTPRequestHandler does not take args.directory in constructor
New submission from Richard Jayne : In Lib/http/server.py if args.cgi: handler_class = CGIHTTPRequestHandler else: handler_class = partial(SimpleHTTPRequestHandler, directory=args.directory) Notice that CGIHTTPRequestHandler does not accept directory=args.directory, and so the option does not work with the --cgi option. -- components: Extension Modules messages: 349585 nosy: rjayne priority: normal severity: normal status: open title: CGIHTTPRequestHandler does not take args.directory in constructor type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue37843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38612] some non-ascii charcters link to same identifier/data
New submission from Richard Pausch : The issue was first reported in https://github.com/ipython/ipython/issues/11918. Some non-ascii characters like φ (\u03c6) and ϕ (\u03d5) map/link to the same data/identifier. ```python ϕ = 1 φ = 2 print(ϕ) # results in 2 - should be 1 print(φ) # results in 2 ``` It has so far been shown to occur both in python 3.6 and 3.7. -- messages: 355525 nosy: PrometheusPi priority: normal severity: normal status: open title: some non-ascii charcters link to same identifier/data type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue38612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38612] some non-ascii charcters link to same identifier/data
Change by Richard Pausch : -- components: +Unicode nosy: +ezio.melotti, vstinner ___ Python tracker <https://bugs.python.org/issue38612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43946] unpickling a subclass of list fails when it implements its own extend method
Richard Levasseur added the comment:
Here's a self-contained repro:
```
import pickle
class MyList(list):
def __init__(self, required, values):
self.required = required
super().__init__(values)
def __getstate__(self):
return self.required
def __setstate__(self, state):
self.required = state
def extend(self, values):
assert self.required
super().extend(values)
mylist = MyList('foo', [1, 2])
pickled = pickle.dumps(mylist)
unpickled = pickle.loads(pickled)
print(mylist)
```
The above will raise an AttributeError when self.required is accessed in
extend().
Oddly, defining a `__reduce__()` function that simply calls and returns
`super().__reduce__()` seems to restore the previous behavior and things work
again.
--
nosy: +richardlev
___
Python tracker
<https://bugs.python.org/issue43946>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44387] Not obvious that locale.LC_MESSAGES may not exist sometimes (e.g. on Windows)
New submission from Richard Mines : Documentation page: https://docs.python.org/3/library/locale.html#locale.LC_MESSAGES Code comment saying that locale.LC_MESSAGES doesn't exist sometimes: https://github.com/python/cpython/blob/62f1d2b3d7dda99598d053e10b785c463fdcf591/Lib/locale.py#L25-L26 Code fragment showing that locale.LC_MESSAGES can be non-existent: https://github.com/python/cpython/blob/62f1d2b3d7dda99598d053e10b785c463fdcf591/Lib/locale.py#L1747-L1752 Reading documentation it's not obvious that locale.LC_MESSAGES may not exist (e.g. Windows - Microsoft Store - Python 3.8) -- assignee: docs@python components: Documentation messages: 395588 nosy: docs@python, richardmines91 priority: normal severity: normal status: open title: Not obvious that locale.LC_MESSAGES may not exist sometimes (e.g. on Windows) type: enhancement 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/issue44387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44387] Not obvious that locale.LC_MESSAGES may not exist sometimes (e.g. on Windows)
Richard Mines added the comment: If you need a proof that it is possible that locale.LC_MESSAGES doesn't exist, I've attached a screenshot. Even more I'm showing that locale.LC_TIME may be equal to 5 which is a placeholder for locale.LC_MESSAGES if there is an ImportError: https://github.com/python/cpython/blob/62f1d2b3d7dda99598d053e10b785c463fdcf591/Lib/locale.py#L57 OS: Windows 10 20H2 Python: 3.8.10 Exact link to get python: https://www.microsoft.com/ru-ru/p/python-38/9mssztt1n39l?activetab=pivot:overviewtab -- Added file: https://bugs.python.org/file50102/lc_messages_not_exist.png ___ Python tracker <https://bugs.python.org/issue44387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44401] const kwlist for PyArg_ParseTupleAndKeywords and PyArg_VaParseTupleAndKeywords
New submission from Richard Barnes : PyArg_ParseTupleAndKeywords and PyArg_VaParseTupleAndKeywords currently accept `kwlist` as `char **`; however, is not modified by either function. Therefore, a `const char **` might be better since this allows calling code to take advantage of `const` safety. -- components: C API messages: 395674 nosy: r-barnes priority: normal severity: normal status: open title: const kwlist for PyArg_ParseTupleAndKeywords and PyArg_VaParseTupleAndKeywords type: security ___ Python tracker <https://bugs.python.org/issue44401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42560] Improve Tkinter Documentation
Change by Richard Sheridan : -- nosy: +Richard Sheridan ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45109] pipes seems designed for bytes but is str-only
New submission from Richard Tollerton : 1. https://github.com/python/cpython/blob/3.9/Lib/pipes.py#L6 > Suppose you have some data that you want to convert to another format, > such as from GIF image format to PPM image format. 2. https://docs.python.org/3.9/library/pipes.html > Because the module uses /bin/sh command lines, a POSIX or compatible shell > for os.system() and os.popen() is required. 3. https://docs.python.org/3.9/library/os.html#os.popen > The returned file object reads or writes text strings rather than bytes. (1) and (3) are AFAIK mutually contradictory: you can't reasonably expect to shove GIFs down a str file object. I'm guessing that pipes is an API that never got its bytes API fleshed out? My main interest in this is that I'm writing a large CSV to disk and wanted to pipe it through zstd first. And I wanted something like perl's open FILE, "|zstd -T0 -19 > out.txt.zst". But the CSV at present is all bytes. (Technically the content is all latin1 at the moment, so I may have a workaround, but I'm not 100% certain it will stay that way.) What I'd like to see is for pipes.Template.open() to accept 'b' in flags, and for that to be handled in the usual way. -- components: Library (Lib) messages: 401103 nosy: rtollert priority: normal severity: normal status: open title: pipes seems designed for bytes but is str-only versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45601] test_tk and test_ttk_guionly fail with resource not availiable
New submission from Richard Hinerfeld : Please note that test_tk and test_ttk_guionly fail when running testall when compiling 3.8.9 python from source code. Compiling on Linux Debian 64-bit bullseye 11.1.0 on a 2008 Mac Book. -- components: Build files: TestTK.txt messages: 404942 nosy: rhinerfeld1 priority: normal severity: normal status: open title: test_tk and test_ttk_guionly fail with resource not availiable type: compile error versions: Python 3.8 Added file: https://bugs.python.org/file50393/TestTK.txt ___ Python tracker <https://bugs.python.org/issue45601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45601] test_tk and test_ttk_guionly fail with resource not availiable
Richard Hinerfeld added the comment: running build_scripts copying and adjusting /home/richard/Python-3.8.9/Tools/scripts/pydoc3 -> build/scripts-3.8 copying and adjusting /home/richard/Python-3.8.9/Tools/scripts/idle3 -> build/scripts-3.8 copying and adjusting /home/richard/Python-3.8.9/Tools/scripts/2to3 -> build/scripts-3.8 changing mode of build/scripts-3.8/pydoc3 from 644 to 755 changing mode of build/scripts-3.8/idle3 from 644 to 755 changing mode of build/scripts-3.8/2to3 from 644 to 755 renaming build/scripts-3.8/pydoc3 to build/scripts-3.8/pydoc3.8 renaming build/scripts-3.8/idle3 to build/scripts-3.8/idle3.8 renaming build/scripts-3.8/2to3 to build/scripts-3.8/2to3-3.8 ./python ./Tools/scripts/run_tests.py -v test_ttk_guionly /home/richard/Python-3.8.9/python -u -W default -bb -E -m test -r -w -j 0 -u all,-largefile,-audio,-gui -v test_ttk_guionly == CPython 3.8.9 (default, Oct 24 2021, 15:58:53) [GCC 10.2.1 20210110] == Linux-5.10.0-9-amd64-x86_64-with-glibc2.29 little-endian == cwd: /home/richard/Python-3.8.9/build/test_python_34348 == CPU count: 2 == encodings: locale=UTF-8, FS=utf-8 Using random seed 6980064 0:00:00 load avg: 0.32 Run tests in parallel using 4 child processes 0:00:00 load avg: 0.32 [1/1] test_ttk_guionly skipped (resource denied) test_ttk_guionly skipped -- Use of the 'gui' resource not enabled == Tests result: SUCCESS == 1 test skipped: test_ttk_guionly Total duration: 957 ms Tests result: SUCCESS -- ___ Python tracker <https://bugs.python.org/issue45601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37569] Complete your registration to Python tracker
Richard Hinerfeld added the comment: I just get an error when I visit the URL On Sun, Oct 24, 2021 at 4:57 PM Python tracker wrote: > To complete your registration of the user "rhinerfeld1" with > Python tracker, please visit the following URL: > > > https://bugs.python.org/?@action=confrego&otk=MxJ6fZghVQdh3dhyE1fj8I7bFrmjfve9 > > -- nosy: +rhinerfeld1 ___ Python tracker <https://bugs.python.org/issue37569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42738] subprocess: don't close all file descriptors by default (close_fds=False)
Richard Xia added the comment: I'd like to provide another, non-performance-related use case for changing the default value of Popen's close_fds parameters back to False. In some scenarios, a (non-Python) parent process may want its descendant processes to inherit a particular file descriptor and for each descendant process to pass on that file descriptor its own children. In this scenario, a Python program may just be an intermediate script that calls out to multiple subprocesses, and closing the inheritable file descriptors by default would interfere with the parent process's ability to pass on that file descriptor to descendants. As a concrete example, we have a (non-Python) build system and task runner that orchestrates many tasks to run in parallel. Some of those tasks end up invoking Python scripts that use subprocess.run() to run other programs. Our task runner intentionally passes an inheritable file descriptor that is unique to each task as a form of a keep-alive token; if the child processes continue to pass inheritable file descriptors to their children, then we can determine whether all of the processes spawned from a task have terminated by checking whither the last open handle to that file descriptor has been closed. This is particularly important when a processes exits before its children, sometimes uncleanly due to being force killed by the system or by a user. In our use case, Python's default value of close_fds=True interferes with our tracking scheme, since it prevents Python's subprocesses from inheriting that file descriptor, even though that file descriptor has intentionally been made inheritable. While we are able to work around the issue by explicitly setting close_fds=False in as much of our Python code as possible, it's difficult to enforce this globally since we have many small Python scripts. We also have no control over any third party libraries that may possibly call Popen. Regarding security, PEP 446 already makes it so that any files opened from within a Python program are non-inheritable by default, which I agree is a good default. One can make the argument that it's not Python's job to enforce a security policy on file descriptors that a Python process has inherited from a parent process, since Python cannot distinguish from descriptors that were accidentally or intentionally inherited. -- nosy: +richardxia ___ Python tracker <https://bugs.python.org/issue42738> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45936] collections.Counter drops key if value is 0 and updating using += operator
New submission from Richard Decal :
In brief:
```
from collections import Counter
x = Counter({'a': 0, 'b': 1})
x.update(x) # works: Counter({'a': 0, 'b': 2})
x += x # expected: Counter({'a': 0, 'b': 3}) actual: Counter({'b': 3})
```
I expect `+=` and `.update()` to be synonymous. However, the += operator is
deleting keys if the source Counter has a zero count to begin with:
```
x = Counter({'a': 1})
x += Counter({'a': 0}) # ok: Counter({'a': 1})
y = Counter({'a': 0})
y += y # expected: Counter({'a': 0}) actual: Counter()
```
--
messages: 407348
nosy: crypdick
priority: normal
severity: normal
status: open
title: collections.Counter drops key if value is 0 and updating using +=
operator
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue45936>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45943] kids10yrsap...@gmail.com
Change by Qualyn Richard : -- components: email files: PSX_20210903_080553.jpg nosy: barry, oktaine57, r.david.murray priority: normal severity: normal status: open title: kids10yrsap...@gmail.com type: behavior versions: Python 3.11 Added file: https://bugs.python.org/file50463/PSX_20210903_080553.jpg ___ Python tracker <https://bugs.python.org/issue45943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38904] "signal only works in main thread" in main thread
New submission from Richard Warfield : I have an application (https://github.com/litxio/ptghci) using embedded Python, which needs to set a signal handler (and use the prompt-toolkit library which itself sets signal handlers). My call to signal.signal is guarded by a check that we're running in the main thread: if threading.current_thread() is threading.main_thread(): print (threading.current_thread().name) signal.signal(signal.SIGINT, int_handler) And the above indeed prints "MainThread". But this raises an exception: File "app.py", line 45, in __init__ signal.signal(signal.SIGINT, int_handler) File "/usr/lib/python3.8/signal.py", line 47, in signal handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler)) ValueError: signal only works in main thread This seems like something that should not happen. Now, I tried to generate a simple replicating example but thus far haven't been able to do so -- simply calling signal.signal from PyRun_SimpleString doesn't do the trick, even within a pthreads thread. -- messages: 357390 nosy: Richard Warfield priority: normal severity: normal status: open title: "signal only works in main thread" in main thread type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38904] "signal only works in main thread" in main thread
Richard Warfield added the comment: I should mention, this behavior is new in 3.8.0. It did not occur in 3.7.x. -- ___ Python tracker <https://bugs.python.org/issue38904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38904] "signal only works in main thread" in main thread
Richard Warfield added the comment: Thanks for looking into this. Changing the behavior of the "threading" module to be consistent with the runtime and "signal" module would be sufficient, at least for my particular case. If the "if threading.current_thread() is threading.main_thread()" guard worked as expected it would be clear how to resolve the problem. On Sat, Dec 14, 2019 at 6:25 AM Eric Snow wrote: > > Eric Snow added the comment: > > Before 3.8, the "signal" module checked against the thread in which the > module was initially loaded, treating that thread as the "main" thread. > That same was true (and still is) for the "threading" module. The problem > for both modules is that the Python runtime may have actually been > initialized in a different thread, which is the actual "main" thread. > > Since Python 3.8 we store the ID of the thread where the runtime is > initialized and use that in the check the "signal" module does. However, > the "threading" module still uses the ID of the thread where it is first > imported. So your check against "threading.main_thread()" must be in code > that isn't running in the same thread where you ran Py_Initialize(). It > probably used to work because you imported "signal" and "threading" for the > first time in the same thread. > > So what next? > > First, I've created issue39042 to address the current different meanings > of "main thread". That should resolve the discrepancy between the signal > and threading modules. > > Second, what can we do to help embedders make sure they are running their > code in the main thread (e.g. when setting signals)? Is there any C-API we > could add which would have helped you here? > > -- > nosy: +eric.snow, vstinner > > ___ > Python tracker > <https://bugs.python.org/issue38904> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38904] "signal only works in main thread" in main thread
Richard Warfield added the comment: I think so, yes. On Wed, Dec 18, 2019 at 1:10 AM Eric Snow wrote: > > Eric Snow added the comment: > > So resolving issue39042 would be enough, particularly if we backported > the change to 3.8? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue38904> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35108] inspect.getmembers passes exceptions from object's properties through
Richard Bruskiewich added the comment: This "bug" is buzzing around my project head right now, interfering with the operation of the Python Fire CLI library when it attempts to interrogate the Python Pandas DataFrame using the inspect.getmembers() call. See https://github.com/pandas-dev/pandas/issues/31474 and https://github.com/pandas-dev/pandas/pull/31549. I have code that uses Fire and Pandas, but have to "dumb it down" to use Pandas 0.24.3 rather than the latest 0.25.1 which raises a "NotImplementedError" which leaks out of the getmembers() call. The Pandas people are passing the buck to you folks in the Python community. This is terribly frustrating for we minions in the real work trying to implementing real working software systems leveraging all these wonderful libraries (and the Python language). When is this "bug" going to be fixed? Help! -- nosy: +richardbruskiewich ___ Python tracker <https://bugs.python.org/issue35108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39686] add dump_json to ast module
New submission from Richard K :
Currently within the ast module, `dump` generates a string representation of
the AST for example,
>>> ast.dump(node)
'Module(body=[], type_ignores=[])'
The proposed enhancement would provide a complementary function, `dump_json` as
in a json representation of the ast.
This would be useful for those who would like to benefit from the utilities of
the json module for formatting, pretty-printing, and the like.
It would also be useful for those who want to serialize the AST or export it in
a form that can be consumed in an other programming language.
A simplified example,
>>> import ast
>>> node = ast.parse('')
>>> ast.dump_json(node)
{'Module': {'body': [], 'type_ignores': []}}
A simplified example of using `ast.dump_json` with the json module,
>>> import json
>>> json.dumps(ast.dump_json(node))
'{"Module": {"body": [], "type_ignores": []}}'
--
components: Library (Lib)
messages: 362256
nosy: sparverius
priority: normal
severity: normal
status: open
title: add dump_json to ast module
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39686>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39686] add dump_json to ast module
Change by Richard K : -- keywords: +patch pull_requests: +17938 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18558 ___ Python tracker <https://bugs.python.org/issue39686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39686] add dump_json to ast module
Richard K added the comment: Batuhan & Pablo thank you for your thoughts! Just wanted to reply to a few of the comments to clarify my position on the issue. > IMHO this is not a feature that has a general usage. If you want, as far as I > can see, there are some packages for doing that in PyPI already. Also, the > patch looks small so you can just add this to the required project. There seems to be movement towards a general usage. For instance, take a look at clang, in particular the flag '-ast-dump=json'. $ clang -cc1 -ast-dump=json foo.cc > ast.dump now can dump in pretty-printed way. Indeed however, there is not much one can do further with the output of ast.dump. With ast.dump_json one would benefit from programmer-centric functionality. -- > Thanks, Richard for your proposal. I concur with Batuhan: I am -1 as well on > this addition. Echoing some of the same ideas, I think this is specialized > enough that does not make sense to have it in the standard library, > especially if a Pypi package already exists. After just browsing the the pypi package/s you may be referring to, it appears that they do so in non-standard ways. > Additionally, this is straightforward to implement for very simple cases but > PR18558 will fail for very generic ASTs if they are deep enough (it uses > recursion). The implementation of ast.dump also uses recursion. I have tested ast.dump_json on sufficiently large source files and have not run into recursion depth exceeded issues. Thanks again for your perspective! -- ___ Python tracker <https://bugs.python.org/issue39686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39686] add dump_json to ast module
Richard K added the comment:
> I don't think the clang argument holds because clang is a command-line tool
> after all and it makes sense that it can produce several outputs while the
> ast module is exposes APIs that you can further process inside the language.
> Having json from the clang output will require more than one tool if clang
> does not support it while doing it in Python only requires Python.
I see what you mean. I was just trying to illustrate that such a feature is
desired by some.
Perhaps 'Python only requires Python' means that Python _could_ be the first
widely used language with such a superior meta-programming feature with respect
to AST analysis/code generation.
> > it appears that they do so in non-standard ways.
> Can you clarify what do you mean with that?
By non-standard I mean that the resulting json does not follow the structure of
the tree explicitly. For example with ast2json, '"_type": "Print"' includes a
(somewhat misleading) key that is not represented in the actual AST.
Example of ast2json output (example found here,
https://github.com/YoloSwagTeam/ast2json#example),
{
"body": [
{
"_type": "Print",
"nl": true,
"col_offset": 0,
"dest": null,
"values": [
{
"s": "Hello World!",
"_type": "Str",
"lineno": 1,
"col_offset": 6
}
],
"lineno": 1
}
],
"_type": "Module"
}
> Just to clarify: ast.dump *will* fail with a more deph object as well, I am
> not claiming that ast.dump will parse everything because of course suffers
> the same problem.
Makes sense. As you mentioned, these are edge cases which I assume will not be
an issue for those seeking to gain the benefits of 'ast.dump_json'
--
___
Python tracker
<https://bugs.python.org/issue39686>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39964] adding a string to a list works differently with x+='' compared to x=x+''
New submission from Richard King : x = ['a'] x += ' ' results in ['a',' '] x = x + ' ' results in an exception: Traceback (most recent call last): File "", line 1, in TypeError: can only concatenate list (not "str") to list It behaves the same in 2.7.15 and 3.7.2. -- components: Windows messages: 364213 nosy: paul.moore, rickbking, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: adding a string to a list works differently with x+='' compared to x=x+'' type: behavior versions: Python 2.7, Python 3.7 ___ Python tracker <https://bugs.python.org/issue39964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40054] Allow formatted strings as docstrings
New submission from Richard Neumann :
Currently only plain strings can be used as docstrings, such as:
class Foo:
"""Spamm eggs."""
For dynamic class generation, it would be useful to allow format strings as
docstrings as well:
doc = 'eggs'
class Foo:
"""Spamm {}.""".format(doc)
or:
doc = 'eggs'
class Foo:
f"""Spamm {doc}."""
A current use case in which I realized that this feature was missing is:
class OAuth2ClientMixin(Model, ClientMixin): # pylint: disable=R0904
"""An OAuth 2.0 client mixin for peewee models."""
@classmethod
def get_related_models(cls, model=Model):
"""Yields related models."""
for mixin, backref in CLIENT_RELATED_MIXINS:
yield cls._get_related_model(model, mixin, backref)
@classmethod
def _get_related_model(cls, model, mixin, backref):
"""Returns an implementation of the related model."""
class ClientRelatedModel(model, mixin):
f"""Implementation of {mixin.__name__}."""
client = ForeignKeyField(
cls, column_name='client', backref=backref,
on_delete='CASCADE', on_update='CASCADE')
return ClientRelatedModel
It actually *is* possible to dynamically set the docstring via the __doc__
attribute:
doc = 'eggs'
class Foo:
pass
Foo.__doc__ = doc
Allowing format strings would imho be more obvious when reading the code as it
is set, where a docstring is expected i.e. below the class / function
definition.
--
messages: 364934
nosy: conqp
priority: normal
severity: normal
status: open
title: Allow formatted strings as docstrings
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40054>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42765] Introduce new data model method __iter_items__
New submission from Richard Neumann :
I have use cases in which I use named tuples to represent data sets, e.g:
class BasicStats(NamedTuple):
"""Basic statistics response packet."""
type: Type
session_id: BigEndianSignedInt32
motd: str
game_type: str
map: str
num_players: int
max_players: int
host_port: int
host_ip: IPAddressOrHostname
I want them to behave as intended, i.e. that unpacking them should behave as
expected from a tuple:
type, session_id, motd, … = BasicStats(…)
I also want to be able to serialize them to a JSON-ish dict.
The NamedTuple has an _asdict method, that I could use.
json = BasicStats(…)._asdict()
But for the dict to be passed to JSON, I need customization of the dict
representation, e.g. set host_ip to str(self.host_ip), since it might be a
non-serializable ipaddress.IPv{4,6}Address. Doing this in an object hook of
json.dumps() is a non-starter, since I cannot force the user to remember, which
types need to be converted on the several data structures.
Also, using _asdict() seems strange as an exposed API, since it's an underscore
method and users hence might not be inclined to use it.
So what I did is to add a method to_json() to convert the named tuple into a
JSON-ish dict:
def to_json(self) -> dict:
"""Returns a JSON-ish dict."""
return {
'type': self.type.value,
'session_id': self.session_id,
'motd': self.motd,
'game_type': self.game_type,
'map': self.map,
'num_players': self.num_players,
'max_players': self.max_players,
'host_port': self.host_port,
'host_ip': str(self.host_ip)
}
It would be nicer to have my type just return this appropriate dict when
invoking dict(BasicStats(…)). This would require me to override the __iter__()
method to yield key / value tuples for the dict.
However, this would break the natural behaviour of tuple unpacking as described
above.
Hence, I propose to add a method __iter_items__(self) to the python data model
with the following properties:
1) __iter_items__ is expected to return an iterator of 2-tuples representing
key / value pairs.
2) the built-in function dict(), when called on an object, will attempt to
create the object from __iter_items__ first and fall back to __iter__.
Alternative names could also be __items__ or __iter_dict__.
--
components: C API
messages: 383897
nosy: conqp
priority: normal
severity: normal
status: open
title: Introduce new data model method __iter_items__
type: enhancement
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue42765>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42768] super().__new__() of list expands arguments
New submission from Richard Neumann :
When sublassing the built-in list, the invocation of super().__new__ will
unexpectedly expand the passed arguments:
class MyTuple(tuple):
def __new__(cls, *items):
print(cls, items)
return super().__new__(cls, items)
class MyList(list):
def __new__(cls, *items):
print(cls, items)
return super().__new__(cls, items)
def main():
my_tuple = MyTuple(1, 2, 3, 'foo', 'bar')
print('My tuple:', my_tuple)
my_list = MyList(1, 2, 3, 'foo', 'bar')
print('My list:', my_list)
if __name__ == '__main__':
main()
Actual result:
(1, 2, 3, 'foo', 'bar')
My tuple: (1, 2, 3, 'foo', 'bar')
(1, 2, 3, 'foo', 'bar')
Traceback (most recent call last):
File "/home/neumann/listbug.py", line 24, in
main()
File "/home/neumann/listbug.py", line 19, in main
my_list = MyList(1, 2, 3, 'foo', 'bar')
TypeError: list expected at most 1 argument, got 5
Expected:
(1, 2, 3, 'foo', 'bar')
My tuple: (1, 2, 3, 'foo', 'bar')
(1, 2, 3, 'foo', 'bar')
My list: [1, 2, 3, 'foo', 'bar']
--
components: ctypes
messages: 383902
nosy: conqp
priority: normal
severity: normal
status: open
title: super().__new__() of list expands arguments
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42768>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42768] super().__new__() of list expands arguments
Richard Neumann added the comment: I could have sworn, that this worked before, but it was obviously me being tired at the end of the work day. Thanks for pointing this out and sorry for the noise. -- ___ Python tracker <https://bugs.python.org/issue42768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42765] Introduce new data model method __iter_items__
Richard Neumann added the comment: Thank you all for your input. I had a look at aforementioned discussion and learned something new. So I tried to implement the dict data model by implementing keys() and __getitem__() accordingly: from typing import NamedTuple class Spamm(NamedTuple): foo: int bar: str def __getitem__(self, item): if isinstance(item, str): try: return getattr(self, item) except AttributeError: raise KeyError(item) from None return super().__getitem__(item) def keys(self): yield 'foo' yield 'bar' def main(): spamm = Spamm(12, 'hello') print(spamm.__getitem__) print(spamm.__getitem__(1)) d = dict(spamm) if __name__ == '__main__': main() Unfortunately this will result in an error: Traceback (most recent call last): File "/home/neumann/test.py", line 4, in class Spamm(NamedTuple): RuntimeError: __class__ not set defining 'Spamm' as . Was __classcell__ propagated to type.__new__? Which seems to be caused by the __getitem__ implementation. I found a corresponding issue here: https://bugs.python.org/issue41629 Can I assume, that this is a pending bug and thusly I cannot implement the desired behaviour until a fix? -- ___ Python tracker <https://bugs.python.org/issue42765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42765] Introduce new data model method __iter_items__
Richard Neumann added the comment:
Okay, I found the solution. Not using super() works:
from typing import NamedTuple
class Spamm(NamedTuple):
foo: int
bar: str
def __getitem__(self, index_or_key):
if isinstance(index_or_key, str):
try:
return getattr(self, index_or_key)
except AttributeError:
raise KeyError(index_or_key) from None
return tuple.__getitem__(self, index_or_key)
def keys(self):
yield 'foo'
yield 'bar'
def main():
spamm = Spamm(12, 'hello')
print(spamm.__getitem__)
print(spamm.__getitem__(1))
d = dict(spamm)
print(d)
if __name__ == '__main__':
main()
Result:
hello
{'foo': 12, 'bar': 'hello'}
--
___
Python tracker
<https://bugs.python.org/issue42765>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41629] __class__ not set defining 'X' as
Richard Neumann added the comment:
I just stumbled across this issue trying to resolve this:
https://bugs.python.org/issue42765?
While this fails:
from typing import NamedTuple
class Spamm(NamedTuple):
foo: int
bar: str
def __getitem__(self, index_or_key):
"""Returns the respective item."""
if isinstance(index_or_key, str):
try:
return getattr(self, index_or_key)
except AttributeError:
raise IndexError(index_or_key) from None
return super().__getitem__(index_or_key)
def keys(self):
return self._fields
def main():
spamm = Spamm(12, 'hello')
print(dir(spamm))
print(spamm._fields)
d = dict(spamm)
print(d)
if __name__ == '__main__':
main()
with
Traceback (most recent call last):
File "/home/neumann/test.py", line 4, in
class Spamm(NamedTuple):
RuntimeError: __class__ not set defining 'Spamm' as .
Was __classcell__ propagated to type.__new__?
The following works:
from typing import NamedTuple
def _getitem(instance, index_or_key):
"""Returns the respective item."""
if isinstance(index_or_key, str):
try:
return getattr(instance, index_or_key)
except AttributeError:
raise IndexError(index_or_key) from None
return super().__getitem__(index_or_key)
def dicttuple(cls: tuple):
"""Extends a tuple class with methods for the dict constructor."""
cls.keys = lambda self: self._fields
cls.__getitem__ = _getitem
return cls
@dicttuple
class Spamm(NamedTuple):
foo: int
bar: str
def main():
spamm = Spamm(12, 'hello')
print(dir(spamm))
print(spamm._fields)
d = dict(spamm)
print(d)
if __name__ == '__main__':
main()
And produces:
['__add__', '__annotations__', '__class__', '__class_getitem__',
'__contains__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__',
'__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__gt__',
'__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__',
'__lt__', '__module__', '__mul__', '__ne__', '__new__', '__orig_bases__',
'__reduce__', '__reduce_ex__', '__repr__', '__rmul__', '__setattr__',
'__sizeof__', '__slots__', '__str__', '__subclasshook__', '_asdict',
'_field_defaults', '_fields', '_make', '_replace', 'bar', 'count', 'foo',
'index', 'keys']
('foo', 'bar')
{'foo': 12, 'bar': 'hello'}
I am a bit baffled, why it works when the method is injected via a decorator.
--
nosy: +conqp
___
Python tracker
<https://bugs.python.org/issue41629>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43237] datetime.__eq__ returns true when timezones don't match
New submission from Richard Wise : from datetime import datetime, timezone, timedelta datetime_in_sgt = datetime(2021, 2, 16, 8, 0, 0, tzinfo=timezone(timedelta(hours=8))) datetime_in_utc = datetime(2021, 2, 16, 0, 0, 0, tzinfo=timezone.utc) print(datetime_in_sgt == datetime_in_utc) Expected: False Actual: True Although these two datetimes represent the same instant on the timeline, they are not identical because they use different timezones. This means that when unit testing timezone handling, tests will incorrectly pass despite data being returned in UTC instead of the requested timezone, so we need to write code such as this: # Timestamp comparison self.assertEqual(datetime_in_sgt, datetime_in_utc) # Timezone comparison self.assertEqual(datetime_in_sgt.tzinfo, datetime_in_utc.tzinfo) This is confusing and non-intuitive. For examples of how other languages handle such comparison, can refer to: https://docs.oracle.com/javase/8/docs/api/java/time/ZonedDateTime.html#equals-java.lang.Object- and https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html#equals-java.lang.Object- -- components: Library (Lib) messages: 387087 nosy: Woodz priority: normal severity: normal status: open title: datetime.__eq__ returns true when timezones don't match versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43273] Mock `_mock_wraps` is undocumented and inconsistently named
New submission from Richard Wise :
I am trying to use wraps to delegate a call to a decorated patch mock to
another method. By examining the source code, I was able to achieve this using
the (apparently undocumented) `Mock._mock_wraps` attribute instead of the
`wraps` attribute which would be expected given the constructor parameter
names. I find this behaviour very confusing and inconsistent. Can we either
expose `Mock.wraps` attribute or document `_mock_wraps` accordingly?
Example:
class MockRepro(unittest.TestCase)
@patch('foo')
def test_side_effect(self, mock_foo):
# Set side effect in constructor as per
https://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock
Mock(side_effect = [1, 2])
# Or can set on decorated patch
foo.side_effect = [1, 2]
@patch('foo')
def test_wraps(self, mock_foo):
def wrapped_method():
return 3
# Set wraps in constructor as per
https://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock
Mock(wraps=wrapped_method)
# Or can set on decorated patch
foo.wraps = wrapped_method # This silently fails
foo._mock_wraps = wrapped_method # Where does `_mock_wraps` come from?
--
components: Library (Lib)
messages: 387397
nosy: Woodz
priority: normal
severity: normal
status: open
title: Mock `_mock_wraps` is undocumented and inconsistently named
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue43273>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41176] revise Tkinter mainloop dispatching flag behavior
New submission from Richard Sheridan : This could also be considered a "behavior" type issue. `TkappObject` has a member `dispatching` that could usefully be exposed by a very simple read-only method for users to determine at runtime if the tkinter mainloop is running. Matplotlib and I'm sure other packages rely on fragile hacks (https://github.com/matplotlib/matplotlib/blob/a68562aa230e5895136120f5073dd01f124d728d/lib/matplotlib/cbook/__init__.py#L65-L71) to determine this state. I ran into this in https://github.com/matplotlib/matplotlib/pull/17802. All these projects would be more reliable with a new "dispatching()" method on the TkappObject, tkinter.Misc objects, and possibly the tkinter module itself. Internally, `dispatching` is used to, yes, determine if the mainloop is running. However, this determination is always done within the `WaitForMainloop` function (https://github.com/python/cpython/blob/bd4a3f21454a6012f4353e2255837561fc9f0e6a/Modules/_tkinter.c#L363-L380), which waits up to 1 second for the mainloop to come up. Apparently, this function allows a thread to implicitly wait for the loop to come up by calling any `TkappObject` method. This is a bad design choice in my opinion, because if client code wants to start immediately and the loop is not started by mistake, there will be a meaningless, hard-to-diagnose delay of one second before crashing. Instead, if some client code in a thread needs to wait for the mainloop to run, it should explicitly poll `dispatching()` on its own. This waiting behavior should be deprecated and, after a deprecation cycle perhaps, all `WaitForMainloop()` statements should be converted to inline `self->dispatching`. The correctness of the `dispatching` flag is dampened by the currently existing, undocumented `willdispatch` method which simply arbitrarily sets the `dispatching` to 1. It seems `willdispatch` was added 18 years ago to circumvent a bug building pydoc caused by `WaitForMainloop` not waiting long enough, as it tricks `WaitForMainloop` into... not waiting for the mainloop. This was in my opinion a bad choice in comparison to adding a dispatching flag: again, if some thread needs to wait for the mainloop, it should poll `dispatching()`, and avoid adding spurious 1 second waits. `willdispatch` currently has no references in CPython and most GitHub references are to Pycharm stubs for the CPython method. It should be deprecated and removed to preserve the correctness of `dispatching`. Happy to make a PR about this, except I don't understand clinic at all, nor the specifics of deprecation cycles in CPython. -- components: Tkinter messages: 372722 nosy: Richard Sheridan priority: normal severity: normal status: open title: revise Tkinter mainloop dispatching flag behavior type: enhancement versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41176] revise Tkinter mainloop dispatching flag behavior
Richard Sheridan added the comment: Removing `WaitForMainloop` would surely break some existing programs, but that's why I suggested deprecation instead of just removing it suddenly. We could issue a RuntimeWarning if `WaitForMainloop` actually waits and tell the client to take responsibility for the race condition they created. (They may have no idea! What if their delay unexpectedly increases to 1.2 seconds?) Whether or not waiting gets deprecated, it would make sense to make the sleep behavior configurable instead of hardcoded. I'll include something along those lines in my PR. On Wed, Jul 1, 2020 at 6:15 AM E. Paine wrote: > > E. Paine added the comment: > > I agree it would be helpful to expose an explicit way of telling if the > mainloop was running but am not sure about removing `WaitForMainloop` as it > could very easily break existing programs. > > If a program executes a tkinter method in a thread before the mainloop is > executed, the method will wait because of the call to `WaitForMainloop`. In > the example script this is done deliberately to demonstrate the behaviour > but could be done accidentally if the main thread has to do something else > before the mainloop (and after the thread has been created). > > I think the changes (whatever is concluded we should do) would be > considered an 'enhancement', which would not be backported to 3.9 and > before (I believe 'behaviour' is generally used for logic errors). > > I am very willing to help review a PR, however the people you really need > to convince are Serhiy and/or Guilherme (I have added them to the nosy). > > -- > nosy: +epaine, gpolo, serhiy.storchaka > versions: -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 > Added file: https://bugs.python.org/file49283/waitmainloop.py > > ___ > Python tracker > <https://bugs.python.org/issue41176> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41176] revise Tkinter mainloop dispatching flag behavior
Change by Richard Sheridan : -- keywords: +patch pull_requests: +20448 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21299 ___ Python tracker <https://bugs.python.org/issue41176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41176] revise Tkinter mainloop dispatching flag behavior
Richard Sheridan added the comment: I'd like to consider one more possibility for future behavior that sort of came to mind while discussing the PR. In current behavior, it is possible to use `willdispatch` to trick `WaitForMainloop` into letting a thread pass through the timeout, where it will eventually wait on a `Tcl_ConditionWait` in `Tkapp_ThreadSend`. This could be very efficient default behavior, since no polling is required; the thread just goes when the loop comes up. Is it possible to make this a well-documented feature and default behavior of tkinter? Or would it be too surprising for new and existing users? It would be important to make sure that threads aren't silently getting lost in old programs and new users can figure out they need to call `mainloop`, `doonevent`, or `update` when not on the REPL or the thread will hang. -- ___ Python tracker <https://bugs.python.org/issue41176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
