Re: Beyond wait-and-see

At 12:27 05.01.2004 -0500, Randolph Brown wrote:
> Samuele Pedroni wrote:
> >would (more) people consider contributing code?
>
> Not sure what kind of a data point I am because I've already been bugging
> the list with patches, but it would certainly be easier if there were other
> progress, particularly as thoughtful responses to patches.

I know, that's also about point 3 but because of what you remark below point 3
is related stricly to point 1.

[- a sized chunk of new-style classes features were implemented
- we would (be able to) make releases more often
- patches would have a sane turnaround]



> >how much: too/otherwise busy VS. what is there is good enough for what I
> >need VS. the code base is too unwelcoming VS. the project admin does not
> >tutor/inspire/give the good example, play a role OTOH?
>
> I think the most important thing that the project needs is a detailed plan
> drawn up on the list for dealing with the major steps needed to move the
> project forward.

somehow in size/effort or relevance order:

*) new-style classes + cleanup of java integration (the second is needed, 
and they go together
because a lot of the general object system plumbing depends right now on 
PyJavaClass (thus PyClass) and on PyReflectedFunction/PyReflected* ...)

*) improve importing of java classes, implement PEP 302

*) jythonc fixing or replacement. The most concrete issue is that there is 
no sane way to compile generators as Java source code, at the meta-level it 
is hard to maintain and a 2nd whole compiler is kind of overkill. I 
understand that the .py -> .java thing has some good-citizenship- 
in-java-world appeal but something has to give. It is to explore whether 
rewriting it as a tool that reuse the interpreter compiler for Python 
modules and concentrate on statically generating proxies for Java classes 
(the interp. normally does this dynamically, this is for sure a no-no where 
ClassLoader creation is not allowed) can really result in a smaller more 
manageable thing. There is likely still some value in producing the proxies 
as .java source.

*) there is a bunch of I/O vs. enconding issues (see bugs on SF).
*) there are some I/O perf issues, see 
http://sourceforge.net/tracker/index.php?func=detail&aid=674932&group_id=12867&atid=112867
*) various small I/O subsys glitches (see bugs of SF)

*) go over CPython 2.2/2.3 NEWS and What's New in x.x documents
*) CPython tests compliance
[ generators, iterators are mostly done, also
Changing the Division Operator (pep-238) and integer/long unification]

*) get our act together wrt PyXML/XML modules, decide what we know we can 
have tested/want to support
*) ...
*) general bug fixing of things not covered by all of the above

*) test_email among others things shows that CPython model where 
unicode/byte strings are distinguishable is not really compatible with 
Jython model in case of using unicode() expecting it to be a no-op for 
unicode strings, or when code explicitly test for unicode vs. byte string.
It is something that merits some thinking. Partly related in some cases to 
the I/O enconding stuff. Although I fear it would be hard to get widespread 
adoption in the Python community at large of the possible guidelines we 
could devise.

nice-to-have:
- NIO/async I/O support as much as possible in a form compatible with what 
CPython does
...

most/ all of this can be attacked in small chunks, not so the bootstrapping 
of the first point.
[and the 3rd, but jythonc is at least a standalone thingy]

I have for sure forgot about something <wink>.

>   It's particularly disheartening to know that some portion
> of the code base is up for radical change and that patches against it might
> be useless.

I have always warned people about this, it is so that the first point above 
implies widespread changes. A different approach wrt. patches would have 
made sense in the case we were doing maintainance releases, so far there 
has not been concrete interest/commitment for that.


> I think it would be great for people to see a brain-dump from people long
> on the project about the issues surrounding new-style types, for which the
> closest thing to a visible design discussion that I could find was on
> python-dev (note the date):
>
>   http://mail.python.org/pipermail/python-dev/2001-August/017255.html

well, time sort some things out, such kind of hiearchies AFAIK does not 
happen in practice,
and the common wisdom now is that is is OK to extend builtin types behavior 
but not to completely override it, because truly the collaboration 
inter-relations beetween the various methods are not really specified. In 
general even in CPython new-style classes design needed also some time to 
somehow stabilize, consider e.g. the change of MRO rules in 2.3 under my 
impulse.

I can do such a brain-dump but this mail is getting too long.

> In short, I don't think the code is opaque, I'm just not sure where people
> want it to go.
>
> I would love to help with new-style classes and such, but it seems that
> replacing jythonc is the most-avoided open task,

yes, you can put it that way <wink>. It would be indeed very valuable, see 
the brief points above. Feel free to ask questions, present what you have 
in mind if/when meaningful.

>  so I'm looking into that
> now -- partially because I haven't seen inklings of a plan for that,
> whereas I'm guessing people have thought longer and harder about the issues
> surrounding new-style classes.

yup 



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click