Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #17707 > unrolled thread

what does 'a=b=c=[]' do

Back to article view | Back to comp.lang.python

Contents

  what does 'a=b=c=[]' do Eric <einazaki668@yahoo.com> - 2011-12-21 14:25 -0800
    Re: what does 'a=b=c=[]' do Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-12-21 18:20 -0500
      Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-21 23:48 +0000
        Re: what does 'a=b=c=[]' do Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-12-24 19:41 +0100
          Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-25 13:16 +0000
      Re: what does 'a=b=c=[]' do Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-12-24 19:45 +0100
    Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-21 23:44 +0000
      Re: what does 'a=b=c=[]' do Eric <einazaki668@yahoo.com> - 2011-12-22 20:27 -0800
    Re: what does 'a=b=c=[]' do alex23 <wuwei23@gmail.com> - 2011-12-21 16:50 -0800
      Re: what does 'a=b=c=[]' do Rolf Camps <rolf@roce.be> - 2011-12-22 09:51 +0100
        Re: what does 'a=b=c=[]' do alex23 <wuwei23@gmail.com> - 2011-12-22 18:10 -0800
          Re: what does 'a=b=c=[]' do Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-22 19:59 -0700
            Re: what does 'a=b=c=[]' do alex23 <wuwei23@gmail.com> - 2011-12-22 19:40 -0800
              Re: what does 'a=b=c=[]' do Chris Angelico <rosuav@gmail.com> - 2011-12-23 15:25 +1100
              Re: what does 'a=b=c=[]' do Ian Kelly <ian.g.kelly@gmail.com> - 2011-12-22 22:22 -0700
                Re: what does 'a=b=c=[]' do alex23 <wuwei23@gmail.com> - 2011-12-22 22:00 -0800
          Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 00:38 -0800
            Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-23 09:39 +0000
              Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 02:22 -0800
                Re: what does 'a=b=c=[]' do Robert Kern <robert.kern@gmail.com> - 2011-12-23 13:10 +0000
                  Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 05:23 -0800
                    Re: what does 'a=b=c=[]' do Robert Kern <robert.kern@gmail.com> - 2011-12-23 13:53 +0000
                      Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 06:57 -0800
                        Re: what does 'a=b=c=[]' do Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-23 15:33 +0000
                          Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 07:59 -0800
            Re: what does 'a=b=c=[]' do Ethan Furman <ethan@stoneleaf.us> - 2011-12-23 00:49 -0800
            Re: what does 'a=b=c=[]' do Chris Angelico <rosuav@gmail.com> - 2011-12-23 20:59 +1100
              Re: what does 'a=b=c=[]' do rusi <rustompmody@gmail.com> - 2011-12-23 02:31 -0800
                Timeout when calling COM objects on Windows Wong Wah Meng-R32813 <r32813@freescale.com> - 2011-12-23 11:20 +0000
                Re: what does 'a=b=c=[]' do Michael Torrie <torriem@gmail.com> - 2011-12-23 10:23 -0700
              Re: what does 'a=b=c=[]' do Neil Cerutti <neilc@norwich.edu> - 2011-12-23 13:10 +0000
                Re: what does 'a=b=c=[]' do Neil Cerutti <neilc@norwich.edu> - 2011-12-23 13:13 +0000
                  Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-23 15:49 +0000
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Chris Angelico <rosuav@gmail.com> - 2011-12-24 02:55 +1100
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-23 22:32 +0000
                        Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Chris Angelico <rosuav@gmail.com> - 2011-12-24 09:50 +1100
                          Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-24 08:11 +0000
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Roy Smith <roy@panix.com> - 2011-12-23 11:15 -0500
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] alex23 <wuwei23@gmail.com> - 2011-12-24 05:43 -0800
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Mel Wilson <mwilson@the-wire.com> - 2011-12-23 11:27 -0500
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] alex23 <wuwei23@gmail.com> - 2011-12-24 05:52 -0800
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Neil Cerutti <neilc@norwich.edu> - 2011-12-23 17:03 +0000
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-24 08:25 +0000
                        Re: Early and late binding [was Re: what does 'a=b=c=[]' do] alex23 <wuwei23@gmail.com> - 2011-12-24 06:08 -0800
                          Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-24 18:25 -0500
                            Re: Early and late binding [was Re: what does 'a=b=c=[]' do] alex23 <wuwei23@gmail.com> - 2011-12-24 16:10 -0800
                              Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-24 19:32 -0500
                                Re: Early and late binding [was Re: what does 'a=b=c=[]' do] rusi <rustompmody@gmail.com> - 2011-12-24 19:22 -0800
                        Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Lie Ryan <lie.1296@gmail.com> - 2011-12-25 15:12 +1100
                    Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-23 19:24 -0500
                      Re: Early and late binding [was Re: what does 'a=b=c=[]' do] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-24 08:26 +0000
          Re: what does 'a=b=c=[]' do Ethan Furman <ethan@stoneleaf.us> - 2011-12-23 00:38 -0800
      Re: what does 'a=b=c=[]' do Ethan Furman <ethan@stoneleaf.us> - 2011-12-22 05:20 -0800
      Re: what does 'a=b=c=[]' do Eric <einazaki668@yahoo.com> - 2011-12-22 19:46 -0800
    Re: what does 'a=b=c=[]' do Lie Ryan <lie.1296@gmail.com> - 2011-12-24 21:30 +1100
    Re: what does 'a=b=c=[]' do Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-12-24 19:49 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#17802

