On Saturday, October 12, 2013 3:37:58 PM UTC-7, Chris Angelico wrote: > On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi > > <peter.cacio...@gmail.com> wrote: > > > Along with "batteries included" and "we're all adults", I think Python > > needs a pithy phrase summarizing how well thought out it is. That is to > > say, the major design decisions were all carefully considered, and as a > > result things that might appear to be problematic are actually not barriers > > in practice. My suggestion for this phrase is "Guido was here". > > > > "Designed". > > > > You simply can't get a good clean design if you just let it grow by > > itself, one feature at a time. You'll end up with something where you > > can do the same sort of thing in three different ways, and they all > > have slightly different names: > > > > http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/#general > > > > (Note, I'm not here to say that PHP is awful and Python is awesome > > (they are, but I'm not here to say it). It's just that I can point to > > a blog post that shows what I'm saying.) > > > > Design is why, for instance, Python's builtin types all behave the > > same way with regard to in-place mutator methods: they don't return > > self. I personally happen to quite like the "return self" style, as it > > allows code like this: > > > > GTK2.MenuBar() > > ->add(GTK2.MenuItem("_File")->set_submenu(GTK2.Menu() > > ->add(menuitem("_New Tab",addtab)->add_accelerator(...)) > > ->add(menuitem("Close tab",closetab)->add_accelerator(...)) > > ... etc ... > > )) > > ->add(GTK2.MenuItem("_Options")->set_submenu(GTK2.Menu() > > ->add(menuitem("_Font",fontdlg)) > > ... etc ... > > )) > > ... etc ... > > > > It's a single expression (this is from Pike, semantically similar to > > Python) that creates and sets up the whole menu bar. Most of Pike's > > object methods will return this (aka self) if it's believed to be of > > use. The Python equivalent, since the .add() method on GTK objects > > returns None, is a pile of code with temporary names. But that's a > > smallish point of utility against a large point of consistency; > > newbies can trust that a line like: > > > > lst = lst.sort() > > > > will trip them up immediately (since lst is now None), rather than > > surprise them later when they try to make a sorted copy of the list: > > > > sorted_lst = lst.sort() > > > > which, if list.sort returned self, would leave you with sorted_lst is > > lst, almost certainly not what the programmer intended. > > > > Oh, and the use of exceptions everywhere is a sign of design, too. > > Something went wrong that means you can't return a plausible value? > > Raise. > > > > >>> json.loads("{") > > ValueError: Expecting object: line 1 column 0 (char 0) > > > > >>> pickle.loads(b"\x80") > > EOFError > > > > Etcetera. PHP borrows from C in having piles and piles of "was there > > an error" functions; there's no consistency in naming, nor (in many > > cases) in the return values. Pike generally raises exceptions, but I/O > > failure usually results in a zero return and the file object's errno > > attribute set; but at least they're consistent error codes. > > > > This is design. Python has a king (Guido). It wasn't built by a > > committee. Maybe you won't like some aspect of Python's design, but it > > has one, it's not just sloppily slapped together. > > > > ChrisA
So Python was designed reasonably well, with a minimum of hacky-screw-ups. This happened because Python's growth was effectively managed by an individual who was well suited to the task. In other words, "Guido was here". Good thread, I learned a lot from it, thanks. -- https://mail.python.org/mailman/listinfo/python-list
