Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
From: "Prasad, Ramit" <ramit.prasad@jpmorgan.com>
To: "andrew3@r3dsolutions.com" <andrew3@r3dsolutions.com>, "python-list@python.org" <python-list@python.org>
Subject: RE: Multi-dimensional list initialization
Thread-Topic: Multi-dimensional list initialization
Thread-Index: AQHNvG/ZqOr0cXvBdU2FrAoICmLR4Jfdahog
Date: Tue, 6 Nov 2012 23:39:17 +0000
References: <mailman.3267.1352096879.27098.python-list@python.org> <50978323$0$6908$e4fe514c@news2.news.xs4all.nl> <CAHVvXxQR2J2tyFcQZd7bNYTAeetwM+LfoV4UcYrkRfeNVOj+pg@mail.gmail.com> <CAPTjJmqzQi2TEjme_we-KfmG7vxOfRWoKG=zL=SGHYGqiFf9_Q@mail.gmail.com> <CAHVvXxQNCxpACM=tkKir0f3iVqui4oVGnyS-GywO+dtGacKAdQ@mail.gmail.com> <mailman.3311.1352181444.27098.python-list@python.org> <5098d2ac$0$29980$c3e8da3$5496439d@news.astraweb.com> <50999214.50100@r3dsolutions.com>
In-Reply-To: <50999214.50100@r3dsolutions.com>
Accept-Language: en-US
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3346.1352245174.27098.python-list@python.org>
Lines: 135
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:32853

Andrew Robinson wrote:=0D=0A> =0D=0A> On 11/06/2012 01:04 AM, Steven D'Apra=
no wrote:=0D=0A> > On Mon, 05 Nov 2012 21:51:24 -0800, Andrew Robinson wrot=
e:=0D=0A> >=0D=0A[snip]=0D=0A> >      Q: What about other mutable objects l=
ike sets or dicts?=0D=0A> >      A: No, the elements are never copied=2E=0D=
=0A> They aren't list multiplication compatible in any event! It's a total=
=0D=0A> nonsense objection=2E=0D=0A> =0D=0A> If these are inconsistent in m=
y idea -- OBVIOUSLY -- they are=0D=0A> inconsistent in Python's present imp=
lementation=2E  You can't even=0D=0A> reference duplicate them NOW=2E=0D=0A=
> =0D=0A>  >>> { 1:'a', 2:'b', 3:'c' } * 2=0D=0A> Traceback (most recent ca=
ll last):=0D=0A>    File "<stdin>", line 1, in <module>=0D=0A> TypeError: u=
nsupported operand type(s) for *: 'dict' and 'int'=0D=0A=0D=0A>>> z =3D [ {=
'a':1} ]*10=0D=0A>>> z[0]['b'] =3D 4=0D=0A>>> z=0D=0A[{'a': 1, 'b': 4}, {'a=
': 1, 'b': 4}, {'a': 1, 'b': 4},{'a': 1, 'b': 4}, =0D=0A{'a': 1, 'b': 4}, {=
'a': 1, 'b': 4}, {'a': 1, 'b': 4}, {'a': 1, 'b': 4},=0D=0A{'a': 1, 'b': 4},=
 {'a': 1, 'b': 4}]=0D=0A=0D=0AShould that copy the dictionary? According to=
 logical reasoning=0D=0Ait should copy the dictionary as well=2E How do you=
 draw the line of =0D=0Awhat should be copied and what should not? =0D=0A=
=0D=0A> =0D=0A> >      Q: How about on Tuesdays? I bet they're copied on Tu=
esdays=2E=0D=0A> >      A: No, the elements are never copied=2E=0D=0A> That=
's really a stupid objection, and everyone knows it=2E=0D=0A=0D=0AAgreed=2E=
 [snip]=0D=0A=0D=0A> >      Q: How about if I use delegation to proxy a lis=
t?=0D=0A> >      A: Oh no, they definitely won't be copied=2E=0D=0A> Give a=
n example usage of why someone would want to do this=2E  Then we can=0D=0A>=
 discuss it=2E=0D=0A=0D=0AIIRC, someone wanted to do something very similar=
 for dictionaries to =0D=0Aprevent editing of global variables=2E=0D=0A=0D=
=0A> >      Q: What about other mutable objects like sets or dicts?=0D=0A> =
>      A: No, definitely not=2E Unless people complain enough=2E=0D=0A> now=
 you're just repeating yourself to make your contrived list longer --=0D=0A=
