7 ms·

I did not know you could append to a Path via "/", but that's really awesome! I also really love working with generators when I write Python. They are just su

I did not know you could append to a Path via "/", but that's really awesome! I also really love working with generators when I write Python. They are just such a simple idea that's very powerful and I miss them so much when I go back to javascript (I know javascript has them now, but I haven't written them, and they don't look as fluent as Python 3, where the large parts of the language design is based around them).

rajathagasthya 9y ago
> I did not know you could append to a Path via "/", but that's really awesome! I didn't know that too. It's pretty cool. Seems like they overload __truediv__ operator: https://github.com/python/cpython/blob/master/Lib/pathlib.py#L878 https://github.com/python/cpython/blob/master/Lib/pathlib.py...
- lloeki 9y ago
  Homebrew does that in formulas (in Ruby), it's definitely neat.
dekhn 9y ago
can't say I'm thrilled about this sugar (override division operator in another context).
Animats 9y ago
Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic overload problem comes from using "+" for concatenate. For built-in vectors, "+" is concatenate, but for NumPy arrays, it's addition. You can use "+" between a NumPy array and a built-in vector. Does it add, or concatenate? ("|" is supposed to be the concatenate operator; it was added to ASCII to support PL/I. But decades of C have made it the bitwise OR operator to most programmers, so we're stuck. "_" is allowed within symbols, so that's taken. There's "⁀", character tie, but nobody can type it.) It seems to be best to restrict the math operators to math.
- nradov 9y ago
  Another approach taken in some programming languages is to dispense with operators entirely and just use functions, with fairly loose restrictions on function names. For example, in principle there's no reason a function couldn't be named "+" or "|". Obviously that can lead to readability problems.
  - Jach 9y ago
    And then in some of those languages they let you create macros so in the cases where the normal function syntax looks ugly you can make it readable with no cost... But with macros comes the same sort of potential abuse as other operator overloading, so it's a tradeoff.
- dragonwriter 9y ago
  > Overloading operators for cute purposes is usually a misfeature Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. > There was a fad for this in the early C++ days. Yeah, like overloading the bitwise shift operators as stream insertion/extraction operators. > Python's classic overload problem comes from using "+" for concatenate. For built-in vectors, "+" is concatenate Python doesn't have built-in vectors, it has lists. > but for NumPy arrays, it's addition. Not sure I see a problem. For numbers, it's an addition. For simple ordered collections, it's concatenation. For matrix-like collections, it's memberwise addition. > You can use "+" between a NumPy array and a built-in vector. Does it add, or concatenate? To the extent that's a problem, it's a problem with implicit coercion more than operator overloading.
  - jacquesm 9y ago
    > Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. The fact that it requires context other than the language spec is where the problem resides. The cognitive overhead of reading code is high enough without having to alias common operators.
tveita 9y ago
You can also use the .joinpath() method, in case you're not thrilled about divining the meaning of nonsense code like dividing a path by a string.
est 9y ago
And it's totally portable to Python 2.

rajathagasthya 9y ago

> I did not know you could append to a Path via "/", but that's really awesome! I didn't know that too. It's pretty cool. Seems like they overload __truediv__ operator: https://github.com/python/cpython/blob/master/Lib/pathlib.py#L878 https://github.com/python/cpython/blob/master/Lib/pathlib.py...

lloeki 9y ago
Homebrew does that in formulas (in Ruby), it's definitely neat.

dekhn 9y ago

can't say I'm thrilled about this sugar (override division operator in another context).

Animats 9y ago

Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic overload problem comes from using "+" for concatenate. For built-in vectors, "+" is concatenate, but for NumPy arrays, it's addition. You can use "+" between a NumPy array and a built-in vector. Does it add, or concatenate? ("|" is supposed to be the concatenate operator; it was added to ASCII to support PL/I. But decades of C have made it the bitwise OR operator to most programmers, so we're stuck. "_" is allowed within symbols, so that's taken. There's "⁀", character tie, but nobody can type it.) It seems to be best to restrict the math operators to math.

nradov 9y ago
Another approach taken in some programming languages is to dispense with operators entirely and just use functions, with fairly loose restrictions on function names. For example, in principle there's no reason a function couldn't be named "+" or "|". Obviously that can lead to readability problems.
- Jach 9y ago
  And then in some of those languages they let you create macros so in the cases where the normal function syntax looks ugly you can make it readable with no cost... But with macros comes the same sort of potential abuse as other operator overloading, so it's a tradeoff.
dragonwriter 9y ago
> Overloading operators for cute purposes is usually a misfeature Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. > There was a fad for this in the early C++ days. Yeah, like overloading the bitwise shift operators as stream insertion/extraction operators. > Python's classic overload problem comes from using "+" for concatenate. For built-in vectors, "+" is concatenate Python doesn't have built-in vectors, it has lists. > but for NumPy arrays, it's addition. Not sure I see a problem. For numbers, it's an addition. For simple ordered collections, it's concatenation. For matrix-like collections, it's memberwise addition. > You can use "+" between a NumPy array and a built-in vector. Does it add, or concatenate? To the extent that's a problem, it's a problem with implicit coercion more than operator overloading.
- jacquesm 9y ago
  > Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. The fact that it requires context other than the language spec is where the problem resides. The cognitive overhead of reading code is high enough without having to alias common operators.

tveita 9y ago

You can also use the .joinpath() method, in case you're not thrilled about divining the meaning of nonsense code like dividing a path by a string.

est 9y ago

And it's totally portable to Python 2.