Change by Cong Ma :
--
keywords: +patch
pull_requests: +23787
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25039
___
Python tracker
<https://bugs.python.org/issu
Cong Ma added the comment:
Some more context: Issue 37646. The demo in that one was "eval inside
list-comprehension-scope", while this one is the other way around.
Perhaps another example may better illustrate the interplay between eval and
the execution environment:
```
def f():
Cong Ma added the comment:
> sum(get(i) for i in range(len(l)))
This expression inside the body of ``func()`` references the name "get" and "l"
(ell), both are local to the scope introduced by ``func()``. More specifically,
these two names are referenced in
Cong Ma added the comment:
I'm preparing an update to the documentation of eval/exec. There are several
issues, but chiefly I'll link to the appropriate sections in the Language
Reference, and clean up some other inaccuracies. When it's ready I'll submit a
PR for core devs to review
Cong Ma added the comment:
> I think it is *very* reasonable to expect that calling eval() on a string
> should have the exact same effect as if the code that is inside the eval had
> been written as part of the source code.
I don't think Python's execution model is defined
Cong Ma added the comment:
> The extra macros are provided by optional packages. On Fedora and
> Debian/Ubuntu the package is called autoconf-archive.
Thank you very much. This (and the patch) is clearing things up for me a lot.
At first I thought I was supposed to copy the m4 file
Cong Ma added the comment:
I think this is in the same class of behaviours as
```
def func(l):
def get(i):
return l[i]
print(eval("(lambda x: get(x))(0)")) # Call anonymous lambda with the
constant 0 as argument
```
Calls like ``func(["spam"
Cong Ma added the comment:
>From the configure.ac file:
> dnl ***
> dnl * Please run autoreconf to test your changes! *
> dnl ***
I take it to mean "if configure.ac is changed, run
Cong Ma added the comment:
> If you consider that there is a bug, please open a new issue since you closed
> this one.
Please see the follow up in Issue 43617.
Many thanks for bearing with me.
--
___
Python tracker
<https://bugs.p
Change by Cong Ma :
--
type: -> compile error
___
Python tracker
<https://bugs.python.org/issue43617>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Cong Ma :
The problem
---
In the repository, the definition for ``AX_CHECK_COMPILE_FLAG`` in Python's
``configure.ac`` file is missing. If ``autoreconf`` is run, an invalid
``configure`` script is generated. The following is the behaviour of running
``autoreconf
Cong Ma added the comment:
BTW, do we need to fix the missing definition of the AX_CHECK_COMPILE_FLAG
macro in configure.ac? This is a separate problem, if a problem at all.
--
resolution: -> not a bug
stage: -> resolved
status: open -&g
Cong Ma added the comment:
Hello Victor,
I think you're right. This is bogus on my part. TL;DR: The Python version is
3.8 but I was trying to understand what's going on using the latest source.
Full version: I was trying to understand why the following C file when compiled
with -shared
New submission from Cong Ma :
(This is a summarized form of the commit message in the attached patch. I'm
submitting a patch instead of a PR over GitHub, because it seems that the
``autoreconf`` output files are part of the repository. In order for the
changes to take effect in the repo, I
Cong Ma added the comment:
> Idea: We could make this problem go away by making NaN a singleton.
Apart from the fact that NaN is not a specific value/object (as pointed out in
the previous message by @mark.dickinson), currently each builtin singleton
(None, True, False, etc.) in Pyt
Cong Ma added the comment:
Sorry, please ignore my rambling about "float() returning aliased object" -- in
that case the problem with hashing doesn't arise.
--
___
Python tracker
<https://bugs.python.o
Cong Ma added the comment:
Thank you @mark.dickinson for the detailed analysis.
In addition to your hypothetical usage examples, I am also trying to understand
the implications for user code.
If judging by the issues people open on GitHub like this:
https://github.com/pandas-dev/pandas
New submission from Cong Ma :
Summary: CPython hash all NaN values to 0. This guarantees worst-case behaviour
for dict if numerous existing keys are NaN. I think by hashing NaN using the
generic object (or "pointer") hash instead, the worst-case situation can be
alleviated withou
18 matches
Mail list logo
