On Sun, May 03, 2020 at 11:13:58PM -0400, David Mertz wrote:
> It seems to me that a Python implementation of zip_equals() shouldn't do
> the check in a loop like a version shows (I guess from more-itertools).
> More obvious is the following, and this has only a small constant speed
> penalty.
>
"strict" doesn't say what it's being strict about. That information has
to be inferred by the reader. As a keyword argument I'd expect it to
relate to the function's main purpose, so for `zip` I can understand how
this refers to the arguments (since their items end up in the resulting
tuples). How
Guido van Rossum wrote:
> I should really stay out of this (hundreds of messages and still
> bickering^Wbikeshedding :-), but I personally find strict=True less
> confusing than equal=True, both for zip() and for map(). If I didn't know
> what was going on, seeing equal=True would make me wonder ab
If you use the word 'even' and tell me it has to do with lengths (or any
number) I'm going to think of multiples of 2, not equality.
On Mon, May 4, 2020 at 3:52 PM wrote:
> Guido van Rossum wrote:
> > I should really stay out of this (hundreds of messages and still
> > bickering^Wbikeshedding :-
On Sun, May 03, 2020 at 09:41:00PM -0700, Christopher Barker wrote:
> On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano wrote:
>
> > > > map(func, x, y, strict=True) # ?
> > > >
> > > > Admittedly the word "strict" in the context of `map` would be rather
> > > > confusing.
> > > >
> > >
> > > T
Alex Hall wrote:
> If you use the word 'even' and tell me it has to do with lengths (or any
> number) I'm going to think of multiples of 2, not equality.
> On Mon, May 4, 2020 at 3:52 PM jdve...@gmail.com
> wrote:
> > Guido van Rossum wrote:
> > I should really stay out of this (hundreds of
> > mes
On Mon, May 04, 2020 at 02:18:15PM -, jdve...@gmail.com wrote:
> Ok,`even`is one of those scarce polysemic words in English ;-)
>
> Meaning depends on context and message receiver's expectations, of course.
>
> But... "add an even mixture of milk and cream" and "the curtain rod
> and the
I'm wondering if a `mode` (or similar) keyword argument, with multiple
possible options, should be included in the "rejected" section of the PEP.
zip(*args, mode="longest") <-- default
zip(*args, mode="equal") <-- or "even"
An advantage of this way is if the option to zip in different ways prov
On 04/05/2020 15:02, Alex Hall wrote:
...top-posted stuff in response to jdve...@gmail.com, who had bottom posted.
Guys, I know I'm not going to persuade either of you of the fundamental
truth that posting interleaved replies is best, but if you're going to
post at opposite ends of the chain o
On Mon, May 4, 2020, 10:55 AM Ricky Teachey wrote:
> I'm wondering if a `mode` (or similar) keyword argument, with multiple
> possible options, should be included in the "rejected" section of the PEP.
>
> zip(*args, mode="longest") <-- default
> zip(*args, mode="equal") <-- or "even"
>
Whoops
On Sun, 3 May 2020 21:57:42 -0700
Guido van Rossum wrote:
> I should really stay out of this (hundreds of messages and still
> bickering^Wbikeshedding :-), but I personally find strict=True *less*
> confusing than equal=True, both for zip() and for map(). If I didn't know
> what was going on, seei
On 2020-05-04 13:17, Dominik Vilsmeier wrote:
"strict" doesn't say what it's being strict about. That information has
to be inferred by the reader.
[snip]
And "equal" doesn't say what it's equal.
What we need is a word that means "same length", much as "shorter" and
"longer" are about length.
On Sun, 3 May 2020 14:58:41 -0700
Andras Tantos wrote:
>
> 1. With the recent type-hint support, the feature could be made way more
> descriptive if this PEP got implemented.
>
> For example, instead of doing the following:
>
> def func(in: Dict[str, int])
>
> one could write
How about "balanced" or "exact" as possible names. The main thing that I think
is vital is for the docstring(s) to mention that they all exist - the current
zip (in 3.8) doesn't mention zip_longest so if you don't already know about it.
Or even how about calling any flag/parameter "tail", "spare
There could be other modes, such as `mode="repeat"` which reuses the
last value of each iterator as a fillvalue, or `mode="wrap"` which is
similar to `zip(*(it.cycle(x) for x in its))`.
So indeed a binary flag protects from additional requests to further
overload that function. This can be a good
Hi All,
First of all, if this is something which has been discussed in the past the
please point me in the right direction.
*Problem:*
When creating classes in Python, I find myself writing the __init__ method
in a very similar way a lot of the time, that is:
```
def __init__(self, argument_1, a
On 04.05.20 19:43, Steve Barnes wrote:
How about "balanced" or "exact" as possible names. The main thing that I think
is vital is for the docstring(s) to mention that they all exist - the current zip (in 3.8) doesn't
mention zip_longest so if you don't already know about it.
What about "equi
On 04.05.20 16:14, Steven D'Aprano wrote:
On Sun, May 03, 2020 at 09:41:00PM -0700, Christopher Barker wrote:
On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano wrote:
map(func, x, y, strict=True) # ?
Admittedly the word "strict" in the context of `map` would be rather
confusing.
This a
On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano wrote:
> On Sat, May 02, 2020 at 10:26:18PM +0200, Alex Hall wrote:
>
> > > If I know that consumers of my data truncate on the shortest input,
> then
> > > as the producer of data I don't have to care about making them equal. I
> > > can say:
> > >
On Tue, May 5, 2020 at 5:11 AM Alex Hall wrote:
>
> On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano wrote:
>> Can we agree to meet half-way?
>>
>> - there are legitimate, genuine uses for zip_strict;
>>
>> - but encouraging people to change zip to zip_strict "just in case"
>> in the absence of a
Thanks to everyone who provided useful feedback. I'm working now to incorporate
many of your suggestions into the next draft, which should be pushed soon.
Brandt
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to py
On Mon, May 4, 2020 at 2:33 AM Steven D'Aprano wrote:
> On Sat, May 02, 2020 at 07:43:44PM +0200, Alex Hall wrote:
> > On Sat, May 2, 2020 at 6:09 PM Steven D'Aprano
> wrote:
> >
> > > On Sat, May 02, 2020 at 04:58:43PM +0200, Alex Hall wrote:
> > >
> > > > I didn't think carefully about this im
On Mon, May 4, 2020 at 10:03 Antoine Pitrou wrote:
> Of course, that's why I originally suggested that `Dict[...]` should be
> spelled `Dict(...)` instead.
...and we’d be hosed now with no path from Dict to dict.
> --
--Guido (mobile)
___
Python-idea
On Mon, May 4, 2020 at 9:18 PM Chris Angelico wrote:
> On Tue, May 5, 2020 at 5:11 AM Alex Hall wrote:
> >
> > On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano
> wrote:
> >> Can we agree to meet half-way?
> >>
> >> - there are legitimate, genuine uses for zip_strict;
> >>
> >> - but encouraging p
You are not the first to have this idea. Unless I am mistaken you might
find what you are looking for in dataclasses which were added in Python 3.7:
https://docs.python.org/3/library/dataclasses.html
On Mon, 4 May 2020 at 19:06, Lewis Ball wrote:
> Hi All,
>
> First of all, if this is something
On Mon, 4 May 2020 21:07:26 +0200
Alex Hall wrote:
> Yes. We're starting to go in circles here, but I'm arguing that it's
> OK for people to be mildly inconvenienced sometimes having to
> preemptively trim their inputs in exchange for less confusing,
> invisible, frustrating bugs. I'd like peopl
I did think about data classes and although I haven't really used them much
they do seem to be for a different use case, for example they don't support
keyword-only args or positional-only args. I'm not sure if there are any
other differences. Maybe a data class which supported kW-only args and
pos
I agree that dataclasses are for a slightly different use case.
It looks like this could be implemented as a decorator using the
functionality afforded by `inspect.signature`, though what I've come up
with so far is a bit clunky because you have to account for parameters that
could be positional o
I had a similar solution with a decorator using inspect.getfullargspec but
it is pretty fiddly and it is pretty easy to miss some of the edge cases.
Having a standard implementation would definitely take care of this. And I
imagine static analysis tools would be able to cope with it, they do a good
On Mon, May 04, 2020 at 07:01:03PM +0100, Lewis Ball wrote:
> Hi All,
>
> First of all, if this is something which has been discussed in the past the
> please point me in the right direction.
It certainly has been, but with no conclusion one way or another. I
think people agree that it is a pain
On Mon, May 04, 2020 at 09:20:28PM +0200, Alex Hall wrote:
> > Seriously, if some object defines a weird `__eq__` then half the
> > standard library, including builtins, stops working "correctly". See for
> > example the behaviour of float NANs in lists.
> >
> > My care factor for this is negligib
On 05/04/2020 12:35 PM, Alex Hall wrote:
I imagine there are few people who are too lazy to copy code from SO right now,
and would be too lazy to import from itertools when the feature becomes
available, but if it's a builtin then they're willing to make changes
Quite frankly, I have zero co
On 05/04/2020 12:07 PM, Alex Hall wrote:
No, I stand by my position for now that "just in case" is a genuine reason
"just in case" is boiler-plate. One of the huge wins in Python is its low
boiler-plate requirements. It's okay if programmers have to think about their code and
what's requir
> We should have a mechanism that collects the current function or method's
> parameters into a dict, similar to the way locals() returns all local
> variables.
Maybe I'm missing something here, but how about... `locals`? It works exactly
as you hope:
```
def __init__(self, argument_1, argumen
> On May 3, 2020, at 6:19 PM, Steven D'Aprano wrote:
>
>>> `frozenset` and `set` make a counterexample:
>>>
>> frozenset({1}) == {1}
>>> True
>>>
>>
>> Nice catch! That's really interesting. Is there reasoning behind
>> `frozenset({1}) == {1}` but `[1] != (1,)`, or is it just an acciden
Steven: I understand that Alex said he thought that putting "strict" in as
a flag would make it a bit more likely that people would use, and that he
thinks that's a good thing, and you think that's a bad thing, but...
Unless we were to make it the default behavior, very few people are going
to be
36 matches
Mail list logo
