jython-dev

[Jython-dev] Exposed types not in CoreExposed.includes

[Jeff A. <ja...@fa...>]

Tinkering with the logic of PyType, I have run across cases where a 
class is annotated @ExposedType but does produce a TypeBuilder when 
initialised. This is because they are not listed in 
CoreExposed.includes, are not processed by the exposer, and therefore 
are represented by a  PyJavaType object.

I am experimenting with using the annotation, rather than static 
initialisation and looking for a builder, as my way to distinguish the 
two cases, and which reveals this discrepancy whe addBuilder is not called.

So far I found: PyNullImporter, org.python.modules.itertools.imap, 
org.python.antlr.ast.SetComp, org.python.antlr.ast.SetComp, PyXRangeIter.

Such cases are just an oversight, not some subtle choice I haven't 
understood, right?

Jeff

Re: [Jython-dev] Exposed types not in CoreExposed.includes

[<fwi...@gm...>]

The ast.* cases are oversights (specifically my oversights, I think). I
suspect the other is an oversight as well.

Thanks for finding them!

-Frank

On Aug 26, 2017 05:47, "Jeff Allen" <ja...@fa...> wrote:

> Tinkering with the logic of PyType, I have run across cases where a class
> is annotated @ExposedType but does produce a TypeBuilder when initialised.
> This is because they are not listed in CoreExposed.includes, are not
> processed by the exposer, and therefore are represented by a  PyJavaType
> object.
>
> I am experimenting with using the annotation, rather than static
> initialisation and looking for a builder, as my way to distinguish the two
> cases, and which reveals this discrepancy whe addBuilder is not called.
>
> So far I found: PyNullImporter, org.python.modules.itertools.imap,
> org.python.antlr.ast.SetComp, org.python.antlr.ast.SetComp, PyXRangeIter.
>
> Such cases are just an oversight, not some subtle choice I haven't
> understood, right?
>
> Jeff
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Exposed types not in CoreExposed.includes

[Jeff A. <ja...@fa...>]

Good. There has been so much in PyType I thought I understood but broke. 
This could easily, in my mind, have been another. I've corrected as many 
types as I've come across, and it passes tests, but I don't quite know 
what I'm doing here. (I had notes from the first time I learned it, but 
they were on the Wiki.)

I've just pushed recent work to 
https://bitbucket.org/tournesol/jython-fgtype . I still have a few more 
ideas for things I can break ...

Jeff


On 26/08/2017 16:51, Jim Baker wrote:
> Jeff,
>
> Agreed that these all must be an oversight. I specifically contributed 
> PyXRangeIter per the blame info, and I know I would have added this to 
> CoreExposed.includes. Not being exposed can impact some aspects of 
> Python integration, eg right now the __doc__ string is not being 
> exposed properly, but most likely the key thing that is impacted with 
> these specific classes is possibly higher calling overhead due to 
> reflection. So that's why we haven't caught it until now.
>
> Thanks for systematically digging into this!
>
> I also plan to respond to your earlier analysis about using 
> ClassValue. I was busy, then on vacation, then busy again. Summer!
>
> Lastly I was hopeful that exposing this iterator would see at least 
> some impact in a tight loop, but it's not visible in a trivial 
> benchmark like
>
> jython -m timeit -n 100000 'def f():' ' c = 0' ' for i in 
> xrange(10000):' '  c += 1' 'f()'
>
> It might be worthwhile trying https://github.com/zware/codespeed, but 
> obviously a secondary concern. Any performance tuning with respect to 
> function calling — and the use of fun stuff like InvokeDynamic and 
> SwitchPoint — should go into Jython 3.
>
> - Jim
>
> On Sat, Aug 26, 2017 at 6:46 AM, Jeff Allen <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     Tinkering with the logic of PyType, I have run across cases where
>     a class is annotated @ExposedType but does produce a TypeBuilder
>     when initialised. This is because they are not listed in
>     CoreExposed.includes, are not processed by the exposer, and
>     therefore are represented by a  PyJavaType object.
>
>     I am experimenting with using the annotation, rather than static
>     initialisation and looking for a builder, as my way to distinguish
>     the two cases, and which reveals this discrepancy whe addBuilder
>     is not called.
>
>     So far I found: PyNullImporter, org.python.modules.itertools.imap,
>     org.python.antlr.ast.SetComp, org.python.antlr.ast.SetComp,
>     PyXRangeIter.
>
>     Such cases are just an oversight, not some subtle choice I haven't
>     understood, right?
>
>     Jeff
>
>

