On 7/15/2017 7:35 AM, oyster wrote:
as the title says. has @ been used in projects?
@ was added as an operator for the benefit of numpy, which is a hugh
project. I am pretty sure that it is used there, but you can ask on
some numpy list.
--
Terry Jan Reedy
--
https://mail.python.org/mail
sorry, I mean "PEP 465 - A dedicated infix operator for matrix
multiplication" on
https://docs.python.org/3/whatsnew/3.5.html#whatsnew-pep-465
2017-07-15 20:05 GMT+08:00 Matt Wheeler :
> On Sat, 15 Jul 2017, 12:35 oyster, wrote:
>>
>> as the title says. has @ been used in projects?
>
>
> Strictl
On Sat, 15 Jul 2017, 13:49 Christian Heimes, wrote:
> @ is an actual operator in Python. It was added in Python 3.5 as infix
> matrix multiplication operator, e.g.
>
>m3 = m1 @ m2
>
TIL
The operator is defined in PEP 465,
> https://www.python.org/dev/peps/pep-0465/
Perhaps it should also
Chris Angelico wrote:
> On Sat, Jul 15, 2017 at 11:05 PM, Peter Otten <__pete...@web.de> wrote:
>> Matt Wheeler wrote:
>>
as the title says. has @ been used in projects?
>>
>> numpy, probably?
>>
>>> Strictly speaking, @ is not an operator.
>>
>> In other words it's not popular, not even wide
On Sat, Jul 15, 2017 at 11:05 PM, Peter Otten <__pete...@web.de> wrote:
> Matt Wheeler wrote:
>
>>> as the title says. has @ been used in projects?
>
> numpy, probably?
>
>> Strictly speaking, @ is not an operator.
>
> In other words it's not popular, not even widely known.
>
> Compare:
>
> $ pytho
Matt Wheeler wrote:
>> as the title says. has @ been used in projects?
numpy, probably?
> Strictly speaking, @ is not an operator.
In other words it's not popular, not even widely known.
Compare:
$ python3.4 -c '__pete...@web.de'
File "", line 1
__pete...@web.de
^
SyntaxErr
On 2017-07-15 14:05, Matt Wheeler wrote:
> On Sat, 15 Jul 2017, 12:35 oyster, wrote:
>
>> as the title says. has @ been used in projects?
>>
>
> Strictly speaking, @ is not an operator.
> It delimits a decorator statement (in python statements and operations are
> not the same thing).
> However,
On Sat, 15 Jul 2017, 12:35 oyster, wrote:
> as the title says. has @ been used in projects?
>
Strictly speaking, @ is not an operator.
It delimits a decorator statement (in python statements and operations are
not the same thing).
However, to answer the question you actually asked, yes, all the
as the title says. has @ been used in projects?
--
https://mail.python.org/mailman/listinfo/python-list
Terry Reedy :
> On 2/22/2015 4:25 PM, Marko Rauhamaa wrote:
>> This is a true statement:
>>
>> If X is Y, then id(X) == id(Y).
>>
>> However, this is generally not a true statement:
>>
>> If X is Y, then id(X) is id(Y).
>
> If X and Y exist at the *same time*, then (X is Y) == (id(X) is id
On 02/22/2015 10:02 PM, Terry Reedy wrote:
On 2/22/2015 4:25 PM, Marko Rauhamaa wrote:
LJ :
id(b[0])
4582
[...]
id(b[2])
4582
Please correct me if I am wrong, but according to this b[2] and b[0]
are the same object. Now,
b[0] is b[2]
False
This is a true statement:
If
On 2/22/2015 12:53 PM, LJ wrote:
Hi everyone. Quick question here. Lets suppose if have the
following numpy array:
b=np.array([[0]*2]*3)
and then:
id(b[0])
4582
id(b[1])
45857512
id(b[2])
4582
Please correct me if I am wrong,
You are, as other explained
> but according to th
On 2/22/2015 4:25 PM, Marko Rauhamaa wrote:
LJ :
id(b[0])
4582
[...]
id(b[2])
4582
Please correct me if I am wrong, but according to this b[2] and b[0]
are the same object. Now,
b[0] is b[2]
False
This is a true statement:
If X is Y, then id(X) == id(Y).
However, this
LJ wrote:
> Hi everyone. Quick question here. Lets suppose if have the following numpy
> array:
>
> b=np.array([[0]*2]*3)
>
> and then:
>
id(b[0])
> 4582
id(b[1])
> 45857512
id(b[2])
> 4582
>
> Please correct me if I am wrong, but according to this b[2] and b[0] are
> th
On Mon, Feb 23, 2015 at 8:25 AM, Marko Rauhamaa wrote:
> This is a true statement:
>
>If X is Y, then id(X) == id(Y).
>
> However, this is generally not a true statement:
>
>If X is Y, then id(X) is id(Y).
Irrelevant, because the identities of equal integers didn't come into this.
ChrisA
LJ :
id(b[0])
> 4582
[...]
id(b[2])
> 4582
>
> Please correct me if I am wrong, but according to this b[2] and b[0]
> are the same object. Now,
>
b[0] is b[2]
> False
This is a true statement:
If X is Y, then id(X) == id(Y).
However, this is generally not a true statem
Ooops, I missed the numpy, so I thought that it was the contents
of the array that was causing the problem. My very bad. Apologies.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
On 02/22/2015 09:53 AM, LJ wrote:
Hi everyone. Quick question here. Lets suppose if have the following numpy
array:
b=np.array([[0]*2]*3)
and then:
id(b[0])
4582
id(b[1])
45857512
id(b[2])
4582
Please correct me if I am wrong, but according to this b[2] and b[0] are the
same o
s b[2]
>>False
>
>
> You are running into one of the peculiarities of the python representation
> of numbers. It can make things more efficient to represent all common
> numbers as 'there is only one' of them.
That shouldn't break the correspondence between id() an
In a message of Sun, 22 Feb 2015 09:53:33 -0800, LJ writes:
>Hi everyone. Quick question here. Lets suppose if have the following numpy
>array:
>
>b=np.array([[0]*2]*3)
>
>and then:
>
id(b[0])
>4582
id(b[1])
>45857512
id(b[2])
>4582
>
>Please correct me if I am wrong, but ac
Hi everyone. Quick question here. Lets suppose if have the following numpy
array:
b=np.array([[0]*2]*3)
and then:
>>> id(b[0])
4582
>>> id(b[1])
45857512
>>> id(b[2])
4582
Please correct me if I am wrong, but according to this b[2] and b[0] are the
same object. Now,
>>> b[0] is b[2]
On Fri, 05 Apr 2013 06:49:14 -0700, Candide Dandide wrote:
> So, could someone please explain what exactly the is operator returns ?
> The official doc says :
>
> The ‘is‘ operator compares the identity of two objects; the id()
> function returns an integer representing its iden
On 6 April 2013 03:40, candide wrote:
> Le vendredi 5 avril 2013 16:53:55 UTC+2, Arnaud Delobelle a écrit :
>
>
> >
> > You've fallen victim to the fact that CPython is very quick to collect
> >
> > garbage.
>
>
> OK, I get it but it's a fairly unexpected behavior.
> Thanks for the demonstrative
Le vendredi 5 avril 2013 16:53:55 UTC+2, Arnaud Delobelle a écrit :
>
> You've fallen victim to the fact that CPython is very quick to collect
>
> garbage.
OK, I get it but it's a fairly unexpected behavior.
Thanks for the demonstrative snippet of code and the instructive answer.
--
http
On 5 April 2013 14:49, Candide Dandide wrote:
> Until now, I was quite sure that the is operator acts the same as the id
> builtin function, or, to be more formal, that o1 is o2 to be exactly
> equivalent to id(o1) == id(o2). This equivalence is reported in many books,
>
Until now, I was quite sure that the is operator acts the same as the id
builtin function, or, to be more formal, that o1 is o2 to be exactly equivalent
to id(o1) == id(o2). This equivalence is reported in many books, for instance
Martelli's Python in a Nutshell.
But with the following
On Sun, 27 Nov 2011 02:42:52 +0100, candide wrote:
>> Even if you can guarantee that your code base does not contain any
>> object which compares equal to None except for None itself (and how
>> would you do that? a full audit of every line of code in every library
>> you use?), the use of `is` sh
On Sun, Nov 27, 2011 at 12:42 PM, candide wrote:
> So, for the same reason, wouldn't it be better to use "if spam is True"
> against to "if spam == True" (or better "if spam") ?
>
They're quite different. "if spam" will check the truthiness of spam -
it's equivalent to "if bool(spam) is True"; "
ances comparing identities of objects is really vital.
`is` is not a function. It is a keyword and an operator.
oops exponent 10 !! I have in mind the id() function, very close to the
is operator. An operator named "is" makes search of code snippets very
complicated because the verb
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| What is the notion of equal defined for functions?
Isness. The developers did not see sufficient reason to refine it further
by comparing all the attributes, including the code object. But there has
just been a discussion on pydev
On Mar 10, 11:36 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Mon, 10 Mar 2008 07:39:25 -0700, Gary Herron wrote:
> > If either is a surprise, then understand that the "is" operator should
> > probably *never* be used with immutable
On Mon, 10 Mar 2008 07:39:25 -0700, Gary Herron wrote:
> If either is a surprise, then understand that the "is" operator should
> probably *never* be used with immutable types.
Carl Banks has already mentioned testing for None with "is". The standard
idiom for using
>
> > >>> x is y
>
> > True
>
> > Is this right? Why? Thanks.
>
> Yes that is true, but it's an implementation defined optimization and
> could be applied to *any* immutable type. For larger ints, such a thing
> is not true.
> >>> x=1
ght? Why? Thanks.
>
>
>
Yes that is true, but it's an implementation defined optimization and
could be applied to *any* immutable type. For larger ints, such a thing
is not true.
>>> x=1000
>>> y=1000
>>> x is y
False
If either is a surpris
On Mar 10, 9:11 pm, Matt Nordhoff <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >> I believe Python automatically creates and caches int objects for 0-256,
> >> so whenever you use them, they refer to the same exact objects. Since
> >> ints are immutable, it doesn't matter.
>
> > One of t
[EMAIL PROTECTED] wrote:
>> I believe Python automatically creates and caches int objects for 0-256,
>> so whenever you use them, they refer to the same exact objects. Since
>> ints are immutable, it doesn't matter.
>
> One of the biggest hits on start-up time, by the way. ;)
Well, the developer
> I believe Python automatically creates and caches int objects for 0-256,
> so whenever you use them, they refer to the same exact objects. Since
> ints are immutable, it doesn't matter.
One of the biggest hits on start-up time, by the way. ;)
--
http://mail.python.org/mailman/listinfo/python-l
Metal Zong wrote:
> The operator is and is not test for object identity: x is y is true if
> and only if x and y are the same objects.
>
x = 1
y = 1
x is y
> True
>
> Is this right? Why? Thanks.
I believe Python automatically creates and caches int objects for 0-256,
so whenever y
The operator is and is not test for object identity: x is y is true if and
only if x and y are the same objects.
>>> x = 1
>>> y = 1
>>> x is y
True
Is this right? Why? Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
>> I don't pretend to understand the reasons for all of this,
>> but if it is possible to use the same integer object whenever
>> it is referenced, then why should there be a limit on range?
>
> Preallocating all the 4 billion 4-byte ints would overfill the memory of
> most machines ;-)
Sure, I
Terry Reedy wrote:
> "Georg Brandl" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> tobiah wrote:
>>> Suppose I fill an list with 100 million random integers in the range
>>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>>> of '12345' pointed to the same int
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> tobiah wrote:
>> Suppose I fill an list with 100 million random integers in the range
>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>> of '12345' pointed to the same integer object? Why should m
"tobiah" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> wesley chun wrote:
>>> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>>> > as a side note, the ints that are cached (for current versions of
>>> > Python) are in range(-1, 100)... is this documented somewhere?
>>> Not true for at l
tobiah wrote:
> Simon Brunning wrote:
>
>>On 9/27/06, tobiah <[EMAIL PROTECTED]> wrote:
>>
>>>Suppose I fill an list with 100 million random integers in the range
>>>of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>>>of '12345' pointed to the same integer object? Why should mo
Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Suppose I fill an list with 100 million random integers in the range
>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>> of '12345' pointed to the same integer object? Why should more be
>> made, when they all do the same thing, and
tobiah wrote:
>>> Suppose I fill an list with 100 million random integers in the range
>>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>>> of '12345' pointed to the same integer object? Why should more be made,
>>> when they all do the same thing, and are not subject to cha
>> Suppose I fill an list with 100 million random integers in the range
>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>> of '12345' pointed to the same integer object? Why should more be made,
>> when they all do the same thing, and are not subject to change?
>
> Because
Simon Brunning wrote:
> On 9/27/06, tobiah <[EMAIL PROTECTED]> wrote:
>> Suppose I fill an list with 100 million random integers in the range
>> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
>> of '12345' pointed to the same integer object? Why should more be made,
>> when th
tobiah wrote:
> wesley chun wrote:
>>> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>>> > as a side note, the ints that are cached (for current versions of
>>> > Python) are in range(-1, 100)... is this documented somewhere?
>>> Not true for at least 2.4 and 2.5. The cached range has expanded
>>
>> o
On 9/27/06, tobiah <[EMAIL PROTECTED]> wrote:
> Suppose I fill an list with 100 million random integers in the range
> of 1 - 65535. Wouldn't I save much memory if all of the ocurrances
> of '12345' pointed to the same integer object? Why should more be made,
> when they all do the same thing, an
wesley chun wrote:
>> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>> > as a side note, the ints that are cached (for current versions of
>> > Python) are in range(-1, 100)... is this documented somewhere?
>> Not true for at least 2.4 and 2.5. The cached range has expanded
>
> oops, apologies to all.
> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> > as a side note, the ints that are cached (for current versions of
> > Python) are in range(-1, 100)... is this documented somewhere?
> Not true for at least 2.4 and 2.5. The cached range has expanded
oops, apologies to all... it really *is* subject t
"wesley chun" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> as a side note, the ints that are cached (for current versions of
> Python) are in range(-1, 100)... is this documented somewhere?
Not true for at least 2.4 and 2.5. The cached range has expanded
> i know it's subject
Wesley> as a side note, the ints that are cached (for current versions
Wesley> of Python) are in range(-1, 100)... is this documented
Wesley> somewhere?
Other than the code, probably not. Since it's an implementation
optimization, I see no particular reason that it should be document
as a side note, the ints that are cached (for current versions of
Python) are in range(-1, 100)... is this documented somewhere? i know
it's subject to change. and as already mentioned, you probably
wouldn't use "is" this way in real code... i know you are just
reinforcing your learning of the dif
Antoon Pardon wrote:
>
> I find this a bit oddly worded. Now the "may always reuse" phrase
> suggests this is not an obligation and I can certainly understand
> that in the case of integers. But when you enumerate examples you
> include None and Booleans, creating the suggestion these don't
> have
On 2006-09-26, John Roth <[EMAIL PROTECTED]> wrote:
>
> Antoon Pardon wrote:
>>
>> I find this a bit oddly worded. Now the "may always reuse" phrase
>> suggests this is not an obligation and I can certainly understand
>> that in the case of integers. But when you enumerate examples you
>> include N
"codefire" <[EMAIL PROTECTED]> writes:
> I was just trying to check if objects were the same (object), didn't
> know Integers were a special case.
They're not. The Python runtime environment can do whatever it likes
underneath the hood; the language gives no promises about any
relationship betwee
Thanks for that Fredrik, that's clear. That's actually a pretty nice
feature as it's nicely optimised.
>>> a = 10
>>> c = 10
>>> a is c
True
>>> c = c +1
>>> a is c
False
>>>
Cheers,
Tony
--
http://mail.python.org/mailman/listinfo/python-list
Haha!
OK thanks guys.
I was just trying to check if objects were the same (object), didn't
know Integers were a special case.
Thanks,
Tony
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-09-26, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> codefire wrote:
>
>> I was just trying to check if objects were the same (object), didn't
>> know Integers were a special case.
>
> they're not, really; "is" works the same way for all objects.
>
> when you ask for a new immutable object, a
codefire a écrit :
> Haha!
>
> OK thanks guys.
>
> I was just trying to check if objects were the same (object), didn't
> know Integers were a special case.
They are not a special case so much. It's just that "is" is extremly
unreliable unless you're the one who created the objects. In the case
codefire wrote:
> I was just trying to check if objects were the same (object), didn't
> know Integers were a special case.
they're not, really; "is" works the same way for all objects.
when you ask for a new immutable object, a Python implementation may
always reuse an existing object, if it w
codefire a écrit :
> I thought the 'is' operator was used to identify identical objects,
> whereas the '==' operator checked equality. Well, I got a surprise
> here:
>
> IDLE 1.1.3
>>>> a = 10
>>>> b = a
>>>> a is b
>
codefire wrote:
> I thought the 'is' operator was used to identify identical objects,
> whereas the '==' operator checked equality. Well, I got a surprise
> here:
>
> IDLE 1.1.3
>>>> a = 10
>>>> b = a
>>>> a is b
>
I thought the 'is' operator was used to identify identical objects,
whereas the '==' operator checked equality. Well, I got a surprise
here:
IDLE 1.1.3
>>> a = 10
>>> b = a
>>> a is b
True
>>> a == b
True
>>> c = 10
>>>
"> Lonnie Princehouse wrote:
>> Calling the wrapped version of this function from Python will produce a
>> Python wrapper which represents the same underlying C++ object, but is
>> not actually the same Python object:
What I think you need is a custom version of the .__eq__ (self,other)
method t
In article <[EMAIL PROTECTED]>,
Lonnie Princehouse <[EMAIL PROTECTED]> wrote:
>
>> Why did you want to customize "is"?
>
>Well, mostly out of principle ;-)
>
>But also because I'm wrapping a C library which passes around C structs
>which are wrapped in shim C++ classes for a Boost.Python layer. Bo
ng' }
>>>>b = identity(a)
>>>>b in mydict
>
> True
>
> It's quite possible that there is some way to do this correctly from
> the Boost.Python side of things... my understanding of how to use
> Boost.Python is minimal.
>
I will adopt my usual
> Why did you want to customize "is"?
Well, mostly out of principle ;-)
But also because I'm wrapping a C library which passes around C structs
which are wrapped in shim C++ classes for a Boost.Python layer. Boost
Python does a marvelous job of translating between Python and C++ data
types; when
On Thu, 26 Jan 2006 23:26:14 -0800, Lonnie Princehouse wrote:
>> (objects are not allowed to lie about who they are, or what they are).
>
> Dangit! I need to find a less honest programming language. Anyone
> have a Perl cookbook handy? ...
No, you need a better algorithm.
Why did you want to
Lonnie Princehouse enlightened us with:
> There doesn't seem to be any way to customize the behavior of "is" as
> can be done for other operators... why not?
Pure logic: A == A or A != A. An object is another object or not.
Why would you want to change that?
Sybren
--
The problem with the world
Lonnie Princehouse wrote:
>>(objects are not allowed to lie about who they are, or what they are).
>
>
> Dangit! I need to find a less honest programming language. Anyone
> have a Perl cookbook handy? ...
>
+1 QOTW (approved by a fellow Perl programmer FWIW !-)
--
bruno desthuilliers
python
> (objects are not allowed to lie about who they are, or what they are).
Dangit! I need to find a less honest programming language. Anyone
have a Perl cookbook handy? ...
--
http://mail.python.org/mailman/listinfo/python-list
Lonnie Princehouse wrote:
> There doesn't seem to be any way to customize the behavior of "is" as
> can be done for other operators... why not?
because it does "id(a) == id(b)", and there's no way to customize
the behaviour of id().
(objects are not allowed to lie about who they are, or what the
There doesn't seem to be any way to customize the behavior of "is" as
can be done for other operators... why not?
--
http://mail.python.org/mailman/listinfo/python-list
76 matches
Mail list logo
