> Although I might use it a lot (more than I would like to admit), I don't
> like this feature. First of all, I think it favors not-very-pretty code,
> effectively reducing the cost you pay for writing too-many-argument
> functions. It'd also obfuscate the code, and here I would like to quote the
>
On Thu, May 7, 2020 at 4:42 AM Kirill Balunov
wrote:
> `chain(*iterable)` converts iterable into a tuple, concretizing it in
>> memory. chain.from_iterable(iterable) is lazy and goes through the elements
>> one a time, meaning iterable can be infinite.
>>
>
> "meaning iterable can be infinite" -
On 07/05/2020 10:11, Steven D'Aprano wrote:
On Sat, May 02, 2020 at 05:12:58AM -, Ahmed Amr wrote:
Currently, when comparing a list of items to an array of the same
items for equality (==) it returns False, I'm thinking that it would
make sense to return True in that context, as we're compa
On Thu, 7 May 2020 21:18:16 +1000
Steven D'Aprano wrote:
> > The strongest equality is the "is" operator
>
> Please don't encourage the conceptual error of thinking of `is` as
> *equality*, not even a kind of equality. It doesn't check for equality,
> it checks for *identity* and we know that
On Wed, 6 May 2020 at 18:56, Lewis Ball wrote:
>
> Joao S. O. Bueno wrote:
> > Here - with the current inspect.Signature, it is straightforward
> > to get a decorator that can do that covering most, if not all,
> > corner cases, and even adding some extra functionality:
> > https://gist.github.co
Christopher Barker writes:
> But though Python blurs the lines between various callables and
> functions, there is a general "sense" of how they are used. And for
> the most part, zip is not used like a class. WE "use" classes,
> usually, by creating instances, and then calling various methods
On 07.05.20 09:38, Stephen J. Turnbull wrote:
Christopher Barker writes:
> So while yes, alternate constructors are a common pattern, I don't
> think they are a common pattern for classes like zip.
That's a matter of programming style, I think. There's no real
difference between
zip
On Thu, 7 May 2020 at 08:54, Greg Ewing wrote:
>
> On 7/05/20 1:07 pm, David Mertz wrote:
> > For *most* functions, the substitution
> > principle is fine in Python. A whole lot of the time, numeric functions
> > can take either an int or a float that are equal to each other and
> > produce resul
On 07.05.20 11:11, Steven D'Aprano wrote:
On Sat, May 02, 2020 at 05:12:58AM -, Ahmed Amr wrote:
Currently, when comparing a list of items to an array of the same
items for equality (==) it returns False, I'm thinking that it would
make sense to return True in that context, as we're compar
Hello everyone, I am Pablo from Argentina! This is my first email here, so
just let me know if I am missing anything that is of use in this list, such
as presenting myself. As for this topic in particular:
Although I might use it a lot (more than I would like to admit), I don't
like this feature.
The connection is very obvious after you know about it.
And probably you can guess the meaning if you see an
@once decorator in someone's code. But it's less clear
that a person who hasn't seen the word "once" used
this way will think of searching for it when they want
a way to cache the return val
On Thu, May 07, 2020 at 01:17:37PM +0100, Henk-Jaap Wagenaar wrote:
> Why use "." which has clear syntax problems?
[Me]
> > (For the avoidance of doubt, I know that syntax will not work in
> > Python because it will be ambiguous. That's why I picked it -- it's
> > syntax that we can all agree w
Why use "." which has clear syntax problems?
This can already be done in current Python (this was linked to in a
previous thread about something else) using a generic solution if you
change the syntax:
https://pypi.org/project/infix/
You could write it as |EQ|, ^EQ^, ... and have it in its own P
On Thu, May 07, 2020 at 10:44:01PM +1200, Greg Ewing wrote:
> On 7/05/20 9:11 pm, Steven D'Aprano wrote:
> >I'm initially going to use the ancient 1960s
> >Fortran syntax and spell it `.EQ.`.
> >
> >I know that syntax will not work in Python
> >because it will be ambiguous.
>
> I'm sure the new pa
On Thu, May 07, 2020 at 06:04:13AM -0400, Dan Sommers wrote:
> On Thu, 7 May 2020 19:11:43 +1000
> Steven D'Aprano wrote:
>
> > We could define this .EQ. operate as *sequence equality*, defined very
> > roughly as:
> >
> > def .EQ. (a, b):
> > return len(a) == len(b) and all(x==y for
On Wed, May 06, 2020 at 08:48:51AM -0700, Christopher Barker wrote:
[I asked]
> > A ternary flag of strict = True, False or what?
> >
>
> Come on:
>
> ternary: having three elements, parts, or divisions (
> https://www.merriam-webster.com/dictionary/ternary)
>
> did you really not know that?
On 7/05/20 9:11 pm, Steven D'Aprano wrote:
I'm initially going to use the ancient 1960s
Fortran syntax and spell it `.EQ.`.
I know that syntax will not work in Python
because it will be ambiguous.
I'm sure the new parser will handle it just fine!
--
Greg
__
On Thu, 7 May 2020 19:11:43 +1000
Steven D'Aprano wrote:
> We could define this .EQ. operate as *sequence equality*, defined very
> roughly as:
>
> def .EQ. (a, b):
> return len(a) == len(b) and all(x==y for x, y in zip(a, b))
Equality and its awkward cousin equivalence are slippery
On Wed, May 06, 2020 at 09:17:15PM -0400, Eric V. Smith wrote:
> I think David is right: itertools.chain.from_iterable() is the only
> place I know of with an attribute on a function that's another function.
Functions decorated with `functools.wrap` have an attribute that gives
the original fun
This reminded me of another recent message so I decided to find that and
link it here:
https://mail.python.org/archives/list/python-ideas@python.org/message/7ILSYYOFPQL5DVH5DGIGQSL6PYFYF7PC/
It seemed like a more useful thing to do before I discovered that you wrote
that too...
On Thu, May 7, 202
On Sat, May 02, 2020 at 05:12:58AM -, Ahmed Amr wrote:
> Currently, when comparing a list of items to an array of the same
> items for equality (==) it returns False, I'm thinking that it would
> make sense to return True in that context, as we're comparing item
> values and we have the sam
On Thu, May 7, 2020 at 3:07 AM Christopher Barker
wrote:
> On Wed, May 6, 2020 at 1:42 PM Kirill Balunov
> wrote:
>
>> I'm totally agree with everything you said here. From my perspective,
>> comparing three main cases:
>> 1. zip(*iters, strict= (False | True))
>> 2. zip(*iters, mode = ('shortes
On Thu, May 7, 2020 at 10:56 AM Alex Hall wrote:
> On Thu, May 7, 2020 at 9:48 AM Kirill Balunov
> wrote:
>
>> Sorry for off topic. Isn't this chain.from_iterable just a historical
>> legacy... now we have PEP 448 and I see no differences* between
>> chain(*iterable) vs chain.from_iterable(itera
On Thu, May 7, 2020 at 9:48 AM Kirill Balunov
wrote:
> Sorry for off topic. Isn't this chain.from_iterable just a historical
> legacy... now we have PEP 448 and I see no differences* between
> chain(*iterable) vs chain.from_iterable(iterable). Are there?
>
> * chain.from_iterable is a little bit
On 7/05/20 1:07 pm, David Mertz wrote:
For *most* functions, the substitution
principle is fine in Python. A whole lot of the time, numeric functions
can take either an int or a float that are equal to each other and
produce results that are equal to each other.
It's not much use for decidin
Sorry for off topic. Isn't this chain.from_iterable just a historical
legacy... now we have PEP 448 and I see no differences* between
chain(*iterable) vs chain.from_iterable(iterable). Are there?
* chain.from_iterable is a little bit faster for small iterables, but if at
that time we had PEP 448,
On Thu, May 7, 2020 at 2:33 AM Oscar Benjamin
wrote:
> On Sat, 2 May 2020 at 20:50, Serhiy Storchaka wrote:
> >
> > 02.05.20 21:34, Ahmed Amr пише:
> > > I see there are ways to compare them item-wise, I'm suggesting to bake
> > > that functionality inside the core implementation of such indexed
Christopher Barker writes:
> But though Python blurs the lines between various callables and
> functions, there is a general "sense" of how they are used. And for
> the most part, zip is not used like a class. WE "use" classes,
> usually, by creating instances, and then calling various methods
On Thu, May 7, 2020 at 12:26 PM Oscar Benjamin
wrote:
>
> On Thu, 7 May 2020 at 02:07, David Mertz wrote:
> >
> > That's the point though. For *most* functions, the substitution principle
> > is fine in Python. A whole lot of the time, numeric functions can take
> > either an int or a float t
On Thu, 7 May 2020 at 01:07, Christopher Barker wrote:
> 3) Add a ternary mode flag to zip
> zip(*iters, mode = ('shortest' | 'equal' | 'longest'), fillvalue=None)
You missed
itertools.zip_longest(*iters, fillvalue=None)
from this one. Unless you're proposing to drop itertools.zip_longest,
the
30 matches
Mail list logo
