Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote:
> On Sat, 03 Jun 2006 17:03:00 -0700
> [EMAIL PROTECTED] (Alex Martelli) wrote:
>
> #> Terry Reedy <[EMAIL PROTECTED]> wrote:
> #>
> #> > Depends what one means by 'copy'. See below for your alternate wording.
> #>
> #> Please give me a reasonable d
[EMAIL PROTECTED] wrote:
> Yes. You stated it quite precisely. I believe l1==l2 should always
> return True and l1==l3 should always be False. (unless l3 is reassigned
> as l3=l1). Your idea of a separate operator for 'all elements have
> numerically equal values at the moment of comparision' is
On Sat, 03 Jun 2006 17:03:00 -0700
[EMAIL PROTECTED] (Alex Martelli) wrote:
#> Terry Reedy <[EMAIL PROTECTED]> wrote:
#>
#> > Depends what one means by 'copy'. See below for your alternate wording.
#>
#> Please give me a reasonable definition of the unadorned word "copy"
#> which would make thi
Terry Reedy <[EMAIL PROTECTED]> wrote:
> > it's EXACTLY the
> > concatenation of three copies of that string -- no more, no less.
>
> Depends what one means by 'copy'. See below for your alternate wording.
Please give me a reasonable definition of the unadorned word "copy"
which would make this
"Alex Martelli" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>> <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>> > (As an aside, may I point out that Python In A Nutshell states on page
>> > 46 "The result of S*n or n*S is
Hey Alex, lighten up! Python is a programming language -- not your
family, religion, or civil rights.
Cheers,
Mike
Alex Martelli wrote:
> <[EMAIL PROTECTED]> wrote:
>...
> > (As an aside, may I point out that Python In A Nutshell states on page
> > 46 "The result of S*n or n*S is the concatena
Alex Martelli wrote:
> <[EMAIL PROTECTED]> wrote:
>> Can somebody please shut down this bot? I think it's running out of
>
> Much as you might love for somebody to "shut me down", that
> (unfortunately, no doubt, from your viewpoint) is quite unlikely to
> happen. Although "making predictions
<[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
>
> [snip]
>
> Can somebody please shut down this bot? I think it's running out of
Much as you might love for somebody to "shut me down", that
(unfortunately, no doubt, from your viewpoint) is quite unlikely to
happen. Although "making predict
Alex Martelli wrote:
[snip]
Can somebody please shut down this bot? I think it's running out of
control. It seems to be unable to understand that "don't be evil" might
be good when you're small (at least it's not very bad) but that it
becomes distinctly evil when you're big.
What is good when
Terry Reedy <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > (As an aside, may I point out that Python In A Nutshell states on page
> > 46 "The result of S*n or n*S is the concatenation of n copies of S".
>
> It would be more exact to say that S*n is
<[EMAIL PROTECTED]> wrote:
...
> (As an aside, may I point out that Python In A Nutshell states on page
> 46 "The result of S*n or n*S is the concatenation of n copies of S". It
> might be well to put a warning in a future edition that this is not
> strictly the case.)
Can you give me an exampl
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> (As an aside, may I point out that Python In A Nutshell states on page
> 46 "The result of S*n or n*S is the concatenation of n copies of S".
It would be more exact to say that S*n is [] extended with S n times,
which makes it clear
Perhaps a little background to my original post will defuse some of the
controversy. While working during an airline flight, I ran into an
unexpected outcome from using the * replication operator to initialize
an array of lists. When I modified a single element of the array an
entire column chang
Alex Martelli wrote:
> to be called "identical" by ALL observers (because trying to
> ascertain the differences, if any, would inevitably perturb the
> systems irretrievably by Heisenberg's effect
Not to detract from your point, but the "Heisenberg effect", if
you mean the "Heisenberg uncertain
Alex Martelli wrote:
> Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote:
> > On Thu, 01 Jun 2006 13:40:34 -0700 [EMAIL PROTECTED] wrote:
> > #> Scott David Daniels wrote: #> > Would you say that envelope
> > containing five $100 bills is equal to #> > an envelope containing
> > five $100 bills with dif
"Aahz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Except, of course, that BofA doesn't exist anymore. Oh, the *name*
> does, but what's now called BofA is simply the current name of the bank
> that acquired BofA.
In Pythonese, they performed
SomeBank.extend(BofA)
BofA = Some
In article <[EMAIL PROTECTED]>,
Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>Just to share some tidbits (about which, as an Italian now living
>between San Francisco and San Jose, I'm sort of proud of...!-)...:
>
>Bank of America is a private bank, founded in San Francisco more than
>100 years ago b
On Thu, 01 Jun 2006 19:16:16 -0700
[EMAIL PROTECTED] (Alex Martelli) wrote:
#> > What does "parallel mutations" mean? In particular, what should be the
#> > results of each of the following three comparisons:
#> >
#> > x, y, z = [1],[1],[1]
#> > a, b = [x,y], [y,z]
#> > c, d = [[1],[1]], [[1],[1]
Le Vendredi 02 Juin 2006 00:12, [EMAIL PROTECTED] a écrit :
> I believe that 'is' tests equality of reference, such that
>
> >>> a = range(1,3)
> >>> b = range(1,3)
> >>> a is b
>
> False
>
> The 'is' operator tells you whether a and b refer to the same object.
Yeah ! That's it. And you proposed a
Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote:
> On Thu, 01 Jun 2006 15:12:23 -0700
> [EMAIL PROTECTED] wrote:
>
> #> I believe that 'is' tests equality of reference, such that
> #>
> #> >>> a = range(1,3)
> #> >>> b = range(1,3)
> #> >>> a is b
> #> False
> #>
> #> The 'is' operator tells you wh
Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote:
> On Thu, 01 Jun 2006 13:40:34 -0700
> [EMAIL PROTECTED] wrote:
>
> #> Scott David Daniels wrote:
> #> > Would you say that envelope containing five $100 bills is equal to
> #> > an envelope containing five $100 bills with different serial numbers?
>
<[EMAIL PROTECTED]> wrote:
...
> I agree with Alex that checking for this type of inequality is not a
> trivial programming exercise. It requires (at least) a parallel
I'm not asking for ANY programming: I'm asking for a *straightforward
operational definition*. If the concept which you hanke
<[EMAIL PROTECTED]> wrote:
> Hi Alex,
> With all due respect to your well-deserved standing in the Python
> community, I'm not convinced that equality shouldn't imply invariance
> under identical operations.
So, why aren't you satisfying my request? Provide a simple concrete
definition of what y
On Thu, 01 Jun 2006 15:12:23 -0700
[EMAIL PROTECTED] wrote:
#> I believe that 'is' tests equality of reference, such that
#>
#> >>> a = range(1,3)
#> >>> b = range(1,3)
#> >>> a is b
#> False
#>
#> The 'is' operator tells you whether a and b refer to the same object.
#> What I've been discussing
I believe that 'is' tests equality of reference, such that
>>> a = range(1,3)
>>> b = range(1,3)
>>> a is b
False
The 'is' operator tells you whether a and b refer to the same object.
What I've been discussing is whether == should test for "structural"
equality so that a and b remain equivalent u
On Thu, 01 Jun 2006 13:40:34 -0700
[EMAIL PROTECTED] wrote:
#> Scott David Daniels wrote:
#> > Would you say that envelope containing five $100 bills is equal to
#> > an envelope containing five $100 bills with different serial numbers?
#> Yes (unless I was testing the assertion that the second e
Truthfully, I wouldn't mind it at all. In Python, I frequently write
things like
i == int(f)
or vice versa just to avoid subtle bugs that sometimes creep in when
later modifications to code change the original assumptions.
When working in C, I always set the compiler for maximum warnings and
d
Le Jeudi 01 Juin 2006 18:00, [EMAIL PROTECTED] a écrit :
> Perhaps the most fundamental notion is mathematics is that the left and
> right sides of an equation remain identical after any operation applied
> to both sides.
IMHO, you are not aware that the '=' symbol of mathematics exists in python,
[EMAIL PROTECTED] wrote:
> With all due respect to your well-deserved standing in the Python
> community, I'm not convinced that equality shouldn't imply invariance
> under identical operations.
Doo you really want
2 == 2.0
to be False?
--
Erik Max Francis && [EMAIL PROTECTED] && http
Yes (unless I was testing the assertion that the second envelope did
not contain counterfeits of the first)
Scott David Daniels wrote:
> Would you say that envelope containing five $100 bills is equal to
> an envelope containing five $100 bills with different serial numbers?
--
http://mail.pytho
Considering the number of new programmers who get bit by automatic
coercion, I wish Dennis Ritchie had made some different choices when he
designed C. But then I doubt he ever dreamed it would become so wildly
successful.
Being a curmudgeon purist I'd actually prefer it if Python raised a
TypeErr
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>Yes. You stated it quite precisely. I believe l1==l2 should always
>return True and l1==l3 should always be False. (unless l3 is reassigned
>as l3=l1). Your idea of a separate operator for 'all elements have
>numerically equal values at
[EMAIL PROTECTED] wrote:
> Hi Alex,
> With all due respect to your well-deserved standing in the Python
> community, I'm not convinced that equality shouldn't imply invariance
> under identical operations.
>
> Perhaps the most fundamental notion is mathematics is that the left and
> right sides of
Yes. You stated it quite precisely. I believe l1==l2 should always
return True and l1==l3 should always be False. (unless l3 is reassigned
as l3=l1). Your idea of a separate operator for 'all elements have
numerically equal values at the moment of comparision' is a good one.
For want of a better
Hi Tim,
In your example, a & b are references to the same object. I agree they
should compare equally. But please note that a==b is True at every
point in your example, even after the ValueError raised by b.remove(1).
That's good consistent behavior.
My original example is a little different.
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>Hi Alex,
>With all due respect to your well-deserved standing in the Python
>community, I'm not convinced that equality shouldn't imply invariance
>under identical operations.
>
>Perhaps the most fundamental notion is mathematics is that
[EMAIL PROTECTED] wrote:
> As to containers, would you say that envelope containing five $100
> bills is the same as an envelope containing a single $100 bill and 4
> xerox copies of it? If so, I'd like to engage in some envelope
> exchanges with you :-)
Would you say that envelope containing fi
[EMAIL PROTECTED] wrote:
> As to containers, would you say that envelope containing five $100
> bills is the same as an envelope containing a single $100 bill and 4
> xerox copies of it? If so, I'd like to engage in some envelope
> exchanges with you :-)
if you spent as much time *learning* stuf
[EMAIL PROTECTED]
> ...
> As I see it, reference copying is a very useful performance and memory
> optimization. But I don't think it should undermine the validity of
> assert(a==b) as a predictor of invariance under identical operations.
So, as Alex said last time,
Try concisely expressing
> As to containers, would you say that envelope containing five $100
> bills is the same as an envelope containing a single $100 bill and 4
> xerox copies of it? If so, I'd like to engage in some envelope
> exchanges with you :-)
if len(set([bill.serialnumber for bill in envelope])) !=
len(envel
oops! last sentence of 2nd paragraph in previous message should read
"If my expectation is NOT met ..."
--
http://mail.python.org/mailman/listinfo/python-list
Hi Alex,
With all due respect to your well-deserved standing in the Python
community, I'm not convinced that equality shouldn't imply invariance
under identical operations.
Perhaps the most fundamental notion is mathematics is that the left and
right sides of an equation remain identical after any
<[EMAIL PROTECTED]> wrote:
...
> operations. I think what must be going on is that the 'b' list
> contains replicated references instead of copies of [range(1,3)]*2 .
Right.
> IMO, python's == operator should detect this difference in list
> structure since it leads to different behavior unde
The following script puzzles me. It creates two nested lists that
compare identically. After identical element assignments, the lists
are different. In one case, a single element is replaced. In the
other, an entire column is replaced.
---
44 matches
Mail list logo
