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

#48874

On Fri, 21 Jun 2013 11:26:39 -0700, Rick Johnson wrote:

> You know, out of all these post, not one of you guys has presented a
> valid use-case that will give validity to the existence of this PyWart

LOL.

Okay, you're trolling. Time for another month in the kill-file.

*plonk*


-- 
Steven

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

#48876

On Friday, June 21, 2013 1:37:13 PM UTC-5, Steven D'Aprano wrote:
> Okay, you're trolling. Time for another month in the kill-file. 
> *plonk*

That's so typical of you. You start losing an argument, and
when you have no remaining counter arguments, you resort to
name calling. Why am i not surprised? You wanna see some
trolling?

Is this all you can conjure Steven "Sauron" D'Aprano? 

... A FEW MINDLESS ORCS?

I have defeated your orcs, and your cave trolls. I have
defeated you in my darkest hour in the keep. I have thrown
out that despot from the white city, i have even slain your
Nazgul. Heck, my little sister killed your witch king.

...AND STILL YOU THINK YOU CAN DEFEAT ME!

And now, here i stand, at the foot of the mountain of doom,
with the ring of *POWER* in my hand, and i shall cast it
into the fires from whence it came!

...WHO WILL STOP ME?

All you have remaining is your beloved "gollom van rossum"
and he has already defeated himself with his blind devotion
to this despicable ring. A ring that represents illogical
and inconsistent design philosophies. A philosophy that he
himself cannot defend.

Free my people from this plague of darkness, and cast light
on these atrocities so that the sun may bleach this language
and this community clean, and maybe we'll let you visit the
shire. 

...MAYBE!

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

#48880

On Friday, June 21, 2013 2:18:27 PM UTC-5, Rick Johnson wrote:
> On Friday, June 21, 2013 1:37:13 PM UTC-5, Steven D'Aprano wrote:
> 
> > Okay, you're trolling.

Steven, you wouldn't know "trolling" even if you were an honorary salad tosser at a troll face-sitting contest.

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

#48875

On Sat, Jun 22, 2013 at 4:26 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I could cast a "virtual net" over my poor lemmings before
> they jump off the cliff by throwing an exception:
>
>   Traceback (most recent screw-up last):
>    Line BLAH in SCRIPT
>     def f(x = [None, b, [a, [4]]]):
>   ArgumentError: No mutable default arguments allowed!

So tell me, oh Great and Powerful Wizard of Rick, how is the
interpreter supposed to know which defaults are mutable? I mean, it's
obviously some intrinsic property of the object. Somehow one thing is
clearly immutable, another thing clearly isn't. Will there be a
PyObject_IsImmutable() API?

Oh! I know. Function argument defaults will now be restricted to
int/float/tuple. That would do it, right? Nobody would be bothered by
little restrictions like that, would they.

ChrisA

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

#48877

On 2013-06-21, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Jun 22, 2013 at 4:26 AM, Rick Johnson
><rantingrickjohnson@gmail.com> wrote:
>> I could cast a "virtual net" over my poor lemmings before
>> they jump off the cliff by throwing an exception:
>>
>>   Traceback (most recent screw-up last):
>>    Line BLAH in SCRIPT
>>     def f(x = [None, b, [a, [4]]]):
>>   ArgumentError: No mutable default arguments allowed!
>
> So tell me, oh Great and Powerful Wizard of Rick, how is the
> interpreter supposed to know which defaults are mutable? I
> mean, it's obviously some intrinsic property of the object.
> Somehow one thing is clearly immutable, another thing clearly
> isn't. Will there be a PyObject_IsImmutable() API?
>
> Oh! I know. Function argument defaults will now be restricted
> to int/float/tuple. That would do it, right? Nobody would be
> bothered by little restrictions like that, would they.

I've been around here long enough to have even participated in
one of these discussions before.

Rick, it's not a wart, It's a gotcha.

The reason it's a gotcha is this: In order to predict what will
happen correctly, you have to have mastered three separate Python
concepts.

1. How name-binding works.
2. How argument passing works, i.e., via name-binding.
3. When default arguments are evaluated.
4. The Python object model.

OK, you have to know four things. Curses! I'll come in again.

-- 
Neil Cerutti

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

#48881

