Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Steven D'Aprano]

On Sat, May 26, 2018 at 02:06:40AM +0200, Michael Lohmann wrote:

> I propose to add some mechanism that can automatically collect everything
> what would normally be collected by **kwargs in the __init__ method and
> directly pass it through to the super().__init__ call without being
> accessible in the __init__ itself. This way the autocompletion/docstring
> generation could safely ignore this argument which before would have showed
> up as **kwargs.

Why is this an advantage? Consider the following scenario: you are 
reading an unfamiliar code base and come across a class instantiation:

obj = Aardvark(27, spam=3, eggs=5, cheese=True)

So you look up help(Aardvark), and it tells you that the signature is

Aardvark.__init__(self, foo)

What the hell? If Aardvark.__init__ only takes a single argument (aside 
from self), why on earth isn't it an error to pass those keyword 
arguments?

If you're a beginner, this is probably going to be a mind-melting 
WTF-I-don't-even moment.

And even if you're *not* a beginner, it will probably cause a momentary 
sense of existential dread as, for a moment, everything you thought you 
understood about Python seems wrong. And then you remember that there's 
an obscure feature that tells the class to lie to you about what 
parameters it takes.

It is bad enough when a method collects a bunch of parameters under 
**kwargs and I have to pour through the documentation for all its super 
classes to work out what they are. But at least the use of an explicit 
**kwargs gives me a clue that this is what is going on.

Making **kwargs implicit and invisible reminds me of the old saying 
about coding for maintenance. To paraphrase:

Design language features as if your language's users -- all of
them -- are violent psychopaths who know where you live.


[...]
> With the current python version the code would have looked like
> 
> class A:
> def __init__(self, a_value, **kwargs):
> super().__init__(**kwargs)
> 
> But the user could have had the false impression that additional kwargs
> could be given when instantiating A.

But they *can* be given when instantiating A. What makes you think they 
can't be?


> Obviously they are purely there for
> getting the init in the MRO working with multiple inheritance.

That's not always true. Even if it were true, it isn't obviously true.



-- 
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/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Carl Smith]

> But the user could have had the false impression that additional kwargs
> could be given when instantiating A. Obviously they are purely there for
> getting the init in the MRO working with multiple inheritance.

This just isn't true. You often do things with the kargs before passing them
or other values to super. By using **kargs in the constructor and the call
to
`super`, you are indicating that the signature passes through, but there are
many other things you could do instead.

The docs *should* show that the derived method takes the same args as the
inherited one it overrides. That is very useful information that belongs
there.

Best,

-- Carl Smith
carl.in...@gmail.com

On 26 May 2018 at 01:06, Michael Lohmann 
wrote:

> Hi!
>
> ***Disclaimer: I am relatively new to Python***
>
> I propose to add some mechanism that can automatically collect everything
> what would normally be collected by **kwargs in the __init__ method and
> directly pass it through to the super().__init__ call without being
> accessible in the __init__ itself. This way the autocompletion/docstring
> generation could safely ignore this argument which before would have showed
> up as **kwargs.
>
> I believe that this could greatly enhance the readability of automated
> documentation and especially the autocomplete of an IDE.
>
> I would like something like this to work:
>
> class A:
> @pass_through_kwargs  # like this? Or maybe  __init__(self,
> a_value, ***pass_through_kwargs)?
> def __init__(self, a_value):
> super().__init__()  # <- realize that nothing is passed in here
>
> class B:
> def __init__(self, some_value):
> pass
>
> class MyClass(A, B):
> def __init__(self):
> super().__init__(a_value=1, some_value=2)
>
> Where the autocomplete of `A(` shows me just `A(a_value)`. The
> pass_through_kwargs can safely be ignored, since it is not "a real input"
> of A. It is automatically merged with the parameters of the `super(A,
> self).__init__()` call. How exactly this should be done would have to be
> discussed in more detail (I guess the actual values should probably
> override the passed through ones).
>
> With the current python version the code would have looked like
>
> class A:
> def __init__(self, a_value, **kwargs):
> super().__init__(**kwargs)
>
> But the user could have had the false impression that additional kwargs
> could be given when instantiating A. Obviously they are purely there for
> getting the init in the MRO working with multiple inheritance.
>
> One could also add something like pass_through_args as well but the
> usability of that is probably much more limited.
>
> Could this even work in theory? I guess it might be quite tricky since
> `super().__init__` doesn't even have to be called. If that would be the
> case: should it be called automatically if pass_through_kwargs were given
> after the init is done?
>
>
> By the way: Thank you all for this amazing language!
> Cheers, Michael
>
> ___
> 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] ternary without else

[Carl Smith]

​You cannot have `expression if expression` in a language that also supports
`expression if expression else expression` (like Python).​ Otherwise, you
have
the dangling else problem:

https://en.wikipedia.org/wiki/Dangling_else

-- Carl Smith
carl.in...@gmail.com

On 25 May 2018 at 15:21, Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

>
>
> On 25/05/2018 12:38, Steven D'Aprano wrote:
>
>>
>> PEP 8 is not holy writ. Ignore it when your code is better for ignoring
>> it.
>>
>>
>> +1.  Not infrequently I judge that my code is easier both to read and to
> maintain with more than 1 (short) statement on a line,
> often when it allows similar items to be aligned vertically.  A
> spur-of-the moment, totally invented example:
> if MON <= day <= FRI:Rate = Normal
> if day==SAT: Rate = DoubleTime
> if day==SUN:Rate = TripleTime
> I also feel no inhibitions about using Jacco's original example:
> if cond: do_something
> Rob Cliffe
>
> ___
> 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] Proposal: A Reduce-Map Comprehension and a "last" builtin

[Tim Peters]

[Peter O'Connor]
>> ...
>> We could use given for both the in-loop variable update and the variable
>> initialization:
>>smooth_signal =  [average given average=(1-decay)*average + decay*x
>> for x in signal] given average=0.

[Steven D'Aprano ]
> I don't think that will work under Nick's proposal, as Nick does not
> want assignments inside the comprehension to be local to the surrounding
> scope. (Nick, please correct me if I'm wrong.)

Nick appears to have moved on from "given" to more-general augmented
assignment expressions.  See PEP 577, but note that it's still a
work-in-progress:

https://github.com/python/peps/pull/665


Under that PEP,

average = 0
smooth_signal =  [(average := (1-decay)*average + decay*x)
 for x in signal]

Or, for the running sums example:

total = 0
sums = [(total += x) for x in data]

I'm not entirely clear on whether the "extra" parens are needed, so
added 'em anyway to make grouping clear.
___
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] Make asyncio.get_event_loop a builtin

[Mark E. Haase]

asyncio.coroutine and async def are slightly different—not synonyms. The
former defines a generator function and the latter defines a coroutine
function. Generators and coroutines are very similar in Python (they share
lots of code in the CPython implementation) but coroutines are preferred
for async programming. Furthermore, yield from (suspend a generator) and
await (suspend a coroutine) are also similar but not synonyms.

It is surprising that Python's async syntax isn't tightly bound to its
built-in implementation of asynchronous I/O. This was a shrewd decision
that—as others have pointed out—permits a variety of event loop
implementations. The downside—as you point out—is that there is no built-in
function that can drive an async function.

On Thu, May 24, 2018 at 8:42 PM, Ken Hilton  wrote:

> On Tue May 22 22:08:40 (-0400), Chris Barker wrote:
> > while asyncio is in the standard library, it is not intended to be THE
> async event loop implementation
>
> I'm surprised this is true - with dedicated syntax like async def/await,
> it's still not THE async event loop implementation? As far as I know,
> "async def" is a shorthand for
>
> @asyncio.coroutine
> def
>
> and "await" is short for "yield from".
>
> Sincerely,
> Ken Hilton;
>
> ___
> 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] ternary without else

[Rob Cliffe via Python-ideas]

On 25/05/2018 12:38, Steven D'Aprano wrote:


PEP 8 is not holy writ. Ignore it when your code is better for ignoring
it.


+1.  Not infrequently I judge that my code is easier both to read and to 
maintain with more than 1 (short) statement on a line,
often when it allows similar items to be aligned vertically.  A 
spur-of-the moment, totally invented example:

    if MON <= day <= FRI:    Rate = Normal
    if day==SAT: Rate = DoubleTime
    if day==SUN:    Rate = TripleTime
I also feel no inhibitions about using Jacco's original example:
    if cond: do_something
Rob Cliffe
___
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] Reuse "for" to express "given"

[Rob Cliffe via Python-ideas]

On 24/05/2018 16:54, Alexander Belopolsky wrote:
I have read most of the PEP 572 related threads, but I don't think 
I've seen this idea.  As many other people mentioned, Python already 
allows a trick to introduce local bindings in generator expressions 
and list comprehensions.  This can be achieved by adding a "for var in 
[]" clause. I propose to make "for var = " have the same 
effect as "for var in []".



I made this exact same suggestion some time ago (not in the context of 
PEP 572).  Guido rejected it because it is easy (especially for newbies) 
to confuse

    for var in expr
    for var = expr
I point out that the confusion is particularly acute in the cases such as
    for x = SomeTuple
Rob Cliffe
___
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] ternary without else

[Jacco van Dorp]

2018-05-25 14:57 GMT+02:00 Elazar :
> The title is misleading - this has nothing to do with the conditional
> operator, except small syntactic similarity.

On second look, yeah, you're right.
___
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] ternary without else

