On 2021-10-16 20:31, Erik Demaine wrote:
On Sun, 17 Oct 2021, Steven D'Aprano wrote:
On Sat, Oct 16, 2021 at 11:42:49AM -0400, Erik Demaine wrote:
I guess the question is whether to define `(*it for it in its)` to mean
tuple or generator comprehension or nothing at all.
I don't see why
Even though I am just a regular user of Python, +10 for me. It makes sense and
I think I can easily teach it to people. However, (*expr for expr in its)
should be generator expression and should be allowed to have nice mirror to all
the un-packing comprehensions. It would be equivalent to:
def
On Sat, Oct 16, 2021 at 12:21 PM David Mertz, Ph.D.
wrote:
> I'm not making any claims about tuple creation speed vs. list creation on
> microbenchmarks. It might we'll be 10% faster to create a million item
> tuple than a million item list. Or maybe the opposite, I don't know.
>
The thing to
On Sun, 17 Oct 2021, Steven D'Aprano wrote:
On Sat, Oct 16, 2021 at 11:42:49AM -0400, Erik Demaine wrote:
I guess the question is whether to define `(*it for it in its)` to mean
tuple or generator comprehension or nothing at all.
I don't see why that is even a question. We don't have tuple
On Sat, Oct 16, 2021, 12:08 PM Steven D'Aprano
> unpacking in *comprehensions*.
>
> # not currently permitted
> [*s for s in ["abc", "def", "ghi"]]
>
> > Moreover, it is an anti-pattern to create large and indefinite
> sized tuples,
>
> Is it? In what way?
>
As mentioned, I clipped the
On Sat, 16 Oct 2021 at 18:01, Steven D'Aprano wrote:
>
> On Sat, Oct 16, 2021 at 02:49:42PM +0100, Paul Moore wrote:
>
> > I'd be more likely to just remove the types (the type checking
> > equivalent of `#noqa` when you don't agree with what your style
> > checker says).
>
> Type annotations are
16.10.21 17:07, Erik Demaine пише:
> Extended unpacking notation (* and **) from PEP 448 gives us great ways
> to concatenate a few iterables or dicts:
>
> ```
> (*it1, *it2, *it3) # tuple with the concatenation of three iterables
> [*it1, *it2, *it3] # list with the concatenation of three
On Sat, Oct 16, 2021 at 02:49:42PM +0100, Paul Moore wrote:
> I'd be more likely to just remove the types (the type checking
> equivalent of `#noqa` when you don't agree with what your style
> checker says).
Type annotations are still useful to the human reader, even if the type
checker is
On Sat, Oct 16, 2021 at 11:42:49AM -0400, Erik Demaine wrote:
> I guess the question is whether to define `(*it for it in its)` to mean
> tuple or generator comprehension or nothing at all.
I don't see why that is even a question. We don't have tuple
comprehensions and `(expr for x in items)`
On Sat, Oct 16, 2021 at 10:56:07AM -0400, David Mertz, Ph.D. wrote:
> POn Sat, Oct 16, 2021, 10:10 AM Erik Demaine
>
> > (*it1, *it2, *it3) # tuple with the concatenation of three iterables
> > [*it1, *it2, *it3] # list with the concatenation of three iterables
> > {*it1, *it2, *it3} # set
On Sat, Oct 16, 2021, 11:42 AM Erik Demaine
> > But the first one is much more suggestive of a generator comprehension. I
> > would want/expect it to be equivalent to itertools.chain(), not create a
> > tuple.
>
> I guess you were referring to `(*it for it in its)` (proposed notation)
> rather
>
On Sat, Oct 16, 2021 at 09:19:26AM -0400, Erik Demaine wrote:
> To me (a mathematician), the existence of this magic in def, class, import,
> etc. is a sign that this is indeed useful functionality. As a fan of
> first-class language features, it definitely makes me wonder whether it
> could
On Sat, 16 Oct 2021, David Mertz, Ph.D. wrote:
On Sat, Oct 16, 2021, 10:10 AM Erik Demaine
(*it1, *it2, *it3) # tuple with the concatenation of three
iterables
[*it1, *it2, *it3] # list with the concatenation of three
iterables
{*it1, *it2, *it3} # set with the
Erik Demaine writes:
> I propose (not for the first time) that similarly concatenating an unknown
> number of iterables or dicts should be possible via comprehensions:
>
> ```
> (*it for it in its) # tuple with the concatenation of iterables in 'its'
> [*it for it in its] # list with
POn Sat, Oct 16, 2021, 10:10 AM Erik Demaine
> (*it1, *it2, *it3) # tuple with the concatenation of three iterables
> [*it1, *it2, *it3] # list with the concatenation of three iterables
> {*it1, *it2, *it3} # set with the union of three iterables
> {**dict1, **dict2, **dict3} # dict with the
+1
I think this is a very sensible proposal and I encountered the use-cases you
mentioned several times.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Seems sensible to me. I’d write the equivalency as
for x in y: answer.extend([…x…])
On Sat, Oct 16, 2021 at 07:11 Erik Demaine wrote:
> Extended unpacking notation (* and **) from PEP 448 gives us great ways to
> concatenate a few iterables or dicts:
>
> ```
> (*it1, *it2, *it3) # tuple with
Extended unpacking notation (* and **) from PEP 448 gives us great ways to
concatenate a few iterables or dicts:
```
(*it1, *it2, *it3) # tuple with the concatenation of three iterables
[*it1, *it2, *it3] # list with the concatenation of three iterables
{*it1, *it2, *it3} # set with the
On Sat, 16 Oct 2021 at 14:07, Alex Waygood wrote:
>
> Indeed — we essentially lie to mypy about the method resolution order for
> list, dict, etc (mypy thinks that list directly inherits from
> collections.abc.MutableSequence — see the typeshed stub here:
>
On Sat, 16 Oct 2021, Steven D'Aprano wrote:
The token should preferably be:
* self-explanatory, not line-noise;
* shorter rather than longer, otherwise it is easier to just
type the target name as a string: 'x' is easier to type than
NAME_OF_ASSIGNMENT_TARGET;
* backwards compatible, which
Indeed — we essentially lie to mypy about the method resolution order for
list, dict, etc (mypy thinks that list directly inherits from
collections.abc.MutableSequence — see the typeshed stub here:
On Sat, Oct 16, 2021 at 09:54:13AM +0100, Alex Waygood wrote:
> > On 16 Oct 2021, at 06:13, Steven D'Aprano wrote:
> > Be careful about believing what you are told.
>
> Indeed, MyPy will correctly raise errors if you assign {None: []} to a
> variable annotated with dict[str, Number]. However,
Soni L. writes:
> Can we call this "antichecked exceptions"?
I don't see why not. Personally I'd prefer calling it "exception
filtering" since it's not a property of the exception, but a pattern
in the calling code. But I'm only -0 on "antichecked" and +0 on
"filtered".
> (Is this the wrong
> On 16 Oct 2021, at 06:13, Steven D'Aprano wrote:
> Be careful about believing what you are told.
Indeed, MyPy will correctly raise errors if you assign {None: []} to a variable
annotated with dict[str, Number]. However, you'll find that MyPy also raises an
error if you assign {'foo': 4} to a
24 matches
Mail list logo
