Python Type-Inference based LINT.. (pylint.py)
skaller
skaller at maxtal.com.au
Sat Dec 11 23:53:19 EST 1999
More information about the Python-list mailing list
Sat Dec 11 23:53:19 EST 1999
- Previous message (by thread): Python Type-Inference based LINT.. (pylint.py)
- Next message (by thread): performance of tuple-less Python?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
David Jeske wrote: > Does it seem more proper to: > > I. Do all static checking based on the micro-types, and require > the function writer to define the type constraints if they want > larger granularity? > > def sumListElements(a_list): > 'pylint a_list (SequenceType,)' ## <- this is the syntax pylint.py > ## supports currently for type > ## declarations Hmmm. A specialised docstring .. > > II. Always "upgrade" types to proper-types during static checking. > If someone wants to have a fine-grained type which just includes > __getitem__ and __len__, then force them to at least declare > this as a proper type, like "SimpleSequenceType" and then > show the signature as: > > sumListElements( SimpleSequenceType of AddableType ) -> AddableType I think it depends on what you want to do. First, in the ISO C++ Standard, the same issue arose for algoithms that didn't need the full functionality of some iterator kind, but the specification requires the full kind all the same, because there is no compact wording for anything else (and it allows implementors more freedom). In functional programming languages, signatures tend to be used. [I.e. mico types]. In Viper, the issue will arise -- but when we're talking about calling class methods, the overheads are so large optimisation isn't relevant. I'm interested in knowing whether something is an integer or not, or whether it is precisely a Tuple or not: if a class emulating a sequence is used, it's irrelevant because optimisation is impossible [by type inference] in this case. OTOH knowing _exactly_ which class is passed to a function in a particular call is important, since it allows the method calls to be inlined. -- John Skaller, mailto:skaller at maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller voice: 61-2-9660-0850
- Previous message (by thread): Python Type-Inference based LINT.. (pylint.py)
- Next message (by thread): performance of tuple-less Python?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list