On Nov 21, 4:24 am, alex23 <[EMAIL PROTECTED]> wrote:
> On Nov 21, 7:49 pm, Aaron Brady <[EMAIL PROTECTED]> wrote:
>
> > On Nov 20, 11:26 pm, alex23 <[EMAIL PROTECTED]> wrote:
>
> > > On Nov 21, 10:07 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
>
> > > > Why, I would expect the interpreter to define
On Nov 21, 7:49 pm, Aaron Brady <[EMAIL PROTECTED]> wrote:
> On Nov 20, 11:26 pm, alex23 <[EMAIL PROTECTED]> wrote:
>
> > On Nov 21, 10:07 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
>
> > > Why, I would expect the interpreter to define the functions when it
> > > first hits the def, that is, at the
On Nov 20, 11:26 pm, alex23 <[EMAIL PROTECTED]> wrote:
> On Nov 21, 10:07 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
>
> > Why, I would expect the interpreter to define the functions when it
> > first hits the def, that is, at the point of definition.
>
> Then why are you arguing that the parameter
On Thu, Nov 20, 2008 at 9:26 PM, alex23 <[EMAIL PROTECTED]> wrote:
> On Nov 21, 10:07 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
>> Why, I would expect the interpreter to define the functions when it
>> first hits the def, that is, at the point of definition.
>
> Then why are you arguing that the p
On Nov 21, 10:07 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
> Why, I would expect the interpreter to define the functions when it
> first hits the def, that is, at the point of definition.
Then why are you arguing that the parameters should be re-defined at
the point of calling?
--
http://mail.py
On Thu, 20 Nov 2008 04:42:24 -0800, Aaron Brady wrote:
> On Nov 19, 7:58 pm, alex23 <[EMAIL PROTECTED]> wrote:
>> On Nov 20, 10:14 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
>>
>> > If you had a menu in a browser interface that had the items, say,
>> > 'Stop' and 'Reload', what would you expect to
On Wed, 19 Nov 2008 11:26:54 -0800, George Sakkis wrote:
> On Nov 19, 1:05 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 19 Nov 2008 05:41:57 -0800 (PST), Rick Giuly
>> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>>
>>
>>
>> > (By "better" I mean that over man
On Wed, 19 Nov 2008 10:05:23 -0800, Dennis Lee Bieber wrote:
> Do you really want a "default" argument that changes value depending
> upon actions performed in the /surrounding/ scope?
And if you do, it is easy to get:
default_y = "something"
def parrot(x, y=None):
if y is None:
y =
On Nov 20, 5:54 pm, alex23 <[EMAIL PROTECTED]> wrote:
> On Nov 20, 10:42 pm, Aaron Brady <[EMAIL PROTECTED]> wrote:
>
> > At first, I would expect it to define them at compile-time. Then,
> > when I learned there was no such thing, I would expect it to define
> > them at execute-time. What does t
On Nov 20, 10:42 pm, Aaron Brady <[EMAIL PROTECTED]> wrote:
> At first, I would expect it to define them at compile-time. Then,
> when I learned there was no such thing, I would expect it to define
> them at execute-time. What does that have to do with evaluating a
> default argument?
It has -ev
On Nov 19, 7:58 pm, alex23 <[EMAIL PROTECTED]> wrote:
> On Nov 20, 10:14 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
>
> > If you had a menu in a browser interface that had the items, say,
> > 'Stop' and 'Reload', what would you expect to happen if you clicked on
> > them?
>
> If you had a keyword c
On Wed, Nov 19, 2008 at 8:58 PM, alex23 <[EMAIL PROTECTED]> wrote:
> On Nov 20, 10:14 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
> > If you had a menu in a browser interface that had the items, say,
> > 'Stop' and 'Reload', what would you expect to happen if you clicked on
> > them?
>
> If you had
On Nov 20, 10:14 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
> If you had a menu in a browser interface that had the items, say,
> 'Stop' and 'Reload', what would you expect to happen if you clicked on
> them?
If you had a keyword called 'def', which defined functions, would you
expect it to define
On Nov 19, 12:05 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
>
> I wouldn't expect a language like Ada to somehow re-evaluate a
> default argument on each call; why would I expect Python to do such?
Lots of people do.
If you had a menu in a browser interface that had the items, say,
On Nov 19, 1:05 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On Wed, 19 Nov 2008 05:41:57 -0800 (PST), Rick Giuly
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>
>
> > (By "better" I mean that over many years of time programmers will be
> > more productive because the
On Nov 19, 8:41 am, Rick Giuly <[EMAIL PROTECTED]> wrote:
> Python provides, for the most part, an *excellent* user
> interface to the programmer. Why not make it even "better"
> by evaluating the arguments each time the function is called?
> It will be harder to change the language 10 years from
Thanks to all for your replies
All things considered, I vote for evaluating the arguments at runtime
(each time the function is called). Good reasons for this have already
been mentioned so I won't repeat them. A programming language is a
user interface of sorts. (Pretty much all languages are log
On Nov 17, 12:52 am, Aaron Brady <[EMAIL PROTECTED]> wrote:
> On Nov 16, 8:16 pm, Aaron Brady <[EMAIL PROTECTED]> wrote:
> > On Nov 16, 12:52 am, Steven D'Aprano <[EMAIL PROTECTED]
> > > I've given practical reasons why the
> > > Python choice is better. If you want default argument to be created f
On Nov 16, 8:16 pm, Aaron Brady <[EMAIL PROTECTED]> wrote:
> On Nov 16, 12:52 am, Steven D'Aprano <[EMAIL PROTECTED]
> > I've given practical reasons why the
> > Python choice is better. If you want default argument to be created from
> > scratch when the function is called, you can get it with lit
For the Nth time this year that this has come up, I'll point out yet
again that this issue has already been discussed to death before:
[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
http://mail.python.org/pipermail/python-ideas/2007-January/000121.html
[Python-3000] pre-PEP: Defa
On Nov 17, 12:27 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> If multiple statements are needed to perform the
> argument initialization, how would you then propose the problem should
> be solved?
Why, with another function of course!
def f(x, y=`f_arg_computation(x)`): ...
Or my personal favou
Aaron Brady wrote:
> On Nov 16, 7:28 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>> George Sakkis wrote:
>>> On Nov 16, 2:05 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
>> Hello All,
On Nov 16, 12:52 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sat, 15 Nov 2008 21:29:22 -0800, Aaron Brady wrote:
...
> If you want to be pedantic, then my "answer" (which you seem to approve
> of) doesn't correspond to either of the original poster's questions. If
> you'r
On Nov 16, 7:28 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > On Nov 16, 2:05 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
>
> >> Steven D'Aprano <[EMAIL PROTECTED]> writes:
> >>> On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
> Hello All,
> Why is pytho
On Nov 16, 4:05 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sun, 16 Nov 2008 07:05:51 +, Arnaud Delobelle wrote:
> > Steven D'Aprano <[EMAIL PROTECTED]> writes:
>
> >> On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
>
> >>> Hello All,
>
> >>> Why is python desig
On Nov 16, 2:30 pm, "Chris Rebert" <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 16, 2008 at 11:02 AM, George Sakkis <[EMAIL PROTECTED]> wrote:
> > On Nov 16, 8:28 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> >> "Less obvious" is entirely in the mind of the reader.
>
> > Without documentation or peek
On Sun, Nov 16, 2008 at 11:02 AM, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Nov 16, 8:28 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>>
>> > +1. Understanding and accepting the current behavior (mainly because
>> > of the extra performance penalty of evaluating the default expressions
>> > on e
On Nov 16, 8:28 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> > +1. Understanding and accepting the current behavior (mainly because
> > of the extra performance penalty of evaluating the default expressions
> > on every call would incur) is one thing, claiming that it is somehow
> > natural is p
Dennis Lee Bieber wrote:
> On Sat, 15 Nov 2008 01:40:04 -0800 (PST), Rick Giuly
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>> Why is python designed so that b and c (according to code below)
>> actually share the same list object? It seems more natural to me that
>> each
George Sakkis wrote:
> On Nov 16, 2:05 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
>
>> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>>> On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
Hello All,
Why is python designed so that b and c (according to code below)
actually shar
On Sun, 16 Nov 2008 07:05:51 +, Arnaud Delobelle wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>
>> On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
>>
>>> Hello All,
>>>
>>> Why is python designed so that b and c (according to code below)
>>> actually share the same list object?
On Nov 16, 2:05 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> writes:
> > On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
>
> >> Hello All,
>
> >> Why is python designed so that b and c (according to code below)
> >> actually share the same list object
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
>
>> Hello All,
>>
>> Why is python designed so that b and c (according to code below)
>> actually share the same list object? It seems more natural to me that
>> each object would be created with
On Sat, 15 Nov 2008 21:29:22 -0800, Aaron Brady wrote:
> I don't think Dennis or Steven read your post very well.
It's possible.
> You said 'Why
> does Python do X?', and 'It seems natural to you to do not X'. Dennis
> and Steven both said, 'Python does X'.
I also disputed that it is natural to
On Nov 15, 3:40 am, Rick Giuly <[EMAIL PROTECTED]> wrote:
> Hello All,
>
> Why is python designed so that b and c (according to code below)
> actually share the same list object? It seems more natural to me that
> each object would be created with a new list object in the points
> variable.
>
> cla
On Sat, 15 Nov 2008 01:40:04 -0800, Rick Giuly wrote:
> Hello All,
>
> Why is python designed so that b and c (according to code below)
> actually share the same list object? It seems more natural to me that
> each object would be created with a new list object in the points
> variable.
That's n
Rick Giuly <[EMAIL PROTECTED]> writes:
> Hello All,
Hello,
> Why is python designed so that b and c (according to code below)
> actually share the same list object? It seems more natural to me that
> each object would be created with a new list object in the points
> variable.
>
> class Blob:
>
Hello All,
Why is python designed so that b and c (according to code below)
actually share the same list object? It seems more natural to me that
each object would be created with a new list object in the points
variable.
class Blob:
def __init__(self, points=[]):
self._points = point
38 matches
Mail list logo
