bruno at modulix wrote:
> Blair P. Houghton wrote:
> > So Image.open(filename) seems right as a factory function that opens
> > the file, figures out what it really is, constructs the appropriate
> > subclass object (likely by passing a string to the constructor, e.g.,
> > JPGImage(filename)), and returns the object via the superclass type.
>
> Why "via the superclass type" ? "returns the object" is enough.

I'm just being pedantic; because we can't tell from the return
type what subclass type it is, we see it as an object of the
superclass type and then ask it what subclass type it is.

> > The caller can then either check a flag in the superclass to see what
> > type the subclass is,
>
> Why the h... ? We don't care what type it is, as long at it does what we
> expect it to do.

We might want to know what to expect.  A function returning a Person
may return a Man or a Woman,.  It could make a difference to our
Libido, so it's in our best interest to find out what was returned, so
we
can call the right methods specific to that subclass.

> > or just assume it's the right type of image
>
> Yes
>
> (snip)
> > (or does Python have RTTI?
>
> Much better than 'RTTI'.
>
> > I don't recall if
> > I've seen it, yet...).
>
> obj.__class__ is a reference to the class (which is itself an object...)

Shortly after I posted that I came across other posts mentioning
__class__
and I'm trying to grok it in fullness now.

> > Though if the filename doesn't match the content, someone should raise
> > an exception...
>
> Why ? filenames and extensions are nothing more than conventions.

Ostensibly.  But they're also a means of deceiving people, so the
handling
of a mismatch deserves care.  Whether that care takes the form of an
exception or by defensive coding (which is kind of what exceptions
simplify) is up to you.

> >  Image(string) could easily
> > default to assuming string is a filename, doing the same work as
> > Image.open(filename), though it would at least partially construct an
> > Image instance each time it's called, which isn't what you want.
> > Image.open(filename) defined as a static method (wait...is that
> > possible in Python? I hate being the newbie)
>
> It is (search for 'staticmethod' and 'classmethod'). But there's not
> much use for 'static methods' in Python - we usually just use plain
> functions ('classmethods' are another beast - much more useful than
> staticmethods)

Does it make any noticeable difference in efficiency, or does nobody
care much about efficiency in Python?

--Blair

-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to