hich are probably common.
CPython has included the list->tuple conversion for lists of literals for
quite some time, and Serhiy just posted a patch to extend that to all
inline lists where it's a safe change to make:
https://bugs.python.org/issue32925
Cheers,
Nick.
--
Nick Coghlan
ynamic variable and attribute injection
code that is likely to confuse human readers in addition to confusing
static analysers.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev
//mail.python.org/pipermail/python-ideas/2018-February/049002.html) -
it's still a *long* way from being fully baked enough to make into a
concrete change proposal for 3.8+.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
https://stackoverflow.com/questions/6067839/haskell-let-where-equivalent-within-list-comprehension/6067878#6067878
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
re heavily on
discoverability arguments (since the above approach isn't obvious at all
unless you're already very familiar with the use of `memoryview`), since
the runtime benefit from avoiding the upfront cost of allocating and
initialising two memoryview objects by using a custom iterator type
an't get it in to 3.7.0a3
> next month.
>
I think this qualifies as the beta period serving its intended purpose
(i.e. reviewing and refining the behaviour of already added features,
without allowing completely new features).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | B
gt; tools just to deal with this one mailing list.
>
One useful feature in Gmail for getting the entire list out of your inbox
is the "Filter messages like this" option in the per-message drop down (it
prepopulates a new filter definition with the appropriate list headers).
Cheers,
of bugs.python.org, since the ability to report bugs against
2.7 will be removed from bpo (and all remaining 2.7-only bugs will be
closed).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Pyth
()
# As a last resort, check for lossless int conversion
return int(n) == n
Cheers,
Nick.
P.S. I've suggested "operator" as a possible location, since that's where
we put "operator.index", and it's a low level module that doesn't bring in
a
icular set of modules *doing* imports would be
much harder though, since we don't pass that information along (although
context variables would potentially give us a way to make it available
without having to redefine all the protocol APIs)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gma
On 24 March 2018 at 19:29, Nick Coghlan wrote:
> On 23 March 2018 at 02:58, Gregory Szorc wrote:
>
>> I'd like to start a discussion around practices for vendoring package
>> dependencies. I'm not sure python-dev is the appropriate venue for this
>> discussi
;& make &&
./python -m test test_ensurepip" still works. We'd also want to add docs to
the developer guide on how to update them (those docs are missing at the
moment, since the update process is just dropping the new wheel files
directly into the right place)
Cheer
of direct instantiation, while falling back to the update based
approach when combined with other classes at runtime.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
to getting
ensurepip working, since it didn't require any changes to the build process.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
f possible I'll get it in. I already have the patch written. And if it does
> get in but the consensus is that it's a bad idea, we can back it out.
Would it be feasible to define `Field.__set_name__`, and have that
call `default.__set_name__` when the latter exists, and be a no-o
On 27 March 2018 at 01:17, Eric V. Smith wrote:
> On 3/26/18 11:10 AM, Eric V. Smith wrote:
>>
>> On 3/26/18 11:08 AM, Nick Coghlan wrote:
>>>
>>> On 27 March 2018 at 00:40, Eric V. Smith wrote:
>
>
>>> Would it be feasible to define `Fiel
ending first the pickle
data, then the out-of-band memory views, and finally None as an
end-of-message marker.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https:
f[0]}'
This would probably need to be implemented as Serhiy's option 1
(generating a distinct AST node), which in turn leads to 2a: adding
extra stack manipulation opcodes in order to more closely replicate
str.format semantics.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
On 30 March 2018 at 03:33, Eric V. Smith wrote:
> On 3/29/2018 12:13 PM, Nick Coghlan wrote:
>> While more projects are starting to actively drop Python 2.x support,
>> there are also quite a few still straddling the two different
>> versions. The "rewrite to f-
s to a fully nested expression grammar
rather than hijacking the existing string tokenisation code).
I *think* that's an orthogonal concern (since it relates to the
initial parsing and AST compilation phase, rather then the code
generation and execution phase), but it's worth keeping in mind
t; bool(toggle) and bool(toggle)
False
>>> toggle and toggle
<__main__.FlipFlop object at 0x7f35293604e0>
>>> bool(toggle and toggle)
True
So the general principle is that __bool__ implementations shouldn't do
anything that will change the result o
"22.x" would risk emitting version number that
sort lexically lower than "27" in some contexts.
Since it's a "not to be resolved until after 3.9" problem regardless,
we have time to consider how we want to handle it :)
Cheers,
Nick.
--
Nick Coghlan | ncogh..
4
(although it may make sense to link from the PEP back to the docs for
usage questions, for the benefit of folks that find the PEP first).
There isn't really a universal answer, though - the closest we get to
that is the fact that we default to "No, they're not part of the
stable ABI&qu
On 10 April 2018 at 15:34, Jeroen Demeyer wrote:
> On 2018-04-08 05:17, Nick Coghlan wrote:
>>
>> Changing macro definitions doesn't break the stable ABI, as long as
>> the *old* macro expansions still do the right thing.
>
>
> To me, it looks like a bad idea
ropped from the rest of the
PEP. These remaining references to the concept just need to be cleaned
up.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
__func__ is __class__.random or
getrandbits.__func__ is not __class__.getrandbits:" (since unbound
methods go away even for builtin functions, it becomes easier to check
method identity against a baseline implementation).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
least initially) by either:
1. Listing out specific approved unambiguous use cases (i.e. if
statement conditions, while loop conditions, list comprehensions,
generation expressions)
2. Making the 3rd admonition more general by advising against using
":" for more than one purpose in the sa
[lookup])" to bypass the restriction).
So what these kinds of initial restrictions do is require that any
extra complexity be justified *in its own right*, rather than coming
along for the ride as part of proposals with motivating use cases that
only require much simpler capabilities (na
e loop-and-a-half version.
It does make the guarantee that "y is not None" harder to spot than it
is in the loop-and-a-half version, though.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev ma
in ..."), so it's harder for
the unpacking operation to get confused with other uses of commas as
separators. Similarly, in regular assignments, the unpacking target is
always either between two "=" or else from the start of the line to
the first "=".
By contrast, for as
ess it *does* know enough now to treat the
outermost comprehension as being part of the surrounding scope in
terms of where names are referenced, so it might be feasible to adapt
that logic to enable the eager binding you're describing).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmai
expressions is causing problems,
then it's also complex enough that it's reasonable to require
extracting the algorithm into a named generator function in order to
access assignment statements.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
get the same kind of
scope, there isn't enough new expressiveness introduced by the latter
to justify the syntactic complexity of adding it).
Cheers,
Nick.
P.S. While I'm not planning to work on it myself anytime soon, I think
the sublocal scoping semantics proposed in earlier
ant of PEP 3150's given clause), and then
only propose "expression level name binding with implicit sublocal
scopes" after the semantics of sublocal scoping were already
established elsewhere.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
uot;name = alias = value" could end up
matching "alias := name := value"
(Even in earlier versions, you can illustrate the same assignment
ordering behaviour with the enum module, and there it makes even more
of a difference, as it affects which name binding is considered the
canoni
P to move even the
evaluation of the outermost iterable inside the implicitly nested
scope, rather than leaving it outside the way it is now.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-De
the current "binds the name in the surrounding scope"
semantics when assignment expressions are used in the outermost
iterable in a comprehension.
However, resolving that question *could* be postponed more simply by
making that a SyntaxError, rather than trying to move the expression
ev
from traditional
assignments and limits the potential for obviously unwanted side
effects like accidentally clobbering a name that's already in use, it
also sidesteps a lot of these quirky name resolution issues that arise
when you use full local name bindings.
--
Nick Coghlan | ncogh...@gmail.co
d
"yield from" in the outermost iterable - it's because the restriction
only applies to the implicitly nested scope).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Pytho
(If that's the problem, it would affect all versions of Python equally though).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
s as a shareable link. In this
case:
https://python.zulipchat.com/#narrow/stream/116410-zulip/topic/Sign.20up
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
'm +1 on the proposed
changes (the PEP's been through a number of earlier rounds of
discussion on import-sig, and my feedback from those has already been
incorporated into the current version).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
easonable inline pronunciation of "is=" would
still be Davids suggestion of "is bound to":
"if diff is bound to ex minux ex-base and is true and g is bound
to the gcd of diff and n and is greater than 1, then return g"
Simplifying "is bound to" to "
is *not* allowed to mask names in the current
> local scope.
While I agree this would be unambiguous to a computer, I think for
most humans it would be experienced as a confusing set of arcane and
arbitrary rules about what "=" means in Python.
C
On 24 April 2018 at 23:50, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote:
>> On 24 April 2018 at 23:38, Yury Selivanov wrote:
>>> I propose to use the following syntax for assignment expressions:
>>>
>>> ( NAME = expr )
(like people learn everything in coding).
Except that they'll also find other discrepancies like:
a = 1
a = 2
being OK, while:
a = 1
(a = 2)
fails with SyntaxError on the second line.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
s* a syntax error, and
you have to resolve the ambiguity in intent explicitly by either
adding a second "=" (to request equality comparison), or else some
other leading symbol (to request a binding expression).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Au
On 25 April 2018 at 01:35, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 11:31 AM, Nick Coghlan wrote:
>> I *do* think the "no name rebinding except in a while loop header"
>> restriction would be annoying for the if/elif use case and the while
>> use case:
&
_rhs) is _rhs and target is _rhs
It's the restriction to single names as targets that makes it possible
to impose such a strong assertion about what the syntax means.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
odule lookup chain gets an AttributeError.
The proposed name binding expressions aren't like that - they really
are just an ordinary binding of the result of the given expression to
the given name.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 25 April 2018 at 13:56, Guido van Rossum wrote:
> On Tue, Apr 24, 2018 at 8:24 PM, Nick Coghlan wrote:
>>
>> I also think it would be good for the PEP to spell out the following
>> semantic invariant for code running in a regular namespace:
>>
>> _rhs = e
rresponding values.
That would qualify as a reasonable request for improvement in Python
3.8 :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
tions with side effects, so the folks
asking that this be seen as a major complexity increase for expression
level semantics have an entirely valid point. The PEP aims to address
that point by saying "Don't use binding expressions when the order of
evaluation would be ambiguous", but
ss, we should generalize it to be the "parent" of the function:
> either the class or the module.
PEP 487 refers to this as the "owner" of a descriptor (See the
"__set_name__" example implementation in
https://www.python.org/dev/peps/pep-0487/#trait-descriptors ).
C
to look at would be PEP 3000 (the process doc), PEP 3100 (accepted
changes that didn't get their own PEPs), and PEP 3099 (explicitly
rejected ideas that also didn't get their own PEPs).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
x27;s not a rhetorical question -- maybe I have missed something.)
>
Data classes rely on the presence of annotations to spot field declarations
(it mostly doesn't care what those annotations actually say, but it does
need them to be present in order to create the list of field names).
Chee
ece for doing that would be to define how we'd want a
`py` launcher to work on *nix systems, and then provide that as part of
CPython 3.8+ (and potentially backport it to a 3.7x maintenance release).
Cheers,
Nick.
P.S. Note that on Windows, `py` always refers specifically to the launcher
#x27;t been able to get much real traction with the
"py-for-Unix-like-systems" idea, since it wasn't clear what problem, if
any, it would solve at the *distro* level. However, we may have more luck
if we're able to position it as a more forward-compatible replacement for
explic
taling about a different issue,
> i.e. using a different symbol to rebind names in an outer scope.
>
Right, and that's also noted again in the accepted PEP which introduced
"nonlocal" declarations:
https://www.python.org/dev/peps/pep-3104/#rebinding-operator
Cheers,
Nick.
o
the PEP, since it helps highlights the cases where the recommendations
*have* changed, which can be helpful for folks that were already familiar
with the older versions)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
e 3rd goal, which is the one that answers your other
questions: to allow 3rd party extension modules access to the hot paths in
CPython that are currently restricted to true built-in and Python native
functions (without making those hot paths measurably slower).
Cheers,
Nick.
-
ng reference counting on the Rust side, but it's a lot easier to avoid
than it is in runtimes with mandatory GC.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
ht
interpreter binary, regardless of whether those were standard
library modules or not).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
things *much* closer to parity, and running embedded bytecode instead of
accessing the C API directly should avoid the limitations that exist for
classes defined in C.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
ode. Without that ability to
trace from compiled code back to the preferred source form for editing,
making sense of an otherwise straightforward traceback can become a complex
debugging exercise.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
c's in 3.7, they'd be something you had
to explicitly request via a compileall invocation. In the Linux distro use
case then, the relevant distro packaging helper scripts and macros could
generate traditional cross-platform pyc files for no-arch packages, but
automatically switch to the load-
fers 100% backwards compatibility
> for the classes and for the inspect functions.
>
Thanks for this update Jeroen! If it doesn't come up otherwise, I'll try to
claim one of the lightning talk slots at the Language Summit to discuss
this with folks in person :)
Cheers,
Nick.
--
N
d decide to
repeat the language moratorium, we could co-announce it with the Python 3.7
release.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python
protocol may have for the recommendations that we
should be giving to new (and existing!) developers that don't need to worry
about Python 2.7 compatibility.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Pyt
s warranted, but
I'm now satisfied the semantics can be well specified in a way that allows
us to retain the explanation of generator expressions and comprehensions in
terms of their statement level counterparts (with the added bonus of making
"__class__" a little less of a magically un
just thought we wanted because we were used to the way the Python 2
text model worked (or failed to work, as the case may be). (The build time
source code translation step was also far less effective than we hoped it
was going to be, since we completely failed to account for the problem of
mappin
an it
adds" is typically a point strongly in favour of a particular change.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
future of the Python programming
language.
If folks get more feedback than they have the ability to process in a short
amount of time, then "Deferred" is a perfectly reasonable state to put a
PEP into until they *do* have time to go through and account for the
feedback - it isn't like
f yet...)
>
For data structure wonks,
http://eagain.net/articles/git-for-computer-scientists/ can be more
informative than any number of git usage guides :)
The mapping from command line incantations to their effect on the DAG can
be a little (*cough*) obscure, but having the right mental m
additional
testing that only happens post-merge anyway.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
ublic struct
definition in a public header - even though the macros for working with it
are marked as private, the struct itself isn't.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
base than Mac OS X, since the latter is regularly different enough
from other *nix systems that we need to give it dedicated code paths.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
SecureTransport API on Mac OS X.
So yeah, unless someone from PyCA chimes in to say that the PEP still
offers benefits that we can't get another way, withdrawing PEP 546 as
"Overtaken by events" probably makes sense.
Cheers,
Nick.
--
mated that it can be a release
checklist item in PEP 101.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
entives based on
the prevailing technology landscape than I am in my ability to predict the
actions of a VC firm like Andreesen Horowitz :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Py
= 1
exec(compile('print([x+i for i in range(1,3)])', 'MyTest', 'exec'),
locals())
explicit_local_namespace()
(Note: you'll then need to use collections.ChainMap instead of separate
locals and globals namespaces if you want the exec'ed code
X.Y releases for some time
before that)
[6] https://pypi.org/project/SIP/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubs
lt;https://developer.github.com/v3/migrations/orgs/> to download archived
> GitHub data of CPython. Ernest is helping us get set up with daily backups
> of CPython repo to be stored within The PSF's infrastructure.
>
Nice!
Cheers,
Nick.
--
Nick Coghlan
ty project build
matrices to instead be "wheel-per-target-platform".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo
On 14 June 2018 at 06:30, Ronald Oussoren wrote:
> On 13 Jun 2018, at 15:42, Nick Coghlan wrote:
>
> Yeah, pretty much - once we can get to the point where it's routine for
> folks to be building "abiX" or "abiXY" wheels (with the latter not actually
> be
gt; Another advantage is that it's more general and easier for existing classes
> to use the protocol (PEP 575 on the other hand requires subclassing from
> base_function which may not be compatible with an existing class hierarchy).
Ah, this looks *very* nice :)
Cheers,
N
from the situation with object constructors,
where a whole lot of applications will get to the point of having a
relatively stable working set of objects, and then see the rate of
object creation slow down markedly.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aus
new.
I was going to ask a question here about JSON parsing
micro-benchmarks, but then I went back and re-read
https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html
and realised that the main problem discussed in that article was the
*memory* overhead of creating full Python
; data.__len__()
Traceback (most recent call last):
File "", line 1, in
OverflowError: Python int too large to convert to C ssize_t
Infinite sequences that want to prevent infinite loops or unbounded
memory consumption in consumers may also choose to implement a
__length_hint__ that throws
ries to use the window between PEP 561
being accepted, and the related permissions being enforced in PyPI to
squat on stubs-related project names, then PEP 541 provides a
mechanism for addressing that.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
ted function equivalent.
Cheers,
Nick.
[1] From
https://docs.python.org/3.0/reference/expressions.html#displays-for-lists-sets-and-dictionaries:
'Note that the comprehension is executed in a separate scope, so names
assigned to in the target list don’t “leak” in the enclosing scope.'
uch a need did arise in the future, the "py.typed" marker
file and the different file extension for stub files within a package
still gives us an enormous amount of design flexibility
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 23 June 2018 at 09:06, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> x:= f():" implies "x" is already defined as a target somewhere else in
>> the current scope, while "if x := f() given x:" potentially introduces
>> "x" as a new lo
On 23 June 2018 at 13:48, Steven D'Aprano wrote:
> On Sat, Jun 23, 2018 at 12:22:33AM +1000, Nick Coghlan wrote:
> [...]
>> plenty of
>> functional-language-inspired documentation to instead encourage folks
>> to view comprehensions as tightly encapsulated declarat
On 24 June 2018 at 15:56, Steven D'Aprano wrote:
> On Sun, Jun 24, 2018 at 02:33:59PM +1000, Nick Coghlan wrote:
>
>> Given that PEP 572 *is* proposing implicit comprehension state export,
>
> "Implicit" and "explicit" are two terms which often get mi
On 24 June 2018 at 16:53, Chris Angelico wrote:
> On Sun, Jun 24, 2018 at 4:33 PM, Nick Coghlan wrote:
>> On 24 June 2018 at 15:56, Steven D'Aprano wrote:
>>> On Sun, Jun 24, 2018 at 02:33:59PM +1000, Nick Coghlan wrote:
>>>
>>>> Given that PEP 572
e result of how
assignment expressions were defined, rather than only showing up in
how they interacted with other scoping design decisions made years
ago.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-
sn't the parent local scoping, or even the assignment expression,
that's at fault there, since you'd get exactly the same exception for:
def outer(x=1):
def middle():
x = x +1
return x
return middle()
Cheers,
Nick.
--
Nick Coghlan |
On 25 June 2018 at 22:17, Nick Coghlan wrote:
> FWIW, the most cryptic parent local scoping related exception I've
> been able to devise so far still exhibits PEP 572's desired "Omitting
> the comprehension scope entirely would give you the same name lookup
> behaviour&
rence from previous iterations of the "given" idea is
that it doesn't try to completely replace the proposed inline
assignments, it just supplements them by providing a way to do inline
name *declarations* (which may include declaring targets as global or
nonlocal, just as regular fun
601 - 700 of 6587 matches
Mail list logo
