[issue43529] pathlib.Path.glob causes OSError encountering symlinks to long filenames
Eric Frederich added the comment: I'm happy to create a pull request but would need some help. Looking at that routine it has changed over time and I cannot simply create a single patch against 3.6 and have it merge cleanly into newer versions. I'd need help explaining the process -- ___ Python tracker <https://bugs.python.org/issue43529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43529] pathlib.Path.glob causes OSError encountering symlinks to long filenames
Eric Frederich added the comment: I verified against all versions available for me to select. For 3.10 I used the 3.10-rc Docker image. -- versions: +Python 3.10, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue43529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43529] pathlib.Path.glob causes OSError encountering symlinks to long filenames
Change by Eric Frederich : -- versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43529] pathlib.Path.glob causes OSError encountering symlinks to long filenames
New submission from Eric Frederich :
Calling pathlib.Path.glob("**/*) on a directory containing a symlink which
resolves to a very long filename causes OSError.
This is completely avoidable since symlinks are not followed anyway.
In pathlib.py, the _RecursiveWildcardSelector has a method _iterate_directories
which first calls entry.is_dir() prior to excluding based on entry.is_symlink().
It's the entry.is_dir() which is failing.
If the check for entry.is_symlink() were to happen first this error would be
avoided.
It's worth noting that on Linux "ls -l bad_link" works fine.
Also "find /some/path/containing/bad/link" works fine.
You do get an error however when running "ls bad_link"
I believe Python's glob() should act like "find" on Linux and not fail.
Because it is explicitly ignoring symlinks anyway, it has no business calling
is_dir() on a symlink.
I have attached a file which reproduces this problem. It's meant to be ran
inside of an empty directory.
--
files: uhoh.py
messages: 388927
nosy: eric.frederich
priority: normal
severity: normal
status: open
title: pathlib.Path.glob causes OSError encountering symlinks to long filenames
Added file: https://bugs.python.org/file49884/uhoh.py
___
Python tracker
<https://bugs.python.org/issue43529>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41482] docstring errors in ipaddress.IPv4Network
New submission from Eric Frederich : The __init__ method for IPv4Network has a typo where it says all three of '192.0.2.0/24', '192.0.2.0/255.255.255.0' and '192.0.0.2/0.0.0.255' should be equal. -- assignee: docs@python components: Documentation messages: 374841 nosy: docs@python, eric.frederich priority: normal severity: normal status: open title: docstring errors in ipaddress.IPv4Network 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/issue41482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29319] Embedded 3.6.0 distribution cannot run pyz files
Eric Frederich added the comment: I can confirm that this is NOT fixed in 3.6.1rc1 embeddable zip. This is extremely easy to reproduce. Look at the contents of foo.py and bar.py. Just throw them in the same directory and try to run C:\path\to\extracted\python.exe foo.py -- versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29319] Embedded 3.6.0 distribution cannot run pyz files
Eric Frederich added the comment:
I'm wondering if I'm experiencing this same issue.
In a simple directory with a foo.py and a bar.py where foo tries to import from
bar I cannot get it to work with the embeddable 3.6.0 zip, but the standard
3.6.0 that gets "installed" works fine. Also 3.5.3 works fine
C:\Users\eric\Desktop\wtf>more foo.py
from bar import bar
print(bar('hi'))
C:\Users\eric\Desktop\wtf>more bar.py
def bar(s):
return s.upper()
C:\Users\eric\Desktop\wtf>C:\Users\eric\Downloads\python-3.5.3-embed-amd64\python.exe
foo.py
HI
C:\Users\eric\Desktop\wtf>C:\Users\eric\Downloads\python-3.6.0-embed-amd64\python.exe
foo.py
Traceback (most recent call last):
File "foo.py", line 1, in
from bar import bar
ModuleNotFoundError: No module named 'bar'
--
nosy: +eric.frederich
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29319>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24685] collections.OrderedDict collaborative subclassing
Eric Frederich added the comment: I understand that in the general case you cannot just swap the order around and get the same behaviour. This LoggingDict just prints some stuff to the screen and delegates to super and so I believe it should work wherever it is placed in a cooperative hierarchy. Do you agree? Now, I understand that OrderedDict is not cooperative. You stated that this is a design decision and I respect that choice, but you also stated that classes can be made to be cooperative by creating a wrapper. The reason I re-opened this bug is because I fail to see a way in which to create such a wrapper for Python3. Do you believe that it should be possible to create a cooperative wrapper? If it is possible (and its just my inability to create one) then I have no issue and the bug should be closed. If it is not possible, then perhaps it could be noted somewhere that its not cooperative and impossible to make it cooperative and it should be listed last when using multiple inheritance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24685] collections.OrderedDict collaborative subclassing
Eric Frederich added the comment: Éric (Araujo), Combinding defaultdict and OrderedDict is a little easier since one of them (defaultdict) has special behavior on getitem while the other (OrderedDict) has special behavior on setitem. I played with mixing those two myself and saw some issues and found that I had to explicitly call __init__ on both base classes to get them primed properly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24685] collections.OrderedDict collaborative subclassing
Eric Frederich added the comment: Raymond, Thanks for the explanation of your reasoning. Could you please provide an example of how to create a cooperative subclass of OrderedDict? I have attempted to make one. I succeeded to make it work where the previous example failed but in doing made the example that used to work now fail. I have attached my attempt at making a cooperative OrderedDict in inj2.py class coop_OrderedDict(OrderedDict): A cooperative version of OrderedDict def __setitem__(self, k, v, **kwargs): # OrderedDict calls dict.__setitem__ directly skipping over LoggingDict # fortunately we can control this with dict_setitem keyword argument # calculate OrderedDict's real parent instead of skipping right to dict.__setitem__ # though depending on the hierarchy it may actually be dict.__setitem__ m = super(OrderedDict, self).__setitem__ # dict_setitem wants an unbound method unbound_m = m.im_func return super(coop_OrderedDict, self).__setitem__(k, v, dict_setitem=unbound_m) In Python2 it fails with: Traceback (most recent call last): File /tmp/inj2.py, line 51, in module old1['hooray'] = 'it worked' File /tmp/inj2.py, line 30, in __setitem__ return super(LoggingDict, self).__setitem__(k, v) File /tmp/inj2.py, line 18, in __setitem__ unbound_m = m.im_func AttributeError: 'method-wrapper' object has no attribute 'im_func' In Python3 both cases fail. -- Added file: http://bugs.python.org/file39998/inj2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24685] collections.OrderedDict collaborative subclassing
Changes by Eric Frederich eric.freder...@gmail.com: Removed file: http://bugs.python.org/file39998/inj2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24685] collections.OrderedDict collaborative subclassing
Changes by Eric Frederich eric.freder...@gmail.com: Added file: http://bugs.python.org/file3/inj2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24685] collections.OrderedDict collaborative subclassing
Eric Frederich added the comment: Attached, as inj3.py, is a version I made which seems to work with Python2 but not with Python3's C implementation of OrderedDict. I had to walk the MRO myself to get the unbound method to pass along as dict_setitem. With Python3 it doesn't look like doing this was left configurable. It crashes complaining TypeError: wrapper __setitem__ doesn't take keyword arguments Re-opening this bug since it seems impossible to make OrderedDict cooperative in Python3 even with a wrapper. Perhaps Python3's OrderedDict should either (a) be cooperative at the C level (b) support dict_setitem keyword argument to maintain compatibility with Python2. -- resolution: not a bug - status: closed - open versions: +Python 3.5 Added file: http://bugs.python.org/file4/inj3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24685] collections.OrderedDict collaborative subclassing
New submission from Eric Frederich: After watching the PyCon talk Super considered super[1] and reading the corresponding blog post[2] I tried playing with dependency injection. I was surprised to notice that the example he gave did not work if I swap the order of the classes around. I think it should have. See attached file. I think this is a bug in collections.OrderedDict OrderedDict is not well-behaved as far as cooperative subclassing is concerned. The source code is hard wired with a keyword argument dict_setitem=dict.__setitem__ which it then calls at the end with dict_setitem(self, key, value) A quick search of github for dict_setitem shows that this bad practice seems be making its way into other projects If dict_setitem keyword arg is really necessary to have, then maybe: (a) have it default to None (b) at the end of __setitem__ do something like: if dict_setitem is not None: return dict_setitem(self, key, value) super(OrderedDict, self).__setitem__(key, value) After a discussion on #py-dev this seemed like a reasonable request (not necessarily the implementation, but the idea that OrderedDict should cooperate). I tested this against the C implementation of OrderedDict in Python 3.5 and noticed that it doesn't cooperate either. [1] https://www.youtube.com/watch?v=EiOglTERPEo [2] https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ -- components: Library (Lib) files: inj.py messages: 247136 nosy: eric.frederich, eric.snow, rhettinger priority: normal severity: normal status: open title: collections.OrderedDict collaborative subclassing versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file39982/inj.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6498] Py_Main() does not return on SystemExit
Eric Frederich eric.freder...@gmail.com added the comment: So there is a disconnect. You can either change the documentation to match the behavior or you can change the code to match the documentation. I would prefer to leave the documentation alone and make Py_Main return rather than exit on sys.exit. That's just my 2 cents. -- nosy: +eric.frederich ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6498 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