On Friday, June 21, 2013 2:20:22 PM UTC-5, Neil Cerutti wrote:
> Rick, it's not a wart, It's a gotcha. The reason it's a
> gotcha is this: In order to predict what will happen
> correctly, you have to have mastered three separate Python
> concepts.
>
> 1. How name-binding works.
> 2. How argument passing works, i.e., via name-binding.
> 3. When default arguments are evaluated.
> 4. The Python object model.

I understand all these concepts in a Python context quite
well, but understanding a PyWart is no validation for it's
continued existence. 

You probably understand the common cold quite well. If you
do you'll wash your hands before eating, and avoid exposure
to sick people.

 THAT'S CALLED A WORKAROUND!

But disease is not yet fully under human control, we are
forced to used the workaround. Whereas, languages are. So
designing a language poorly and then getting upset because
people don't praise your clunky work-around is ludicrous.

 Psst: THE PROBLEM IS SELF-INDUCED!

Mankind, the only creature dumb enough to self-induce his
own hardships -- somewhere a higher intelligence must be
laughing... or crying, who knows. *sigh*

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

#48895

On Sat, 22 Jun 2013 05:07:59 +1000, Chris Angelico wrote:

> Oh! I know. Function argument defaults will now be restricted to
> int/float/tuple. That would do it, right? Nobody would be bothered by
> little restrictions like that, would they.

Alas, tuples won't do it. Fortunately, you can include str and bytes 
(unicode and str) and frozenset in the "Good List". Tuples have to go 
into the "Bad List" because, although they themselves are immutable, 
their contents may not be. Imagine the confusion and horror that poor 
developers will experience when they do something like this:

def func(arg, extra=(23, 'foo', [])):
    [code goes here...]
    extra[2].append("something")
    [more code...]


and they've now mutated the immutable default!

Thinking about this, I think that the only safe thing to do in Rickython 
4000 is to prohibit putting mutable objects inside tuples. Putting a list 
or a dict inside a tuple is just a bug waiting to happen!

-- 
Steven

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

#48898

On Sat, Jun 22, 2013 at 11:31 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Thinking about this, I think that the only safe thing to do in Rickython
> 4000 is to prohibit putting mutable objects inside tuples. Putting a list
> or a dict inside a tuple is just a bug waiting to happen!

I think you're onto something here, but you really haven't gone far
enough. Mutable objects *anywhere* are a problem. The solution?
Abolish mutable objects. Strings (bytes and Unicode), integers,
decimals (floats are a problem to many people), tuples of the above,
and dictionaries mapping any of the above to any other of the above,
should be enough to do everything.

ChrisA

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

#48900

On Friday, June 21, 2013 8:31:35 PM UTC-5, Steven D'Aprano wrote:
> Tuples have to go into the "Bad List" because, although
> they themselves are immutable, their contents may not be.
> Imagine the confusion and horror that poor developers will
> experience when they do something like this:
> 
> def func(arg, extra=(23, 'foo', [])):
>     [code goes here...]
>     extra[2].append("something")
>     [more code...]
>
> and they've now mutated the immutable default! Thinking
> about this, I think that the only safe thing to do in
> Rickython 4000 is to prohibit putting mutable objects
> inside tuples. Putting a list or a dict inside a tuple is
> just a bug waiting to happen!

Geezsus, the warts in this language are innumerable! 

So what your saying is that Python Tuples are "immutable"
like automobiles passengers are "immutable". Sure you can
design the car for a maximum number of passengers, but as
soon as the circus clowns show up, all bets are off!

This whole language is a joke! It just some sick joke! ROTF

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

#48906

On 22/06/2013 02:40, Chris Angelico wrote:
> On Sat, Jun 22, 2013 at 11:31 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Thinking about this, I think that the only safe thing to do in Rickython
>> 4000 is to prohibit putting mutable objects inside tuples. Putting a list
>> or a dict inside a tuple is just a bug waiting to happen!
>
> I think you're onto something here, but you really haven't gone far
> enough. Mutable objects *anywhere* are a problem. The solution?
> Abolish mutable objects. Strings (bytes and Unicode), integers,
> decimals (floats are a problem to many people), tuples of the above,
> and dictionaries mapping any of the above to any other of the above,
> should be enough to do everything.
>
Pure functional languages don't have mutables, or even variables, but
then we're not talking about a pure functional language, we're talking
about Python.

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

#48909

