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

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

Default Value

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

Contents

  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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#48892

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 ismutable(arg). The implementation of ismutable is 
just an implementation detail, somebody else can work that out. A 
language designer of the sheer genius of Rick can hardly be expected to 
worry himself about such trivial details.



-- 
Steven

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

#48897

On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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 you'd know that the
>> argument was mutable.
>
> That's easy. Just call ismutable(arg). The implementation of ismutable is
> just an implementation detail, somebody else can work that out. A
> language designer of the sheer genius of Rick can hardly be expected to
> worry himself about such trivial details.

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.

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

#48910

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. languages sometimes things that look laughably easy can turn out HARD.

As a personal example of a time I found myself in Rick's shoes:

I was lecturing to some audience on the glories of FP. Someone asked me how efficient such a language would be.  I replied (rather cock-surely) that efficiency is not a property of languages but of implementations.

So someone got up and asked me: Ok lets say I add a new value-space to your language -- propositions, and a new operator -- sat -- that checks whether a proposition is satisfiable...

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

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

#48914

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

So now you're going to attempt to defeat my idea by
suggesting that it chalks up to nothing more than a safety
measure? How many times must i explain the simple concept
of stateless subroutines and hazards of the current 
incarnation Python FUNCtions (You smell the func!)

Yes you gain safety by utilizing such an implementation 
over the current implementation, however you also trim
a negative attribute of the language. Not to mention the
intuitive and readability gains.

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

#48917

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 who think
> > Haskell is safe. Safer (than something or other) -- Ok
> > Safe -- NO
> 
> 
> So now you're going to attempt to defeat my idea by
> suggesting that it chalks up to nothing more than a safety
> measure? How many times must i explain the simple concept
> of stateless subroutines and hazards of the current 
> incarnation Python FUNCtions (You smell the func!)

I appreciate Rick that you are committed to a better programming language.
And you too need to appreciate that many intelligent and capable people for the last 50 years have had similar goals.  When those goals are soft eg strictures on cohesion and coupling -- which is what your wish for stateless procedures amounts to -- then those remain suggestions and cannot be imposed.
When those goals are made hard as in functional programming then other problems result such as performance hits, what-to-do-about-IO etc etc.

See my blog
http://blog.languager.org/2012/11/imperative-programming-lessons-not.html
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 practised in the human sphere even if not implemented in the programming language sphere.  The aggregation of such 'best-practices' is what I call FP as an ideology rather than as technology.
I have a collection here 
http://blog.languager.org/2012/10/functional-programming-lost-booty.html
And I would welcome suggestions/discussions on the same.

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

#48926

> 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
> practised in the human sphere even if not implemented in
> the programming language sphere.  The aggregation of such
> 'best-practices' is what I call FP as an ideology rather
> than as technology. 
>
> I have a collection here [...]
> And I would welcome suggestions/discussions on the same.

Here are some statements from your blog, i have made a few
tweaks to the text (mainly structure) so as to render it
more readable. 

> Unfortunately these are the exceptions.  In the vast
> majority of cases, the quest for generalities only
> produces rubbish. So lets see how the... The Philosophy of
> OO fares in this regard.
> 
> OO starts off its philosophical sojourn with the dogma:
> Everything is an object I will start with a variation that
> is slightly less nonsensical but easier to debunk;
> Everything can be modeled as a class
> 
> Now if we start looking at the justifications of this
> statement we would find certain methodological directives
> such as Identify the nouns in the use-case and make them
> classes In itself this is - as a methodology - not
> objectionable.
> 
> So for example if we are presented with the standard
> example of a customer coming to an ATM and making a
> transaction, this methodology tells us that it may be a
> good idea to make customer and ATM into classes - so far
> so good.
> 
> And what about transaction? Yes we could make it into a
> class also, but as we shall see, blanket- adding the set
> of abstract nouns into the set of common nouns as class-
> ifiable objects gets us into trouble.

No, the transaction itself need NOT be a custom object.

> 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 methodology - we need to
> make performance, response-time and even customer-
> satisfaction(!!) into classes.

LOL! 

Only a fool, or a religious OOP extremist, would create
custom objects for such things. Although, if he were forced
to use Java, he wouldn't have any choice would he? Poor
basterd! >:D

But my point is, OOP is not a cure-all for every problem, in
fact, it can overly complicate many problems. For instance,
being forced to write an object definition for a simple hello
world program in Java is nothing less than pure sadism --
but that's why i don't use Java unless i'm forced!