On Dec 23, 6:10 pm, Robert Kern <robert.k...@gmail.com> wrote:
> On 12/23/11 10:22 AM, rusi wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 23, 2:39 pm, Steven D'Aprano<steve
> > +comp.lang.pyt...@pearwood.info>  wrote:
> >> On Fri, 23 Dec 2011 00:38:07 -0800, rusi wrote:
> >>> Likewise function arguments that default to mutable entities is a known
> >>> gotcha of python which is best treated as a bug in python.
>
> >> Nonsense. It is a feature, not a bug.
>
> > Tsk Tsk How can python have a bug? And that too on the python mailing
> > list?
>
> > Others however feel differently. See Chris Rebert's
> >http://mail.python.org/pipermail/python-ideas/2007-January/000073.html
> > and the links cited there.
>
> >> Some people might argue that it is a mistake, a minor feature which
> >> allegedly causes more difficulties than benefits. I do not hold with that
> >> idea. But either way, it is not a bug to be fixed, but a deliberate
> >> consequence of intended semantics.
>
> > I did not ask or imply that it should be 'fixed', just that language
> > misfeatures should be treated with extra care.
>
> "Bug" means, roughly, "something that should be fixed" not just any "thing that
> has some unwanted consequences". So yes, by calling it a bug you are asking and
> implying just that. If you don't mean that, don't use the word "bug".

Of course it should be fixed.  The repeated recurrence of it as a
standard gotcha as well as the python ideas list testifies to that.

Its not going to be fixed -- does not mean thats ideal, just that the
best proposed solutions cost/benefit equations are not good enough at
this point.

Case in point: I think it was around python 2.2 that there were
discussions for having a conditional operator.  GvR did not put it in
for a couple of releases not because it was a bad idea but because no
syntax was good enough.

When he finally did it, he chose a syntax which is arguably not ideal
but is the best all-things-considered (eg no unnecessary new keywords,
compatibility with existing code etc)

[toc] | [prev] | [next] | [standalone]

#17803

On 12/23/11 1:23 PM, rusi wrote:
> On Dec 23, 6:10 pm, Robert Kern<robert.k...@gmail.com>  wrote:
>> On 12/23/11 10:22 AM, rusi wrote:
>>> On Dec 23, 2:39 pm, Steven D'Aprano<steve
>>> +comp.lang.pyt...@pearwood.info>    wrote:

>>>> Some people might argue that it is a mistake, a minor feature which
>>>> allegedly causes more difficulties than benefits. I do not hold with that
>>>> idea. But either way, it is not a bug to be fixed, but a deliberate
>>>> consequence of intended semantics.
>>
>>> I did not ask or imply that it should be 'fixed', just that language
>>> misfeatures should be treated with extra care.
>>
>> "Bug" means, roughly, "something that should be fixed" not just any "thing that
>> has some unwanted consequences". So yes, by calling it a bug you are asking and
>> implying just that. If you don't mean that, don't use the word "bug".
>
> Of course it should be fixed.  The repeated recurrence of it as a
> standard gotcha as well as the python ideas list testifies to that.

So you were lying when you said that you did not ask or imply that it should be 
'fixed'? Please make up your mind. It's quite rude to "defend" your position by 
constantly shifting it whenever you get challenged on it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#17805

On Dec 23, 6:53 pm, Robert Kern <robert.k...@gmail.com> wrote:
> On 12/23/11 1:23 PM, rusi wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 23, 6:10 pm, Robert Kern<robert.k...@gmail.com>  wrote:
> >> On 12/23/11 10:22 AM, rusi wrote:
> >>> On Dec 23, 2:39 pm, Steven D'Aprano<steve
> >>> +comp.lang.pyt...@pearwood.info>    wrote:
> >>>> Some people might argue that it is a mistake, a minor feature which
> >>>> allegedly causes more difficulties than benefits. I do not hold with that
> >>>> idea. But either way, it is not a bug to be fixed, but a deliberate
> >>>> consequence of intended semantics.
>
> >>> I did not ask or imply that it should be 'fixed', just that language
> >>> misfeatures should be treated with extra care.
>
> >> "Bug" means, roughly, "something that should be fixed" not just any "thing that
> >> has some unwanted consequences". So yes, by calling it a bug you are asking and
> >> implying just that. If you don't mean that, don't use the word "bug".
>
> > Of course it should be fixed.  The repeated recurrence of it as a
> > standard gotcha as well as the python ideas list testifies to that.
>
> So you were lying when you said that you did not ask or imply that it should be
> 'fixed'? Please make up your mind. It's quite rude to "defend" your position by
> constantly shifting it whenever you get challenged on it.

Meanings of "should" http://www.englishpage.com/modals/should.html
My first should was the 3rd one
My second was the 1st one.

[And we really should stop this argument (2nd one)]

[toc] | [prev] | [next] | [standalone]

#17806

On Fri, 23 Dec 2011 06:57:02 -0800, rusi wrote:

> On Dec 23, 6:53 pm, Robert Kern <robert.k...@gmail.com> wrote:
>> On 12/23/11 1:23 PM, rusi wrote:
[...]
>> > Of course it should be fixed.  The repeated recurrence of it as a
>> > standard gotcha as well as the python ideas list testifies to that.
>>
>> So you were lying when you said that you did not ask or imply that it
>> should be 'fixed'? Please make up your mind. It's quite rude to
>> "defend" your position by constantly shifting it whenever you get
>> challenged on it.
> 
> Meanings of "should" http://www.englishpage.com/modals/should.html My
> first should was the 3rd one
> My second was the 1st one.

Rusi, are you a native English speaker? Because that excuse/defense does 
not excuse your comments at all, multiple meanings of "should" or not. 
Why not just admit to a mistake? After denying you were asking for Python 
to fix a so-called bug, you then called for Python to fix it. If this 
were a real argument rather than a friendly debate, people would be 
crying "Gotcha!" for sure.


> [And we really should stop this argument (2nd one)]

When the facts are against you, argue semantics; when semantics are 
against you, argue the facts; when both are against you, claim to be 
above arguing.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17810

On Dec 23, 8:33 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Fri, 23 Dec 2011 06:57:02 -0800, rusi wrote:
> > On Dec 23, 6:53 pm, Robert Kern <robert.k...@gmail.com> wrote:
> >> On 12/23/11 1:23 PM, rusi wrote:
> [...]
> >> > Of course it should be fixed.  The repeated recurrence of it as a
> >> > standard gotcha as well as the python ideas list testifies to that.
>
> >> So you were lying when you said that you did not ask or imply that it
> >> should be 'fixed'? Please make up your mind. It's quite rude to
> >> "defend" your position by constantly shifting it whenever you get
> >> challenged on it.
>
> > Meanings of "should"http://www.englishpage.com/modals/should.htmlMy
> > first should was the 3rd one
> > My second was the 1st one.
>
> Rusi, are you a native English speaker? Because that excuse/defense does
> not excuse your comments at all, multiple meanings of "should" or not.
> Why not just admit to a mistake? After denying you were asking for Python
> to fix a so-called bug, you then called for Python to fix it. If this
> were a real argument rather than a friendly debate, people would be
> crying "Gotcha!" for sure.