On Friday, June 21, 2013 8:54:50 PM UTC-5, MRAB wrote:
> On 22/06/2013 00:51, Rick Johnson wrote:
> > On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> > My argument has always been that mutables should not be
> > passed into subroutines as default arguments because bad
> > things can happen. [...] I also believe that a programmer
> > should not be prevented from passing mutable default
> > arguments [...]
> So, having mutables as default arguments is a bad idea,
> but a programmer should not be prevented from doing that,
> and a warning message should be printed on such occasions.

Well i'll admit that does sound like a contradiction.
Basically i meant, programmers should be *discouraged* from
passing mutables as default arguments but not *prevented*.
Of course, utilizing a stateless subroutine like i suggest,
argument mutability would not matter.

Sometimes when you're passionate about something your
explanations become so verbose as to render your idea lost
in the noise. Obviously i made that mistake here :)

In my last reply to Rotwang i explained the functionality i
seek to achieve in a set of three interactive examples.
Take a look at those and let me know what you think.

> > Why should i help the developers of this language. What have
> > they done for me?
> 
> They've developed this language, and provided it for free.
> They've even released the source code. You perceive flaws
> that you say must be fixed, but you're not going to help
> to fix them.

Agreed. And i am thankful for everyone's contributions. I
can be a bit harsh sometimes but my intention has always
been to improve Python.

> I _do_ want you to help to improve the language, and I
> don't care if you don't get it right first time. I didn't
> get it right first time when I worked on the regex module
> (I think that what I have on PyPI is my _third_ attempt!).

Well thanks for admitting you are not perfect. I know i am
not. We all had to start somewhere and anyone who believes
he knows everything is most assuredly a fool. Learning is
a perpetual process, same for software evolution.

> > You want to gain my respect? Then start engaging in honest
> > debates. Start admitting that yes, somethings about Python
> > are not only undesirable, they're just plain wrong.
> Python isn't perfect, but then no language is perfect.
> There will always be compromises, and the need to maintain
> backwards compatibility means that we're stuck with some
> "mis-features", but I think it's still worth using; I
> still much prefer it to other languages.

I understand. We can't break backwards compatibility for
everything, even breaking it for some large flaws could
cause a fatal abandonment of the language by long time
users. 

I just don't understand why i get so much hostility when i
present the flaws for discussion. Part of my intention is to
air the flaw, both for new users and old users, but a larger
intention is to discover the validity of my, or others,
possible solutions.

And even if that solution involves a fork, that is not a bad
thing. Creating a new fork and then garnering an acceptance
of the new spinoff would lead to at worse, a waste of time
and a huge learning experience, or at best, an evolution of
the language.

> > Stop calling me a troll when i am not. And not just me, stop
> > calling other people trolls too! Stop using the personal
> > attacks and straw man arguments.

Sorry. I failed to explain that this statement was meant not
directly for you but as a general statement to all members.
Sometimes i feel like my back is against the wall and i'm
fighting several foes at once. That can lead to me getting
defensive.

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

#48944

On 22/06/2013 03:32, Rick Johnson wrote:
> On Friday, June 21, 2013 8:54:50 PM UTC-5, MRAB wrote:
>> On 22/06/2013 00:51, Rick Johnson wrote:
>> > On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
>> > My argument has always been that mutables should not be
>> > passed into subroutines as default arguments because bad
>> > things can happen. [...] I also believe that a programmer
>> > should not be prevented from passing mutable default
>> > arguments [...]
>> So, having mutables as default arguments is a bad idea,
>> but a programmer should not be prevented from doing that,
>> and a warning message should be printed on such occasions.
>
> Well i'll admit that does sound like a contradiction.
> Basically i meant, programmers should be *discouraged* from
> passing mutables as default arguments but not *prevented*.
> Of course, utilizing a stateless subroutine like i suggest,
> argument mutability would not matter.
>
> Sometimes when you're passionate about something your
> explanations become so verbose as to render your idea lost
> in the noise. Obviously i made that mistake here :)
>
Yes, a more measured explanation tends to work better. :-)

> In my last reply to Rotwang i explained the functionality i
> seek to achieve in a set of three interactive examples.
> Take a look at those and let me know what you think.
>
Hmm. Like they say, "The devil's in the details". As with the
mutability thing, I need to think about it some more. Sometimes it
seems straight-forward, until you try to do it! :-)

