On 10/07/2015 15:30, Thierry Chappuis wrote:
[snipped]
Please don't top post here as it can get irritating, especially in long
threads, thanks.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/
Anyway, if we enter this kind of discussion, it is a reliable indication that
the code smells. There is a pythonic way to express the same task:
>>> t.sort()
>>> t
kind regards
Thierry
On ven., juil. 10, 2015 at 2:28 PM, Terry Reedy < tjre...@udel.edu
[tjre...@udel.edu] > wrote:
On 7/10/2015 8
On Fri, Jul 10, 2015 at 10:04 PM, candide wrote:
> But in order to perform an operation, the interpreter has to evaluate the
> operands and "evaluating" is not "grabbing a reference to".
Actually, it is. Suppose that instead of 't', you had a function call:
def get_t(announce, returnme=[]):
Hi,
No, the value of t is a reference to tje list. So first, (1) the value of
the reference t is recovered, (2) the parenthesis is evaluated, (...) the
whole expression is evaluated.
To evaluate (2), the .sort() call is executed in place with the side effect
of sorting the content of t. t.sort()
Hi,
No, the value of t is a reference to tje list. So first, (1) the value of
the reference t is recovered, (2) the parenthesis is evaluated, (...) the
whole expression is evaluated.
To evaluate (2), the .sort() call is executed in place with the side effect
of sorting the content of t. t.sort()
On 7/10/2015 8:04 AM, candide wrote:
Le vendredi 10 juillet 2015 04:02:56 UTC+2, Chris Angelico a écrit :
I'm not sure what contradiction you're referring to, here. The
evaluation that you're pointing out says, as Terry showed via the
disassembly, that Python's first action is to look up the nam
On Friday, July 10, 2015 at 8:04:36 AM UTC-4, candide wrote:
> Le vendredi 10 juillet 2015 04:02:56 UTC+2, Chris Angelico a écrit :
>
>
>
> > I'm not sure what contradiction you're referring to, here. The
> > evaluation that you're pointing out says, as Terry showed via the
> > disassembly, tha
Le vendredi 10 juillet 2015 04:02:56 UTC+2, Chris Angelico a écrit :
> I'm not sure what contradiction you're referring to, here. The
> evaluation that you're pointing out says, as Terry showed via the
> disassembly, that Python's first action is to look up the name 't' and
> grab a reference t
On Fri, Jul 10, 2015 at 10:10 AM, candide wrote:
> The official doc explains that :
>
> Python evaluates expressions from left to right.
>
> cf. https://docs.python.org/3.3/reference/expressions.html#evaluation-order
>
>
> But consider the following snippet :
>
>
>
On 7/9/2015 8:10 PM, candide wrote:
The official doc explains that :
Python evaluates expressions from left to right.
cf. https://docs.python.org/3.3/reference/expressions.html#evaluation-order
But consider the following snippet :
t=[2020, 42, 2015]
t*(1+int(bool(t.sort(
[42, 2015
The official doc explains that :
Python evaluates expressions from left to right.
cf. https://docs.python.org/3.3/reference/expressions.html#evaluation-order
But consider the following snippet :
>>> t=[2020, 42, 2015]
>>> t*(1+int(bool(t.sort(
[42, 2015, 2020]
>&
On Fri, 26 Apr 2013 09:15:51 +0200, Peter Otten wrote:
> Define a global variable x and run it again. I don't have an ancient
> Python lying around but my "prediction" is
>
x = 42
f().x
> 42
>
> which would be the same behaviour as that of Python 3.3.
/facepalm
You're absolutely ri
Steven D'Aprano wrote:
> On Fri, 26 Apr 2013 07:39:32 +0200, Peter Otten wrote:
>
>> A class body is basically a function body that is executed once. To
>> allow an assignment
>>
> x = 42
> class A:
>> ... x = x
>> ...
>>
>> which is not possible inside a function
>
>
> As far as
On Fri, 26 Apr 2013 07:39:32 +0200, Peter Otten wrote:
> A class body is basically a function body that is executed once. To
> allow an assignment
>
x = 42
class A:
> ... x = x
> ...
>
> which is not possible inside a function
As far as I can tell, the documentation says that thi
Alastair Thompson wrote:
> I am completely baffled by the behavior of this code with regards to the
> evaluation order of namespaces when assigning the class attributes. Both
> classes are nested within a function I called whywhywhy.
>
> I assumed that example1 and example2 cla
Thats a good pointer to what is going on. Thank you Bas.
I am familiar with error such as
x=1
def foo():
x = 2
def erm():
print(x)
x=3
erm()
foo()
UnboundLocalError: local variable 'x' referenced before assignment.
It seems a bit different for classes (below), as it j
On Thursday, April 25, 2013 11:27:37 PM UTC+2, Alastair Thompson wrote:
> I am completely baffled by the behavior of this code with regards to the
> evaluation order of namespaces when assigning the class attributes. Both
> classes are nested within a function I called whywhywhy.
[s
I am completely baffled by the behavior of this code with regards to the
evaluation order of namespaces when assigning the class attributes. Both
classes are nested within a function I called whywhywhy.
I assumed that example1 and example2 classes would look first at their own
namespace, then
James Stroud wrote:
Python 2.5:
mbi136-176 211% python
*** Pasting of code with ">>>" or "..." has been enabled.
## ipython ##
##
James Stroud wrote:
> py> b = 4 if True else b
> py> b
> 4
> Isn't the right side supposed to be evaluated first?
Perhaps it becomes clearer if you change it a bit:
>>> b = 4 if True else whatever
>>> whatever
Traceback (most recent call last):
File "", line 1, in
NameError: name 'whatever'
On 2009-07-31 15:11, James Stroud wrote:
Python 2.5:
mbi136-176 211% python
*** Pasting of code with ">>>" or "..." has been enabled.
## ipython ##
py
On Fri, 2009-07-31 at 13:11 -0700, James Stroud wrote:
> Python 2.5:
>
> mbi136-176 211% python
> *** Pasting of code with ">>>" or "..." has been enabled.
>
> ## ipython
Python 2.5:
mbi136-176 211% python
*** Pasting of code with ">>>" or "..." has been enabled.
## ipython ##
###
23 matches
Mail list logo
