6 ms·

The nice thing is that it makes a nice symbol `@` available to objects that aren't matrices, to do with as they want ... The (ab)use seems endless :)

scrollaway 13y ago
@ is already used by decorators. I hope decorators will be reimplemented as prefix operators on functions with this change, so that @<foo> becomes available as well.
- ecma 13y ago
  With @ as a grammatical infix matrix mult operator, there doesn't seem to be any real need beyond exclusivity to redefine the decorator grammar. By the same argument, we shouldn't use * for unpacking.
- mcherm 13y ago
  But the use as an operator and the use as a decorator is easily distinguished by where they appear in the grammar. Neither the parser nor human readers (as far as I can tell) have any difficulty determining which use is which. So let's not confuse the two: they are two different uses that happen to utilize the same symbol.
  - scrollaway 13y ago
    My point is that if @<func> is re-implemented as, for example, the function.__dec__, then it can be overridden and some cool DSL uses can pop up. As it stands, the use of @ as a (class-)decorator is built in to the grammar, rather than simply being a prefix operator.
    - ecma 13y ago
      How might that implementation be used in code? Would coders be directly accessing and overriding the __dec__ attribute? Since decorators are definition time anyway, I don't really see much potential that decorated function factories can't already provide.
      - scrollaway 13y ago
        "x = @y" will call y.__dec__. "@foo" behind a function will call foo.__dec__ with the function as an argument, meaning decoration behaviour can then be altered or be even completely different for other classes. As I said, there is DSL potential. As it stands, it's just something that is not possible.
        jessaustin 13y ago
        The core python devs don't really care about DSLs.
gkya 13y ago
I'd love it to be used as value membership operator for dictionaries. Something like this in pseudo-code: class object: def __matmul__(self, dict): return self in dict.values() a = {'asdf': 1} if 1 @ a: # Evaluates to True. print('Lovely!')
- mjburgess 13y ago
  better just to have and __in__ no?
  - aptwebapps 13y ago
    You can already do: 'a' in {'a':1} which will evaluate True. But that's for keys. GP post wants to know about values, if I understand properly.
    - untothebreach 13y ago
      the `in` keyword uses `__contains__` under the hood, if I remember correctly, so you could always make a `dict` subclass that provides this functionality.
- ecma 13y ago
  That seems too esoteric to ever go into the language unfortunately. I love the idea of some sort of __in__ targeting values in mappings but have never been able to think of an elegant mechanism that uses the existing grammar sanely or introduces useful new grammar. I've always thought that maps and a matching __maps__ would have been a nicer way of referring to the keys of a mapping with in/__in__ referring to the values. Although the semantics are a bit odd in that case. Technically the mapping maps a key, but the language semantic to to have it the other way around as in key is mapped by mapping. foo = {'bar': 42} assert 42 in foo but which makes more sense below? assert 42 maps foo assert foo maps 42 or even assert 42 mapped by foo The benefits of including by in the grammar could be of consequence here too.
  - 13y ago
dalke 13y ago
@ is a binary operator with the same precedence and left-right associativity as * , /, and //. It's hard to think of places where @ could be abused where those other three couldn't equally well be a source of abuse. There hasn't been much abuse of those other three, so there likely won't be much abuse of @. I think the only real (ab)use of @ is to echo its use in another language. For example, @ means something in XPath, so X@Y could be used as a short-hand for X.attrib[Y] in an ElementTree-like API: tree = load_xml_tree(...) for node in tree.select("//item[@price > 2*@discount]"): print(node @ "price", node @ "discount")
- ecma 13y ago
  The only other hypothetical I can think of right now is evaluation shorthand. Something like an expression group represented by a class which may be subject to arithmetic using standard operators. @ could be used as shorthand for a .evaluate_at() method but it's probably not that useful anyway. Maybe passing objects with 'argument @ resource' would be interesting...
- tveita 13y ago
  In Python 3.4's pathlib, you can concatenate two paths by dividing one path with the other. I guess you could torture @ for similar purposes in an email library or something.
  - Widdershin 13y ago
    Just got to say, dirtiness aside, overloading / to be path.join is actually a godsend for readability working with path heavy code.
wyuenho 13y ago
> The nice thing is that it makes a nice symbol `@` available to objects that aren't matrices, to do with as they want ... The (ab)use seems endless :) Dozens of operators in Python have been overloadable and open for abuse for decades now, and yet I don't see much abuse, unlike the C++ and Scala communities. This says a lot about the Python community's ability to avoid pitfalls over the years.
loqi 13y ago
I'd love to see it used for partial application - f@a instead of functools.partial(f, a). If wishes were better functional programming support in Python...

