What If..... Strong Types
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.
Don Garrett http://www.bgb.cc/garrett/
BGB Consulting garrett at bgb.cc
More information about the Python-list