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
34 matches
Mail list logo
