can i implement virtual functions in python ?
Andrew Dalke
adalke at mindspring.com
Wed Oct 1 16:24:13 EDT 2003
Alex:
> I think the "guaranteed to be unique" comment SHOULD make it
> pretty obvious (to Pythonistas advanced enough to grasp the
> try/except/else construct that we both prefer).
True. I don't like making the comment since it feels like I'm
using a side effect of the implementation.
> Actually if you object to the "class creation" (which IS also
> a standard construct:-), use ANY mutable object instead, e.g.:
Ahh, of course. Is that guaranteed in the language spec?
For example, suppose I had
x = []
y = []
assert x is not y
Could a future Python implementation support copy-on-write
and return a reference to the same empty list, but which
becomes a different list on mutation?
Here's what the docs say:
] Every object has an identity, a type and a value. An object's
] identity never changes once it has been created; you may
] think of it as the object's address in memory. The `is' operator
] compares the identity of two objects; the id() function returns
] an integer representing its identity (currently implemented as its
] address).
In order for my conjecture to occur, x and y would have to
have the same id, as that's what the 'is' test uses. But since
since the id is fixed over the lifetime of an object, copy-on-write
won't change it, so all lists which start as [] would have the
same id. Since I'm supposed to think of the id as a position
in memory, I have to assume that two objects with the same
id are the same object, so no, a future implementation cannot
make this change.
> > In any case, remember that I said it's a personal preference,
>
> Yeah, that's probably what's rubbing on people's nerves -- there
> is SUPPOSED TO BE "ideally only one obvious way". Maybe it
> would help if we were Dutch;-).
I'm 1/4th Dutch; is that my problem? :)
No, you're right. I'm a proponent of the "preferably only one
obvious way to do it" guideline. Why do I consider this a personal
preference?
When I use default arguments and need to distinguish between
a 1 argument and a 2 argument call (which is rare), I'll use
class _undefined: pass
def function(a, b = _undefined):
if b is _undefined:
...
In addition, if I need to do several test for exists/doesn't exist
(also rare) then I'll do
class _undefined: pass
x = getattr(obj, "blah", _undefined)
if x is _undefined:
...
y = getattr(obj, "blarg", _undefined)
if y is _undefeind:
...
because it's more concise than the try/except/else approach.
Interesting. I looks like my internal guideline is to use
t/e/e iff the test is needed once and if a _undefined object
is not defined in the module, else use an _undefined.
That seems inelegant. If there's a prefered style for this
then it seems it should be the use of an _undefined object
and not t/e/e.
Comments?
Andrew
dalke at dalkescientific.om
More information about the Python-list
mailing list