[Python-ideas] For/in/as syntax

[Erik]

Hi Brice,

On 04/03/17 08:45, Brice PARENT wrote:
>> * Creating a real object at runtime for each loop which needs to be
>> the target of a non-inner break or continue

> However, I'm not sure the object should be constructed and fed for every
> loop usage. It should probably only be instanciated if explicitly asked
> by the coder (by the use of "as loop_name").

That's what I meant by "needs to be the target of a non-inner break or 
continue" (OK, you are proposing something more than just a referenced 
break/continue target, but we are talking about the same thing). Only 
loops which use the syntax get a loop manager object.

>> * For anything "funky" (my words, not yours ;)), there needs to be a
>> way of creating a custom loop object - what would the syntax for that
>> be? A callable needs to be invoked as well as the name bound (the
>> current suggestion just binds a name to some magical object that
>> appears from somewhere).

> I don't really understand what this means, as I'm not aware of how those
> things work in the background.

What I mean is, in the syntax "for spam in ham as eggs:" the name "eggs" 
is bound to your loop manager object. Where is the constructor call for 
this object? what class is it? That's what I meant by "magical".

If you are proposing the ability to create user-defined loop managers 
then there must be somewhere where your custom class's constructor is 
called. Otherwise how does Python know what type of object to create?

Something like (this is not a proposal, just something plucked out of 
the air to hopefully illustrate what I mean):

   for spam in ham with MyLoop() as eggs:
       eggs.continue()

> I guess it would be magical in the sense it's not
> the habitual way of constructing an object. But it's what we're already
> used to with "as". When we use a context manager, like "with
> MyPersonalStream() as my_stream:", my_stream is not an object of type
> "MyPersonalStream" that has been built using the constructor, but the
> return of __enter__()

By you have to spell the constructor (MyPersonalStream()) to see what 
type of object is being created (whether or not the eventual name bound 
in your context is to the result of a method call on that object, the 
constructor of your custom context manager is explicitly called.


If you are saying that the syntax always implicitly creates an instance 
of a builtin class which can not be subclassed by a custom class then 
that's a bit different.


> This solution, besides having been explicitly rejected by Guido himself,

I didn't realise that. Dead in the water then probably, which is fine, I 
wasn't pushing it.

> brings two functionalities that are part of the proposal, but are not
> its main purpose, which is having the object itself. Allowing to break
> and continue from it are just things that it could bring to us, but
> there are countless things it could also bring (not all of them being
> good ideas, of course), like the .skip() and the properties I mentioned,

I understand that, but I concentrated on those because they were easily 
converted into syntax (and would probably be the only things I'd find 
useful - all the other stuff is mostly doable using a custom iterator, I 
think).

I would agree that considering syntax for all of the extra things you 
mention would be a bad idea - which your loop manager object idea gets 
around.

> but we could discuss about some methods like forloop.reset(),
> forloop.is_first_iteration() which is just of shortcut to (forloop.count
> == 0), forloop.is_last_iteration()

Also, FWIW, if I knew that in addition to the overhead of creating a 
loop manager object I was also incurring the overhead of a loop counter 
being maintained (usually, one is not required - if it is, use 
enumerate()) I would probably not use this construct and instead find 
ways of restructuring my code to avoid it using regular for loops.


I'm not beating up on you - like I said, I think the idea is interesting.

E.