OTOH, from skimming a few other threads in your blog, you
seem to long for some salvation of FP to save all our souls
from the eternal damnation of IP, like a Christian
longing for the second coming of Christ!

 "Take us away to streets paved in gold!"

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
honing practical *real world* skill sets. 

    ########################################################
    #                    Tip of the Day                    #
    ########################################################
    # Remember, whilst the professor's tenure will         #
    # guarantee he gets a paycheck even for producing      #
    # rubbish, you won't be afforded such luxuries in the  #
    # real world.                                          #
    ########################################################

 "If it IS to be, then it's up to ME"

The point is, no one paradigm is going to save us from the
devil. We must take from each style it's positive
attributes, and reject it's negative attributes. The art of
intelligently applying multiple paradigms to solve complex
problems should be held up as the pinnacle of greatness. If
your going to worship something, worship achievement.

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

#48928

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 methodology - we need to
> > make performance, response-time and even customer-
> > satisfaction(!!) into classes.
> 
> LOL! 
> 
> Only a fool, or a religious OOP extremist, would create
> custom objects for such things. Although, if he were forced
> to use Java, he wouldn't have any choice would he? Poor
> basterd! >:D

Shall I quote something of yours to Steven about "the ability to recognize sarcasm?"

On a more serious note, Ian's terminate function, or Chris' bug-free function which is the same by Rice theorem are different variants of the same thing:  some of the most key things of concern to the programmer cannot be modeled/reified into his program.


> The point is, no one paradigm is going to save us from the
> devil. We must take from each style it's positive
> attributes, and reject it's negative attributes. The art of
> intelligently applying multiple paradigms to solve complex
> problems should be held up as the pinnacle of greatness. If
> your going to worship something, worship achievement.

Ok -- I agree.

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

#48932

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
> honing practical *real world* skill sets. 
> 
> 
>     ########################################################
>     #                    Tip of the Day                    #
>     ########################################################
>     # Remember, whilst the professor's tenure will         #
>     # guarantee he gets a paycheck even for producing      #
>     # rubbish, you won't be afforded such luxuries in the  #
>     # real world.                                          #
>     ########################################################

Here are some examples for your kind consideration. 
[Something I wrote a few days back with a few additions]

Comprehensions and lambdas have come into python. From where? Haskell
[Lambdas have even got into C++ !!]
LINQ in C#  inspired by comprehensions
Generics were not there in C# and Java early editions.  Now they've
been retrofitted -- Origin SML.
Almost every modern language supports garbage collection. Origin Lisp
Numpy is just APL with python syntax
Hottest DBMSes today are the nosql ones -- couchdb written in erlang.
Knuth - Vol 1 is a gigantic exercise on how to do lisp without lisp.
Also called Greenspun's 10th law: http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming

And heard of google? Uses something called map-reduce. Route: APL -> FPLs -> google

Yes FP is very academic -- for those living in the last century.

I just assumed we are all in 2013 :-)

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

#49049

On 2013-06-22, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
><steve+comp.lang.python@pearwood.info> 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 you'd know that the
>>> argument was mutable.
>>
>> That's easy. Just call ismutable(arg). The implementation of ismutable is
>> just an implementation detail, somebody else can work that out. A
>> language designer of the sheer genius of Rick can hardly be expected to
>> worry himself about such trivial details.
>
> 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 think it should be terminate_time() -- so you can also find out how
long it's going to run.  It can return None if it's not going to
terminate...

-- 
Grant Edwards               grant.b.edwards        Yow! I'm continually AMAZED
                                  at               at th'breathtaking effects
                              gmail.com            of WIND EROSION!!

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

#49053 — Re: [SPAM] Re: Default Value

On 24/06/2013 15:22, Grant Edwards wrote:
> On 2013-06-22, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
>><steve+comp.lang.python@pearwood.info> 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 you'd know that the
>>>> argument was mutable.
>>>
>>> That's easy. Just call ismutable(arg). The implementation of ismutable is
>>> just an implementation detail, somebody else can work that out. A
>>> language designer of the sheer genius of Rick can hardly be expected to
>>> worry himself about such trivial details.
>>
>> 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 think it should be terminate_time() -- so you can also find out how
> long it's going to run.  It can return None if it's not going to
> terminate...
>
Surely that should be float("inf")! Anything else would be ridiculous!
:-)

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

#48899

