No Do while/repeat until looping construct in python?

[William Sonna]

On Fri, 14 Mar 2003 11:32:27 -0600, sismex0 wrote:

>> From: William Sonna [mailto:wsonna at attglobal.net] Sent: Friday, March
>> 14, 2003 10:30 AM
>> 
>> On Thu, 13 Mar 2003 09:27:07 -0600, sismex0 wrote:
>> 
>> > Troll? Flamebait? Or just uninformed?
>> 
>> None of the above.  Legitmate criticism of questionable design
>> decisions made.  Either respond to the issues raised or look foolish-
>> your choice.
>> 
>> 
> "Questionable design".  That's a pretty subjective qualification,
> because it's "questionable" from your point of view, using your scale of
> what's important and what's not.
>
>
EVERY design decision in the world is subject to question, therefore
questionable.  That is an OBJECTIVE fact.


> There is no absolutely perfect language, because absolute perfection
> does not exist.  Python is "perfect" in it's own niche, which means it's
> "relatively perfect".  You might disagree, certainly you're entitled to
> it; but don't go spouting off pseudo-data and pseudo- knowledge,
> implying that we *have* to agree with you.
> 
> 
> 
First two sentences of paragraph - I agree.

Third sentence - YOU are the one throwing flames here, not me.

I have backed up EVERYTHING I have said with facts.

What "pseudo-data" and "pseudo-knowledge", are you referring to, anyway?
As for the "implication" that I care whether you or anyone else agrees
with me, you haven't backed that up either.

[snip]

>> > repeat ... until (condition)
>> > 
>> > is exactly the same thing; only that the language places the
>> > responsability of choosing the condition's location and exit point on
>> > the programmer, not the other way around.
>> > 
>> > For bonus points, can you point out the advantage of Python's
>> > approach and the disadvantage of language X's?
>> > 
>> Item 1 - one-or-more is *not* the same as zero-or-more.  It is
>> mathematically incorrect to make that claim.
>> 
>> 
> Where did I say that [0..n] == [1..n] ??
> 
> 
> 
What does "exactly the same thing" mean, then?  You can score some of your
own "bonus points" if you can explain that one.

> Exactly, no where.  If you wish to code a "zero or more" construct in
> Python, you do it.  If you wish for a "one or more" construct, you can
> also do it.
> 
> 
The correct word for what you describe is "approximately", or
"functionally", not "exactly".

> Except that, there's no syntax sugar to sweeten your day, you have to
> pick when and where.  Whether you like the freedom it gives you, or
> resent the responsability of having to think carefully your algorithms,
> is your issue, not the language's.
> 
> 
Its not a question of freedom or responsibility.  It is a question of
having to recode standard (and often classic) algorithms for Python's
quirky omission.

[snip]

>> The argument is NOT whether its already there (it isn't), or whether it
>> would be nice to have (it would), but whether it is sufficiently
>> important to justify its existence.
>> 
>> The general concensus is that it is not.  A substantial number
>> disagree.
>> 
>> 
> In that case, "a substantial number" may fork Python and add it, it's
> perfectly doable.
> 
> Ahh... but you don't want to do it yourself, and you wish for approval
> by the masses, and also a little checkmark which says "Approved by
> Guido".  I don't think you can have it both ways.
> 
> 
When did I ask for "approval by the masses" or "Approved by Guido"?  More
false claims.

Do you really consider false claims to be a valid argument in favor of the
design decisions that I was attempting to discuss with you?


>> >> The workaround for "self" is to assign a local variable and use it
>> >> instead.
>> >> 
>> >> 
>> > Really...
>> > 
>> > "self", in an instance method, *IS* a local variable.  You can call
>> > it whatever you want: "me", "self", "this", "_", "obj", "instance",
>> > "here", "etc", ...
>> > 
>> > And, having it explicit and not implicit keeps the instance's
>> > namespace apart from the local namespace.
>> > 
>> > 
>> You've just contradicted yourself, (which is OK; it illustrates the
>> problem). Why would a local variable need to be qualified to keep it
>> separate from the local namespace? That's the *conceptual* problem with
>> "self".
>> 
>> 
> I really, try as hard as I might, can't see exactly where I contradicted
> myself.
> 
> "self" is a local variable, referencing the instance which is "active".
> Local variables are in the local namespace.  Instance namespace is
> inside "self", and accessed as attributes.
> 
> Where's the contradiction?
>
>
When you state it clearly like that, of course there is none.

Instance variables are in the namespace of the local variable "self", but
they are never local despite the fact that they occur in an instance
method of the same instance of the same class.

I find it very confusing, and while I can parrot the rules, I don't think
I'll EVER understand the rationale (unless someone can explain it).

[snip]


> Well, that just demonstrates that common sense is the least common of
> senses.  Instance variables are inside self.__dict__ (where applicable),
> and local variables are visible through local().
> 
> 
>> It MAY be consistent with Python's general tendency to favor least-type
>> (both as in class, and as in typewriter), it DOESN'T help get the job
>> done.
>> 
>> 
> Get *what* job done?
> 
> 
The job of generating correct code quickly.


>> Now, as for your personal attacks ("troll", "flaimbait", etc.), I have
>> taken the time to post legitimate criticism substatiated with facts.
>>
>>
> You're oversensitivity to criticism to your own comments, while
> attacking others who disagree with you, truly make you out as a troll.
> Many won't take your comments seriously and will simply ignore you
> because of it.
> 
> 
Who's throwing flames here?  YOU just said I am a troll.  And I haven't
insulted you once!  tu MADRE, cabron!

All kidding aside - my response? - I am NOT a troll, but you APPEAR to be
a very poor debater.

The true test of poor-debaterhood is substitution of facts and logic for
unsubstantiated claims and personal attacks.


[snip]

> I already explained why I find it advantageous; you're entitled to not
> like mi reasons, but they're mine, and I'm my own user. Is not my point
> of view as a user valid?
>
>
>
You haven't explained why this is advantageous, you have merely re-stated
the rules.  If you have more to say about this, tell me something new.

For example: why is the current design better than, say, having instance
variables unqualified and qualifying local variables with "local"?

Or better than not needing to qualify local or instance variables at all -
with well-defined rules for precedence between local and instance
variables?

If you can answer these questions without making false claims about me or
my motives or resorting to insults or personal attacks, there's hope for
you yet.