On Sat, Apr 1, 2017 at 12:44 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> On Fri, Mar 31, 2017 at 06:58:21PM +1100, Chris Angelico wrote:
>> This keeps on coming up in one form or another - either someone
>> multiplies a list of lists and ends up surprised that they're all the
>> same, or is frustrated with the verbosity of the alternatives.
>>
>> Can we use the matmul operator for this?
>
> I like the idea of using * for repetition without copying, and @ for
> repetition with shallow copying.
>
> That does mean that now you have a built-in operator which relies on the
> copy module, since it has to work with arbitrary objects. Isn't copy
> written in Python?

Yes it is, but I'm not entirely sure of all its semantics.

>> If this were supported by the built-in list type, it would be either of 
>> these:
>>
>> >>> x = [[0] * 4] @ 2
>> >>> x = [[0] @ 4] @ 4
>>
>> (identical functionality, as copying an integer has no effect).
>
> I think that's an implementation detail: copying immutable objects
> *might* return a reference to the original immutable object, or it might
> return a new object. For ints, any sane implementation would surely
> behave as we say, but let's not specify that as part of the
> behaviour of @ itself.

Right, right. What I meant was that people would be free to build the
matrix either way, since it wouldn't have any significant difference.
Of course it'd be legal to copy the integer too, but you shouldn't
care one way or the other.

>> The semantics could be either as shown above (copy.copy()), or
>> something very simple and narrow like "lists get shallow-copied, other
>> objects get referenced".
>
> I prefer the distinction copy versus non-copy. That makes it simple to
> understand, and means that it works if somebody wants a list of dicts
> instead of a list of lists:
>
> data = [{'a': 1, 'b': 2}] @ 5

Sounds like a plan. Probably, though, the @ operator should be defined
in concrete terms that are similar to the implementation of
copy.copy(), rather than actually being copy.copy(), in case someone
shadows or monkey-patches the module. But normal usage should have
them behave the same way.

ChrisA
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to