4 ms·

I’m not a Python fan and these examples reinforce my dislike for its design. 1. Caused by confusing reference semantics and value semantics, which is pretty mu

I’m not a Python fan and these examples reinforce my dislike for its design. 1. Caused by confusing reference semantics and value semantics, which is pretty much inevitable when a fundamental data type is mutable. 2. Boolean is a subclass of Integer, because... why? 3. Same problem as #1. 4. Once again, beginners have no understanding of reference vs. value semantics, and why should they? 5. Default arguments of a function are evaluated just once, because... why? This one just seems crazy to me. It turns default arguments into stateful globals, so an innocent-looking function suddenly exhibits unpredictable behavior.

nurettin 7y ago
#5 got me after almost three decades of programming in various languages. I initialized a future in the argument list, but the second time I called the function, python told me I set the result of the future twice. AFAIK no language behaves this way. Rest of the points I was already familiar with from various experiences. To me, they are just filler for the article.
wodenokoto 7y ago
I sum my booleans all the time in python, but other than that I agree. This whole mutating or not mutating thing was a huge headache when starting python and still causes gotchas. R is supposedly the “poorly designed” programming language that data scientists may use instead of python, but I’ve never had such problems in R.
- tempguy9999 7y ago
  > This whole mutating or not mutating thing was a huge headache when starting python and still causes gotchas. Well, I'd say 1) immutability is expensive[0] and 2) mutability is sometimes simpler and clearer than immutability for some algorithms IMO. So I'd want python to have both. Today's passion for 'immutable everything' is going to burn out pretty quick as it's great but being used too much and without recognising its cost. IMO again. [0] if naively implemented, and it so often is.
  - brianberns 7y ago
    I think mutability is fine, but there should be some syntactic difference in the usage to alert the user.
  - wodenokoto 7y ago
    R doesn’t have strict immutability. I’m not sure which data structures in R are mutable, but I’m sure it’s most, as a common operation is to change the values of a subset of a list/vector/dataframe. So my point is not “python is hard because of mutability” it’s that pythons mutability really gets in the way of the beginner and causes lots of gotchas for even well experienced developers.
    - tempguy9999 7y ago
      > So my point is not “python is hard because of mutability”... ok > ...it’s that pythons mutability really gets in the way of the beginner and causes lots of gotchas for even well experienced developers So python is hard because of mutability? (well, harder anyway). The fact is, if python had immutability it'd be semantically simpler. Unquestionably (I'd claim). But that comes at a performance cost, so mutability is allowed. That's when we get these confusions of what an operation does (because the semantics get non-simple). My point is either way we pay a price. Anyway I have a feeling I may be misconstruing your point, sorry if that's so.
- tempguy9999 7y ago
  > I sum my booleans all the time in python, but other than that I agree. Use any/all instead? <https://stackoverflow.com/questions/31099561/test-if-all-elements-of-a-python-list-are-false> https://stackoverflow.com/questions/31099561/test-if-all-ele.... More general (see my other post), shorter and clearer?
  - dagw 7y ago
    Often I want to know how many items are True, not just if all/some/none are True.
  - wodenokoto 7y ago
    I get my averages from sum(list_of_bools) / len(list_of_bools) and np_array_of_bools.mean() There is probably a more correct way, but I enjoy it.
dTal 7y ago
I think you're being too kind on point #4. Even if you perfectly understood the basic idea of reference vs value semantics, two independent string objects being the same or not depending on their length is just... calculated to confuse.
tempguy9999 7y ago
> Boolean is a subclass of Integer, because... why? truth/falsity is more general than that in python, so bools aren't really necessary. As for why, 0 is false, nonzero is true (not 1, any non-zero). So false is 'nothing there' and true is 'something is there'. This generalises to other structures, an empty list is nothing (ie. false) a non-empty list is not-nothing so is true so you can do >>> y = [23, 24, 25] >>> while y: ... print(y) ... y = y[1:] ... [23, 24, 25] [24, 25] [25] Ditto loadsa other things. I guess this was a lisp inheritance.
- hjk05 7y ago
  > As for why, 0 is false, nonzero is true It’s not that clear cut. If you assign d[True] and then d[1] you overwrite because True hashes to 1, not because 1 is a truthy value. If you try writing to d[2] you don’t overwrite d[True]. In any case this Feels like an odd case where python is sort of doing something similar to implicit type conversion which goes against the zen of python.
  - tempguy9999 7y ago
    This is an excellent point, and one I met a while ago when designing a rather specialised DSL. I went the same way as python, so one didn't have to keep casting to bools to do a check and it made things a lot cleaner mostly, but it did introduce some dubious corner case niggles. I don't know if there is a good answer. I didn't find one anyway.