Ok You got me!

Does that help the OP's?

> It's a slick language but I still have trouble wrapping my brain around some of the concepts.

[toc] | [prev] | [next] | [standalone]

#17788

rusi wrote:
> On Dec 23, 7:10 am, alex23 <wuwe...@gmail.com> wrote:
>> On Dec 22, 6:51 pm, Rolf Camps <r...@roce.be> wrote:
>>
>>> I'm afraid it's dangerous to encourage the use of '[]' as assignment to
>>> a parameter in a function definition. If you use the function several
>>> times 'default' always points to the same list.
 >>
>> I appreciate the concern, but adding a default argument guard would
>> not only obscure the code. It's irrelevant, as you recognise, because
>> no matter what, it's going to make copies of the default argument.
>>
>> You know what the say about foolish consistencies :)
> 
> Programming languages can have bugs as much as programs can.
> A classic example is the precedence table of C which Kernighan or
> Ritchie (dont remember which) admitted was wrong.
> 
> Likewise function arguments that default to mutable entities is a
> known gotcha of python which is best treated as a bug in python. It
> should be avoided with the suitable additional circumspection that a
> language bug deserves over a program bug.

That is the most ridiculous thing I have heard in a while.  Mutable 
default arguments are *not* a bug in Python.

Reminds me of a bug report a couple years back claiming multiple 
inheritence was a bug and asking it to be removed.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#17789

On Fri, Dec 23, 2011 at 7:49 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
> That is the most ridiculous thing I have heard in a while.  Mutable default
> arguments are *not* a bug in Python.
>
> Reminds me of a bug report a couple years back claiming multiple inheritence
> was a bug and asking it to be removed.

Both of these could arguably be called misfeaures, but not bugs.

ChrisA

[toc] | [prev] | [next] | [standalone]

#17791

On Dec 23, 2:59 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Dec 23, 2011 at 7:49 PM, Ethan Furman <et...@stoneleaf.us> wrote:
> > That is the most ridiculous thing I have heard in a while.  Mutable default
> > arguments are *not* a bug in Python.
>
> > Reminds me of a bug report a couple years back claiming multiple inheritence
> > was a bug and asking it to be removed.
>
> Both of these could arguably be called misfeatures, but not bugs.
>
> ChrisA

In Fortran, if the comma in the loop
DO 10 I = 1,10
is misspelt as '.' it becomes the assignment
DO10I = 1.0

Do you consider it a bug or a feature?
Does Fortran consider it a bug or feature?

[toc] | [prev] | [next] | [standalone]

#17798 — Timeout when calling COM objects on Windows

Hello there,

I am converting my VB ActiveX application written sometime back in year 2000 with python 1.5.2 to run in python 2.7.1. 

My application is using RMI architecture and I am using a pythonOleRmi.py parser to exchange data/objects between the python and the VB exe. 

I have no issue when my VB EXE is not running as a COM server while making python API calls where my application server is written purely in python and runs on UNIX. However, when my VB EXE is running as a COM server, this code seems hangs when I make the python API same call to the application server. Is there something that I need to change or configure in order to run this successfully? Or to make some security setting on my Windows? (My VB EXE is run on Windows 7 now, will try out if the same issue is encountered on XP next week). 

Is the issue resided in the calling to the local daemon process (10.228.70.137:26000), or it is some security setting depicted in the policy.py file?