[Steven D'Aprano]

On Fri, May 25, 2018 at 12:06:42PM +0200, Jacco van Dorp wrote:
> I would like to carefully suggest a half form of the ternary expression.
[...]
> However, this isn't PEP8 compliant

PEP 8 is not holy writ. Ignore it when your code is better for ignoring 
it.


> I would very much like to write:
> 
> >>> do_something if cond
> 
> and be done with it. Like a ternary expression but without the else clause.

I believe there are a number of languages out there which have clauses 
like this. I'm not going to do a language survey, but two popular 
choices are:

something if condition

something unless condition

and similar variations. For example, Ruby:

http://www.railstips.org/blog/archives/2008/12/01/unless-the-abused-ruby-conditional/



> ===Example Usecases===
> (inside loop)
> >>> continue if x > 50

That's not going to work if this is an *expression*. You can't say:

continue if x > 50 else "don't continue"

The problem with an expression is, what does this return if the clause 
is false? So the comparison to the ternary if expression is invalid. 
This would have to be a statement.



> 
> (logging)
> >>> logger.info(f"{var}") if DEBUG
> (Logging module ofc already does this, and in a much better way.
> However, if var is expensive to get it could save a bit of time.)

If the logging module already solves this problem in "a much better 
way", why are you including a much worse way?


> (singleton creation)
> >>> cls.inst = super().__new__(cls, *args, **kwargs) if cls.inst is None

And this is a problem: that is ambiguous with the if...else ternary 
expression. Presumably you want that to look like a statement:

cls.inst = super().__new__(cls, *args, **kwargs)

guarded by an if statement:

if cls.inst is None

but it can also be interpreted as an assignment:

cls.inst = 

with an incomplete ternary expression:

super().__new__(cls, *args, **kwargs) if cls.inst is None
else what

Even if we decide to make it a rule that one interpretation beats the 
other, we still have to expect people will be confused by it. So we 
ought to be cautious about syntax which is ambiguous in this way.

> (cache)
> >>> cache.warm() if cache is None

There are about a zillion things that you can write like this:

if condition:
do something


so the use-cases certainly exist. The only question is a matter of taste 
and familiarity, whether it nicer to write it as above or like:

do something if condition


-- 
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/

Re: [Python-ideas] ternary without else

[Elazar]

The title is misleading - this has nothing to do with the conditional
operator, except small syntactic similarity.

Elazar

בתאריך יום ו׳, 25 במאי 2018, 05:40, מאת Jacco van Dorp ‏<
j.van.d...@deonet.nl>:

> 2018-05-25 14:26 GMT+02:00 Kirill Balunov :
> > If it is an expression, what should `do_something if cond` return on
> > failure? If you don't care you can already use `cond and do_something`.
>
> Duh, forgot to mention.
> I wouldn't have it return anything. Ternary returns something because
> you have two options and picks one. This is conditional execution of a
> statement. I guess it would be a statement, like normal if.
>
> I guess cond and do_something would be equivalent, but that's not
> really the intention of and/or, no matter how much it's used for this
> sort of thing.
>
> Disclaimer:
> I don't really expect this to be accepted. It's more of a minor gripe
> i've occasionally had. This afternoon, I wrote:
>
> if not article["art_wt"]: article["art_wt"] = 0
> if not article["px_pchs"]: article["px_pchs"] = 0
> if not article["px_calc"]: article["px_calc"] = 0
> if not article["px_sell"]: article["px_sell"] = 0
>
> while preparing a dict for import in accountview. I try not to make a
> habit of dismissing syntax warnings. I consider the code above
> abundantly clear (no, I dont know what those keys mean. Since I have
> no power over that, I dont consider it detrimental to clarity.)
> ___
> 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] ternary without else

[Jacco van Dorp]

2018-05-25 14:26 GMT+02:00 Kirill Balunov :
> If it is an expression, what should `do_something if cond` return on
> failure? If you don't care you can already use `cond and do_something`.

Duh, forgot to mention.
I wouldn't have it return anything. Ternary returns something because
you have two options and picks one. This is conditional execution of a
statement. I guess it would be a statement, like normal if.

I guess cond and do_something would be equivalent, but that's not
really the intention of and/or, no matter how much it's used for this
sort of thing.

Disclaimer:
I don't really expect this to be accepted. It's more of a minor gripe
i've occasionally had. This afternoon, I wrote:

if not article["art_wt"]: article["art_wt"] = 0
if not article["px_pchs"]: article["px_pchs"] = 0
if not article["px_calc"]: article["px_calc"] = 0
if not article["px_sell"]: article["px_sell"] = 0

while preparing a dict for import in accountview. I try not to make a
habit of dismissing syntax warnings. I consider the code above
abundantly clear (no, I dont know what those keys mean. Since I have
no power over that, I dont consider it detrimental to clarity.)
___
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] ternary without else

