New language

[Topmind]

> Topmind <topmind at technologist.com> wrote:
> 
> >> Topmind <topmind at technologist.com> wrote:
> >> [snip]
> >> > Python blew an opportunity for minimalism. They could have made
> >> > touples, dictionaries, and classes all the same thing, for example. The 
> >> > differecence are not large enough to justify 3 seperate syntactical
> >> > creatures, and the difference could have been mitigated.
> >> 
> >> Topmind: in Python, instances are syntactic sugar for dictionaries.
> 
> > Is that new? My Oreilly Programming Python
> > version 1 says they are different
> > on page 239.
> 
> As far as I know it's always been like that.


Well, there appears to be a discrepency somewhere.
Perhaps one can use a dictionary to *access* methods,
but that is not the same as methods *being* 
a dictionary.


> 
> >> You can even ask for the __dict__ attribute of any instance to
> >> see the dictionary.
> >> 
> >> Could you please stop saying things about Python without studying the
> >> matter? 
> 
> Apparently you did study the matter, as you mentioned Programming Python. :)
> 
> >> And yes, you could make a good case against the need for tuples in Python,
> >> though as syntax they're very useful, especially when you want to return
> >> multiple things from a function.
> >> 
> >> def foo():
> >>    return 1, "2", [3]
> >> 
> >> a, b, c = foo()
> >> 
> >> Dictionaries may be just a bit too heavyweight for this sometimes, especially
> >> in syntax.
> 
> > What do you mean by "heavy-weight"?
> 
> More work typing and handling them in your code, under certain circumstances
> such as the return value case I just gave. 


Which I disagreed was a noticable improvement over "traditional"
parameter passing and dictionaries. More on that below.


> Another good example is for
> instance x, y coordinates you want to pass around, without going to the
> trouble of  dealing with anything more complicated.
> 


What keeps a dictionary from satisfying this role?


> I think tuples may also take less memory and processing time when used
> this way, but that's relatively unimportant. The case you could make 
> against them could include the argument that you could provide syntactic
> sugar that allows you to do something similar with dictionaries/objects.
> 


I think that was my case, more or less. Touples, dictionaries, and
classes have too much *overlap* in Python. It just seems to me that
they could have factored the 3 into *one* thing. It keeps the
language cleaner and the learning curve shorter that way.


For example, do have OO,
allow dots to be represent dictionary items:

a["foo"] = 3

a.foo = 3

(Both are probably needed in case spaces are used in the key.)

Have a special option indicator for a "parent" dictionary,
and wallah! you have inheritance:

a.__parent__ = bar

or perhaps

a.__parent__ = "bar"      # the "by name" approach


> > Besides, what is wrong
> > with regular by-reference parameters? 
> 
> Nothing at all, except that returning multiple values is far more clear
> by just about any measure you can come up with. :)


Which would be?

I suppose you could argue that under the old approach
one could not tell what was being changed and what was
not by looking at the caller. However, you might have to check
the bottom or middle instead of the top of a routine to
figure out the result parameter interface in Python.
IOW, it might trade caller readability for callee
readability. At the most it is a wash IMO.

Having the entire interface defined at the top is
a good thing IMO. (Although "return" is rarely
at the top, but it is a single item if it
exists.)


> 
> > I see no reason to deviate from tradition unless it 
> > does something better. It is a "cute" idea, but I
> > don't see any advantage to by-ref parameters.
> 
> It's a very old tradition in many programming languages that functions get
> their input through their parameters, and return their output with
> a return statement. It's a bit strange that as soon as you have to
> return multiple things, you'll have to go deal with these odd by reference
> parameters (output through input? not syntactically obvious when you're 
> calling such a function? great idea!) or alternatively have to create a lot
> of syntax just to return a datastructure of two elements (as you'd need to do
> in C, for instance).
> 


C is hardly the pennacle of programming languages. Using that
as the alternative to Python is misleading. 

If you want to return 2 elements, then use a dictionary.


> Anyway, Python's ability is just a consequence of the ability to return a
> tuple in Python, like this:
> 
> def foo():
>    return "my", "tuple"
> 
> t = foo() # t now contains a tuple.
> 
> and the ability to 'unpack' tuples, like this:
> 
> a, b = t
> 
> They both seem to be entirely reasonable constructs, the combination
> is entirely reasonable too and in fact a lot clearer when you're reading
> code than by reference parameters, so why object against them out of
> some idea of tradition?
> 

Because I am not convinced it is significantly better. As a rule of
thumb, I say something has to be at least 15 to 30 percent better to
deviate from tradition. Perhaps if I saw more actual uses for 
it besides foo-bar examples, but I have not.

Most "data structures" I deal with are more than 2 positions.
Thus, I use tables, and perhaps a dictionary-like thing to
interface to such records. (I prefer to use tables to store
data instead of dictionaries themselves, other than an interface
mechanism to specific records.) Perhaps some niches have lots of
"skinney collections" where touples may help, but not mine.


> If you're objecting against cute because we have an old tradition, you'd
> object against this consequence of tuples and tuple unpacking too, I'm sure:
> 
> a,b = b,a # swap a & b
> 

Yes, because it is not obvious what is going on. Perhaps if 10+ percent
of all code was devoted to swapping, then I might agree. As it is,
swapping is something that is done perhaps 1/1000 lines. At that
low rate, it is nothing more than an intellectually cute idea
that can confuse people.

My philosophy is optimize the syntax for the *common* stuff. I don't
see Python doing that, at least not the way I code.

Don't get me wrong, there are languages a lot worse than Python,
but the poor consolidation of the similar things I mentioned
kind of bug me.


> Regards,
> 
> Martijn
> -- 
> History of the 20th Century: WW1, WW2, WW3?
> No, WWW -- Could we be going in the right direction?
> 

Thanks for your feedback,
-T-