On 28/07/2020 15:33, Guido van Rossum wrote:
Rest assured this is not a problem. In any case it’s the compiler, not
the parser, that generates the bytecode, from the AST. The compiler
always has the full AST available before it is asked to generate any
bytecode. The new parser just allows
2qdxy4rzwzuui...@potatochowder.com writes:
> in order to foil suck attacks.
Typo of the Year candidate! (It was a typo, right?)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Christopher Barker writes:
> from itertools import islice
>
> smaller_dict = dict(islice(large_dict.items(), 0, 255))
>
> which works, and isn't doing an unnecessary copying but it's pretty
> darn ugly, as far as I'm concerned.
In your application, I think that's just pretty, myself.
Jonathan Fine writes:
> Sometimes a loop has multiple break commands, which have different
> purposes. So a further extension might be
> for i in items:
> LOOP_BODY
> if break left:
An if here is already valid syntax. I'm pretty sure that the parsers
can handle it. But
On Sun, Jul 26, 2020 at 4:44 AM Marco Sulla
wrote:
>
> I also remembered another possible use-case: kwargs in CPython. In C code,
> kwargs are PyDictObjects. I suppose they are usually not modified; if so,
> fdict could be used, since it seems to be faster at creation.
>
I have not confirmed
On 2020-07-28 at 15:58:58 -0700,
Christopher Barker wrote:
> But a dict always has a LOT fewer buckets than possible hash values,
> so clashes within a bucket are not so rare, so equality needs to be
> checked always -- which is what I was missing.
> And while it wouldn't break anything, having
re-awakening this thread, because I just happened on an actual real-world
use case:
I need the first 255 items in a dict, as a dict. Order is important, and I
can count on an order-preserving dict.
I ended up with:
from itertools import islice
smaller_dict = dict(islice(large_dict.items(), 0,
On Mon, Jul 27, 2020 at 5:42 PM Ethan Furman wrote:
> Chris Barker wrote:
> > Is this because it's possible, if very
> > unlikely, for ANY hash algorithm to create the same hash for two
> > different inputs? So equality always has to be checked anyway?
>
> snip
For example, if a hash algorithm
Check the thread
https://mail.python.org/archives/list/python-ideas@python.org/thread/REYDJFCXQNQG4SAWKELQMCGM77IZG47Q/#CGMWPLJME4ZZNGHDY4DGCSF347VBMAKZ
There are comments in favor of both first and one.
On Tue, Jul 28, 2020 at 3:59 PM Noam Yorav-Raphael
wrote:
> Thanks! It's good to hear that
Thanks! It's good to hear that you too find it useful.
Since adding methods to built-in types is much heavier than adding one
function to a module, l suggest keeping this discussion focused on adding
just the one() function to itertools, and see if there is enough support
for this.
Cheers,
Noam
In my personal toolbox of utility functions, this is by far the function I
use most often, although it's implemented slightly differently and I call
it `only`. I think it's very useful and it would be great to have in the
standard library to encourage people to write safer code.
Often this is
Hello,
There's a simple function that I use many times, and I think may be a good
fit to be added to itertools. A function that gets an iterator, and if it
has exactly one element returns it, and otherwise raises an exception. This
is very useful for cases where I do some sort of query that I
On Sat, Jul 25, 2020 at 12:58 PM Guido van Rossum wrote:
> On Sat, Jul 25, 2020 at 12:45 PM Marco Sulla
> wrote:
>
>> I also remembered another possible use-case: kwargs in CPython. In C
>> code, kwargs are PyDictObjects. I suppose they are usually not modified; if
>> so, fdict could be used,
I also like that one, both more intuitive than current syntax I think.
On Tue, 28 Jul 2020, 11:25 Guido van Rossum, wrote:
> On Tue, Jul 28, 2020 at 05:42 Thiago Carvalho D' Ávila <
> thiagocav...@gmail.com> wrote:
>
>> The idea here is to use the same operator already used to type-hint the
>>
Rest assured this is not a problem. In any case it’s the compiler, not the
parser, that generates the bytecode, from the AST. The compiler always has
the full AST available before it is asked to generate any bytecode. The new
parser just allows more flexible syntactic constructs, esp. “soft
On Tue, Jul 28, 2020 at 05:42 Thiago Carvalho D' Ávila <
thiagocav...@gmail.com> wrote:
> The idea here is to use the same operator already used to type-hint the
> return of functions `->` to define the return of a Callable.
>
> * Current syntax:
>
> Callable[[ArgumentList], ReturnType]
>
> eg.
>
On 2020-07-28 at 11:04:25 -0300,
"Joao S. O. Bueno" wrote:
> Anyway, that is feasible via a decorator.
> Since it can't be done the wya you are proposing as is, since
> having a function as a default argument is valid Python
> (and the function is not called) - and
> having new syntax for this
Anyway, that is feasible via a decorator.
Since it can't be done the wya you are proposing as is, since
having a function as a default argument is valid Python
(and the function is not called) - and
having new syntax for this would be more cumbersome
than using a decorator, I think that closes
Hello,
The idea here is to use the same operator already used to type-hint the
return of functions `->` to define the return of a Callable.
* Current syntax:
Callable[[ArgumentList], ReturnType]
eg.
def x(method: Callable[[int, dict], None]) -> None:
pass
* Proposed syntax:
Hi Rob
You wrote:
So: You're asking that the bytecode generated for the for-loop depends
> on something that happens (or not) after the end of the for-loop body
> (which could be arbitrarily long).
>
> I speak from ignorance, but I suspect that even with the new parser,
> which I am reliably
Thank you Rob, for your contribution. I find it very helpful. You've raised
important implementation questions.
Regarding the no-iterations case. Suppose we have
for i in items:
loop_body
case:
zero:
print('no items to process')
In this case, the Python
There's been a discussion of the "for ... else ..." construction in Python.
Here's a suggestion as to how we might improve matters, and perhaps
usefully extend the language. I hope it might benefit some, without harming
anyone else.
Aside: I've not read the whole of the previous discussion, and
22 matches
Mail list logo
