Re: [Python-ideas] if-statement in for-loop

[Greg Ewing]

Erik Bray wrote:

Then following my own logic it
would be desirable to also allow the nested for loop syntax of list
comprehensions outside them as well.


The only use for such a syntax would be to put
an inadvisable amount of stuff on one line.

When describing a procedural series of steps,
the Pythonic style encourages putting each step
on its own line. Other areas of the language also
nudge one in this direction, e.g. the fact that
mutating operations usually return None, which
discourages chaining them together into a single
expression.

--
Greg

___
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] Suggestion: Clear screen command for the REPL

[João Matos]

Hello,


It doesn't work in Windows.


Best regards,

JM


terça-feira, 27 de Setembro de 2016 às 16:40:42 UTC+1, Dennis Brakhane via 
Python-ideas escreveu:

> I don't know if it works on Windows, but at least in Linux pressing 
> Ctrl-L will do exactly what you describe (as long as the REPL uses 
> readline) 
>
> On 17.09.2016 12:51, João Matos wrote: 
> > Hello, 
> > 
> > I would like to suggest adding a clear command (not function) to Python. 
> > It's simple purpose would be to clear the REPL screen, leaving the >>> 
> > prompt at the top left of the screen. 
> > 
> > This is something very basic but also very useful for newbies learning 
> > Python from the REPL. 
> > After some trial and errors it is best to start with a clean screen. 
> > Clearing the screen helps clear your mind. 
> > 
> > Historically it is a common command in interpreted languages. 
> > 
> > Best regards, 
> > 
> > JM 
> > 
> > ___ 
> > Python-ideas mailing list 
> > python...@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] if-statement in for-loop

[Paul Moore]

On 27 September 2016 at 16:54, Erik Bray  wrote:
> Then following my own logic it
> would be desirable to also allow the nested for loop syntax of list
> comprehensions outside them as well.

I'd say that it's a case where we should either allow arbitrary
concatenation outside of comprehensions, or we allow none. And as
arbitrary concatenation is obviously bad, the only sane choice is no
nesting :-)

Paul
___
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] if-statement in for-loop

[Erik Bray]

On Tue, Sep 27, 2016 at 5:33 PM, Nick Coghlan  wrote:
> On 28 September 2016 at 00:55, Erik Bray  wrote:
>> On Sun, Sep 11, 2016 at 12:28 PM, Bernardo Sulzbach
>>  wrote:
>>> On 09/11/2016 06:36 AM, Dominik Gresch wrote:

 So I asked myself if a syntax as follows would be possible:

 for i in range(10) if i != 5:
 body

 Personally, I find this extremely intuitive since this kind of
 if-statement is already present in list comprehensions.

 What is your opinion on this? Sorry if this has been discussed before --
 I didn't find anything in the archives.

>>>
>>> I find it interesting.
>>>
>>> I thing that this will likely take up too many columns in more convoluted
>>> loops such as
>>>
>>> for element in collection if is_pretty_enough(element) and ...:
>>> ...
>>>
>>> However, this "problem" is already faced by list comprehensions, so it is
>>> not a strong argument against your idea.
>>
>> Sorry to re-raise this thread--I'm inclined to agree that the case
>> doesn't really warrant new syntax.  I just wanted to add that I think
>> the very fact that this syntax is supported by list comprehensions is
>> an argument *in its favor*.
>>
>> I could easily see a Python newbie being confused that they can write
>> "for x in y if z" inside a list comprehension, but not in a bare
>> for-statement.  Sure they'd learn quickly enough that the filtering
>> syntax is unique to list comprehensions.  But to anyone who doesn't
>> know the historical progression of the Python language that would seem
>> highly arbitrary and incongruous I would think.
>>
>> Just $0.02 USD from a pedagogical perspective.
>
> This has come up before, and it's considered a teaching moment
> regarding how the comprehension syntax actually works: it's an
> *arbitrarily deep* nested chain of if statements and for statements.
>
> That is:
>
>   [f(x,y,z) for x in seq1 if p1(x) for y in seq2 if p2(y) for z in
> seq3 if p3(z)]
>
> can be translated mechanically to the equivalent nested statements
> (with the only difference being that the loop variable leak due to the
> missing implicit scope):
>
> result = []
> for x in seq1:
> if p1(x):
> for y in seq2:
> if p2(y):
> for z in seq3:
> if p3(z):
> result.append(f(x, y, z))
>
> So while the *most common* cases are a single for loop (map
> equivalent), or a single for loop and a single if statement (filter
> equivalent), they're not only the forms folks may encounter in the
> wild.

