471,310 Members | 1,381 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,310 software developers and data experts.

Collections of non-arbitrary objects ?

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a collection
of non-arbitrary objects? A list of records, or something like that?

Jun 21 '07 #1
28 1426
walterbyrd wrote:
Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a collection
of non-arbitrary objects? A list of records, or something like that?
Code the record as an object (class) and place instances of those objects inside
a list or dictionary (depending on access required). Or if you don't want to do
much with the records just put each instance of a record (normally a record is
implemented as a tuple at least thats how SQL databases return rows) inside a
list or a dictionary (again depending on access required).

-Larry
Jun 21 '07 #2
On Jun 21, 8:19 pm, walterbyrd <walterb...@iname.comwrote:
Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries.
And sets.
But what if I want a collection
of non-arbitrary objects?
Then only put the kind of objects you want in the collection.
A list of records, or something like that
'Records' can be implemented as tuples, dicts or using a custom class.

Jun 21 '07 #3
walterbyrd <wa********@iname.comwrites:
Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a
collection of non-arbitrary objects? A list of records, or something
like that?
Then collect them in a non-arbitrary way.

That's a flippant response, but I don't understand the question. What
are you asking for that you don't already have? A list can contain a
sequence of objects of the same type already. What are you expecting
that a list does not provide?

--
\ "Faith may be defined briefly as an illogical belief in the |
`\ occurrence of the improbable." -- Henry L. Mencken |
_o__) |
Ben Finney
Jun 21 '07 #4
On 2007-06-21, Ben Finney <bi****************@benfinney.id.auwrote:
walterbyrd <wa********@iname.comwrites:
>Python seems to have a log of ways to do collections of
arbitrary objects: lists, tuples, dictionaries. But what if I
want a collection of non-arbitrary objects?
Lists never contain arbitrary objects, they contain only
objects that you put there. The reason that other languages
have typed containers (e.g. array of type T) is that the
elements of the array don't know what type they are, so you've
got to limit what you put in there. In python, all objects
know what type they are, so there's no point in labelling the
references to the objects with type info as well.
>A list of records, or something like that?

Then collect them in a non-arbitrary way.

That's a flippant response, but I don't understand the
question. What are you asking for that you don't already have?
A list can contain a sequence of objects of the same type
already. What are you expecting that a list does not provide?
I was also a bit baffled by the question. The only things I
could think of are:

1) a "container" that raised an exception if the type of a new
item doesn't match the type of what's in it already. I
don't really see much benefit in that. If you want a list
to contain only objects of type T, then only put that type
of objects in it.

2) an "array" that contains a large number of small things
(e.g. integer or floating point numbers) that need to be
stored with minimal overhead. That's a useful thing, and
there are several packages that do that -- numpy is the one
generally recommended for new designs.

--
Grant Edwards grante Yow! Are the STEWED PRUNES
at still in the HAIR DRYER?
visi.com
Jun 22 '07 #5
On Jun 21, 5:38 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
That's a flippant response, but I don't understand the question.
Everybody here seems to have about the same response: "why would you
ever want to do that?"

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Think of this: why use tuples when lists are available? You can use a
tuple to index a dictionary, but not a list - why? I the answer may
be that sometimes you want some degree on inherent enforced structure.
I'm sure the language could have designed to allow lists to index
dictionary, but you would have to awfully careful with those lists.
The burden would be on the programmer to make certain that those lists
didn't change. But, it could be done, therefore tuples are not
"needed" right?

Languages like C are often criticized as being too rigid - you have to
pre-define your variables, and pre-allocate your array sizes. But,
languages like Perl and BASIC, are often criticized as being to
sloppy - too few restrictions tend to lead to sloppy code. So I guess
there is a sort of trade-off.

I suppose I could use a database, that might give me some degree of
assured integrity - depending on what database I used.

Jun 23 '07 #6
walterbyrd <wa********@iname.comwrites:
Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.
Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?

--
\ "Quidquid latine dictum sit, altum viditur." ("Whatever is |
`\ said in Latin, sounds profound.") -- Anonymous |
_o__) |
Ben Finney
Jun 23 '07 #7
En Fri, 22 Jun 2007 21:45:02 -0300, walterbyrd <wa********@iname.com>
escribió:
Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.
Sure. You can implement it yourself, if you want; it's not so hard even
for a beginner. It's just not needed enough, or required enough, to become
a builtin type.
Look for some recent posts about a RestrictedList.

