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
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
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
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 venv, "python -m" doesn't let you ensure
that the code exec
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
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, Australia
__
lts 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...@gmail.c
s-check 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
ll 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.python.org/mailman/
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
https://mail.python.org/
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
___
Python-
lly
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
___
Pyt
t_school_list))
> Out[38]: Grouping({'SchoolA': ['Fred', 'Mary'],
>'SchoolB': ['Bob', 'Jane'],
>'SchoolC': ['Nancy']})
Unpacking and repacking the tuple would also work:
Grouping(((school, student) for student, school in student_school_
ifferent 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 dict does, but
on 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 | nco
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 handling logic inter
ointed on
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 | Brisbane, Aus
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 CCall
PEP needs to refe
gt; 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 encourages it.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aus
o 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://mail.python.org/m
n 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
___
Python-ideas mai
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
___
Python-ideas mailing list
Python-ide
gt; 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 only slice.indices
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 | Brisbane, Australia
__
rs, 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-ideas mailing list
y 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 or
group permissions.
--
n 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.org
https://mai
te 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 <greg.ew...@canterbury.ac.nz> 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
xtra" 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 sees
oposals can focus 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
_
quot; to introduce 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 reason that s
gt; 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
that Ken's aware of its existence if this is a
ing 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
On 14 May 2018 at 08:24, Ed Kellett <e+python-id...@kellett.im> 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 wor
ly* overturning PEP 3099'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 consis
On 11 May 2018 at 12:45, Tim Peters <tim.pet...@gmail.com> 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
so allow "and", "or", "is",
and "as" to be freed up for use as names.
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/
aining 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 implementable (thanks!),
lues (just a little more indirectly 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/
ame nonlocal name, what to
do 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
___
Pyth
onditional 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 allow for an "
On 11 May 2018 at 07:15, Nick Coghlan <ncogh...@gmail.com> 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 out
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 how those new semantics are expected to work in *all* of the
existing s
owing
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,
Ni
On 10 May 2018 at 23:22, Guido van Rossum <gu...@python.org> wrote:
> On Thu, May 10, 2018 at 5:17 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
>> How would you expect this to work in cases where the generator expression
>> isn't immediately consumed? If "p&
esting_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 that don't
want to w
do have to repeat the 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 anyw
t kind of lazy evaluation is
to accept a zero-argument callable, which can then be used with "lambda: "
at the call site:
runtime_assert(lambda: )
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/
> def f():
... 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 nonlocal, or as local
riable 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 | ncogh...@gmail.com | Brisbane, Australia
__
object in question 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 for how verbose t
ve 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
___
Python-id
On 7 May 2018 at 14:33, Nathaniel Smith <n...@pobox.com> wrote:
> On Sun, May 6, 2018 at 8:47 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > On 7 May 2018 at 13:33, Nathaniel Smith <n...@pobox.com> wrote:
> >>
> >> Spit-balling: how about __filepa
b abstraction".
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 7 May 2018 at 12:35, Chris Angelico <ros...@gmail.com> wrote:
> On Mon, May 7, 2018 at 12:13 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > So I have a different suggestion: perhaps it might make sense to propose
> > promoting a key handful of path manipulati
On 7 May 2018 at 12:51, Nick Coghlan <ncogh...@gmail.com> 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 =
values out 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 | ncogh.
On 6 May 2018 at 02:06, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 4 May 2018 at 22:06, Nick Coghlan <ncogh...@gmail.com> 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
On 4 May 2018 at 22:06, Nick Coghlan <ncogh...@gmail.com> 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
On 5 May 2018 at 13:36, Tim Peters <tim.pet...@gmail.com> wrote:
> [Nick Coghlan <ncogh...@gmail.com>]
> > ...
> > The essence of the given clause concept would be to modify *these
> specific
> > cases* (at least initially) to allow the condition expressi
ion scope (and 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/
e 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
___
Python-ideas mailing list
Py
On 29 April 2018 at 21:24, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Apr 29, 2018 at 6:03 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > The challenge with doing this implicitly is that there's no indication
> > whatsoever that the two "e&qu
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
___
P
ot;super(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
__
azy if you don'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
current namespace, you might
instead write:
from 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
m' 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 *lot* of backwards
c
one. In both cases, 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
_
simply due
to the runime introspection benefits that it brings.
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/
lying on a higher level type like enum objects.
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/
s
actually "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 f
On 16 April 2018 at 03:45, Steve Barnes <gadgetst...@live.co.uk> 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 c
mplexity and edge cases,
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
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 __enter__ (which may be
self), not the cm directly
Indeed, https://www.python.org/dev/peps/pep-0343/#mo
On 15 April 2018 at 13:54, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Apr 15, 2018 at 1:08 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> === Target first, 'from' keyword ===
>>
>> while (value from read_next_item()) is not None: # New
>>
On 15 April 2018 at 17:12, Nick Coghlan <ncogh...@gmail.com> 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 = import
kinds of techniques could definitely
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 langua
type annotations)
=== Target first, 'from' keyword ===
while (value from read_next_item()) is not None: # New
...
Pros:
* avoids the syntactic ambiguity of "as"
* being target first provides an obvious distinction from the "as" keyword
* typically reads ni
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/
he C operand precedence 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
On 12 April 2018 at 07:28, Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>>> Frequently Raised Objections
>>>
>>
>> There needs to be a subsection here
prohibited top 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.
--
-
>
> 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 constructs can be used.
This argument will be strengthened by making the examples used in the
PEP itse
f folks having to read 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
__
)
easier to understand when it's framed as "last(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.
On 9 April 2018 at 01:01, Steven D'Aprano <st...@pearwood.info> 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 real
curdir, and os.getcwd()), 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
___
d adjust
the partial result calculations, without adding an extra result.
Other parameter names (like the "first_result" I suggested in my reply
to Guido) wouldn't have the same implications for me, so this
objection is specific to the use of "start" as the parameter name, not
to
2, 4, 7]
I'd be +1 on:
>>> list(accumulate(1, 2, 3))
[1, 3, 6]
>>> list(accumulate(1, 2, 3, first_result=0))
[0, 1, 3, 6]
>>> list(accumulate(1, 2, 3, first_result=1))
[1, 2, 4, 7]
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisb
On 8 April 2018 at 13:17, Tim Peters <tim.pet...@gmail.com> wrote:
> [Nick Coghlan <ncogh...@gmail.com>]
>> So I now think that having "start" as a parameter to one but not the
>> other, counts as a genuine API discrepancy.
>
> Genuine but minor ;-)
ast, using the prepend() approach with accumulate() not only
changes the starting value, it also changes the number of cumulative
sums produced.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Pyt
wait until Chris has a sufficiently complete
reference implementation for the revised semantics to be confident
that we can make things work the way the revised PEP proposes.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
onvincing other community contributors that it's a good way to go :)
--
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 C
using.
I don't have a particularly great alternative name to suggest, but
"defined_function" at least takes its inspiration from the "def"
keyword, and the fact that these functions are significantly better
defined than builtin ones (from a runtime introspection perspective).
ine string is significant, including the common prefix arising
from the code block indentation.
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/
complexity and overhead of the dynamic stack, then it would
be nice to be able to instead write:
with contextlib.callback(fn, *args, **kwds):
...
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-i
same result as in Py2.
Right, "ur" strings were originally taken out in Python 3.0, and then
we made the decision *not* to add them back when PEP 414 restored
other uses of the "u" prefix:
https://www.python.org/dev/peps/pep-0414/#exclusion-of-raw-unicode-literals
Cheers,
Nick.
-
1 - 100 of 592 matches
Mail list logo