Thanks for pointing this out Nick.  Then following my own logic it
would be desirable to also allow the nested for loop syntax of list
comprehensions outside them as well.  That's a slippery slope to
incomprehensibility (they're bad enough in list comprehensions, though
occasionally useful).

This is a helpful way to think about list comprehensions though--I'll
remember it next time I teach them.

Thanks,
Erik
___
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] if-statement in for-loop

[Nick Coghlan]

On 28 September 2016 at 00:55, Erik Bray  wrote:
> On Sun, Sep 11, 2016 at 12:28 PM, Bernardo Sulzbach
>  wrote:
>> On 09/11/2016 06:36 AM, Dominik Gresch wrote:
>>>
>>> So I asked myself if a syntax as follows would be possible:
>>>
>>> for i in range(10) if i != 5:
>>> body
>>>
>>> Personally, I find this extremely intuitive since this kind of
>>> if-statement is already present in list comprehensions.
>>>
>>> What is your opinion on this? Sorry if this has been discussed before --
>>> I didn't find anything in the archives.
>>>
>>
>> I find it interesting.
>>
>> I thing that this will likely take up too many columns in more convoluted
>> loops such as
>>
>> for element in collection if is_pretty_enough(element) and ...:
>> ...
>>
>> However, this "problem" is already faced by list comprehensions, so it is
>> not a strong argument against your idea.
>
> Sorry to re-raise this thread--I'm inclined to agree that the case
> doesn't really warrant new syntax.  I just wanted to add that I think
> the very fact that this syntax is supported by list comprehensions is
> an argument *in its favor*.
>
> I could easily see a Python newbie being confused that they can write
> "for x in y if z" inside a list comprehension, but not in a bare
> for-statement.  Sure they'd learn quickly enough that the filtering
> syntax is unique to list comprehensions.  But to anyone who doesn't
> know the historical progression of the Python language that would seem
> highly arbitrary and incongruous I would think.
>
> Just $0.02 USD from a pedagogical perspective.

This has come up before, and it's considered a teaching moment
regarding how the comprehension syntax actually works: it's an
*arbitrarily deep* nested chain of if statements and for statements.

That is:

  [f(x,y,z) for x in seq1 if p1(x) for y in seq2 if p2(y) for z in
seq3 if p3(z)]

can be translated mechanically to the equivalent nested statements
(with the only difference being that the loop variable leak due to the
missing implicit scope):

result = []
for x in seq1:
if p1(x):
for y in seq2:
if p2(y):
for z in seq3:
if p3(z):
result.append(f(x, y, z))

So while the *most common* cases are a single for loop (map
equivalent), or a single for loop and a single if statement (filter
equivalent), they're not only the forms folks may encounter in the
wild.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] if-statement in for-loop

[Erik Bray]

On Sun, Sep 11, 2016 at 12:28 PM, Bernardo Sulzbach
 wrote:
> On 09/11/2016 06:36 AM, Dominik Gresch wrote:
>>
>> So I asked myself if a syntax as follows would be possible:
>>
>> for i in range(10) if i != 5:
>> body
>>
>> Personally, I find this extremely intuitive since this kind of
>> if-statement is already present in list comprehensions.
>>
>> What is your opinion on this? Sorry if this has been discussed before --
>> I didn't find anything in the archives.
>>
>
> I find it interesting.
>
> I thing that this will likely take up too many columns in more convoluted
> loops such as
>
> for element in collection if is_pretty_enough(element) and ...:
> ...
>
> However, this "problem" is already faced by list comprehensions, so it is
> not a strong argument against your idea.

Sorry to re-raise this thread--I'm inclined to agree that the case
doesn't really warrant new syntax.  I just wanted to add that I think
the very fact that this syntax is supported by list comprehensions is
an argument *in its favor*.

