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