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
On Mon, May 30, 2011 at 11:37 PM, Henry Olders henry.old...@mcgill.ca 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
On 2011-05-30, at 20:52 , Benjamin Kaplan wrote:
On Mon, May 30, 2011 at 5:28 PM, Henry Olders henry.old...@mcgill.ca 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
On 2011-05-31, at 24:35 , Dan Stromberg wrote:
On Mon, May 30, 2011 at 5:28 PM, Henry Olders henry.old...@mcgill.ca 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
On Tue, May 31, 2011 at 6:17 PM, Henry Olders henry.old...@mcgill.ca 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?
On Tue, May 31, 2011 at 5:17 PM, Henry Olders henry.old...@mcgill.ca 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?
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. It
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
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 Tue, May 31, 2011 at 1:38 AM, Daniel Kluev dan.kl...@gmail.com 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
On Tue, May 31, 2011 at 9:16 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Tue, May 31, 2011 at 1:38 AM, Daniel Kluev dan.kl...@gmail.com wrote:
@decorator.decorator
def copy_args(f, *args, **kw):
nargs = []
for arg in args:
nargs.append(copy.deepcopy(arg))
nkw = {}
On Tue, May 31, 2011 at 10:34 AM, Chris Kaynor ckay...@zindagigames.com 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)
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
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~
--
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
On Wed, Jun 1, 2011 at 3:16 AM, Ian Kelly ian.g.ke...@gmail.com 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.
On Tue, May 31, 2011 at 6:04 PM, Daniel Kluev dan.kl...@gmail.com wrote:
On Wed, Jun 1, 2011 at 3:16 AM, Ian Kelly ian.g.ke...@gmail.com 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
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 Mon, May 30, 2011 at 5:28 PM, Henry Olders henry.old...@mcgill.ca 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 =
On Tue, May 31, 2011 at 11:28 AM, Henry Olders henry.old...@mcgill.ca 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
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
On Tue, May 31, 2011 at 12:30 PM, Terry Reedy tjre...@udel.edu 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 Tue, May 31, 2011 at 10:28 AM, Henry Olders henry.old...@mcgill.ca 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
On Tue, May 31, 2011 at 2:05 PM, Chris Angelico ros...@gmail.com 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
On Tue, May 31, 2011 at 1:18 PM, Daniel Kluev dan.kl...@gmail.com wrote:
On Tue, May 31, 2011 at 2:05 PM, Chris Angelico ros...@gmail.com wrote:
Infinitely-nested scoping is simply one of the casualties of a
non-declarative language.
Well, this is not accurate, as you can have
On Mon, May 30, 2011 at 5:28 PM, Henry Olders henry.old...@mcgill.cawrote:
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
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 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
as
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
Daniel Kluev dan.kl...@gmail.com 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.
On Tue, May 31, 2011 at 4:13 PM, Wolfgang Rohdewald
wolfg...@rohdewald.de 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
31 matches
Mail list logo
