Re: [Python-ideas] Add "default" kwarg to list.pop()

[Ron Reiter]

I think l.pop() if l else None is good enough. I think it's pretty obvious
that a developer means "Pop the list if the list is not empty, and return
None if the list is empty ".

- Ron


[image: Facebook]  [image: Twitter]
 [image: LinkedIn]



On Wed, Oct 31, 2018 at 11:24 AM Nicolas Rolin 
wrote:

>
> As a user I always found a bit disurbing that dict pop method have a
> default while list and set doesn't.
> While it is way more computationally easy to check wether a list or a set
> is empty that to check if a key is in a dict, it still create a signature
> difference for no real reason (having a default to a built-in in python is
> pretty standard).
> It would be nice if every built-in/method of built-in type that returns a
> value and raise in some case have access to a default instead of raise, and
> not having to check the doc to see if it supports a default.
>
> We could for exemple ask ourselves wether or not list.index should have a
> default, as it is a method that we explecitely excpect to return a value
> and might just raise instead.
>
> 2018-10-31 2:08 GMT+01:00 Steven D'Aprano :
>
>> On Wed, Oct 31, 2018 at 02:25:25AM +0200, Serhiy Storchaka wrote:
>> > 31.10.18 01:44, Giampaolo Rodola' пише:
>> > >Sorry in advance if this has been proposed in the past but I couldn't
>> > >find anything on python-ideas:
>> > >
>> > > >>> l = []
>> > > >>> l.pop(default=1)
>> > >1
>> [...]
>>
>> > It is just
>> >
>> > l.pop() if l else default
>>
>> It might *do* the same thing, but it doesn't communicate the
>> programmer's intention as well.
>>
>> {}.pop('key', default) could be written using LBYL too, but the
>> intention is much clearer given an explicit default argument.
>>
>> The only advantage of the "if l" version is that if the default is
>> expensive to calculate, we can short-circuit it.
>>
>>
>> > or
>> >
>> > (l or [default]).pop()
>>
>> That's clever, but it is also wasteful, building a single-item list only
>> to immediately pop the item out of it and throw the list away.
>>
>> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "l.pop() if l else None"
>> 1000 loops, best of 3: 0.0739 usec per loop
>>
>> [steve@ando ~]$ python3.5 -m timeit -s "l = []" "(l or [None]).pop()"
>> 100 loops, best of 3: 0.421 usec per loop
>>
>>
>>
>> --
>> Steve
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> --
>
> --
> *Nicolas Rolin* | Data Scientist
> + 33 631992617 - nicolas.ro...@tiime.fr 
>
>
> *15 rue Auber, **75009 Paris*
> *www.tiime.fr *
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] gevent-like Coroutines in Python

[Ron Reiter]

You are right that they are different, I was actually assuming that
developers by default don't try to parallelize and would rather go ahead
and write code to yield one function at a time, which is fine. The need to
separate "await" from the invocation is something which is rarely used. Not
sure what you mean about "threading" as it is still more efficient and
lightweight to parallelize workers on an event loop rather than using
blocking threads.

As I said - I don't think we should downgrade Python's current ability to
do so, my suggestion is to create something like the "codef" proposal,
which will also await on every function invocation - for readability.

- Ron


[image: Facebook] <http://www.facebook.com/ron.reiter> [image: Twitter]
<http://twitter.com/#!/ronreiter> [image: LinkedIn]
<https://il.linkedin.com/in/ronreiter>


On Tue, Oct 30, 2018 at 12:41 PM Chris Angelico  wrote:

