conceiling function calls..

[Alex Martelli]

Emile van Sebille wrote:

> Gonçalo Rodrigues:
>> Can you explain why you would want to do that? What possible gain
> can
>> you have by counfounding name lookup with calling?
>>
> 
> Well, I can't explain for the OP, but I found it (some years ago...
> I'm not sure I'd do the same thing now) convenient in a prototype
> minimalist database application.  Data fields could always be inferred
> if not actually present in the instance.  Thus when programming you
> could write:
>     duedate = order.shipdate + order.terms.duedays
> without shipdate or terms being attributes of order.
> 
> Similarly,
>     lineextenion = lineitem.qty * lineitem.price
> without price or print the destination address without having
> designated a shipto.
> 
> This allowed order entry to get along with only the minimum "how many
> of what go where" being entered.  Everything else could be swizzled up
> when needed if not present.  I specifically wanted the data structure
> to be an implementation detail.

I see your use case as perfectly fine and totally unconnected to
the OP's requirement.  The concept of a property or dynamically
fetched attribute of an object, such as your 'order' or 'lineitem',
is perfectly fine (it is, however, valse that shipdate or terms
would not be attributes of order -- hasattr would show this as
being false -- if they can be accessed with this syntax, they ARE
attributes, by Python's definition, even if they're computed via
the property or __getattr__ routes).

Having x.y "mean" x().y for some _function_ x is quite a different
thing.  _Functions_ don't have __getattr__ nor properties, they do
have a simple dictionary where you can set arbitrary attributes
and later fetch them back again, that's all.  Properties and other
dynamically computed/fetched attributes are typical of instamces of
some user-coded classes that need such dynamism, not of functions.


Alex