Webware for Python

On Wed, 2002-09-04 at 02:02, Edmund Lian wrote:
> 
> On 09/04/2002 02:41:19 AM Ian Bicking wrote:
> 
> >It *is* 2.2 compatible (AFAIK), I think you are proposing that it should
> >use 2.2 features.  This would make it incompatible with pre-2.2 Python.
> 
> Are you sure about this Ian? AFAIK, calls like super() and use of the new
> multiple inheritance method resolution algorithm are only possible with new
> style classes. Since none of the Webware servlet classes uses 'object' (as
> opposed to 'Object', the mother of all Webware objects) as a base class,
> then by default none of the servlet classes supports Python 2.2 stuff to
> the full extent. For example, when I experimented with this the other day,
> I got  a  "TypeError: super() argument 1 must be type, not class" message
> in the traceback.
> 
> The inheritance chain used in Webware for servlets is: NamedValueAccess -->
> Object --> Servlet --> HTTPServlet --> Page. Making Webware use object as
> the base class so that one can use super() etc. does not appear to be as
> simple as having NamedValueAccess subclass object. It makes other parts of
> Webware blow up.

I think you are still confusing 2.2-compatibility with taking advantage
of 2.2 features.  Webware is 2.2 compatible, but does not use any 2.2
features.  If it did it would *require* 2.2.  I'm sure you are correct
that Webware would require some changes to the base system to make
things like super() work.  It seems like it's best to wait until there's
some more significant features of new-style classes before Webware gets
rid of backward compatibility, though.  (Properties would be one such
feature, but I don't know if anyone is certain how/where/if they should
be used right now).

  Ian

On 09/04/2002 03:37:12 AM Ian Bicking wrote:

>I think you are still confusing 2.2-compatibility with taking advantage
>of 2.2 features.  Webware is 2.2 compatible, but does not use any 2.2
>features.  If it did it would *require* 2.2.  I'm sure you are correct
>that Webware would require some changes to the base system to make
>things like super() work.  It seems like it's best to wait until there's
>some more significant features of new-style classes before Webware gets
>rid of backward compatibility, though.  (Properties would be one such
>feature, but I don't know if anyone is certain how/where/if they should
>be used right now).

Oh, I guess I'm using compatibility in a stronger sense than you. What
you're describing is sounds like minimal compatibility to me. Full
compatibility would mean that Webware ran with Python 2.2, did not use any
of the new features so that it was backwards compatible with earlier
Pythons, but allowed one to use the new Python features if one wanted to.

In fact, the situation is greyer. I do use Python 2.2 features in all the
objects that I create and instantiate in Webware. I just can't use the
features in any subclass of Servlet or any subclass that mixes in my
objects (because of the assertion in line 187 of ServletFactory--or is the
failure of the assertion unrelated to Python 2.2?).

...Edmund.

On 09/04/2002 08:51:00 AM I  wrote:

>In fact, the situation is greyer. I do use Python 2.2 features in all the
>objects that I create and instantiate in Webware. I just can't use the
>features in any subclass of Servlet or any subclass that mixes in my
>objects (because of the assertion in line 187 of ServletFactory--or is the
>failure of the assertion unrelated to Python 2.2?).

I just checked... it is indeed true that mixins to any Servlet subclass
cannot be new style classes due to the assertion in line 187 of
ServletFactory. If you comment out that assertion, Webware is happy to use
new style class mixins.

...Edmund.

Edmund Lian wrote:
> I just checked... it is indeed true that mixins to any 
> Servlet subclass
> cannot be new style classes due to the assertion in line 187 of
> ServletFactory. If you comment out that assertion, Webware is 
> happy to use
> new style class mixins.

Which assertion causes the problem?

	assert type(theClass) is ClassType

or

	assert issubclass(theClass, Servlet)

?

I assume it's the first one, right?

Is there a way to rewrite the assertion so that it still provides some
protection against screwups but works with new-style class mixins?

- Geoff

On 09/04/2002 09:30:55 AM Geoffrey Talvola wrote:

>Which assertion causes the problem?
>
>    assert type(theClass) is ClassType
>or
>    assert issubclass(theClass, Servlet)
>?
>I assume it's the first one, right?
>
>Is there a way to rewrite the assertion so that it still provides some
>protection against screwups but works with new-style class mixins?

It's the first one. But it would be nice to do something about the second
one too since it is the one that prevents the use of delegation.

...Edmund.

Hey folks,

I've just run up against a nasty little exception block in Application.py
which drops import errors on context initialization. I was trying to figure
out why some of my context's __init__.py code wasn't executing  - eventually
I simply tried to import the context from command line Python and saw an
ImportError related to a module I was importing as part of the
initialization.

So naturally I wondered why Webware didn't raise this ImportError on
AppServer startup, and this is what I found in Application.addContext():

799     try:
800         importAsName = name
801         localdir, pkgname = os.path.split(dir)
802         if not sys.modules.has_key(importAsName):
803             res = imp.find_module(pkgname, [localdir])
804             mod = imp.load_module(name, res[0], res[1], res[2])
805             if mod.__dict__.has_key('contextInitialize'):
806                 result = mod.__dict__['contextInitialize'](self,
os.path.normpath(os.path.join(os.getcwd(),dir)))
807                 if result != None and result.has_key('ContentLocation'):
808                     dir = result['ContentLocation']
809     except ImportError:
810         pass
811     print 'Loading context: %s at %s' % (name, dir)

So I have 2 questions:
1 - It would be nice to raise the ImportError. Is there a reason why it is
dropped?
2 - Shouldn't the 'Loading context ...' message come before the context load
is attempted? :)

Regards,
Ben