python philosophical question - strong vs duck typing

[Sean Wolfe]

Hello everybody, I'm a happy pythonista newly subscribed to the group.
How is it going?
I have a theoretical / philosophical question regarding strong vs duck
typing in Python. Let's say we wanted to type strongly in Python and
were willing to compromise our code to the extent necessary, eg not
changing variable types or casting or whatever. Let's say there was a
methodology in Python to declare variable types.

The question is, given this possibility, would this get us closer to
being able to compile down to a language like C or C++?

What I am driving at is, if we are coding in python but looking for
more performance, what if we had an option to 1) restrict ourselves
somewhat by using strong typing to 2) make it easy to compile or
convert down to C++ and thereby gain more performance.

It seems to be that accepting the restrictions of strong typing might
be worth it in certain circumstances. Basically the option to use a
strongly-typed Python as desired. Does this get us closer to being
able to convert to Cpp? Does the Cython project have anything to do
with this?

Thanks!

 

[Sean Wolfe]

Welcome!

Thanks! and thanks to all, hjaha.

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 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.

“Strongly-typed” is one end of a spectrum whose opposite end is
“weakly-typed”. Weakly-typed objects are in languages like e.g. PHP,
where an integer object can be added to a string object.

Ah ok, I didn't realize this distinction. Now I grok it a bit better.

Python does not have variables in the sense of languages like C; rather,
Python has references bound to objects. A reference (e.g. a name, or a
list index, etc.) never has a type. An object always has a type.

yeah I've been learning a lot about this ... at times I have to
're-create' a variable to avoid modifying the original value as well.
For example, when I pass a 'screen' object in my game, at times I have
to duplicate the screen in the new method, then work on the duplicate,
otherwise I will be using the original screen by reference.

You may be thinking of “static typing” (identifiers have types, and
won't allow themselves to refer to an object of a different type),
versus “dynamic typing” (identifiers are ignorant of types – this is
what you have in Python).

Yep I think so.

Thanks for the info all!

 

[Tim Wintle]

Thanks! and thanks to all, hjaha.


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