Steve D'Aprano writes:
> Given a function like this:
>
>
> def func(alpha, beta, gamma, delta=4, *args, **kw):
> ...
>
>
> which is called in some fashion:
>
> # say
> func(1, 2, gamma=3, epsilon=5)
>
> which may or may not be valid:
>
> func(1, 2, alpha=0)
>
> how does Python match up the for
On Wed, 1 Mar 2017 10:18 pm, Steve D'Aprano wrote:
[...]
> how does Python match up the formal parameters in the `def` statement with
> the arguments given in the call to `func`?
>
> I'm looking for official docs, if possible. So far I've had no luck
> finding anything.
Never mind, I found it ab
Given a function like this:
def func(alpha, beta, gamma, delta=4, *args, **kw):
...
which is called in some fashion:
# say
func(1, 2, gamma=3, epsilon=5)
which may or may not be valid:
func(1, 2, alpha=0)
how does Python match up the formal parameters in the `def` statement with
the arg
On 02/10/2013 11:15, Oscar Benjamin wrote:
On 2 October 2013 00:45, Rotwang wrote:
So the upside of duck-typing is clear. But as you've already discovered, so
is the downside: Python's dynamic nature means that there's no way for the
interpreter to know what kind of arguments a function will a
On 2 October 2013 00:45, Rotwang wrote:
>
> So the upside of duck-typing is clear. But as you've already discovered, so
> is the downside: Python's dynamic nature means that there's no way for the
> interpreter to know what kind of arguments a function will accept, and so a
> user of any function
Chris Friesen writes:
> I've got a fair bit of programming experience (mostly kernel/POSIX
> stuff in C). I'm fairly new to python though, and was hoping for some
> advice.
Welcome! Thanks for taking the practice of programming seriously enough
to seek improvement.
> Is the recommendation to ha
On 10/1/2013 6:54 PM, Chris Friesen wrote:
Given the fact that function parameters do not specify types, when you're
looking at someone else's code how the heck do you know what is expected for a
given argument? (Especially in a nontrivial system where the parameter is just
pa
On 01/10/2013 23:54, Chris Friesen wrote:
I've got a fair bit of programming experience (mostly kernel/POSIX stuff in C).
I'm fairly new to python though, and was hoping for some advice.
Given the fact that function parameters do not specify types, when you're
looking at some
On Tue, Oct 1, 2013 at 6:54 PM, Chris Friesen wrote:
>
> I've got a fair bit of programming experience (mostly kernel/POSIX stuff
> in C). I'm fairly new to python though, and was hoping for some advice.
>
> Given the fact that function parameters do not specify types,
I've got a fair bit of programming experience (mostly kernel/POSIX stuff in C).
I'm fairly new to python though, and was hoping for some advice.
Given the fact that function parameters do not specify types, when you're
looking at someone else's code how the heck do you k
On 20/09/2013 16:51, bab mis wrote:
Hi ,
I have a function as below:
def func(**kwargs):
...
...
args="a='b',c='d'"
i want to call func(args) so that my function call will take a var as an
parameter.
it fails with an error "typeError: fun() takes exactly 0 arguments (1 given)
On Friday, September 20, 2013 10:51:46 AM UTC-5, bab mis wrote:
> Hi ,
>
> I have a function as below:
>
>
>
> def func(**kwargs):
>
> ...
>
> ...
>
>
>
>
>
>
>
>
>
> args="a='b',c='d'"
>
>
>
> i want to call func(args) so that my function call will take a var as an
>
Hi ,
I have a function as below:
def func(**kwargs):
...
...
args="a='b',c='d'"
i want to call func(args) so that my function call will take a var as an
parameter.
it fails with an error "typeError: fun() takes exactly 0 arguments (1 given)"
. Is there any other way to get the
On 27 December 2012 20:47, Joseph L. Casale wrote:
>> Don't use kwargs for this. List out the arguments in the function
>> spec and give the optional ones reasonable defaults.
>
>> I only use kwargs myself when the set of possible arguments is dynamic
>> or unknown.
>
> Gotch ya, but when the inp
On Thu, Dec 27, 2012 at 1:47 PM, Joseph L. Casale
wrote:
>> Don't use kwargs for this. List out the arguments in the function
>> spec and give the optional ones reasonable defaults.
>
>> I only use kwargs myself when the set of possible arguments is dynamic
>> or unknown.
>
> Gotch ya, but when t
> Don't use kwargs for this. List out the arguments in the function
> spec and give the optional ones reasonable defaults.
> I only use kwargs myself when the set of possible arguments is dynamic
> or unknown.
Gotch ya, but when the inputs to some keywords are similar, if the function is
called
On Thu, Dec 27, 2012 at 1:16 PM, Joseph L. Casale
wrote:
> When you use optional named arguments in a function, how do you deal with with
> the incorrect assignment when only some args are supplied?
>
> If I do something like:
>
> def my_func(self, **kwargs):
>
> then handle the test cases wit
When you use optional named arguments in a function, how do you deal with with
the incorrect assignment when only some args are supplied?
If I do something like:
def my_func(self, **kwargs):
then handle the test cases with:
if not kwargs.get('some_key'):
raise SyntaxError
or:
Needed to make one change... for functions with no default args:
def pdict(f):
parameter_defaults = {}
defaults = f.func_defaults
if defaults is not None:
defaultcount = len(defaults)
else:
defaultcount = 0
argcount = f.func_code.co_argcount
for i in xrang
>> I am trying to get some information about a function
>> before (and without) calling it.
> how about
def pdict(f):
parameter_defaults = {}
defaults = f.func_defaults
defaultcount = len(defaults)
argcount = f.func_code.co_argcount
for i in xrange(f.func_code.co_argco
Lee Harr wrote:
> I am trying to get some information about a function
> before (and without) calling it.
If you allow for the function arguments to be evaluated it's easy (requires
Python 2.7):
>>> import inspect
>>> def get_args(*args, **kw):
... return args, kw
...
>>> argstr = "1, 2, z=
Lee Harr, 03.08.2011 18:02:
I am trying to get some information about a function
before (and without) calling it.
Here is what I have so far. I chose to go with a
regular expression, so now I have 2 problems :o)
Can't you just use runtime introspection? Take a look at the inspect module.
Stef
I am trying to get some information about a function
before (and without) calling it.
Here is what I have so far. I chose to go with a
regular expression, so now I have 2 problems :o)
def pdict(f, pstr):
'''given a function object and a string with the function parameter
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
u:
>>> alist = [1, 2, 3, 4]
>>> blist = alist
>>> blist[0] = -999
>>> alist
[-999, 2, 3, 4]
Passing alist to a function is no different to any other name binding. It
doesn't make a copy of the list, it doesn't pass a reference to the name
"a
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
equence of a particular decision.
> 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.
>
> Henry
This has nothing to
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
n order to reduce
clutter by not having to have global declarations all over the place.
I would have thought that a function parameter would automatically be
considered local to the function.
Function *parameters* are names, the first *local names* of the function.
It doesn't make sense to m
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)
apparently been adopted in order to reduce clutter by
> not having to have global declarations all over the place.
>
> I would have thought that a function parameter would automatically be
> considered local to the function.
> Are there others who feel as I do that a function par
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
d have a question on the grammar for function
>> parameters:
>>
>> funcdef: 'def' NAME parameters ['->' test] ':' suite
>> parameters: '(' [typedargslist] ')'
>> typedargslist: ((tfpdef ['=' test] ',&#x
On Mon, Jul 12, 2010 at 3:32 PM, Junkman wrote:
> Greetings to Python users,
>
> I'm trying to parse Python code using the grammar supplied with the
> documentation set, and have a question on the grammar for function
> parameters:
>
> funcdef: 'def' N
Greetings to Python users,
I'm trying to parse Python code using the grammar supplied with the
documentation set, and have a question on the grammar for function
parameters:
funcdef: 'def' NAME parameters ['->' test] ':' suite
parameters: '(' [type
find out more about
how this is don in reStructuredText, since that seems to be what's
used to document Python at docs.python.org. There is a section in the
page that you linked to which describes how documenting function
parameters in reST works, which seems to be what I was looking for.
--
http://mail.python.org/mailman/listinfo/python-list
danielx wrote:
Is there a convention for how to document function (or method)
parameters in doc strings? Recently, I've been doing alot of PHP
programming, and in PHPdoc, you'd do it like this:
/*
* @param type $foo Description.
*
* @return type Description.
*/
function bar($foo) {
...
}
Is there a convention for how to document function (or method)
parameters in doc strings? Recently, I've been doing alot of PHP
programming, and in PHPdoc, you'd do it like this:
/*
* @param type $foo Description.
*
* @return type Description.
*/
function bar($foo) {
...
}
Is there an equiv
1 - 100 of 133 matches
Mail list logo
