Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #66310 > unrolled thread
| Started by | dave em <daveandem2000@gmail.com> |
|---|---|
| First post | 2014-02-14 10:08 -0800 |
| Last post | 2014-02-16 09:27 +1100 |
| Articles | 20 on this page of 136 — 23 participants |
Back to article view | Back to comp.lang.python
Explanation of list reference dave em <daveandem2000@gmail.com> - 2014-02-14 10:08 -0800
Re: Explanation of list reference Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-14 20:26 +0200
Re: Explanation of list reference dave em <daveandem2000@gmail.com> - 2014-02-14 10:54 -0800
Re: Explanation of list reference Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-14 19:20 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 21:56 +0200
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-14 13:17 -0700
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 22:58 +0200
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 08:16 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 23:43 +0200
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-14 19:00 -0500
Re: Explanation of list reference dave em <daveandem2000@gmail.com> - 2014-02-14 16:26 -0800
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:07 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 11:00 +0200
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 11:57 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 17:55 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 13:08 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 18:34 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 13:42 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 19:14 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 14:33 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 20:24 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 15:37 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:54 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 18:19 +1100
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-14 22:20 -0700
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 07:03 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 16:31 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 22:07 -0800
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-15 17:19 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 22:31 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 17:23 +1100
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 01:08 -0700
Re: Explanation of list reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-15 12:42 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 15:44 +0200
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-16 06:00 -0800
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-16 11:29 -0500
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-16 08:50 -0800
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 20:01 +0200
Re: Explanation of list reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-16 18:36 +0000
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 05:52 +0000
Re: Explanation of list reference Terry Reedy <tjreedy@udel.edu> - 2014-02-15 15:40 -0500
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-16 02:27 +0000
Re: Explanation of list reference Grant Edwards <invalid@invalid.invalid> - 2014-02-15 19:02 +0000
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:44 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 18:05 +1100
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-16 00:29 +1300
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:15 +0000
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 22:24 -0800
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-16 00:32 +1300
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 22:37 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 11:10 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 10:31 +0000
Re: Explanation of list reference Christian Gollwitzer <auriocus@gmx.de> - 2014-02-15 10:44 +0100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 12:10 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 10:53 +0000
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-17 11:40 +1300
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 05:57 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 22:21 +1100
Re: Explanation of list reference Alister <alister.ware@ntlworld.com> - 2014-02-16 19:16 +0000
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-15 15:20 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 11:31 +0200
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 12:13 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 11:17 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 14:07 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 14:41 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 18:29 +0200
Re: Explanation of list reference Roy Smith <roy@panix.com> - 2014-02-15 12:02 -0500
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-15 09:30 -0800
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 11:37 -0700
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 11:45 -0700
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 19:05 +0000
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 10:11 -0700
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 22:20 +0200
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 14:20 -0700
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-15 09:47 -0800
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 19:17 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 23:01 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-16 02:25 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 13:18 +0200
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 22:31 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 10:40 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 22:17 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 23:20 +0200
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 10:08 +0200
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-16 01:28 -0700
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 12:52 +0200
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-16 22:24 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-16 12:04 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 18:17 +0200
Re: Explanation of list reference Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-16 10:35 +0200
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-16 01:35 -0700
Re: Explanation of list reference Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2014-02-16 03:38 -0500
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-16 08:40 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-16 21:18 +1100
Re: Explanation of list reference Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-02-16 12:10 -0500
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-14 15:45 -0500
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-14 13:12 -0700
Re: Explanation of list reference Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-14 22:36 +0200
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-16 01:03 +1300
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-15 23:21 +1100
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-14 13:42 -0500
Re: Explanation of list reference Ryan Gonzalez <rymg19@gmail.com> - 2014-02-14 12:31 -0600
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 05:36 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 17:07 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:48 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 17:57 +1100
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-16 01:18 +1300
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 23:24 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 15:25 +0200
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-16 00:59 +1100
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-17 11:54 +1300
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-17 10:02 +1100
Re: Explanation of list reference Roy Smith <roy@panix.com> - 2014-02-16 18:46 -0500
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-17 12:26 +1100
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-17 10:05 +1100
Re: Explanation of list reference Roy Smith <roy@panix.com> - 2014-02-16 18:43 -0500
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-17 11:04 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 06:31 +0000
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-17 05:43 -0800
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-16 20:43 -0500
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-17 12:59 +1100
Re: Explanation of list reference Roy Smith <roy@panix.com> - 2014-02-16 22:28 -0500
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-17 14:52 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-16 20:35 -0800
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 08:03 +0000
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 06:21 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-17 18:11 +1100
Re: Explanation of list reference Rotwang <sg552@hotmail.co.uk> - 2014-02-17 18:24 +0000
Re: Explanation of list reference Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-02-15 14:30 -0500
Re: Explanation of list reference Terry Reedy <tjreedy@udel.edu> - 2014-02-14 16:37 -0500
Re: Explanation of list reference pecore@pascolo.net - 2014-02-14 23:34 +0100
Re: Explanation of list reference Christian Gollwitzer <auriocus@gmx.de> - 2014-02-15 10:38 +0100
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-16 01:20 +1100
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-16 01:26 +1100
Re: Explanation of list reference Joshua Landau <joshua@landau.ws> - 2014-02-15 20:44 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-16 09:27 +1100
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 10:40 +0000 |
| Message-ID | <52ff442b$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66397 |
On Sat, 15 Feb 2014 11:31:42 +0200, Marko Rauhamaa wrote:
> It think the best way to define the semantics of "is" is
> through constraints:
>
> 1. if x is y then y ix x
>
> 2. if x is y and y is z then x is z
>
> 3. after x = y, x is y
>
> 4. if x is y, then x == y
Incorrect.
py> x = float('nan')
py> y = x
py> x is y
True
py> x == y
False
> That's why "is" is not introductory material.
No. "is" is not introductory material because it is an attractive
nuisance for beginners. Beginners have a tendency to think that "is" is a
synonym for "equals", as it can be in English. Sometimes it appears to
work:
x = 2
y = x*3 - 4
x is y
=> probably returns True
but in other cases it fails, confusing the beginner.
With the exception of "is None", beginners almost never need "is".
> The constraints define a relation that coincides with == wherever it is
> defined.
It certainly does not.
class Wacky:
def __eq__(self, other):
return random.random() < 0.5
> So why would you ever use "is" instead of "=="? After all, all
> well-defined programs would behave identically after replacing "is" with
> "==". Really, the only reason would be performance; "is" is often
> faster to evaluate than "==".
Incorrect. "is" is NOT equivalent to ==, the two are not guaranteed to do
the same thing, you CANNOT safely replace "is" with == or visa versa, and
the meaning of the "is" operator is completely different from the meaning
of the == operator.
The "is" operator tests whether the two operands are the same object,
nothing more, nothing less. The == operator tests whether the two
operands compare equal.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 22:17 +1100 |
| Message-ID | <mailman.6980.1392463057.18130.python-list@python.org> |
| In reply to | #66397 |
On Sat, Feb 15, 2014 at 8:31 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Referring to "objects in memory" when defininig "is" leads to circular
> definitions. It think the best way to define the semantics of "is" is
> through constraints:
>
> 1. if x is y then y ix x
>
> 2. if x is y and y is z then x is z
>
> 3. after x = y, x is y
Yes. Yes. Yes.
> 4. if x is y, then x == y
No.
>>> x = float("nan")
>>> x == x
False
> The constraints define a relation that coincides with == wherever it is
> defined. So why would you ever use "is" instead of "=="? After all, all
> well-defined programs would behave identically after replacing "is" with
> "==". Really, the only reason would be performance; "is" is often faster
> to evaluate than "==".
Because your criteria are one-way. If x is y, then usually x == y, but
plenty of things compare equal that aren't identical.
>>> x = [1,2,3]
>>> y = [1,2,3]
>>> x == y
True
>>> x.pop()
3
>>> x == y
False
Two things may be equal now and not later, or vice versa, but if
they're identical, they will always be (because they're not "two
things" but one thing), and if they're not identical, they will never
be (because they really are two things, and the traditional marriage
ceremony with the "two becoming one" doesn't happen in computing).
Identity and equality are quite different states, and should be tested
for differently.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-14 23:20 +0200 |
| Message-ID | <87r475o0hq.fsf@elektro.pacujo.net> |
| In reply to | #66326 |
Marko Rauhamaa <marko@pacujo.net>: > You're right, of course. Conceptually, the "everything is a reference" > and the "small"/"big" distinction are equivalent (produce the same > outcomes). The question is, which model is easier for a beginner to > grasp. In fact, if you adjust my annotations to the given example from the "everything is a reference" point of view, you'll see that the explanations become a whole deal longer and probably more confusing. Also, the picture becomes much messier with more strings attached. Marko
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-16 10:08 +0200 |
| Message-ID | <8761ofiio9.fsf@elektro.pacujo.net> |
| In reply to | #66326 |
Marko Rauhamaa <marko@pacujo.net>: > Conceptually, the "everything is a reference" and the "small"/"big" > distinction are equivalent (produce the same outcomes). The question > is, which model is easier for a beginner to grasp. Case in point, if everything is a reference, how come: >>> "hello".__str__() 'hello' >>> 1.__str__() SyntaxError: invalid syntax Marko
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-16 01:28 -0700 |
| Message-ID | <mailman.7042.1392539318.18130.python-list@python.org> |
| In reply to | #66513 |
[Multipart message — attachments visible in raw view] — view raw
On Feb 16, 2014 1:11 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote: > > Marko Rauhamaa <marko@pacujo.net>: > > > Conceptually, the "everything is a reference" and the "small"/"big" > > distinction are equivalent (produce the same outcomes). The question > > is, which model is easier for a beginner to grasp. > > Case in point, if everything is a reference, how come: > > >>> "hello".__str__() > 'hello' > >>> 1.__str__() > SyntaxError: invalid syntax You need parentheses around the 1. Otherwise you confuse the lexer, which thinks you're starting a float literal. >>> (1).__str__() '1'
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-16 12:52 +0200 |
| Message-ID | <87wqgvgwhh.fsf@elektro.pacujo.net> |
| In reply to | #66515 |
Ian Kelly <ian.g.kelly@gmail.com>: >>>> (1).__str__() > '1' Fair enough. The syntactic awkwardness, then, explains why numbers don't have an evolved set of methods (unlike strings). Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-16 22:24 +1100 |
| Message-ID | <mailman.7049.1392549885.18130.python-list@python.org> |
| In reply to | #66523 |
On Sun, Feb 16, 2014 at 9:52 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>>>>> (1).__str__()
>> '1'
>
> Fair enough.
>
> The syntactic awkwardness, then, explains why numbers don't have an
> evolved set of methods (unlike strings).
No; it's more that numbers are more often used with either operators
or polymorphic functions. Yes, you can add strings together with +,
but with numbers, you also subtract them, multiply them (okay, you can
multiply a string by a number, but that kinda counts one to each), and
divide them (some languages let you divide a string by a string, but
Python does that with the .split() method). There are only two types
of string, and arguably one of them is more an array of bytes than it
is a string; but with numbers, you have
int/float/complex/Fraction/Decimal, and rather than create methods
that have to be implemented by each, there are stand-alone functions
instead.
Strings get methods:
>>> "a b c d".count(" ")
3
>>> "asdf".capitalize()
'Asdf'
>>> "asdf".center(20)
' asdf '
Numbers get functions:
>>> math.sqrt(100)
10.0
>>> math.sqrt(100.0)
10.0
>>> math.log(1234)
7.1180162044653335
Sometimes the line is blurred:
>>> help(math.trunc)
Help on built-in function trunc in module math:
trunc(x)
Truncates x to the nearest Integral toward 0. Uses the __trunc__
magic method.
Which could have been done as x.trunc() instead:
>>> 0o1.__trunc__
<built-in method __trunc__ of int object at 0x1E288A30>
>>> 1.0.__trunc__
<built-in method __trunc__ of float object at 0x012AF400>
>>> (1+0j).__trunc__
Traceback (most recent call last):
File "<pyshell#14>", line 1, in <module>
(1+0j).__trunc__
AttributeError: 'complex' object has no attribute '__trunc__'
>>> math.trunc(1+0j)
Traceback (most recent call last):
File "<pyshell#16>", line 1, in <module>
math.trunc(1+0j)
TypeError: type complex doesn't define __trunc__ method
But in a lot of cases, it makes good sense to have a single function
that can take many types of number (since, after all, it's possible to
define a lot of functions in terms of the basic operators), whereas
doing them as methods would entail duplicating code.
Partly it's just a matter of expectations. People expect strings to
have more methods and numbers to use more operators, so a string
method is discoverable and an int method is less so. (When was the
last time *you* checked to see what methods an int has?)
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-16 12:04 +0000 |
| Message-ID | <5300a94b$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66523 |
On Sun, 16 Feb 2014 12:52:58 +0200, Marko Rauhamaa wrote:
> Ian Kelly <ian.g.kelly@gmail.com>:
>
>>>>> (1).__str__()
>> '1'
>
> Fair enough.
>
> The syntactic awkwardness, then, explains why numbers don't have an
> evolved set of methods (unlike strings).
But numbers do have an evolved set of methods.
py> [name for name in vars(int) if not name.startswith("_")]
['numerator', 'imag', 'to_bytes', 'from_bytes', 'bit_length', 'real',
'conjugate', 'denominator']
py> [name for name in vars(float) if not name.startswith("_")]
['fromhex', 'imag', 'as_integer_ratio', 'is_integer', 'hex', 'real',
'conjugate']
py> [name for name in vars(complex) if not name.startswith("_")]
['imag', 'real', 'conjugate']
To say nothing of these numbers:
py> from decimal import Decimal
py> [name for name in vars(Decimal) if not name.startswith("_")]
['canonical', 'exp', 'to_integral_value', 'logical_xor', 'imag',
'same_quantum', 'log10', 'max_mag', 'is_snan', 'to_eng_string', 'ln',
'is_normal', 'min', 'is_subnormal', 'to_integral_exact', 'is_nan',
'logb', 'is_qnan', 'logical_or', 'radix', 'real', 'max', 'normalize',
'as_tuple', 'is_canonical', 'is_zero', 'copy_negate', 'min_mag',
'next_plus', 'is_finite', 'number_class', 'scaleb', 'is_signed',
'compare_total', 'next_toward', 'adjusted', 'fma', 'rotate',
'logical_and', 'from_float', 'to_integral', 'next_minus',
'remainder_near', 'compare_signal', 'quantize', 'is_infinite',
'copy_sign', 'shift', 'compare_total_mag', 'copy_abs', 'compare',
'conjugate', 'logical_invert', 'sqrt']
That's more methods than strings have:
py> len([name for name in vars(Decimal) if not name.startswith("_")])
54
py> len([name for name in vars(str) if not name.startswith("_")])
44
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-16 18:17 +0200 |
| Message-ID | <87lhxbghhe.fsf@elektro.pacujo.net> |
| In reply to | #66526 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> On Sun, 16 Feb 2014 12:52:58 +0200, Marko Rauhamaa wrote:
>> The syntactic awkwardness, then, explains why numbers don't have an
>> evolved set of methods (unlike strings).
>
> But numbers do have an evolved set of methods.
> [...]
> py> from decimal import Decimal
> py> [name for name in vars(Decimal) if not name.startswith("_")]
> ['canonical', 'exp', 'to_integral_value', 'logical_xor', 'imag',
> 'same_quantum', 'log10', 'max_mag', 'is_snan', 'to_eng_string', 'ln',
> 'is_normal', 'min', 'is_subnormal', 'to_integral_exact', 'is_nan',
> 'logb', 'is_qnan', 'logical_or', 'radix', 'real', 'max', 'normalize',
> 'as_tuple', 'is_canonical', 'is_zero', 'copy_negate', 'min_mag',
> 'next_plus', 'is_finite', 'number_class', 'scaleb', 'is_signed',
> 'compare_total', 'next_toward', 'adjusted', 'fma', 'rotate',
> 'logical_and', 'from_float', 'to_integral', 'next_minus',
> 'remainder_near', 'compare_signal', 'quantize', 'is_infinite',
> 'copy_sign', 'shift', 'compare_total_mag', 'copy_abs', 'compare',
> 'conjugate', 'logical_invert', 'sqrt']
That's more like it!
Alas:
>>> (2).sqrt()
AttributeError: 'int' object has no attribute 'sqrt'
>>> (2.0).sqrt()
AttributeError: 'float' object has no attribute 'sqrt'
>>> import math
>>> math.sqrt(2)
1.4142135623730951
Also, unfortunately:
>>> (2.0).hex()
'0x1.0000000000000p+1'
>>> (2).hex()
AttributeError: 'int' object has no attribute 'hex'
There's still some evolving to do. The "smallness" of numbers is still
shining through.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2014-02-16 10:35 +0200 |
| Message-ID | <qotmwhr4fqv.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #66513 |
Marko Rauhamaa <marko@pacujo.net> writes: > Marko Rauhamaa <marko@pacujo.net>: > > > Conceptually, the "everything is a reference" and the "small"/"big" > > distinction are equivalent (produce the same outcomes). The question > > is, which model is easier for a beginner to grasp. > > Case in point, if everything is a reference, how come: > > >>> "hello".__str__() > 'hello' > >>> 1.__str__() > SyntaxError: invalid syntax That's just a clash with number syntax. Once succesfully parsed, there is no such difference: >>> (1).__str__() '1' >>> 1 .__str__() '1' (I'm not saying anything about anything being a reference, just that your example didn't get analyzed to a level where there are things.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-16 01:35 -0700 |
| Message-ID | <mailman.7043.1392539780.18130.python-list@python.org> |
| In reply to | #66513 |
On Sun, Feb 16, 2014 at 1:28 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote: > > On Feb 16, 2014 1:11 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote: >> Case in point, if everything is a reference, how come: >> >> >>> "hello".__str__() >> 'hello' >> >>> 1.__str__() >> SyntaxError: invalid syntax > > You need parentheses around the 1. Otherwise you confuse the lexer, which > thinks you're starting a float literal. > >>>> (1).__str__() > '1' Or if the parentheses bother you, you can also just toss in some whitespace: >>> 1 .__str__() '1'
[toc] | [prev] | [next] | [standalone]
| From | Alan Bawden <alan@scooby-doo.csail.mit.edu> |
|---|---|
| Date | 2014-02-16 03:38 -0500 |
| Message-ID | <w2deh33cuzk.fsf@scooby-doo.csail.mit.edu> |
| In reply to | #66513 |
Marko Rauhamaa <marko@pacujo.net> writes: > Case in point, if everything is a reference, how come: > > >>> "hello".__str__() > 'hello' > >>> 1.__str__() > SyntaxError: invalid syntax >>> (1).__str__() '1' >>> 1..__str__() '1.0' -- Alan Bawden
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-16 08:40 +0000 |
| Message-ID | <5300797c$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66513 |
On Sun, 16 Feb 2014 10:08:22 +0200, Marko Rauhamaa wrote: > Case in point, if everything is a reference, how come: > > >>> "hello".__str__() > 'hello' > >>> 1.__str__() > SyntaxError: invalid syntax Because it is a syntax error, just like the parser tells you. When the parser sees "1." it expects a floating point number, and "1.__str__()" is not a legal float. There are three simple ways to get the effect that you want: py> x = 1; x.__str__() # don't use a literal '1' py> (1).__str__() # parenthesize the literal '1' py> 1 .__str__() # offset it from the dot with a space '1' -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-16 21:18 +1100 |
| Message-ID | <mailman.7048.1392545902.18130.python-list@python.org> |
| In reply to | #66519 |
On Sun, Feb 16, 2014 at 7:40 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > There are three simple ways to get the effect that you want: > > py> x = 1; x.__str__() # don't use a literal > '1' > py> (1).__str__() # parenthesize the literal > '1' > py> 1 .__str__() # offset it from the dot with a space > '1' Four: >>> 0o1.__str__() # use a literal notation that doesn't allow floats '1' ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2014-02-16 12:10 -0500 |
| Message-ID | <mailman.7067.1392570906.18130.python-list@python.org> |
| In reply to | #66513 |
On Sun, 16 Feb 2014 01:28:34 -0700, Ian Kelly <ian.g.kelly@gmail.com>
declaimed the following:
>On Feb 16, 2014 1:11 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote:
>>
>> Marko Rauhamaa <marko@pacujo.net>:
>>
>> > Conceptually, the "everything is a reference" and the "small"/"big"
>> > distinction are equivalent (produce the same outcomes). The question
>> > is, which model is easier for a beginner to grasp.
>>
>> Case in point, if everything is a reference, how come:
>>
>> >>> "hello".__str__()
>> 'hello'
>> >>> 1.__str__()
>> SyntaxError: invalid syntax
>
>You need parentheses around the 1. Otherwise you confuse the lexer, which
>thinks you're starting a float literal.
>
>>>> (1).__str__()
>'1'
Don't even need the parens...
>>> 1 .__str__()
'1'
>>>
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2014-02-14 15:45 -0500 |
| Message-ID | <mailman.6935.1392410739.18130.python-list@python.org> |
| In reply to | #66319 |
On 2/14/14 3:17 PM, Ian Kelly wrote: > On Fri, Feb 14, 2014 at 12:56 PM, Marko Rauhamaa <marko@pacujo.net> wrote: >> There are two fundamentally different kinds of values in Python: "small" >> values and "big" values. A variable can only hold a small value. A list >> element can only hold a small value. A dictionary entry can only hold a >> small value. The same is true for an object member (aka field). >> >> So we have four kinds of (memory) slots: variables, list elements, >> dictionary entries and fields. Any slot can only hold a small value. >> >> The small values include numbers, booleans (True or False) and >> references. All other values are big, too big to fit in a slot. They >> have to be stored in a "vault" big enough to hold them. This vault is >> called the heap. Big values cannot be stored in slots directly; instead, >> references to big values are used. > > This is nonsense. Python the language makes no such distinction > between "big" and "small" values. *All* objects in CPython are stored > internally on the heap. Other implementations may use different > memory management schemes. > Marko, I have to agree with Ian. While I really like the picture you drew, the distinction between big and small values is pure fiction. CPython does not store ints directly in list elements, for example. All names are references to values. All list elements (and dictionary values, dictionary keys, set elements, etc) are references to values. A value can be another container like a list, or it can be something "simple" like an int. This covers all the details, including pictures like Marko's, but with an explanation why we draw the ints inside the boxes: http://nedbatchelder.com/text/names.html -- Ned Batchelder, http://nedbatchelder.com
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-14 13:12 -0700 |
| Message-ID | <mailman.6933.1392408815.18130.python-list@python.org> |
| In reply to | #66314 |
On Fri, Feb 14, 2014 at 11:54 AM, dave em <daveandem2000@gmail.com> wrote: > Thanks for your quick response. I'm still not sure we understand. The code below illustrates the concept we are trying to understand. > > Case 1: Example of variable with a specific value from P 170 of IYOCGWP > >>>> spam = 42 >>>> cheese = spam >>>> spam = 100 >>>> spam > 100 >>>> cheese > 42 > > Case 2: Example of variable with a list reference from p 170 > >>>> spam = [0, 1, 2, 3, 4, 5] >>>> cheese = spam >>>> cheese[1] = 'Hello!' >>>> spam > [0, 'Hello!', 2, 3, 4, 5] >>>> cheese > [0, 'Hello!', 2, 3, 4, 5] > > What I am trying to explain is this, why in case 1 when acting on spam (changing the value from 42 to 100) only affects spam and not cheese. Meanwhile, in case two acting on cheese also affects spam. In the first case, after the assignment "cheese = spam", the names spam and cheese are bound to the same object (42). If you were to modify the object 42 (which you cannot do in this case, because ints are immutable) then you would see the change reflected in the object regardless of which name you used to access it. You then rebind the name "spam" to a different object (100), which does not affect the binding of the name "cheese" at all; the names end up referring to different objects. In the second case, after the assignment "cheese = spam", the names again are bound to the same object, a list. The assignment "cheese[1] = 'Hello!'" then *modifies* that list, without rebinding cheese. cheese and spam continue to refer to the same object, and since it was modified you can see the change in that object regardless of which name you used to access it. If in the second case, you were to explicitly copy the list (e.g. "cheese = list(spam)") prior to modifying it, then the two names would instead be bound to different objects, and so subsequently modifying one would not affect the other. So the short answer is that there is no difference at all between the way that names are bound to ints and the way they are bound to lists. There only superficially appears to be a difference because ints are immutable and lists are not.
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2014-02-14 22:36 +0200 |
| Message-ID | <qot4n41tosb.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #66314 |
dave em writes: > On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote: > > dave em writes: > > > > > He is asking a question I am having trouble answering which is > > > how a variable containing a value differs from a variable > > > containing a list or more specifically a list reference. > > > > My quite serious answer is: not at all. In particular, a list is a > > value. > > > > All those pointers to references to locations are implementation > > details. The user of the language needs to understand that an > > object keeps its identity when it's passed around: passed as an > > argument, returned by a function, stored in whatever location, > > retrieved from whatever location. > > Thanks for your quick response. I'm still not sure we understand. > The code below illustrates the concept we are trying to understand. > > Case 1: Example of variable with a specific value from P 170 of IYOCGWP > > >>> spam = 42 > >>> cheese = spam > >>> spam = 100 > >>> spam > 100 > >>> cheese > 42 In case 1, you have only assignments to variables. After spam = 100, the value of spam is another number. The previous number 42 itself is still 42 - number are not mutable, and no attempt was made to change the number. In cheese = spam, cheese is the variable while spam is a variable reference and stands for 42. > Case 2: Example of variable with a list reference from p 170 > > >>> spam = [0, 1, 2, 3, 4, 5] > >>> cheese = spam > >>> cheese[1] = 'Hello!' > >>> spam > [0, 'Hello!', 2, 3, 4, 5] > >>> cheese > [0, 'Hello!', 2, 3, 4, 5] The first two statements in case 2 are assignments to variables, just like in case 1, but the third statement is different: it doesn't change the value of the variable (the value is still the same object) but it does change the value (replaces one element of the list with another). You don't need to mention the variable cheese here. Note how the value of spam is now different (though still the same object), even though you didn't mention spam at all when you changed it. Python syntax to replace an element of a list looks much like an assignment - many languages do this - but it's not. Behind the scenes it's a method call >>> cheese.__setitem__(1, 'spam') where cheese is a variable reference. You are calling a method of the list that is the value of the variable. > What I am trying to explain is this, why in case 1 when acting on > spam (changing the value from 42 to 100) only affects spam and not > cheese. Meanwhile, in case two acting on cheese also affects spam. Would it help to say that in case 1 the relevant statement acts on the variable while in case 2 it acts on the value of the variable? This is accurate, I just don't know if it happens to be the thing that helps. One last thing: a variable is not an object.
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-02-16 01:03 +1300 |
| Message-ID | <bm93ccFhndqU1@mid.individual.net> |
| In reply to | #66324 |
Jussi Piitulainen wrote:
> Would it help to say that in case 1 the relevant statement acts on the
> variable while in case 2 it acts on the value of the variable?
I would try to avoid using words like "value" and "variable",
because they don't have well-defined meanings in Python.
The way I would put it is that
a = b
changes which object the name 'a' refers to, whereas
a[i] = b
does not.
--
Greg
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-15 23:21 +1100 |
| Message-ID | <mailman.6987.1392466895.18130.python-list@python.org> |
| In reply to | #66324 |
Jussi Piitulainen <jpiitula@ling.helsinki.fi> writes: > In cheese = spam, cheese is the variable while spam is a variable > reference and stands for 42. Oof. This distinction between “variable” and “variable reference” is bogus and unnecessary, and highlights what is wrong with talking about “variable” at all. In the Python code ‘cheese = spam’, “cheese” is a name, and “spam” is a name. Both of them are references (because all names are references). The assignment binds the name “cheese” to whatever object the name “spam” was bound to at that point in time. In either case, a different kind of reference (for example, a list item) could have been used. Names are merely one kind of reference. > > >>> spam = [0, 1, 2, 3, 4, 5] > > >>> cheese = spam > > >>> cheese[1] = 'Hello!' > > >>> spam > > [0, 'Hello!', 2, 3, 4, 5] > > >>> cheese > > [0, 'Hello!', 2, 3, 4, 5] > > The first two statements in case 2 are assignments to variables, just > like in case 1, but the third statement is different: it doesn't > change the value of the variable (the value is still the same object) > but it does change the value (replaces one element of the list with > another). Again, this distinction is nonsense and confusing. What is happening in all those assignments is: A reference (the expression on the left-hand-side of the ‘=’ symbol) is bound to an object (the value resulting from the expression on the right-hand-side of the ‘=’ symbol). In the first two cases, the reference happens to be a name. In the third case, the reference happens to be a list item. > Would it help to say that in case 1 the relevant statement acts on the > variable while in case 2 it acts on the value of the variable? This is > accurate, I just don't know if it happens to be the thing that helps. I think not. What would help is to abandon the “variable” baggage, and focus on what assignment actually does: binds a reference to an object. > One last thing: a variable is not an object. Right. Also: a reference is not an object, but a reference always refers to exactly one object. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web