Collecting Python Trace Output...
Proxy called with: MatlMgr, getCompatibleFTCSVersions(), (), {}
Dec 23 18:41:21 OleRmiClient     Timeout of 300 seconds occurred on the invocati
on of ('getAppAddress', (u'MatlMgr',), {}) to ('10.228.70.137', 26000)
pythoncom error: Python error invoking COM method.

Traceback (most recent call last):
  File "C:\genesis\Enablers\Python\lib\site-packages\win32com\server\policy.py",
 line 277, in _Invoke_
    return self._invoke_(dispid, lcid, wFlags, args)
  File "C:\genesis\Enablers\Python\lib\site-packages\win32com\server\policy.py",
 line 282, in _invoke_
    return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None)
  File "C:\genesis\Enablers\Python\lib\site-packages\win32com\server\policy.py",
 line 585, in _invokeex_
    return func(*args)
  File "C:\genesis\Product\Lib\PythonOleRmi.py", line 240, in Proxy
    proxy = self._getProxyObj(pyserverString)
  File "C:\genesis\Product\Lib\PythonOleRmi.py", line 223, in _getProxyObj
    None, self._logWriter, rem_admin_addr = remAddr )
  File "C:\genesis\Product\Lib\EComponent.py", line 710, in __init__
    addr = self._getAppProxyAddress()
  File "C:\genesis\Product\Lib\EComponent.py", line 742, in _getAppProxyAddress
    addr = remAdmin.getAppAddress(self.server_name)
  File "C:\genesis\Product\Lib\EComponent.py", line 611, in __call__
    self._method, args, kw )
  File "C:\genesis\Product\Lib\RMI.py", line 1779, in _genericInvocation
    reply = self._requestReply( replyBit, (method_name, args, kw) )
  File "C:\genesis\Product\Lib\RMI.py", line 1585, in _requestReply
    reply = self._receive()
  File "C:\genesis\Product\Lib\RMI.py", line 1677, in _receive
    raise ServerReplyTimeout( self.reply_timeout)
ServerReplyTimeout: 300


Regards,
Wah Meng 

[toc] | [prev] | [next] | [standalone]

#17819

On 12/23/2011 03:31 AM, rusi wrote:
> In Fortran, if the comma in the loop
> DO 10 I = 1,10
> is misspelt as '.' it becomes the assignment
> DO10I = 1.0
> 
> Do you consider it a bug or a feature?
> Does Fortran consider it a bug or feature?

Non sequitor.  Nothing at all to do with the issue at hand.
Furthermore, you are talking about a parser "feature" not a runtime
behavior.

[toc] | [prev] | [next] | [standalone]

#17799

On 2011-12-23, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Dec 23, 2011 at 7:49 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
>> That is the most ridiculous thing I have heard in a while.
>> ?Mutable default arguments are *not* a bug in Python.
>>
>> Reminds me of a bug report a couple years back claiming
>> multiple inheritence was a bug and asking it to be removed.
>
> Both of these could arguably be called misfeaures, but not
> bugs.

Is the misfeature that Python doesn't evaluate the default
argument expression every time you call the function? What would
be the harm if it did?

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#17801

On 2011-12-23, Neil Cerutti <neilc@norwich.edu> wrote:
> Is the misfeature that Python doesn't evaluate the default
> argument expression every time you call the function? What
> would be the harm if it did?

...you know, assuming it wouldn't break existing code. ;)

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#17807 — Early and late binding [was Re: what does 'a=b=c=[]' do]

On Fri, 23 Dec 2011 13:13:38 +0000, Neil Cerutti wrote:

> On 2011-12-23, Neil Cerutti <neilc@norwich.edu> wrote:
>> Is the misfeature that Python doesn't evaluate the default argument
>> expression every time you call the function? What would be the harm if
>> it did?
> 
> ...you know, assuming it wouldn't break existing code. ;)

It will. Python's default argument strategy has been in use for 20 years. 
Some code will rely on it. I know mine does.

There are two strategies for dealing with default arguments that I know 
of: early binding and late binding. Python has early binding: the default 
argument is evaluated once, when the function is created. Late binding 
means the default argument is always re-evaluated each time it is needed.

