Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #53902 > unrolled thread

Language design

Back to article view | Back to comp.lang.python

Contents

  Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-10 06:09 +0000
    Re: Language design diverman <pavel@schon.cz> - 2013-09-09 23:59 -0700
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-10 17:07 +1000
      Re: Language design Nobody <nobody@nowhere.com> - 2013-09-11 01:03 +0100
        Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 00:53 +0000
          Re: Language design Nobody <nobody@nowhere.com> - 2013-09-12 18:23 +0100
    Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-10 09:58 +0200
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-10 20:20 +1000
    Re: Language design Chris Rebert <clp2@rebertia.com> - 2013-09-10 18:46 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-11 14:21 +1000
    Re: Language design Burak Arslan <burak.arslan@arskom.com.tr> - 2013-09-11 13:38 +0300
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-11 14:32 +0000
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 00:46 +1000
    Re: Language design Wayne Werner <wayne@waynewerner.com> - 2013-09-11 06:42 -0500
    Re: Language design Dave Angel <davea@davea.name> - 2013-09-11 12:05 +0000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-11 07:52 -0700
    Re: Language design Burak Arslan <burak.arslan@arskom.com.tr> - 2013-09-11 18:41 +0300
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-11 22:41 +0200
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 23:40 +0000
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 14:22 -0700
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 14:30 -0700
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 23:40 +0000
        Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:49 -0700
          Re: Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-12 05:33 +0000
            Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-12 20:23 -0700
              Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-13 05:08 +0000
                Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 17:39 +1000
                Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-14 19:37 -0700
                Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-15 09:57 +0200
        Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-11 21:40 -0400
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 11:41 +1000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-11 14:15 -0700
    RE: Language design "Prasad, Ramit" <ramit.prasad@jpmorgan.com.dmarc.invalid> - 2013-09-11 21:56 +0000
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:16 +1000
    Please omit false legalese footers (was: Language design) Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:22 +1000
      Re: Please omit false legalese footers (was: Language design) Grant Edwards <invalid@invalid.invalid> - 2013-09-12 20:12 +0000
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 09:27 +1000
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:19 +1000
    Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-11 19:51 -0400
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:25 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 10:31 +1000
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-12 02:33 +0000
        Re: Language design Roy Smith <roy@panix.com> - 2013-09-11 22:43 -0400
          Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 12:58 +1000
          Re: Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-12 05:08 +0000
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:34 -0700
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:37 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 10:40 +1000
    Re: Language design Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-09-11 17:54 -0700
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 10:57 +1000
    Re: Language design Joshua Landau <joshua@landau.ws> - 2013-09-12 05:17 +0100
    Re: Please omit false legalese footers (was: Language design) Skip Montanaro <skip@pobox.com> - 2013-09-12 04:27 -0500
    Re: Please omit false legalese footers (was: Language design) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-09-12 10:44 +0100
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 19:51 +0200
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-12 18:06 +0000
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 20:13 +0200
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 20:24 +0200
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-12 19:18 +0000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-12 11:05 -0700
    Re: Language design Ned Batchelder <ned@nedbatchelder.com> - 2013-09-12 14:37 -0400
    Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-12 14:46 -0400
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 07:53 +1000
    Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-13 09:04 +0200
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-13 10:13 +0000
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 21:16 +1000
        Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-13 13:28 +0200
        Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-13 15:32 -0400
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-14 09:57 +1000
          Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 14:57 +0000
            Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-19 01:02 +1000
              Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 15:08 +0000
                Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-19 01:12 +1000
                Re: Language design William Ray Wing <wrw@mac.com> - 2013-09-18 12:58 -0400
                  Re: Language design wxjmfauth@gmail.com - 2013-09-18 10:45 -0700
                    Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 17:55 +0000
        Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-13 17:28 -0700
        Re: Language design Vito De Tullio <vito.detullio@gmail.com> - 2013-09-14 07:25 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#53999

1) It tried to make Object the parent of every class.  No one's close
enough to God to make that work.
2) It didn't make dicts inherit from sets when they were added to Python.
3) It used the set literal for dict, so that there's no obvious way to
do it.  This didn't get changed in Py3k.
4?) It allowed [reference] variables to be used as dict keys.  This
creates a parsing difficulty for me, mentally.  Keys should be direct,
hashable values, not hidden in a variable name.

A few of the top of the head....

Mark

On Mon, Sep 9, 2013 at 11:09 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of
> Perl":
>
> http://www.perl.com/doc/FMTEYEWTK/versus/perl.html
>
>
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, there may be good reasons for it, but
> they're surprising.
>
> To get started, here are a couple of mine:
>
>
> - Python is so dynamic, that there is hardly anything at all that can be
> optimized at compile time.
>
> - The behaviour of mutable default variables is a gotcha.
>
> - Operators that call dunder methods like __add__ don't use the same
> method resolution rules as regular methods, they bypass the instance and
> go straight to the type, at least for new-style classes.
>
>
>
> --
> Steven
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#54008

On Wed, 11 Sep 2013 14:30:54 -0700, Mark Janssen wrote:

> 1) It tried to make Object the parent of every class.  

Tried, and succeeded.


> No one's close enough to God to make that work.