[Kirill Balunov]

2018-05-25 13:06 GMT+03:00 Jacco van Dorp :

> [...]
>
> I would very much like to write:
>
> >>> do_something if cond
>
> and be done with it. Like a ternary expression but without the else clause.
>
>
If it is an expression, what should `do_something if cond` return on
failure? If you don't care you can already use `cond and do_something`.

With kind regards,
-gdg
___
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] ternary without else

[Philipp A.]

in jinja, you can do “{{ 'foo' if bar }}”.

it evaluates to “'foo'” or an empty string (differently to python’s
formatting, “None” expands to an empty string in jinja)

similarly I often do “thing = 'foo' if bar else None” and it would be nice
if i could shorten that by making “else None” implicit.

idk how often other people do that though

Serhiy Storchaka  schrieb am Fr., 25. Mai 2018 um
12:34 Uhr:

> 25.05.18 13:06, Jacco van Dorp пише:
> > I would like to carefully suggest a half form of the ternary expression.
> >
> > Currently, you can write code like:
> >
>  if cond:
>  do_something
> >
> > However, especially if the condition and action are both really
> > simple, taking two lines feels like a bit of a waste. So I sometimes
> > write:
> >
>  if cond: do_something
> >
> > However, this isn't PEP8 compliant, and every linter complains about
> > it. They'd be right if the condition and action were a bit more
> > complicated.
> >
> > I would very much like to write:
> >
>  do_something if cond
> >
> > and be done with it. Like a ternary expression but without the else
> clause.
>
> This isn't PEP8 compliant either.
>
> I suppose that if this syntax be accepted by the compiler, it will be
> explicitly disallowed by PEP8 for the same reason as "if cond:
> do_something".
>
> It is easier to pass an option to linter that will silence this warning
> than introduce a new ambiguous syntax.
>
> For example try to interpret "[a for b if c]" if "b if c" be a valid
> expression.
>
> ___
> 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] ternary without else

[Serhiy Storchaka]

25.05.18 13:06, Jacco van Dorp пише:

I would like to carefully suggest a half form of the ternary expression.

Currently, you can write code like:


if cond:
do_something


However, especially if the condition and action are both really
simple, taking two lines feels like a bit of a waste. So I sometimes
write:


if cond: do_something


However, this isn't PEP8 compliant, and every linter complains about
it. They'd be right if the condition and action were a bit more
complicated.

I would very much like to write:


do_something if cond


and be done with it. Like a ternary expression but without the else clause.


This isn't PEP8 compliant either.

I suppose that if this syntax be accepted by the compiler, it will be 
explicitly disallowed by PEP8 for the same reason as "if cond: 
do_something".


It is easier to pass an option to linter that will silence this warning 
than introduce a new ambiguous syntax.


For example try to interpret "[a for b if c]" if "b if c" be a valid 
expression.


___
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] ternary without else

[Jacco van Dorp]

I would like to carefully suggest a half form of the ternary expression.

Currently, you can write code like:

>>> if cond:
>>>do_something

However, especially if the condition and action are both really
simple, taking two lines feels like a bit of a waste. So I sometimes
write:

>>> if cond: do_something

However, this isn't PEP8 compliant, and every linter complains about
it. They'd be right if the condition and action were a bit more
complicated.

I would very much like to write:

>>> do_something if cond

and be done with it. Like a ternary expression but without the else clause.

I know this is probably not gonna make it due to "not strong enough
pro's, just swallow the linters complaints and roll with the 'if cond:
do_something' if you care so much about that 1 line", but I still
wanted to make my case.

===Example Usecases===
(inside loop)
>>> continue if x > 50

(logging)
>>> logger.info(f"{var}") if DEBUG
(Logging module ofc already does this, and in a much better way.
However, if var is expensive to get it could save a bit of time.)

(singleton creation)
>>> cls.inst = super().__new__(cls, *args, **kwargs) if cls.inst is None

(cache)
>>> cache.warm() if cache is None
___
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] Make asyncio.get_event_loop a builtin

[João Santos]

Hi,

You can use uvloop , for example,
without using asyncio:

import uvloop
loop = uvloop.new_event_loop()
loop.run_forever()


Best regards,
João Santos

On Fri, 25 May 2018 at 02:42, Ken Hilton  wrote:

> On Tue May 22 22:08:40 (-0400), Chris Barker wrote:
> > while asyncio is in the standard library, it is not intended to be THE
> async event loop implementation
>
> I'm surprised this is true - with dedicated syntax like async def/await,
> it's still not THE async event loop implementation? As far as I know,
> "async def" is a shorthand for
>
> @asyncio.coroutine
> def
>
> and "await" is short for "yield from".
>
> Sincerely,
> Ken Hilton;
> ___
> 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/