Basic data types

[yakutovicha]

fixes #3

[edoardob90]

Just a couple of things maybe worth mentioning when talking about floats:

• Floating point representation error and "catastrophic cancellation" (example)
• The fractions and decimals built-in modules to handle those types of floats
• How to compare floats for equality (e.g., the math.isclose() method)

[edoardob90]

To me, it seems very good and comprehensive overall 👍🏻

Just three comments:

1. Might be useful to mention "unpacking" and "parallel assignment" for iterables. Just for tuples and lists is enough. I will expand on unpacking in "Functions"
2. Unlike lists, sets and dictionaries, tuples are simply defined by comma-separated sequence of names or values. Parentheses are required only with single-element tuples
3. Maybe saying that preferring lists over tuples doesn't concern much searching speed (they both use linear search methods), but mostly memory efficiency and initialization speed. And, if you want, the fact that they are immutable allows one to use them as keys of dictionaries

[edoardob90]

For me it's okay overall. I left three comments. The final version can be merged without further approval

[yakutovicha]

You might want to reference the data model document of the python reference documentation. There they list all the basic built in types including oddities like Ellipsis (...) and NotImplemented

done in fc50d0c

[yakutovicha]

As you talk about data types ,in the dynamic typing section, you could briefly mention that there are tools to handle typing information (static typing) although these are not part of the python runtime

done in 41c0cd9

[yakutovicha]

• When you talk about promoting and casting, you could remark that python as a strong (albeit dynamic) type system. Therefore:

1 + "1.2" 

won't work. Other dynamic languages have a weaker type system (JS) and allow these implicit casts.

I don't know how to phrase this properly. I do provide an example that 1+"1.2" doesn't work despite 1+2.0 working fine. But it is not super clear to me where is the separation line between cases where (a) implicit type promotion works and where (b) the programmer needed to perform explicit type casting.

[yakutovicha]

In the section on lists, you show an heterogeneous list. While this is possible (and quite common in python) I would provide a warning telling people this approach is not advisable for many reasons (type safety, type hinting, ...)

done in 69f679b

• When you write about dictionaries, maybe give a warning that if you try to use a non-hashable type as dict key you receive a runtime error

done in d6a7440

[yakutovicha]

Might be useful to mention "unpacking" and "parallel assignment" for iterables. Just for tuples and lists is enough. I will expand on unpacking in "Functions"

Added issue #38 to address it after our PRs are merged.

[yakutovicha]

2. Unlike lists, sets and dictionaries, tuples are simply defined by comma-separated sequence of names or values. Parentheses are required only with single-element tuples

done in c608fc7

[yakutovicha]

3. Maybe saying that preferring lists over tuples doesn't concern much searching speed (they both use linear search methods), but mostly memory efficiency and initialization speed. And, if you want, the fact that they are immutable allows one to use them as keys of dictionaries

fixed in 5b25aba

[yakutovicha]

@edoardob90, @baffelli I think I addressed all your comments in one way or another. Please have a look and let me know if it is okay to merge the PR.

[baffelli]

You might want to reference the data model document of the python reference documentation. There they list all the basic built in types including oddities like Ellipsis (...) and NotImplemented

done in fc50d0c

Well done, great text!

[baffelli]

• When you talk about promoting and casting, you could remark that python as a strong (albeit dynamic) type system. Therefore:

1 + "1.2" 

won't work. Other dynamic languages have a weaker type system (JS) and allow these implicit casts.

I don't know how to phrase this properly. I do provide an example that 1+"1.2" doesn't work despite 1+2.0 working fine. But it is not super clear to me where is the separation line between cases where (a) implicit type promotion works and where (b) the programmer needed to perform explicit type casting.

I think the difference is that all numerical types belong somehow to the same type hierarchy here therefore they support implicit promotion, while strings do not belong to that hierachy. This sort of ambiguity was one of the reason for defining typeclasses in other programming languages such as haskell...

[edoardob90]

Good, good 👍🏻

[yakutovicha]

I think the difference is that all numerical types belong somehow to the same type hierarchy here therefore they support implicit promotion, while strings do not belong to that hierachy. This sort of ambiguity was one of the reason for defining typeclasses in other programming languages such as haskell...

ok, addressed in c8b24cb