>> > Why should i help the developers of this language. What have
>> > they done for me?
>>
>> They've developed this language, and provided it for free.
>> They've even released the source code. You perceive flaws
>> that you say must be fixed, but you're not going to help
>> to fix them.
>
> Agreed. And i am thankful for everyone's contributions. I
> can be a bit harsh sometimes but my intention has always
> been to improve Python.
>
>> I _do_ want you to help to improve the language, and I
>> don't care if you don't get it right first time. I didn't
>> get it right first time when I worked on the regex module
>> (I think that what I have on PyPI is my _third_ attempt!).
>
> Well thanks for admitting you are not perfect. I know i am
> not. We all had to start somewhere and anyone who believes
> he knows everything is most assuredly a fool. Learning is
> a perpetual process, same for software evolution.
>
>> > You want to gain my respect? Then start engaging in honest
>> > debates. Start admitting that yes, somethings about Python
>> > are not only undesirable, they're just plain wrong.
>> Python isn't perfect, but then no language is perfect.
>> There will always be compromises, and the need to maintain
>> backwards compatibility means that we're stuck with some
>> "mis-features", but I think it's still worth using; I
>> still much prefer it to other languages.
>
> I understand. We can't break backwards compatibility for
> everything, even breaking it for some large flaws could
> cause a fatal abandonment of the language by long time
> users.
>
> I just don't understand why i get so much hostility when i
> present the flaws for discussion. Part of my intention is to
> air the flaw, both for new users and old users, but a larger
> intention is to discover the validity of my, or others,
> possible solutions.
>
The problem is in _how_ you do it, namely, very confrontationally.
You call yourself "RantingRick". People don't like ranting!

Instead of saying "This is obviously a flaw, and you're a fool if you
don't agree", you should say "IMHO, this is a flaw, and this is how I
think it could be fixed". Then, if someone points out a problem in your
suggested fix, you can say "OK, I see your point, I'll try to see
whether I can think of a way around that". Etc.

> And even if that solution involves a fork, that is not a bad
> thing. Creating a new fork and then garnering an acceptance
> of the new spinoff would lead to at worse, a waste of time
> and a huge learning experience, or at best, an evolution of
> the language.
>
>> > Stop calling me a troll when i am not. And not just me, stop
>> > calling other people trolls too! Stop using the personal
>> > attacks and straw man arguments.
>
> Sorry. I failed to explain that this statement was meant not
> directly for you but as a general statement to all members.
> Sometimes i feel like my back is against the wall and i'm
> fighting several foes at once. That can lead to me getting
> defensive.
>

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

#48949

On Sat, 22 Jun 2013 20:36:30 +0100, MRAB <python@mrabarnett.plus.com>
declaimed the following:


>The problem is in _how_ you do it, namely, very confrontationally.
>You call yourself "RantingRick". People don't like ranting!
>

	Unless you've got fur and wings... And are in a proper venue...

http://en.wikifur.com/wiki/2,_The_Ranting_Gryphon
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#48912

On Saturday, June 22, 2013 7:34:18 AM UTC+5:30, MRAB wrote:
> Pure functional languages don't have mutables, or even variables, but
> then we're not talking about a pure functional language, we're talking
> about Python.

In which case neither do mathematicians.  Do we rewrite the last 1000 years of math history?

The incantation:
x = x+1
is something algorithmists (ie programmers) write without batting an eyelid.

Algebraically (ie for a mathematician) this is the specification of an impossibility.

Every programmer needs to have both these modes of thinking -- algebraic and algorithmic -- up his sleeve.

Ironically it was al Khwarizmi -- whose name became 'algorithm' -- who wrote al Gebr -- from which we get algebra ie its taken us a millenium to come full circle!!

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

#48919

On 22/06/2013 02:31, Steven D'Aprano wrote:
> On Sat, 22 Jun 2013 05:07:59 +1000, Chris Angelico wrote:
>
>> Oh! I know. Function argument defaults will now be restricted to
>> int/float/tuple. That would do it, right? Nobody would be bothered by
>> little restrictions like that, would they.
>
> Alas, tuples won't do it. Fortunately, you can include str and bytes
> (unicode and str) and frozenset in the "Good List". Tuples have to go
> into the "Bad List" because, although they themselves are immutable,
> their contents may not be. Imagine the confusion and horror that poor
> developers will experience when they do something like this:
>
> def func(arg, extra=(23, 'foo', [])):
>      [code goes here...]
>      extra[2].append("something")
>      [more code...]
>
>
> and they've now mutated the immutable default!
>
> Thinking about this, I think that the only safe thing to do in Rickython
> 4000 is to prohibit putting mutable objects inside tuples. Putting a list
> or a dict inside a tuple is just a bug waiting to happen!
>