Non-sequitor. One doesn't need to be close to a deity to have a single 
root of the object hierarchy.


> 2) It didn't make dicts inherit from sets when they were added to
> Python. 

Why would you want dicts to inherit from sets?


> 3) It used the set literal for dict, so that there's no obvious
> way to do it.  This didn't get changed in Py3k. 

No, it uses the dict literal for dicts. 

And the obvious way to form an empty set is by calling set(), the same as 
str(), int(), list(), float(), tuple(), dict(), ... 


> 4?) It allowed
> [reference] variables to be used as dict keys.  This creates a parsing
> difficulty for me, mentally.  Keys should be direct, hashable values,
> not hidden in a variable name.

I don't even understand what you are talking about here. "[reference] 
variables"? What does that mean?

Dict keys are direct, hashable values, and I have no idea what you mean 
by "hidden in a variable name".



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#54019

>> 1) It tried to make Object the parent of every class.
>
> Tried, and succeeded.

Really?  Are you saying you (and the community at-large) always derive
from Object as your base class?

>> No one's close enough to God to make that work.
>
> Non-sequitor. One doesn't need to be close to a deity to have a single
> root of the object hierarchy.

But wait is it the "base" (at the bottom of the hierarchy) or is it
the "parent" at the top?  You see, you, like everyone else has been
using these terms loosely, confusing yourself.

>> 2) It didn't make dicts inherit from sets when they were added to
>> Python.
>
> Why would you want dicts to inherit from sets?

A dict is-a set of {key:object, key:object} pairs bound together with
a colon ":".  By inheriting from sets you get a lot of useful
functionality for free.  That you don't know how you could use that
functionality is a failure of your imagination, not of the general
idea.

>> 3) It used the set literal for dict, so that there's no obvious
>> way to do it.  This didn't get changed in Py3k.
>
> No, it uses the dict literal for dicts.

Right.  The dict literal should be {:} -- the one obvious way to do
it.  Pay me later.

> And the obvious way to form an empty set is by calling set(), the same as
> str(), int(), list(), float(), tuple(), dict(), ...

Blah, blah.  Let me know when you got everyone migrated over to Python.v3.

>> 4?) It allowed
>> [reference] variables to be used as dict keys.  This creates a parsing
>> difficulty for me, mentally.  Keys should be direct, hashable values,
>> not hidden in a variable name.
>
> I don't even understand what you are talking about here. "[reference]
> variables"? What does that mean?

It's a just a tricky point, that I will wait to comment on.

--mark

[toc] | [prev] | [next] | [standalone]

#54034

By the way, please keep attributions for those you are quoting. It is 
rude otherwise.


On Wed, 11 Sep 2013 17:49:09 -0700, Mark Janssen wrote:

>>> 1) It tried to make Object the parent of every class.
>>
>> Tried, and succeeded.
> 
> Really?  Are you saying you (and the community at-large) always derive
> from Object as your base class?

Not directly, that would be silly. But if you derive from int, or dict, 
or ValueError, or any other type, you're indirectly deriving from object 
since they derive from object. In Python 3, *everything* derives from 
object.

In Python 2, the situation is slightly different in that there are still 
legacy ("old style" or "classic") classes, but that's an old version of 
Python. It's not quite obsolete as yet, but in another five years or so 
it will be. The important thing is, as of *right now*, there are Python 
versions where object is the base class of every class.



>>> No one's close enough to God to make that work.
>>
>> Non-sequitor. One doesn't need to be close to a deity to have a single
>> root of the object hierarchy.
> 
> But wait is it the "base" (at the bottom of the hierarchy) or is it the
> "parent" at the top?  You see, you, like everyone else has been using
> these terms loosely, confusing yourself.

Depends on whether I'm standing on my head or not.

Or more importantly, it depends on whether I visualise my hierarchy going 
top->down or bottom->up. Both are relevant, and both end up with the 
*exact same hierarchy* with only the direction reversed.


>>> 2) It didn't make dicts inherit from sets when they were added to
>>> Python.
>>
>> Why would you want dicts to inherit from sets?
> 
> A dict is-a set of {key:object, key:object} pairs bound together with a
> colon ":".  

It certainly is not.

py> {'x': []}  # Lists can be in dicts.
{'x': []}
py> set([[]])  # But not in sets.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'



> By inheriting from sets you get a lot of useful
> functionality for free.  That you don't know how you could use that
> functionality is a failure of your imagination, not of the general idea.

No you don't. You get a bunch of ill-defined methods that don't make 
sense on dicts.


For example: what is the intersection of these two dicts?

{'a': 1, 'b': 3}
{'a': 3, 'b': 5}


I can see SIX possibilities:

{}
{'a': 1, 'b': 3}
{'a': 3, 'b': 5}
{'a': 3}
{'b': 3}
raise an exception



>>> 3) It used the set literal for dict, so that there's no obvious way to
>>> do it.  This didn't get changed in Py3k.
>>
>> No, it uses the dict literal for dicts.
> 
> Right.  The dict literal should be {:} -- the one obvious way to do it. 

I don't agree it is obvious. It is as obvious as (,) being the empty tuple 
or [,] being the empty list.