--
Gabriel Genellina

Jun 23 '07 #8
On Jun 23, 1:45 am, walterbyrd <walterb...@iname.comwrote:
On Jun 21, 5:38 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
That's a flippant response, but I don't understand the question.

Everybody here seems to have about the same response: "why would you
ever want to do that?"

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Think of this: why use tuples when lists are available? You can use a
tuple to index a dictionary, but not a list - why? I the answer may
be that sometimes you want some degree on inherent enforced structure.
I'm sure the language could have designed to allow lists to index
dictionary, but you would have to awfully careful with those lists.
The burden would be on the programmer to make certain that those lists
didn't change. But, it could be done, therefore tuples are not
"needed" right?

Languages like C are often criticized as being too rigid - you have to
pre-define your variables, and pre-allocate your array sizes. But,
languages like Perl and BASIC, are often criticized as being to
sloppy - too few restrictions tend to lead to sloppy code. So I guess
there is a sort of trade-off.

I suppose I could use a database, that might give me some degree of
assured integrity - depending on what database I used.
Hi Walterbyrd,
What happens when you are given good advice that may be contrary to
intuition?

Unfortunately its how we usually do things in Python and do NOT
suffer because of it. Try writing your application without it. Test
without it. Write other applications without it. Others do,
successfully.

- Paddy.
Jun 23 '07 #9
On Jun 22, 11:43 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?
Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.

In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list - or any such
structure. To me, that seems like a potentially vulnerability.
Especially since variables in python do not have to be explicitly
assigned - another variable that points to the same thing, could
change the data that a variable points to.

Jun 23 '07 #10
On Jun 23, 11:45 am, walterbyrd <walterb...@iname.comwrote:
On Jun 22, 11:43 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.
if hasattr(elmt, some_func):
elmt.some_func()

Jun 23 '07 #11
In <11**********************@e16g2000pri.googlegroups .com>, walterbyrd
wrote:
On Jun 22, 11:43 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
>Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.
It raises an exception. What want you an "typed list" to do when a wrong
object is put into it? Raising an exception? So all you change is the
point in time when the exception is raised.
In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list - or any such
structure. To me, that seems like a potentially vulnerability.
Especially since variables in python do not have to be explicitly
assigned - another variable that points to the same thing, could
change the data that a variable points to.
But this doesn't really change with a "typed list". It's easy to take
an object and completely replace all its attributes so it behaves very
different.

Ciao,
Marc 'BlackJack' Rintsch
Jun 23 '07 #12
On Jun 23, 6:45 pm, walterbyrd <walterb...@iname.comwrote:
On Jun 22, 11:43 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.

In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list - or any such
structure. To me, that seems like a potentially vulnerability.
Especially since variables in python do not have to be explicitly
assigned - another variable that points to the same thing, could
change the data that a variable points to.
Reminds me a bit of that (awful) sketch:
Patient: Doctor doctor it hurts if I do that.
Doctor: Well don't do that then.

The data for the list should have been checked when it entered
your program. It is up to you to then only stuff the list with
data expected by the routine. If you don't then Python will most
likely throw a runtime exception, but it is up to you to trust
your co-workers on the project.

- Paddy

Jun 23 '07 #13
7stud wrote:
On Jun 23, 11:45 am, walterbyrd <walterb...@iname.comwrote:
>Suppose you are sequentially processing a list with a routine
that expects every item to be of a certain type. Something in the
list that doesn't conform to the type could give you unexpected
results, maybe crash your application.

if hasattr(elmt, some_func):
elmt.some_func()
Personally, I prefer

try:
elmt.some_func()
except AttributeError:
# do stuff

Regards,
Björn

--
BOFH excuse #130:

new management

Jun 24 '07 #14
walterbyrd <wa********@iname.comwrites:
Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list
that doesn't conform to the type could give you unexpected results,
maybe crash your application.
A routine that demands its inputs to be of a certain *type*, rather
than requiring that the implement the required *behaviour*, breaks
polymorphism.

Polymorphism is considered valuable in Python; search for any of
"polymorphism", "duck typing" and "easier to ask forgiveness than
permission".

--
\ "Intellectual property is to the 21st century what the slave |
`\ trade was to the 16th." -- David Mertz |
_o__) |
Ben Finney
Jun 24 '07 #15
walterbyrd a écrit :
On Jun 22, 11:43 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:

>>Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?


Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type.
it should expects every item to support a given protocol (expose a given
interface, have a given set of attributes, whatever...).

OOP is not about "types" or "classes", it's about objects. And in a
dynamic language like Python, where you can add/remove/replace almost
each attribute (including methods and even it's class...) of an object
at runtime, override the way the attribute look-up is done, etc, this is
specially true.

The fact that an object is an instance of a given class doesn't
necessarily imply that it supports the same protocol. And the fact that
an object is an instance of a given class is only true at a given
time... So testing on type to allow inclusion of an object in a list for
"type safety" reasons is mostly a waste of time. It's also
counter-productive since it would reject objects that actually supports
the right protocol but are not of the "correct type".
Something in the list that
doesn't conform to the type
s/conform to the type/support the protocol/
could give you unexpected results, maybe
crash your application.
Yes. But... you do test your application, don't you ?-)
In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list
No. cf above.
- or any such
structure. To me, that seems like a potentially vulnerability.
Did you actually had some effective problem with this ?
Especially since variables in python do not have to be explicitly
assigned
???

I suppose you meant something else here, probably about declarative typing ?
- another variable that points to the same thing, could
change the data that a variable points to.
Give me a reference to an object in a list, and I can change almost any
attribute of the object - even it's class.

FWIW, a similar - but usually much much worse wrt/ possible results -
problem exists in C with pointers and memory.

I came to Python from statically typed languages, and first had a
similar reaction. It took me some time to believe it, but type errors
are quite less frequent that you would imagine, and most of the time
quite trivial to spot and fix. I've had bigger problems with memory
handling and dangling pointers in C, Pascal or C++.
Jun 24 '07 #16
On Jun 24, 10:31 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
Especially since variables in python do not have to be explicitly
assigned

???
I have probably expressed this incorrectly. What I meant was:
>>a = [1,2,3]
b = a
a[1] = 'spam'
Here, I have changed b, without an explicit assignment. After I
assigned a to b, I never did another "b =" yet b changed anyway
because I changed a. I am not saying there is anything wrong with
this, I'm just explaining what I meant.

So let's say I have list L, and I have a routine that expects every
item in L to be a dictionary like: {'name':'joe', 'job':'dev', 'pay':
min_wage}.

Not only could the app crash if an incorrect item where inserted into
L. But the app could crash if an incorrect item were inserted in lists
X,Y, or Z.

Of course, you can always work around this by just programming very
carefully, and doing a lot of error checking. That is always true in
any language.

But, I think sometimes it's helpful to use a structure that is little
more restrictive, to sort of enforce a degree of integrity. An example
I have already given: why use tuples instead of a list? Tuples are
actually a bit more restrictive.

I don't think there is anything wrong with the data structures that
exist in python. I was just wondering if there was a structure that
would restrict a collection to only allow certain types. The
"restrictedlist" class discussed in another thread may be the sort of
thing I was looking for.

BTW: I think polymorphism is great and all. But it does have (and IMO
should have) it's limitations. For example, I don't think you can
divide a string by another string.

Jun 25 '07 #17
I don't think there is anything wrong with the data structures that
exist in python. I was just wondering if there was a structure that
would restrict a collection to only allow certain types. The
"restrictedlist" class discussed in another thread may be the sort of
thing I was looking for.

Just remenber that if you write a library using such a thing, your
(consenting adults) users will not be able to store objects in your
list that implement (part of) the interface of the type that you
restricted.
--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
Jun 25 '07 #18
On 2007-06-25, walterbyrd <wa********@iname.comwrote:
BTW: I think polymorphism is great and all. But it does have
(and IMO should have) it's limitations. For example, I don't
think you can divide a string by another string.
It might be a pointless new spelling for the .split method.

x = 'Smith, Ted, 15 Smedly Rd."
last, first, street = x / ', '

Tongue-in-cheekily-yours,

--
Neil Cerutti
Strangely, in slow motion replay, the ball seemed to hang in the air for even
longer. --David Acfield
Jun 25 '07 #19
walterbyrd a écrit :
On Jun 24, 10:31 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:

>>>Especially since variables in python do not have to be explicitly
assigned

???


I have probably expressed this incorrectly. What I meant was:

>>>>a = [1,2,3]
b = a
a[1] = 'spam'


Here, I have changed b, without an explicit assignment.
You haven't changed b, you have changed the object bound to name 'b'.
Which happens to be also bound to name 'a'.
After I
assigned a to b,
Well, I guess the term "assignment" is misleading you then. "binding"
would be more accurate - you bound names 'a' and 'b' to the same object.
Then, whether you access this object via name 'a' or name 'b', you're
still accessing the same object.
I never did another "b =" yet b changed anyway
Doing 'b = some_other_object' would still not 'change b' - you don't
change a name - but rebind name 'b' to another object.

You perhaps don't know this, but most statically typed languages have
the notion of either pointers or references, that can cause similar -
and usually worse - problems.
because I changed a. I am not saying there is anything wrong with
this, I'm just explaining what I meant.

So let's say I have list L, and I have a routine that expects every
item in L to be a dictionary like: {'name':'joe', 'job':'dev', 'pay':
min_wage}.

Not only could the app crash if an incorrect item where inserted into
L. But the app could crash if an incorrect item were inserted in lists
X,Y, or Z.
Yes - assuming names L, X, Y and Z are bound to the same list.

And it would also crash if one the dicts was modified between the moment
it is added to the list and the moment you pass the list to your
function. Which makes "typed" lists totally useless anyway. And even if
you use a smarter 'correctness' test (like a callback function checking
that every item added or inserted supports keying and has the correct
keys), it would still be useless since you could still manage to modify
one of the items of the list *after* it has been added to it.
Of course, you can always work around this by just programming very
carefully,
You do program carefully, don't you ?-)
and doing a lot of error checking.
That's usually not even necessary - most of the time (ie: almost
always), you'll have a nice traceback in the minutes following the
moment you introduced the error.
That is always true in
any language.
Nope. In Python, you seldom have to do error *checking* - the language
do it for you (that's what exceptions are for). What you have to do is
1/ testing, and 2/ error *handling*.

Now did you actually had any effective problem with Python's dynamism ?
Or are you just scared ?

You know, Python is now something like 17 years old, and is used by a
*lot* of peoples for a *lot* of programs - some of them far from
trivial. I think you can be confident in this experience. IOW, just
write your code, and you'll find out that the kind of problems you seem
to fear so much will not happens that often.
But, I think sometimes it's helpful to use a structure that is little
more restrictive, to sort of enforce a degree of integrity.
Sometimes you do have to check the validity of the data you are supposed
to work on, true - mostly when it comes to program inputs (be it wia
files, sockets, forms, environment, whatever). Once this is done, you
shouldn't have to worry too much - just let Python crash when there's
something wrong, carefully read the traceback, and correct the offending
code (which is very likely in the last modifications you made).
An example
I have already given: why use tuples instead of a list? Tuples are
actually a bit more restrictive.
You don't use tuples "instead of" lists. Lists are collections, tuples
are structured data.
I don't think there is anything wrong with the data structures that
exist in python. I was just wondering if there was a structure that
would restrict a collection to only allow certain types.
Not builtin. You can roll your own if it makes you happy, but that would
be a waste of time - been here, done that, you see...
The
"restrictedlist" class discussed in another thread may be the sort of
thing I was looking for.
So please take time to read the whole thread.
BTW: I think polymorphism is great and all. But it does have (and IMO
should have) it's limitations.
Yes, indeed - if an object doesn't understand a message, then you have
an exception. But since the only way to know if an object can handle a
message is to send the message (please refer to my previous post),
enforcing 'type'-based (with 'type'=='class') restriction in Python is
not only useless, it's also harmful. IOW, stop fighting against the
language - just use it.
For example, I don't think you can
divide a string by another string.
No, because this operation is not implemented for strings - IOW, strings
doesn't understand this message. What would be the meaning of dividing
strings anyway ? (while concatening string is a well-known operation).
Jun 25 '07 #20
In <46***********************@news.free.fr>, Bruno Desthuilliers wrote:
walterbyrd a écrit :
>For example, I don't think you can divide a string by another string.

No, because this operation is not implemented for strings - IOW, strings
doesn't understand this message. What would be the meaning of dividing
strings anyway ? (while concatening string is a well-known operation).
As someone else already mentioned dividing strings is splitting. The Pike
language does this:

http://pike.ida.liu.se/generated/man...chapter_4.html

Scroll down to ``string / string``. The definition of ``string / float``
is neat too. Something I really miss in everyday programming in Python,
not. ;-)

Ciao,
Marc 'BlackJack' Rintsch
Jun 25 '07 #21
walterbyrd <wa********@iname.comwrites:
>a = [1,2,3]
b = a
a[1] = 'spam'

Here, I have changed b, without an explicit assignment.
No. Both 'a' and 'b' are names bound to a single object; you're
changing that object. This is a subtle difference, but it's one that
is confusing you in this instance.
So let's say I have list L, and I have a routine that expects every
item in L to be a dictionary like: {'name':'joe', 'job':'dev',
'pay': min_wage}.
If that routine expects objects of a particular *type*, instead of
objects that exhibit expected *behaviour*, the routine is poorly
designed.
Not only could the app crash if an incorrect item where inserted
into L. But the app could crash if an incorrect item were inserted
in lists X,Y, or Z.
When the routine tries to deal with an object that doesn't behave as
expected, an exception will be raised. If the exception goes uncaught,
then Python will exit and throw the exception to the user; I suppose
you could call this a "crash".
Of course, you can always work around this by just programming very
carefully, and doing a lot of error checking. That is always true in
any language.
Better is to catch the exception at a level where it can be dealt
with; this is usually the same level where those non-conforming
objects were placed in the list to begin with.
BTW: I think polymorphism is great and all. But it does have (and
IMO should have) it's limitations. For example, I don't think you
can divide a string by another string.
Indeed, and you'll get an exception raised if you try. Catch that
exception at a level where there's enough context to make sense of it,
and deal with it in whatever way you see fit.

--
\ "Imagine a world without hypothetical situations." -- Anonymous |
`\ |
_o__) |
Ben Finney
Jun 25 '07 #22
Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:
You know, Python is now something like 17 years old, and is used by a
*lot* of peoples for a *lot* of programs - some of them far from
trivial. I think you can be confident in this experience. IOW, just
write your code, and you'll find out that the kind of problems you
seem to fear so much will not happens that often.
Assembler and Cobol have been around even longer...
Jun 26 '07 #23
En Mon, 25 Jun 2007 11:14:23 -0300, walterbyrd <wa********@iname.com>
escribió:
I have probably expressed this incorrectly. What I meant was:
>>>a = [1,2,3]
b = a
a[1] = 'spam'

