[Python-Dev] PEP 343 update (with statement context terminology) (original) (raw)
Paul Moore p.f.moore at gmail.com
Tue Apr 25 10:05:47 CEST 2006
- Previous message: [Python-Dev] PEP 343 update (with statement context terminology)
- Next message: [Python-Dev] PEP 343 update (with statement context terminology)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 4/25/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
PEP 343 made a deliberate, conscious design decision to copy the semantics of iterators by making the context management protocol a superset of the context protocol (or rather, the context specification protocol in alpha 2).
OK. It's possible I'll need to go back to PEP 343 to locate the justification for this design decision (as I can't find it in the documentation). I haven't done so thus far, as I am deliberately trying to retain a position as "newcomer who has only ready the documentation", because I want to offer that perspective. I've been drawn so far into design discussions now, that I am probably no longer of any use in that role.
So now, I'm really just supporting Phillip's side of the discussion. Which isn't much help, as all we seem to be achieving is a 2 vs 1 impasse, rather than the previous 1 vs 1 :-(
What I don't understand is why you and Phillip are so keen on breaking this deliberate symmetry with an existing part of the language design. Of course it isn't necessary, but then neither was it necessary to make the iterator protocol a superset of the iterable protocol.
What I don't understand, is why the symmetry is so crucial to you.
OK, I'll give in on this one (as Philip has done). I'll accept that objects providing enter and exit must also provide context. I'll accept your argument above that the parallel with generators and iter is enough. I'll even accept that the name of the decorator is the only issue, and it's just a naming and documentation fix we're after here.
But that leaves one fundamental point (I'm tempted to shout here, but I won't :-))
I still found the alpha 1 terminology and documentation completely natural and intuitive. Completely. Not "acceptable", but "completely natural". From the perspective of someone with limited understanding of the design, looking to the documentation for enlightenment.
And that's got to be my last word. I can't judge the alpha 2 documentation any more, I'm too close to the problem now. Heck, I no longer even have usable terms to describe the objects involved, because every reference has to be qualified with (a1 terminology) or (a2 terminology).
So I'll bow out at this point. +1 on a1 terminology, can't judge on anything else. (Oh, and +100000 on just getting the damn thing resolved once and for all).
I hope my contributions have been useful.
Paul.
- Previous message: [Python-Dev] PEP 343 update (with statement context terminology)
- Next message: [Python-Dev] PEP 343 update (with statement context terminology)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]