> Pay me later.
> 
>> And the obvious way to form an empty set is by calling set(), the same
>> as str(), int(), list(), float(), tuple(), dict(), ...
> 
> Blah, blah.  Let me know when you got everyone migrated over to
> Python.v3.

What does this have to do with Python 3? It works fine in Python 2.


>>> 4?) It allowed
>>> [reference] variables to be used as dict keys.  This creates a parsing
>>> difficulty for me, mentally.  Keys should be direct, hashable values,
>>> not hidden in a variable name.
>>
>> I don't even understand what you are talking about here. "[reference]
>> variables"? What does that mean?
> 
> It's a just a tricky point, that I will wait to comment on.

I'm looking forward to an explanation, as I'm intrigued.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#54097

>> Really?  Are you saying you (and the community at-large) always derive
>> from Object as your base class?
>
> Not directly, that would be silly.

Silly?  "Explicit is better than implicit"... right?

>> But wait is it the "base" (at the bottom of the hierarchy) or is it the
>> "parent" at the top?  You see, you, like everyone else has been using
>> these terms loosely, confusing yourself.
>
> Depends on whether I'm standing on my head or not.
>
> Or more importantly, it depends on whether I visualise my hierarchy going
> top->down or bottom->up. Both are relevant, and both end up with the
> *exact same hierarchy* with only the direction reversed.

Ha,  "only the direction reversed".  That little directionality that
you're passing by so blithely is the difference between whether you're
talking about galaxies or atoms.  Please.

The simplicity of Python has seduced you into making an "equivocation"
of sorts.  It's subtle and no one in the field has noticed it.  It
crept in slowly and imperceptively.

>> By inheriting from sets you get a lot of useful
>> functionality for free.  That you don't know how you could use that
>> functionality is a failure of your imagination, not of the general idea.
>
> No you don't. You get a bunch of ill-defined methods that don't make
> sense on dicts.

They are not necessarily ill-defined.  Keep in mind Python already
chose (way back in 1.x) to arbitrary overwrite the values in a key
collision.  So this problem isn't new.  You've simply adapted to this
limitation without knowing what you were missing.

>>>> 3) It used the set literal for dict, so that there's no obvious way to
>>>> do it.  This didn't get changed in Py3k.
>>>
>>> No, it uses the dict literal for dicts.
>>
>> Right.  The dict literal should be {:} -- the one obvious way to do it.
>
> I don't agree it is obvious. It is as obvious as (,) being the empty tuple
> or [,] being the empty list.

You're just being argumentative.  If there are sets as built-ins, then
{:} is the obvious dict literal, because {} is the obvious one for
set.  You don't need [,] to be the list literal because there is no
simpler list-type.

>>> And the obvious way to form an empty set is by calling set(), the same
>>> as str(), int(), list(), float(), tuple(), dict(), ...
>>
>> Blah, blah.  Let me know when you got everyone migrated over to
>> Python.v3.
>
> What does this have to do with Python 3? It works fine in Python 2.

I mean, you're suggestions are coming from a "believer", not someone
wanting to understand the limitations of python or whether v3 has
succeeded at achieving its potential.

>>> I don't even understand what you are talking about here. "[reference]
>>> variables"? What does that mean?
>>
>> It's a just a tricky point, that I will wait to comment on.
>
> I'm looking forward to an explanation, as I'm intrigued.

Well, wer'e here at junior-high.  It will take some time....
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#54101

On Thu, 12 Sep 2013 20:23:21 -0700, Mark Janssen wrote:

>>> Really?  Are you saying you (and the community at-large) always derive
>>> from Object as your base class?
>>
>> Not directly, that would be silly.
> 
> Silly?  "Explicit is better than implicit"... right?

If I'm inheriting from str, I inherit from str explicitly:

class MyStr(str): ...

and then str in turn inherits from object explicitly. I certainly do not 
inherit from object and then re-implement all the string methods from 
scratch:

class MyStr(object):
    def __new__(cls, value): ...
    def upper(self): ... 
    def lower(self): ...
    # and so on...

That would be ridiculous, and goes against the very idea of inheritance. 
But nor do I feel the need to explicitly list the entire superclass 
hierarchy:

class MyStr(str, object):
    ...


which would be silly. Only somebody who doesn't understand how 
inheritance works in Python would do that. There's simply no need for it, 
and in fact it would be actively harmful for larger hierarchies.


>>> But wait is it the "base" (at the bottom of the hierarchy) or is it
>>> the "parent" at the top?  You see, you, like everyone else has been
>>> using these terms loosely, confusing yourself.
>>
>> Depends on whether I'm standing on my head or not.
>>
>> Or more importantly, it depends on whether I visualise my hierarchy
>> going top->down or bottom->up. Both are relevant, and both end up with
>> the *exact same hierarchy* with only the direction reversed.
> 
> Ha,  "only the direction reversed".  That little directionality that
> you're passing by so blithely is the difference between whether you're
> talking about galaxies or atoms.

It makes no difference whether I write:

    atoms -> stars -> galaxies

or

    galaxies <- stars <- atoms