Both strategies are reasonable choices. Both have advantages and 
disadvantages. Both have use-cases, and both lead to confusion when the 
user expects one but gets the other. If you think changing from early to 
late binding will completely eliminate the default argument "gotcha", you 
haven't thought things through -- at best you might reduce the number of 
complaints, but only at the cost of shifting them from one set of use-
cases to another.

Early binding is simple to implement and simple to explain: when you 
define a function, the default value is evaluated once, and the result 
stored to be used whenever it is needed. The disadvantage is that it can 
lead to unexpected results for mutable arguments.

Late binding is also simple to explain, but a little harder to implement. 
The function needs to store the default value as a piece of code (an 
expression) which can be re-evaluated as often as needed, not an object.

The disadvantage of late binding is that since the expression is live, it 
needs to be calculated each time, even if it turns out to be the same 
result. But there's no guarantee that it will return the same result each 
time: consider a default value like x=time.time(), which will return a 
different value each time it is called; or one like x=a+b, which will 
vary if either a or b are changed. Or will fail altogether if either a or 
b are deleted. This will surprise some people some of the time and lead 
to demands that Python "fix" the "obviously buggy" default argument 
gotcha.

If a language only offers one, I maintain it should offer early binding 
(the status quo). Why? Because it is more elegant to fake late binding in 
an early binding language than vice versa.

To fake late binding in a language with early binding, use a sentinel 
value and put the default value inside the body of the function:

    def func(x, y=None):
        if y is None:
            y = []
        ...

All the important parts of the function are in one place, namely inside 
the function.

To fake early binding when the language provides late binding, you still 
use a sentinel value, but the initialization code creating the default 
value is outside the body of the function, usually in a global variable:

    _DEFAULT_Y = []  # Private constant, don't touch.

    def func(x, y=None):
        if y is None:
            y = _DEFAULT_Y
        ...

This separates parts of the code that should be together, and relies on a 
global, with all the disadvantages that implies.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17808 — Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

On Sat, Dec 24, 2011 at 2:49 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> To fake early binding when the language provides late binding, you still
> use a sentinel value, but the initialization code creating the default
> value is outside the body of the function, usually in a global variable:
>
>    _DEFAULT_Y = []  # Private constant, don't touch.
>
>    def func(x, y=None):
>        if y is None:
>            y = _DEFAULT_Y
>        ...
>
> This separates parts of the code that should be together, and relies on a
> global, with all the disadvantages that implies.

A static variable (in the C sense) would make this just as clean as
the alternative. In Python, that could be implemented as an attribute
of the function object. Oh looky here... that's how default arguments
are implemented. :)

Tim Toady.

ChrisA

[toc] | [prev] | [next] | [standalone]

#17827 — Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

On Sat, 24 Dec 2011 02:55:41 +1100, Chris Angelico wrote:

> On Sat, Dec 24, 2011 at 2:49 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> To fake early binding when the language provides late binding, you
>> still use a sentinel value, but the initialization code creating the
>> default value is outside the body of the function, usually in a global
>> variable:
>>
>>    _DEFAULT_Y = []  # Private constant, don't touch.
>>
>>    def func(x, y=None):
>>        if y is None:
>>            y = _DEFAULT_Y
>>        ...
>>
>> This separates parts of the code that should be together, and relies on
>> a global, with all the disadvantages that implies.
> 
> A static variable (in the C sense) would make this just as clean as the
> alternative. In Python, that could be implemented as an attribute of the
> function object. Oh looky here... that's how default arguments are
> implemented. :)

Yes. But having to manage it *by hand* is still unclean:

* you still have to assign the default value to the function assignment 
outside the function, which is inelegant; 

* if you rename the function, the internal lookup func.default_value will 
fail.

I'm not saying it can't be done. I'm just saying that the status quo is 
cleaner and more elegant, and if you want late binding, there is a 
simple, obvious, elegant idiom to get it.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17829 — Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

On Sat, Dec 24, 2011 at 9:32 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Yes. But having to manage it *by hand* is still unclean:

Well, my point was that Python's current behaviour _is_ that.

> * you still have to assign the default value to the function assignment
> outside the function, which is inelegant;

