Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python 3.0 - is this true?

Reply
Thread Tools

Python 3.0 - is this true?

 
 
Roy Smith
Guest
Posts: n/a
 
      11-09-2008
In article <(E-Mail Removed)-berlin.de>,
"Diez B. Roggisch" <(E-Mail Removed)> wrote:

> >
> > Also, I thought that part of the python philosophy was to allow any
> > sort of object in a list, and to allow the same methods to work with
> > whatever was in list.

>
> Not really. When the usual argument about the existence (and
> justification) of lists & tuples comes along, one common distinction is
> that
>
> - tuples contain arbitrary object of varying types, so they are kind
> of "records"
> - lists should contain uniform objects.


I see absolutely nothing wrong with lists of heterogenous types. Or, for
that matter, iterators which generate heterogeneous types. Here's some
perfectly reasonable examples (equally applicable to lists or iterators):

* The tokens parsed out of a file (ints, floats, identifiers, keywords,
various kinds of punctuation, etc)

* The entries in a unix directory (plain files, directories, symlinks,
special files, named sockets, etc)

* The vehicles going through a toll booth (cars, trucks, motorcycles)

I don't see any reason you shouldn't be able to build lists of those things.
 
Reply With Quote
 
 
 
 
Diez B. Roggisch
Guest
Posts: n/a
 
      11-09-2008
Roy Smith schrieb:
> In article <(E-Mail Removed)-berlin.de>,
> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>
>>> Also, I thought that part of the python philosophy was to allow any
>>> sort of object in a list, and to allow the same methods to work with
>>> whatever was in list.

>> Not really. When the usual argument about the existence (and
>> justification) of lists & tuples comes along, one common distinction is
>> that
>>
>> - tuples contain arbitrary object of varying types, so they are kind
>> of "records"
>> - lists should contain uniform objects.

>
> I see absolutely nothing wrong with lists of heterogenous types. Or, for
> that matter, iterators which generate heterogeneous types. Here's some
> perfectly reasonable examples (equally applicable to lists or iterators):
>
> * The tokens parsed out of a file (ints, floats, identifiers, keywords,
> various kinds of punctuation, etc)
>
> * The entries in a unix directory (plain files, directories, symlinks,
> special files, named sockets, etc)
>
> * The vehicles going through a toll booth (cars, trucks, motorcycles)
>
> I don't see any reason you shouldn't be able to build lists of those things.


When I wrote "uniform" I meant objects of the same kind. So for example
subclasses are of course ok. And all of your examples are these: I want
a Token-object, keeping file-location and possibly original string
representation. The same goes for files - they are simply strings, their
properties determined using stat-calls. And vehicles are... vehicles. So
I'd create a common base-class for them, or made them at least behave
proper through duck-typing. Which - for the case at hand - might include
creating a __cmp__-method, based on horsepower or price-tag or...

Diez
 
Reply With Quote
 
 
 
 
Stefan Behnel
Guest
Posts: n/a
 
      11-09-2008
Duncan Booth wrote:
> Roy Smith wrote:
>
>> In 3.0, can you still order types? In 2.x, you can do:
>>
>>>>> t1 = type(1)
>>>>> t2 = type(1j)
>>>>> t1 < t2

>> False
>>
>> If this still works in 3.0, then you can easily do something like:
>>
>> def total_order(o1, o2):
>> "Compare any two objects of arbitrary types"
>> try:
>> return o1 <= o2
>> except UncomparableTypesError: # whatever the right name is
>> return type(o1) <= type(o2)
>>
>> and get the same effect as you had in 2.x.

>
> No, that won't work. You can compare types for equality/inequality, but
> they are not orderable:
>
>>>> type(1)==type('a')

> False
>>>> sorted([1, 'a'], key=lambda xtype(x),x))

> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: unorderable types: type() < type()


However, for an arbitrary ordering of types, id(type(o1)) <= id(type(o2)) will
work well enough.

Stefan
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      11-09-2008
In article <(E-Mail Removed)-berlin.de>,
"Diez B. Roggisch" <(E-Mail Removed)> wrote:

> Roy Smith schrieb:
> > In article <(E-Mail Removed)-berlin.de>,
> > "Diez B. Roggisch" <(E-Mail Removed)> wrote:
> >
> >>> Also, I thought that part of the python philosophy was to allow any
> >>> sort of object in a list, and to allow the same methods to work with
> >>> whatever was in list.
> >> Not really. When the usual argument about the existence (and
> >> justification) of lists & tuples comes along, one common distinction is
> >> that
> >>
> >> - tuples contain arbitrary object of varying types, so they are kind
> >> of "records"
> >> - lists should contain uniform objects.

> >
> > I see absolutely nothing wrong with lists of heterogenous types. Or, for
> > that matter, iterators which generate heterogeneous types. Here's some
> > perfectly reasonable examples (equally applicable to lists or iterators):
> >
> > * The tokens parsed out of a file (ints, floats, identifiers, keywords,
> > various kinds of punctuation, etc)
> >
> > * The entries in a unix directory (plain files, directories, symlinks,
> > special files, named sockets, etc)
> >
> > * The vehicles going through a toll booth (cars, trucks, motorcycles)
> >
> > I don't see any reason you shouldn't be able to build lists of those things.

>
> When I wrote "uniform" I meant objects of the same kind. So for example
> subclasses are of course ok. And all of your examples are these: I want
> a Token-object, keeping file-location and possibly original string
> representation.


Maybe, but only if the logic of my program says that's the right way to do
it. If I decide that the appropriate way to return an integer is by
returning something of type(int), that's my business. Why should I have to
define a Token class if using the native Python types works just as well
for what I'm doing? I'll write class Token when there's some added value
I get from it which I can't get with raw types. I don't want to be forced
into it just because a container doesn't like what I'm doing.

I spend too much time in C++ pleading with the compiler to allow me to do
what I want. I come to Python to get away from all that type bondage.

As another example, consider a list of items being juggled:

[RubberChicken(), ChainSaw(), Canteloupe()]

I could go through contortions to find some common subclass for these
items, but the whole *point* is that they're not of the same type. And
making a list of them is a perfectly reasonable thing to do.
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      11-09-2008
In article <(E-Mail Removed)>,
Duncan Booth <(E-Mail Removed)> wrote:

> Roy Smith wrote:
>
> > In 3.0, can you still order types? In 2.x, you can do:
> >
> >>>> t1 = type(1)
> >>>> t2 = type(1j)
> >>>> t1 < t2

> > False
> >
> > If this still works in 3.0, then you can easily do something like:
> >
> > def total_order(o1, o2):
> > "Compare any two objects of arbitrary types"
> > try:
> > return o1 <= o2
> > except UncomparableTypesError: # whatever the right name is
> > return type(o1) <= type(o2)
> >
> > and get the same effect as you had in 2.x.

>
> No, that won't work. You can compare types for equality/inequality, but
> they are not orderable:
>
> >>> type(1)==type('a')

> False
> >>> sorted([1, 'a'], key=lambda xtype(x),x))

> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: unorderable types: type() < type()


Sigh. So if I really wanted to do that, I'd be forced to write
"str(type(o1)) < str(type(o2))"? To me, that sounds suspiciously like
"sudo type(o1) < type(o2)"
 
Reply With Quote
 
Marc 'BlackJack' Rintsch
Guest
Posts: n/a
 
      11-09-2008
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:

> In article <(E-Mail Removed)-berlin.de>,
> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>> Roy Smith schrieb:
>>> In article <(E-Mail Removed)-berlin.de>,
>>> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>>>

>> When I wrote "uniform" I meant objects of the same kind. So for example
>> subclasses are of course ok. And all of your examples are these: I want
>> a Token-object, keeping file-location and possibly original string
>> representation.

>
> Maybe, but only if the logic of my program says that's the right way to
> do it. If I decide that the appropriate way to return an integer is by
> returning something of type(int), that's my business. Why should I have
> to define a Token class if using the native Python types works just as
> well for what I'm doing? I'll write class Token when there's some
> added value I get from it which I can't get with raw types.


One added value in Python┬*3.0 would be that they are sortable in a
`list`. But seriously, your token example should work fine with
Python┬*3.0 because the wish to sort tokens is a bit exotic IMHO.