Re: [Jython-dev] Exposed types not in CoreExposed.includes

[Jeff A. <ja...@fa...>]

No problem. Sometimes it's difficult to tell what's intentional. I have 
done my best to give these *Derived classes too, following the models 
nearby -- all on my BB fork, not the main repo. (If the fork turns out 
bent, we can cherry-pick this out.)

J.


On 26/08/2017 22:51, fwi...@gm... wrote:
> The ast.* cases are oversights (specifically my oversights, I think). 
> I suspect the other is an oversight as well.
>
> Thanks for finding them!
>
> -Frank
>
> On Aug 26, 2017 05:47, "Jeff Allen" <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     Tinkering with the logic of PyType, I have run across cases where
>     a class is annotated @ExposedType but does produce a TypeBuilder
>     when initialised. This is because they are not listed in
>     CoreExposed.includes, are not processed by the exposer, and
>     therefore are represented by a  PyJavaType object.
>
>     I am experimenting with using the annotation, rather than static
>     initialisation and looking for a builder, as my way to distinguish
>     the two cases, and which reveals this discrepancy whe addBuilder
>     is not called.
>
>     So far I found: PyNullImporter, org.python.modules.itertools.imap,
>     org.python.antlr.ast.SetComp, org.python.antlr.ast.SetComp,
>     PyXRangeIter.
>
>     Such cases are just an oversight, not some subtle choice I haven't
>     understood, right?
>
>     Jeff
>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Jython-dev mailing list
>     Jyt...@li...
>     <mailto:Jyt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>     <https://lists.sourceforge.net/lists/listinfo/jython-dev>
>

Re: [Jython-dev] Exposed types not in CoreExposed.includes

[Adam B. <ada...@gm...>]

Was some content lost from the wiki? 

https://wiki.python.org/jython/FrontPage?action=fullsearch&titlesearch=0&value=Pytype&context=180

Adam

> 在 2017年8月27日，下午11:02，Jeff Allen <ja...@fa...> 写道：
> 
> No problem. Sometimes it's difficult to tell what's intentional. I have done my best to give these *Derived classes too, following the models nearby -- all on my BB fork, not the main repo. (If the fork turns out bent, we can cherry-pick this out.)
> 
> J.
> 
> 
>> On 26/08/2017 22:51, fwi...@gm... wrote:
>> The ast.* cases are oversights (specifically my oversights, I think). I suspect the other is an oversight as well.
>> 
>> Thanks for finding them!
>> 
>> -Frank
>> 
>> On Aug 26, 2017 05:47, "Jeff Allen" <ja...@fa... <mailto:ja...@fa...>> wrote:
>> 
>>    Tinkering with the logic of PyType, I have run across cases where
>>    a class is annotated @ExposedType but does produce a TypeBuilder
>>    when initialised. This is because they are not listed in
>>    CoreExposed.includes, are not processed by the exposer, and
>>    therefore are represented by a  PyJavaType object.
>> 
>>    I am experimenting with using the annotation, rather than static
>>    initialisation and looking for a builder, as my way to distinguish
>>    the two cases, and which reveals this discrepancy whe addBuilder
>>    is not called.
>> 
>>    So far I found: PyNullImporter, org.python.modules.itertools.imap,
>>    org.python.antlr.ast.SetComp, org.python.antlr.ast.SetComp,
>>    PyXRangeIter.
>> 
>>    Such cases are just an oversight, not some subtle choice I haven't
>>    understood, right?
>> 
>>    Jeff
>> 
>> 
>>    ------------------------------------------------------------------------------
>>    Check out the vibrant tech community on one of the world's most
>>    engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>    _______________________________________________
>>    Jython-dev mailing list
>>    Jyt...@li...
>>    <mailto:Jyt...@li...>
>>    https://lists.sourceforge.net/lists/listinfo/jython-dev
>>    <https://lists.sourceforge.net/lists/listinfo/jython-dev>
>> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev