| > > 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 so it works my way but operator overl
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
[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)
>
a = myint(3)
a ** 3
> 6
>
> OK, it works.
<[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 works.
>
> > Here is my try:>>> class myint(int):
>
> > def __pow_
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):
> return self.__add__(value)
>
> >>> a =
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)
>
> >>> a = myint(3)
> >>> a ** 3
>
> 6
>
> OK, it
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
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
> def __add__ (self,operand2):
>
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 '**'
On 25 Nov 2004 06:35:23 -0800, [EMAIL PROTECTED] (Sebastien Boisgerault) wrote:
>Peter Maas <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
>> Sebastien Boisgerault schrieb:
>> > I wonder if the following quotation from the Python Reference Manual
>> > (release 2.3.3) about opera
58 matches
Mail list logo
