Chris Angelico writes:
> So [a "deferred object" is] a lambda function that gets called the
> moment you touch it in any way.
I'll take that as a question, though you present it like a fact. It's
a code object plus "other stuff" that gets called automatically when
dereferencing a name in most contexts (like a descriptor but works
with "plain" identifiers rather than attribute names). Other cases
I'm not sure about, and I don't know whether they can be resolved in a
way *generally* useful enough to make them worth adding. For example,
let a and b[0] both refer to a "deferred object".
1. The statement x = a will evaluate the contained expression.
2. I don't know when x = b[0] will evaluate the contained expression.
3. I don't know when f(a) will evaluate the contained expression.
4. There will be APIs such as "isdeferred(x)" and "unevalled x" that
do not evaluate the contained expression.
I think my answers are "2. before binding x" and "3. as in PEP 671",
but I'm somewhat unsure of both, since I don't know David's and Eric's
use cases. (FWIW, the alternatives I had in mind were "2. when x is
dereferenced" and "3. when a is dereferenced in the body of f". There
may be others.)
The "other stuff" mentioned above similarly depends on use cases that
I don't know. I suspect that "use cases I don't know" are
characteristic of everyone's reluctance to do a "generic deferred
evaluation" PEP. I get the feeling there are a number of them.
> > > (Another theoretical difference is that a deferred expression is
> > > parsed in the context of its *usage* rather than its *definition*, but
> > > that would break all manner of things in Python and is quite
> > > impractical.)
> >
> > I'm a little confused by "theoretical" and "parsed".
>
> What I mean is that I don't know whether you intend it one way or the
> other, so I don't know whether it's an actual difference in your
> proposal, or something that could in theory be.
Do you not realize that "you" is plural, and "proposal" is not unique
at this point? In particular, I was asking about you channelling
Eric. I was not making any statement about my own proposal (which is
starting to gel but until a day or so ago was 100% nonexistent), or
Eric's for that matter.
I still don't understand why time of parsing matters. Do you mean
time of compilation?
> If name lookups in these temporary expressions have to refer to
> names in the target function, not in their current context, it
> causes all kinds of problems.
That's what Ruby blocks do, and Rubyists love them. They certainly
don't think blocks have huge problems.
Alternatively, it would certainly be possible to do as Common Lisp
does, and provide for optional closure over creation-time arguments as
well as access to namespaces active at evaluation time via explicit
APIs. Sure, all this would be complex, and maybe "too complicated to
be a good idea". On the other hand, there may be other use cases that
can take advantage of evaluation of a simple reference to z after
z = defer foo(*args) besides the case of late binding of function
arguments. If those use cases are sufficiently compatible and
compelling, it may be possible to define the implicit APIs and add
explicit APIs as needed in the future.
> Is that your intention? Otherwise, what is x there?
I don't understand why you are pushing so hard for these details, when
I doubt any of the advocates of a more general deferred evaluation
facility have communicated with each other yet, and the details
probably vary substantially. And even David has acknowledged that he
doesn't have a worked-out proposal at the moment, only a wisp of a
threat to write one.
It's reasonable to say, as you have, "my proposal is the only one on
the table." That's true (and acknowledged by all who prefer to wait
for a generic deferred evaluation proposal), but existence of a
proposal is a necessary condition for adoption, not sufficient. If
nonexistence of a competing proposal is not the point you're trying to
make, I'm not sure what you're after in this subthread.
Please don't waste your time answering any implicit questions in this
post. If you find them interesting, go right ahead, but I'm not
asking for answers from you, I'm trying to provide answers to your
questions as I understand them. (David, Eric, and any lurkers may
have different answers, though!)
Regards,
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TQVLHXENCFAMQCCBLC2KIUFUPU5PMEGU/
Code of Conduct: http://python.org/psf/codeofconduct/
