On 5/15/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Having done the python-dev summary on this topic,
You have my deepest sympathy :-)
> So in some sense, PEP 340 was the reason for the lack of "enthusiasm";
> with the semantics laid out, people were forced to deal with a specific
> implementation instead of a variety of wild suggestions.
I'm not sure I agree with that - to me, PEP 340 felt like the
consolidation of the previous discussion. My feeling was "cool - we've
had the discussion, now we've formalised the results, maybe a few
details to tidy up and then we can see the implementation being
checked in". Then Nick's proposal *failed* to feel like the tidying up
of the details, and PEP 343 felt like giving up on the powerful (but
hard) bits. It's all people's impressions, though, so maybe I'm just
bitter and cynical :-)
Interestingly, some new ideas have started appearing again (the GUI
example someone raised yesterday, for instance). But with the current
"multiple PEPs" situation, I can't evaluate such ideas, as I've no
clue which of the various proposals would support them.
> > No-one is looking at PEP 343, or
> > Nick's PEP 3XX, and saying "hey, that's neat - I can do XXX with
> > that!". This makes me feel that we've thrown out the baby with the
> > bathwater.
>
> I'd be surprised if you can find many examples that PEP 340 can do
> that PEP 3XX can't.
In which cask, Nick is "marketing" it really badly - I hadn't got that
impression at all. And if Nick's proposal really *is* PEP 340 with the
issues people had resolved, how come Guido isn't supporting it?
(By the way, I agree with Philip Eby - Nick's proposal really needs to
be issued as a proper PEP - although if it's that close to just being
a fix for PEP 340, it should probably just be the new version of PEP
340).
> > (Yes, I know PEP 342 is integral to many of the neat
> > features, but I get the impression that PEP 342 is being lost - later
> > iterations of the other two PEPs are going out of their way to avoid
> > assuming PEP 324 is implemented...)
>
> Not very far out of their way.
Well, PEP 343 uses
def template():
before
yield
after
rather than
def template():
before
try:
yield
finally:
after
which I would argue is better - but it needs PEP 342 functionality.
OTOH, Guido argues there are other reasons for the PEP 343 style.
Also, the discussion has moved to resource objects with special
methods rather than generators as templates - which I see as a direct
consequence of PEP 342 being excluded. One of the things I really
liked about PEP 340 was the "generator template" style of code, with
yield as the "block goes here" placeolder
> If you want to get people enthused about PEP 342 again (which is the
> right way to make sure it gets excepted), what would really help is a
> bunch of good examples of how it could be used.
In my view, *every* PEP 340/343/3XX example when written in generator
form counts as a good example (see above). Neat coroutine tricks and
the like are the "additional benefits" - maybe bordering on abuses in
some cases, so I don't want to focus on them in case we get into
arguments about whether a feature is bad simply because it *can* be
abused... But the key use case, for me, *is* the generator-as-template
feature.
> I'm convinced that such a tone is inevitable after 30 days and over
> 700 messages on *any* topic. ;-)
Which is why I regret that Guido didn't just go ahead and implement
it, consensus be damned :-) I vote for a dictatorship :-)
> Ok, back to summarizing this fortnight's 380+ PEP 340 messages. ;-)
Best of luck - and in case you need a motivation boost, can I just say
that this sort of thread is why I have the greatest respect and
appreciation for the job the summarisers do.
Paul.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
