What If..... Strong Types

Don Garrett garrett at bgb.cc
Wed Jun 19 07:23:49 CEST 2002


brueckd at tbye.com wrote:
> On Sun, 16 Jun 2002, Don Garrett wrote:
> 
> I never understood all the hooplah over ints not being classes. I've only 
> ever seen a handful of cases where it might be useful, and lots of cases 
> where it'd get abused, but some people really seem to want it.

   My desire for it is simple desire for orthagonality. The curse of a CS 
background, I guess. But I'm curious, how could you really abuse it?

>>   My belief is that almost all the convenience of Python would be
>>maintained, but that compilation, optimization, and automated code
>>analysis would be simpler.
> 
> 
> I'm _sort of_ in favor of some optional type annotation for optimization 
> purposes, and sort of against it, the idea being that after your code is 
> done you could go back and annotate (or even have a tool suggest 
> annotation) variables with type information such that you are saying that 
> a particular variable name will always refer to integers, for example. My 
> fear, though, is that it would be used too often, i.e. people would 
> provide type information in places where it wouldn't help at all in terms 
> of execution speed. One of the beauties of Python is the clean syntax, the 
> readable code. A good portion of that is the code is not encumbered with 
> all sorts of variable and type declarations. I like the approach of Pyrex 
> because it's close to Python but still separate enough to prevent people 
> from using it too much - if you make it too easy to optimize the code then 
> people will optimize it too often. Bleh.

   I have very similar feelings on this. My hope is that high quality 
compilation could be done without type tagging. I really don't feel 
comfortable about that, but have some ideas about how to approach it.

>>   I'm just wondering if the change would be good or bad. Would it really 
>>break anything important in Python today?
> 
> 
> You might not consider it important, but it'd break a lot of _my_ code, so 
> it'd be important to me! :) Python doesn't force you to use all its 
> dynamic abilities, but I regard that as one of the tools of the Python 
> toolbox, so yes, I'd be hurt by its removal.

   What kinds of code would it break? That's what I'm trying to understand. I 
find that my code doesn't take advantage of these features at all.

   I use function pointers a lot, but I never change/add/delete methods at run 
time, and I always define all members in __init__, even if it's just to a 
default value (or None). Whenever I start to do anything else, it feels hacky 
and hard to follow. Obviously other people feel differently.

>>Would it help with automated code analysis (compilation and optimization 
>>included) as much as I think it would?
> 
> 
> Dunno - how much do you think it would? ;-) A better question, is how
> often do we really need compilation and optmization at all anyway? If it's
> less than 10% (which I believe it is), then the payoff generally wouldn't
> be worth language-wide changes. A plain extension module (especially with
> the help of Boost, SWIG, PyInline, etc.) isn't too painful, and projects
> like Pyrex might have a permanent niche too, but in all cases they are one 
> step removed from standard Python - which is exactly where they belong.

   Since what I'm trying (badly) to suggest is discussion of a new language 
based on Python, but which is compilable..... I'd say it's really needed.

   As a note, I'm pretty much against adding interfaces to Python. I think 
it's a matter of adding a feature when it's not needed just because everyone 
else has them.


> -Dave
> 
> 
> 



-- 
Don Garrett                             http://www.bgb.cc/garrett/
BGB Consulting                                      garrett at bgb.cc




More information about the Python-list mailing list