How about naming the fork RickedPython 4000, where ricked is defined 
here http://www.urbandictionary.com/define.php?term=ricked ?

-- 
"Steve is going for the pink ball - and for those of you who are 
watching in black and white, the pink is next to the green." Snooker 
commentator 'Whispering' Ted Lowe.

Mark Lawrence

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

#48878

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:
>
> ============================================================
>   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!
>
What about this:

     def f(x=Foo()):
         pass # do something

Should it raise an exception? Only if a Foo instance is mutable? How do
you know whether such an instance is mutable?

> ============================================================
>   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.
>
> ============================================================
>   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!
>
How does the "Apathetic Approach" differ from the "Malevolent Approach"?

> ============================================================
>   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. All you can muster is
> some weak argument about protecting the lemmings.
>
>   Is anyone up the challenge?
>   Does anyone here have any real chops?
>
> PS: I won't be holding my breath.
>
Speaking of which, on 11 January 2013, in the thread "PyWart: Import
resolution order", you were asked:

"""Got any demonstrable code for Python 4000 yet?"""

and you said:

"""I am working on it. Stay tuned. Rick is going to rock your little 
programming world /very/ soon."""

How soon is "/very/ soon" (clearly longer than 5 months), and how did
you fix this "PyWart"?

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

#48882

On Friday, June 21, 2013 2:25:49 PM UTC-5, MRAB wrote:
> On 21/06/2013 19:26, Rick Johnson wrote:
> > ============================================================
> >   The Apathetic Approach:
> > ============================================================
> > I could just assume that a programmer 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.
> > ============================================================
> >   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!
>
> How does the "Apathetic Approach" differ from the
> "Malevolent Approach"?

In the apathetic approach i allow the programmer to be the
sole proprietor of his own misfortunes. He lives by the
sword, and thus, he can die by the sword.

Alternatively the malevolent approach injects misfortunes
for the programmer on the behalf of esoteric rules. In this
case he will live by sword, and he could die by the sword,
or he could be unexpectedly blown to pieces by a supersonic
Howitzer shell.

It's an Explicit death versus an Implicit death; and Explicit
should ALWAYS win! 

The only way to strike a reasonable balance between the
explicit death and implicit death is to throw up a warning:

 "INCOMING!!!!"

Which in Python would be the "MutableArgumentWarning".

*school-bell*

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

#48889

On 21/06/2013 21:44, Rick Johnson wrote:
> On Friday, June 21, 2013 2:25:49 PM UTC-5, MRAB wrote:
>> On 21/06/2013 19:26, Rick Johnson wrote:
>> > ============================================================
>> >   The Apathetic Approach:
>> > ============================================================
>> > I 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.
>> > ============================================================
>> >   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!
>>
>> How does the "Apathetic Approach" differ from the
>> "Malevolent Approach"?
>
> In the apathetic approach i allow the programmer to be the
> sole proprietor of his own misfortunes. He lives by the
> sword, and thus, he can die by the sword.
>
> Alternatively the malevolent approach injects misfortunes
> for the programmer on the behalf of esoteric rules. In this
> case he will live by sword, and he could die by the sword,
> or he could be unexpectedly blown to pieces by a supersonic
> Howitzer shell.
>
> It's an Explicit death versus an Implicit death; and Explicit
> should ALWAYS win!
>
> The only way to strike a reasonable balance between the
> explicit death and implicit death is to throw up a warning:
>
>   "INCOMING!!!!"
>
> 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.

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

#48891

On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> I notice that you've omitted any mention of how you'd know that the
> argument was mutable.

My argument has always been that mutables should not be
passed into subroutines as default arguments because bad
things can happen. And Python's excuse of saving the poor
dummies is no excuse.

It does not matter if we are passing the arguments into the
current implementation of "python functions which maintain
state of default mutables arguments between successive
calls" or in a more desirable system of truly "stateless
subroutines".

I also believe that a programmer should not be prevented
from passing mutable default arguments, but if he does, I'm
not going to provide any sort of protection -- other than
possibly throwing up a warning message.