I could easily see a Python newbie being confused that they can write
"for x in y if z" inside a list comprehension, but not in a bare
for-statement.  Sure they'd learn quickly enough that the filtering
syntax is unique to list comprehensions.  But to anyone who doesn't
know the historical progression of the Python language that would seem
highly arbitrary and incongruous I would think.

Just $0.02 USD from a pedagogical perspective.

Erik
___
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] Delay evaluation of annotations

[Neil Girdhar]

On Tue, Sep 27, 2016 at 5:01 AM Nick Coghlan  wrote:

> On 27 September 2016 at 17:29, Neil Girdhar  wrote:
> > On Friday, September 23, 2016 at 2:23:58 AM UTC-4, Nick Coghlan wrote:
> >> The difference between that and the "methods referring to the class
> >> they're defined in" case is that it's likely to be pretty normal to
> >> want to do the latter, so it may prove worthwhile to provide a cleaner
> >> standard spelling for it. The counter-argument is the general
> >> circularity one above: do you *really* need instances of the
> >> particular class being defined? Or is there a more permissive
> >> interface based type signature you could specify instead? Or perhaps
> >> no type signature at all, and let ducktyping sort it out implicitly at
> >> runtime?
> >
> > I agree that circularity should in general be avoided, but it's not
> always
> > possible or elegant to do that.  Sometimes you really need two classes to
> > refer to each other. In that case, why not expose your placeholder idea
> to
> > the user via a library? You have one function that generates placeholder
> > singletons (generate_placeholder()), and another function to walks a
> class
> > object and replaces a placeholder with a given value
> > (replace_placeholder(placeholder, cls, value)).
>
> Because the general case is already covered by using a quoted string
> instead of a name reference. "I don't like using strings to denote
> delayed evaluation" isn't a compelling argument, which is why
> alternative ideas have to offer some other significant benefit, or
> else be incredibly simple both to implement and to explain.
>

My motivation for something other than quoted strings is that there are
other instances of circular dependencies.  Currently, when I am forced into
a circular dependency, I import the later class in the member functions of
the first:

# module x
class X:
def f(self):
from y import Y
# do something with Y

# module y
class Y:
pass

That's not ideal and I don't see how to extend this solution to use of "y"
in class level definitions.

Best,

Neil


> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
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] Delay evaluation of annotations

[Paul Moore]

On 27 September 2016 at 13:46, Neil Girdhar  wrote:
> Yes, I understand that, but I don't see how that would help at all with
> annotations.  Aren't annotations also evaluated at "compile time"?

Yes, but a string whose value is a class name is treated as being the
same annotation (i.e., meaning the same) as the class itself.
Paul
___
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] Delay evaluation of annotations

[Nick Coghlan]

On 27 September 2016 at 17:29, Neil Girdhar  wrote:
> On Friday, September 23, 2016 at 2:23:58 AM UTC-4, Nick Coghlan wrote:
>> The difference between that and the "methods referring to the class
>> they're defined in" case is that it's likely to be pretty normal to
>> want to do the latter, so it may prove worthwhile to provide a cleaner
>> standard spelling for it. The counter-argument is the general
>> circularity one above: do you *really* need instances of the
>> particular class being defined? Or is there a more permissive
>> interface based type signature you could specify instead? Or perhaps
>> no type signature at all, and let ducktyping sort it out implicitly at
>> runtime?
>
> I agree that circularity should in general be avoided, but it's not always
> possible or elegant to do that.  Sometimes you really need two classes to
> refer to each other. In that case, why not expose your placeholder idea to
> the user via a library? You have one function that generates placeholder
> singletons (generate_placeholder()), and another function to walks a class
> object and replaces a placeholder with a given value
> (replace_placeholder(placeholder, cls, value)).

Because the general case is already covered by using a quoted string
instead of a name reference. "I don't like using strings to denote
delayed evaluation" isn't a compelling argument, which is why
alternative ideas have to offer some other significant benefit, or
else be incredibly simple both to implement and to explain.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Delay evaluation of annotations

[Neil Girdhar]

I really like this idea, and in the rare case that someone adds an element 
to a class with the same name as the class that would shadow your 
definition, but that seems fine to me.
 
