[issue43905] dataclasses.astuple does deepcopy on all fields
New submission from Erik Carstensen :
It seems that the 'dataclass.astuple' function does a deepcopy of all fields.
This is not documented. Two problems:
1. Dictionary keys that rely on object identity are ruined:
import dataclasses
@dataclasses.dataclass
class Foo:
key: object
key = object()
lut = {key: 5}
(y,) = dataclasses.astuple(Foo(x))
# KeyError
lut[y]
2. dataclasses can only be converted to a tuple if all fields are serializable:
import dataclasses
@dataclasses.dataclass
class Foo:
f: object
foo = Foo(open('test.py'))
dataclasses.astuple(foo)
->
TypeError: cannot pickle '_io.TextIOWrapper' object
In my use case, I just want a list of all fields. I can do the following as a
workaround:
(getattr(foo, field.name) for field in dataclasses.fields(foo))
Tested on Python 3.8.7 and 3.7.9.
--
components: Library (Lib)
messages: 391516
nosy: mandolaerik
priority: normal
severity: normal
status: open
title: dataclasses.astuple does deepcopy on all fields
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue43905>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43905] dataclasses.astuple does deepcopy on all fields
Erik Carstensen added the comment: Would it make sense to make dataclasses iterable, like so? def __iter__(self): return (getattr(self, field.name) for field in fields(self)) With that in place, deprecating astuple would maybe be less disruptive? -- ___ Python tracker <https://bugs.python.org/issue43905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44225] stop() on a stopped loop inhibits the next run_forever
New submission from Erik Carstensen : If you call stop() on an already stopped event loop, then the next call to run_forever will terminate after one loop iteration. I would expect the stop to either be a nop, or to be invalid in this state (and raise an exception). Example: import asyncio async def coro(x): print(x) if x < 10: asyncio.create_task(coro(x+1)) loop = asyncio.get_event_loop() loop.create_task(coro(0)) loop.stop() loop.run_forever() -- components: asyncio messages: 394250 nosy: asvetlov, mandolaerik, yselivanov priority: normal severity: normal status: open title: stop() on a stopped loop inhibits the next run_forever type: behavior versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44552] incomplete documentation of __main__.py
New submission from Erik Carstensen : I can find partial information on how Python treats __main__.py here: https://docs.python.org/3/library/__main__.html However, it is not documented how python handles __main__.py when passing the Python package to the interpreter without -m. If I have a program defined by /tmp/foo/bar.py and a file /tmp/foo/__main__.py, and I run python /tmp/foo ... then Python will run __main__.py, with /tmp/foo prepended to sys.path. I find this behaviour unfortunate; to me it would make more sense to prepend /tmp to sys.path, because then "python /tmp/foo" would be equivalent to "PYTHONPATH=/tmp python -m foo". With the current behaviour, if __main__.py wants to import bar.py, then it must write 'import bar' or 'import foo.bar' depending on whether the interpreter was invoked with -m. Unfortunately, by Hyrum's Law, you can find people describing and encouraging reliance upon the current undocumented behaviour, e.g.: https://www.geeksforgeeks.org/usage-of-__main__-py-in-python/ so perhaps the behaviour can't be changed that easily. Therefore, my request is to document how it works. -- assignee: docs@python components: Documentation messages: 396865 nosy: docs@python, mandolaerik priority: normal severity: normal status: open title: incomplete documentation of __main__.py type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44552] incomplete documentation of __main__.py
Erik Carstensen added the comment: thanks for the pointer and sorry for the noise! I'll review your text. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5985] Implement os.path.samefile and os.path.sameopenfile on Windows
Erik Carstensen added the comment: > Once I considered this approach, but problems was that > nFileIndexLow/High can change every time file handle is opened, so > it's not unique. Ah, I see, then your approach makes sense. There's another part of your patch that I don't understand: +except ImportError: # not running on Windows - mock up something sensible +from posixpath import samefile # XXX In what situations will this happen, and are we guaranteed in those cases that samefile will be found in posixpath? -- ___ Python tracker <http://bugs.python.org/issue5985> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5827] os.path.normpath doesn't preserve unicode
Erik Carstensen added the comment: Also, assertTrue has an alias failUnless which I personally find more descriptive (I don't know if either form is preferred for inclusion in Python though). -- ___ Python tracker <http://bugs.python.org/issue5827> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5985] Implement os.path.samefile and os.path.sameopenfile on Windows
Erik Carstensen added the comment: > Once I considered this approach, but problems was that > nFileIndexLow/High can change every time file handle is opened, so it's > not unique. See remarks in following page. > http://msdn.microsoft.com/en-us/library/aa363788%28VS.85%29.aspx Actually, that page only says that file identities may vary over time, and that it may happen during operations such as defragmentation. However, I have been in contact with a customer who observed a file system where the file index actually changed every time a file was closed and re-opened, given that nobody else kept the file open inbetween. This was on some kind of network mount, I wasn't told which kind (and I couldn't reproduce it with samba). This means that it's actually essential that you don't close the file between the CreateFile calls (and yes, your patch does this correctly). -- ___ Python tracker <http://bugs.python.org/issue5985> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8886] zipfile.ZipExtFile should be a context manager
New submission from Erik Carstensen : It's nice that ZipFile is a context manager in 2.7. It would be nice and more consistent if the objects returned from ZipFile.open() were context managers too. -- components: Library (Lib) messages: 106941 nosy: sandberg priority: normal severity: normal status: open title: zipfile.ZipExtFile should be a context manager type: feature request versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8886> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8886] zipfile.ZipExtFile is a context manager, but that is not documented
Erik Carstensen added the comment: Sorry, my mistake, ZipExtFile is indeed a context manager: I ran into the problem in 2.6, and checked whether it was fixed in 2.7; when quickly reading zipfile.py I saw that only ZipFile had context manager methods, I missed the BufferedIOBase inheritance. And when reading the tests I didn't see any 'with ZipFile.open(x) as y' expression. Maybe it still makes sense to document and test this. Changing the title. -- title: zipfile.ZipExtFile should be a context manager -> zipfile.ZipExtFile is a context manager, but that is not documented ___ Python tracker <http://bugs.python.org/issue8886> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8886] zipfile.ZipExtFile is a context manager, but that is not documented
Erik Carstensen added the comment: Patch that makes the zipfile test consistently use with statements to handle the return value of ZipFile.open(). -- keywords: +patch Added file: http://bugs.python.org/file17529/with-ZipExtFile-in-test.patch ___ Python tracker <http://bugs.python.org/issue8886> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