nor does it make any difference if I write the chain starting at the top 
and pointing down, or at the bottom and pointing up.

Your objection implies that writing family trees with the most distant 
ancestor (the root of the tree) at the top of the page somehow confuses 
people into thinking that perhaps they are the progenitor of people who 
lived generations earlier. That's absurd -- people simply are not as 
stupid as you think.


> The simplicity of Python has seduced you into making an "equivocation"
> of sorts.  It's subtle and no one in the field has noticed it.  It crept
> in slowly and imperceptively.

Ah, and now we come to the heart of the matter -- people have been 
drawing tree-structures with the root at the top of the page for 
centuries, and Mark Janssen is the first person to have realised that 
they've got it all backwards.


>>> By inheriting from sets you get a lot of useful functionality for
>>> free.  That you don't know how you could use that functionality is a
>>> failure of your imagination, not of the general idea.
>>
>> No you don't. You get a bunch of ill-defined methods that don't make
>> sense on dicts.
> 
> They are not necessarily ill-defined.  Keep in mind Python already chose
> (way back in 1.x) to arbitrary overwrite the values in a key collision. 
> So this problem isn't new.  You've simply adapted to this limitation
> without knowing what you were missing.

No, Python didn't "arbitrarily" choose this behaviour. It is standard, 
normal behaviour for a key-value mapping, and it is the standard 
behaviour because it is the only behaviour that makes sense for a general 
purpose mapping.

Python did not invent dicts (although it may have invented the choice of 
name "dict").

If you think of inheritance in the Liskov Substitution sense, then you 
might *consider* building dicts on top of sets. But it doesn't really 
work, because there is no way to sensibly keep set-behaviour for dicts.

For example, take intersection of two sets s and t. It is a basic 
principle of set intersection that s&t == t&s.

But now, take two dicts with the same keys but different values, d and e. 
What values should be used when calculating d&e compared to e&d? Since 
they are different values, we can either:

* prefer the values from the left argument over that from the right;
* prefer the values from the right argument over that from the left;
* refuse to choose and raise an exception;
* consider the intersection empty

The first three choices will break the Liskov Substitution Principle, 
since now dicts *cannot* be substituted for sets. The fourth also breaks 
Liskov, but for a different reason:

# sets
(key in s) and (key in t) implies (key in s&t);

but

# dicts
(key in d) and (key in e) *does not* imply (key in d&e)


So whatever you do, you are screwed Liskov-wise. You cannot derive dicts 
from sets and still keep the Liskov Substitution Principle.

Of course, LSP is not the only way to design your inheritance 
hierarchies. An alternative is to design them in terms of delegating 
implementation to the superclass. As Raymond Hettinger puts it, your 
classes tells it's parent to do some of the work. But in this case, 
you're still screwed: you can derive sets from dicts, and in fact the 
first implementation of sets in Python did exactly that, but you cannot 
derive dicts from sets.

So either way, whether you are an OOP purist who designs your classes 
with type-theoretic purity and the Liskov Substitution Principle in mind, 
or a pragmatist who designs your classes with delegation of 
implementation in mind, you can't sensibly derive dicts from sets.


>>>>> 3) It used the set literal for dict, so that there's no obvious way
>>>>> to do it.  This didn't get changed in Py3k.
>>>>
>>>> No, it uses the dict literal for dicts.
>>>
>>> Right.  The dict literal should be {:} -- the one obvious way to do
>>> it.
>>
>> I don't agree it is obvious. It is as obvious as (,) being the empty
>> tuple or [,] being the empty list.
> 
> You're just being argumentative.  If there are sets as built-ins, then
> {:} is the obvious dict literal, because {} is the obvious one for set. 
> You don't need [,] to be the list literal because there is no simpler
> list-type.

The point is that the obvious way to write an empty collection is using a 
pair of delimiters, not to shove an arbitrary separator separating 
nothing at all in there:

[] is an empty list, not [,]
() is an empty tuple, not (,)
{} is an empty (dict|set), not {,} or {:}


We can't have {} be both an empty set and an empty dict, so one of the 
two has to miss out. Neither is more obvious than the other. dicts are 
more important data structures, and they have historical precedence, so 
they win. If Python was being re-invented from scratch now, or if sets 
had been around just as long as dicts, people might have chosen to given 
sets higher priority than dicts, but frankly I doubt it. It's much more 
common to want an empty dict than an empty set, at least in my experience.

 
>>>> And the obvious way to form an empty set is by calling set(), the
>>>> same as str(), int(), list(), float(), tuple(), dict(), ...
>>>
>>> Blah, blah.  Let me know when you got everyone migrated over to
>>> Python.v3.
>>
>> What does this have to do with Python 3? It works fine in Python 2.
> 
> I mean, you're suggestions are coming from a "believer", not someone
> wanting to understand the limitations of python or whether v3 has
> succeeded at achieving its potential.

"not someone wanting to understand the limitations of python..." -- are 
you aware that I started this thread?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#54106

On Fri, Sep 13, 2013 at 3:08 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> For example, take intersection of two sets s and t. It is a basic
> principle of set intersection that s&t == t&s.

Note that, while this is true, the two are not actually identical:

>>> set1 = {0,1,2}
>>> set2 = {0.0,1.0,3.0}
>>> set1&set2
{0.0, 1.0}
>>> set2&set1
{0, 1}
>>> (set1&set2) == (set2&set1)
True

I'd actually posit that Python has this particular one backward (I'd
be more inclined to keep the left operand's value), but it's
completely insignificant to most usage. But in any case, there's
already the possibility that a set union can be forced to make a
choice between two equal objects, so we're already a bit beyond the
purity of mathematics. Python could have implemented dicts much more
like "sets with values", with set semantics maintained throughout, but
it'd require some oddities:

>>> {1:"asdf"} == {1:"asdf"}
True
>>> {1:"asdf"} == {1:"qwer"}
False

"Sets with values" semantics would demand that these both be True,
which is grossly unintuitive.

So while it may be true in pure mathematics that a set is-a dict (or a
dict is-a set), it's bound to create at least as many gotchas as it
solves.

ChrisA

[toc] | [prev] | [next] | [standalone]

#54180

>>>> Really?  Are you saying you (and the community at-large) always derive
>>>> from Object as your base class?
>>>
>>> Not directly, that would be silly.
>>
>> Silly?  "Explicit is better than implicit"... right?
>
> If I'm inheriting from str, I inherit from str explicitly:
>
> class MyStr(str): ...
>
> and then str in turn inherits from object explicitly. I certainly do not
> inherit from object and then re-implement all the string methods from
> scratch:

I know that.  Str already inherits from object (due to the language
definition).  Your inheritance from object is implied by your
inheritance from a child class (str), but note there is an implied
directionality:  you don't say str is the parent of object.  But tell
me this:  is str the superclass of object or is it the other way
around?

> class MyStr(object):
>     def __new__(cls, value): ...
>     def upper(self): ...
>     def lower(self): ...
>     # and so on...
>
> That would be ridiculous, and goes against the very idea of inheritance.
> But nor do I feel the need to explicitly list the entire superclass
> hierarchy:
>
> class MyStr(str, object):
>     ...

Now you've lost your marbles.  You are arguing points that a python
programmer would not argue.  Now, since I know you to be a decent
python programmer, I can only conclude that your sanity is in
question.

> which would be silly. Only somebody who doesn't understand how
> inheritance works in Python would do that. There's simply no need for it,
> and in fact it would be actively harmful for larger hierarchies.

Explicitly inheriting from object ("class myBase(object):" rather than
"class myBase():") would not be "actively harmful" in any way.

>>>> But wait is it the "base" (at the bottom of the hierarchy) or is it
>>>> the "parent" at the top?  You see, you, like everyone else has been
>>>> using these terms loosely, confusing yourself.
>>>
>>> Depends on whether I'm standing on my head or not.
>>>
>>> Or more importantly, it depends on whether I visualise my hierarchy
>>> going top->down or bottom->up. Both are relevant, and both end up with
>>> the *exact same hierarchy* with only the direction reversed.
>>
>> Ha,  "only the direction reversed".  That little directionality that
>> you're passing by so blithely is the difference between whether you're
>> talking about galaxies or atoms.
>
> It makes no difference whether I write:
>
>     atoms -> stars -> galaxies
>
> or
>
>     galaxies <- stars <- atoms
>
> nor does it make any difference if I write the chain starting at the top
> and pointing down, or at the bottom and pointing up.

Here again, your sanity is questioned.  You are simply wrong.  Atoms
lie within galaxies, but galaxies do not lie within atoms (poetic
license excluded); i.e. there is a difference, whether your talking
about syntactically by the parser or conceptually by a human being.
Somewhere you have to put yourself in the middle.  And that point
defines how you relate to the machine -- towards abstraction (upwards)
or towards the concrete (to the machine itself).

>> The simplicity of Python has seduced you into making an "equivocation"
>> of sorts.  It's subtle and no one in the field has noticed it.  It crept
>> in slowly and imperceptively.
>
> Ah, and now we come to the heart of the matter -- people have been
> drawing tree-structures with the root at the top of the page for
> centuries, and Mark Janssen is the first person to have realised that
> they've got it all backwards.

I'll be waiting for your apology once you simply grasp the simple
(however inconvenient and unbelievable) truth. ;*)

>>>> By inheriting from sets you get a lot of useful functionality for
>>>> free.  That you don't know how you could use that functionality is a
>>>> failure of your imagination, not of the general idea.
>>>
>>> No you don't. You get a bunch of ill-defined methods that don't make
>>> sense on dicts.
>>
>> They are not necessarily ill-defined.  Keep in mind Python already chose
>> (way back in 1.x) to arbitrary overwrite the values in a key collision.
>> So this problem isn't new.  You've simply adapted to this limitation
>> without knowing what you were missing.
>
> No, Python didn't "arbitrarily" choose this behaviour.

Perhaps you don't recall the discussion.

> It is standard,
> normal behaviour for a key-value mapping, and it is the standard
> behaviour because it is the only behaviour that makes sense for a general
> purpose mapping.

No.  Please don't propagate your limited sense of things as if it "the
only way to do it".