C's static variables are initialized inside the function. But since
Python doesn't have that, it doesn't really work that way. (You might
be able to use a decorator to do some cool tricks though.)

> * if you rename the function, the internal lookup func.default_value will
> fail.

Python would benefit some from a "current-function" reference, if
tricks like this were to be encouraged. It'd help with recursion too.
hmmmm...

>>> def Y(func):
	return lambda *args,**kwargs: func(func,*args,**kwargs)

>>> @Y
def foo(me,x):
	if x>5: return x
	return me(me,x+1),7,x

>>> foo(3)
(((6, 7, 5), 7, 4), 7, 3)

Useful? Not very. Maybe as a language feature, but not as a parameter.
But of curiosity value.

ChrisA

[toc] | [prev] | [next] | [standalone]

#17835 — Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

On Sat, 24 Dec 2011 09:50:04 +1100, Chris Angelico wrote:

> On Sat, Dec 24, 2011 at 9:32 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Yes. But having to manage it *by hand* is still unclean:
> 
> Well, my point was that Python's current behaviour _is_ that.

Minus the managing it by hand part.


>> * you still have to assign the default value to the function assignment
>> outside the function, which is inelegant;
> 
> C's static variables are initialized inside the function. But since
> Python doesn't have that, it doesn't really work that way. (You might be
> able to use a decorator to do some cool tricks though.)

If Python were C, then static variables would be the right solution, but 
since it isn't, they aren't.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#17812 — Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

In article <4ef4a30d$0$29973$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> The disadvantage of late binding is that since the expression is live, it 
> needs to be calculated each time, even if it turns out to be the same 
> result. But there's no guarantee that it will return the same result each 
> time: consider a default value like x=time.time(), which will return a 
> different value each time it is called

I know this is not quite the same thing, but it's interesting to look at 
what django (and mongoengine) do in their model definitions, prompted by 
your time.time() example.  You can do declare a model field something 
like:

class Foo(models.Model):
   timestamp = DateTimeField(default=datetime.utcnow)

Now, when you create a Foo, if you don't supply a timestamp, it 
generates one by calling utcnow() for you.  Very handy.

I'm not arguing that Python should do that, just pointing out an example 
of where late binding is nice.  Technically, that's probably not really 
late binding.  You always get the same function bound, it's just called 
each time it's used because django notices that you passed a callable.  
Maybe sort of "early binding, late calling" would be a more apt 
description, but given that python has descriptors, the line between 
data and function sometimes gets a little blurry anyway.

[toc] | [prev] | [next] | [standalone]

#17840 — Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

On Dec 24, 2:15 am, Roy Smith <r...@panix.com> wrote:
> I know this is not quite the same thing, but it's interesting to look at
> what django (and mongoengine) do in their model definitions, prompted by
> your time.time() example.  You can do declare a model field something
> like:
>
> class Foo(models.Model):
>    timestamp = DateTimeField(default=datetime.utcnow)
>
> Now, when you create a Foo, if you don't supply a timestamp, it
> generates one by calling utcnow() for you.  Very handy.
>
> I'm not arguing that Python should do that, just pointing out an example
> of where late binding is nice.

There is absolutely nothing stopping you from writing functions now
with that behaviour. All Python functions are "early binding, late
calling" with their arguments, if you treat the arguments as callables
within the function body.

[toc] | [prev] | [next] | [standalone]

#17814 — Re: Early and late binding [was Re: what does 'a=b=c=[]' do]

Steven D'Aprano wrote:
> On Fri, 23 Dec 2011 13:13:38 +0000, Neil Cerutti wrote:
>> On 2011-12-23, Neil Cerutti <neilc@norwich.edu> wrote:
>> ...you know, assuming it wouldn't break existing code. ;)
> 
> It will. Python's default argument strategy has been in use for 20 years.
> Some code will rely on it. I know mine does.

In a tool that's meant for other people to use to accomplish work of their 
own, breaking workflow is a cardinal sin.

In a research language that's meant always to be up-to-date with the concept 
of the week, not so much.

	Mel.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web