3 ms·

Python is very fun and agile, however I was always under the impression it was also not meant for big projects as it is strongly not typed. Do you think Python

Python is very fun and agile, however I was always under the impression it was also not meant for big projects as it is strongly not typed. Do you think Python is a great substitute or compliment to rails? What's your code of choice?

rst 16y ago
If you want to do a big project in Python, it's considered best practice nowadays to have a thorough test suite, in part to catch the sorts of goofs that the typechecker would otherwise tell you about (though a good test suite will do a great deal more than that). However, Rails is a Ruby web framework; Python and Rails do not mix. The Python equivalents would be Django or, I think, Pyramid.
sho_hn 16y ago
Python actually is strongly typed: Everything does have a type, and aside from within numerics (integers upconvert to floats), Python generally won't automatically convert between them. Mixing objects of different types in operations that would otherwise be ambiguous hence throws an error: You can't use a string and a numeric as the operands of an addition without explicitly converting one of them first, for example. However, variables in Python aren't names assigned to storage areas for data of a particular type, but store references to objects, and can be freely reassigned to objects of any type at any time, i.e. there's no type constraint on them. Similarly, Python's built-in collection working horses (lists, dictionaries, tuples, sets) store references to objects of any type as well, including allowing mixing of the types of referenced objects in a single collection. So while on one hand it won't allow you to shoot yourself in the foot with type mixing to a degree that e.g. PHP does, it also won't allow you to place much in the way of specific type constraints on common constructs. Technically you can check an object's specific type explicitly, but that's a lot of manual work and frowned upon since it undermines polymorphism, i.e. having the same code work on as many different object types as possible as long as they implement the interfaces the code wants to use. Some people feel this makes large bodies of code harder to maintain than in a language that places specific type constraints on variables, collections and other constructs.

rst 16y ago

If you want to do a big project in Python, it's considered best practice nowadays to have a thorough test suite, in part to catch the sorts of goofs that the typechecker would otherwise tell you about (though a good test suite will do a great deal more than that). However, Rails is a Ruby web framework; Python and Rails do not mix. The Python equivalents would be Django or, I think, Pyramid.

sho_hn 16y ago

Python actually is strongly typed: Everything does have a type, and aside from within numerics (integers upconvert to floats), Python generally won't automatically convert between them. Mixing objects of different types in operations that would otherwise be ambiguous hence throws an error: You can't use a string and a numeric as the operands of an addition without explicitly converting one of them first, for example. However, variables in Python aren't names assigned to storage areas for data of a particular type, but store references to objects, and can be freely reassigned to objects of any type at any time, i.e. there's no type constraint on them. Similarly, Python's built-in collection working horses (lists, dictionaries, tuples, sets) store references to objects of any type as well, including allowing mixing of the types of referenced objects in a single collection. So while on one hand it won't allow you to shoot yourself in the foot with type mixing to a degree that e.g. PHP does, it also won't allow you to place much in the way of specific type constraints on common constructs. Technically you can check an object's specific type explicitly, but that's a lot of manual work and frowned upon since it undermines polymorphism, i.e. having the same code work on as many different object types as possible as long as they implement the interfaces the code wants to use. Some people feel this makes large bodies of code harder to maintain than in a language that places specific type constraints on variables, collections and other constructs.