On Sat, Jun 22, 2013 at 11:27 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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 you'd know that the
>>> argument was mutable.
>>
>> That's easy. Just call ismutable(arg). The implementation of ismutable is
>> just an implementation detail, somebody else can work that out. A
>> language designer of the sheer genius of Rick can hardly be expected to
>> worry himself about such trivial details.
>
> 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
purity, and most people know their functions will terminate (that's
what Ctrl-C is for). No, I want a function isbuggy(f) to find out
whether a function is, well, buggy. We could abolish all unit-testing
if we had that.

ChrisA

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

#48913

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
> purity, and most people know their functions will terminate (that's
> what Ctrl-C is for). No, I want a function isbuggy(f) to find out
> whether a function is, well, buggy. We could abolish all unit-testing
> if we had that.

That's awesome.  I laughed out loud when I read Ian's comment, though it
took me longer than I should have needed to notice your tongue firmly in
your cheek as well.

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

#48925

Op 22-06-13 03:27, Ian Kelly schreef:
> On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info>  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 you'd know that the
>>> argument was mutable.
>>
>> That's easy. Just call ismutable(arg). The implementation of ismutable is
>> just an implementation detail, somebody else can work that out. A
>> language designer of the sheer genius of Rick can hardly be expected to
>> worry himself about such trivial details.
>
> 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.

Are you two guys now egging on Rick Johnson?

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

#48934

On Fri, 21 Jun 2013 19:27:42 -0600, Ian Kelly <ian.g.kelly@gmail.com>
declaimed the following:

>On Fri, Jun 21, 2013 at 7:15 PM, Steven D'Aprano
><steve+comp.lang.python@pearwood.info> 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 you'd know that the
>>> argument was mutable.
>>
>> That's easy. Just call ismutable(arg). The implementation of ismutable is
>> just an implementation detail, somebody else can work that out. A
>> language designer of the sheer genius of Rick can hardly be expected to
>> worry himself about such trivial details.
>
>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.

	Maybe in a universe with different physical constants...

	Otherwise I think you have encountered
http://en.wikipedia.org/wiki/Halting_problem (consider: could your function
conclude that it terminates when fed it's own code)

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#48941

On Sat, Jun 22, 2013 at 10:49 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Fri, 21 Jun 2013 19:27:42 -0600, Ian Kelly <ian.g.kelly@gmail.com>
> 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 actually call it.
>
>         Maybe in a universe with different physical constants...
>
>         Otherwise I think you have encountered
> http://en.wikipedia.org/wiki/Halting_problem (consider: could your function
> conclude that it terminates when fed it's own code)

Yes, that was the joke.

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

#48951

On Sat, 22 Jun 2013 12:57:07 -0600, Ian Kelly <ian.g.kelly@gmail.com>
declaimed the following:

>On Sat, Jun 22, 2013 at 10:49 AM, Dennis Lee Bieber
><wlfraed@ix.netcom.com> wrote:
>> On Fri, 21 Jun 2013 19:27:42 -0600, Ian Kelly <ian.g.kelly@gmail.com>
>> 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 actually call it.
>>
>>         Maybe in a universe with different physical constants...
>>
>>         Otherwise I think you have encountered
>> http://en.wikipedia.org/wiki/Halting_problem (consider: could your function
>> conclude that it terminates when fed it's own code)
>
>Yes, that was the joke.

	Given some of the personalities here, making sure the irony was
revealed could be useful...

	Yes, I suspected it was humor... Some might have taken it literally.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#48890

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 passed a mutable argument as a
>> default value in a def statement? E.g. this:
>>
>>   >>> a = [1, 2, 3]
>>   >>> a.append(a)
>>   >>> b = object()
>>   >>> def f(x = [None, b, [a, [4]]]):
>> ...     pass # do something
>>
>> What would you like to see the interpreter do in this case?
>
> Ignoring that this is a completely contrived example that has
> no use in the real world, here are one of three methods by
> which i can handle this:

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). I asked what would happen 
in /your/ version of Python. Which of the alternatives that you present 
would have been implemented, if you had designed the language?


> ============================================================
>   The Benevolent Approach:
> ============================================================
> 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 mutable default arguments allowed!

So how does the interpreter know whether an arbitrary object passed as a 
default value is mutable or not?

Not that it really matters. Elsewhere in this thread you wrote:

> Let's imagine for a second if Python allowed mutable keys in
> a dictionary,

which it does

> 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!

Now, I don't really believe that you think that the user shouldn't be 
protected from doing one idiotic thing with mutable dict keys but should 
be protected from doing another idiotic thing with mutable default 
arguments, especially as you've already been given a use case for the 
latter. So I assume that The Benevolent Approach is not the approach you 
would have gone for if you had designed the language, right? If so then 
let's ignore it.


> ============================================================
>   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 then mutates the mutable later, too
> bad, he'll understand the value of writing solid code after
> a few trips to exception Hell.

It seems to me that this is exactly what currently happens.


> ============================================================
>   The Malevolent Approach (disguised as beneva-loon-icy):
> ============================================================
> I could use early binding to confuse the hell out of him and
> enjoy the laughs with all my ivory tower buddies as he falls
> into fits of confusion and rage. Then enjoy again when he
> reads the docs. Ahh, the gift that just keeps on giving!

My question was about how you think the language should work, not about 
what your buddies should or shouldn't enjoy. In terms of how a language 
actually works, is there any difference between The Malevolent Approach 
and The Apathetic Approach? And is there any difference between either 
of them and what Python currently does?


> ============================================================
>   Conclusion:
> ============================================================
> As you can probably guess the malevolent approach has some
> nice fringe benefits.
>
> 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 -- at least not one that CANNOT be
> reproduced by using my fine examples.

Of course using a mutable default as a cache can be reproduced by other 
means, as can another common use case that I don't think anyone's 
mentioned yet (defining functions parametrised by variables whose values 
aren't known until runtime). That's hardly an argument against it - you 
might as well argue that Python shouldn't have decorators, or that it 
shouldn't have for loops because their behaviour can be reproduced with 
while loops.

But this is beside the point anyway, until you present an alternative to 
Python's current behaviour. If you do so then we can start debating the 
relative merits of the two approaches.

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

#48893

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). I asked what would happen in /your/ version of
> Python. Which of the alternatives that you present would
> have been implemented, if you had designed the language?

The apathetic approach. However, you fail to understand that
whilst Python's current implementation is partly apathetic,
is is also benevolent, and malevolent simultaneously. My
approach is purely apathetic. I'll explain later. Stay
tuned.

> [...]
> So how does the interpreter know whether an arbitrary
> object passed as a default value is mutable or not? Not
> that it really matters.

Well i'm glad it does not matter to you because it does not
matter to me either. *shrugs*

> > 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 = {[1]:2}
    Traceback (most recent call last):
      File "<pyshell#0>", line 1, in <module>
        d = {[1]:2}
    TypeError: unhashable type: 'list'
    # Symbol
    py> lst = [1]
    py> d = {lst:2}
    Traceback (most recent call last):
      File "<pyshell#2>", line 1, in <module>
        d = {lst:2}
    TypeError: unhashable type: 'list'

Hmm, maybe only certain mutables work? Great, more esoteric
rules! Feel free to enlighten me since i'm not going to
waste one second of my time pursuing the docs just to learn
about ANOTHER unintuitive PyWart i have no use for.

> Now, I don't really believe that you think that the user
> shouldn't be protected from doing one idiotic thing with
> mutable dict keys but should be protected from doing
> another idiotic thing with mutable default arguments,
> especially as you've already been given a use case for the
> latter. So I assume that The Benevolent Approach is not
> the approach you would have gone for if you had designed
> the language, right? If so then let's ignore it.

You are correct. Finally, we can agree on something.

> > ============================================================
> >   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 then mutates the mutable later, too
> > bad, he'll understand the value of writing solid code after
> > a few trips to exception Hell.
>
> It seems to me that this is exactly what currently happens.

(is this lazy readers day? I swear i explained this earlier)

And here is where you are wrong. In the current implementation
python functions carry the state of mutable default arguments
between successive calls. That's a flaw. Observe:

    py> def foo(arg=[]):
    ...     arg.append(1)
    ...     print(arg)
    ...
    py> foo()
    [1]
    py> foo()
    [1, 1]
    py> foo()
    [1, 1, 1]

No, no, NO! That's wrong! Subroutines should be stateless.
That means that an empty mutable default argument will
ALWAYS be empty at each call of the subroutine.  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 intuitive! That is sane! Now, what if
we pass a reference to a mutable object? What then. Well, let's
see:

    py> lst = range(5)
    py> lst
    [0, 1, 2, 3, 4]
    py> def foo(arg=lst):
    ...     arg.append(1)
    ...     print(arg)
    ...
    py> foo()
    [0, 1, 2, 3, 4, 1]
    py> foo()
    [0, 1, 2, 3, 4, 1, 1]

