[issue15196] os.path.realpath gets confused when symlinks include '..'
New submission from Ben Longbons :
I encountered this bug with the following filesystem layout
project/build/bin/main-gdb.py -> ../src/main-gdb.py
project/build/src -> ../src/
project/src/main-gdb.py -> ../py/main-gdb.py
project/py/main-gdb.py
where root/py/main-gdb.py contains
import os
print(os.path.realpath(__file__))
Actual Result:
project/build/py/main-gdb.py
instead of
project/py/main-gdb.py
The cause of this bug is the fact that os.path._resolve_link calls
os.path.normpath, which is not symlink-safe.
Specically, this is bad:
os.path.normpath('project/build/src/../py/main-gdb.py')
The correct thing to do is never call normpath; instead leave .. components and
pop off the last element after ensuring that the preceding directory is not a
symlink.
This bug seems pretty severe to me, because it prevents imports from working.
Exact python --version and Debian package versions:
Python 2.6.7(2.6.7-4)
Python 2.7.3rc2 (2.7.3~rc2-2.1)
Python 3.2.3(3.2.3-1)
--
components: Library (Lib)
messages: 164090
nosy: o11c
priority: normal
severity: normal
status: open
title: os.path.realpath gets confused when symlinks include '..'
versions: Python 2.6, Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue15196>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15196] os.path.realpath gets confused when symlinks include '..'
Ben Longbons added the comment: Yeah, this is a duplicate of issue 6975. Sorry also about the version thing. Although I can set this as closed: duplicate, I don't seem to be able to set what bug this is a duplicate of. -- resolution: -> duplicate status: open -> closed type: -> behavior ___ Python tracker <http://bugs.python.org/issue15196> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6975] symlinks incorrectly resolved on Linux
Ben Longbons added the comment: After filing a duplicate, issue 15196, I analyzed this: What happens: test/one/that_dir test/one/../two/this_dir/this_dir/this_dir/this_dir test/two/this_dir/this_dir/this_dir/this_dir test/two/this_dir/this_dir/this_dir/../two test/two/this_dir/this_dir/two What should happen: test/one/that_dir test/two/this_dir/this_dir/this_dir/this_dir test/two/../two/this_dir/this_dir/this_dir test/two/this_dir/this_dir/this_dir test/two/../two/this_dir/this_dir test/two/this_dir/this_dir test/two/../two/this_dir test/two/this_dir test/two/../two test/two -- nosy: +o11c versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue6975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15248] In "TypeError: 'tuple' object is not callable", suggest a comma.
New submission from Ben Longbons : I frequently construct lists of tuples, such as: [ (1, 2, 3) # oops, missing comma! (4, 5, 6) ] It would be nice if the error message gave a hint on what was *actually* wrong. Although I always use homogeneous containers, the type that's not callable could be something other than 'tuple'. You could possibly cut down on false positives (at the risk of false negatives) by checking that the not-callable object is newly constructed. A better way to cut down on false positives would be to check that a list, tuple, or set is being constructed from a literal, but this might be more complex. -- messages: 164637 nosy: o11c priority: normal severity: normal status: open title: In "TypeError: 'tuple' object is not callable", suggest a comma. type: enhancement ___ Python tracker <http://bugs.python.org/issue15248> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15248] In "TypeError: 'tuple' object is not callable", explain that a comma may be missing
Ben Longbons added the comment: This kind of "debug your code" is the kind of thing I've gotten used to from the Clang C/C++ compiler. Granted, compiled languages have an advantage here, but enough residual information remains for the interpreter at runtime. And I am in no way suggesting that *every* attempt to call a non-function have the extra information. For the cases where the error message is given, something like: TypeError: 'tuple' object is not callable (missing preceding comma?) The case of a homogenous container is the most important case. I've offered two different ways to figure out whether it's a typo or an attempt to call an object that you honestly think is callable: 1. Is the called object a newly-constructed (refcount=1) tuple literal? (Also works for list, set, and dictionary literals; probably wouldn't work for string literals due to interning) 2. Does the false call occur within a container literal or function call? I'm not intimately familiar with python bytecode or interpreter, but I'm sure anyone who is could extract this information. -- ___ Python tracker <http://bugs.python.org/issue15248> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19240] iglob should try to use `readdir`
Ben Longbons added the comment: This is a duplicate of bug 25596, which is now fixed. -- nosy: +o11c ___ Python tracker <http://bugs.python.org/issue19240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29475] option to not follow symlinks when globbing
New submission from Ben Longbons: Background: I have a data hierarchy with a lot of "sibling" symlinked directories/files. I want to glob only the non-symlink files, because it's a *huge* performance increase. Before `os.scandir`, I was using a local copy of `glob.py` and calling `os.path.islink` every time, which was faster for *my* use case, but unacceptable for upstreaming. With `os.scandir`, my new patch should be acceptable. The patch includes tests. Current discussion points: * Am I making the right decision to still accept symlinks for fully-literal components (in glob0)? It doesn't apply to my use-case, and I imagine some people might want to handle that case separately. * Are my tests sufficient? I just copied and modified the existing symlink tests. * Should my `flags` TODO be implemented *before* this patch? IMO it would be clearer after, even if it makes the diffs longer. Future discussion points (don't derail): * Should my `flags` TODO be implemented internally (this would significantly shrink any future patches)? (I can work on this) * Should `flags` also be exposed externally? * What additional `flags` might be useful? (my list: GLOB_ERR, GLOB_MARK, ~GLOB_NOSORT, ~GLOB_NOESCAPE, GLOB_PERIOD, GLOB_BRACE, GLOB_TILDE_CHECK, GLOB_ONLYDIR (+ equivalent for files - also, why doesn't `os.scandir` have accessors for the other types without doing an unnecessary stat?)) * Is there a bitwise enum (or equivalently, enum set) in the standard library so `flags` can get sane reprs? (I've implemented this before, but imagine it would be overwhelmed with bikeshedding if it doesn't exist yet) * Should `pathlib` really be implementing globbing on its own? That makes it hard to ensure feature parity. Perhaps the `glob` module needs some additional APIs? (I don't want to work on `pathlib` itself) -- components: Library (Lib) files: python-glob-symlink.diff keywords: patch messages: 287256 nosy: o11c priority: normal severity: normal status: open title: option to not follow symlinks when globbing type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file46566/python-glob-symlink.diff ___ Python tracker <http://bugs.python.org/issue29475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24791] *args regression
New submission from Ben Longbons: The following code is allowed by the grammar of Python 3.4, but not Python 3.5: `def f(): g(*a or b)` where unary `*` has the lowest precedence, i.e. it is equivalent to: `def f(): g(*(a or b))` The cause of the regression that the 3.4 grammar for `arglist` uses `'*' test` but the 3.5 grammar uses `'*' expr`. This is likely an oversight due to the PEP 448 changes; the fix should most likely be applied to the new `display`s as well as fixing the regression. *** Thanks to zware on IRC for actually testing this for me, since I don't have a runnable python3.5, just docs. -- components: Interpreter Core messages: 248014 nosy: o11c priority: normal severity: normal status: open title: *args regression versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue24791> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24791] *args regression
Ben Longbons added the comment: Related: bug 24176 fixed this for the `**` case. -- ___ Python tracker <http://bugs.python.org/issue24791> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24791] *args regression
Ben Longbons added the comment:
Also consider:
*() or (), *() or ()
[*() or (), *() or ()]
{*() or (), *() or ()}
{**{} or {}, **{} or {}}
Note that the second-or-later argument is a separate part of the grammar so
that's why I wrote it twice.
Actually, I think `star_expr` will probably go away entirely.
--
___
Python tracker
<http://bugs.python.org/issue24791>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2786] Names in traceback should have class names, if they're methods
Ben Longbons added the comment:
Code objects currently have no mutable fields.
So what are you planning to do about things like:
Foo = namedtuple('Foo', 'x y')
def frob(self):
return self.x + self.y
# probably actually done via a @member(Foo) decorator
# so adding more code here is not a problem.
Foo.frob.__qualname__ = 'Foo.frob'
Foo.frob = frob
del frob
--
nosy: +o11c
___
Python tracker
<http://bugs.python.org/issue2786>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2786] Names in traceback should have class names, if they're methods
Ben Longbons added the comment: I made a minimal gist of my motivating code: https://gist.github.com/o11c/ce0c2ff74b87ea71ad46 -- ___ Python tracker <http://bugs.python.org/issue2786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
