[issue38306] High level API for loop.run_in_executor(None, ...)?
Antoine Pietri added the comment: Yeah I'm pretty sure this solves it: https://github.com/python/cpython/pull/20143 Closing the issue, thanks. -- resolution: -> fixed ___ Python tracker <https://bugs.python.org/issue38306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38306] High level API for loop.run_in_executor(None, ...)?
Antoine Pietri added the comment: Yes, that's why I'm in favor of calling it run_thread. Because it fundamentally *isn't* a way to run a function in an executor, it's a way to run a function in a thread. -- ___ Python tracker <https://bugs.python.org/issue38306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38306] High level API for loop.run_in_executor(None, ...)?
Antoine Pietri added the comment: On Sat, Oct 12, 2019 at 1:24 PM Caleb Hattingh wrote: > Even before task groups land, this API can be easily improved by adding > > asyncio.run_in_executor(func, *args, **kwargs) > > - Only valid inside a coro or async context (uses get_running_loop internally) > - Analogous to how `loop.create_task` became `asyncio.create_task` > - Drop having to specify `None` for the default executor > - Users already know the `run_in_executor` name > - Allow both positional and kwargs (we can partial internally before calling > loop.run_in_executor) I think it should be run_thread() if it only works for thread. run_in_executor() should take an executor= parameter, but it wouldn't be as clear for beginners. I think there's value in having a simple, explicit way of saying "I want to run this function in a thread" without having to know what executors are. -- ___ Python tracker <https://bugs.python.org/issue38306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38306] High level API for loop.run_in_executor(None, ...)?
Antoine Pietri added the comment: > run_in_executor doesn't necessarily create a new thread each time so > create_thread would be misleading. run_in_thread might be better. Right, the idea was to have an analogy with create_task, because the run_in_executor would be wrapped in a Task. I'm okay with run_thread() too. -- ___ Python tracker <https://bugs.python.org/issue38306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38306] High level API for loop.run_in_executor(None, ...)?
Antoine Pietri added the comment: Actually I don't think it's possible with the current implementation to cancel the concurrent.Future after a timeout, so maybe we should remove that argument. So, this signature instead: async def create_thread(callable, *args, *, kwargs=None, loop=None) -- ___ Python tracker <https://bugs.python.org/issue38306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38306] High level API for loop.run_in_executor(None, ...)?
New submission from Antoine Pietri : In 3.7 a lot of high level functions have been added to the asyncio API, but nothing to start blocking functions as non-blocking threads. You still have to call get_event_loop() then await loop.run_in_executor(None, callable). I think this pattern is *very* common and could use a higher level interface. Would an API like this make sense? async def create_thread(callable, *args, *, kwargs=None, loop=None, timeout=None) Then it could just be used like this: await asyncio.create_thread(my_blocking_read, 4096, timeout=10) This API could wrap the run_in_executor in an asyncio.Task, that way you wouldn't have to await it to start the thread. There's evidence that this has confused people in the past: https://stackoverflow.com/questions/54263558/is-asyncio-run-in-executor-specified-ambiguously -- components: asyncio messages: 353456 nosy: antoine.pietri, asvetlov, yselivanov priority: normal severity: normal status: open title: High level API for loop.run_in_executor(None, ...)? type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10496] Python startup should not require passwd entry
Antoine Pietri added the comment: Would it make sense to backport this fix in 3.6 and 3.7? As distros increasingly move in the direction of using DynamicUser=yes for most stateless services, it would really help to have that, for instance in Debian Buster (which will probably be on 3.7 if my understanding is correct). FYI the cutoff date for the release candidate of 3.6.8 is 2018-12-07 (in two days). -- ___ Python tracker <https://bugs.python.org/issue10496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10496] Python startup should not require passwd entry
Antoine Pietri added the comment: Trivial way to reproduce, run this as root: systemd-run -p DynamicUser=yes -t python3 -- nosy: +antoine.pietri ___ Python tracker <https://bugs.python.org/issue10496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34930] sha1module: Switch sha1 implementation to sha1dc/hardened sha1
Antoine Pietri added the comment: Thanks, those arguments are convincing. I guess for applications that really can't move to a more secure hash, it would be better for them to rely on third-party libraries that implement the "band-aid". I'm closing this for now. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34961] Global scoping when shadowing local names in class definitions
Antoine Pietri added the comment: Tracking down the issue a bit further: a = 10 def main(): a = 42 class wtf(): print(a) class wtf2(): print(a) a = 2 main() prints: 42 10 It seems that when there is an assignation in the class body, prior usages of the variables in the class body are done by loading the variable using LOAD_NAME instead of LOAD_CLASSDEREF: Disassembly of : [...] 8 8 LOAD_NAME3 (print) 10 LOAD_CLASSDEREF 0 (a) 12 CALL_FUNCTION1 14 POP_TOP 16 LOAD_CONST 1 (None) 18 RETURN_VALUE Disassembly of : [...] 11 8 LOAD_NAME3 (print) 10 LOAD_NAME4 (a) 12 CALL_FUNCTION1 14 POP_TOP 12 16 LOAD_CONST 1 (2) 18 STORE_NAME 4 (a) 20 LOAD_CONST 2 (None) 22 RETURN_VALUE -- nosy: +antoine.pietri ___ Python tracker <https://bugs.python.org/issue34961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34930] sha1module: Switch sha1 implementation to sha1dc/hardened sha1
Antoine Pietri added the comment: On Wed, Oct 10, 2018 at 11:27 PM STINNER Victor wrote: > I dislike modifying a hash function to return its output but keep the same > name. For name, "SHA1" must remain "SHA1". If you want a variant, it should > have a different name, but I would expect that the existing sha1 function > remains unchanged. How do you keep the compatibility between different > programming languages and applications if one use SHA1 and the other uses > "hardened SHA-1"? Well, as I said we could almost consider both algorithms to be "compatible", in that they only differ in an infinitesimally small number of cases that were specifically *designed* to break SHA1. I agree it's not ideal to just replace the function directly, and that's why I suggested 4 possible alternatives. But you have to understand that the decision is not as simple as just "it doesn't give the same outputs so it should have a different name", because it *does* give the same outputs in *all of the cases that weren't designed to break it*, and the tradeoff for not making that the default is that most people who don't care about seeing the collisions happen will keep using a broken implementation for no reason. I'm not saying I disagree with you here, I'm just making sure you're aware of the tradeoff. If we make it the default, it's a *very slight* break of backwards compatibility, but it will be a positive change for 99.99% of users. The only affected people will be the ones that were writing scripts to check whether collisions did exist in the old algorithm, and if we change the name of the "classic sha1" they could trivially change it themselves. That said, if you'd rather have another name for it, it also works for me, it's better than having nothing. > One alternative is to stop using sha1 :-D Totally agree with you here, but it's not always an option, so I'd argue we should do our best to mitigate the problem. > Do you have examples? I already gave the Git example: https://github.com/git/git/commit/28dc98e343ca4eb370a29ceec4c19beac9b5c01e#diff-a44b837d82653a78649b57443ba99460 Fossil also migrated to it: https://www.fossil-scm.org/xfer/doc/trunk/www/hashpolicy.wiki The truth is, most of the other Merkle Tree implementations (like Bitcoin) were using a different hash in the first place, and that seems to be the main application where you have to keep backward compatibility with your hashes. So the fact that two of the main SHA-1 Merkle tree implementations moved to Hardened SHA-1 is huge, IMO. -- ___ Python tracker <https://bugs.python.org/issue34930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34930] sha1module: Switch sha1 implementation to sha1dc/hardened sha1
New submission from Antoine Pietri : SHA-1 has been broken a while ago. While the general recommandation is to migrate to more recent hashes (like SHA-2 and SHA-3), a lot of industry applications (notably Merkle DAG implementations like Git or Blockchains) require backwards compatibility with SHA-1, at least for the time being required for all the users to transition. The SHAttered authors published along with their paper a reference implementation of a "hardened SHA-1" algorithm, a SHA-1 implementation that uses counter-cryptanalysis to detect inputs that were forged to produce a hash collision. What that means is that Hardened SHA-1 is a secure hash function that produces the same output as SHA-1 in 99.99...% of cases, and only differs when two inputs were specifically made to generate collisions. The reference implementation is here: https://github.com/cr-marcstevens/sha1collisiondetection A large part of the industry has adopted Hardened SHA-1 as a temporary replacement for SHA-1, most notably Git under the name "sha1dc": https://github.com/git/git/commit/28dc98e343ca4eb370a29ceec4c19beac9b5c01e Since CPython has its own implementation of SHA-1, I think it would be a good idea to provide a hardened SHA-1 implementation. So either: 1. we replace the current implementation of sha1 by sha1dc completely, which might be a problem for people who write script to detect whether two files collide with classic sha1 2. we replace the current implementation but we keep the old one under a new name, like "sha1_broken" or "sha1_classic", which breaks backwards compatibility in a few marginal cases but the functionality can be trivially restored by changing the name of the hash 3. we keep the current implementation but add a new one under a new name "sha1dc", which probably means most people will stay on a broken implementation for no good reason, but it will be fully backwards-compatible even in the marginal cases 4. we don't implement Hardened SHA-1 at all, and we advise people to change their hash algorithm, while realizing that this solution is not feasible in a lot of cases. I'd suggest going with either 1. or 2. What would be your favorite option? Not sure whether this should go in security or enhancement, so I put it in the latter category to be more conservative in issue prioritization. I added the devs who worked the most on Modules/sha1module.c in the Nosy list. -- components: Library (Lib) messages: 327343 nosy: antoine.pietri, christian.heimes, loewis, vstinner priority: normal severity: normal status: open title: sha1module: Switch sha1 implementation to sha1dc/hardened sha1 type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22674] RFE: Add signal.strsignal(): string describing a signal
Antoine Pietri <antoine.piet...@gmail.com> added the comment: Done, https://github.com/python/cpython/pull/6085 As I said in the PR body, I can't test it myself, I don't have an OSX VM setup. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22674] RFE: Add signal.strsignal(): string describing a signal
Change by Antoine Pietri <antoine.piet...@gmail.com>: -- pull_requests: +5846 stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22674] RFE: Add signal.strsignal(): string describing a signal
Antoine Pietri <antoine.piet...@gmail.com> added the comment:
Yes, sorry, the issue is that we decided with pitrou to remove the osx specific
handling.
The fix should be:
diff --git a/Lib/test/test_signal.py b/Lib/test/test_signal.py
index fbb12a5b67..ae0351e992 100644
--- a/Lib/test/test_signal.py
+++ b/Lib/test/test_signal.py
@@ -58,8 +58,10 @@ class PosixTests(unittest.TestCase):
self.assertEqual(signal.getsignal(signal.SIGHUP), hup)
def test_strsignal(self):
-self.assertEqual(signal.strsignal(signal.SIGINT), "Interrupt")
-self.assertEqual(signal.strsignal(signal.SIGTERM), "Terminated")
+self.assertTrue(signal.strsignal(signal.SIGINT)
+.startswith("Interrupt"))
+self.assertTrue(signal.strsignal(signal.SIGTERM)
+.startswith("Terminated"))
# Issue 3864, unknown if this affects earlier versions of freebsd also
def test_interprocess_signal(self):
Should I submit a new PR for this?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22674>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22674] RFE: Add signal.strsignal(): string describing a signal
Antoine Pietri <antoine.piet...@gmail.com> added the comment: I updated Vajrasky's patch to rebase it onto master, use the clinic argument parser and improve the docs. I made a PR on GitHub so the review can be easier than a patch. I left a Co-Authored-By field so I'm not stealing the ownership of this patch :-P -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22674] RFE: Add signal.strsignal(): string describing a signal
Change by Antoine Pietri <antoine.piet...@gmail.com>: -- pull_requests: +5784 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29116] Make str and bytes error messages on concatenation conform with other sequences
Change by Antoine Pietri <antoine.piet...@gmail.com>: -- keywords: +patch pull_requests: +4084 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22674] strsignal() missing from signal module
Antoine Pietri <antoine.piet...@gmail.com> added the comment: Hey everyone, We would like to have that feature for a project where we have to use ctypes to achieve that. I don't know the answers to vajrasky's questions but I just wanted to chime in to say having this feature would be greatly appreciated. I can also work on the code if you need any help. Thanks! -- nosy: +antoine.pietri ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30762] Misleading message “can't concat bytes to str”
Changes by Antoine Pietri <antoine.piet...@gmail.com>: -- components: +Interpreter Core ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30762] Misleading message “can't concat bytes to str”
Changes by Antoine Pietri <antoine.piet...@gmail.com>: -- pull_requests: +2447 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30762] Misleading message “can't concat bytes to str”
New submission from Antoine Pietri: >>> b'a' + 'a' Traceback (most recent call last): File "", line 1, in TypeError: can't concat bytes to str This error message is misleading because it is reversed: what is really happening is that we're concatenating str to bytes! When you say "attach A to B" it means B is there first and A is added to it afterwards. That said, we can't just reverse the message (“can't concat str to bytes”), because having the message reversed compared to the code would be also misleading. I therefore propose to use “and” (→ “can't concat bytes and str”), which makes more sense and preserve the order. -- messages: 296870 nosy: antoine.pietri priority: normal severity: normal status: open title: Misleading message “can't concat bytes to str” ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Changes by Antoine Pietri <antoine.piet...@gmail.com>: -- pull_requests: +2189 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Changes by Antoine Pietri <antoine.piet...@gmail.com>: -- pull_requests: +2188 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: The only backport was for 3.6 as the previous versions don't have the strict= parameter. PR submitted here: https://github.com/python/cpython/pull/1985 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Changes by Antoine Pietri <antoine.piet...@gmail.com>: -- pull_requests: +2052 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: The code has been reviewed by (the other) Antoine, I guess there is now everything needed to merge it? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: I updated the PR to fix the Windows part of the issue thanks to Zachary who gave me access to a Windows machine. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: So, I asked a friend to check again with a more recent Python version on Windows and he can't reproduce the documented behavior, so the bug seems to also be present on Windows. My patch doesn't address that for now, which explains why the build fails (and why it was working before). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Changes by Antoine Pietri <antoine.piet...@gmail.com>: -- stage: test needed -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24692] types.coroutines() idempotence documentation
Antoine Pietri added the comment: I checked, the current doc gives a good explanation. I'm closing the issue. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: I added a fix for the tests and the code. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: I'm on it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: By the way, I'm pasting what I said on the PR here: For what it's worth, this bug was the cause of an important downtime in our organization, because someone needed to normalize a path that was later passed to a .mkdir(parents=True), and it was, in some cases, silently doing the mkdir of a wrong path instead of creating all the parents. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: In Windows/Python 3.6, the behavior matches the documented one, so this could actually be an important silent bug when executing a code wrote for Windows in another OS. I'd argue to fix it in 3.6 too. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30177] pathlib.resolve(strict=False) only includes first child
Antoine Pietri added the comment: I can reproduce this bug. This behavior is really confusing. -- nosy: +seirl ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24692] types.coroutines() idempotence documentation
Antoine Pietri added the comment: Lgtm! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24692 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24692] types.coroutines() idempotence documentation
New submission from Antoine Pietri: In the new types.coroutines() documentation, it is not clearly stated whether this function is idempotent or not: what happens when it is called on a function that is already a native coroutine? -- assignee: docs@python components: Documentation messages: 247184 nosy: docs@python, seirl priority: normal severity: normal status: open title: types.coroutines() idempotence documentation versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24692 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: Also, Serhiy, I think you may have got me mixed up with someone else. I don’t think I did any patches here, so I probably shouldn’t be credited for them :) Yeah, but I don't mind if I'm not in the ACKS file for a one-line patch though :P -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: This change does not need to be merged on 2.7 anyway, as the os.fdopen sets the name attribute to 'fdopen' and not to the fd, this check is not required prior to python 3. Still, it would be interesting to investigate why this breaks 2.7 though. -- versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19776] Provide expanduser() on Path objects
Antoine Pietri added the comment: I think that `absolute` method should call `expanduser` and `expandvars` (do you plan to include it?) automatically. This should be optional (via default arguments: `expanduser=True, expandvars=True`. I think it shouldn't. (Or shouldn't be set to True by default anyway). absolute() method resolves symlinks, and it would make no sense to expand tildes and vars, which are purely a shell syntax. . and .. are real things in the filesystem, ~ is just a notation commonly used (since it's in the SCL spec), but it's not *part* of the path, that's why you can totally have a valid ~ file. Making absolute() expand tildes would be illogic, unintuitive and unpythonic. (+1 for the .expanduser() patch though, I went here after searching for this feature in the docs). -- nosy: +seirl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: Well, that seems complicated: you can't overwrite a io.FileIO().name attribute, and doing so would be nonsensical for tarfile, which would try to perform IO operations on a random file descriptor... Also, I can't think of any case where a .name attribute could actually be bytes (I was just mirroring the code in msg214670). Here's a patch that tries all combinations of encoding for writing, but I can't see a way to enforce manually the name attribute being an int, even for this test purposes. -- Added file: http://bugs.python.org/file34739/test_tarfile_all_modes.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13781] gzip module does the wrong thing with an os.fdopen()'ed fileobj
Antoine Pietri added the comment: Actually, thinking about it, it seems safer to use os.open() + os.fdopen() than TemporaryFile(), like in the equivalent test for 'gzip'. This new patch replaces last one. -- nosy: +seirl Added file: http://bugs.python.org/file34740/test_tarfile_fdopen.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: Ping. The patch is just one line and there's a test case, if someone could review that, it would be great! (For the record I signed the contributor agreement a week ago and my profile still hasn't been updated). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tempfile.TemporaryFile() shouldn't have a name attribute
Antoine Pietri added the comment: I attached a patch for tarfile with eryksun's suggestion. -- keywords: +patch Added file: http://bugs.python.org/file34603/tarfile-fileobjname.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: Here's the test case as requested by berkerpeksag in the patch review. -- Added file: http://bugs.python.org/file34605/test_tarfile_fobj_int.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: Yes, the bug report was originally titled like this (TemporaryFile should'nt have a name attribute) but apparently this is a common and expected behavior for FileIO subclasses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: Well, this behavior seems pretty inconsistent to me, it means that every library has to check if the name attribute is actually a string (which would correspond to a path) or an int (that would mean a fd), and I think a fd attribute would seem more consistent. But as I don't think we could change this behavior that easily (it means breaking retrocompatibility after all...), we must at least make tarlib deal with that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tempfile.TemporaryFile() shouldn't have a name attribute
New submission from Antoine Pietri: The fact that tempfile.TemporaryFile() has a name integer attribute causes weird behavior when interacting with libraries that rely on this attribute being a valid string for file objects. For instance, it led to this exception with the tarfile module, which I resolved by using a NamedTemporaryFile(): tarfile.open(fileobj=tempfile.TemporaryFile(), mode='w') Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.4/tarfile.py, line 1585, in open return cls.taropen(name, mode, fileobj, **kwargs) File /usr/lib/python3.4/tarfile.py, line 1595, in taropen return cls(name, mode, fileobj, **kwargs) File /usr/lib/python3.4/tarfile.py, line 1431, in __init__ self.name = os.path.abspath(name) if name else None File /usr/lib/python3.4/posixpath.py, line 360, in abspath if not isabs(path): File /usr/lib/python3.4/posixpath.py, line 64, in isabs return s.startswith(sep) AttributeError: 'int' object has no attribute 'startswith' Which is caused by these lines in the tarfile module: if name is None and hasattr(fileobj, name): name = fileobj.name If TemporaryFile() didn't have a name attribute, tarfile, which doesn't really need the file name, would simply have continued without errors. I am not aware of any place where this name integer attribute is actually useful, and, as a matter of fact, it is not even documented: http://docs.python.org/3.4/library/tempfile.html#tempfile.TemporaryFile -- components: Library (Lib) messages: 214662 nosy: seirl priority: normal severity: normal status: open title: tempfile.TemporaryFile() shouldn't have a name attribute type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tempfile.TemporaryFile() shouldn't have a name attribute
Antoine Pietri added the comment: Alternatively, if the name attribute can't be removed, I propose the following diff for the tarfile module: -if name is None and hasattr(fileobj, name): +if name is None and hasattr(fileobj, name) and isinstance(fileobj.name, str): :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18145] Strange behavior when importing internal modules in the __init__.py of a submodule
New submission from Antoine Pietri:
I just found a very strange bug today, and it took me like two hours to figure
out the problem.
We first create a package package, which contains an __init__.py, which makes
an absolute import of package/foo.py (import package.foo), which makes an
absolute import of package/bar.py (import package.bar).
Everything works fine as expected, the modules are imported correctly in the
__init__.py and we can use them.
Now, if we move everything in a subpackage, the behavior is complete nonsense.
We then have package/subpackage/{foo,bar,__init__}.py and an empty
package/__init__.py.
We can import package.subpackage.foo and use it, but when we import
package.subpackage.bar, the import statement works as expected but we CAN'T
use the imported package:
import package.subpackage.bar # works fine
dir(package.subpackage.bar) # WAT
AttributeError: 'module' object has no attribute 'subpackage'
You can find a tarball attached to this bug report that contains the working
case and the failing case:
package1
├── bar.py
├── foo.py
└── __init__.py
package2
└── subpackage
├── bar.py
├── foo.py
└── __init__.py
$ python3
import package1.foo
__init__: importing package1.foo
foo.py: importing package1.bar
foo.py: package1.bar.__name__: package1.bar
__init__: package1.foo.__name__: package1.foo
import package2.subpackage.foo
__init__: importing package2.subpackage.foo
foo.py: importing package2.subpackage.bar
Traceback (most recent call last):
File stdin, line 1, in module
File ./package2/subpackage/__init__.py, line 2, in module
import package2.subpackage.foo
File ./package2/subpackage/foo.py, line 3, in module
print('foo.py: package2.subpackage.bar.__name__:',
package2.subpackage.bar.__name__)
AttributeError: 'module' object has no attribute 'subpackage'
tl;dr: you can use only relative imports to refer to modules of a package
inside a module imported by the __init__.py of this package except if the
package is not a subpackage. Else, the package will be successfully imported
but trying to use it will lead to a weird AttributeError. (Wat.)
--
components: Interpreter Core
files: lolpython.tar.xz
messages: 190688
nosy: seirl
priority: normal
severity: normal
status: open
title: Strange behavior when importing internal modules in the __init__.py of a
submodule
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file30478/lolpython.tar.xz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18145
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18145] Strange behavior when importing internal modules in the __init__.py of a submodule
Antoine Pietri added the comment: Okay, maybe my message was unclear. I figured out on my own how to work around this issue (for instance using relative imports), the main problem for me is that this issue is very difficult to debug. The import statement should at least fail with a more explicit error, imho. -- resolution: wont fix - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18145 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
