I am gonna think about that, but all of these operators (though I think you are
calling it "confusing") are basically the equivalent of `iter(dict_object)[x]`.
So they're fast, and can also extract something from the middle of a 'dict'
object.
___
Pyth
PEP 479 introduced this idea that basically boils down to raising your
exceptions only when you mean it.
Specifically: generators only raise StopIteration when they
return/exit/terminate. And they prevent the user from raising it under
other circumstances.
Can we call this "antichecked exceptions
On Thu, Oct 14, 2021 at 8:46 AM Paul Moore wrote:
>
> ...maybe the energy focused on "making basic types easier to write"
> should be focused on making protocols easier to write, instead.
>
> Paul
>
+ a billion
Rick.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about g
On Fri, Oct 15, 2021 at 12:16 AM Steven D'Aprano wrote:
>
> On Thu, Oct 14, 2021 at 11:15:52PM +1100, Chris Angelico wrote:
> > On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
> > wrote:
> > >
> > > Results are in (tested
> > > `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and
On Thu, Oct 14, 2021 at 11:15:52PM +1100, Chris Angelico wrote:
> On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
> wrote:
> >
> > Results are in (tested
> > `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
> > `next(reverse())` counterparts):
> > `*` / `/` implemented i
On Thu, 14 Oct 2021 at 13:04, Ricky Teachey wrote:
>
> I think all of this additional syntax is just a mistake.
>
> The reason is it will encourage people to not properly annotate their input
> types for duck typing. Some of these shortcuts might be nice for output
> types. But the more general
On Thu, Oct 14, 2021 at 11:03 PM Jeremiah Vivian
wrote:
>
> Results are in (tested
> `next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
> `next(reverse())` counterparts):
> `*` / `/` implemented is 2x faster than `next(iter(d))`/`next(reversed(d))`
> `+` / `-` implemented i
I think all of this additional syntax is just a mistake.
The reason is it will encourage people to not properly annotate their input
types for duck typing. Some of these shortcuts might be nice for output
types. But the more general trying.Mapping, typing.Sequence and friends
should be preferred f
Results are in (tested
`next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
`next(reverse())` counterparts):
`*` / `/` implemented is 2x faster than `next(iter(d))`/`next(reversed(d))`
`+` / `-` implemented is approximately 3x faster than
`next(iter(d.values()))`/`next(revers
> I implemented these functions as operators in a downloaded source of CPython
And Chris is probably right, but I can't test it now at the time of writing
this reply.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email t
On Thu, Oct 14, 2021 at 08:36:37AM -, Jeremiah Vivian wrote:
> So I implemented these functions as operators in a downloaded source
> of CPython... the differences are insane! (Sorry if this produces
> nested quotes)
> > >>> import timeit
> > # d + 1 vs list(d.values())[0]: 2133x speedup
d
On Thu, Oct 14, 2021 at 7:37 PM Jeremiah Vivian
wrote:
>
> So I implemented these functions as operators in a downloaded source of
> CPython... the differences are insane! (Sorry if this produces nested quotes)
> > >>> import timeit
> > # d + 1 vs list(d.values())[0]: 2133x speedup
> > >>> timeit
I agree with Steven. I very much like Abdulla's proposed syntax for dicts,
TypedDicts and sets. But I'm not sure that the idea for `Annotated` is
workable, and the proposal for lists seems too prone to ambiguity, given how
extensively square brackets are already used in typing syntax.
One ques
Fixed reply:
So I implemented these functions as operators in CPython... the differences are
insane!
> \>\>\> import timeit
>
> # d + 1 vs list(d.values())[0]: 2133x speedup
> \>\>\> timeit.main(['-s', "d = {x: x+1 for x in range(1)}", "d + 1"])
> 200 loops, best of 5: 165 nsec per loop
>
(gonna test highlighting)
\>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.or
So I implemented these functions as operators in a downloaded source of
CPython... the differences are insane! (Sorry if this produces nested quotes)
> >>> import timeit
> # d + 1 vs list(d.values())[0]: 2133x speedup
> >>> timeit.main(['-s', "d = {x: x+1 for x in range(1)}", "d + 1"])
> 2
On Thu, Oct 14, 2021 at 12:32:57AM +0400, Abdulla Al Kathiri wrote:
> Today I found myself write a function that returns a tuple of list of
> list of strings (tuple[list[list[str]], list[list[str]]]). Wouldn’t it
> easier to read to write it like the following:
> ([[str]], [[str]])?
Not really
Now I didn't expect this thread to blow up in replies with alternatives,
specifically `str1 / str2` for 'str1.split(str2)' and `seq1 * str` for
'str.join(seq1)'.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to py
Peter Ludemann writes:
> From a mathematical point of view, x+y is equivalent to y+x,
Yes, other things being equal, mathematical purists would prefer '*'
to '+' for string concatenation *because* it's not commutative, but
they're not equal. I imagine a good majority of folks can guess what
'"
19 matches
Mail list logo
