[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:

[issue17050] argparse.REMAINDER doesn't work as first argument

Change by Devin Bayer : -- nosy: +akvadrako ___ Python tracker <https://bugs.python.org/issue17050> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17050] argparse.REMAINDER doesn't work as first argument

Devin Bayer added the comment: Can we at least document that argparse.REMAINDER cannot be used as the first argument? -- ___ Python tracker <https://bugs.python.org/issue17

[issue17050] argparse.REMAINDER doesn't work as first argument

Devin Bayer 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 <https://bugs.python.org/is

[issue17050] argparse.REMAINDER doesn't work as first argument

Devin Bayer 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 firs

[issue17050] argparse.REMAINDER doesn't work as first argument

Devin Bayer 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.

[issue17050] argparse.REMAINDER doesn't work as first argument

Change by Devin Bayer : -- nosy: -akvadrako ___ Python tracker <https://bugs.python.org/issue17050> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14369] make __closure__ writable

Change by Devin Bayer : -- nosy: +akvadrako ___ Python tracker <https://bugs.python.org/issue14369> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14369] make __closure__ writable

Devin Bayer 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 ni

[issue31750] expose PyCell_Type in types module

New submission from Devin Bayer : 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/issu

[issue31750] expose PyCell_Type in types module

Devin Bayer 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

[issue31750] expose PyCell_Type in types module

Devin Bayer 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 impo

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

New submission from Devin Bayer : 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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

Change by Devin Bayer : -- keywords: +patch pull_requests: +3941 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31772> ___ ___ Python-

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

Devin Bayer 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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

Devin Bayer 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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

Devin Bayer 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 &

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

Devin Bayer 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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

Devin Bayer 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