I'm working on putting the docs in order for the 3.2 release, and
thought I'd update appendix A as I go.

ie, http://www.modpython.org/live/curre...pp-changes.html

So, what are the changes from 3.1? Should major bug fixes be listed or
just new features/changed behaviour? Feel free to flesh these out to
full line or add more.

Changed import mechanism.
(I wasn't paying too much attention to this whole discussion, so maybe
someone else could comment on how this changed and the possible impact
on user code?)

New version attribute.

Added publisher.get_page() which allows the import of a published page.

Added new session class FileSession which stores the data for each
session in a separate file.

More??

Regards,
Jim

[ Post a follow-up to this message ]

Hi Jim,

I don't have much time now but there should be a complete list here :

http://issues.apache.org/jira/secur...=3D11060&style=
Name=3DHtml&projectId=3D10640&Create=3DCreate

What you should add to your list are :

- a fix/improvement for FieldStorage allowing for better file upload manage=
ment
- lots of bugfixes ;)

BTW, there's a new feature in JIRA, now : it looks like if a
MODPYTHON-xx bug number is inserted into a subversion commit message,
the commit is reference in a "Subversion commit" tab in the bug page.
Example : http://issues.apache.org/jira/browse/MODPYTHON-48

Regards,
Nicoas



2005/6/25, Jim Gallacher <jg.lists@sympatico.ca>:
> I'm working on putting the docs in order for the 3.2 release, and
> thought I'd update appendix A as I go.
>=20
> ie, http://www.modpython.org/live/curre...pp-changes.html
>=20
> So, what are the changes from 3.1? Should major bug fixes be listed or
> just new features/changed behaviour? Feel free to flesh these out to
> full line or add more.
>=20
> Changed import mechanism.
> (I wasn't paying too much attention to this whole discussion, so maybe
> someone else could comment on how this changed and the possible impact
> on user code?)
>=20
> New version attribute.
>=20
> Added publisher.get_page() which allows the import of a published page.
>=20
> Added new session class FileSession which stores the data for each
> session in a separate file.
>=20
> More??
>=20
> Regards,
> Jim
>=20
>

[ Post a follow-up to this message ]

On 26/06/2005, at 1:28 AM, Jim Gallacher wrote:
> Changed import mechanism.
> (I wasn't paying too much attention to this whole discussion, so
> maybe someone else could comment on how this changed and the possible
> impact on user code?)
>
> New version attribute.
>
> Added publisher.get_page() which allows the import of a published page.

I know I am not part of the development team, so can only make
suggestions,
but I personally don't believe that the new import mechanism which has
been
developed just for publisher should be included.

There are already problems which can arise due to the mixing of the
"import"
statement and "apache.import_module()", and now a third system is being
brought into the picture which behaves different enough that in itself
may
cause confusion, but when wrongly mixed with the others could result in
a
mess. I know I don't want to have to be answering questions about it and
if it did come down to it, I probably wouldn't.

Thus, I would be suggesting leaving this feature out. You shouldn't
however
let this delay 3.2. People understand that module importing is broken
and
how to work around it, leaving it that way a bit longer is not going to
cause any new harm. At least, less harm than if this new scheme has to
be
ripped out at a later date.

Instead, fixing of the main module importer should be carried out. I
know
that others disagree with some of my ideas on that, but I do believe it
can
be fixed and the only features you would loose would be the ability to
import
parts of packages when using "apache.import_module()" explicitly and
this
only because to support packages properly when autoreloading is
supported
overly complicates the design to the point that it isn't practical. This
ability of the current importer to deal with packages is actually broken
in various ways anyway and I don't think dropping it would cause any
real
problem. Note that this wouldn't prevent use of packages or parts of
packages
from standard Python locations from any of the Handler directives.

Anyway, the point of this mail is simply to register my viewpoint that
the
new publisher specific import mechanism should not be included. I am not
at this time going to be drawn into further discussions about how to fix
the current import mechanism though. I am working on a document which
describes the basics of how the module importer works and all its
problems
and issues. When I am finished that, then we might start discussing it
again. I am about half done on this document and hopefully in another
week it will be ready to be used as the basis of some discussions on how
to progress this issue.

Graham

[ Post a follow-up to this message ]

On Sun, 26 Jun 2005, Graham Dumpleton wrote:

> Anyway, the point of this mail is simply to register my viewpoint that the
> new publisher specific import mechanism should not be included.

What does everyone think? I'm inclined to agree, especially given that
Graham is working on documenting the issue (see below) which may affect
the ultimate design.

Grisha

> I am not at this time going to be drawn into further discussions about
> how to fix the current import mechanism though. I am working on a
> document which describes the basics of how the module importer works and
> all its problems and issues. When I am finished that, then we might
> start discussing it again. I am about half done on this document and
> hopefully in another week it will be ready to be used as the basis of
> some discussions on how to progress this issue.
>
> Graham
>
>
>

[ Post a follow-up to this message ]

I agree with Graham on the whole, but I'd like to point out a few things.

1) The current publisher implementation, with its own dynamic loading
mechanism, already fixes
http://issues.apache.org/jira/browse/MODPYTHON-9
http://issues.apache.org/jira/browse/MODPYTHON-10
http://issues.apache.org/jira/browse/MODPYTHON-11 and a bit of
http://issues.apache.org/jira/browse/MODPYTHON-8 . So I think we
should keep it until we have a "unified importing theory".

2) The only thing I'm not too proud of, retrospectively, is
publisher.get_page. Like Graham wrote, this introduces a third way for
a developer to handle imports, which is bad. So I agree that even if
we keep the current implementation of the publisher, we should remove
publisher.get_page.

3) My suggestion for an "unified importing theory" is :
a) static importing should be done with import and end up in sys.modules
b) dynamic importing should be done with apache.import_module and end
up in its own module cache, not polluting sys.modules.
c) root level handlers should be imported statically, published pages
and application specific code should be imported dynamically
d) to be practical in a shared hosting environment, dynamic importing
should support reloading, of course, with dependencies, so that
restarting the server whenever published pages or application-specific
code is modified would not be needed.

4) Graham, I don't know what it takes to be a member of the
development team, but to me you are one .

Regards,
Nicolas

2005/6/26, Gregory (Grisha) Trubetskoy <grisha@apache.org>:
>=20
> On Sun, 26 Jun 2005, Graham Dumpleton wrote:
>=20 
the[vbcol=seagreen] 
>=20
> What does everyone think? I'm inclined to agree, especially given that
> Graham is working on documenting the issue (see below) which may affect
> the ultimate design.
>=20
> Grisha
>=20 
d[vbcol=seagreen] 
>

[ Post a follow-up to this message ]

Nicolas Lehuen wrote:
> Hi Jim,
>
> I don't have much time now but there should be a complete list here :
>
> http://issues.apache.org/jira/secur...0&Create=Create

Nice. That will certainly make things easier.

> What you should add to your list are :
>
> - a fix/improvement for FieldStorage allowing for better file upload manag
ement
> - lots of bugfixes ;)

OK.

> BTW, there's a new feature in JIRA, now : it looks like if a
> MODPYTHON-xx bug number is inserted into a subversion commit message,
> the commit is reference in a "Subversion commit" tab in the bug page.
> Example : http://issues.apache.org/jira/browse/MODPYTHON-48

You pointed that out previously, so I've been making a point of doing it
with my commits. However, JIRA does not seem to send these commit
comments to the mailing list in the same way it does regular comments.

Jim

[ Post a follow-up to this message ]

On Sun, 26 Jun 2005, Nicolas Lehuen wrote:

> 2) The only thing I'm not too proud of, retrospectively, is
> publisher.get_page.

One thing we can do is leave it undocumented and put a comment in the code
warning people not to rely on it as it is not a "sure thing".

Grisha

[ Post a follow-up to this message ]

> Nicolas Lehuen wrote: 
>
>
> You pointed that out previously, so I've been making a point of doing it
> with my commits. However, JIRA does not seem to send these commit
> comments to the mailing list in the same way it does regular comments.
>

For some reason, the last couple of commits I've made have not been
picked up by JIRA, in spite of referencing the issue in the commit message.

eg. MODPYTHON-45 - JIRA picked up the commit message
MODPYTHON-58 - JIRA missed it.

Odd. JIRA was really slow or inaccessible last week. Over the weekend it
was better, but it seems to me that the performance improvement
coincided with it ignoring the subversion commits. Did something change?

Jim

[ Post a follow-up to this message ]