On Tue, May 31, 2011 at 6:04 PM, Daniel Kluev wrote:
> On Wed, Jun 1, 2011 at 3:16 AM, Ian Kelly wrote:
>>
>> There is no "decorator" module in the standard library. This must be
>> some third-party module. The usual way to do this would be:
>
> Yes, but its very useful for decorators and provi
On Wed, Jun 1, 2011 at 3:16 AM, Ian Kelly wrote:
>
> There is no "decorator" module in the standard library. This must be
> some third-party module. The usual way to do this would be:
Yes, but its very useful for decorators and provides some
not-readily-available functionality.
http://pypi.pyth
I was thinking you could do something strange like:
kw = {object(): None}
def test(**kw):
print kw
test(**kw)
however, upon testing it (in Python 2.6), I found that it errors while
trying to unpack the kw dict stating that they must all be strings.
Perhaps making a custom class derived off ba
Henry Olders wrote:
Clearly, making a copy within the function eliminates the possibility of
the side effects caused by passing in mutable objects. Would having the
compiler/interpreter do this automatically make python so much
different?
It would be a different language.
~Ethan~
--
http://m
Henry Olders wrote:
[...] what I want is a function that is free of side effects [...]
Shoot, that's easy! Just write your function to not have any!
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
On May 31, 9:46 pm, rusi wrote:
> So you then use (something like)
>
> fnc2(c): return c[0:1] + c[2:]
Er sorry -- that should have been
def fnc2(c): return c[0:1] + ('having',) + c[2:]
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, May 31, 2011 at 10:34 AM, Chris Kaynor wrote:
> Is there any reason not to simplify this to:
> def copy_args(f):
> @functools.wraps(f)
> def wrapper(*args, **kw):
> nargs = copy.deepcopy(args)
> nkw = copy.deepcopy(kw)
> return f(*nargs, **nkw)
> return wrappe
On May 29, 1:30 pm, Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
>
On Tue, May 31, 2011 at 9:16 AM, Ian Kelly wrote:
> On Tue, May 31, 2011 at 1:38 AM, Daniel Kluev wrote:
> > @decorator.decorator
> > def copy_args(f, *args, **kw):
> >nargs = []
> >for arg in args:
> >nargs.append(copy.deepcopy(arg))
> >nkw = {}
> >for k,v in kw.iteritem
On Tue, May 31, 2011 at 1:38 AM, Daniel Kluev wrote:
> @decorator.decorator
> def copy_args(f, *args, **kw):
> nargs = []
> for arg in args:
> nargs.append(copy.deepcopy(arg))
> nkw = {}
> for k,v in kw.iteritems():
> nkw[k] = copy.deepcopy(v)
> return f(*nargs, **nkw)
On 5/31/2011 3:17 AM, Henry Olders wrote:
Clearly, making a copy within the function eliminates the possibility of
the side effects caused by passing in mutable objects.
Mutable objects and mutating methods and functions are a *feature* of
Python. If you do not like them, do not use them.
>
On 5/31/2011 2:37 AM, Henry Olders wrote:
what I want is a function that is free of side effects back through
the parameters passed in the function call.
You can get that by refraining from mutating parameter objects.
Simple as that.
Just do not expect Python to enforce that discipline on ever
On Dienstag 31 Mai 2011, Henry Olders wrote:
> You're partially right - what I want is a function that is
> free of side effects back through the parameters passed in
> the function call.
I don't know any object oriented language where it is not
possible to change objects passed in as parameters.
On Tue, May 31, 2011 at 5:17 PM, Henry Olders wrote:
> Clearly, making a copy within the function eliminates the possibility of the
> side effects caused by passing in mutable objects. Would having the
> compiler/interpreter do this automatically make python so much different?
Yes, it would make
On Tue, May 31, 2011 at 6:17 PM, Henry Olders wrote:
> Clearly, making a copy within the function eliminates the possibility of the
> side effects caused by passing in mutable objects. Would having the
> compiler/interpreter do this automatically make python so much different?
As I've pointed, yo
On 2011-05-31, at 24:35 , Dan Stromberg wrote:
>
> On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote:
>
> Be careful not to conflate global scoping or global lifetime, with mutability
> or pure, side-effect-free functions (callables). It sounds like what you
> want is immutability and/or
On 2011-05-30, at 20:52 , Benjamin Kaplan wrote:
> On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote:
>>
>> On 2011-05-29, at 4:30 , Henry Olders wrote:
>>
>
> Python doesn't have true globals. When we say "global" what we mean is
> "module or built-in". Also, consider this code
>
> from ma
On Mon, May 30, 2011 at 11:37 PM, Henry Olders wrote:
> On 2011-05-31, at 1:13 , Wolfgang Rohdewald wrote:
>>
>> what you really seem to want is that a function by default
>> cannot have any side effects (you have a side effect if a
>> function changes things outside of its local scope). But
>> th
On 2011-05-31, at 1:13 , Wolfgang Rohdewald wrote:
>
> what you really seem to want is that a function by default
> cannot have any side effects (you have a side effect if a
> function changes things outside of its local scope). But
> that would be a very different language than python
You're pa
On Tue, May 31, 2011 at 4:13 PM, Wolfgang Rohdewald
wrote:
> what you really seem to want is that a function by default
> cannot have any side effects (you have a side effect if a
> function changes things outside of its local scope). But
> that would be a very different language than python
This
Daniel Kluev writes:
> On a sidenote, I wonder what is the reason to keep word 'variable' in
> python documentation at all. I believe word 'name' represents concept
> better, and those, who come from other languages, would be less likely
> to associate wrong definitions with it.
I agree, but the
Am 31.05.2011 02:28 schrieb Henry Olders:
This suggests that the decision to make unassigned (ie "free"
variables) have a global scope, was made somewhat arbitrarily to
prevent clutter. But I don't believe that the feared clutter would
materialize. My understanding is that when a variable is ref
On Dienstag 31 Mai 2011, Henry Olders wrote:
> What I would like is that the variables which are included in
> the function definition's parameter list, would be always
> treated as local to that function (and of course, accessible
> to nested functions) but NOT global unless explicitly defined
> a
On Mon, 30 May 2011 20:28:34 -0400, Henry Olders wrote:
> I am trying to write python programs in a more-or-less functional
> programming mode, ie functions without side effects (except for print
> statements, which are very helpful for debugging). This is easiest when
> all variables declared in
On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote:
> What I would like is that the variables which are included in the function
> definition's parameter list, would be always treated as local to that
> function (and of course, accessible to nested functions) but NOT global
> unless explicitly de
On Tue, May 31, 2011 at 1:18 PM, Daniel Kluev wrote:
> On Tue, May 31, 2011 at 2:05 PM, Chris Angelico wrote:
>> Infinitely-nested scoping is simply one of the casualties of a
>> non-declarative language.
>
> Well, this is not accurate, as you can have 'infinitely-nested
> scoping' in python, in
On Tue, May 31, 2011 at 2:05 PM, Chris Angelico wrote:
> Infinitely-nested scoping is simply one of the casualties of a
> non-declarative language.
Well, this is not accurate, as you can have 'infinitely-nested
scoping' in python, in form of nested functions. For example, you can
use map(lambda x
On Tue, May 31, 2011 at 10:28 AM, Henry Olders wrote:
> I don't believe I'm the only person who thinks this way. Here is a quote from
> wikipedia: "It is considered good programming practice to make the scope of
> variables as narrow as feasible so that different parts of a program do not
> acc
On Tue, May 31, 2011 at 12:30 PM, Terry Reedy wrote:
> Again, go back and reread what I and other wrote. I believe that you are, in
> part, hypnotized by the work 'variable'. Can you define the word? There are
> 10 to 20 possible variations, and yours is probably wrong for Python.
On a sidenote,
On 5/30/2011 8:28 PM, Henry Olders wrote:
Sadly, I feel that the main issue that I was trying to address, has
not been dealt with.
False. Please go back and read what I and others wrote before.
...
What I would like is that the variables which are included in the
function definition's param
On Tue, May 31, 2011 at 11:28 AM, Henry Olders wrote:
> What I would like is that the variables which are included in the function
> definition's parameter list, would be always treated as local to that function
You still mis-reading docs and explanations you received from the list.
Let me try a
On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote:
>
> On 2011-05-29, at 4:30 , Henry Olders wrote:
>
>> I just spent a considerable amount of time and effort debugging a program.
>> The made-up code snippet below illustrates the problem I encountered:
>>
>> def main():
>> a = ['a list','
On 2011-05-29, at 4:30 , Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
On 5/30/2011 5:08 AM, Laurent Claessens wrote:
Le 30/05/2011 11:02, Terry Reedy a écrit :
On 5/30/2011 3:38 AM, Laurent wrote:
Cool. I was thinking that "5" was the name, but
>>> 5.__add__(6)
File "", line 1
5.__add__(6)
Try 5 .__add__(6)
What is the rationale behind the fact to add a spa
Laurent Claessens writes:
> Le 30/05/2011 11:02, Terry Reedy a écrit :
> > On 5/30/2011 3:38 AM, Laurent wrote:
> >
> >> Cool. I was thinking that "5" was the name, but
> >> >>> 5.__add__(6)
> >> File "", line 1
> >> 5.__add__(6)
> >
> >
> > Try 5 .__add__(6)
>
> What is the rationale behind
What is the rationale behind the fact to add a space between "5" and
".__add__" ?
Why does it work ?
It's a hint for the tokenizer.
I didn't know the tokenizer. Now I understand.
Thanks
Laurent
--
http://mail.python.org/mailman/listinfo/python-list
What is the rationale behind the fact to add a space between "5" and
".__add__" ?
Why does it work ?
It's a hint for the tokenizer.
I didn't know the tokenizer. Now I understand.
Thanks
Laurent
--
http://mail.python.org/mailman/listinfo/python-list
Laurent Claessens wrote:
> Le 30/05/2011 11:02, Terry Reedy a écrit :
>> On 5/30/2011 3:38 AM, Laurent wrote:
>>
>>> Cool. I was thinking that "5" was the name, but
>>> >>> 5.__add__(6)
>>> File "", line 1
>>> 5.__add__(6)
>>
>>
>> Try 5 .__add__(6)
>
> What is the rationale behind the fact
Laurent Claessens writes:
> Le 30/05/2011 11:02, Terry Reedy a écrit :
> > Try 5 .__add__(6)
>
> What is the rationale behind the fact to add a space between "5" and
> ".__add__" ?
> Why does it work ?
Try asking it the other way around. Why doesn't ‘5.__add__(6)’, without
the space, work?
--
On Mon, 30 May 2011 09:12:50 +0200, Laurent Claessens wrote:
> Could you give an example of an object that has no name ? I've missed
> something ...
>>> mylist = [None, 42, "something"]
The list object has a name, mylist.
The three objects inside the list have no names.
--
Steven
--
http:
On Mon, 30 May 2011 11:08:23 +0200, Laurent Claessens wrote:
> Le 30/05/2011 11:02, Terry Reedy a écrit :
>> On 5/30/2011 3:38 AM, Laurent wrote:
>>
>>> Cool. I was thinking that "5" was the name, but
>>> >>> 5.__add__(6)
>>> File "", line 1
>>> 5.__add__(6)
>>
>>
>> Try 5 .__add__(6)
>
> W
Le 30/05/2011 11:02, Terry Reedy a écrit :
On 5/30/2011 3:38 AM, Laurent wrote:
Cool. I was thinking that "5" was the name, but
>>> 5.__add__(6)
File "", line 1
5.__add__(6)
Try 5 .__add__(6)
What is the rationale behind the fact to add a space between "5" and
".__add__" ?
Why does
On 5/30/2011 3:38 AM, Laurent wrote:
Cool. I was thinking that "5" was the name, but
>>> 5.__add__(6)
File "", line 1
5.__add__(6)
Try 5 .__add__(6)
Modules, classes, and functions have a .__name__ attribute (I call it
their 'definition name') used to print a representation. As best I can
On Mon, May 30, 2011 at 6:12 PM, Laurent Claessens wrote:
> Could you give an example of an object that has no name ? I've missed
> something ...
>>> object()
--
With best regards,
Daniel Kluev
--
http://mail.python.org/mailman/listinfo/python-list
Could you give an example of an object that has no name ? I've missed
something ...
def foo():
return 5
print(foo())
The int object 5 has no name here.
Cool. I was thinking that "5" was the name, but
>>> 5.__add__(6)
File "", line 1
5.__add__(6)
^
SyntaxError: inva
On Mon, May 30, 2011 at 12:12 AM, Laurent Claessens wrote:
> Le 29/05/2011 23:42, Ben Finney a écrit :
>> Peter Pearson writes:
>>
>>> Python works in terms of objects having names, and one
>>> object can have many names.
>>
>> Or no names. So it's less accurate (though better than talking of
>
Le 29/05/2011 23:42, Ben Finney a écrit :
Peter Pearson writes:
Python works in terms of objects having names, and one
object can have many names.
Or no names. So it's less accurate (though better than talking of
“variables”) to speak of Python objects “having names”.
Could you give an e
On Mon, 30 May 2011 11:31:33 +1000, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> http://mail.python.org/pipermail/tutor/2010-December/080505.html
>>
>>
>> Constructive criticism welcome.
>
> Informative, but it “buries the lead” as our friends in the press corps
> would say.
Thank you, tha
On Mon, May 30, 2011 at 12:08 PM, Ben Finney wrote:
> Chris Angelico writes:
>
>> Of course, there's a significant difference between a mailing list
>> post and a detailed and well copyedited article. Quite frequently I'll
>> ramble on list, in a way quite inappropriate to a publication that
>> w
Chris Angelico writes:
> Of course, there's a significant difference between a mailing list
> post and a detailed and well copyedited article. Quite frequently I'll
> ramble on list, in a way quite inappropriate to a publication that
> would be linked to as a "hey guys, here's how it is" page. Di
On Mon, May 30, 2011 at 11:31 AM, Ben Finney wrote:
> http://www.computerworld.com/s/article/print/93903/I_m_OK_The_Bull_Is_Dead>
I agree with the gist of that. My take on this is: When I'm talking to
my boss, I always assume that the phone will ring ten seconds into my
explanation. Ten seconds
Steven D'Aprano writes:
> http://mail.python.org/pipermail/tutor/2010-December/080505.html
>
>
> Constructive criticism welcome.
Informative, but it “buries the lead” as our friends in the press corps
would say.
Instead you should write as though you have no idea where the reader
will stop rea
On Sun, 29 May 2011 04:30:52 -0400, Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a
> program. The made-up code snippet below illustrates the problem I
> encountered:
[...]
> Are there others who feel as I do that a function parameter should
> always be loca
On 5/29/2011 4:19 PM, Henry Olders wrote:
From my perspective, a function parameter should be considered as
having been assigned (although the exact assignment will not be known
until runtime), and as an assigned variable, it should be considered
local.
That is exactly the case for Python func
On Sun, 29 May 2011 16:19:11 -0400
Henry Olders wrote:
> > def fnc2(c):
> > c = c[:]
> >c[1] = 'having'
> >return c
>
> Thank you, Wolfgang. That certainly works, but to me it is still a
> workaround to deal with the consequence of a particular decision.
> From my per
Peter Pearson writes:
> Python works in terms of objects having names, and one
> object can have many names.
Or no names. So it's less accurate (though better than talking of
“variables”) to speak of Python objects “having names”.
> The names b and c aren't boxes that hold things, they are -- i
On 5/29/2011 7:59 AM, Mel wrote:
Henry Olders wrote:
I just spent a considerable amount of time and effort debugging a program.
The made-up code snippet below illustrates the problem I encountered:
def main():
a = ['a list','with','three elements']
print a
print fnc1(a)
print a
def fnc1(b):
r
Henry
On 2011-05-29, at 5:47 , Wolfgang Rohdewald wrote:
> On Sonntag 29 Mai 2011, Henry Olders wrote:
>> It seems that in Python, a variable inside a function is
>> global unless it's assigned.
>
> no, they are local
>
>> I would have thought that a function parameter would
>> automaticall
On Mon, May 30, 2011 at 4:53 AM, Steven D'Aprano
wrote:
> UnboundLocalError is a subclass of NameError, so it will still be caught
> by try...except NameError.
>
> If you're crazy enough to be catching NameError :)
Ah okay. So it is still NameError, it just doesn't look like one.
> While Unbound
On Sun, May 29, 2011 at 12:38 PM, Chris Angelico wrote:
> I thought it basically functioned top-down. You get a different error
> on the print line if there's a "bar = 42" *after* it. This could make
> debugging quite confusing.
>
> Guess it's just one of the consequences of eschewing variable
> d
On Mon, 30 May 2011 04:38:26 +1000, Chris Angelico wrote:
> On Mon, May 30, 2011 at 4:01 AM, Chris Rebert wrote:
>> def foo():
>> print bar
>> bar = 42
>>
>> foo()
>>
>> ===>
>> Traceback (most recent call last):
>> File "", line 1, in
>> File "", line 2, in foo
>> UnboundLocalError: loc
On Mon, May 30, 2011 at 4:01 AM, Chris Rebert wrote:
> def foo():
> print bar
> bar = 42
>
> foo()
>
> ===>
> Traceback (most recent call last):
> File "", line 1, in
> File "", line 2, in foo
> UnboundLocalError: local variable 'bar' referenced before assignment
Wow
I thought it basica
On Mon, 30 May 2011 03:53:24 +1000, Chris Angelico wrote:
> On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
> wrote:
>> If a name is assigned to anywhere in the function, treat it as a local,
>> and look it up in the local namespace. If not found, raise
>> UnboundLocalError.
>>
>>
> Wait wha? I
On Sun, May 29, 2011 at 10:53 AM, Chris Angelico wrote:
> On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
> wrote:
>> If a name is assigned to anywhere in the function, treat it as a local,
>> and look it up in the local namespace. If not found, raise
>> UnboundLocalError.
>>
>
> Wait wha? I've
On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
wrote:
> If a name is assigned to anywhere in the function, treat it as a local,
> and look it up in the local namespace. If not found, raise
> UnboundLocalError.
>
Wait wha? I've never seen this... wouldn't it just create it in the
local namespac
On Sun, 29 May 2011 04:30:52 -0400, Henry Olders wrote:
[snip]
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
> print a
>
> def fnc1(b):
> return fnc2(b)
>
> def fnc2(c):
> c[1] = 'having'
> return c
>
> This is the
On Sun, 29 May 2011 11:47:26 +0200, Wolfgang Rohdewald wrote:
> On Sonntag 29 Mai 2011, Henry Olders wrote:
>> It seems that in Python, a variable inside a function is global unless
>> it's assigned.
>
> no, they are local
I'm afraid you are incorrect. Names inside a function are global unless
Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
> print a
>
> def fnc1(b):
> return fnc2(b)
On Sun, May 29, 2011 at 1:30 AM, Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
> a = ['a list','with','three elements']
> print a
> print
On Sonntag 29 Mai 2011, Henry Olders wrote:
> It seems that in Python, a variable inside a function is
> global unless it's assigned.
no, they are local
> I would have thought that a function parameter would
> automatically be considered local to the function. It doesn't
> make sense to me to pas
I just spent a considerable amount of time and effort debugging a program. The
made-up code snippet below illustrates the problem I encountered:
def main():
a = ['a list','with','three elements']
print a
print fnc1(a)
print a
def fnc1(b):
return fn
71 matches
Mail list logo