> Python did not invent dicts (although it may have invented the choice of
> name "dict").
>
> If you think of inheritance in the Liskov Substitution sense, then you
> might *consider* building dicts on top of sets. But it doesn't really
> work, because there is no way to sensibly keep set-behaviour for dicts.

There's no need to preserve LSP -- it's just one way to think about
class relations.  In fact, I'll argue that one should not -- because
the field has not perfected the object model adequately, so it would
lead to a suboptimal situation akin to premature optimization.   The
conceptual abstraction is most important:  a subtype (child class)
should do everything that its parent does.

(That's far from a complete definition, but I'm just laying the
groundwork to start to understand the breadth of ideas and in this
landscape of OOP and how they relate to each other.)

> For example, take intersection of two sets s and t. It is a basic
> principle of set intersection that s&t == t&s.

That's called "commutation", grasshopper.  That's the word you want to use.

> But now, take two dicts with the same keys but different values, d and e.
> What values should be used when calculating d&e compared to e&d? Since
> they are different values, we can either:
>
> * prefer the values from the left argument over that from the right;
> * prefer the values from the right argument over that from the left;

...the way python effectively does it:  d1.update(d2) -- the values in
d2 overwrite the values in d1.  This is a semi-arbitrary decision.

But here's how it should be done:  any (op)eration:  d1 op d2, should
first apply op to the keys of (d1,d2), and then again apply to the
values in a recursive fashion to the values.  Now one will have to
define what should happen for things like __sub__ and such but at
least we have a solid framework for starting to think about it in a
more sophisticated way.

> * refuse to choose and raise an exception;
> * consider the intersection empty
>
> The first three choices will break the Liskov Substitution Principle,
> since now dicts *cannot* be substituted for sets. The fourth also breaks
> Liskov, but for a different reason:

I'm not going to evaluate your claim because I don't care about LSP.
Why you obsess over it is simply because it's how you've come to make
sense of the confusion that is in the field.

> # sets
> (key in s) and (key in t) implies (key in s&t);
>
> but
>
> # dicts
> (key in d) and (key in e) *does not* imply (key in d&e)
>

Eh?  How so?  There is a straightforward and obvious mapping from a
dict to a set, so your last line could be re-written as key in
(set(d)&set(e)) where it is clear that it *is* indeed equivalent.

> So either way, whether you are an OOP purist who designs your classes
> with type-theoretic purity and the Liskov Substitution Principle in mind,
> or a pragmatist who designs your classes with delegation of
> implementation in mind, you can't sensibly derive dicts from sets.

You *can* sensibly derive dicts from sets, because there is a clear
function that can map a dict to a set.  The dict, then, is just a
specialization of set.

As an attempt to try to nail this terminology down.  There's
"extending" a type, and there's "specializing" a type.  One adds more
methods and one refines what the methods do.  They are different.

>>>> Right.  The dict literal should be {:} -- the one obvious way to do
>>>> it.
>>>
>>> I don't agree it is obvious. It is as obvious as (,) being the empty
>>> tuple or [,] being the empty list.
>>
>> You're just being argumentative.  If there are sets as built-ins, then
>> {:} is the obvious dict literal, because {} is the obvious one for set.
>> You don't need [,] to be the list literal because there is no simpler
>> list-type.
>
> The point is that the obvious way to write an empty collection is using a
> pair of delimiters, not to shove an arbitrary separator separating
> nothing at all in there:

It's not a arbitrary separator, it is the obvious one, given that set
is already using the the empty curly braces and dict uses the colon as
a separator.

>>>>> And the obvious way to form an empty set is by calling set(), the
>>>>> same as str(), int(), list(), float(), tuple(), dict(), ...
>>>>
>>>> Blah, blah.  Let me know when you got everyone migrated over to
>>>> Python.v3.
>>>
>>> What does this have to do with Python 3? It works fine in Python 2.
>>
>> I mean, you're suggestions are coming from a "believer", not someone
>> wanting to understand the limitations of python or whether v3 has
>> succeeded at achieving its potential.
>
> "not someone wanting to understand the limitations of python..." -- are
> you aware that I started this thread?

Hence, the irony.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#54184

Op 15-09-13 04:37, Mark Janssen schreef:

>>>
>>> Ha,  "only the direction reversed".  That little directionality that
>>> you're passing by so blithely is the difference between whether you're
>>> talking about galaxies or atoms.
>>
>> It makes no difference whether I write:
>>
>>      atoms -> stars -> galaxies
>>
>> or
>>
>>      galaxies <- stars <- atoms
>>
>> nor does it make any difference if I write the chain starting at the top
>> and pointing down, or at the bottom and pointing up.
>
> Here again, your sanity is questioned.  You are simply wrong.  Atoms
> lie within galaxies, but galaxies do not lie within atoms (poetic
> license excluded);

No body is questioning that. What is being pointed out is, that it 
doesn't make a difference whether you say that atoms lie within galaxies 
or you say galaxies have atoms in them. It doesn't matter which of the 
items you mention first in defining the relation between the two.

