On 11 October 2001, Michael McLay said:
> Parsing docstrings to get the type definitions is a pragmatic work-around,
> but the features of Grouch would benefit by giving them direct language
> support.
Yes indeed.
> That's what the TypedSlots class does, so I think we are on the same page
> regarding what features are needed.
I'm sorry, I must have missed something. What is TypedSlots and where
is it defined/documented?
> Are you walking the object graph to enforce the type because it isn't
> possible to enforce them at creation time in the current Python language?
More-or-less. I think it's possible to do that with a classic
__setattr__, but I avoided going that way out of performance concerns.
We run Grouch on our database nightly to detect any type errors that may
have crept in in the last 24 hours. That's kinda weird, and specific to
applications that work primarily on a large, persistent data store.
Using Grouch in another context would require custom coding to query the
object schema API for type-correctness of an object or whole object
graph.
> The TypedSlots concept never allows the instance variables to be populated
> with anything but the allowed types.
Let me see if I have this straight: __slots__, a built-in feature of
new-style classes, catches "self.nubmer = 3" when you meant
"self.number = 3". TypedSlots, which I've never heard of before,
adds to this by catching "self.number = '3'". Correct?
Question: does use of __slots__ guarantee that self.foo is always there?
Or do you still have to create it in __init__?
> The primary advantage of __slots__ in Python is a reduction in memory
> usage.
Gee, I would have said the primary advantage is catching
"self.nubmer = 3".
> The TypedSlots mechanism would only apply to the variables
> defined with the new __slots__ mechanism. Would this the constraint be a
> problem for the types of applications you are building with Grouch?
Not at all. I nearly leapt out of my seat with joy when I saw __slots__
for the first time.
In the short term, we (the MEMS Exchange virtual fab, the project for
which I wrote Grouch) are utterly dependent on ZODB and ExtensionClass,
so won't be able to use new-style classes until ExtensionClass is dead
and ZODB is switched to use new-style classes. So Grouch will continue
to work as-is for a while. (It already knows about two types of Python
classes, namely classic classes and ExtensionClass. Adding a third
shouldn't be *too* hard .... >famous last words<)
Greg
--
Greg Ward - Linux weenie gward@python.net
http://starship.python.net/~gward/
If you and a friend are being chased by a lion, it is not necessary to
outrun the lion. It is only necessary to outrun your friend.
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