[Python-ideas] For/in/as syntax

[Brice PARENT]

Hi Erik,

>> 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".
It's what I thought, thanks for the clarification.
>
> 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?
I wasn't thinking about a custom object, although this syntax wouldn't 
ease the process of customizing the looping behaviour itself.
>
> 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 get it.
If there are use cases where we'd like to use a custom loop type, it 
surely gets a bit more complicated, but we could find some alternative 
syntaxes like yours or one of those :

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

or

for spam in ham as (MyLoop, eggs):
     # When it's a 2-tuple, first element is the class, second the 
instance. But I'm not sure about a tuple where one value is to be read 
while the other is assigned to...
     eggs.continue()

or

eggs = MyLoop()
for spam in ham using eggs:
     # I particularly dislike this one...
     eggs.continue()


But anyway, I'm not sure we're yet at this point of the thinking!
>
>
>> 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).
Probably, i'll probably try to implement those as I've needed one or the 
other some times already.
>
> 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 would certainly not enforce the users to use this syntax, nor the 
system to maintain the object if it is not instanciated explicitly by 
the user.
Also, I don't know how it works behind the doors, so I have no idea 
whether having such an object and a counter (which is probably the only 
things to maintain, as everything else just depend on the counter) would 
change a lot the cost of the loop in term of speed and memory (and 
anything else).
>
>
> I'm not beating up on you - like I said, I think the idea is interesting.
Don't worry, I didn't think you were. I like this idea as I think it 
could be of a good help to many people, but it doesn't get much traction 
here, so I probably overestimate it!

Brice