On Thursday, September 22, 2016 at 11:09:28 PM UTC-4, Nick Coghlan wrote:
>
> On 23 September 2016 at 12:05, אלעזר  
> wrote:
> > On Fri, Sep 23, 2016 at 4:17 AM Nick Coghlan  > wrote:
> > ...
> >>
> >> As others have noted, the general idea of allowing either a
> >> placeholder name or the class name to refer to a suitable type
> >> annotation is fine, though - that would be a matter of implicitly
> >> injecting that name into the class namespace after calling
> >> __prepare__, and ensuring the compiler is aware of that behaviour,
> >> just as we inject __class__ as a nonlocal reference into method bodies
> >> that reference "super" or "__class__".
> >>
> > Just to be sure I understand, will the following work?
> >
> > class A:
> > def repeat(n: int) -> List[A]: pass
>
> Right now? No - you'll get a name error on the "A", just as you would
> if you tried to reference it as a default argument:
>
>   >>> class A:
>   ... def side_effects_ahead(arg: print(A) = print(A)) -> print(A): 
> pass
>   ...
>   Traceback (most recent call last):
> File "", line 1, in 
> File "", line 2, in A
>   NameError: name 'A' is not defined
>
> And that's the problem with using the class name in method annotations
> in the class body: they're evaluated eagerly, so they'd fail at
> runtime, even if the typecheckers were updated to understand them.
>
> Rather than switching annotations to being evaluated lazilly in the
> general case, one of the solutions being suggested is that *by
> default*, the class name could implicitly be bound in the body of the
> class definition to some useful placeholder, which can already be done
> explicitly today:
>
>   >>> class A:
>   ... A = "placeholder"
>   ... def side_effects_ahead(arg: print(A) = print(A)) -> print(A): 
> pass
>   ...
>   placeholder
>   placeholder
>   placeholder
>
> Since method bodies don't see class level name bindings (by design),
> such an approach would have the effect of "A" referring to the
> placeholder in the class body (including for annotations and default
> arguments), but to the class itself in method bodies.
>
> I don't think this is an urgent problem (since the "A"-as-a-string
> spelling works today without any runtime changes), but it's worth
> keeping an eye on as folks gain more experience with annotations and
> the factors affecting their readability.
>
> Cheers,
> Nick.
>
> -- 
> Nick Coghlan   |   ncog...@gmail.com|   Brisbane, 
> Australia
> ___
> Python-ideas mailing list
> python...@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] Delay evaluation of annotations

[Neil Girdhar]

On Friday, September 23, 2016 at 2:23:58 AM UTC-4, Nick Coghlan wrote:
>
> On 23 September 2016 at 15:50, Greg Ewing  > wrote:
> > אלעזר wrote:
> >>
> >> it feels like a
> >> placeholder for this meaning would be better.  E.g.:
> >>
> >> class A:
> >> def __add__(self, other: CLS) -> CLS: ...
> >
> >
> > That's fine for a class that refers to itself, but
> > what about classes that refer to each other? This
> > only addresses a small part of the problem.
>
> Same answer as with any other circular dependency: the code smell is
> the circular dependency itself, not the awkwardness of the syntax for
> spelling it. If the string based "circular reference here!" spelling
> really bothers you, refactor to eliminate the circularity (e.g. by
> extracting a base class or an implementation independent interface
> definition), rather than advocating to make the spelling less
> obnoxious.
>
> The difference between that and the "methods referring to the class
> they're defined in" case is that it's likely to be pretty normal to
> want to do the latter, so it may prove worthwhile to provide a cleaner
> standard spelling for it. The counter-argument is the general
> circularity one above: do you *really* need instances of the
> particular class being defined? Or is there a more permissive
> interface based type signature you could specify instead? Or perhaps
> no type signature at all, and let ducktyping sort it out implicitly at
> runtime?
>

I agree that circularity should in general be avoided, but it's not always 
possible or elegant to do that.  Sometimes you really need two classes to 
refer to each other.  In that case, why not expose your placeholder idea to 
the user via a library?  You have one function that generates placeholder 
singletons (generate_placeholder()), and another function to walks a class 
object and replaces a placeholder with a given value 
(replace_placeholder(placeholder, cls, value)).

Best,

Neil
 

> Cheers,
> Nick.
>
> -- 
> Nick Coghlan   |   ncog...@gmail.com|   Brisbane, 
> Australia
> ___
> Python-ideas mailing list
> python...@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/