Reasons Y Python is Alsome xD

[livingheaven]

WHY IS PYTHON SOOO ALSOME???



I must say that its very easy to Learn

[TerranceN]

I don't think it's awesome for a couple reasons...

Variable declarations are implicit
This bothers me because if I make a typo on a variable name, a new variable may be created instead of a syntax error being thrown, making it hard to find the problem.

Variables have dynamic types
This bothers me because it is possible to accidentally assign a different type to a variable which must have a specific type for a call later on, which throws no error until that call, whereas in statically typed languages, a syntax error would be thrown where you assigned the wrong type. This means you would have to look at every place you changed that variable to find the error, instead of having it pointed out to you.

Those are the two biggest problems that stop me from using Python, but there are other, smaller, more controversial issues I have with Python (like having to type 'self' in classes).

Also is there any 'Strict' mode in python?

[Tony]

but people _want_ dynamic types. That's why in C/Java everything can be cast into void*/Object

[jcollins1991]

Cause python is awesome for iteration. It has map, reduce, lambda, generators, and a bunch of other interesting things built right into it. It's also got simple libraries for stuff like regular expressions, fetching web resources, diff-like functions, compression, etc (http://docs.python.org/library/). And anything that isn't standard you can probably find an open source library for.

[DtY]

Tony @ Thu Dec 02, 2010 6:11 pm wrote:

but people _want_ dynamic types. That's why in C/Java everything can be cast into void*/Object

Agreed, dynamic types are very useful. (Although, I don't think there's too much use casting to void* in C.)

[wtd]

jcollins1991 @ Fri Dec 03, 2010 7:27 am wrote:

Cause python is awesome for iteration. It has map, reduce, lambda, generators, and a bunch of other interesting things built right into it.

Sounds like you want to learn a functional programming language.

[DemonWasp]

IMO, if you're typing Object in Java, you're doing it wrong. The language is strongly-typed for a reason, and it's not so that you have to work around it.

Use your parametrized types and Interfaces!

[Insectoid]

I agree that implicit variable declaration is annoying, however dynamic typing simplifies a lot of actions. If you DO assign the wrong type somewhere, it isn't usually hard to find.

Working in C feels very restrictive to me after using Ruby a while and I tend to have to re-learn a lot of functions written with static types in mind.

[[Gandalf]]

What DemonWasp said. Casting to Object is deprecated!

TerranceN, the reasons you gave are highly situation based. The reason (at least, the reason that counts) we have many programming languages is so that they can be applied in situations where they are appropriate.

[DtY]

This explains pretty well why python is awesome:

Python:

False = True max = sum if False:     print "The sum of the largest number (0..10) is %d"%max(range(10))

[TerranceN]

Insectoid @ Fri Dec 03, 2010 10:36 am wrote:

I agree that implicit variable declaration is annoying, however dynamic typing simplifies a lot of actions. If you DO assign the wrong type somewhere, it isn't usually hard to find.

I don't see why it would be such a problem to specify if you are creating a variable or not, even if the variable is dynamically typed. Something like

code:

var number = 5

would not get in people's way and would get rid of the problem.

Also, I am not saying to get rid of dynamic typing, but allow some way of locking the type of something you know shouldn't change. Maybe some built in function like

code:

var number = 5 TypeLock(number) number = "This would throw an error" TypeUnlock(number) number = "now it wouldn't"

Although I highly doubt python will have any future syntax changes that wont have backwards compatibility.

Gandalf @ Fri Dec 03, 2010 10:42 am wrote:

TerranceN, the reasons you gave are highly situation based. The reason (at least, the reason that counts) we have many programming languages is so that they can be applied in situations where they are appropriate.

I don't understand how the situations I proposed could not occur in a situation where Python is appropriate (sorry if I mistook your comment as arguing that). It is always possible to make a typo, and when you call a method of an instance of a class, you can never be certain it got to that part of the code with the correct type, unless you check manually.

[DtY]

TerranceN @ Fri Dec 03, 2010 7:14 pm wrote:

Also, I am not saying to get rid of dynamic typing, but allow some way of locking the type of something you know shouldn't change. Maybe some built in function like

code:

var number = 5 TypeLock(number) number = "This would throw an error" TypeUnlock(number) number = "now it wouldn't"

I think Javascript is moving towards this, you can create a dynamically typed variable with var as usual, or use familiar C-style type identifiers when creating a new variable.

[Tony]

Dynamic variable types cause runtime errors only when some type doesn't support a method called upon it. The responsibility for those checks moves from the compiler to the developer, but this also allows for Duck Typing.

Quote:

irb(main):001:0> class Dog
irb(main):002:1> def speak
irb(main):003:2> "woof"
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> class Cat
irb(main):007:1> def speak
irb(main):008:2> "meow"
irb(main):009:2> end
irb(main):010:1> end
=> nil
irb(main):011:0> [Dog.new, Cat.new].each do |pet|
irb(main):012:1* puts pet.speak
irb(main):013:1> end
woof
meow

Similar behaviour can be achieved in Static languages with explicit interfaces, but certain situations desire multiple inheritances and/or subsets of interfaces.

Perhaps we have something else in a set that can also speak, but shares no other properties with pets.

Quote:

irb(main):026:0> [Dog.new, Cat.new, AudioRecording.new].each do |entity|
irb(main):027:1* puts entity.speak
irb(main):028:1> end
woof
meow
this is only a test

Even if multiple inheritances are allowed, explicitly defining an interface on per-method basis will become quite tedious.

Besides, we could also code defensively, and check if we can call a particular method.

Quote:

irb(main):017:0> [Dog.new, Cat.new, 42].each do |pet|
irb(main):018:1* puts pet.speak if pet.methods.include?("speak")
irb(main):019:1> end
woof
meow

So with Static languages we write extra code to allow methods to be called, while in Dynamic languages we write extra code to not allow methods to be called. Depending on the style one wishes to code in, and the level to which one must formally prove that the code will execute in a certain way, one might be a better choice than another.

Edit: the sample code is in Ruby, but identical concepts apply.

[wtd]

It may also be instructive to learn a programming language with very strict and thorough compile-time type-checking, which eschews the semi-dynamic nature of Object or void pointers.

Though it's important to understand what a "type" can comprise in such languages.

As well, the other concept that would be valuable for any aspiring CS student to explore would be structural typing. Ruby and Python have sort of "informal structural typing" and thus are a decent introduction, but a thorough exploration involves something like the following.

code:

$ ocaml         Objective Caml version 3.11.0 # class foo = object      method foo () = print_endline "bar"   end;; class foo : object method foo : unit -> unit end # let baz x = x#foo ();; val baz : < foo : unit -> 'a; .. > -> 'a = <fun> # baz (new foo);; bar - : unit = () # baz (object method foo () = print_endline "wooble" end);; wooble - : unit = () # baz (object method qux () = print_endline "wooble" end);; Characters 4-55:   baz (object method qux () = print_endline "wooble" end);;       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error: This expression has type < qux : unit -> unit >        but is here used with type < foo : unit -> 'a; .. >        The first object type has no method foo #

code:

class foo = object      method foo () = print_endline "bar"   end;;

Here we define a class foo with a method foo which takes a parameter of type unit and returns a value of type unit.

code:

let baz x = x#foo ();;

We define a function baz which takes an object as its parameter and returns whatever is returned by calling the foo method with a paremeter of value unit on that object.

It thus infers the following signature for that function.

code:

< foo : unit -> 'a; .. > -> 'a

This signature says nothing about the class foo, but rather says simply that the function must take as its parameter an object with a method foo that takes unit and returns some value whose type cannot be solidly inferred.

The first "anonymous" object we create afterward to test this works because it has a foo method which meets the requirements. The latter does not, as it does not have a foo method.

If we wish to replicate this in Python, it's quite simple.

code:

def baz(x):     x.foo()

The drawback of this even more simple version is that we do not find until runtime if we pass an object to baz which does not have a method foo.

If we wish to implement this in Java or C#, we can, but it would require explicitly created interfaces.