> i.e. there is a difference, whether your talking
> about syntactically by the parser or conceptually by a human being.
> Somewhere you have to put yourself in the middle.  And that point
> defines how you relate to the machine -- towards abstraction (upwards)
> or towards the concrete (to the machine itself).

Maybe, but where you put yourself is not determined by such unimportant 
details as to which of the components in a relation you mention first. a 
< b or b > a, are two ways to write the exact same relation and someone 
arguing that there is an important difference because in the first case 
we mention a first while in the second case we mention b first is only 
illustrating his own confusion. And that is essentially
what you are doing.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#54022

On 9/11/2013 8:49 PM, Mark Janssen wrote:
>>> 1) It tried to make Object the parent of every class.
>>
>> Tried, and succeeded.
>
> Really?  Are you saying you (and the community at-large) always derive
> from Object as your base class?

The name is 'object', and yes, everyone does it because it is automatic. 
(I am including indirect inheritance, and excluding weird metaclass games.)

 >>> class C(): pass

 >>> dir(C)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', 
'__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__']

Just *where* do you think all those methods come from.

>>> C.__bases__
(<class 'object'>,)

> But wait is it the "base" (at the bottom of the hierarchy) or is it
> the "parent" at the top?

This sort of quibbling should be beneath you.

> A dict is-a set of {key:object, key:object} pairs bound together with
> a colon ":".

Yes... but there is a very important additional condition: each key 
appears only once.

Humans are primates, but that is not a sufficient characterization.

 > By inheriting from sets you get a lot of useful
> functionality for free.

Actually, you get a lot of un-useful functionality for free. Because of 
the extra condition, the rule for adding a key:object pair to a dict is 
different from the rule for adding a key:object pair to a set of such 
pairs. The set-union of two dicts is not necessarily a dict. To put is 
another way, dicts as set subclasses would violate the Liskov 
Substitution Principle.

'Homogenous' sets (of strings, numbers) would be proper subclasses of set.

> Right.  The dict literal should be {:}

and the set literal 'should' be {}, and would be if Python were 
redesigned from scratch. Is your imagination so stunted that you 
actually think we did not discuss that when designing Python 3?
We did, but Guido rejected switching because he thought it would cause 
too much pain and discourage adoption of Python 3 even more than the 
other code-breaking changes that were made.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#54023

On Thu, Sep 12, 2013 at 10:49 AM, Mark Janssen
<dreamingforward@gmail.com> wrote:
>>> 1) It tried to make Object the parent of every class.
>>
>> Tried, and succeeded.
>
> Really?  Are you saying you (and the community at-large) always derive
> from Object as your base class?

Uhh, yep? It kinda happens automatically for me:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600
32 bit (Intel)] on win32
>>> class Foo:
    pass
>>> Foo.__bases__
(<class 'object'>,)

Yeah, I think I'm always deriving from object. Also, if ever I write
code that has to run also on 2.x, I'll do that explicitly, to be sure
it works the same way.

ChrisA

[toc] | [prev] | [next] | [standalone]

#54000

On 09/11/2013 01:41 PM, Markus Rother wrote:
>
>      4. As has been mentioned already, some built-in functions do magic
>      stuff behind the scenes:

That's why they're called magic methods.  ;)


>      >>> () == []
>      False
>
>      But:
>
>      >>> bool(().__eq__([]))
>      True

This is not a trap, this is simply the wrong way to do it.  The magic methods (aka dunder methods) are there for Python 
to call, not you (except under special circumstances, such as when writing your own dunder methods).

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#54003

Mark Janssen wrote:
> 1) It tried to make Object the parent of every class.  No one's close
> enough to God to make that work.
> 2) It didn't make dicts inherit from sets when they were added to Python.
> 3) It used the set literal for dict, so that there's no obvious way to
> do it.  This didn't get changed in Py3k.
> 4?) It allowed [reference] variables to be used as dict keys.  This
> creates a parsing difficulty for me, mentally.  Keys should be direct,
> hashable values, not hidden in a variable name.

What do you mean by 4? Do you mean that keys should only be hardcoded?
I am going to assume you meant something different, as that sounds like
a terrible idea to me...

> 
> A few of the top of the head....
> 
> Mark

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

[toc] | [prev] | [next] | [standalone]

#54004

Wayne Werner <wayne@waynewerner.com> writes:

> On Tue, 10 Sep 2013, Ben Finney wrote:
> >  The sooner we replace the erroneous
> >  “text is ASCII” in the common wisdom with “text is Unicode”, the
> >  better.
>
> I'd actually argue that it's better to replace the common wisdom with
> "text is binary data, and we should normally look at that text through
> Unicode eyes". A little less catchy, but more accurate ;)

No, that's inaccurate. A sequence of bytes is binary data. Unicode is
not binary data.

There are encodings which map Unicode to a sequence of bytes, but text is
not binary data.

