Change by Erwan Le Pape :
--
pull_requests: +19696
pull_request: https://github.com/python/cpython/pull/20439
___
Python tracker
<https://bugs.python.org/issue34
Erwan Le Pape added the comment:
Assuming similar configuration to the one in msg343430, a simple native
getaddrinfo test to check whether any scope ID is returned.
```
#include
#include
#include
#include
void test(char *addrstr) {
int status;
struct addrinfo *res;
struct
Erwan Le Pape added the comment:
Thanks for testing that. It's good that you used an actual address because that
eliminates the possibility that AIX doesn't handle addresses it doesn't really
know about.
On the other hand, even when properly specified to a real scoped IPv6 address
Erwan Le Pape added the comment:
I don't have an AIX lying around to test so would you mind just running the
test on `getaddrinfo` for AIX. A simple `python3 -c 'import socket;
print(socket.getaddrinfo("fe80::1%1", 80))'` should fairly rapidly determine if
there is a legitim
Change by Erwan Le Pape :
--
keywords: +patch
pull_requests: +10507
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35545>
___
___
Py
Erwan Le Pape added the comment:
While the 3.7+ getaddrinfo isn't the best human representation of an IPv6
address, I believe it does make the most sense to keep it that way.
In any case, this is a regression and changing return values of getaddrinfo for
3.7 isn't something that should
Erwan Le Pape added the comment:
As mentioned by Benjamin Peterson, this is a duplicate of #34722, which already
has an implementation proposal by Peter Ebden.
While implementation specifics change, the aim is the same and #34722 is the
better solution (again, credit to Benjamin Peterson
Erwan Le Pape added the comment:
Given that marshal basically only just dumps code objects, the only viable
solution I can see is adding a flag that can be passed all the way to the AST
from `Python/bltinmodule.c:builtin_compile_impl` that would sort elements when
creating code objects
Change by Erwan Le Pape :
--
keywords: +patch
pull_requests: +8786
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34689>
___
___
Py
Erwan Le Pape added the comment:
Great! My only concern with that is marshalling of untrusted data at runtime (I
know, you shouldn't do that) can become a much more expensive operation.
Is there any internal use of marshal beyond .pycs used at runtime by the core
interpreter that might
New submission from Erwan Le Pape :
Lib/sysconfig.py _parse_makefile needs to expand Makefile-style variables which
includes `$()` `${}` variables with a litteral `$` being `$$`.
That last particular point is properly accounted for in the first half of the
function when determining values
Erwan Le Pape added the comment:
How would you suggest going about doing that?
Without the proposed option, the alternative is leaving the build process
vulnerable to environment variables potentially breaking the build process by
patching configure.ac as follows:
-PYTHON_FOR_BUILD
New submission from Erwan Le Pape :
I'm attempting to leverage PEP 552 to make the core interpreter build process
more deterministic. However, the standard Python Makefile uses `python -E` when
calling the compileall (and all other setup scripts), which forces
randomization since it can only
Erwan Le Pape added the comment:
I can confirm Eryk got what I meant. I didn't know if it was meant to work that
way or if it was simply something that was overlooked so I thought I'd ask, I
will look into the ctypes code to provide a patch sometime this week if I can.
Terry, for a working
New submission from Erwan Le Pape:
When using a custom class to store a ctype value, passing that class as a
function argument explicitly declared to be a pointer type fails to pass the
_as_parameter_ class attribute as a pointer and instead raises a TypeError.
For example:
>>> fr
15 matches
Mail list logo
