No Do while/repeat until looping construct in python?

[sismex01 at hebmex.com]

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

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.

> 
> >> ...so file it right next to "self" as the second of the 
> >> two most-hated "features" of the language.  The problem
> >> is that as a relatively small language, you can't escape them.
> >>
> > "Hated"?  Yeesh...
> > 
> Yes. Hated.  Go to the Ruby web site - one of the quoted "features" of
> Ruby is not having to type "self".
> 

That's a pretty shallow reason to pick a language.

What happens in Ruby when a thread hangs waiting for an OS event
or function return?  Guess.... yep, the whole application hangs
with it.

Ruby as an idea is neat; as an application development platform
it leaves much to be desired.  Your use of Ruby as a template for
desireable traits is ... enlightening.

> >> The workaround for (no) repeat is to brake after the test 
> >> placed at the end of the loop.
> >> 
> > 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] ??

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.

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.

>
> Item 2 -  There can be no "advantage" to Python's way since 
> there is no way.  There is only a workaround.  The question
> is whether the addition results in a correspnding disadvantage
> that outweighs the advantage.
> 

I don't quite understand what you're trying to point out here.

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

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

There's three different things, the instance (self), it's contents
(instance namespace), and the current execution frame (local namespace).
Thanks to the explicit reference to self, the instance namespace is
totally separate from the local namespace, orthogonally accesible.

>
> The *practical* problem is that because common sense says the instance
> variables are local, and typing "self" is a pain, the user  has a double
> disincentive to include it, resulting in gratuitous bugs.
> 

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?

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

If the way you communicate generates criticism, just *maybe* it's
because of the way you do it.  If after that, you simply reply
with the stupidity with which you replied to Jb, the rest
of the group will simply ignore you and label you a troll.

So chill, read what people are saying about your issues,
explain clearly, and if you still don't like it, the maybe,
just maybe, Python isn't for you.

OTOH, if you're enterprising enough, you can make your own
fork of Python with all the goodies you want, others will like
it and that's that.  Nobody's gonna hunt you down because of
it.

> 
> If you feel the need to respond with trash-talk, you are 
> welcome to do so, but you really should look in the mirror
> before you call me anything.
>

Well, I'd tell you to look into a mirror also; you invite your
so called "trash-talk" with your attitude.  Cool down, it's a
public newsgroup and you either invite others to partake of
your discussion with your attitude, or you turn them away.
 
> 
> On the other hand, if you have a valid reason why "self" is 
> advantageous FROM THE USER's POINT OF VIEW I would like to hear it.
> 

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?

>
> I already know that:
> 
> a. "its already been talked to death! see html://blahblahblah"

true.

> b. "real Python programmers KNOW why"

Hmmm... questionable.

> c. "use (c++|Java|Perl|$your_pick) instead"

valid.

> d. Python RULEZZZ

dumb.

> e. Please don't question the language or post critiques - 
>    somebody might agree with you!!

I couldn't give less of a damn if others agree with you; there's
tools and languages for all kinds of people, why should I care
if others like Ruby, or Lisp, or Haskell, or Dylan, or C++, or
Java, or ... any of a huge number.

That's what makes it so nice about using free software, you can
find a tool which fits what you need, or like.

>
> So you can skip those (or cut and paste, if you prefer).
>

Heh.
 
-gustavo