On Fri, Jun 1, 2012 at 9:39 AM, Josh Benner wrote:
>
> Is there a good way to trace what's going on under the hood wrt operator
> overloading?
>
> I am trying to understand what is happening in the code and output listed
> below.
>
> Why doesn't __getitem__ in my
Is there a good way to trace what's going on under the hood wrt operator
overloading?
I am trying to understand what is happening in the code and output listed
below.
Why doesn't __getitem__ in mylist return the same result as the builtin
list object?
Does it have something to do with
| > > Sure. Cosines are a monadic operation and the monadic '+' is a NOP,
so
| > > why shouldn't I define +45 to return cosine of 45, (presuming I
needed
| > > lots of cosines). I'd even let you define your own operators. Lots of
| > > programmers really liked '++' and '--', for examples.
One c
On Jan 25, 8:52 pm, Hexamorph <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > Hexamorph wrote:
> >> You mean you want the ability to change for example the + operator
> >> for ints to something like calculating the cosine instead of doing
> >> addition?
>
> > Sure. Cosines are a monadic
[EMAIL PROTECTED] wrote:
>
> Hexamorph wrote:
>> You mean you want the ability to change for example the + operator
>> for ints to something like calculating the cosine instead of doing
>> addition?
>
> Sure. Cosines are a monadic operation and the monadic '+' is a NOP, so
> why shouldn't I defin
Hexamorph wrote:
> You mean you want the ability to change for example the + operator
> for ints to something like calculating the cosine instead of doing
> addition?
Sure. Cosines are a monadic operation and the monadic '+' is a NOP, so
why shouldn't I define +45 to return cosine of 45, (presum
[EMAIL PROTECTED] wrote:
>
> Diez B. Roggisch wrote:
>> No, there is no way. You would change general interpreter behavior if
>> you could set arbitrary operators for predefined types.
>>
>> Start grumping...
>
> Thank you, Diez.
>
> If I ever design a language, please remind me that complete, e
[EMAIL PROTECTED] schrieb:
>
> Diez B. Roggisch wrote:
>> No, there is no way. You would change general interpreter behavior if
>> you could set arbitrary operators for predefined types.
>>
>> Start grumping...
>
> Thank you, Diez.
>
> If I ever design a language, please remind me that complete,
Diez B. Roggisch wrote:
> No, there is no way. You would change general interpreter behavior if
> you could set arbitrary operators for predefined types.
>
> Start grumping...
Thank you, Diez.
If I ever design a language, please remind me that complete, easy,
well-documented access to the worki
[EMAIL PROTECTED] schrieb:
> If it were my choice, the plus sign would do this:
>
> def itemadd( i1, i2 ):
> if ( type(i1) == str ) or ( type(i2) == str ):
> return str(i1) + str(i2)
> else:
> return i1 + i2
>
> I'd like to redefine it
If it were my choice, the plus sign would do this:
def itemadd( i1, i2 ):
if ( type(i1) == str ) or ( type(i2) == str ):
return str(i1) + str(i2)
else:
return i1 + i2
I'd like to redefine it so it works my way but operator overloading
seems strictly confined to clas
On Thu, 08 Nov 2007 22:53:16 -0800, r.grimm wrote:
(1).__cmp__(10)
> -1
As the dot is an operator like ``+`` or ``/`` you can also add spaces to
avoid the ambiguity:
In [493]: 1 . __cmp__(10)
Out[493]: -1
In [494]: 1 .__cmp__(10)
Out[494]: -1
Ciao,
Marc 'BlackJack' Rintsch
--
htt
[EMAIL PROTECTED] wrote:
(1).__cmp__(10)
> -1
Integer object "(1)" followed by method call ".__cmp__(10)"
1.__cmp__(10)
> File "", line 1
> 1.__cmp__(10)
> ^
> SyntaxError: invalid syntax
Floating point number "1." followed by "__cmp__(10)".
STeVe
--
http://mail.pyt
Hallo,
could you explaint me the difference between the two following
statements.
Python 2.5 (r25:51908, Oct 7 2006, 23:45:05)
[GCC 3.3.5 20050117 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (1).__cmp__(10)
-1
>>> 1.__cmp__(10)
[EMAIL PROTECTED] wrote:
> On Apr 4, 4:55 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>> "Ziga Seilnacht" <[EMAIL PROTECTED]> wrote in message
>>
>> news:[EMAIL PROTECTED]
>> | This looks like a bug in Python. It works for all the other
>> | operators:
> [SNIP]
>> | >>> i ** 3
>> | 74088
>> |
>> |
looping wrote:
> Hi,
> for the fun I try operator overloading experiences and I didn't
> exactly understand how it works.
>
> Here is my try:
>>>> class myint(int):
> def __pow__(self, value):
> return self.__add__(value)
>
>>&g
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| FWIW:
| Python 2.5 (r25:51908, Jan 21 2007, 03:10:25)
| [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on HOSTNAME_REDACTED
| Type "help", "copyright", "credits" or "license" for more information.
| >>> class MyInt(int):
| ... __pow__ = in
On Apr 4, 4:55 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Ziga Seilnacht" <[EMAIL PROTECTED]> wrote in message
>
> news:[EMAIL PROTECTED]
> | This looks like a bug in Python. It works for all the other
> | operators:
[SNIP]
> | >>> i ** 3
> | 74088
> |
> | You should submit a bug report to the
"Ziga Seilnacht" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| This looks like a bug in Python. It works for all the other
| operators:
|
| >>> class MyInt(int):
| ... __sub__ = int.__add__
| ... __mul__ = int.__add__
| ... __div__ = int.__add__
| ... __truediv__ =
On Apr 4, 12:41 pm, "7stud" <[EMAIL PROTECTED]> wrote:
> According to Python in a Nutshell(p.102), a name that is a slot can
> only be "bound"(i.e. assigned to) inside the class body.
Upon closer reading, it actually says that the name "__slots__" has to
be bound inside the class body for the sl
On Apr 4, 12:41 pm, "7stud" <[EMAIL PROTECTED]> wrote:
> On Apr 4, 3:36 am, "looping" <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi,
> > for the fun I try operator overloading experiences and I didn't
> > exactly understand how it
On Apr 4, 3:36 am, "looping" <[EMAIL PROTECTED]> wrote:
> Hi,
> for the fun I try operator overloading experiences and I didn't
> exactly understand how it works.
>
> Here is my try:>>> class myint(int):
>
> def __pow__(self, value):
>
looping wrote:
> Hi,
> for the fun I try operator overloading experiences and I didn't
> exactly understand how it works.
>
> Here is my try:
> >>> class myint(int):
>
> def __pow__(self, value):
> return self.__add__(value)
>
Hi,
for the fun I try operator overloading experiences and I didn't
exactly understand how it works.
Here is my try:
>>> class myint(int):
def __pow__(self, value):
return self.__add__(value)
>>> a = myint(3)
>>> a ** 3
6
OK, it works. No
Terry Reedy wrote:
> "Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Terry Reedy wrote:
>>> "Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in message
>>> news:[EMAIL PROTECTED]
The current namespace object, of course.
>>> Implementing a namespace as a P
> Fredrik Lundh <[EMAIL PROTECTED]> (FL) wrote:
>FL> Piet van Oostrum wrote:
>>> The official Python documentation (language reference manual) talks a lot
>>> about variables. So it seems silly to say that Python doesn't have
>>> variables.
>FL> the language reference mostly uses the term "va
Terry Reedy wrote:
> Implementing a namespace as a Python object (ie, dict) is
> completely optional and implementation dependent. For CPython, the
> local namespace of a function is generally *not* done that way.
Sure, but this is all just theoretical talk anyway, right? I would
like
"Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> "Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> The current namespace object, of course.
>>
>> Implementing a namespace as a Python object (ie, dict)
Terry Reedy wrote:
> "Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> The current namespace object, of course.
>
> Implementing a namespace as a Python object (ie, dict) is completely
> optional and implementation dependent. For CPython, the local namespace
Georg Brandl wrote:
> Bruno Desthuilliers wrote:
>> Steven D'Aprano wrote:
>>> On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>>>
>> With the caveat of the "=" mentioned in the subject-line (being
>> different from "==")...I haven't found any way to override
>> assignment in the g
Paul Rubin wrote:
> The symbols on the left side of = signs are called variables even in
> Haskell, where they don't "vary" (you can't change the value of a
> variable once you have set it).
FWIW, that's the original, mathematical meaning of the word 'variable'.
They _do_ vary, but only when you
Paul Rubin wrote:
> The symbols on the left side of = signs are called variables even in
> Haskell, where they don't "vary" (you can't change the value of a
> variable once you have set it).
at the language specification level, the things to the left side of =
signs are called "targets" in Pytho
Piet van Oostrum wrote:
> The official Python documentation (language reference manual) talks a lot
> about variables. So it seems silly to say that Python doesn't have
> variables.
the language reference mostly uses the term "variables" when discussing
local variables and instance variables, an
Piet van Oostrum <[EMAIL PROTECTED]> writes:
> The official Python documentation (language reference manual) talks a lot
> about variables. So it seems silly to say that Python doesn't have
> variables.
The symbols on the left side of = signs are called variables even in
Haskell, where they don't
> Steven D'Aprano <[EMAIL PROTECTED]> (SD) wrote:
>SD> Despite sloppy talk to the contrary (which I think most of us do from time
>SD> to time), Python doesn't have variables. It has names and objects. Names
>SD> are just labels -- there is no difference in behavior between the *names*
>SD> th
Antoon Pardon <[EMAIL PROTECTED]> writes:
> Suppose one has the following intention in mind:
>
> while x = setup():
> if y = pre_process() in ErrorCondition:
> break
> post_process(y)
> else:
> NormalTermination()
Maybe we need a new itertools function:
def forever(func,
On 2006-10-10, Paul Rubin wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>> or for the perhaps-overly-clever hackers,
>>
>> for x in iter(lambda: foo() or None, None):
>> process(x)
>
> for x in takewhile(bool, (foo() for _ in repeat(None))):
> process(x)
>
> Meh, both ar
Antoon Pardon <[EMAIL PROTECTED]> writes:
> >>> for x in takewhile(foo() for _ in repeat(None)):
> ... print x
> ...
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: takewhile expected 2 arguments, got 1
Yeah, I cancelled and posted a followup
for x in takewhile(boo
On 2006-10-10, Paul Rubin wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>> or for the perhaps-overly-clever hackers,
>>
>> for x in iter(lambda: foo() or None, None):
>> process(x)
>
> for x in takewhile(foo() for _ in repeat(None)):
>process (x)
>>> for x in takewhile(foo
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> or for the perhaps-overly-clever hackers,
>
> for x in iter(lambda: foo() or None, None):
> process(x)
for x in takewhile(bool, (foo() for _ in repeat(None))):
process(x)
Meh, both are ugly.
--
http://mail.python.org/mailman/listi
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> or for the perhaps-overly-clever hackers,
>
> for x in iter(lambda: foo() or None, None):
> process(x)
for x in takewhile(foo() for _ in repeat(None)):
process (x)
--
http://mail.python.org/mailman/listinfo/python-list
Roman Neuhauser wrote:
> People who complain often fail to see how
>
>x = foo()
>while x:
>process(x)
>x = foo()
>
>is safer than
>
>while x = foo():
>process(x)
that's spelled:
for x in foo():
process(x)
in Python, or, if foo() just refuses b
# [EMAIL PROTECTED] / 2006-10-08 11:44:18 +0100:
> That's because assignment isn't an operator - that's why (for example)
>
> print x = 33
>
> would be a syntax error. This is a deliberate design decision about
> which, history shows, there is little use complaining.
Just to clarify: n
On 9 Oct 2006 11:27:40 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> I honestly don't see why "variable" would be an inappropiate word to use.
> AFAIU, python assignment seems to behave much like lisp and smalltalk
> and I never heard that those communities found the word "variable"
> inappropia
"Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> The current namespace object, of course.
Implementing a namespace as a Python object (ie, dict) is completely
optional and implementation dependent. For CPython, the local namespace of
a function is generall
Bruno Desthuilliers wrote:
> Steven D'Aprano wrote:
>> On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>>
> With the caveat of the "=" mentioned in the subject-line (being
> different from "==")...I haven't found any way to override
> assignment in the general case.
Why would
Steven D'Aprano wrote:
> On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>
With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case.
>>> Why would you want to do that?
>> For the sa
On 2006-10-08, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>
With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case.
>>>
>>> Why w
Daniel Nogradi wrote:
> > Can these operators be overloaded?
> > If so. How?
> >
>
> http://www.python.org/doc/ref/numeric-types.html
>
> HTH,
> Daniel
Thanks everyone.
--
http://mail.python.org/mailman/listinfo/python-list
Tim Chase wrote:
>>>Can these operators be overloaded?
>>
>>Yes.
>
>
> With the caveat of the "=" mentioned in the subject-line (being
> different from "==")...I haven't found any way to override
> assignment in the general case. There might be some oddball way
> to do it via property() but A
On Sat, 07 Oct 2006 17:21:55 -0500, Tim Chase wrote:
>>> With the caveat of the "=" mentioned in the subject-line (being
>>> different from "==")...I haven't found any way to override
>>> assignment in the general case.
>>
>> Why would you want to do that?
>
> For the same reason one would use p
>> With the caveat of the "=" mentioned in the subject-line (being
>> different from "==")...I haven't found any way to override
>> assignment in the general case.
>
> Why would you want to do that?
For the same reason one would use property() to create
getter/setter functions for a particular v
Tim Chase enlightened us with:
> With the caveat of the "=" mentioned in the subject-line (being
> different from "==")...I haven't found any way to override
> assignment in the general case.
Why would you want to do that?
Sybren
--
Sybren Stüvel
Stüvel IT - http://www.stuvel.eu/
--
http://ma
Tim Chase wrote:
>>> Can these operators be overloaded?
>>
>> Yes.
>
> With the caveat of the "=" mentioned in the subject-line (being
> different from "==")...I haven't found any way to override
> assignment in the general case. There might be some oddball way
> to do it via property() but A
>> Can these operators be overloaded?
>
> Yes.
With the caveat of the "=" mentioned in the subject-line (being
different from "==")...I haven't found any way to override
assignment in the general case. There might be some oddball way
to do it via property() but AFAIK, this only applies to
pr
> Can these operators be overloaded?
> If so. How?
>
http://www.python.org/doc/ref/numeric-types.html
HTH,
Daniel
--
http://mail.python.org/mailman/listinfo/python-list
SpreadTooThin enlightened us with:
> Can these operators be overloaded?
Yes.
> If so. How?
Implement __add__, __sub__ etc. in the class that you want to be able
to add, subtract, etc.
Sybren
--
Sybren Stüvel
Stüvel IT - http://www.stuvel.eu/
--
http://mail.python.org/mailman/listinfo/pytho
Can these operators be overloaded?
If so. How?
--
http://mail.python.org/mailman/listinfo/python-list
do I define new-style classes?
>
> - Edward
>
>
> Original Message Follows
> From: "Calvin Spealman" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: "Edward Waugh" <[EMAIL PROTECTED]>
> Subject: Re: Problem with operator over
On 9/17/06, Edward A. Waugh <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Consider the following code:
>
> import sys
>
> class FirstClass:
> def __init__(self, value):
> self.data = value
> def __add__(self, value):
> return FirstClass(self.data + value)
> def display(self):
>
Consider the following code:
import sys
class FirstClass: def
__init__(self, value): self.data =
""> def __add__(self,
value): return
FirstClass(self.data + value) def
display(self): print
self.data
class
SecondClass(FirstClass): def __add__(self,
Thanks a lot Fredrik and Tim for your help.
Cheers,
Mohit
--
http://mail.python.org/mailman/listinfo/python-list
> obj1 = c1(1)
>
> obj1 + 10 # this works just fine
>
10 + obj1 # throws exception
> Q. What do I have to do to make the following line work?
>
> 10 + obj1
http://docs.python.org/ref/numeric-types.html
You want to read the section on __radd__ (and it's o
Mohit Bhatt wrote:
> Hello,
>
> I just started out with python( couple of weeks).
>
> I have a query regarding Operator Overloading
>
> class c1:
> def __init__(self,value):
> self.data = value
>
Hello,
I just started out with python(
couple of weeks).
I have a query regarding Operator
Overloading
class c1:
def
__init__(self,value):
self.data
= "">
def
__add__ (self,operand2):
self.dat
On 1 Aug 2005 05:12:47 -, Gurpreet Sachdeva
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there any provision in python which allows me to make my own operators?
>
> My problem is that I need to combine two dictonaries with their keys and I
> don't want to use any of the existing operators lik
Gurpreet Sachdeva wrote:
>
> Hi,
>
> Is there any provision in python which allows me to make my own operators?
>
> My problem is that I need to combine two dictonaries with their keys and
> I don't want to use any of the existing operators like '+','-','*'.
> So is there a way I can make '**'
Hi,
Is there any provision in python which allows me to make my own operators?
My problem is that I need to combine two dictonaries with their keys and I don't want to use any of the existing operators like '+','-','*'.
So is there a way I can make '**' or '~' as my operators to add two dicto
Rory Campbell-Lange wrote:
Hi Steve
I've been playing around with your two suggestions.
The Record class is an elegant solution. It doesn't however help in the
case where the class has the following general data structure (something
I should have stated originally):
class.config1 = param
Hi Steve
I've been playing around with your two suggestions.
The Record class is an elegant solution. It doesn't however help in the
case where the class has the following general data structure (something
I should have stated originally):
class.config1 = param
class.config2 = param
Rory Campbell-Lange wrote:
Hi. I'm just starting to use python.
I am anxious about how best to set and access items one level down in a
data structure if I am using __setitem__ and __getitem__.
At the moment I can do
for a data structure Data:
object.Data = { 'one' : [1, 2, {}, 4],
Anyone out there?
Criticism about the objective of my question, not just the execution,
gratefully received!
Basically, if I have a
class This:
def __init__(self, x, y):
self.x=x
self.y=y
self.data = {}
and then make all my setitem and getitem cal
Hi. I'm just starting to use python.
I am anxious about how best to set and access items one level down in a
data structure if I am using __setitem__ and __getitem__.
At the moment I can do
for a data structure Data:
object.Data = { 'one' : [1, 2, {}, 4],
'two' : [5, 6,
al
>> > (release 2.3.3) about operator overloading is true :
>> >
>> > "For example, if a class defines a method named __getitem__(), and x
>> > is an instance of this class, then x[i] is equivalent to
>> > x.__getitem__(i)"
>> [...]
>
74 matches
Mail list logo