> but there's no new objections=2E=2E=2E=0D=0A=0D=0AThis is my main objecti=
on and one of the flaws of your argument=2E=0D=0AYou want to handle one typ=
e of mutable objects completely separately=0D=0Athan other mutable objects=
=2E Why is list any different than dictionary=0D=0Ain this respect? The onl=
y reason I can imagine is because lists=0D=0Aend up being used for 2d (or h=
igher) "matrices"=2E=0D=0A=0D=0A> =0D=0A> > Losing consistency in favour of=
 saving a few characters for something as=0D=0A> > uncommon as list multipl=
ication is a poor tradeoff=2E That's why this=0D=0A> > proposal has been re=
jected again and again and again every time it has=0D=0A> > been suggested=
=2E=0D=0A> Please link to the objection being proposed to the developers, a=
nd their=0D=0A> reasoning for rejecting it=2E=0D=0A> I think you are exagge=
rating=2E=0D=0A=0D=0AI reject (as a developer) it because it forces me to r=
emember a very =0D=0Aspecific quirk versus a simple (logical) rule that app=
lies to all objects=2E Not to mention that the quirk is not even that usefu=
l except for beginners=2E=0D=0A=0D=0A> =0D=0A> > List multiplication [x]*n =
is conceptually equivalent to:=0D=0A> > <snip>=0D=0A> > This is nice and si=
mple and efficient=2E=0D=0A> No it isn't efficient=2E It's *slow* when done=
 as in your example=2E=0D=0A> =0D=0A> > Copying other objects is slow and i=
nefficient=2E Keeping list=0D=0A> > multiplication consistent, and fast, is=
 MUCH more important than making=0D=0A> > it work as expected for the rare =
case of 2D arrays:=0D=0A> I don't think so -- again, look at range(); it wa=
s made to work=0D=0A> inconsistent for a "common" case=2E=0D=0A> =0D=0A> Be=
sides, 2D arrays are *not* rare and people *have* to copy internals of=0D=
=0A> them very often=2E=0D=0A> The copy speed will be the same or *faster*,=
 and the typing less -- and=0D=0A> the psychological mistakes *less*, the e=
legance more=2E=0D=0A> =0D=0A> It's hardly going to confuse anyone to say t=
hat lists are copied with=0D=0A> list multiplication, but the elements are =
not=2E=0D=0A> =0D=0A> Every time someone passes a list to a function, they =
*know* that the=0D=0A> list is passed by value -- and the elements are pass=
ed by reference=2E=0D=0A> People in Python are USED to lists being "the" wa=
y to weird behavior=0D=0A> that other languages don't do=2E=0D=0A=0D=0AI th=
ink you just lost 90% of your credibility (with me)=2E When did lists =0D=
=0Aget passed by value? Python uses call by sharing[0]=2E =0D=0A=0D=0ATermi=
nology aside, lists are handled exactly the same way as all=0D=0Aother obje=
cts; the rules regarding their mutability in the callee=0D=0Aare the same a=
s dictionaries, sets, or any mutable type (including=0D=0Anon-builtins)=2E =
=0D=0A  =0D=0A=0D=0A> =0D=0A> >=0D=0A> > Copying those elements does not co=
me for free=2E=0D=0A> >=0D=0A> > It is true that list multiplication can be=
 much faster than a list comp=2E=0D=0A> > But that's because the list multi=
ply doesn't have to inspect the=0D=0A> > elements, copy them, or engage the=
 iteration machinery=2E Avoiding copying=0D=0A> > gives you a big saving:=
=0D=0A> >=0D=0A> >=0D=0A> > [steve@ando ~]$ python3=2E3 -m timeit -s "x =3D=
 range(1000)"=0D=0A> > "[x for _ in range(100)]"  # not copied=0D=0A> > 100=
000 loops, best of 3: 11=2E9 usec per loop=0D=0A> >=0D=0A> > [steve@ando ut=
ilities]$ python3=2E3 -m timeit -s "x =3D range(1000)"=0D=0A> > "[x[:] for =
_ in range(100)]"  # copied=0D=0A> > 10000 loops, best of 3: 103 usec per l=
oop=0D=0A> >=0D=0A> > So there's a factor of ten difference right there=2E =
If list multiplication=0D=0A> > had to make copies, it would lose much of i=
ts speed advantage=2E=0D=0A> And when multiplication doesn't make copies of=
 *lists*, it's going=0D=0A> "nowhere fast", because people don't want the r=