> On Tue, Oct 30, 2018 at 6:01 PM Ron Reiter  wrote:
> >
> > ... most developers would always mean they prefer to do this:
> >
> > result = [await fun(x) for fun in funcs]
> >
> > versus:
> >
> > result = [fun(x) for fun in funcs]
> > await asyncio.gather(*result)
> >
> > Moreso, having it become the default makes statements like this:
> >
> > result = [await fun(x) for fun in funcs if await smth]
> >
> > Look like this:
> >
> > result = [fun(x) for fun in funcs if smth]
> >
> > Therefore, my suggestion is to create a new "async" definition which
> basically turns every function invocation into an "await" if a generator is
> returned.
> >
>
> I'm not sure what you're driving at here. From your first example, I
> gather that (pun intended) you're expecting the 'result' list to
> contain all the results from the different function calls, running
> them all in parallel; but your second example and described suggestion
> seem to imply that the waitings would continue to be sequential.
>
> Unless you're asking for straight-up magic ("do everything in parallel
> unless they need to be serialized"), there still needs to be a clear
> way to differentiate between "wait for this right now and give me a
> result before this function continues" and "gather all these jobs
> together, get me the results, and then move on once you have them
> all". It might perhaps be nice to have an easier/more obvious syntax
> for gather(), but it definitely needs to have some form of spelling.
>
> If you're not asking for them to be run in parallel, you're asking for
> an implicit way for a function call to block its caller, and for the
> calling function to act sequentially. Python already has that - it's
> called threading :)
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] gevent-like Coroutines in Python

[Ron Reiter]

One of Golang's advantages is that goroutines act like gevent's coroutines
instead of relying on an async/await syntax. In my opinion, it makes Golang
code much more readable.

I feel like having the await syntax trigger by default on any awaitable
invocation in a coroutine context makes much more sense. I consider
async/await syntax to be too complicated for the average developer since it
opens up too many abilities whereas most developers would always mean they
prefer to do this:

result = [await fun(x) for fun in funcs]

versus:

result = [fun(x) for fun in funcs]
await asyncio.gather(*result)

Moreso, having it become the default makes statements like this:

result = [await fun(x) for fun in funcs if await smth]

Look like this:

result = [fun(x) for fun in funcs if smth]

Therefore, my suggestion is to create a new "async" definition which
basically turns every function invocation into an "await" if a generator is
returned. Instead of "async def" I propose the alternative "coroutine def"
syntax. However, a better solution may be to imply the word "async" in
every function definition given some sort of trigger (however I assume that
this won't be the preferable approach as it is not something that can be
implemented at the parsing level).

For me, I believe that Python should aspire to be both concise and
straightforward, which means no boilerplate code just because it's more
"correct" but rather assume there's some logical default behavior going on
in the back - and to me this logical behavior is that every invocation can
trigger an await and go back to the main loop. Our assumption that a
function invocation has to tie back to instant execution unless an "await"
statement has been placed should be challenged in favor of readability,
conciseness, and to always aim to appeal to novice developers (which I
believe is the reason Python is on such a rise these days).

I do have to admit I have not thought through what is the best syntax or
the implications of this because I would like to see what is the general
opinion on this idea first.

- Ron
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Multi Statement Lambdas

[Ron Reiter]

Just write all your transformations at the top of the file and then write
the mapreduce chain at the end. If you need to use closures that depend on
each other then it may be a bit more ugly but still feasible to implement.

- Ron


[image: Facebook] <http://www.facebook.com/ron.reiter> [image: Twitter]
<http://twitter.com/#!/ronreiter> [image: LinkedIn]
<https://il.linkedin.com/in/ronreiter>


On Sun, Oct 21, 2018 at 10:20 PM Marko Ristin-Kaufmann <
marko.ris...@gmail.com> wrote:

