On Monday 15 July 2002 06:30 pm, Clark C . Evans wrote:
...
> If someone really insists on having check() exposed, the I
> don't see the harm... only that it makes the proposal seem more
> complicated than it is.
The harm of exposing check is encouraging the "look before you
leap" (LBYL) idiom:
if allconditionsgreenformetodothis():
dothis()
else:
print "oops, cant dothis"
rather than the generally more effective "it's easier to ask
forgiveness than permission" (EAFP) idiom:
try:
dothis()
except DoingThisWasWrongError:
print "oops, cant dothis"
With LBYL one more easily gets into duplication of work (the
effort of checking duplicates the effort of actually doing the
work) and multiprogramming issues (a check passes, but then
immediately afterwards the situation has changed...).
> | > The key thing about the Object Adaptation proposal is that it
> | > leaves wide open what it means to comply. This flexibility is
> |
> | Yes, but I see it as a minimum that a "compliant" object has
> | a set of methods callable with given signatures. If a protocol is
> | represented by a type, the set should comprise the type's methods.
>
> Yes. This would be an improvement of the proposal. How do we
> express this so that the protocol of core Types can do this
> sort of enforcement. Perhaps by giving the Protocol the ability
> to "veto" the final result?
Dunno. I do plan to devote substantial concentrated effort to
rewriting the PEP, and that's incompatible with my current
situation wrt finishing the Nutshell. Further delay should be
little problem given the time PEP 246 has already waited AND
the BDFL's indication that it's not going to get into 2.3 anyway,
so there's definitely no hurry.
Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4