Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #18426 > unrolled thread

python philosophical question - strong vs duck typing

Back to article view | Back to comp.lang.python

Contents

  python philosophical question - strong vs duck typing Sean Wolfe <ether.joe@gmail.com> - 2012-01-03 15:13 -0300
    Re: python philosophical question - strong vs duck typing Ben Finney <ben+python@benfinney.id.au> - 2012-01-04 09:28 +1100
      Re: python philosophical question - strong vs duck typing Sean Wolfe <ether.joe@gmail.com> - 2012-01-04 11:30 -0300
      Re: python philosophical question - strong vs duck typing Tim Wintle <tim.wintle@teamrubber.com> - 2012-01-04 17:01 +0000

#18426 — python philosophical question - strong vs duck typing

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!








-- 
A musician must make music, an artist must paint, a poet must write,
if he is to be ultimately at peace with himself.
- Abraham Maslow

[toc] | [next] | [standalone]

#18460

Sean Wolfe <ether.joe@gmail.com> writes:

> Hello everybody, I'm a happy pythonista newly subscribed to the group.

Welcome!

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

Are you aware that Python has strong typing *and* duck typing,
simultaneously?

Every Python object is strongly-typed: they know exactly what type they
are, what operations are permitted with objects of other types, and
won't pretend to be a different type. (So an object of, e.g., type
‘int’, won't allow addition of itself with an object of type ‘str’.)

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

Every Python object allows duck typing: its operations are available to
any code that wants to use that functionality, regardless of what type
the client may assume it's working with. (This allows an object of,
e.g., type ‘StringIO’, which has no relationship to the ‘file’ type, to
be used by functions expecting a file object.)

What do you mean to convey by “strong vs. duck typing”?

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

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.

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

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

I would need to know what you mean instead of “strong typing”, because
Python already has that.

-- 
 \        “If we ruin the Earth, there is no place else to go. This is |
  `\    not a disposable world, and we are not yet able to re-engineer |
_o__)                      other planets.” —Carl Sagan, _Cosmos_, 1980 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#18499

On Tue, Jan 3, 2012 at 7:28 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Sean Wolfe <ether.joe@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 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!

[toc] | [prev] | [next] | [standalone]

#18506

On Wed, 2012-01-04 at 11:30 -0300, Sean Wolfe wrote:
> On Tue, Jan 3, 2012 at 7:28 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> > Sean Wolfe <ether.joe@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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web