Georg Brandl wrote:

Josiah Carlson schrieb:

...

"Ian D. Bollinger" wrote:

...

It would be nice if containers had a more consistent interface. The standard idiom for copying a list has been L[:], but this isn't

The standard way of copying a list (or producing a list from an arbitrary sequence) is list(L).

The first part is news to me. Who defined that standard?

No one needs to define a standard for it to be the standard. How would you propose, generally, to convert some arbitrary sequence into a list? Would you use a list comprehension: [i for i in seq] ? Would you use a generator expression passed to a list: list(i for i in seq) ? Or would you just use list(seq)? Me, I prefer simplicity and the case that works the way I usually need it to: list(seq). Conveniently, this works for list(dct), list(lst), list(deq), list(st), list(uni), list(tup), list(ite), ... To not use list(obj) when you can would seem to me to be an anti-pattern, regardless of the minor opimization that can be had in lst[:] copying. This technique is also going to be used in the 2to3 conversion utility to convert range() calls to list(range()) calls, and I am honestly baffled by anyone asking, "how do I copy a list, deque, dictionary,...". How could one *not* look at the base constructors? - Josiah

Georg Brandl wrote:

Josiah Carlson schrieb:

...

Georg Brandl wrote:

...

Josiah Carlson schrieb:

...

"Ian D. Bollinger" wrote:

...

It would be nice if containers had a more consistent interface. The standard idiom for copying a list has been L[:], but this isn't

The standard way of copying a list (or producing a list from an arbitrary sequence) is list(L).

The first part is news to me. Who defined that standard?

No one needs to define a standard for it to be the standard. How would you propose, generally, to convert some arbitrary sequence into a list?

No, I meant the "copying a list" part. Getting a list from an iterable is easiest with list(), of course.

I choose as standard what works in the most cases. Since list() works everywhere, using it on lists makes the most sense to me. - Josiah

"Ian D. Bollinger" wrote:

Josiah Carlson wrote:

...

I choose as standard what works in the most cases. Since list() works everywhere, using it on lists makes the most sense to me.

Good point. Would it be worth specifying this in the official style guide?

I think that would be more hand-holding than we really want to be doing. - Josiah

On 5/15/07, Fred L. Drake, Jr. wrote:

On Tuesday 15 May 2007, Ian D. Bollinger wrote:

...

It would be nice if containers had a more consistent interface. The standard idiom for copying a list has been L[:], but this isn't polymorphic and perhaps arcane. Also, deques can only be copied with the copy module's copy function (or calling the __copy__ wrapper directly); thus using copy.copy is the only polymorphic way to copy a mutable container. Additionally, having a consistent interface for mutable containers may dovetail with the ABC PEP.

copy.copy() and copy.deepcopy() have always been the only polymorphic ways to create copies.

For builtin container types (and many other container types as well): type(obj)(obj) is another polymorphic way to create copies. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

"Fred L. Drake, Jr." wrote:

On Tuesday 15 May 2007, Steven Bethard wrote:

...

For builtin container types (and many other container types as well): type(obj)(obj) is another polymorphic way to create copies.

If you're willing to rely on the constructor signature, sure. For many applications, the convention that the constructor can be used as a copier doesn't hold.

But for builtin types (which is the only objects we can reliably change), using the base constructor to copy an object *does* work for all container types (except for defaultdict). - Josiah