in that case you presented maybe it is more readeable but considering that
lists as ["a","b"] can be inputted, not just using range, the result might
be as it was. change x y people are happy change y and z people hate it
Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com
On
On Fri, Sep 15, 2017 at 08:03:32PM +0200, Jason H wrote:
> But really, I've learned a few things along the way. Though nothing to
> convince me that I'm wrong or it's a bad idea. It's just not liked by
> the greybeards, which I can appreciate. "here's some new punk kid, get
> off my lawn!" type
On 09/15/2017 11:03 AM, Jason H wrote:
From: "Steven D'Aprano"
>> Um... what's in it for *us*? What benefit do we get?
>
How that question is answered, depends on who is 'us'? If you're a bunch of
> python purist greybeards, then conceivably nothing.
How about refugees from other languages?
On 9/15/17 2:03 PM, Jason H wrote:
It's just not liked by the greybeards, which I can appreciate. "here's some new punk
kid, get off my lawn!" type of mentality. Dunning-Kruger, etc.
I'm not sure if you meant this tongue-in-cheek or not. The main problem
with your proposal is that it would b
> Sent: Friday, September 15, 2017 at 12:24 PM
> From: "Steven D'Aprano"
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] Make map() better
>
> Jason,
>
> I'm sorry if you feel that everyone is piling on you to poo-poo your
> ideas,
Jason,
I'm sorry if you feel that everyone is piling on you to poo-poo your
ideas, but we've heard it all before. To you it might seem like
"peaceful coexistence", but we already have peaceful coexistence. Python
exists, and Javascript exists (to say nothing of thousands of other
languages, go
On Sep 15, 2017 7:23 AM, "Jason H" wrote:
Another pain point is python uses [].append() and JS uses [].join() Having
a wrapper for append would be helpful.
There should be one, and only one, obvious way to do it.
And for that matter, why isn't append/extend a global? I can add things to
lots o
> And for that matter, why isn't append/extend a global? I can add things
to lots of different collections. lists, sets, strings...
No, append is relevant when the collection is ordered. You update
dictionnaries, you make unions of sets, and you append lists to another
ones.
These operations are s
I'm going to respond to a few replies with this one.
> > Because join apply on a string, and strings are defined by the str class,
> > not by a specific protocol (unlike iterables).
>
> Join actually used to only be available as a function (string.join in
> Python 2.x). However, nobody could eve
For these examples, you shouldn't be using map at all.
On Wednesday, September 13, 2017 at 11:10:39 AM UTC-4, Jason H wrote:
>
> The format of map seems off. Coming from JS, all the functions come
> second. I think this approach is superior.
>
> Currently:
> map(lambda x: chr(ord('a')+x), range
On 15 September 2017 at 03:38, Antoine Rozo wrote:
>> Why is it ','.join(iterable), why isn't there join(',', iterable)
>
> Because join apply on a string, and strings are defined by the str class,
> not by a specific protocol (unlike iterables).
Join actually used to only be available as a funct
> Why? I can iterate over a string. [c for c in 'abc'] It certainly behaves
like one... I'd say this is inconsistent because there is no __iter__() and
next() on the str class.
Yes, strings are iterables. You can use a string as argument of str.join
method.
But only strings can be used as separato
On Fri, Sep 15, 2017 at 5:06 AM, Jason H wrote:
>
>>> Why is it ','.join(iterable), why isn't there join(',', iterable)
>
>> Because join apply on a string, and strings are defined by the str class,
>> not by a specific protocol (unlike iterables).
> Why? I can iterate over a string. [c for c in
>> Why is it ','.join(iterable), why isn't there join(',', iterable)
> Because join apply on a string, and strings are defined by the str class, not
> by a specific protocol (unlike iterables).
Why? I can iterate over a string. [c for c in 'abc'] It certainly behaves like
one... I'd say this
> Why is it ','.join(iterable), why isn't there join(',', iterable)
Because join apply on a string, and strings are defined by the str class,
not by a specific protocol (unlike iterables).
2017-09-14 18:43 GMT+02:00 MRAB :
> On 2017-09-14 03:55, Steven D'Aprano wrote:
>
>>
>> On Wed, Sep 13, 201
On 2017-09-14 03:55, Steven D'Aprano wrote:
On Wed, Sep 13, 2017 at 11:05:26PM +0200, Jason H wrote:
> And look, map() even works with all of them, without inheritance,
> registration, and whatnot. It's so easy!
Define easy.
Opposite of hard or difficult.
You want to map a function?
map(
On Wed, Sep 13, 2017 at 5:05 PM, Jason H wrote:
> Python is weird in that there are these special magical globals that
> operate on many things.
Jason, that weirdness is actually a deep part of Python's philsophy. The
language is very protocol driven. It's not just the built-in functions that
u
On Wed, Sep 13, 2017 at 11:05:26PM +0200, Jason H wrote:
> > And look, map() even works with all of them, without inheritance,
> > registration, and whatnot. It's so easy!
>
> Define easy.
Opposite of hard or difficult.
You want to map a function?
map(function, values)
is all it takes. You
On Wed, Sep 13, 2017 at 05:09:37PM +0200, Jason H wrote:
> The format of map seems off. Coming from JS, all the functions come
> second. I think this approach is superior.
Obviously Javascript has got it wrong. map() applies the function to
the given values, so the function comes first. That ma
> Sent: Wednesday, September 13, 2017 at 3:57 PM
> From: "Stefan Behnel"
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] Make map() better
>
> Jason H schrieb am 13.09.2017 um 17:54:
> > I'm rather surprised that there isn't a Iterabl
Jason H schrieb am 13.09.2017 um 17:54:
> I'm rather surprised that there isn't a Iterable class which dict and list
> derive from.
> If that were added to just dict and list, I think it would cover 98% of
> cases, and adding Iterable would be reasonable in the remaining scenarios.
Would you the
On Wed, Sep 13, 2017 at 10:54 AM, Jason H wrote:
>
> Thanks for the insights.
> I don't think it would be that breaking:
>
> def remap_map(a1, a2):
> if hasattr(a1, '__call__'):
> return map(a1, a2)
> elif hasattr(a2, '__call__'):
> return map(a2,a1)
> else:
> raise NotCallable #
> Sent: Wednesday, September 13, 2017 at 11:23 AM
> From: "Edward Minnix"
> To: "Jason H"
> Cc: Python-Ideas
> Subject: Re: [Python-ideas] Make map() better
>
> While I agree that the method calling syntax is nicer, I disagree with
> flippi
While I agree that the method calling syntax is nicer, I disagree with flipping
the argument error for three main reasons.
First: it violates the signature entirely
The signature to map is map(function, *iterables). Python’s map is more like
Haskell’s zipWith. Making the function last would eith
We're not going to break every version of Python since 0.9 because
Javascript does something a certain way. Whatever might be better
abstractly, this is well established.
As to adding a `.map()` method to *every* iterable... just how would you
propose to do that given that it's really easy and co
The format of map seems off. Coming from JS, all the functions come second. I
think this approach is superior.
Currently:
map(lambda x: chr(ord('a')+x), range(26)) # ['a', 'b', 'c', 'd', 'e', 'f', 'g',
'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
'x', 'y', 'z'
26 matches
Mail list logo