Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #48742 > unrolled thread
| Started by | Ahmed Abdulshafy <abdulshafy@gmail.com> |
|---|---|
| First post | 2013-06-19 12:17 -0700 |
| Last post | 2013-06-20 01:17 +0000 |
| Articles | 6 on this page of 86 — 21 participants |
Back to article view | Back to comp.lang.python
Default Value Ahmed Abdulshafy <abdulshafy@gmail.com> - 2013-06-19 12:17 -0700
Re: Default Value Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-19 22:35 +0300
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-19 12:38 -0700
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-20 05:57 -0700
Re: Default Value Roy Smith <roy@panix.com> - 2013-06-20 09:19 -0400
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-20 06:31 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-21 00:17 +0000
Re: Default Value Roy Smith <roy@panix.com> - 2013-06-20 20:25 -0400
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-20 07:49 -0700
Re: Default Value Chris Angelico <rosuav@gmail.com> - 2013-06-21 01:38 +1000
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-20 11:05 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-21 00:57 +0000
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-20 20:16 -0700
Re: Default Value Chris Angelico <rosuav@gmail.com> - 2013-06-21 17:10 +1000
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 07:32 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-21 16:22 +0000
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-21 15:57 +0000
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 10:01 -0700
Re: Default Value Rotwang <sg552@hotmail.co.uk> - 2013-06-21 18:47 +0100
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 11:26 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-21 18:37 +0000
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 12:18 -0700
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 12:35 -0700
Re: Default Value Chris Angelico <rosuav@gmail.com> - 2013-06-22 05:07 +1000
Re: Default Value Neil Cerutti <neilc@norwich.edu> - 2013-06-21 19:20 +0000
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 13:27 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-22 01:31 +0000
Re: Default Value Chris Angelico <rosuav@gmail.com> - 2013-06-22 11:40 +1000
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 18:42 -0700
Re: Default Value MRAB <python@mrabarnett.plus.com> - 2013-06-22 03:04 +0100
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 19:32 -0700
Re: Default Value MRAB <python@mrabarnett.plus.com> - 2013-06-22 20:36 +0100
Re: Default Value Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-22 18:51 -0400
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-21 19:43 -0700
Re: Default Value Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-22 09:26 +0100
Re: Default Value MRAB <python@mrabarnett.plus.com> - 2013-06-21 20:25 +0100
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 13:44 -0700
Re: Default Value MRAB <python@mrabarnett.plus.com> - 2013-06-21 23:49 +0100
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 16:51 -0700
Re: Default Value MRAB <python@mrabarnett.plus.com> - 2013-06-22 02:54 +0100
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-22 01:15 +0000
Re: Default Value Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-21 19:27 -0600
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-21 19:32 -0700
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 19:55 -0700
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-21 23:23 -0700
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-22 08:07 -0700
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-22 08:31 -0700
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-22 09:11 -0700
Re: Default Value Grant Edwards <invalid@invalid.invalid> - 2013-06-24 14:22 +0000
Re: [SPAM] Re: Default Value MRAB <python@mrabarnett.plus.com> - 2013-06-24 16:22 +0100
Re: Default Value Chris Angelico <rosuav@gmail.com> - 2013-06-22 11:41 +1000
Re: Default Value Michael Torrie <torriem@gmail.com> - 2013-06-21 20:46 -0600
Re: Default Value Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-06-22 16:40 +0200
Re: Default Value Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-22 12:49 -0400
Re: Default Value Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-22 12:57 -0600
Re: Default Value Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-22 18:48 -0400
Re: Default Value Rotwang <sg552@hotmail.co.uk> - 2013-06-22 00:40 +0100
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 18:15 -0700
Re: Default Value Chris Angelico <rosuav@gmail.com> - 2013-06-22 11:37 +1000
Re: Default Value Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-21 19:42 -0600
Re: Default Value Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-21 19:38 -0600
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 19:40 -0700
Re: Default Value Rotwang <sg552@hotmail.co.uk> - 2013-06-22 03:01 +0100
Re: Default Value Chris Angelico <rosuav@gmail.com> - 2013-06-22 12:18 +1000
Re: Default Value Rotwang <sg552@hotmail.co.uk> - 2013-06-22 03:25 +0100
Re: Default Value Rotwang <sg552@hotmail.co.uk> - 2013-06-22 18:19 +0100
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-22 11:49 -0700
Re: Default Value Rotwang <sg552@hotmail.co.uk> - 2013-06-23 01:49 +0100
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-20 10:12 -0700
Re: Default Value Chris Angelico <rosuav@gmail.com> - 2013-06-21 03:19 +1000
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-20 10:30 -0700
Re: Default Value Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-20 11:57 -0600
Re: Default Value rusi <rustompmody@gmail.com> - 2013-06-20 11:15 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-21 01:08 +0000
Re: Default Value Tim Chase <python.list@tim.thechases.com> - 2013-06-20 20:26 -0500
Re: Default Value Roy Smith <roy@panix.com> - 2013-06-20 21:40 -0400
Re: Default Value Tim Chase <python.list@tim.thechases.com> - 2013-06-20 21:02 -0500
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-20 11:07 -0700
Re: Default Value alex23 <wuwei23@gmail.com> - 2013-06-21 10:55 +1000
Re: Default Value 88888 Dihedral <dihedral88888@gmail.com> - 2013-06-20 19:18 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-21 02:26 +0000
Re: Default Value "Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC]" <matthew.lefavor@nasa.gov> - 2013-06-20 17:28 -0500
Re: Default Value Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-21 08:17 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-21 01:28 +0000
Re: Default Value Gary Herron <gherron@digipen.edu> - 2013-06-19 12:57 -0700
Re: Default Value Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-20 01:17 +0000
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-21 02:26 +0000 |
| Message-ID | <51c3b9e3$0$29999$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48809 |
On Thu, 20 Jun 2013 10:12:01 -0700, rusi wrote: > Python (and all the other 'cool' languages) dont have gotchas because > someone malevolently put them there. > In most cases, the problem is seen too late and the cost of changing > entrenched code too great. > Or the problem is clear, the solution is not etc etc. And sometimes the gotcha is unavoidably in the nature of the problem. This is remarkably common in real life, so much so that in English there is even a proverb for it: "You can't have your cake and eat it too", or to put it another way, you can't save your cake for later and eat it now at the same time. For default arguments, you cannot simultaneously have them evaluated once *and* evaluated each time they are needed. Whichever choice you make, there will be situations that lead to a gotcha. Even if Python supported syntax for both, there would be cases where people used the wrong syntax, not knowing any better, and would trip over unexpected behaviour. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | "Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC]" <matthew.lefavor@nasa.gov> |
|---|---|
| Date | 2013-06-20 17:28 -0500 |
| Message-ID | <mailman.3662.1371812413.3114.python-list@python.org> |
| In reply to | #48809 |
[Multipart message — attachments visible in raw view] — view raw
Or, in many MANY cases, the choice was the right one, but isn't
obvious to everyone.
I think it's worth pointing out that changing function defaults to
late-binding would merely change the nature of the gotcha, not eliminate it.
words = ("one", "two", "red", "blue", "fish")
def join_strings(strings=words):
return ' '.join('%s %s' % (s, strings[-1]) for s in strings[:-1])
# Later:
words = open("gettysburg_address.txt", "r").read().split()
# Oops, the default argument of join_strings just changed.
+1. This is what convinces me that keeping references to keyword arguments is actually the right thing to do.
Perhaps I'm biased because I'm used to the mutable-argument behavior by now, but the gotcha described above seems to be much harder to track down and understand than any bugs caused by mutable arguments. With mutable arguments, at least you know the cause is in the function definition. If you initialized variables each time, you'd have to track the problem down across the entire namespace.
I, for one, would much rather follow the rule "don't use mutable arguments in function definitions" than "don't ever re-use the name of your variables."
ML
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2013-06-21 08:17 -0700 |
| Message-ID | <68185404-406e-48da-b00c-1ef99f8cf7ab@googlegroups.com> |
| In reply to | #48858 |
On Thursday, June 20, 2013 5:28:06 PM UTC-5, Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC] wrote:
>
> [snip example showing dummy coder doing something dumb]
>
> +1. This is what convinces me that keeping references to
> keyword arguments is actually the right thing to do.
>
> Perhaps I'm biased because I'm used to the mutable-
> argument behavior by now, but the gotcha described above
> seems to be much harder to track down and understand than
> any bugs caused by mutable arguments. With mutable
> arguments, at least you know the cause is in the function
> definition. If you initialized variables each time, you'd
> have to track the problem down across the entire
> namespace.
That's because you and many other folks, who keep supporting
this BS idea, have become SO accustomed to writing code in a
sloppy manner, that you need this flaw to save yourself,
FROM YOURSELF!
" Hello, allow myself to introduce myself"
Apparently you don't understand the value of writing rock
solid code. Instead of passing your mutables in as
arguments, all you have to do is reference them properly in
the BODY of the subroutine and everything will work just
fine. If you fear global level variables then write up a
simple Object definition to encapsulate the mutable and make
it callable.
============================================================
Thought Exercise:
============================================================
Let's imagine for a second if Python allowed mutable keys in
a dictionary, would you be surprised if you used a mutable
for a key, then you mutated the mutable key, then you could
not access the value from the original key?
## Imaginary code ##
py> lst = [3]
py> d = {1:2, lst:4}
py> lst.append(10)
py> d[lst]
opps, KeyError!
Would you REALLY be so surprised? I would not. But more
importantly, does Python need to protect you from being such
an idiot? I don't think so!
Any "intelligent" programmer would NEVER use mutable keys
for a hash table -- unless he had a very good reason and was
willing to take the risks -- EVEN IF the language allowed
such foolishness!
But you people will sit here all day arguing that "early
binding" is warranted on the grounds that people need to be
protected from doing stupid things -- like passing mutables
as arguments to subroutines. This is a weak argument. Tell
me you have something better, tell me the fate of this
language does not revolve around benevolent idiocy!
If you really want to save the poor idiot from writing code
that could fail, a leader ruled by benevolence, but who has
a modicum of intelligence remaining, would simply throw up a
warning.
Warning:
Argument "lst" to function "poopoo" has been mutated,
which could cause a subtle bug on successive calls.
YOU HAVE BEEN WARNED!
What you never, EVER, want to do is to use idiots for an
excuse to create some esoteric abomination of persistent
mutables between successive calls of subroutines.
> I, for one, would much rather follow the rule "don't use
> mutable arguments in function definitions"
Yes, that's the exact point i'm making! A little self
discipline can go a long way
> than "don't ever re-use the name of your variables."
Well, we're not even talking about that, but i understand
the value of your statement. Although, i think your
comparing Apples and Oranges.
PS: First you support the opposition. now you go an do a
180? You're confusing the hell out of me Matthew! @_@
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-21 01:28 +0000 |
| Message-ID | <51c3ac25$0$29999$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48796 |
On Thu, 20 Jun 2013 07:49:37 -0700, Rick Johnson wrote: > When the subroutine is completed, all inputs and local variables are > expected to be destroyed. If the programmer wants a return value, he > need simply ask. Data persistence is not a function of subroutines! > Finally, a subroutine should never have side effects UNLESS the > programmer explicitly ask for a side effect. Correct. And by using a default value, you are explicitly asking for a side-effect, namely, "use this object as the default" (not, "use this expression, and re-evaluate it at call-time"). That some people do not comprehend the *consequences* of doing so is not Python's fault, any more that it is Python's fault when people write: a = b = [] a.append(1) and then are surprised that b is no longer empty. That doesn't happen with x = y = 0 x += 1 therefore Python is buggy, yes? No. In short, your invalid understanding of Python's execution model is your lack of knowledge, not a bug in Python to be fixed. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Gary Herron <gherron@digipen.edu> |
|---|---|
| Date | 2013-06-19 12:57 -0700 |
| Message-ID | <mailman.3597.1371672307.3114.python-list@python.org> |
| In reply to | #48742 |
On 06/19/2013 12:17 PM, Ahmed Abdulshafy wrote:
> I'm reading the Python.org tutorial right now, and I found this part rather strange and incomprehensible to me>
>
> Important warning: The default value is evaluated only once. This makes a difference when the default is a mutable object such as a list, dictionary, or instances of most classes
This code:
> def f(a, L=[]):
> L.append(a)
> return L
does the same as this code:
M=[]
def f(a, L=M):
L.append(a)
return L
where it's slightly more obvious that the list is created once, and
modified with each call to the function (or rather with each call to the
function that does not supply its own value for L).
Gary Herron
>
> print(f(1))
> print(f(2))
> print(f(3))
>
> This will print
> [1]
> [1, 2]
> [1, 2, 3]
>
> How the list is retained between successive calls? And why?
--
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-20 01:17 +0000 |
| Message-ID | <51c25842$0$29999$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48742 |
On Wed, 19 Jun 2013 12:17:35 -0700, Ahmed Abdulshafy wrote:
> I'm reading the Python.org tutorial right now, and I found this part
> rather strange and incomprehensible to me>
>
> Important warning: The default value is evaluated only once. This makes
> a difference when the default is a mutable object such as a list,
> dictionary, or instances of most classes def f(a, L=[]):
> L.append(a)
> return L
>
> print(f(1))
> print(f(2))
> print(f(3))
>
> This will print
> [1]
> [1, 2]
> [1, 2, 3]
>
> How the list is retained between successive calls? And why?
"How" is easy: it is stored inside the function object, where the code
can get to it. To be precise, in the function object's __defaults__
attribute:
py> def f(a=1, b=5, c="hello world"):
... pass
...
py> f.__defaults__
(1, 5, 'hello world')
"Why" is even easier: because the creator of Python decided to do it this
way.
This is called "early binding" -- the default value is bound (assigned)
to the parameter early in the process, when the function is created. This
has a few advantages:
- It is the most efficient: the cost of evaluating the defaults
only happens once, when the function is created, not over and
over again, every time the function is called.
- It is usually what people expect. If you have a function with
a default, you normally expect the default to be set once, and
not re-evaluated each time.
- If you start with "early binding", it is trivial to get "late
binding" semantics instead; but if you start with late binding,
it's less convenient to get early binding semantics.
The usual way to get the effect of late binding in Python is with a
sentinel value to trigger the re-evaluation of the default. Normally, we
would use None and a call-time check:
def function(arg, value=None):
if value is None:
# Re-calculate the default.
value = ...
# rest of code
--
Steven
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.python
csiph-web