[issue41556] hostname verification fails if hostname starts with literal IPv4
Change by Devin Bayer : -- nosy: +akvadrako ___ Python tracker <https://bugs.python.org/issue41556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17050] argparse.REMAINDER doesn't work as first argument
Change by Devin Bayer <d...@doubly.so>: -- nosy: -akvadrako ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17050] argparse.REMAINDER doesn't work as first argument
Devin Bayer <d...@doubly.so> added the comment: This bug is 5 years old and you are arguing what? That it doesn't matter because it's rarely used compared to some undocumented useless alternative? It's mildly interesting to hear about some implementation detail but I really don't care. I think you're just wasting your time. I want the docs to match the implementation. But it doesn't matter - argparse is shit anyway - I'll just write my own parser. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17050] argparse.REMAINDER doesn't work as first argument
Devin Bayer <d...@doubly.so> added the comment: I still don't understand how that corresponds to the described behavior of REMAINDER and what it has to do with this bug. How can REMAINDER possibly ever work if optionals take priority? However it does when it's not the first argument. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17050] argparse.REMAINDER doesn't work as first argument
Devin Bayer <d...@doubly.so> added the comment: I don't understand how this is about positionals vs optionals. REMAINDER is supposed to capture everything from that point forward, not just positionals. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17050] argparse.REMAINDER doesn't work as first argument
Devin Bayer <d...@doubly.so> added the comment: Can we at least document that argparse.REMAINDER cannot be used as the first argument? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17050] argparse.REMAINDER doesn't work as first argument
Change by Devin Bayer <d...@doubly.so>: -- nosy: +akvadrako ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds
Devin Bayer <d...@doubly.so> added the comment: That seems like it makes the most sense, though I would suggest a higher-level test, because caching of bytecode is an implementation detail. So, while mocking time.time to be constant: 1. write dummy module with x=1 2. import dummy 3. overwrite dummy module with x=2 4. reload(dummy) 5. assert dummy.x == 2 BTW Brett, I didn't think it was personal; that would be odd considering you don't know me. But from a new contributor's perspective it didn't look like you are taking bugs seriously. If you had pointed out that you will reopen it if I made a good case, that would be been more clear. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds
Devin Bayer <d...@doubly.so> added the comment: You can't demand a hot loader to react instantly and there are other use cases, like generating modules programatically. What is your objection to my proposed solution, which behaves correctly in all cases? If you are not importing modules immediately after writing them, there is no harm in skipping the cache if the file mtime differs from the current time. If you are importing modules immediately, then you want to bypass the cache in that case, since it can't be relied upon. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds
Devin Bayer <d...@doubly.so> added the comment: That wouldn't always work either. If the source file is imported, then edited, then not reimported until the next second (or far in the future) the stale bytecode would still be used. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds
Devin Bayer <d...@doubly.so> added the comment: Thanks for the support Nick. I think your proposed idea would still result in rare but confusing behavior, which is the type of surprise Python should avoid. The hash-based pyc files doesn't seem like a solution to me, because it won't be enabled by default. And I think it's obvious the performance loss of doing so is unacceptable. If changing the bytecode format is unacceptable, though it seems like the cleanest answer, the import machinery could just avoid caching bytecode when the int(mtime) of the source file is potentially in the future. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds
Devin Bayer <d...@doubly.so> added the comment: Hello Brett, it would be nice if you would discuss this before closing. The referenced PEP will not solve my use case, because hash-based checking will not become the default. The issue is that by default the source file loader will be returning stale bytecode and that's incorrect behavior. If you wish to avoid the stat call you could use a higher resolution timestamp in the pyc file, or better yet add a second field indicating bytecode compilation time. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds
Change by Devin Bayer <d...@doubly.so>: -- keywords: +patch pull_requests: +3941 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds
New submission from Devin Bayer <d...@doubly.so>: The current import machinery will use stale cached bytecode if the source is modified more than once per second and with equal size. A straightforward fix is to require the bytecode mtime to be greater than the source file mtime. In the unusual case where the file is written twice with the precision the filesystem records, this will ignore the cache, but at least we aren't behaving incorrectly. -- components: Interpreter Core messages: 304236 nosy: akvadrako priority: normal severity: normal status: open title: SourceLoader uses stale bytecode in case of equal mtime seconds type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31750] expose PyCell_Type in types module
Devin Bayer <d...@doubly.so> added the comment: Well that's true enough. My main argument is consistency. Cells and code objects together make up closures, so to manipulate closures you need both. Right now I am using a ctypes hack to modify the cells/closures, for what I consider a strategically important use-case. So I guess a type(cell) hack isn't out of place; the risk is it's fragile. So, to really make hot reloading work with no hacks I need both this and the follow-up of https://bugs.python.org/issue14369 to be implemented. Or equivalently, a python interface to make closures mutable. Honestly I don't know what your criteria are, so it's hard to make a point. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31750] expose PyCell_Type in types module
Devin Bayer <d...@doubly.so> added the comment: I have just reread those discussions and I don't see any reasoning behind omitting the cell type. It is barely mentioned. Basically, I need this type and it isn't exposed anywhere. I don't care where it is, but the only way to get it right now is a hack, for example: a = [1] def f(): return a return type(f.__closure__[0]) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31750] expose PyCell_Type in types module
New submission from Devin Bayer <d...@doubly.so>: The type of PyCell_Type is not available in the types module or anywhere else. Since this type is exposed to users it seems like it's a rather odd omission. Related issues: - https://bugs.python.org/issue2408 - https://bugs.python.org/issue1605 -- components: Library (Lib) messages: 304062 nosy: akvadrako priority: normal severity: normal status: open title: expose PyCell_Type in types module type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14369] make __closure__ writable
Devin Bayer <d...@doubly.so> added the comment: Any updates on this? I'm trying to implement hot module reloading using code from IPython, which tries to modify __closure__ in place. It fails silently and doesn't work, but indeed would be nice to have. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue14369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14369] make __closure__ writable
Change by Devin Bayer <d...@doubly.so>: -- nosy: +akvadrako ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue14369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
