From: Samuele P. <ped...@st...> - 2006-12-06 22:43:27
|
Leo User wrote: > Hmm, that's why all the *__* methods. Ill have to > think if that changes the question at all. If the > point is to always call the "*_*" version, I don't see > how this would stop having a common method name for > the *_* implementation. Im not sure what the names > would be: > > interface PyNumber{ > > PyObject __abs__impl(); > etc... > > } > > PyLong extends PyObject implements PyNumber{ > ... > } > > maybe, is just a matter of teaching the code generation tools to produce the right code, also potentially built-ins have built-in subclasses (think bool and int), so one needs to be careful. To be honest if I think of readability and clarity problems I have other candidates than the exposed_* classes, the cluster Py(Java)Class, Py(Java)Instance comes to mind, especially considering that right now we don't support subclassing java classes and new-style python classes at the same time. > leouser > > > --- Samuele Pedroni <ped...@st...> wrote: > > >> Leo User wrote: >> >>> What may be a possible move to reduce the amount >>> >> of >> >>> classes produced here is to introduce a common >>> interface(s) among some of the classes. For >>> >> example, >> >>> Im looking at PyFloat, PyInteger and PyLong. >>> Compiling these show off quite a few produced >>> >> classes >> >>> whose purpose(apparently) is to invoke a method on >>> >> the >> >>> Py* instance. Each one of theses produces an >>> "exposed__abs__.class". Hence, make a common >>> interface for these 3 and have an __abs__ method >>> >> in >> >>> it. Then instead of generating a new class for >>> >> each >> >>> of the classes __abs__ method, generate one and >>> >> have >> >>> it invoke the common interface method. Id take a >>> >> wild >> >>> guess that this could reduce the count of extra >>> classes from 60 to maybe 20. Also, Ive perused >>> >> code >> >>> in places where it checks if its a PyFloat and >>> >> than if >> >>> its a PyInteger and essentially does the same >>> >> method >> >>> call. So there may be opportunities for further >>> >> code >> >>> simplification elsewhere by following this path. >>> >>> Another idea for reduction would be to not >>> >> generate >> >>> the exposed classed if something higher up in the >>> hierarchy already has a class to do this. For >>> example, it look s like PyFloat, PyInteger and >>> >> PyLong >> >>> each produce an "exposed__str__.class". So does >>> PyObject. Why not just reuse what PyObject >>> >> creates in >> >>> this case? >>> >>> >>> >> I suspect you are missing the point that some of >> this methods may be >> overriden, >> and the point is that the exposed __xxx__ descriptor >> should invoke >> the original code not any overriden version thereof. >> >> In java is sort of abomination to try to access a >> far away super class >> behavior, >> unless you are a direct subclass, this is not the >> case in Python at all, >> you can >> invoke int.__add__ on whatever subclass of int and >> expect the original >> int behavior. >> >> >> >>> leouser >>> >>> >>> --- Leo User <leo...@ya...> wrote: >>> >>> >>> >>>> Well it has at least one negatives beyond start >>>> >> up >> >>>> time, it makes things harder to read. The first >>>> piece >>>> of code you run into when looking at the files is >>>> this >>>> large swath of class definitions... I guess that >>>> leaves the juicy parts til later. >>>> >>>> >From running a test of the class per method vs >>>> >> the >> >>>> 1 >>>> class-with-switch statement, it seems that the >>>> >> class >> >>>> per method looks roughly 50% cheaper than the >>>> >> switch >> >>>> statement, that is on a Mustang Java. With a >>>> >> Java >> >>>> 4, >>>> they apparently are the same with the >>>> class-per-method >>>> being a little quicker. >>>> >>>> leouser >>>> >>>> >>>> --- Samuele Pedroni <ped...@st...> wrote: >>>> >>>> >>>> >>>>> Leo User wrote: >>>>> >>>>> >>>>>> Oh yeah, >>>>>> >>>>>> this sure looks like it would slow things down. >>>>>> >>>>>> >>>>>> >>>>> From >>>>> >>>>> >>>>>> looking a quasi-simulation where the extra >>>>>> >> level >> >>>>>> >>>>>> >>>>> of >>>>> >>>>> >>>>>> indirection is timed against the one with one >>>>>> >>>>>> >>>> less >>>> >>>> >>>>>> level, the switch statement can really add to >>>>>> >>>>>> >>>> the >>>> >>>> >>>>>> times. >>>>>> >>>>>> leouser >>>>>> >>>>>> >>>>>> >>>>>> >>>>> the current structuring is mostly because >>>>> >>>>> >>>> generating >>>> >>>> >>>>> code for >>>>> self-contained classes, >>>>> vs this switch structure was slightly easier. >>>>> >> Also >> >>>>> indeed it may be >>>>> faster than other approaches. >>>>> It also depends how good jvms are at coping with >>>>> many classes, which I >>>>> suppose they should be >>>>> reasonable at. >>>>> >>>>> OTOH startup time was never a major >>>>> >> consideration, >> >>>>> is essentially a lost >>>>> race vs. CPython. >>>>> >>>>> >>>>> >>>>>> --- Leo User <leo...@ya...> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I was looking at the generated code in >>>>>>> >>>>>>> >>>> typeSetup. >>>> >>>> >>>>>>> It >>>>>>> seems that for many(all?) the methods in the >>>>>>> >>>>>>> >>>>> types >>>>> >>>>> >>>>>>> there is a corresponding class created just >>>>>>> >> for >> >>>>>>> >>>>>>> >>>>> the >>>>> >>>>> >>>>>>> sake of invoking a method on the "self" >>>>>>> >> object. >> >>>>>>> >>>>>>> That's alot of class fat put into place just >>>>>>> >>>>>>> >>>> for >>>> >>>> >>>>>>> that. >>>>>>> So, Im curious if anyone has looked at other >>>>>>> schemes >>>>>>> for this? >>>>>>> >>>>>>> One idea Ive been thinking about is instead of >>>>>>> creating a class for each is to have a generic >>>>>>> routing >>>>>>> class. The router would invoke a general >>>>>>> >>>>>>> >>>> method >>>> >>>> >>>>> on >>>>> >>>>> >>>>>>> each type with a int that corresponds to an >>>>>>> >>>>>>> >>>> int. >>>> >>>> >>>>>>> The >>>>>>> routing method in turn would take the >>>>>>> >>>>>>> >>>> information >>>> >>>> >>>>>>> and >>>>>>> invoke the right method. This probably would >>>>>>> >>>>>>> >>>> cut >>>> > === message truncated === > > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |