Currently type(None) returns None if you call it with no args:
>>> print(type(None)())
None
it'd be nice if it did the same regardless of args. currently it raises:
>>> print(type(None)(1))
Traceback (most recent call last):
File "", line 1, in
TypeError: NoneType takes no arguments
inspire
On Sat, Apr 25, 2020 at 1:20 AM Soni L. wrote:
>
> Currently type(None) returns None if you call it with no args:
>
> >>> print(type(None)())
> None
>
> it'd be nice if it did the same regardless of args. currently it raises:
>
> >>> print(type(None)(1))
> Traceback (most recent call last):
>
On 2020-04-24 12:26 p.m., Chris Angelico wrote:
On Sat, Apr 25, 2020 at 1:20 AM Soni L. wrote:
>
> Currently type(None) returns None if you call it with no args:
>
> >>> print(type(None)())
> None
>
> it'd be nice if it did the same regardless of args. currently it raises:
>
> >>> print(typ
On Sat, Apr 25, 2020 at 1:44 AM Soni L. wrote:
>
>
>
> On 2020-04-24 12:26 p.m., Chris Angelico wrote:
> > On Sat, Apr 25, 2020 at 1:20 AM Soni L. wrote:
> > >
> > > Currently type(None) returns None if you call it with no args:
> > >
> > > >>> print(type(None)())
> > > None
> > >
> > > it'd be
> On Apr 24, 2020, at 08:46, Soni L. wrote:
>
> it's not my own use case for once. the PEP clearly lists a use-case. we
> should support that use-case.
So your use case is the rationale from a PEP written because Barry “can’t
resist” and rejected as a joke in record time, for which a better so
24.04.20 07:58, Andrew Barnert via Python-ideas пише:
And not only that, the PEP for this first step has to make it clear that it’s
useful on its own—not just to people like Serhiy who eventually want to replace
zip and see it as a first step, but also to people who do not want zip to ever
cha
> Since this is not a rare assumption for you, then you should have no trouble
> coming up with some concrete examples of how and when you would use it.
Well, my use cases are "anytime the iterables should be the same length", which
several on this thread have agreed is easily the majority of th
+1 on almost always expecting my iterators to be the same length when I
pass them to zip. I struggle to think of a time when I haven't had that
expectation.
To people asking whether I would catch the error that zip_strict would
raise, almost certainly not. I rarely catch ValueError other than
On Apr 24, 2020, at 11:07, Brandt Bucher wrote:
>
> 1. Likely the most common case, for me, is when I have some data and want to
> iterate over both it and a calculated pairing:
>
x = ["a", "b", "c", "d"]
y = iter_apply_some_transformation(x)
for a, b in zip(x, y):
> ... ...
On 25/04/20 6:07 am, Brandt Bucher wrote:
Well, my use cases are "anytime the iterables should be the same
length", which several on this thread have agreed is easily the
majority of the time they use `zip`.
If zip were being designed today, I'm sure most people
wouldn't mind if it were always
> If zip were being designed today, I'm sure most people wouldn't mind if it
> were always strict or strict by default.
Again, I'd like to stress that I think the current default behavior is fine. I
have no desire to change it, even over an extended deprecation period.
> But given how it is, ho
11 matches
Mail list logo