dagw 7y ago
Even as a fan of Python #5 still confuses me. The other 4 I can kind of make up an excuse for if I had to, but that one is just weird.

nurettin 7y ago

#5 got me after almost three decades of programming in various languages. I initialized a future in the argument list, but the second time I called the function, python told me I set the result of the future twice. AFAIK no language behaves this way. Rest of the points I was already familiar with from various experiences. To me, they are just filler for the article.

wodenokoto 7y ago

I sum my booleans all the time in python, but other than that I agree. This whole mutating or not mutating thing was a huge headache when starting python and still causes gotchas. R is supposedly the “poorly designed” programming language that data scientists may use instead of python, but I’ve never had such problems in R.

tempguy9999 7y ago
> This whole mutating or not mutating thing was a huge headache when starting python and still causes gotchas. Well, I'd say 1) immutability is expensive[0] and 2) mutability is sometimes simpler and clearer than immutability for some algorithms IMO. So I'd want python to have both. Today's passion for 'immutable everything' is going to burn out pretty quick as it's great but being used too much and without recognising its cost. IMO again. [0] if naively implemented, and it so often is.
- brianberns 7y ago
  I think mutability is fine, but there should be some syntactic difference in the usage to alert the user.
- wodenokoto 7y ago
  R doesn’t have strict immutability. I’m not sure which data structures in R are mutable, but I’m sure it’s most, as a common operation is to change the values of a subset of a list/vector/dataframe. So my point is not “python is hard because of mutability” it’s that pythons mutability really gets in the way of the beginner and causes lots of gotchas for even well experienced developers.
  - tempguy9999 7y ago
    > So my point is not “python is hard because of mutability”... ok > ...it’s that pythons mutability really gets in the way of the beginner and causes lots of gotchas for even well experienced developers So python is hard because of mutability? (well, harder anyway). The fact is, if python had immutability it'd be semantically simpler. Unquestionably (I'd claim). But that comes at a performance cost, so mutability is allowed. That's when we get these confusions of what an operation does (because the semantics get non-simple). My point is either way we pay a price. Anyway I have a feeling I may be misconstruing your point, sorry if that's so.
tempguy9999 7y ago
> I sum my booleans all the time in python, but other than that I agree. Use any/all instead? <https://stackoverflow.com/questions/31099561/test-if-all-elements-of-a-python-list-are-false> https://stackoverflow.com/questions/31099561/test-if-all-ele.... More general (see my other post), shorter and clearer?
- dagw 7y ago
  Often I want to know how many items are True, not just if all/some/none are True.
- wodenokoto 7y ago
  I get my averages from sum(list_of_bools) / len(list_of_bools) and np_array_of_bools.mean() There is probably a more correct way, but I enjoy it.

dTal 7y ago

I think you're being too kind on point #4. Even if you perfectly understood the basic idea of reference vs value semantics, two independent string objects being the same or not depending on their length is just... calculated to confuse.

tempguy9999 7y ago

> Boolean is a subclass of Integer, because... why? truth/falsity is more general than that in python, so bools aren't really necessary. As for why, 0 is false, nonzero is true (not 1, any non-zero). So false is 'nothing there' and true is 'something is there'. This generalises to other structures, an empty list is nothing (ie. false) a non-empty list is not-nothing so is true so you can do >>> y = [23, 24, 25] >>> while y: ... print(y) ... y = y[1:] ... [23, 24, 25] [24, 25] [25] Ditto loadsa other things. I guess this was a lisp inheritance.

hjk05 7y ago
> As for why, 0 is false, nonzero is true It’s not that clear cut. If you assign d[True] and then d[1] you overwrite because True hashes to 1, not because 1 is a truthy value. If you try writing to d[2] you don’t overwrite d[True]. In any case this Feels like an odd case where python is sort of doing something similar to implicit type conversion which goes against the zen of python.
- tempguy9999 7y ago
  This is an excellent point, and one I met a while ago when designing a rather specialised DSL. I went the same way as python, so one didn't have to keep casting to bools to do a check and it made things a lot cleaner mostly, but it did introduce some dubious corner case niggles. I don't know if there is a good answer. I didn't find one anyway.

dagw 7y ago

Even as a fan of Python #5 still confuses me. The other 4 I can kind of make up an excuse for if I had to, but that one is just weird.