That's fine. Because the object was already created OUTSIDE
the subroutine. So therefore, modifications to the mutable
are not breaking the fundamental of statelessness INSIDE
subroutines. The modification is merely a side effect, and
the subroutine is unconcerned with anything that exists
beyond it's own scope.

IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND?

> > ============================================================
> >   The Malevolent Approach (disguised as beneva-loon-icy):
> > ============================================================
> > I could use early binding to confuse the hell out of him and
> > enjoy the laughs with all my ivory tower buddies as he falls
> > into fits of confusion and rage. Then enjoy again when he
> > reads the docs. Ahh, the gift that just keeps on giving!
> My question was about how you think the language should
> work, not about what your buddies should or shouldn't
> enjoy.

My buddies? This design flaw is NOT my brain child. Your
barking up the wrong tree pal.

> In terms of how a language actually works, is there
> any difference between The Malevolent Approach and The
> Apathetic Approach? And is there any difference between
> either of them and what Python currently does?

I explained this to MRAB already.

> Of course using a mutable default as a cache can be
> reproduced by other means, as can another common use case
> that I don't think anyone's mentioned yet (defining
> functions parametrised by variables whose values aren't
> known until runtime). That's hardly an argument against it
> - you might as well argue that Python shouldn't have
> decorators, or that it shouldn't have for loops because
> their behaviour can be reproduced with while loops.

Nice attempt at sleight of hand but your logic is clumsy.

Your trying to argue that my use of a "custom callable state
object" (to avoid the esoteric and unintuitive nature of the
current implementation of Python "mutable function
arguments") is somehow only a mere reproduction of the
function behavior and has no positive benefits, when in
fact, it has a HUGE direct benefit:

 * AVOIDING A FLAW IN THE LANGUAGE

It also has quite a few positive side effects:

 * CODE ENCAPSULATION
 * INTERFACE
 * USING THE CORRECT TOOL FOR THE JOB++
 * READABILITY
 * NO HIDDEN SURPRISES
 * LESS BUGGY

How much more justification do you need?

> or that it shouldn't have for loops because their
> behaviour can be reproduced with while loops.

Yes, iterating a sequence can be achieved using a "while
loop", but "for loops" should not be thrown out because they
offer a specific type of iteration that nicely complements a
while loop. Plus, for loops do not have any strange side
effects (unlike Python functions). They do one thing and
they do damn well! So stop picking on for loops :-)

I want Python functions to also "do one thing and do it
well", and what is that "one thing" you ask, execute
subprograms.

> But this is beside the point anyway, until you present an
> alternative to Python's current behavior. If you do so
> then we can start debating the relative merits of the two
> approaches.

The fix is simple. No more "magical Python functions", only
stateless routines. I've explained this ad nauseam already,
and until you provide more specific questions on the matter,
i refuse to reply to any more bombastically general questions.

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

#48896

On Sat, Jun 22, 2013 at 11:15 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
>     # Literal
>     py> d = {[1]:2}
>     Traceback (most recent call last):
>       File "<pyshell#0>", line 1, in <module>
>         d = {[1]:2}
>     TypeError: unhashable type: 'list'
>     # Symbol
>     py> lst = [1]
>     py> d = {lst:2}
>     Traceback (most recent call last):
>       File "<pyshell#2>", line 1, in <module>
>         d = {lst:2}
>     TypeError: unhashable type: 'list'
>
> Hmm, maybe only certain mutables work? Great, more esoteric
> rules! Feel free to enlighten me since i'm not going to
> waste one second of my time pursuing the docs just to learn
> about ANOTHER unintuitive PyWart i have no use for.

>>> class HashableList(list):
	def __hash__(self):
		return 42

>>> a=HashableList()
>>> a
[]
>>> a.append(1)
>>> a.append(2)
>>> a.append(3)
>>> a
[1, 2, 3]
>>> d={a:123}
>>> d
{[1, 2, 3]: 123}
>>> a.append(4)
>>> d[a]
123

It's nothing to do with mutability, all to do with hashability. And
you can pick a number of different ways of hashing these objects, like
going for the object's id(), or attempting to hash tuple(self) and
falling back on id(), or anything you like. Easy.

ChrisA

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

#48901

On Fri, Jun 21, 2013 at 7:37 PM, Chris Angelico <rosuav@gmail.com> wrote:
>>>> class HashableList(list):
>         def __hash__(self):
>                 return 42

Hey, we both picked exactly the same example!

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

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

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

csiph-web