[Baypiggies] Frequently Argued Objections

[Chris Rebert]

On Tue, Jun 24, 2008 at 5:12 AM, Shannon -jj Behrens <jjinux at gmail.com> wrote:
> Wait a second, how did we get this far without the normal objections?
>
> * Python isn't stackless.
>
> Ok, I'll just shut up ;)
>
> * Python doesn't have tail call optimization.
>
> I think the thinking is that for loops are more readable than using
> recursion all over the place.
>
> * Python doesn't have a match statement like ML.
>
> This is probably because there's no obvious way to make the syntax work.
>
> * Python differentiates expressions and statements.
>
> This is because Guido thinks that if you allow all statements to be
> expressions, you get weird situations like defining a 100 line
> function as a parameter in the middle of calling another function.
> Looking at modern JavaScript, I would agree with him.  However,
> because of this, you can't write:
>
> a = if b:
>           f()
>       else:
>           g()
> print a

Actually, IIRC, you can write that now (the syntax differs slightly):

a = f() if b else g()
#and it's visually appealing too, unlike ? : line noise!

>
> I know it's sometimes frustrating, but I think Guido was right to err
> on the side of readability.
>
> * No one has brought up the lack of private variables either.
>
> Python doesn't assume that you're an untrustable moron ;)
>
> * Python is a half- at ss Lisp with too few parenthesis.
>
> Actually, Python takes many of the good parts of Lisp, and makes them
> more readable ;)
>
> Happy Hacking!
> -jj
>
> On Tue, Jun 24, 2008 at 5:03 AM, Shannon -jj Behrens <jjinux at gmail.com> wrote:
>> Your post did bring up one thing I do like about Ruby.  It has a more
>> defined notion of class scope at class definition time.  If Python had
>> that, I could do something like:
>>
>> class B(A):
>>    ...
>>    if hasattr(B, 'foo'):
>>        ...
>>
>> That's not possible now, because B doesn't exist until the class is
>> finished being defined.  There are workarounds.  It's not a big deal.
>> I'm just saying ;)
>>
>> -jj
>>
>> On Mon, Jun 23, 2008 at 4:35 PM, Warren Stringer <warren at muse.com> wrote:
>>> Ok, so "var=x" instantiates a static var x, yes? For example:
>>> class a(object):
>>>     b=1
>>>     # self.b does not work here
>>>     def __init__(self):
>>>         self.b=2 # so declare it in the constructor
>>>     def f(self):
>>>         b=3
>>>         print a.b, self.b, b
>>>         b=b+1
>>> i=a()
>>> i.f() # => prints 1 2 3
>>> a.b=4
>>> i.f() # => prints 4 2 3
>>> j=a()
>>> j.f() # => prints 4 2 3
>>> a.b=5 # will change for i and j
>>> i.f() # => prints 5 2 3
>>> j.f() # => prints 5 2 3
>>> i.b=6 #changes self.b
>>> i.f() # => prints 5 6 3
>>> j.f() # = prints 2 6 3
>>>
>>>
>>>
>>> So, the ambiguity is that
>>>
>>>     whatever=a() will instantiate b=1 once, whereas
>>>
>>>     whatever.f() will instantiate b=3 always
>>>
>>>
>>> Must keep track that
>>>     a.b behaves differently from i.b, since
>>>     i.b=6 implicitly passes self,
>>>         somewhat akin to i.self.b, tho not quite
>>>          (how would one express as internal dictionaries?)
>>> As stated about @var, in Ruby:  "but conceptually bends Occam's razor -- it
>>> makes the language introduce one more rule"
>>> One may make the case that examples for b=1, b=3, a.b=5, i.b=6 also
>>> introduce more rules.
>>> This is what confused me the most, when learning Python. I have heard
>>> similar objections. I have seen plenty of questions posted about this
>>> problem and have seen many replies posted that essentially say "oh no, not
>>> THAT question again."
>>> There are several methods of dealing with objections:
>>> 1) ignore it by calling it whining
>>> a) and hope the whiners go away
>>> 2) acknowledge the problem
>>> a) show how it solves a bigger problem
>>> b) show how a fix would create new problems
>>> 3) eliminate the source of the problem
>>> a) without creating new problems
>>>
>>> Guess which methods increase the popularity/longevity of a product? Since 3)
>>> is not going to happen for self, I would suggest 2) over 1).
>>> \~/
>>> On Jun 23, 2008, at 8:40 AM, Alex Martelli wrote:
>>>
>>> On Mon, Jun 23, 2008 at 7:41 AM, Warren Stringer <warren at muse.com> wrote:
>>>   ...
>>>
>>> My guess is that:
>>>
>>>       1)  9 times out of 10 the var in self.var is blindingly obvious,
>>>
>>>       2) 99 times out of 100 it is obvious after a 10 second search,
>>>
>>> I think that there are way more than 1 in 100 uses even just for the
>>> simplest example that shows this guess to be unfounded: "self.var = x"
>>> which would allowed to become "var = x"  under a deleterious "implicit
>>> self" rule.
>>>
>>> Right now, "var = x" sets a local variable in the method, "self.var =
>>> x" sets an instance variable: zero ambiguity, zero chances for error,
>>> zero problems -- well let's say epsilon problems rather than zero,
>>> because there IS the issue of having to listen to whines against
>>> "mandatory explicit self";-).
>>>
>>> There are good ways and bad ways to address this issue during language
>>> design. The best way -- as in Modula-3, Python, Perl-5, Ruby -- is to
>>> explicitly mark instance variables (self.var in Modula-3 and Python,
>>> $self->{var} in Perl-5, @self in Ruby); a somewhat inferior way -- as
>>> in Squeak -- is to give up some of the language's dynamic nature by
>>> forcing variables to be declared; a worse way would be to break
>>> symmetry by using the explicit mark in assignment but not in
>>> reference.
>>>
>>> The very worst way is shown by Javascript's "with" statement -- within
>>> a Javascript "with zap", the meaning of "zop = 23" is essentially
>>> unguessable as it depends on whether zap already did have a zop
>>> attribute (in which case it rebinds it) or not (in which case it binds
>>> a global variable -- unless there was an earlier declaration of "var
>>> zop" in this function, in which case it binds the local variable
>>> instead) -- a mix of forced declaration and blind guessing that good
>>> books on Javascript (e.g. the short and useful "Javascript, the good
>>> parts") strive to convince the reader to never, ever use that accursed
>>> statement.
>>>
>>> Within the "explicit mark" camp, Ruby's "@var" is typographically
>>> concise but conceptually bends Occam's razor -- it makes the language
>>> introduce one more rule (on the meaning of a "@" prefix) where the
>>> choice that Python took from Modula-3 just reuses an existing rule
>>> (whatever.var means exactly the same in all cases, whether "whatever"
>>> is "self" or something other than "self" -- no special cases, no extra
>>> rules).
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>
>>
>>
>> --
>> It's a walled garden, but the flowers sure are lovely!
>> http://jjinux.blogspot.com/
>>
>
>
>
> --
> It's a walled garden, but the flowers sure are lovely!
> http://jjinux.blogspot.com/
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>