scrollaway 13y ago

@ is already used by decorators. I hope decorators will be reimplemented as prefix operators on functions with this change, so that @<foo> becomes available as well.

ecma 13y ago
With @ as a grammatical infix matrix mult operator, there doesn't seem to be any real need beyond exclusivity to redefine the decorator grammar. By the same argument, we shouldn't use * for unpacking.
mcherm 13y ago
But the use as an operator and the use as a decorator is easily distinguished by where they appear in the grammar. Neither the parser nor human readers (as far as I can tell) have any difficulty determining which use is which. So let's not confuse the two: they are two different uses that happen to utilize the same symbol.
- scrollaway 13y ago
  My point is that if @<func> is re-implemented as, for example, the function.__dec__, then it can be overridden and some cool DSL uses can pop up. As it stands, the use of @ as a (class-)decorator is built in to the grammar, rather than simply being a prefix operator.
  - ecma 13y ago
    How might that implementation be used in code? Would coders be directly accessing and overriding the __dec__ attribute? Since decorators are definition time anyway, I don't really see much potential that decorated function factories can't already provide.
    - scrollaway 13y ago
      "x = @y" will call y.__dec__. "@foo" behind a function will call foo.__dec__ with the function as an argument, meaning decoration behaviour can then be altered or be even completely different for other classes. As I said, there is DSL potential. As it stands, it's just something that is not possible.
      - jessaustin 13y ago
        The core python devs don't really care about DSLs.

gkya 13y ago

I'd love it to be used as value membership operator for dictionaries. Something like this in pseudo-code: class object: def __matmul__(self, dict): return self in dict.values() a = {'asdf': 1} if 1 @ a: # Evaluates to True. print('Lovely!')

mjburgess 13y ago
better just to have and __in__ no?
- aptwebapps 13y ago
  You can already do: 'a' in {'a':1} which will evaluate True. But that's for keys. GP post wants to know about values, if I understand properly.
  - untothebreach 13y ago
    the `in` keyword uses `__contains__` under the hood, if I remember correctly, so you could always make a `dict` subclass that provides this functionality.
ecma 13y ago
That seems too esoteric to ever go into the language unfortunately. I love the idea of some sort of __in__ targeting values in mappings but have never been able to think of an elegant mechanism that uses the existing grammar sanely or introduces useful new grammar. I've always thought that maps and a matching __maps__ would have been a nicer way of referring to the keys of a mapping with in/__in__ referring to the values. Although the semantics are a bit odd in that case. Technically the mapping maps a key, but the language semantic to to have it the other way around as in key is mapped by mapping. foo = {'bar': 42} assert 42 in foo but which makes more sense below? assert 42 maps foo assert foo maps 42 or even assert 42 mapped by foo The benefits of including by in the grammar could be of consequence here too.
- 13y ago

dalke 13y ago

@ is a binary operator with the same precedence and left-right associativity as * , /, and //. It's hard to think of places where @ could be abused where those other three couldn't equally well be a source of abuse. There hasn't been much abuse of those other three, so there likely won't be much abuse of @. I think the only real (ab)use of @ is to echo its use in another language. For example, @ means something in XPath, so X@Y could be used as a short-hand for X.attrib[Y] in an ElementTree-like API: tree = load_xml_tree(...) for node in tree.select("//item[@price > 2*@discount]"): print(node @ "price", node @ "discount")

ecma 13y ago
The only other hypothetical I can think of right now is evaluation shorthand. Something like an expression group represented by a class which may be subject to arithmetic using standard operators. @ could be used as shorthand for a .evaluate_at() method but it's probably not that useful anyway. Maybe passing objects with 'argument @ resource' would be interesting...
tveita 13y ago
In Python 3.4's pathlib, you can concatenate two paths by dividing one path with the other. I guess you could torture @ for similar purposes in an email library or something.
- Widdershin 13y ago
  Just got to say, dirtiness aside, overloading / to be path.join is actually a godsend for readability working with path heavy code.

wyuenho 13y ago

> The nice thing is that it makes a nice symbol `@` available to objects that aren't matrices, to do with as they want ... The (ab)use seems endless :) Dozens of operators in Python have been overloadable and open for abuse for decades now, and yet I don't see much abuse, unlike the C++ and Scala communities. This says a lot about the Python community's ability to avoid pitfalls over the years.

loqi 13y ago

I'd love to see it used for partial application - f@a instead of functools.partial(f, a). If wishes were better functional programming support in Python...