-- 
 \       “For fast acting relief, try slowing down.” —Jane Wagner, via |
  `\                                                       Lily Tomlin |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#54005 — Please omit false legalese footers (was: Language design)

"Prasad, Ramit" <ramit.prasad@jpmorgan.com.dmarc.invalid> writes:

> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of securities,
> accuracy and completeness of information, viruses, confidentiality,
> legal privilege, and legal entity disclaimers, available at
> http://www.jpmorgan.com/pages/disclosures/email.

No, your message was not confidential. You sent it to a public mailing
list, presumably by choice. So please omit such false and pointless
legal rubbish from your messages here.

-- 
 \        “I'd take the awe of understanding over the awe of ignorance |
  `\                                          any day.” —Douglas Adams |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#54082 — Re: Please omit false legalese footers (was: Language design)

On 2013-09-11, Ben Finney <ben+python@benfinney.id.au> wrote:
> "Prasad, Ramit" <ramit.prasad@jpmorgan.com.dmarc.invalid> writes:
>
>> This email is confidential and subject to important disclaimers and
>> conditions including on offers for the purchase or sale of securities,
>> accuracy and completeness of information, viruses, confidentiality,
>> legal privilege, and legal entity disclaimers, available at
>> http://www.jpmorgan.com/pages/disclosures/email.
>
> No, your message was not confidential. You sent it to a public
> mailing list, presumably by choice. So please omit such false and
> pointless legal rubbish from your messages here.

OTOH, perhaps it was confidential.  In which case, J. P. Morgan might
want to know that ramit.prasad is sending confidential information to
a pulic mailing list.

-- 
Grant Edwards               grant.b.edwards        Yow! BARRY ... That was
                                  at               the most HEART-WARMING
                              gmail.com            rendition of "I DID IT MY
                                                   WAY" I've ever heard!!

[toc] | [prev] | [next] | [standalone]

#54006

On Thu, Sep 12, 2013 at 6:41 AM, Markus Rother <python@markusrother.de> wrote:
>     3. The default return value of methods is None instead of self.
>     If it was self, it would be possible to chain method calls (which
>     is called a cascade in smalltalk).
>
>
>     >>> lst = []
>     >>> lst.append(1).append(2).append(3) ## FAIL
>     Traceback (most recent call last):
>     ...
>     AttributeError: 'NoneType' object has no attribute 'append'

That's a policy decision: a method (or function) will *EITHER* return
a value, *OR* mutate its primary argument (in the case of a method,
that's self). It reduces the chances of code like this:

foo = [1, 4, 2, 8, 5, 7]
largest_digit = foo.sort()[-1]
one_seventh = ''.join(map(str,foo))

If you used sorted(foo) instead of foo.sort(), this wouldn't crash
out, and it'd do what you expect. Having foo.sort() return self would
mean this wouldn't crash, but would potentially do something
surprising.

But while I understand the reasoning behind it, I don't entirely
agree. There are times when I use Pike's sort() function [1], which
does return its mutated argument, something like this:

foo = sort(blah_blah_blah())

Why should that be split into two statements? Or alternatively, why
should an extra copy of the list be created (if you use Python's
sorted() here)? But for the new programmer, this is a convenient
safety-net, and if list.sort() worked the other way, it'd be just as
much a gotcha ("I ask for a sorted list, and it also changed the
original?!??").

ChrisA

[1] http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/sort.html

[toc] | [prev] | [next] | [standalone]

#54007

Mark Janssen <dreamingforward@gmail.com> writes:

> > * Imports are fiendishly complex, hidden below deceptively simple
> >   syntax.
> >
> >   It's a reasonable expectation that one can import a module from a
> >   source code file given its path on the filesystem, but this turns out
> >   to be much more complicated than in many other languages.
>
> Why is this so difficult?

I don't know, you'll have to ask the people who designed it that way.

> Add a Graph class to the collections module (networkx is quite good)
> and simply check for circular imports.

Er? That doesn't address the task of importing a module from a source
code file given its path on the filesystem.

Other languages have the equivalent of ‘include "/path/to/file.py"’, but
Python doesn't. That's the misdesign I'm describing.

-- 
 \      “Just because nobody complains doesn't mean all parachutes are |
  `\                                             perfect.” —Benny Hill |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#54011

On 9/11/2013 7:19 PM, Ben Finney wrote:

> Er? That doesn't address the task of importing a module from a source
> code file given its path on the filesystem.
>
> Other languages have the equivalent of ‘include "/path/to/file.py"’,

Some includes are equivalent to

with open("/path/to/file.py") as f:
   exec(f.read())

> but Python doesn't.

which Python does have.

Python also has __import__("/path/to/file.py"), which is used by import 
when the module does not exist.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#54014

>> On Tue, 10 Sep 2013, Ben Finney wrote:
>> >  The sooner we replace the erroneous
>> >  “text is ASCII” in the common wisdom with “text is Unicode”, the
>> >  better.
>>
>> I'd actually argue that it's better to replace the common wisdom with
>> "text is binary data, and we should normally look at that text through
>> Unicode eyes". A little less catchy, but more accurate ;)
>
> No, that's inaccurate. A sequence of bytes is binary data. Unicode is
> not binary data.

Well now, this is an area that is not actually well-defined.  I would
say 16-bit Unicode is binary data if you're encoding in base 65,536,
just as 8-bit ascii is binary data if you're encoding in base-256.
Which is to say:  there is no intervening data to suggest a TYPE.
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web