Here, I have changed b, without an explicit assignment. After I
assigned a to b, I never did another "b =" yet b changed anyway
because I changed a. I am not saying there is anything wrong with
this, I'm just explaining what I meant.
I think you should benefit reading this short article:
http://effbot.org/zone/python-objects.htm

--
Gabriel Genellina

Jun 26 '07 #24
On Jun 25, 8:21 pm, Marius Gedminas <mged...@gmail.comwrote:
On Jun 24, 2:12 pm, Bjoern Schliessmann <usenet-

mail-0306.20.chr0n...@spamgourmet.comwrote:
7stud wrote:
if hasattr(elmt, some_func):
elmt.some_func()
Personally, I prefer
try:
elmt.some_func()
except AttributeError:
# do stuff

That also hides attribute errors that occur within some_func. I think
I'd rather know when elmt has an implementation of some_func that is
buggy. Thus I prefer the hasattr version.
Or possibly

try:
do_func = elmt.some_func
except AttributeError:
do_stuff()
else:
do_func()

(internally hasattr is doing that anyway).

Michele Simionato

Jun 26 '07 #25
On Jun 24, 10:31 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:

You perhaps don't know this, but most statically typed languages have
the notion of either pointers or references, that can cause similar -
and usually worse - problems.
Yes, but those languages also have the notion of structures that do
not allow arbitrary collections. That is what I was wondering about
when I started the thread. It's fine that python has four different
ways of creating collections of arbitrary data types, but I thought it
might be helpful if python had, at least, one way of a creating a
collection of non-arbitrary data.
>
You do program carefully, don't you ?-)
I try. But things like typos are a normal part a life.
>
Now did you actually had any effective problem with Python's dynamism ?
Or are you just scared ?
Just scared.
You know, Python is now something like 17 years old, and is used by
a
*lot* of peoples for a *lot* of programs - some of them far from
trivial. I think you can be confident in this experience. IOW, just
write your code, and you'll find out that the kind of problems you seem
to fear so much will not happens that often.
Of course, BASIC is over 40 years old, also used by a *lot* of people.
A lot of non-trivial apps have been written in BASIC. But, BASIC is
often criticized for it's lack of structure. A language's longevity,
and/or popularity, don't mean there isn't room for improvement. Guido
must think python has a lot of room for improvement since he's
completely throwing out backward compatibility with python 3000.
>
You don't use tuples "instead of" lists. Lists are collections, tuples
are structured data.
It seems to me that tuple are essentially immutable lists. So why
impose that immutability restriction on a data collection? Why not
just have lists and not tuples? What can a tuple do that a list can
not do? Why was python designed so that tuples could be used for
dictionary indexes, but not lists? Could it be because imposing that
restriction on a data collection insures a certain degree of
integrity? My point is: sometimes imposing some restrictions can give
a degree in built-in integrity. Maybe you don't need that integrity
insurance, if you code carefully enough, but can you always count on
that?

