On Sun, May 10, 2015 at 9:25 PM, Dave Angel wrote:
> On 05/09/2015 11:33 PM, Chris Angelico wrote:
>> What you could have is "late-binding semantics, optional early binding
>> as an optimization but only in cases where the result is
>> indistinguishable". That would allow common cases (int/bool/st
On 05/09/2015 11:33 PM, Chris Angelico wrote:
On Sun, May 10, 2015 at 12:45 PM, Steven D'Aprano
wrote:
This is the point where some people try to suggest some sort of complicated,
fragile, DWIM heuristic where the compiler tries to guess whether the user
actually wants the default to use early
(To clarify, I am *not* talking about this as a change to Python, so
all questions of backward compatibility are immaterial. This is "what
happens if we go back in time and have Python use late binding
semantics". This is the "alternate 1985" of Back to the Future.)
On Sun, May 10, 2015 at 3:20 PM
On Sun, 10 May 2015 01:35 pm, Rustom Mody wrote:
> On Sunday, May 10, 2015 at 8:16:07 AM UTC+5:30, Steven D'Aprano wrote:
>> I predict that the majority of the time, late binding would just be a
>> pointless waste of time:
>>
>> def process_string(thestr, start=0, end=None, slice=1, reverse=True)
On Sun, 10 May 2015 01:33 pm, Chris Angelico wrote:
> On Sun, May 10, 2015 at 12:45 PM, Steven D'Aprano
> wrote:
>> This is the point where some people try to suggest some sort of
>> complicated, fragile, DWIM heuristic where the compiler tries to guess
>> whether the user actually wants the defa
On Sunday, May 10, 2015 at 8:16:07 AM UTC+5:30, Steven D'Aprano wrote:
> I predict that the majority of the time, late binding would just be a
> pointless waste of time:
>
> def process_string(thestr, start=0, end=None, slice=1, reverse=True):
> pass
>
> Why would you want 0, None, 1 and True
On Sun, May 10, 2015 at 12:45 PM, Steven D'Aprano
wrote:
> This is the point where some people try to suggest some sort of complicated,
> fragile, DWIM heuristic where the compiler tries to guess whether the user
> actually wants the default to use early or late binding, based on what the
> expres
On Sat, 9 May 2015 01:50 am, Michael Welle wrote:
[...]
>> How about this definition:
>>
>> default = 23
>> def spam(eggs=default):
>> pass
>>
>> del default
>>
>> print spam()
>>
>>
>> Do you expect the function call to fail because `default` doesn't exist?
>
> If I refer
On Fri, May 8, 2015 at 9:50 AM, Michael Welle wrote:
>
> Steven D'Aprano writes:
>>
>> If your language uses late binding, it is very inconvenient to get early
>> binding when you want it. But if your language uses early binding, it is
>> very simple to get late binding when you want it: just put
Chris Angelico wrote:
So no, it
isn't proof - it's equally well explained by the code object being
constant.
I suppose, strictly speaking, that's true -- but
then the code object *might as well* be created
at compile time, since the semantics are identical.
In any case, it's easy to see from
On Sat, 9 May 2015 03:49 am, Chris Angelico wrote:
> On Sat, May 9, 2015 at 3:36 AM, Steven D'Aprano
> wrote:
>> On Sat, 9 May 2015 02:02 am, Chris Angelico wrote:
>>> Aside from constructing two closures in the same context and proving
>>> that their __code__ attributes point to the same object,
On Sat, May 9, 2015 at 11:41 AM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> How do you know that the function's code
>> object was created when compile() happened, rather than being created
>> when the function was defined?
>
>
> Python 3.4.2 (default, Feb 4 2015, 20:08:25)
> [GCC 4.2.1 (
Chris Angelico wrote:
How do you know that the function's code
object was created when compile() happened, rather than being created
when the function was defined?
Python 3.4.2 (default, Feb 4 2015, 20:08:25)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or
On Sat, 09 May 2015 03:49:36 +1000, Chris Angelico wrote:
> Yes, but can you *distinguish* them in terms of default argument versus
> code object creation? How do you know that the function's code object
> was created when compile() happened, rather than being created when the
> function was defin
On Sat, May 9, 2015 at 3:36 AM, Steven D'Aprano
wrote:
> On Sat, 9 May 2015 02:02 am, Chris Angelico wrote:
>> Aside from constructing two closures in the same context and proving
>> that their __code__ attributes point to the same object, is there any
>> way to distinguish between "code object co
On Sat, 9 May 2015 02:02 am, Chris Angelico wrote:
> On Sat, May 9, 2015 at 1:48 AM, Ian Kelly wrote:
>> On May 8, 2015 9:26 AM, "Steven D'Aprano"
>> wrote:
>>>
>>> Do you think that Python will re-compile the body of the function every
>>> time
>>> you call it? Setting the default is part of th
On Sat, 9 May 2015 01:48 am, Ian Kelly wrote:
> On May 8, 2015 9:26 AM, "Steven D'Aprano" <
> steve+comp.lang.pyt...@pearwood.info> wrote:
>>
>> Do you think that Python will re-compile the body of the function every
> time
>> you call it? Setting the default is part of the process of compiling th
On Sat, May 9, 2015 at 1:48 AM, Ian Kelly wrote:
> On May 8, 2015 9:26 AM, "Steven D'Aprano"
> wrote:
>>
>> Do you think that Python will re-compile the body of the function every
>> time
>> you call it? Setting the default is part of the process of compiling the
>> function.
>
> To be a bit peda
On May 8, 2015 9:26 AM, "Steven D'Aprano" <
steve+comp.lang.pyt...@pearwood.info> wrote:
>
> Do you think that Python will re-compile the body of the function every
time
> you call it? Setting the default is part of the process of compiling the
> function.
To be a bit pedantic, that's not accurate
On Fri, 8 May 2015 09:59 pm, Michael Welle wrote:
> Hello,
>
> assume the following function definition:
>
> def bar(foo = []):
> print("foo: %s" % foo)
> foo.append("foo")
>
> It doesn't work like one would expect (or as I would expect ;-)). As I
> understand it the assignment of the e
On Fri, May 8, 2015 at 9:59 PM, Michael Welle wrote:
> Hello,
>
> assume the following function definition:
>
> def bar(foo = []):
> print("foo: %s" % foo)
> foo.append("foo")
>
> It doesn't work like one would expect (or as I would expect ;-)). As I
> understand it the assignment of the e
On Friday, May 8, 2015 at 5:30:15 PM UTC+5:30, Michael Welle wrote:
> Hello,
>
> assume the following function definition:
>
> def bar(foo = []):
> print("foo: %s" % foo)
> foo.append("foo")
>
> It doesn't work like one would expect (or as I would expect ;-)). As I
> understand it the as
22 matches
Mail list logo