> I don't want to be forced into it just because a container doesn't like
> what I'm doing.


The container doesn't say what *you* can do with the content, it is just
a bit picky about what the container itself can do. If a function or
method doesn't like something about the arguments it's perfectly okay to
raise a `TypeError` or a `ValueError`.

> As another example, consider a list of items being juggled:
>
> [RubberChicken(), ChainSaw(), Canteloupe()]
>
> I could go through contortions to find some common subclass for these
> items, but the whole *point* is that they're not of the same type.


They are of the same duck type "things to be juggled". And if you use a
method on them they have to implement that. Not necessarily through
inheritance.

> And making a list of them is a perfectly reasonable thing to do.


And possible with current Python and Python┬*3.0.

Ciao,
Marc 'BlackJack' Rintsch
 
Reply With Quote
 
Marc 'BlackJack' Rintsch
Guest
Posts: n/a
 
      11-09-2008
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:

> In article <(E-Mail Removed)-berlin.de>,
> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>> Roy Smith schrieb:
>>> In article <(E-Mail Removed)-berlin.de>,
>>> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>>>

>> When I wrote "uniform" I meant objects of the same kind. So for example
>> subclasses are of course ok. And all of your examples are these: I want
>> a Token-object, keeping file-location and possibly original string
>> representation.

>
> Maybe, but only if the logic of my program says that's the right way to
> do it. If I decide that the appropriate way to return an integer is by
> returning something of type(int), that's my business. Why should I have
> to define a Token class if using the native Python types works just as
> well for what I'm doing? I'll write class Token when there's some
> added value I get from it which I can't get with raw types.


One added value in Python┬*3.0 would be that they are sortable in a
`list`. But seriously, your token example should work fine with
Python┬*3.0 because the wish to sort tokens is a bit exotic IMHO.

> I don't want to be forced into it just because a container doesn't like
> what I'm doing.


The container doesn't say what *you* can do with the content, it is just
a bit picky about what the container itself can do. If a function or
method doesn't like something about the arguments it's perfectly okay to
raise a `TypeError` or a `ValueError`.

> As another example, consider a list of items being juggled:
>
> [RubberChicken(), ChainSaw(), Canteloupe()]
>
> I could go through contortions to find some common subclass for these
> items, but the whole *point* is that they're not of the same type.


They are of the same duck type "things to be juggled". And if you use a
method on them they have to implement that. Not necessarily through
inheritance.

> And making a list of them is a perfectly reasonable thing to do.


And possible with current Python and Python┬*3.0.

Ciao,
Marc 'BlackJack' Rintsch
 
Reply With Quote
 
Marc 'BlackJack' Rintsch
Guest
Posts: n/a
 
      11-09-2008
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:

> In article <(E-Mail Removed)-berlin.de>,
> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>> Roy Smith schrieb:
>>> In article <(E-Mail Removed)-berlin.de>,
>>> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>>>

>> When I wrote "uniform" I meant objects of the same kind. So for example
>> subclasses are of course ok. And all of your examples are these: I want
>> a Token-object, keeping file-location and possibly original string
>> representation.

>
> Maybe, but only if the logic of my program says that's the right way to
> do it. If I decide that the appropriate way to return an integer is by
> returning something of type(int), that's my business. Why should I have
> to define a Token class if using the native Python types works just as
> well for what I'm doing? I'll write class Token when there's some
> added value I get from it which I can't get with raw types.


One added value in Python┬*3.0 would be that they are sortable in a
`list`. But seriously, your token example should work fine with
Python┬*3.0 because the wish to sort tokens is a bit exotic IMHO.

> I don't want to be forced into it just because a container doesn't like
> what I'm doing.


The container doesn't say what *you* can do with the content, it is just
a bit picky about what the container itself can do. If a function or
method doesn't like something about the arguments it's perfectly okay to
raise a `TypeError` or a `ValueError`.

> As another example, consider a list of items being juggled:
>
> [RubberChicken(), ChainSaw(), Canteloupe()]
>
> I could go through contortions to find some common subclass for these
> items, but the whole *point* is that they're not of the same type.