BTW: I'm not assuming that it will always be me running my own app.
Sure, if an exception occureed while I was running my own app, I'd
probably know what to do. But if somebody else (who - god forbid -
didn't know python was running the app, things might be more difficult.

Jun 26 '07 #26
walterbyrd a écrit :
>>On Jun 24, 10:31 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
You perhaps don't know this, but most statically typed languages have
the notion of either pointers or references, that can cause similar -
and usually worse - problems.

Yes, but those languages also have the notion of structures that do
not allow arbitrary collections.
Ever played with casting in C ?
That is what I was wondering about
when I started the thread. It's fine that python has four different
ways of creating collections of arbitrary data types, but I thought it
might be helpful if python had, at least, one way of a creating a
collection of non-arbitrary data.
As I explained, while technically possible (and not specially
difficult), this is a waste of time given Python's dynamism.
>You do program carefully, don't you ?-)

I try. But things like typos are a normal part a life.
So are they in any language. I fail to see much difference here.
>Now did you actually had any effective problem with Python's dynamism ?
Or are you just scared ?
Just scared.
So take a deep breath and try to just do the simplest thing (in this
case: using builtin collection types). Usually, it JustWorks(tm).
You know, Python is now something like 17 years old, and is used by
a
>*lot* of peoples for a *lot* of programs - some of them far from
trivial. I think you can be confident in this experience. IOW, just
write your code, and you'll find out that the kind of problems you seem
to fear so much will not happens that often.

Of course, BASIC is over 40 years old, also used by a *lot* of people.
Not the same kind of people I'd say !-)
A lot of non-trivial apps have been written in BASIC. But, BASIC is
often criticized for it's lack of structure.
Old time basic effectively lacks of "structure", since it uses goto's
instead of functions, loops and conditionals (google for "structured
programming").

What I meant here is that one of the lessons of this collective
experience is that 'typed' containers are more often harmful than useful.
A language's longevity,
and/or popularity, don't mean there isn't room for improvement.
Indeed. But declarative static typechecking wouldn't be an improvement.
Guido
must think python has a lot of room for improvement since he's
completely throwing out backward compatibility with python 3000.
Not "completely throwing out". Just allowing *some* major breakages -
the kind you usually get with each major release of other languages, but
that Python managed to avoid as much as possible so far.
>You don't use tuples "instead of" lists. Lists are collections, tuples
are structured data.

It seems to me that tuple are essentially immutable lists.
They are not (even if you can use them that way too). FWIW and IIRC,
this is a FAQ.
So why
impose that immutability restriction on a data collection?
Because tuples are *not* collections. They are *structured data*. The
canonical tuple is a SQL database row.
Why not
just have lists and not tuples?
because tuples are not lists.
What can a tuple do that a list can
not do?
Be immutable.
Why was python designed so that tuples could be used for
dictionary indexes, but not lists?
How would you compute a hash from a generic mutable collection ?
Could it be because imposing that
restriction on a data collection insures a certain degree of
integrity?
Once again: tuples are *not* collections. Would you define a string as a
collection ?
My point is: sometimes imposing some restrictions can give
a degree in built-in integrity.
Yes. But the kind of restriction you're talking about won't buy you
much, as I already explained, and, in practice, happens to be mostly
useless.
Maybe you don't need that integrity
insurance, if you code carefully enough,
Maybe you don't need that "integrity insurance", period ?-)
but can you always count on
that?
It seems that tens of thousands of Python users are doing fine without this.
BTW: I'm not assuming that it will always be me running my own app.
Sure, if an exception occureed while I was running my own app, I'd
probably know what to do. But if somebody else (who - god forbid -
didn't know python was running the app, things might be more difficult.
The canonical solution is to have an application-level error handler
that logs uncaught exceptions (so the developper can get at them),
display a user-friendly error message (eventually giving the user a way
to submit a bug report to the developper), and try to crash as cleanly
as possible.

However careful and serious you are wrt/ programming and testing, your
program *will* have bugs (unless it's some kind of hello world). Better
learn to live with it.

Let's suppose you implement a restrictedList. It of course raises an
exception when trying to add a 'non-compliant' item. All this happening
at runtime, of course. Now let's suppose there's one such error in your
code that managed to pass thru tests. What's going to happen ? Yes,
exactly the same thing as if you used a plain list - just somewhere else
in the code. For the final user, the result will be *exactly* the same :
a crash.
Jun 26 '07 #27
>
Did you try to sort a tuple ?
>>(1, "aaa").sort()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'tuple' object has no attribute 'sort'
I can do this:
>>x = (3,2,1)
x = tuple(sorted(list(x)))
Which, although senseless, effectively sorts the x tuple. But, you are
right, I am not really sorting the tuple, I'm sorting a list, which
has been made from the tuple, then changing it back to a tuple.

Actually, I can even do it in one line:

x = tuple(sorted(list((3,2,1))))
Jun 28 '07 #28
walterbyrd wrote:
I can do this:
x = tuple(sorted(list((3,2,1))))
The list() conversion is superfluous:
>>tuple(sorted((3,2,1)))
(1, 2, 3)

Peter

Jun 28 '07 #29

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Peter Dobcsanyi | last post: by
24 posts views Thread by Gary van der Merwe | last post: by
1 post views Thread by Tim T. | last post: by
11 posts views Thread by CMM | last post: by
25 posts views Thread by Lars | last post: by
4 posts views Thread by Giorgio Parmeggiani | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.