On Wed, 2012-01-04 at 11:30 -0300, Sean Wolfe wrote:
> On Tue, Jan 3, 2012 at 7:28 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> > Sean Wolfe <ether....@gmail.com> writes:
> >
> >> Hello everybody, I'm a happy pythonista newly subscribed to the group.
> >
> > Welcome!
>
> Thanks! and thanks to all, hjaha.
>
> >
> >> I have a theoretical / philosophical question regarding strong vs duck
> >> typing in Python. Let's say we wanted to type strongly in Python
> >
> > There may be an unstated assumption there, and your wording confuses me.
> >
>
> yep, probably. I am throwing around terminology a bit. Here's another
> attempt -->
>
> If I am willing to create some python code, when needed, where when I
> create a variable, let's say an integer, that it will be for all time
> an integer, and also that a method that returns say a Sprite custom
> object, and will for all time return only a Sprite object ... , does
> this get me significantly closer to being able to compile to C++?
I'd really recommend looking at Cython - which has optional static
typing and does compile into C / C++ (as a python extension)
More generally, a compiler can perform static analysis on code which
will re-order AST nodes into single constant assignments. I've forgotten
the name but it's something like single static assignment form. When the
return type of functions is known it can lead to known types for
variables.
It's being used heavily in the newest generation of javascript JITs to
speed up generated native code.
However, when a function has multiple return types (e.g. {}.get returns
None if there is no result) then you can't imply the type of the
variable even in this form.
A JIT (such as pypy) can generate the native code for all seen return
types - which is why JITs can in general be more useful to dynamically
typed languages such as Python than compilers.
Another issue is where types can be modified (e.g. in python you can
modify the class of an object at runtime) - dynamic language features
such as this make what counts as a "type" fairly flexible. JITs are
getting around this using "hidden classes" (there are lots of other
names for the same thing) - again it would be very difficult to
statically compile this kind of thing to native code.
> I am just thinking in my brain about the differences between cpp and
> python, and if there is a way to compromise a bit on the python-ness
> to get closer to cpp, but still be able to keep a lot of the goodness,
> then put in a translator or converter to cpp and gain performance by
> using cpp code. Sounds like Rpython, cython, shedskin are doing a lot
> or all of this, so lots to study up on.
Yup
Tim Wintle
--
http://mail.python.org/mailman/listinfo/python-list
