>
> The Apathetic Approach:
>
> I could just assume that a programmer is responsible for the
> code he writes. If he passes mutables into a function as
> default arguments, and
On Jun 21, 2013, at 11:17 AM, Rick Johnson wrote:
> 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
On Sat, Jun 22, 2013 at 8:40 AM, Antoon Pardon
wrote:
> Are you two guys now egging on Rick Johnson?
No. Rick is incorrigible, and I would have been surprised if he
responded to that anyway.
--
http://mail.python.org/mailman/listinfo/python-list
On 24/06/2013 15:22, Grant Edwards wrote:
On 2013-06-22, Ian Kelly wrote:
On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
wrote:
On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
On 21/06/2013 21:44, Rick Johnson wrote:
[...]
Which in Python would be the "MutableArgumentWarning".
*school-
On 2013-06-22, Ian Kelly wrote:
> On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
> wrote:
>> On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
>>
>>> On 21/06/2013 21:44, Rick Johnson wrote:
>> [...]
Which in Python would be the "MutableArgumentWarning".
*school-bell*
>>> I not
On 22/06/2013 19:49, Rick Johnson wrote:
On Saturday, June 22, 2013 12:19:31 PM UTC-5, Rotwang wrote:
On 22/06/2013 02:15, Rick Johnson wrote:
IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND?
No, I don't. These two special cases are not sufficient
for me to determine what semantics you are prop
On 22/06/2013 03:32, Rick Johnson wrote:
On Friday, June 21, 2013 8:54:50 PM UTC-5, MRAB wrote:
On 22/06/2013 00:51, Rick Johnson wrote:
> On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> My argument has always been that mutables should not be
> passed into subroutines as default argumen
On Sat, Jun 22, 2013 at 10:49 AM, Dennis Lee Bieber
wrote:
> On Fri, 21 Jun 2013 19:27:42 -0600, Ian Kelly
> declaimed the following:
>
>>While we're at it, I would like to petition for a function
>>terminates(f, args) that I can use to determine whether a function
>>will terminate before I actua
On Saturday, June 22, 2013 12:19:31 PM UTC-5, Rotwang wrote:
> > On 22/06/2013 02:15, Rick Johnson wrote:
> > IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND?
>
> No, I don't. These two special cases are not sufficient
> for me to determine what semantics you are proposing for
> the general case.
On 22/06/2013 03:01, I wrote:
On 22/06/2013 02:15, Rick Johnson wrote:
[...]
This is what should happen:
py> def foo(arg=[]):
... arg.append(1)
... print(arg)
...
py> foo()
[1]
py> foo()
[1]
py> foo()
[1]
Yes, Yes, YES! That is intuiti
On Saturday, June 22, 2013 8:37:20 PM UTC+5:30, Rick Johnson wrote:
> I sorry, but FP is not going to wash our sins clean. In
> fact, if taken too seriously, FP leads to preaching
> professors, intellectually unstimulated students, and
> semesters of wasted time that could have been better spent
>
On Saturday, June 22, 2013 8:37:20 PM UTC+5:30, Rick Johnson wrote:
> > So for example, if the use-case contained a statement
> > like: In order to safeguard customer-satisfaction, the
> > ATM's performance shall not degrade beyond 3 seconds
> > response time.
> > So now - according to our methodol
> See my blog [...]
> for a history of wishes akin to yours and lessons not
> learnt. In short the problems accruing from unconstrained
> imperative programming are severe and the solutions are
> hard. In the meanwhile, goals such as your 'keep-
> procedures-stateless' can and should certainly be
>
Op 22-06-13 03:27, Ian Kelly schreef:
On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
wrote:
On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
On 21/06/2013 21:44, Rick Johnson wrote:
[...]
Which in Python would be the "MutableArgumentWarning".
*school-bell*
I notice that you've omitted
On 22/06/2013 02:31, Steven D'Aprano wrote:
On Sat, 22 Jun 2013 05:07:59 +1000, Chris Angelico wrote:
Oh! I know. Function argument defaults will now be restricted to
int/float/tuple. That would do it, right? Nobody would be bothered by
little restrictions like that, would they.
Alas, tuples
On Saturday, June 22, 2013 8:25:15 AM UTC+5:30, Rick Johnson wrote:
> On Friday, June 21, 2013 9:32:43 PM UTC-5, rusi wrote:
> > So Rick... I agree with you... all these theoreticians
> > should be burnt at the stake!
> > On a more serious note: many
> > people make similar mistakes eg Haskellers
On Friday, June 21, 2013 9:32:43 PM UTC-5, rusi wrote:
> So Rick... I agree with you... all these theoreticians
> should be burnt at the stake! On a more serious note: many
> people make similar mistakes eg Haskellers who think
> Haskell is safe. Safer (than something or other) -- Ok
> Safe -- NO
On 06/21/2013 07:41 PM, Chris Angelico wrote:
>> While we're at it, I would like to petition for a function
>> terminates(f, args) that I can use to determine whether a function
>> will terminate before I actually call it.
>
> Nice idea from a theoretical point of view, but practicality beats
> pu
On Saturday, June 22, 2013 7:34:18 AM UTC+5:30, MRAB wrote:
> Pure functional languages don't have mutables, or even variables, but
> then we're not talking about a pure functional language, we're talking
> about Python.
In which case neither do mathematicians. Do we rewrite the last 1000 years o
On Friday, June 21, 2013 8:38:21 PM UTC-5, Ian wrote:
> The answer to this conundrum is staring you in the face.
Thanks for posting a solution for this. Not sure if i'll
ever need it, but nice to know.
> Note that the TypeError complains that you passed it an
> "unhashable" type, and not that you
On Saturday, June 22, 2013 6:57:42 AM UTC+5:30, Ian wrote:
> While we're at it, I would like to petition for a function
> terminates(f, args) that I can use to determine whether a function
> will terminate before I actually call it.
I was going to say something about this -- viz that in prog. lang
On Friday, June 21, 2013 8:54:50 PM UTC-5, MRAB wrote:
> On 22/06/2013 00:51, Rick Johnson wrote:
> > On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> > My argument has always been that mutables should not be
> > passed into subroutines as default arguments because bad
> > things can happen
On 22/06/2013 03:18, Chris Angelico wrote:
On Sat, Jun 22, 2013 at 12:01 PM, Rotwang wrote:
class hashablelist(list):
... def __hash__(self):
... return hash(tuple(self))
There's a vulnerability in that definition:
a=hashablelist((1,[],3))
a
[1, [], 3]
{a:1}
Traceback (most
On Sat, Jun 22, 2013 at 12:01 PM, Rotwang wrote:
class hashablelist(list):
> ... def __hash__(self):
> ... return hash(tuple(self))
There's a vulnerability in that definition:
>>> a=hashablelist((1,[],3))
>>> a
[1, [], 3]
>>> {a:1}
Traceback (most recent call last):
File "", l
On 22/06/2013 02:15, Rick Johnson wrote:
On Friday, June 21, 2013 6:40:51 PM UTC-5, Rotwang wrote:
On 21/06/2013 19:26, Rick Johnson wrote:
[...]
I didn't ask what alternative methods of handling default
argument binding exist (I can think of several, but none
of them strikes me as preferable to
On 22/06/2013 02:40, Chris Angelico wrote:
On Sat, Jun 22, 2013 at 11:31 AM, Steven D'Aprano
wrote:
Thinking about this, I think that the only safe thing to do in Rickython
4000 is to prohibit putting mutable objects inside tuples. Putting a list
or a dict inside a tuple is just a bug waiting t
On 22/06/2013 00:51, Rick Johnson wrote:
On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
I notice that you've omitted any mention of how you'd know that the
argument was mutable.
My argument has always been that mutables should not be
passed into subroutines as default arguments because
On Fri, Jun 21, 2013 at 7:37 PM, Chris Angelico wrote:
class HashableList(list):
> def __hash__(self):
> return 42
Hey, we both picked exactly the same example!
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Jun 21, 2013 at 7:15 PM, Rick Johnson
wrote:
>> > Let's imagine for a second if Python allowed mutable keys in
>> > a dictionary,
>> which it does
>
> Am i just to take your word for this? You cannot provide an
> example? Here, allow me to "break the ice":
>
> # Literal
> py> d = {
On Friday, June 21, 2013 8:31:35 PM UTC-5, Steven D'Aprano wrote:
> Tuples have to go into the "Bad List" because, although
> they themselves are immutable, their contents may not be.
> Imagine the confusion and horror that poor developers will
> experience when they do something like this:
>
> de
On Sat, Jun 22, 2013 at 11:27 AM, Ian Kelly wrote:
> On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
> wrote:
>> On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
>>
>>> On 21/06/2013 21:44, Rick Johnson wrote:
>> [...]
Which in Python would be the "MutableArgumentWarning".
*school-
On Sat, Jun 22, 2013 at 11:31 AM, Steven D'Aprano
wrote:
> Thinking about this, I think that the only safe thing to do in Rickython
> 4000 is to prohibit putting mutable objects inside tuples. Putting a list
> or a dict inside a tuple is just a bug waiting to happen!
I think you're onto something
On Sat, Jun 22, 2013 at 11:15 AM, Rick Johnson
wrote:
> # Literal
> py> d = {[1]:2}
> Traceback (most recent call last):
> File "", line 1, in
> d = {[1]:2}
> TypeError: unhashable type: 'list'
> # Symbol
> py> lst = [1]
> py> d = {lst:2}
> Traceback
On Sat, 22 Jun 2013 05:07:59 +1000, Chris Angelico wrote:
> Oh! I know. Function argument defaults will now be restricted to
> int/float/tuple. That would do it, right? Nobody would be bothered by
> little restrictions like that, would they.
Alas, tuples won't do it. Fortunately, you can include
On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
wrote:
> On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
>
>> On 21/06/2013 21:44, Rick Johnson wrote:
> [...]
>>> Which in Python would be the "MutableArgumentWarning".
>>>
>>> *school-bell*
>>>
>> I notice that you've omitted any mention of how yo
On Friday, June 21, 2013 6:40:51 PM UTC-5, Rotwang wrote:
> On 21/06/2013 19:26, Rick Johnson wrote:
> [...]
> I didn't ask what alternative methods of handling default
> argument binding exist (I can think of several, but none
> of them strikes me as preferable to how Python currently
> does it).
On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:
> On 21/06/2013 21:44, Rick Johnson wrote:
[...]
>> Which in Python would be the "MutableArgumentWarning".
>>
>> *school-bell*
>>
> I notice that you've omitted any mention of how you'd know that the
> argument was mutable.
That's easy. Just call is
On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> I notice that you've omitted any mention of how you'd know that the
> argument was mutable.
My argument has always been that mutables should not be
passed into subroutines as default arguments because bad
things can happen. And Python's excu
On 21/06/2013 19:26, Rick Johnson wrote:
On Friday, June 21, 2013 12:47:56 PM UTC-5, Rotwang wrote:
It isn't clear to me from your posts what exactly you're
proposing as an alternative to the way Python's default
argument binding works. In your version of Python, what
exactly would happen when I
On 21/06/2013 21:44, Rick Johnson wrote:
On Friday, June 21, 2013 2:25:49 PM UTC-5, MRAB wrote:
On 21/06/2013 19:26, Rick Johnson wrote:
>
> The Apathetic Approach:
>
> I c
On Friday, June 21, 2013 2:25:49 PM UTC-5, MRAB wrote:
> On 21/06/2013 19:26, Rick Johnson wrote:
> >
> > The Apathetic Approach:
> >
> > I could just assume that a programmer
On Friday, June 21, 2013 2:20:22 PM UTC-5, Neil Cerutti wrote:
> Rick, it's not a wart, It's a gotcha. The reason it's a
> gotcha is this: In order to predict what will happen
> correctly, you have to have mastered three separate Python
> concepts.
>
> 1. How name-binding works.
> 2. How argument p
On Friday, June 21, 2013 2:18:27 PM UTC-5, Rick Johnson wrote:
> On Friday, June 21, 2013 1:37:13 PM UTC-5, Steven D'Aprano wrote:
>
> > Okay, you're trolling.
Steven, you wouldn't know "trolling" even if you were an honorary salad tosser
at a troll face-sitting contest.
--
http://mail.python.
On 21/06/2013 19:26, Rick Johnson wrote:
On Friday, June 21, 2013 12:47:56 PM UTC-5, Rotwang wrote:
It isn't clear to me from your posts what exactly you're
proposing as an alternative to the way Python's default
argument binding works. In your version of Python, what
exactly would happen when I
On 2013-06-21, Chris Angelico wrote:
> On Sat, Jun 22, 2013 at 4:26 AM, Rick Johnson
> wrote:
>> I could cast a "virtual net" over my poor lemmings before
>> they jump off the cliff by throwing an exception:
>>
>> Traceback (most recent screw-up last):
>>Line BLAH in SCRIPT
>> def f(x =
On Friday, June 21, 2013 1:37:13 PM UTC-5, Steven D'Aprano wrote:
> Okay, you're trolling. Time for another month in the kill-file.
> *plonk*
That's so typical of you. You start losing an argument, and
when you have no remaining counter arguments, you resort to
name calling. Why am i not surprise
On Sat, Jun 22, 2013 at 4:26 AM, Rick Johnson
wrote:
> I could cast a "virtual net" over my poor lemmings before
> they jump off the cliff by throwing an exception:
>
> Traceback (most recent screw-up last):
>Line BLAH in SCRIPT
> def f(x = [None, b, [a, [4]]]):
> ArgumentError: No mut
On Fri, 21 Jun 2013 11:26:39 -0700, Rick Johnson wrote:
> You know, out of all these post, not one of you guys has presented a
> valid use-case that will give validity to the existence of this PyWart
LOL.
Okay, you're trolling. Time for another month in the kill-file.
*plonk*
--
Steven
--
h
On Friday, June 21, 2013 12:47:56 PM UTC-5, Rotwang wrote:
> It isn't clear to me from your posts what exactly you're
> proposing as an alternative to the way Python's default
> argument binding works. In your version of Python, what
> exactly would happen when I passed a mutable argument as a
> de
On 21/06/2013 18:01, Rick Johnson wrote:
[stuff]
It isn't clear to me from your posts what exactly you're proposing as an
alternative to the way Python's default argument binding works. In your
version of Python, what exactly would happen when I passed a mutable
argument as a default value
On Friday, June 21, 2013 10:57:17 AM UTC-5, Steven D'Aprano wrote:
> On Thu, 20 Jun 2013 11:05:32 -0700, Rick Johnson wrote:
> > py> class FuncAdd(object):
> > ... def __init__(self, ivalue):
> > ... self.ivalue = ivalue
> Notice how you are storing state here? I thought you said,
On Thu, 20 Jun 2013 20:16:19 -0700, Rick Johnson wrote:
> On Thursday, June 20, 2013 7:57:28 PM UTC-5, Steven D'Aprano wrote:
>> On Thu, 20 Jun 2013 11:05:32 -0700, Rick Johnson wrote:
>> They [default argument values] have to be stored *somewhere*, and
>> Python chooses to store them as an attri
On Thu, 20 Jun 2013 11:05:32 -0700, Rick Johnson wrote:
> Python functions are objects that take arguments, of which (the
> arguments) are then converted to attributes of the function object.
> Ah-Ha! Urm, but wait! We already have a method to define Objects. Heck,
> I can even create my own calla
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 b
On Friday, June 21, 2013 2:10:49 AM UTC-5, Chris Angelico wrote:
> Why should that be? Why is a subroutine not allowed to
> retain any state?
I refuse to repeat myself for lazy readers!
> You're free to write code in a purely functional style if
> you like
I don't want to write code in a purely
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(stri
On Fri, Jun 21, 2013 at 1:16 PM, Rick Johnson
wrote:
> On Thursday, June 20, 2013 7:57:28 PM UTC-5, Steven D'Aprano wrote:
>> Python functions are
>> created *once*, when defined. The cost of building the
>> function -- compiling the source code to byte code,
>> assembling the pieces into a functi
On Thursday, June 20, 2013 7:57:28 PM UTC-5, Steven D'Aprano wrote:
> On Thu, 20 Jun 2013 11:05:32 -0700, Rick Johnson wrote:
> > Python functions are objects that take arguments, of
> > which (the arguments) are then converted to attributes
> > of the function object.
> Arguments in general are *n
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
rusi於 2013年6月21日星期五UTC+8上午1時12分01秒寫道：
> You know Rick, you are good at python, you are better at polemics.
>
> If only you would cut the crap I would (be able to) agree with you.
>
> See below
>
>
>
> On Jun 20, 7:49 pm, Rick Johnson wrote:
>
> > On Thursday, June 20, 2013 7:57:06 AM UTC-5,
On 2013-06-20 21:40, Roy Smith wrote:
> In article ,
> Tim Chase wrote:
>
> > On 2013-06-21 01:08, Steven D'Aprano wrote:
> > > Here's my syntax plucked out of thin air:
> > >
> > > def func(arg, x=expression, !y=expression):
> > > ...
> > >
> > > where y=expression is late-bound, and the
In article ,
Tim Chase wrote:
> On 2013-06-21 01:08, Steven D'Aprano wrote:
> > Here's my syntax plucked out of thin air:
> >
> > def func(arg, x=expression, !y=expression):
> > ...
> >
> > where y=expression is late-bound, and the above is compiled to:
> >
> > def func(arg, x=expression,
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
On 2013-06-21 01:08, Steven D'Aprano wrote:
> Here's my syntax plucked out of thin air:
>
> def func(arg, x=expression, !y=expression):
> ...
>
> where y=expression is late-bound, and the above is compiled to:
>
> def func(arg, x=expression, y=None):
> if y is None:
> y = express
On Thu, 20 Jun 2013 11:57:34 -0600, Ian Kelly wrote:
> Additionally, with late-binding semantics the default values would no
> longer be default *values*. They would be initialization code instead,
> which sort of flies in the face of the idea that late-binding would
> somehow be better for funct
On Thu, 20 Jun 2013 11:05:32 -0700, Rick Johnson wrote:
> On Thursday, June 20, 2013 10:38:34 AM UTC-5, Chris Angelico wrote:
>> Function defaults in Python, being implemented as attributes on the
>> function object, are very similar in nature to static variables in C.
>
> Oh wait a minute. i thi
On 21/06/2013 4:07 AM, Rick Johnson wrote:
Okay. So now you are admitting the problem. That is a good
start. Thanks for being honest.
If you think mutable default arguments is a "problem", then you don't
really understand Python. The only "gotcha" here is in people's heads.
--
http://mail.py
In article <51c39b88$0$2$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Thu, 20 Jun 2013 09:19:48 -0400, Roy Smith wrote:
>
> > In article
> > <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
> > rusi wrote:
> >
> >> > > def f(a, L=[]):
> >> > > Â Â
On Thu, 20 Jun 2013 09:19:48 -0400, Roy Smith wrote:
> In article
> <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
> rusi wrote:
>
>> > > def f(a, L=[]):
>> > > L.append(a)
>> > > return L
>
>> Every language has gotchas. This is one of python's.
>
> One of our pr
On Jun 20, 10:57 pm, Ian Kelly wrote:
> If
> the goal is indeed to make the the functions more functional, then the
> proper solution would be to keep the binding early but just disallow
> mutable defaults altogether -- which is tricky to achieve in Python,
> so we simply emulate it with the advic
On Thursday, June 20, 2013 12:12:01 PM UTC-5, 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.
Okay. So now you are admitt
On Thursday, June 20, 2013 10:38:34 AM UTC-5, Chris Angelico wrote:
> Function defaults in Python, being implemented as
> attributes on the function object, are very similar in
> nature to static variables in C.
Oh wait a minute. i think it's becoming clear to me now!
Python functions are objects
On Thu, Jun 20, 2013 at 11:19 AM, Chris Angelico wrote:
> On Fri, Jun 21, 2013 at 3:12 AM, 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
>> entren
On Jun 20, 10:19 pm, Chris Angelico wrote:
> On Fri, Jun 21, 2013 at 3:12 AM, 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
On Fri, Jun 21, 2013 at 3:12 AM, 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
You know Rick, you are good at python, you are better at polemics.
If only you would cut the crap I would (be able to) agree with you.
See below
On Jun 20, 7:49 pm, Rick Johnson wrote:
> On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote:
> > Every language has gotchas. This is one of python
On Fri, Jun 21, 2013 at 12:49 AM, 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!
Funny, C violates your descri
On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote:
> Every language has gotchas. This is one of python's.
So are we purposely injecting illogic into our language just
to be part of some "cool crowd" of programming languages with
gotchas.
"You thought intuitiveness was a virtue? Haha, we go
On Jun 20, 6:19 pm, Roy Smith wrote:
> In article
> <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
>
> rusi wrote:
> > > > def f(a, L=[]):
> > > > L.append(a)
> > > > return L
> > Every language has gotchas. This is one of python's.
>
> One of our pre-interview scree
In article
<447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
rusi wrote:
> > > def f(a, L=[]):
> > > L.append(a)
> > > return L
> Every language has gotchas. This is one of python's.
One of our pre-interview screening questions for Python programmers at
Songza is ab
On Jun 20, 12:38 am, Rick Johnson
wrote:
> On Wednesday, June 19, 2013 2:17:35 PM UTC-5, 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
> >
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
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 li
On Wednesday, June 19, 2013 2:17:35 PM UTC-5, 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
Ahmed Abdulshafy writes:
> 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
Excerpts from Thomas L. Shinnick's message of Sun Jun 26 14:53:21 -0400 2011:
> See reference manual section 7.6 "Function definitions" under the
> discussion subtitle "Default parameter values are evaluated when the
> function definition is executed. "
>
> http://docs.python.org/refer
On Sun, Jun 26, 2011 at 11:28 AM, Marc Aymerich wrote:
> Hi,
> I'm trying to define a function that has an optional parameter which
> should be an empty list whenever it isn't given. However, it takes as
> value the same value as the last time the function was executed. What
> is the reason of thi
At 01:39 PM 6/26/2011, Shashank Singh wrote:
On Sun, Jun 26, 2011 at 11:58 PM, Marc Aymerich wrote:
> Hi,
> I'm trying to define a function that has an optional parameter which
> should be an empty list whenever it isn't given. However, it takes as
> value the same value as the last time the fun
On 6/26/2011 2:28 PM, Marc Aymerich wrote:
Hi,
I'm trying to define a function that has an optional parameter which
should be an empty list whenever it isn't given. However, it takes as
value the same value as the last time the function was executed. What
is the reason of this behaviour? How does
On Sun, Jun 26, 2011 at 7:28 PM, Marc Aymerich wrote:
> Hi,
> I'm trying to define a function that has an optional parameter which
> should be an empty list whenever it isn't given. However, it takes as
> value the same value as the last time the function was executed. What
> is the reason of this
Excerpts from Marc Aymerich's message of Sun Jun 26 14:28:30 -0400 2011:
> Hi,
> I'm trying to define a function that has an optional parameter which
> should be an empty list whenever it isn't given. However, it takes as
> value the same value as the last time the function was executed. What
> is
On Sun, Jun 26, 2011 at 11:58 PM, Marc Aymerich wrote:
> Hi,
> I'm trying to define a function that has an optional parameter which
> should be an empty list whenever it isn't given. However, it takes as
> value the same value as the last time the function was executed. What
> is the reason of thi
On Sep 11, 1:55 pm, 人言落日是天涯，望极天涯不见家 wrote:
> On Sep 11, 1:14 pm, Benjamin Kaplan wrote:
>
>
>
> > On Sat, Sep 11, 2010 at 12:38 AM, 人言落日是天涯，望极天涯不见家
> > wrote:
> > > Please look at below code snippet:
> > > class test():
> > > def __init__(self, a, dic={}):
> > > self.a = a
> > >
On Sep 11, 1:14 pm, Benjamin Kaplan wrote:
> On Sat, Sep 11, 2010 at 12:38 AM, 人言落日是天涯，望极天涯不见家
> wrote:
> > Please look at below code snippet:
> > class test():
> > def __init__(self, a, dic={}):
> > self.a = a
> > self.dic = dic
> > print('__init__ params:',a, dic)
>
> T
On Sat, Sep 11, 2010 at 12:38 AM, 人言落日是天涯，望极天涯不见家 wrote:
> Please look at below code snippet:
> class test():
> def __init__(self, a, dic={}):
> self.a = a
> self.dic = dic
> print('__init__ params:',a, dic)
>
This is a pretty popular mistake to make. Default arguments ar
eb303 a écrit :
On Apr 19, 2:20 pm, AlienBaby wrote:
Hi,
just a quick one,
Is it possible to achieve a default value in a list comprehension
where the if-clause is false?
Ie, something similar to:
[ a for a in b if something(a) else 'default' ]
the idea being that, rather than skip a value
On Apr 19, 1:23 pm, eb303 wrote:
> On Apr 19, 2:20 pm, AlienBaby wrote:
>
>
>
>
>
> > Hi,
>
> > just a quick one,
>
> > Is it possible to achieve a default value in a list comprehension
> > where the if-clause is false?
>
> > Ie, something similar to:
>
> > [ a for a in b if something(a) else 'de
On Apr 19, 2:20 pm, AlienBaby wrote:
> Hi,
>
> just a quick one,
>
> Is it possible to achieve a default value in a list comprehension
> where the if-clause is false?
>
> Ie, something similar to:
>
> [ a for a in b if something(a) else 'default' ]
>
> the idea being that, rather than skip a value
In article
<[EMAIL PROTECTED]>,
Paul McGuire <[EMAIL PROTECTED]> wrote:
> On Oct 14, 1:36 pm, "David C. Ullrich" <[EMAIL PROTECTED]> wrote:
> > >[...]
>
> > In particular default parameters should work the way the user
> > expects! The fact that different users will expect different
> > things
David C. Ullrich a écrit :
In article <[EMAIL PROTECTED]>,
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
(snip)
Well... How to say.. Is there any chance these people will read anything
*at all* ?
No. That's exactly the point!
Yeps. But I don't think we derive the same conclusions from that
1 - 100 of 169 matches
Mail list logo
