Menu
▾
▴
Re: [Jython-dev] Statically typing Python in Jython
|
From: John H. <ja...@gm...> - 2016-11-06 23:45:53
|
Hi everyone, I haven't followed all the subtleties of this discussion, but my naive impression is that statically typed Python variables have been dealt with, in a way, in Cython ( http://cython.org/) to enhance Python performance otherwise. It is incompatible with Jython itself per se AFAIK, but quite interesting in a general Pythonic sense IMO. Cheers, John On Nov 6, 2016 6:20 PM, "Jeff Allen" <ja...@fa...> wrote: > Hello Jan, > > this sounds a very interesting project. I have given a little thought to > type inference as an optimisation technique, walking the AST to infer > type. In that context it seems more helpful to infer the implementation > type (and range), rather than the Python type. This seems to be what > Numba does: I know that the Numba team find the type hints are not fine > enough for their purposes: they want to know how wide the float is, how > big the int. > > I'm not hopeful it could be incorporated into Jython (or CPython) > without implementing the core entirely differently. There seems to be so > much of the runtime where actual type is washed away to PyObject. It's > not just a matter of providing a more precise return type for library > methods. All the abstractions work against you: even adding two integers > has to return a general object because the slot (equivalently Jython's > PyObject._add) has to accommodate the possibility of returning > NotImplemented. > > Jeff Allen > > On 06/11/2016 18:31, Stefan Richthofer wrote: > > Hello Jan, > > > > just some questions/remarks from me for now. > > > > > > PEP 484 > > > > In your whole email you didn't mention PEP 484 for a single time. > > Will your work incorporate this official Python-typing? > > (i.e. given that Jython 3 is still in work, this mainly refers to > https://www.python.org/dev/peps/pep-0484/#suggested- > syntax-for-python-2-7-and-straddling-code) > > In case you are interested: > > I created a Python 2.7-workable version of typing.get_type_hints() (the > original from typing-module only works for Python 3 and plainly returns > None on Python 2.) > > Unfortunately it currently doesn't work on Jython due to > bugs.jython.org/issue2515. Anyway, that issue would need a fix for any > PEP 484-related work on Jython. > > > > > > Java-typing > > > > How would your approach work with Java-typing behind the scenes (e.g. > for mixed Java/Python programs)? Whenever Jython imports a Java-lib, on > Java-site there is more Type-info available than the import mechanism > exposes. Also, it somewhat obfuscates that info due to coercion and so. > Would you also incorporate Java-type info? > > What about Java-Generics? The Generics-info can be retrieved from Java > too, it's a bit constrained and tricky though. > > > > I always wanted to do some type-cleanup in Jython in the sense that > Jython's Java-API could often be more precise regarding type-info. E.g. it > often just returns a PyObject, even when it is clear that actually a > PyTuple, a PyList<PyObject> or at least List<PyObject> etc is returned. > > However, so far I lacked time and motivation to actually start this. > Also not sure if this could break code, but since the types would only be > specialized, everything should stay compatible. > > Anyway, maybe this is more something for Jython 3. Would it benefit your > approach? > > > > > > Including into Jython > > > > If your work goes well, I'd be in principle +1 on including it into > Jython. Especially if it would help to make the Java/Python > cross-connection more typesafe, especially when calling Python-code from > Java. However, let's see what the others say; I guess it will depend on the > actual benefits and features, which are currently formulated a bit vaguely > I guess. > > > > > > Best > > > > Stefan > > > > > > > >> Gesendet: Sonntag, 06. November 2016 um 15:21 Uhr > >> Von: "Jan Wroblewski" <xi...@mi...> > >> An: jyt...@li... > >> Betreff: [Jython-dev] Statically typing Python in Jython > >> > >> To Jython devs, > >> > >> I am a 3rd year PhD student at University of Warsaw and I wanted to do > >> my Python static typing research by implementing it as a part of Jython. > >> Before starting, I would like to hear your opinion on combining my > >> research with Jython, and whether it would have a chance to be > >> integrated into the main Jython branch after it is complete. Below I > >> describe my plans. > >> > >> My research > >> ----------- > >> I want to statically type Python, which means constructing automatic > >> type inference of most objects (incl. functions and classes) present in > >> a Python program. The type system I am working on consists of: > >> - primitives, > >> - objects, i.e. dictionaries from strings known at compile time to types > >> of values contained there, > >> - functions, > >> - constructs like "TypeA or TypeB", "FunctionTypeA and FunctionTypeB". > >> In other words, before even running a program, I want to compute what > >> properties each variable present in it has, and recursively what are > >> properties of those properties, until I get to primitives or function > >> bodies. > >> > >> The Python type inference algorithm I have in mind would take the Python > >> AST, convert it to a simpler Lucretia language and make the type > >> inference there. Lucretia is a language designed by Viviana Bono, Marcin > >> Benke and Aleksy Schubert (my PhD supervisor) for the purpose of static > >> typing of dynamic languages (pdf: https://arxiv.org/pdf/1206.5112.pdf). > >> > >> One of the features of my project is that I would like to support full > >> Python language instead of subset of its features that are typeable > >> (like mypy does: http://mypy-lang.org/). Since it is provably > impossible > >> to make type inference algorithm working for all Python programs, I want > >> to use gradual typing and treat all variables that my algorithm was not > >> able to process as "dynamic". > >> > >> As for similar research projects, I'd say Reticulated Python by Michael > >> M. Vitousek, Andrew M. Kent, Jeremy G. Siek and Jim Baker is the closest > >> one to what I would like to achieve (pdf: > >> http://wphomes.soic.indiana.edu/jsiek/files/2014/03/retic-python.pdf). > >> Reticulated Python also does not seem to restrict allowed language > >> constructs, but it has slightly different type system and different > >> policy on handling imports (kind of at runtime instead of statically). I > >> noticed that Jim Baker is not only sub-author of Reticulated Python > >> paper, but also a major commiter to Jython, so I am interested in > >> hearing if some of the work from Reticulated Python is already > >> integrated into Jython. > >> > >> Combining with Jython > >> --------------------- > >> The type inference in Lucretia and combining its results with Python is > >> something new and I would like to implement it as a part of Jython. The > >> current Jython implementation would help me with parsing, execution, and > >> generally with lots of technical stuff. I was originally going to target > >> only recent versions of Python 3, but I am open for changes, even to > >> Python 2.7. If the general idea is welcome, I am also open to other > >> major changes. > >> > >> I think that there could be two main applications of my research: > >> - Improvement of IDEs - after exposing some Jython internals connected > >> to my work, more precise type information could be made available to an > >> IDE. As many IDEs run on JVM, the integration could also be smoother. > >> - Producing faster, more optimized for JVM bytecode - although it is not > >> the main goal of Jython, more speed is always better. I believe I could > >> do that in situations where I could prove that no properties would be > >> ever dynamically added to an object, existing ones would not change > >> their type and I could resolve statically all called methods. > >> > >> Jan Wroblewski > >> http://www.mimuw.edu.pl/~xi/ > >> > >> ------------------------------------------------------------ > ------------------ > >> Developer Access Program for Intel Xeon Phi Processors > >> Access to Intel Xeon Phi processor-based developer platforms. > >> With one year of Intel Parallel Studio XE. > >> Training and support from Colfax. > >> Order your platform today. http://sdm.link/xeonphi > >> _______________________________________________ > >> Jython-dev mailing list > >> Jyt...@li... > >> https://lists.sourceforge.net/lists/listinfo/jython-dev > >> > > ------------------------------------------------------------ > ------------------ > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li... > > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
