On Tue, 6 Jul 2021, 7:56 am Jim Baker, wrote:
>
>
> On Mon, Jul 5, 2021, 2:40 PM Guido van Rossum wrote:
>
>> FWIW, we could make f-strings properly nest too, like you are proposing
>> for backticks. It's just that we'd have to change the lexer. But it would
>> not be any harder than would be f
On Fri, 2 Jul 2021, 5:12 pm Thomas Güttler, wrote:
> Hi Nick and all other Python ideas friends,
>
> yes, you are right. There is not much difference between PEP-501 or my
> proposal.
>
> One argument why I would like to prefer backticks:
>
> Some IDEs detect that you want to use a f-string autom
Stephen J. Turnbull wrote:
> But a
> PEP 501 i-string "just works" nicely:
> load_warning = i'Load is too high: {load}'
> while (theres_work_to_do_matey):
> if load > max_load:
> logging.warn(load_warning)
> (This assumes a future version of logging.warn that calls str() on
bian didn't put the user's local bin directory on the
system path by default, so commands provided by user level package
installs didn't work without the user adjusting their PATH. The
CPython Windows installer also doesn't adjust PATH by default (for
good reasons). And unlike a
C. Titus Brown wrote:
> put it in the current dev guide somewhere, just so it lands in version
> control.
> Then iterate on both it and the dev guide. My first thought would be to merge
> the content
> with this document,
> https://github.com/python/devguide/blob/master/langchanges.rst.
This op
locality.html and the rest of that site provide
some good info on the kinds of problems that "action at a distance"
effects, like monkeypatching class definitions, can cause in a code
base.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
thinking
about it further now given a per-interpreter locking model, I suspect
there could be some wonderful opportunities for cross-interpreter
deadlocks that we didn't consider in our initial design sketch...)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aust
that results in name sprawl ("But now I have 15 defaults to
export!"), then I take it as a hint that I may not be modeling my data
correctly, and am missing a class definition or two somewhere.
Cheers,
Nick.
--
Nick Coghlan | ncogh.
on the accuracy of
student implementations).
And in the intmath case, there are likely to be more opportunities to
delete private implementations from other standard library modules in
favour of the public intmath functions.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, A
threads that
store all persistent state in memory mapped files, or otherwise
outside the current process).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail
protocol that allows for out-of-band data sharing to avoid
redundant memory copies: https://www.python.org/dev/peps/pep-0574/
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
the part
of the source code responsible for any error messages you're seeing,
and try to work out if there's a setting you can tweak to avoid
hitting that code path.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
o we support building them as statically
linked builtin modules instead (we just don't do it routinely, because
we don't have any great desire to make the main executable even larger
than it already is).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
('Nancy', 'SchoolC'),
> ...:]
>
> In [38]: Grouping(((item[1], item[0]) for item in student_school_list))
> Out[38]: Grouping({'SchoolA': ['Fred', 'Mary'],
>'Sc
mpletely different backend storage model.
> But I still think it is much better off as a helper function in itertools.
I thought we actually had an open enhancement proposal for adding a
"defaultdict.freeze" operation that switched it over to raising
KeyError the same way a normal
tion
management support depend on which version of Python you were using
seems like it would be mostly a source of pain rather than beneficial.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
")
>>>> len(tree2.tolist())
5
Alternatively, you could explore mimicking the way that scikit-learn
saves its trained models (which I believe is a variation on "use
pickle", but I've never actually gone and checked for sure).
Cheers,
Nick.
--
Nick Coghlan
lass instances and the
behaviour of class methods on classes themselves.
So I don't think this is a huge gain in expressiveness, but I do think
it's a low cost consistency improvement that should make it easier to
start unifying more of the descriptor
n
that front :)
(While object creation overhead certainly isn't trivial, the
interpreter's already pretty aggressive about repurposing previously
allocated and initialised memory for new instances)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Bri
you
publish the first draft of your CCall protocol PEP, so that the two
PEPs get assigned consecutive numbers (it doesn't really matter if
they're non-consecutive, but at the same time, I don't think there's
any specific urgency in getting this one published before the CCa
already do that today
as:
>>> import psycopg2 as pg
>>> import psycopg2.extensions
>>> pg.ex = pg.extensions
Monkeypatching other modules at runtime is a questionable enough practice
that we're unlikely to add syntax that actively encoura
ent idea to me (and may actually help the
What's New section supplant the PEP in search results).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://ma
foundered.
PEP 572 arose from Chris deciding to take on the challenge of seriously
asking the question "Well, what if we *did* allow capturing of arbitrary
subexpressions with inline assignments?".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
to close that loophole, the
application should already have the ability to enforce everything else that
it wants to enforce via the existing event loop and event loop policy APIs.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>>> class MyContainer:
... def __getitem__(self, key):
... return key
...
>>> mc = MyContainer()
>>> mc[:bool]
slice(None, , None)
>>> mc[bool:]
slice(, None, None)
>>> mc[list:tuple:range]
slice(, , )
It's onl
out the code you're currently looking at (if anything,
we've been pushing more in the other direction: encouraging the use of
features like checked type hints to better *enable* reasoning locally about
a piece of code).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
xception handlers, although that still sticks to the
principle that exception handler checks solely consider the exception type,
not its value: https://bugs.python.org/issue12029
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python
ortability challenges arising from expecting
the chown and chmod commands to be available.
Cheers,
Nick.
[1] os.chown and shutil.chown don't exist at all there, and os.chmod only
supports setting a file to read-only - there isn't any access to user o
ot;
section of the What's New guide, with the fix being to switch to "import
errno" in any affected code.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.
e state of the disk.
shutil.rmtree fortunately provides some good precedent there, but it does
mean this feature would need to be implemented as its own API, rather than
as an option on shutil.chown.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 28 May 2018 at 10:17, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Aye, while I still don't want comprehensions to implicitly create new
>> locals in their parent scope, I've come around on the utility of letting
>> inline assignment targets be implicitly
; parens are needed, so
> added 'em anyway to make grouping clear.
>
I think the parens would technically be optional (as in PEP 572), since
"EXPR for" isn't legal syntax outside parentheses/brackets/braces, so the
parser would terminate the assignment expression when it see
on what they're proposing to
change and why, without each needing to include all the background details
regarding the specifics of the current situation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-
;
> But how are newer languages solving the problem today? Believe Ryan
> brought
> this up first on the list, but it had been in the back of my mind as well.
> Finally have compiled my research, corrections welcome.
Thank you for compiling this! It's a very useful point of referen
ntroduce a coroutine, and "await EXPR" was only permitted inside
coroutine definitions).
We also run into the problem that even when the compiler can tell the
difference, *humans* are still likely to be confused by the potential
ambiguity (for the same reas
r recursive format
> specs. There's no mechanism for having braces that aren't inspected by the
> f-string machinery.
https://www.python.org/dev/peps/pep-0536/ also seems worth noting (I don't
actually understand the specifics of that PEP myself, just making sure
tha
outer scopes. By contrast, if the implicit access to outer
scopes is limited to inline scopes accessing their containing scope, then
this example becomes precisely analagous to the current syntax error for
binding a name as a local before declaring it as global or nonlocal. The
statement of ambiguity would arise from the fact that when we see "TARGET
:= EXPR" at statement level, we don't know if the missing prior statement
is a local variable assignment, a type declaration, or a global or nonlocal
declaration)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On 14 May 2018 at 08:24, Ed Kellett wrote:
> On 2018-05-14 05:02, Nick Coghlan wrote:
> > The same grammar adjustment that I believe will allow "given" to be used
> as
> > both a postfix keyword and as a regular name would also work for "where".
> &g
#x27;s rejection of the idea of
using "NAME := EXPR" to imply "nonlocal NAME" at function scope, but that's
effectively on the table for implicit functions anyway (and I'd prefer to
have ":=" be consistent everywhere, rather than having to special case the
impl
On 11 May 2018 at 12:45, Tim Peters wrote:
> [Nick Coghlan]
> > I've been thinking about this problem, and I think for the If/elif/while
> > cases it's actually possible to allow the "binding is the same as the
> > condition" case to be simplified to
I do like the
idea of separating out "postfix keywords", which can't start a statement or
expression, and hence can be used *unambiguously* as names everywhere that
names are allowed.
Adding such a capability is essential to proposing a keyword based approach
to inline assignment
in the containing block,
> where it inherits that block's `global` or `nonlocal` declaration if
> one exists, else establishes that the target is local to that block.
> """
>
This is getting pretty close to being precise enough to be at least
potentially implementa
irectly than would
be the case for assignment expressions)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
o with nested comprehensions, how to expand comprehensions using this kind
of scoping to their statement form in a context independent way).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing
could be made to conditional expressions (adjusting
their grammar to permit "EXPR if NAME = EXPR else EXPR") and filter clauses
in comprehensions (allowing "EXPR for TARGET in EXPR if NAME = EXPR"). In
essence, "if", "elif", and "while" would all
On 11 May 2018 at 07:15, Nick Coghlan wrote:
> * *maybe* discover that even the above expansion isn't quite accurate, and
> that the underlying semantic equivalent is actually this (one way to
> discover this by accident is to have a name error in the outermost iterabl
; compiler declaration to
explicitly request those semantics for bound names (allowing the expansions
of comprehensions and generator expressions as explicitly nested functions
to be adjusted accordingly).
But the PEP will need to state explicitly that that's what it is doing, and
fully specify
nd name shadowing
without explicit name aliasing and del statements), it's something else
entirely to do it for the sake of purely cosmetic tweaks like flattening
the occasional nested if-else chain or replacing a loop-and-a-half with an
embedded assignment.
Regards,
Nick.
--
Nick Coghlan
On 10 May 2018 at 23:22, Guido van Rossum wrote:
> On Thu, May 10, 2018 at 5:17 AM, Nick Coghlan wrote:
>
>> How would you expect this to work in cases where the generator expression
>> isn't immediately consumed? If "p" is nonlocal (or global) by default, then
resting_coords = [x, y for x in related_x_coord(x,
y) if is_interesting(y := f(x))]
Deliberately reintroducing stateful side effects into a nominally
functional construct seems like a recipe for significant confusion, even if
there are some cases where it might arguably be useful to folks th
e bound name at least once, you gain a much
clearer order of execution (while it's an order of execution that's
right-to-left rather than left-to-right, "rightmost expression first" is
the normal way assignments get evaluated anyway).
Cheers,
Nick.
--
Nick Coghlan | ncogh...
zation discusses the
"logging.isEnabledFor" API, and how it can be used to avoid the overhead of
expensive state queries when the result log message would just be discarded
anyway.
Generally speaking though, the spelling for that kind of lazy evaluation is
to accept a zero-argument call
. global x
... nonlocal x
... x = 1
...
File "", line 2
SyntaxError: name 'x' is nonlocal and global
Since using a name as a binding target *and* as the iteration variable
would effectively be declaring it as both local and non
treatment where it could be allowed as a variable name in a
non-operator context (since we don't allow two adjacent expressions to
imply a function call, it's only prefix keywords that have to be disallowed
as names to avoid ambiguity in the parser).
Cheers,
Nick.
--
Nick Coghlan
stion is a `pathlib.Path` instance).
Your original point is still valid though: given the boilerplate reduction
already available via "from pathlib import Path; _this_dir =
Path(__file__).parent", it's the pathlib version that needs to be taken as
the baseline
erhead, it doesn't remove it.
>
That's fine - it's not uncommon for folks looking to minimise startup
overhead to have to opt in to using a lower level API for exactly that
reason.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 7 May 2018 at 14:33, Nathaniel Smith wrote:
> On Sun, May 6, 2018 at 8:47 PM, Nick Coghlan wrote:
> > On 7 May 2018 at 13:33, Nathaniel Smith wrote:
> >>
> >> Spit-balling: how about __filepath__ as a
> >> lazily-created-on-first-access pathlib.Path(__
nce
6.5 of those milliseconds are from importing fnmatch), I think there's also
a legitimate argument for a two tier system here, where we say "If you
can't handle your filesystem manipulation task with just open, dirname,
abspath, and joinpath, then reach for the higher level pathli
as nonlocal in the nested scope, so our
rem and p point to the last bound value
I don't really like that though, since it doesn't read as nicely as being
able to put the nonlocal declaration inline.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 7 May 2018 at 12:35, Chris Angelico wrote:
> On Mon, May 7, 2018 at 12:13 PM, Nick Coghlan wrote:
> > So I have a different suggestion: perhaps it might make sense to propose
> > promoting a key handful of path manipulation operations to the status of
> > being builtins?
On 7 May 2018 at 12:51, Nick Coghlan wrote:
> If any other form of comprehension level name binding does eventually get
> accepted, then inline scope declarations could similarly be used to hoist
> values out into the surrounding scope:
>
> rem = None
> while
into the surrounding scope:
rem = None
while any((nonlocal rem := n % p) for nonlocal p in small_primes):
# p and rem were declared as nonlocal in the nested scope, so
our rem and p point to the last bound value
Cheers,
Nick.
--
Nick Coghlan |
x27;d still need to import pathlib or os.path for more complex path
manipulations, but they generally wouldn't be needed any more if all you're
doing is reading and/or writing a handful of specific files.
Cheers,
Nick.
[1] abspath can stand in for os.getcwd(), since you can spell the latter
indirectly, as in the hypothesis API usage), which
is exactly the meaning we're interested in here.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On 6 May 2018 at 02:06, Nick Coghlan wrote:
> On 4 May 2018 at 22:06, Nick Coghlan wrote:
>
>> (Note: Guido's already told me off-list that he doesn't like the way this
>> spelling reads, but I wanted to share it anyway since it addresses one of
>> the
On 4 May 2018 at 22:06, Nick Coghlan wrote:
> (Note: Guido's already told me off-list that he doesn't like the way this
> spelling reads, but I wanted to share it anyway since it addresses one of
> the recurring requests in the PEP 572 discussions for a more targeted
>
On 5 May 2018 at 13:36, Tim Peters wrote:
> [Nick Coghlan ]
> > ...
> > The essence of the given clause concept would be to modify *these
> specific
> > cases* (at least initially) to allow the condition expression to be
> followed
> > by an inline assignment,
assuming PEP 558 is eventually accepted, will some
day reliably *never* work)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
h" for a purpose along these lines, which runs into a different
set of problems related to trying to use "with" for two distinct and
entirely unrelated purposes).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
gt;> a = b'hovercraft'
> >>> int.from_bytes(a, 'big')
> 493182234161465432041076
>
It's also worth noting that if there's more than one integer of interest in
the string, than using the struct module is often going to be better than
using multipl
On 29 April 2018 at 21:24, Chris Angelico wrote:
> On Sun, Apr 29, 2018 at 6:03 PM, Nick Coghlan wrote:
> > The challenge with doing this implicitly is that there's no indication
> > whatsoever that the two "e"'s are different, especially given the
> > l
wouldn't be possible
for code compiled in "single" mode, although working out a suitable
relationship between sublocal scoping and the interactive prompt is likely
to prove tricky no matter what)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
you or someone else has previously run "import
package.submodule" (or an equivalent)
The current attribute error is cryptic (and not always raised if some other
module has already done the import!), so trying the submodule import
implicitly would also provide an opportunity to customise
er(name_of_first_param, __class__)". And
even that limited bit of magic has proven quirky enough to be a recurring
source of irritation when it comes to interpreter maintenance.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
't explicitly import them - you'd only be
*required* to explicitly import top level modules, with everything
under that being an implementation detail of that top level package)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
om pkg import .mod1, .mod2, .mod3
to only bind "pkg" locally, but still make sure "pkg.mod1", "pkg.mod2"
and "pkg.mod3" all resolve at import time.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
7;Enum' is not JSON serializable
The mixin variants basically say "If you run into code that doesn't
natively understand enums, act like an instance of this type".
Since most of the standard library has been around for years, and
sometimes even decades, we tend to face a
es, importing "types" and
"_collections" accounted for around a 3rd of the time, with the bulk
of the execution time being enum's own module level code.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
could potentially be
made for converting some of the inspect module state introspection
APIs over to StringEnum, so it was easier to iterate over the valid
states in a consistent way, but even there I'd need to see a concrete
proposal before I made up my mind).
Making the case for IntEnum us
).
At a less philosophical level, many of the cases where we use magic
strings are in code that has to work even when the import system isn't
working yet - that's relatively straightforward to achieve when the
code is only relying on strings with particular contents, but *much*
harder if t
"with subexpr as target".
So the main concern around "with (name as expr)" is with human readers
getting confused, not the compiler, as we can tell the latter to
implement whichever semantics we decide we want, while humans are far
less tractable :)
Cheers,
Nick.
--
Nick C
On 16 April 2018 at 03:45, Steve Barnes wrote:
> On 15/04/2018 08:12, Nick Coghlan wrote:
>> The discoverability of these kinds of techniques could definitely
>> stand to be improved, but the benefit of adopting them is that they
>> work on all currently supported ver
s,
if you mess it up you can cause significant data loss, and anyone that
already knows they need atomic rewrites is likely to be able to come
up with their own purpose specific implementation in less time than it
would take them to assess the suitability of 3rd party alternatives).
Cheers,
Ni
as name": also prevents "modname"
getting bound in the current scope the way it normally would
* "except exc_filter as exc": binds the caught exception, not the
exception filter
* "with cm as name": binds the result of
On 15 April 2018 at 13:54, Chris Angelico wrote:
> On Sun, Apr 15, 2018 at 1:08 PM, Nick Coghlan wrote:
>> === Target first, 'from' keyword ===
>>
>> while (value from read_next_item()) is not None: # New
>> ...
>>
>> Pros
On 15 April 2018 at 17:12, Nick Coghlan wrote:
> If you want to do this dynamically relative to the current module,
> then it's possible to do:
>
> global __path__
> __path__[:] = (some_directory, some_other_directory)
> custom_mod = importlib.import_module(&q
initely
stand to be improved, but the benefit of adopting them is that they
work on all currently supported versions of Python (even
importlib.import_module exists in Python 2.7 as a convenience wrapper
around __import__), rather than needing to wait for new language level
syntax for them.
when combined with
other uses of ":" as a syntactic marker (e.g. slices, dict key/value
pairs, lambda expressions, type annotations)
=== Target first, 'from' keyword ===
while (value from read_next_item()) is not None: # New
...
Pros:
* avoids the syntactic ambi
on model,
and the import emulation recipe doesn't is intended as a hint :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
unambigous in with statement headers
with create_cm() -> cm as enter_result:
...
(Pronunciation-wise, if we went with that option, I'd probably
pronounce "->" as "as" most of the time, but there are some cases like
the "while" exa
ence table memorized, and there isn't
any simple way for my text editor to help me out).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.or
On 12 April 2018 at 07:28, Chris Angelico wrote:
> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan wrote:
>>> Frequently Raised Objections
>>>
>>
>> There needs to be a subsection here regarding the need to call `del`
>> at class
op level name binding
expressions in with statements: "with (expr as name):" and "with expr
as name:" were far too different semantically for the only syntactic
difference to be a surrounding set of parentheses.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | B
s at those scopes.
> This could be used to create ugly code!
> ---
>
> So can anything else. This is a tool, and it is up to the programmer to use
> it
> where it makes sense, and not use it where superior construct
or an alternate
pyc compiler frontend like Hylang could use it to provide relevant
references back to the original source code (JavaScript's source maps
may provide inspiration on that front).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
20 bytes to see the
new signature byte (which shouldn't be a problem, given that file
defaults to reading up to 1 MiB from files it is trying to identify).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python
(accumulate(iterable,
binop, initial=value)))".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On 9 April 2018 at 01:01, Steven D'Aprano wrote:
> On Sun, Apr 08, 2018 at 09:25:33PM +1000, Nick Coghlan wrote:
>
>> I was writing a new stdlib test case today, and thinking about how I
>> might structure it differently in a PEP 572 world, and realised that a
>> situ
cwd()), and
it occurred to me that a version of PEP 572 that omits the sublocal
scoping concept will allow inline naming of parts of data structures
as you define them.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Pyth
irritating, especially when
demonstrating behaviour at the interactive prompt.
Being able to reliably exhaust an iterator with "last(iterable)" or
"itertools.last(iterable)" would be a nice reduction function to
offer, in addition to our existing complement of builtin reducers
1 - 100 of 708 matches
Mail list logo