Now, YOU, and everyone else, cannot destroy the main points
of my argument because the points are in fact rock solid,
however, what you will do is to focus in one small detail,
one little tiny (perceived) weakness in the armor, and you
will proceed to destroy that small detail (in this case how
i will determine mutability), and hope that the destruction
of this insignificant detail will start a chain-reaction
that will propagate out and bring down my entire position.

So you want me to tell you how to query the mutability of an
object... Ha Ha Ha! Sorry, but that's not going to happen!

Why should i help the developers of this language. What have
they done for me?  Hmm, let's see. They called me names.
Trolled up my posts. Written me off. Refused to answer my
questions. Been absolutely rude. etc, etc... Banned me from
lists i've never posted on and then proclaim the list is
free and open to all... BS!

WOULD YOU OFFER ASSISTANCE TO PEOPLE THAT HAVE TREATED YOU THIS WAY?  
 
And let's just be honest. You don't want my assistance. You
just want me to fumble the ball. Then you can use that
fumble as an excuse to write me off. Nice try!

You want to gain my respect? Then start engaging in honest
debates. Start admitting that yes, somethings about Python
are not only undesirable, they're just plain wrong. 

Stop calling me a troll when i am not. And not just me, stop
calling other people trolls too! Stop using the personal
attacks and straw man arguments.  

Finally, get the core devs to realize that this list matters
and they need to participate (including you know who!)

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

#48903

On 22/06/2013 00:51, Rick Johnson wrote:
> On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
>> I notice that you've omitted any mention of how you'd know that the
>> argument was mutable.
>
> My argument has always been that mutables should not be
> passed into subroutines as default arguments because bad
> things can happen. And Python's excuse of saving the poor
> dummies is no excuse.
>
> It does not matter if we are passing the arguments into the
> current implementation of "python functions which maintain
> state of default mutables arguments between successive
> calls" or in a more desirable system of truly "stateless
> subroutines".
>
> I also believe that a programmer should not be prevented
> from passing mutable default arguments, but if he does, I'm
> not going to provide any sort of protection -- other than
> possibly throwing up a warning message.
>
So, having mutables as default arguments is a bad idea, but a
programmer should not be prevented from doing that, and a warning
message should be printed on such occasions.

> Now, YOU, and everyone else, cannot destroy the main points
> of my argument because the points are in fact rock solid,
> however, what you will do is to focus in one small detail,
> one little tiny (perceived) weakness in the armor, and you
> will proceed to destroy that small detail (in this case how
> i will determine mutability), and hope that the destruction
> of this insignificant detail will start a chain-reaction
> that will propagate out and bring down my entire position.
>
In order to print a warning, Python needs to know whether the object is
mutable, so it's an important detail.

> So you want me to tell you how to query the mutability of an
> object... Ha Ha Ha! Sorry, but that's not going to happen!
>
It's a detail that you're not going to help to solve.

> Why should i help the developers of this language. What have
> they done for me?
>
They've developed this language, and provided it for free. They've even
released the source code.

You perceive flaws that you say must be fixed, but you're not going to
help to fix them.

> WOULD YOU OFFER ASSISTANCE TO PEOPLE THAT HAVE TREATED YOU THIS WAY?
>
> And let's just be honest. You don't want my assistance. You
> just want me to fumble the ball. Then you can use that
> fumble as an excuse to write me off. Nice try!
>
I _do_ want you to help to improve the language, and I don't care if
you don't get it right first time. I didn't get it right first time
when I worked on the regex module (I think that what I have on PyPI is
my _third_ attempt!).

> You want to gain my respect? Then start engaging in honest
> debates. Start admitting that yes, somethings about Python
> are not only undesirable, they're just plain wrong.
>
Python isn't perfect, but then no language is perfect. There will
always be compromises, and the need to maintain backwards compatibility
means that we're stuck with some "mis-features", but I think it's still
worth using; I still much prefer it to other languages.

> Stop calling me a troll when i am not. And not just me, stop
> calling other people trolls too! Stop using the personal
> attacks and straw man arguments.
>
???

> Finally, get the core devs to realize that this list matters
> and they need to participate (including you know who!)
>
Everyone is a volunteer. The core devs contribute by developing the
language, and whether they participate in this particular list is
entirely up to them; how they choose to spend _their own_ free time is,
again, entirely up to them.

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

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

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

csiph-web