> Hi,
> What about writing longer map in pyspark? When I worked with Spark
> and Scala, it was easy to script a longer chain of transformations in
> Scala. Does anybody know how that works in Python without multiline lambdas?
>
> Cheers Marko
>
>
> Le dim. 21 oct. 2018 à 18:40, Ron Reiter  a écrit :
>
>> Multi-line lambdas may be nice for functional languages, but Python is
>> very imperative in nature and prefers clean syntax over conciseness, which
>> means it will make it REALLY hard to fit with Python. I personally find
>> multi-line lambdas an unreadable abomination.
>>
>> As for some more concrete reasons on why this should not be a part of
>> Python, see here for an example which shows why it would even be hard to
>> come up with a plausible syntax for multi-line lambdas:
>>
>> https://stackoverflow.com/questions/1233448/no-multiline-lambda-in-python-why-not
>>
>> Guido's words:
>>
>> "But the complexity of any proposed solution for this puzzle is immense,
>> to me: it requires the parser (or more precisely, the lexer) to be able to
>> switch back and forth between indent-sensitive and indent-insensitive
>> modes, keeping a stack of previous modes and indentation level. Technically
>> that can all be solved (there's already a stack of indentation levels that
>> could be generalized). But none of that takes away my gut feeling that it
>> is all an elaborate Rube Goldberg contraption."
>>
>> If one would find a syntax which is Pythonic and clean then I am in favor
>> of adding it, but I argue it simply does not exist.
>>
>> - Ron
>>
>>
>> [image: Facebook] <http://www.facebook.com/ron.reiter> [image: Twitter]
>> <http://twitter.com/#!/ronreiter> [image: LinkedIn]
>> <https://il.linkedin.com/in/ronreiter>
>>
>>
>> On Sun, Oct 21, 2018 at 7:34 PM Anders Hovmöller 
>> wrote:
>>
>>>
>>> Wheres a lambda expression can be passed anonymously to any other
>>> function as an argument.
>>>
>>> *map(lambda x: x**2, array)*
>>>
>>> vs
>>>
>>> *def powers2(x)*
>>> *   x**2*
>>> *map(powers2, array)*
>>>
>>> Coming up with a name here is not needed, as the operation is expressive
>>> enough.
>>>
>>>
>>> Sure, but there is a well known convention for such non-names already:
>>> meta syntactical variables. In this case the name could be "foo" and all
>>> readers will interpret this as "no name".
>>>
>>> I admit to have wanted lambdas that are just as powerful as normal
>>> functions, but often when I want it the code is nicer when a normal
>>> function is used.
>>>
>>> / Anders
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Multi Statement Lambdas

[Ron Reiter]

Multi-line lambdas may be nice for functional languages, but Python is very
imperative in nature and prefers clean syntax over conciseness, which means
it will make it REALLY hard to fit with Python. I personally find
multi-line lambdas an unreadable abomination.

As for some more concrete reasons on why this should not be a part of
Python, see here for an example which shows why it would even be hard to
come up with a plausible syntax for multi-line lambdas:
https://stackoverflow.com/questions/1233448/no-multiline-lambda-in-python-why-not

Guido's words:

"But the complexity of any proposed solution for this puzzle is immense, to
me: it requires the parser (or more precisely, the lexer) to be able to
switch back and forth between indent-sensitive and indent-insensitive
modes, keeping a stack of previous modes and indentation level. Technically
that can all be solved (there's already a stack of indentation levels that
could be generalized). But none of that takes away my gut feeling that it
is all an elaborate Rube Goldberg contraption."

If one would find a syntax which is Pythonic and clean then I am in favor
of adding it, but I argue it simply does not exist.

- Ron


[image: Facebook]  [image: Twitter]
 [image: LinkedIn]



On Sun, Oct 21, 2018 at 7:34 PM Anders Hovmöller 
wrote:

>
> Wheres a lambda expression can be passed anonymously to any other function
> as an argument.
>
> *map(lambda x: x**2, array)*
>
> vs
>
> *def powers2(x)*
> *   x**2*
> *map(powers2, array)*
>
> Coming up with a name here is not needed, as the operation is expressive
> enough.
>
>
> Sure, but there is a well known convention for such non-names already:
> meta syntactical variables. In this case the name could be "foo" and all
> readers will interpret this as "no name".
>
> I admit to have wanted lambdas that are just as powerful as normal
> functions, but often when I want it the code is nicer when a normal
> function is used.
>
> / Anders
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/