Ken Manheimer wrote:
>
> However it seems to me to make exceeding sense to have the initial
> intrinsic settings specified as part of the object!
Indeed. It makes perfect sense to have _intial_, intrinsic attributes.
The problem is that currently they can't be specified for builtin objects.
Skip asked for existing solutions, so I've made a quick tour on the problem,
pointing him to 3).
> And, in the case of functions, it seems to me to be outstandingly
> consistent with python's treatment of objects.
Oustandingly consistent isn't my opinion, but that's fine with both of us.
If functions win this cause, the next imminent wish of all (Zope) users
will be to attach (protection, or other) attributes to *all* objects:
class Spam(...):
""" Spam product"""
zope_product_version = "2.51"
zope_persistency = 0
zope_cache_limit = 64 * 1024
def eggs(self): ...
def eats(self): ...
How would you qualify the zope_* attributes so that only the zope_product
version is accessible? (without __getattr__ tricks, since we're talking
about `metadata'). Note that I don't expect an answer :-). The issue is
crystal clear already. Be prepared to answer cool questions like this one
to your customers.
>
> I'm mystified about why you would reject that so adamantly!
Oops, I'll demystify you instantly, here, by summing up my posts:
I'm not rejecting anything adamantly! To the countrary, I've suggested more.
Greg said it quite well: Barry's proposal made me sending you signals
about different issues you've probably not thought about before, yet we'd
better sort them out before adopting his patch. As a member of this list,
I feel obliged to share with you my concerns whenever I have them.
My concerns in this case are:
a) consistency of the class model. Apparently this signal was lost in
outerspace, because my interpretation isn't yours. Okay, fine by me.
This one will come back in Py3K. I'm already curious to see what will
be on the table at that time. :-)
b) confusion about the namespaces associated with a function object.
You've been more receptive to this one. It's currently being
discussed.
c) generalize user-attributes for all builtin objects. You'd like to,
but it looks expensive. This one is a compromise: it's related
with sharing, copy on write builtin objects with modified user-attr, etc.
In short, it doesn't seem to be on the table, because this signal
hasn't been emitted before, nor it was really decrypted on python-dev.
Classifying objects as light and heavy, and attributing them specific
functionality only because of their "weight" looks very hairy.
That's all for now. Discussing these issues in prime time here is goodness
for Python and its users! Adopting the proposal in a hurry, because of the
tight schedule for 1.6, isn't. It needs more maturation. Witness the length
of the thread.
it's-vacation-time-for-me-so-see-you-all-after-Easter'ly y'rs
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
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