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