On Tue, 17 Nov 2020 at 22:35, Paul Moore wrote:
>
> On Tue, 17 Nov 2020 at 22:19, Oscar Benjamin
> wrote:
> > It would be nice if islice gave an object that supported slicing so
> > that you could spell it like:
> >
> >for x in islice(a)[5:]:
> >
> > I find it hard to decipher the meaning of
On Tue, Nov 17, 2020 at 10:17:32PM +, Oscar Benjamin wrote:
> It would be nice if islice gave an object that supported slicing so
> that you could spell it like:
>
>for x in islice(a)[5:]:
>
> I find it hard to decipher the meaning of the arguments to islice
> compared to reading a norma
Hello,
This is my first mail here, so greetings for everyone :)
I would like to introduce an idea of the new operators for dict objects.
Any thoughts are welcome.
Since Python3.9 there is a great feature for merging dicts using | (OR)
operator:
{1: "a"} | {2: "b"} == {1: "a", 2: "b"}
Thus, thi
On Tue, 17 Nov 2020 at 22:19, Oscar Benjamin wrote:
> It would be nice if islice gave an object that supported slicing so
> that you could spell it like:
>
>for x in islice(a)[5:]:
>
> I find it hard to decipher the meaning of the arguments to islice
> compared to reading a normal slice expres
> > On Tue, 17 Nov 2020 at 10:35, Nuri Jung wrote:
> >>
> >> How about enabling subscription operator (`[]`) for generator expressions?
> >> Also for all `zip()`, `key()`, etc. They could be evaluated in the
> >> background only for the requested amount, to avoid evaluating the whole
> >> expre
On Tue, Nov 17, 2020 at 03:42:54AM -, Nuri Jung wrote:
> How about enabling subscription operator (`[]`) for generator expressions?
Generator expressions are iterators, and the iterator protocol is
intentionally very simple. You only need to provide two things for an
object to be an iterato
I'm in favor of keeping the PEP as it currently is. Mappings are naturally
structural subtypes of one another, therefore mapping patterns should be
consistent with class patterns.
car = Car(...)
match car:
case Vehicle():
pass
case Car(): # will never match
I'm in favor of keeping the PEP as it currently is. Mappings are naturally
structural subtypes of one another, therefore mapping patterns should be
consistent with class patterns.
car = Car(...)
match car:
case Vehicle():
pass
case Car(): # will never match
I agree with your detailed explanation, and it would be a great idea to add a
keyword argument to the `next()` function.
Just for reference, I believe C++ also has similar function, `std::next()`
which advances 'iterators', and it also works on non-indexible (i.e. linked
list, etc.) containers.
>>> from itertools import islice
>>> a = (i for i in range(0, 100, 10))
>>> next(islice(a, 5, None))
Paul
On Tue, 17 Nov 2020 at 15:37, Joao S. O. Bueno wrote:
>
> Although that is not a pattern I recall I had needed, but for the first item
> in a generator,
> I recognize it is more complicated
On Wed, Nov 18, 2020 at 2:35 AM Joao S. O. Bueno wrote:
> Also, see it as potentially making a lot of code error-prone:
> let's say one gets passed a generator where a sequence is expected.
> In current Python, if an item is accessed by index, one just get an explicit
> IndexError. If objects chan
Go for it. This is a pretty minor issue but we want to get it right. Data
is helpful.
On Tue, Nov 17, 2020 at 06:58 David Foster wrote:
> On 11/15/20 12:11 AM, Steven D'Aprano wrote:
> > It would be good if the PEP gave a survey of the practical experience of
> > other languages with pattern mat
Although that is not a pattern I recall I had needed, but for the first
item in a generator,
I recognize it is more complicated than it should to be able to do that.
However, not only that would be too big a change for all this objects
I think one would expect an object providing index access wit
On 11/15/20 12:11 AM, Steven D'Aprano wrote:
It would be good if the PEP gave a survey of the practical experience of
other languages with pattern matching:
- are there languages which require an exact match, with no left over
keys? what issues, if any, do users have with that choice?
- whic
How about enabling subscription operator (`[]`) for generator expressions? Also
for all `zip()`, `key()`, etc. They could be evaluated in the background only
for the requested amount, to avoid evaluating the whole expression to something
like a list or tuple, then indexed.
__
15 matches
Mail list logo
