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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
