Re: operator overloading + - / * = etc...
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 variables when discussing FL local variables and instance variables, and is (usually) careful to talk FL about names when talking about binding behaviour. Mostly yes, but not exclusively. E.g. If a name is bound in a block, it is a local variable of that block. If a name is bound at the module level, it is a global variable. (The variables of the module code block are local and global.) If a variable is used in a code block but not defined there, it is a free variable. There are also other uses of variable for things at the module level. And the word `variable(s)' occurs 80 times in the language reference manual. FL for example, the description of the assignment statement: FL http://www.python.org/doc/2.4.3/ref/assignment.html FL only uses variable twice, in a note that discussing a given code FL example. the more formal parts of that page consistently use the term FL name. FL it's often a good idea to be a bit careful when discussing detailed FL behaviour, especially in contexts where the audience may associate FL variables with small areas of memory. It is interesting that the word 'variable' is nowhere defined in the manual. What one imagines with the word `variable' depends on one's programming background, I guess, and that could certainly give a wrong impression. -- Piet van Oostrum [EMAIL PROTECTED] URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 Python object (ie, dict) is completely
optional and implementation dependent. For CPython, the local namespace
of
a function is generally *not* done that way.
I know this, and that's not the point here. The op's question seemed to
imply that the hypothetical __assign__ method should belong to the rhs
object, which is obviously not the case - it must of course belongs to
the lhs 'object'.
And my point is that in general there is no lhs object for the method to
belong to.
nitpicking
Mmm... Of course, there's always something that's being used as a
namespace. But yes, this something may not be directly accessible as a
Python object.
/nitpicking.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 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 variable--to intercept attempts to set a
variable.
(snip)
Suppose we bind the name x to the object 1, and then rebind the
name x
to the object []. Which object's hypothetical __assign__ method
should get
called?
The current namespace object, of course.
Which is?
Depends on the context... Can be actually the module (global) namespace,
a function local namespace or a class namespace.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 of
a function is generally *not* done that way.
I know this, and that's not the point here. The op's question seemed to
imply that the hypothetical __assign__ method should belong to the rhs
object, which is obviously not the case - it must of course belongs to
the lhs 'object'.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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) is completely optional and implementation dependent. For CPython, the local namespace of a function is generally *not* done that way. I know this, and that's not the point here. The op's question seemed to imply that the hypothetical __assign__ method should belong to the rhs object, which is obviously not the case - it must of course belongs to the lhs 'object'. And my point is that in general there is no lhs object for the method to belong to. -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 to see more control over the name-binding operation, and exposing the namespace as an object sounds like an interesting way to do this. -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 inappropiate to use. And since the word variable originally comes from mathematics and IMHO the mathematical semantics are closer to the lisp/smalltalk/python semantics than the C/algol/pascal/ada semantics I don't see why variable is seen as sloppy talk Um, that's what I usually use anyway... :) -- Theerasak -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
# [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: not that there's little complaining about assignment not being an expression, it's useless to complain because all previous complaints have been shot down on the basis of claims of reduced safety and readability. People who complain often fail to see how x = foo() while x: process(x) x = foo() is safer than while x = foo(): process(x) (duplication hampers code safety) or how some other features present in the language, e. g. comprehensions, could make it past the readability check. Everybody has an opinion; those who put the most work in the project get to decide what the software looks like. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 be turned into a well-behaved Python citizen: while 1: x = foo() if not x: break process(x) (this is the standard loop-and-a-half pydiom, and every python pro- grammer should be able to identify it as such in a fraction of a second). or for the perhaps-overly-clever hackers, for x in iter(lambda: foo() or None, None): process(x) it's not like the lack of assignment-as-expression is forcing anyone to duplicate code in today's Python. also, in my experience, most assignment-as-expression mistakes are done in if-statements, not while-statements (if not else because if statements are a lot more common in most code). the but it cuts down on duplication argument doesn't really apply to if-statements. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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
Re: operator overloading + - / * = etc...
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/listinfo/python-list
Re: operator overloading + - / * = etc...
On 2006-10-10, Paul Rubin http 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() for _ in repeat(None)): ... print x ... Traceback (most recent call last): File stdin, line 1, in ? TypeError: takewhile expected 2 arguments, got 1 -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
Antoon Pardon [EMAIL PROTECTED] writes: for x in takewhile(foo() for _ in repeat(None)): ... print x ... Traceback (most recent call last): File stdin, line 1, in ? TypeError: takewhile expected 2 arguments, got 1 Yeah, I cancelled and posted a followup for x in takewhile(bool, foo() for _ in repeat(None)): print x but I haven't tested either way. -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
On 2006-10-10, Paul Rubin http 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 are ugly. Sure, but so is IMO the current pythonic idiom. Suppose one has the following intention in mind: while x = setup(): if y = pre_process() in ErrorCondition: break post_process(y) else: NormalTermination() The pythonic idiom for this case would then be something like: while 1: x = setup() if x: NormalTermination() break y = pre_process(x) if y in ErrorCondition: break post_process(y) There was some time it seemed PEP: 315 would be implemented so that this could have been written as: do: x = setup() while x: y = pre_process(x) if y in ErrorCondition: break post_process(y) else: NormalTermination() Which IMO would have been clearer. Alas PEP 315 is deffered so it will be probably a long time before this will be implemented. -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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, *args, **kw): while True: yield func(*args, **kw) then you'd write: for x in takewhile(bool, forever(setup)): if y = pre_process() in ErrorCondition: break post_process(y) else: NormalTermination() It might be preferable to write pre_process to raise an exception if there's an error condition. Then the whole thing becomes: try: for x in takewhile(bool, forever(setup)): post_process(pre_process()) NormalTermination() except PreprocessError: pass -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 this_is_an_integer and this_is_a_string. (The *objects* they point to are SD a different story, naturally.) The official Python documentation (language reference manual) talks a lot about variables. So it seems silly to say that Python doesn't have variables. -- Piet van Oostrum [EMAIL PROTECTED] URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 vary (you can't change the value of a variable once you have set it). -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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, and is (usually) careful to talk about names when talking about binding behaviour. for example, the description of the assignment statement: http://www.python.org/doc/2.4.3/ref/assignment.html only uses variable twice, in a note that discussing a given code example. the more formal parts of that page consistently use the term name. it's often a good idea to be a bit careful when discussing detailed behaviour, especially in contexts where the audience may associate variables with small areas of memory. (it's also important to realize that the language reference is a hodge- podge of incremental revisions with no grand plan behind it; it was a bit more consistent when Guido wrote the first version.) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 Python. if they are plain identifiers, they're called names. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 call the function with different arguments (which happens frequently in Haskell, which uses recursion in place of loops). -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 would you want to do that? For the same reason one would use property() to create getter/setter functions for a particular variable--to intercept attempts to set a variable. Despite sloppy talk to the contrary (which I think most of us do from time to time), Python doesn't have variables. It has names and objects. Names are just labels -- there is no difference in behavior between the *names* this_is_an_integer and this_is_a_string. (The *objects* they point to are a different story, naturally.) 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 inappropiate to use. And since the word variable originally comes from mathematics and IMHO the mathematical semantics are closer to the lisp/smalltalk/python semantics than the C/algol/pascal/ada semantics I don't see why variable is seen as sloppy talk -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 same reason one would use property() to create
getter/setter functions for a particular variable--to intercept
attempts to set a variable.
(snip)
Suppose we bind the name x to the object 1, and then rebind the name x
to the object []. Which object's hypothetical __assign__ method should get
called?
The current namespace object, of course.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 you want to do that? For the same reason one would use property() to create getter/setter functions for a particular variable--to intercept attempts to set a variable. (snip) Suppose we bind the name x to the object 1, and then rebind the name x to the object []. Which object's hypothetical __assign__ method should get called? The current namespace object, of course. Which is? Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 generally *not* done that way. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 AFAIK, this only applies to properties of objects, not top-level names/variables. I'd love to know if there's some workaround for this though... 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. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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
operator overloading + - / * = etc...
Can these operators be overloaded? If so. How? -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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/python-list
Re: operator overloading + - / * = etc...
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
Re: operator overloading + - / * = etc...
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 properties of objects, not top-level names/variables. I'd love to know if there's some workaround for this though... -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 AFAIK, this only applies to properties of objects, not top-level names/variables. I'd love to know if there's some workaround for this though... In almost all cases, binding a name cannot be overridden. There is a possibility to do that with globals, provided you do exec code in globals_dict where globals_dict is an instance of a subclass of dict that has a customized __setitem__. Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 variable--to intercept attempts to set a variable. I'm not sure there's an elegant way to do it other than creating a custom container object with a getter/setter using property(). My purpose was just to note that the = assignment operator is distinct from the remainder of the operators that you correctly identified can be overridden with their associated __[operator]__ method. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: operator overloading + - / * = etc...
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 property() to create getter/setter functions for a particular variable--to intercept attempts to set a variable. Despite sloppy talk to the contrary (which I think most of us do from time to time), Python doesn't have variables. It has names and objects. Names are just labels -- there is no difference in behavior between the *names* this_is_an_integer and this_is_a_string. (The *objects* they point to are a different story, naturally.) Objects do not, and can not, know what names they are bound to, nor can they tell when the name or names they are bound to changes. Objects just don't care what names they are bound to -- in fact, many objects aren't bound to any name at all. Suppose we bind the name x to the object 1, and then rebind the name x to the object []. Which object's hypothetical __assign__ method should get called? Object 1 or object []? Both of them? In what order? Why should the empty list care what names it is bound to? I'm not sure there's an elegant way to do it other than creating a custom container object with a getter/setter using property(). You shouldn't be programming C++ in Python, you should rethink how you are solving the problem. But having done that, if you still find that the property() idiom makes sense for names/objects, you can get close if you are willing to write x = 1 as NAMESPACE.x = 1, and then use a custom class or module to implement the behavior you want. Here is one module that you might be able to use: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65207 -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