esults that gives=2E=0D=0A> =0D=0A> So what difference does it make?  Peopl=
e won't make the construction=0D=0A> unless they wanted to make the copies =
in the first place=2E  If they want=0D=0A> the copies, well -- copies are *=
slow*=2E  Big deal=2E=0D=0A> =0D=0A> >   For large=0D=0A> > enough lists, o=
r complicated enough objects, it would become slower than=0D=0A> > a list c=
omprehension=2E=0D=0A> Huh? You're nuts=2E=0D=0A> =0D=0A> > It would be eve=
n slower if list multiplication had to inspect each=0D=0A> > element first =
and decide whether or not to copy=2E=0D=0A> A single pointer comparison in =
a 'C' for loop takes less than 5 nano=0D=0A> seconds on a 1Ghz machine=2E=
=0D=0A> (I'll bet yours is faster than that=2E=2E=2E!)=0D=0A> Consider: lis=
t objects have a pointer which points back to the generic=0D=0A> list objec=
t -- that's all it takes to determine what the "type" is=2E=0D=0A> =0D=0A> =
Your measured loop times, doing list comprehensions takes over 10=0D=0A> mi=
croseconds *per loop*=2E=0D=0A> Compared to what you're proposing -- The po=
inter compare is a mere 0=2E05%=0D=0A> change;  You can't even measure that=
 with "timeit!"=2E  BUT: The increase=0D=0A> in speed for not running token=
ized "for" loops is *much* bigger than the=0D=0A> loss for a single pointer=
 compare; so it will *usually* be a *serious*=0D=0A> net gain=2E=0D=0A> =0D=
=0A> >> I really don't think doing a shallow copy of lists would break anyo=
ne's=0D=0A> >> program=2E=0D=0A> > Anyone who is currently using list multi=
plication with mutable objects is=0D=0A> > expecting that they will be the =
same object, and relying on that fact=2E=0D=0A> > Otherwise they wouldn't b=
e using list multiplication=2E=0D=0A> yes, and I'm not changing that -- exc=
ept for lists; and *no* one is=0D=0A> using that=2E=0D=0A> Find two example=
s of it from existing non contrived web examples of=0D=0A> Python code=2E=
=0D=0A> *ask* around=2E=0D=0A=0D=0AI am positive that majority of code is n=
ot examples--web or otherwise=2E=0D=0A=0D=0A> =0D=0A> >=0D=0A> > You're sug=
gesting a semantic change=2E Therefore they will be expecting=0D=0A> > some=
thing different from what actually happens=2E Result: broken code=2E=0D=0A>=
 Even if it was;  So are many semantic changes happening between python 2=
=0D=0A> and python 3=2E=0D=0A> Look at what python 2 did:=0D=0A> =0D=0A>  >=
>> range(0,5)[0]=0D=0A> 0=0D=0A>  >>> range(0,5)[1:3]=0D=0A> [1, 2]=0D=0A> =
=0D=0A> That's a *semantic* change=2E=0D=0A> Also; if you complain that xra=
nge has been renamed range; then look:=0D=0A> =0D=0A>  >>> xrange(0,5)[0]=
=0D=0A> 0=0D=0A>  >>> xrange(0,5)[1:3]=0D=0A> Traceback (most recent call l=
ast):=0D=0A>    File "<stdin>", line 1, in <module>=0D=0A> TypeError: seque=
nce index must be integer, not 'slice'=0D=0A> =0D=0A> WOW=2E WOW=2E WOW=2E =
 An even BIGGER semantic change=2E=0D=0A=0D=0ASo because one thing has a se=
mantic change that gives license=0D=0Afor semantic changes everywhere? Bah,=
 ridiculous!=0D=0A=0D=0A[snip]=0D=0A> =0D=0A> > to get the behaviour you wa=
nt, and then in Python 3=2E5 it would become the=0D=0A> > default=2E That's=
 three years until it becomes the standard=2E Meanwhile,=0D=0A> > there wil=
l still be millions of people using Python 2=2E7 or 3=2E2, and their=0D=0A>=
 > code will behave differently from your code=2E=0D=0A> Uh, they aren't *u=
sing* the construction I am proposing now -- they are=0D=0A> avoiding it li=
ke the plague=2E=0D=0A> Hence, it will merely become a new ability in a few=
 years -- not=0D=0A> 'differently' behaving code=2E=0D=0A=0D=0AHow in the n=
ame of <insert deity (or religion)> do you have any clue =0D=0Aabout that? =
Granted, as an educated you *may* be right, but you=0D=0Amay not be=2E I ha=
ve no idea how you could know this definitively=0D=0Aor with any great degr=
ee of certainty=2E [snip]=0D=0A=0D=0A=0D=0A~Ramit=0D=0A=0D=0A[0] http://en=
=2Ewikipedia=2Eorg/wiki/Evaluation_strategy#Call_by_sharing=0D=0A=0D=0A=0D=
=0AThis email is confidential and subject to important disclaimers and=0D=
=0Aconditions including on offers for the purchase or sale of=0D=0Asecuriti=
es, accuracy and completeness of information, viruses,=0D=0Aconfidentiality=
, legal privilege, and legal entity disclaimers,=0D=0Aavailable at http://w=
ww=2Ejpmorgan=2Ecom/pages/disclosures/email=2E