They are of the same duck type "things to be juggled". And if you use a
method on them they have to implement that. Not necessarily through
inheritance.

> And making a list of them is a perfectly reasonable thing to do.


And possible with current Python and Python┬*3.0.

Ciao,
Marc 'BlackJack' Rintsch
 
Reply With Quote
 
Marc 'BlackJack' Rintsch
Guest
Posts: n/a
 
      11-09-2008
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:

> In article <(E-Mail Removed)-berlin.de>,
> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>> Roy Smith schrieb:
>>> In article <(E-Mail Removed)-berlin.de>,
>>> "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>>>

>> When I wrote "uniform" I meant objects of the same kind. So for example
>> subclasses are of course ok. And all of your examples are these: I want
>> a Token-object, keeping file-location and possibly original string
>> representation.

>
> Maybe, but only if the logic of my program says that's the right way to
> do it. If I decide that the appropriate way to return an integer is by
> returning something of type(int), that's my business. Why should I have
> to define a Token class if using the native Python types works just as
> well for what I'm doing? I'll write class Token when there's some
> added value I get from it which I can't get with raw types.


One added value in Python┬*3.0 would be that they are sortable in a
`list`. But seriously, your token example should work fine with
Python┬*3.0 because the wish to sort tokens is a bit exotic IMHO.

> I don't want to be forced into it just because a container doesn't like
> what I'm doing.


The container doesn't say what *you* can do with the content, it is just
a bit picky about what the container itself can do. If a function or
method doesn't like something about the arguments it's perfectly okay to
raise a `TypeError` or a `ValueError`.

> As another example, consider a list of items being juggled:
>
> [RubberChicken(), ChainSaw(), Canteloupe()]
>
> I could go through contortions to find some common subclass for these
> items, but the whole *point* is that they're not of the same type.


They are of the same duck type "things to be juggled". And if you use a
method on them they have to implement that. Not necessarily through
inheritance.

> And making a list of them is a perfectly reasonable thing to do.


And possible with current Python and Python┬*3.0.

Ciao,
Marc 'BlackJack' Rintsch
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      11-09-2008
Kay Schluehr wrote:
> On 9 Nov., 05:04, Terry Reedy <(E-Mail Removed)> wrote:
>
>> Have you written any Python code where you really wanted the old,
>> unpredictable behavior?

>
> Sure:


I was asking the OP

>
> if len(L1) == len(L2):
> return sorted(L1) == sorted(L2) # check whether two lists contain
> the same elements
> else:
> return False
>
> It doesn't really matter here what the result of the sorts actually is
> as long as the algorithm leads to the same result for all permutations
> on L1 ( and L2 ).


Leaving aside the O(n) alternative for hashable items, which only
matters for 'long' lists....
If you literally mean 'the same elements', then key=id would work.

For some mixtures, such as strings and numbers, key=id will work better
than in 2.x since complex numbers can be included.

If you want to duplicate 2.x behavior, which does *not* work for all
types...

def py2key(item): return (str(type(item)), item)

Guido is aware that universal compare was occasionally useful, but
decided that it also caused problems. So he broke universal compare
when he introduced complex numbers without arbitrary comparisons.
Decimal numbers are even worse. So anyone who objects to the change in
3.0 *should* have objected when complex numbers were introduced.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: [Python-Dev] [python-committers] [RELEASED] Python 3.2 rc 1 R. David Murray Python 0 01-17-2011 02:23 PM
Re: [Python-Dev] [python-committers] [RELEASED] Python 3.2 rc 1 Senthil Kumaran Python 0 01-17-2011 10:31 AM
Re: [Python-Dev] [Python-3000] RELEASED Python 2.6a1 and 3.0a3 Martin v. L÷wis Python 0 03-01-2008 10:51 PM
Re: [Python-Dev] [Python-3000] RELEASED Python 2.6a1 and 3.0a3 Paul Moore Python 0 03-01-2008 10:39 PM
Searching comp.lang.python/python-list@python.org (was: UTF-8) skip@pobox.com Python 0 03-10-2007 02:50 PM



Advertisments