[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

RE: dictionary/hash and '1' versus 1

Reedick, Andrew

1/4/2008 3:50:00 PM

> From: Stephen Hansen [mailto:apt.shansen@gmail.com]
> Sent: Thursday, January 03, 2008 7:39 PM
> To: Reedick, Andrew
> Cc: python-list@python.org
> Subject: Re: dictionary/hash and '1' versus 1
>
>
>
> Well one important thing to learn while learning Python is that while the
> language is dynamically typed-- it is also /strongly/ typed. Every piece
> of data has an explicit type and it doesn't change unless you change it.

Meh, mixing dynamic and strong typing is a mixed blessing. You don't find out that you screwed up the data types until the code block is actually executed. Reminds me of Nostradamus. He may have predicted the future[1], but the predictions are so vague/convoluted that you can only figure out the predictions in hindsight.


> It relies on duck typing a lot, and doesn't care if you mix and match
> (even partially) compatible types as long as the operations are there,
> but one type will always be distinct and remain that type until you
> explicitly convert it.
>
> A single integer is distinctly different from a sequence of characters in
> some encoding that may just happen to contain representations of a
> number.... so they'll hash differently :)

Depends on the context. The machine encoding may be different, but in human terms they "should" be the same. Perl managed to achieve an impressive blend of presenting data as human friendly or as machine bits when it made sense to do so. So much so, that Perl is probably the only language I've used that will do what you mean instead of what you say. Nice, but frightening in some ways.


> One type will basically never implicitly convert into another type.
>
> To me, this sounds like the function should have converted the type
> explicitly on return. Or maybe you need to convert it explicitly on
> receipt.

Type casting is easy, IFF you remember to do so. The problem was that I missed the fact that one (important) function was returning a string instead of an int, and since Python supports heterogenous data structures, the human has to remember to keep the key's data type homongenous.
That and Perl does so much automatic type conversion in such a sensible way, that I stopped worrying about mixing data types, which is making the Python transition a tad more error prone. Because of Perl, I almost consider automatic type casting to be the next "you don't have to manage your own memory" that people loved about Java. =O


> But if you are in a use-case where you really don't care and only
> want to hash strings, you can create a dict subclass easily that
> overrides __setitem__ to always str() the input. Check out the
> UserDict class.

UserDict looks like it could be useful. Thanks for the info.


> A similar method lets you make 'case-insensitive' dicts, for example.
>
> Were such a thing to happen automagically, you could get some
> weird situations, such as "assert (key in dict) == (key in dict.keys())"
> failing.

I'm assuming that you would just need to overload the 'in' operator and ..keys() method to be case insensitive also.




[1] No, he didn't.


*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
11 Answers

Paddy

1/5/2008 2:09:00 PM

0

On Jan 4, 3:50 pm, "Reedick, Andrew" <jr9...@ATT.COM> wrote:
> > From: Stephen Hansen [mailto:apt.shan...@gmail.com]
> > Sent: Thursday, January 03, 2008 7:39 PM
> > To: Reedick, Andrew
> > Cc: python-l...@python.org
> > Subject: Re: dictionary/hash and '1' versus 1
>
> > Well one important thing to learn while learning Python is that while the
> > language is dynamically typed-- it is also /strongly/ typed. Every piece
> > of data has an explicit type and it doesn't change unless you change it.
>
> Meh, mixing dynamic and strong typing is a mixed blessing. You don't find out that you screwed up the data types until the code block is actually executed. Reminds me of Nostradamus. He may have predicted the future[1], but the predictions are so vague/convoluted that you can only figure out the predictions in hindsight.
>
> > It relies on duck typing a lot, and doesn't care if you mix and match
> > (even partially) compatible types as long as the operations are there,
> > but one type will always be distinct and remain that type until you
> > explicitly convert it.
>
> > A single integer is distinctly different from a sequence of characters in
> > some encoding that may just happen to contain representations of a
> > number.... so they'll hash differently :)
>
> Depends on the context. The machine encoding may be different, but in human terms they "should" be the same. Perl managed to achieve an impressive blend of presenting data as human friendly or as machine bits when it made sense to do so. So much so, that Perl is probably the only language I've used that will do what you mean instead of what you say. Nice, but frightening in some ways.

There are many character strings that contain numeric characters that
are not necessarily to be interpreted as an int or a float, such as
string representations of IP addresses, or numbers to other bases than
ten, complex numbers, telephone numbers, ...
You need to validate your input and convert and pass around the
correct type of data. Perl inherited this automatic conversion between
strings and numbers from simple shell scripting and the AWK language
that was around before Perl. I find that the follow-on need to have
separate comparisons for numbers or strings to be awkward in Perl.

>
> > One type will basically never implicitly convert into another type.
>
> > To me, this sounds like the function should have converted the type
> > explicitly on return. Or maybe you need to convert it explicitly on
> > receipt.
>
> Type casting is easy, IFF you remember to do so. The problem was that I missed the fact that one (important) function was returning a string instead of an int, and since Python supports heterogenous data structures, the human has to remember to keep the key's data type homongenous.
> That and Perl does so much automatic type conversion in such a sensible way, that I stopped worrying about mixing data types, which is making the Python transition a tad more error prone. Because of Perl, I almost consider automatic type casting to be the next "you don't have to manage your own memory" that people loved about Java. =O

Not really, it seems to me to be going the exact opposite way with
languages with automatic type conversions being seen as not suited for
larger programs.

>
> > But if you are in a use-case where you really don't care and only
> > want to hash strings, you can create a dict subclass easily that
> > overrides __setitem__ to always str() the input. Check out the
> > UserDict class.
>
> UserDict looks like it could be useful. Thanks for the info.
>
> > A similar method lets you make 'case-insensitive' dicts, for example.
>
> > Were such a thing to happen automagically, you could get some
> > weird situations, such as "assert (key in dict) == (key in dict.keys())"
> > failing.
>
> I'm assuming that you would just need to overload the 'in' operator and .keys() method to be case insensitive also.
>
> [1] No, he didn't.
>

Bearophile

1/5/2008 11:07:00 PM

0

Paddy:
> Not really, it seems to me to be going the exact opposite way with
> languages with automatic type conversions being seen as not suited for
> larger programs.

In Java you can add the number 1 to a string, and have it
automatically converted to string before the string join... What do
you think of that feature?

Bye,
bearophile

Steven D'Aprano

1/6/2008 12:01:00 AM

0

On Sat, 05 Jan 2008 15:07:10 -0800, bearophileHUGS wrote:

> Paddy:
>> Not really, it seems to me to be going the exact opposite way with
>> languages with automatic type conversions being seen as not suited for
>> larger programs.
>
> In Java you can add the number 1 to a string, and have it automatically
> converted to string before the string join... What do you think of that
> feature?

You mean special-casing the int 1 so that this works?

# Faked!
>>> x = "spam spam spam"
>>> x = x + 1
>>> x
'spam spam spam1'


but not this?

>>> x = "spam spam spam"
>>> x = x + 2
TypeError: automatic conversion between strings and ints only works for
the int 1


How bizarre.


The problem with automatic conversions between strings and integers is
that it isn't clear what the user wants when they do something like this:

>>> x = '1' + 1

Should x be the string '11' or the int 2? Please justify your answer.


On the other hand, if the language includes separate operators for
addition and concatenation (say, + and &) then that sort of auto-
conversion is no longer ambiguous:

>>> '2' + 3
5
>>> '2' & 3
'23'




--
Steven

Paddy

1/7/2008 7:33:00 AM

0

On Jan 5, 11:07 pm, bearophileH...@lycos.com wrote:
> Paddy:
>
> > Not really, it seems to me to be going the exact opposite way with
> > languages with automatic type conversions being seen as not suited for
> > larger programs.
>
> In Java you can add the number 1 to a string, and have it
> automatically converted to string before the string join... What do
> you think of that feature?
>
> Bye,
> bearophile

Hi Bearophile,
Unfortunately, (fortunately?), I don't know enough Java. I can just
get by reading correct Java programs so could not really comment. If
Java is flexible enough to allow the '+' operator to be defined
between strings and integers and left it to the programmer to define
the result then that would be a good thing, but having the language
automatically define conversions between unrelated types would break
strong typing which I have read that Java enjoys.
http://en.wikipedia.org/wiki/Type_system#Strong_and_w...

- Paddy.

Diez B. Roggisch

1/7/2008 1:18:00 PM

0

bearophileHUGS@lycos.com schrieb:
> Paddy:
>> Not really, it seems to me to be going the exact opposite way with
>> languages with automatic type conversions being seen as not suited for
>> larger programs.
>
> In Java you can add the number 1 to a string, and have it
> automatically converted to string before the string join... What do
> you think of that feature?


This isn't really what is happening. In fact, in Java the +-operator is
overloaded for strings to invoke the mandatory toString()-method on all
objects when concatenated with a string.

So

"" + 1

works internally as

StringBuilder sb = new StringBuilder();
sb.append("");
sb.append(new Integer(1).toString());


Or something like that, depending on how optimizing the compiler is.

So you can also do

"" + some_object

However,

some_object + ""

or

1 + ""

don't work - the operator is only overloaded on the left argument.

Diez

Sion Arrowsmith

1/7/2008 3:51:00 PM

0

<bearophileHUGS@lycos.com> wrote:
>In Java you can add the number 1 to a string, and have it
>automatically converted to string before the string join... What do
>you think of that feature?

"-%s" % 1

--
\S -- siona@chiark.greenend.org.uk -- http://www.chaos.org...
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

Reedick, Andrew

1/7/2008 5:10:00 PM

0



> -----Original Message-----
> From: python-list-bounces+jr9445=att.com@python.org [mailto:python-
> list-bounces+jr9445=att.com@python.org] On Behalf Of Steven D'Aprano
> Sent: Saturday, January 05, 2008 7:01 PM
> To: python-list@python.org
> Subject: Re: dictionary/hash and '1' versus 1
>
> The problem with automatic conversions between strings and integers is
> that it isn't clear what the user wants when they do something like
> this:
>
> >>> x = '1' + 1
>
> Should x be the string '11' or the int 2? Please justify your answer.
>
>
> On the other hand, if the language includes separate operators for
> addition and concatenation (say, + and &) then that sort of auto-
> conversion is no longer ambiguous:
>
> >>> '2' + 3
> 5
> >>> '2' & 3
> '23'


Bingo. Perl has specific operators to establish intent:
> Perl -e "'1' + 1"
> 2
> Perl -e "'1' . 1"
> 11
'+' is the operator for addition
'.' is the operator for string concatenation

int and string comparisons also have specific operators:
$a == $b # compare as integers: ==, >, <, <=, >=
$a eq $b # compare as strings: eq, gt, lt, le, ge


Which now morphs the conversation into the issue of how too much
operator overloading creates confusion and/or ambiguity.



*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

Paddy

1/7/2008 5:52:00 PM

0

On Jan 7, 5:09 pm, "Reedick, Andrew" <jr9...@ATT.COM> wrote:

> Bingo. Perl has specific operators to establish intent:
> > Perl -e "'1' + 1"
> > 2
> > Perl -e "'1' . 1"
> > 11
> '+' is the operator for addition
> '.' is the operator for string concatenation
>
> int and string comparisons also have specific operators:
> $a == $b # compare as integers: ==, >, <, <=, >=
> $a eq $b # compare as strings: eq, gt, lt, le, ge
>
> Which now morphs the conversation into the issue of how too much
> operator overloading creates confusion and/or ambiguity.
>
Or how using different operators for similar operations on different
types causes confusion.
i.e. == versus eq; > versus gt
If Perl had, for example, a complex number 'base' type would that need
yet another set of operators?

Well enough Perl vs Python. The thing is, that when writing in another
programming language you have to use its idioms or you end up fighting
the language in attempt to make it work like another language you are
more familiar with. In Python strings won't ever automatically change
to numbers.

- Paddy.

Reedick, Andrew

1/7/2008 7:26:00 PM

0

> -----Original Message-----
> From: python-list-bounces+jr9445=att.com@python.org [mailto:python-
> list-bounces+jr9445=att.com@python.org] On Behalf Of Paddy
> Sent: Monday, January 07, 2008 12:52 PM
> To: python-list@python.org
> Subject: Re: dictionary/hash and '1' versus 1
>
> Or how using different operators for similar operations on different
> types causes confusion.
> i.e. == versus eq; > versus gt
> If Perl had, for example, a complex number 'base' type would that need
> yet another set of operators?

The real question is: what's the simplest way to implement complex
numbers without sacrificing understanding, accuracy, and convenience? I
would say, no new operators. Imaginary numbers are numbers and should
use numeric operations which means overloaded match operators.

As background: In order to keep things simple, Perl's string operators
are string-like. Math operators are math.
'2' * 5 = 10
'2' x 5 = '22222' ('x' is a char, so think strings)
==, >, >=, <, <=
eq, gt, ge, lt, le (string abbreviations for equal, greater
than, etc.)
'1' + 1 = 2
'1' . 1 = 11 (Think period at the end of a sentence, which
implies stringing strings together.)


> Well enough Perl vs Python. The thing is, that when writing in another
> programming language you have to use its idioms or you end up fighting
> the language in attempt to make it work like another language you are
> more familiar with. In Python strings won't ever automatically change
> to numbers.

Agreed. However looking towards the future (new versions of
Perl/Python, new languages, new paradigms) is it worth asking whether
it's better/clearer/easier/more_accurate to
a) type cast the data: a + b (a and b must be of the same type)

a.1) explicitly type cast the data: str(a) + str(b)
(if a and b are different types)
b) type cast by operator: '1' + 1 = 2; '1' . 1 = '11'
c) go really old school with: concat('1', 1); add('1', 1)

IMO, since Python is strongly but dynamically typed, a) is the 'worst'
solution. If you forget to type cast, you're boned, since you probably
won't find the problem until the code block is actually executed and an
exception is thrown. You could defensively type cast everything, but
that can clutter the code, and cluttered code is harder to understand
and keep bug free. With b) or c), the compiler will type cast as you
intended. Again, just my opinion.

Anyway, it's little things like '1' + 1 that will probably prevent
programming syntax from ever being similar to naturally spoken language.


*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

Paddy

1/7/2008 7:54:00 PM

0

On Jan 7, 7:26 pm, "Reedick, Andrew" <jr9...@ATT.COM> wrote:
> > -----Original Message-----
> > From: python-list-bounces+jr9445=att....@python.org [mailto:python-
> > list-bounces+jr9445=att....@python.org] On Behalf Of Paddy
> > Sent: Monday, January 07, 2008 12:52 PM
> > To: python-l...@python.org
> > Subject: Re: dictionary/hash and '1' versus 1
>
> > Or how using different operators for similar operations on different
> > types causes confusion.
> > i.e. == versus eq; > versus gt
> > If Perl had, for example, a complex number 'base' type would that need
> > yet another set of operators?
>
> The real question is: what's the simplest way to implement complex
> numbers without sacrificing understanding, accuracy, and convenience? I
> would say, no new operators. Imaginary numbers are numbers and should
> use numeric operations which means overloaded match operators.
>
> As background: In order to keep things simple, Perl's string operators
> are string-like. Math operators are math.
> '2' * 5 = 10
> '2' x 5 = '22222' ('x' is a char, so think strings)
> ==, >, >=, <, <=
> eq, gt, ge, lt, le (string abbreviations for equal, greater
> than, etc.)
> '1' + 1 = 2
> '1' . 1 = 11 (Think period at the end of a sentence, which
> implies stringing strings together.)
>
> > Well enough Perl vs Python. The thing is, that when writing in another
> > programming language you have to use its idioms or you end up fighting
> > the language in attempt to make it work like another language you are
> > more familiar with. In Python strings won't ever automatically change
> > to numbers.
>
> Agreed. However looking towards the future (new versions of
> Perl/Python, new languages, new paradigms) is it worth asking whether
> it's better/clearer/easier/more_accurate to
> a) type cast the data: a + b (a and b must be of the same type)
>
> a.1) explicitly type cast the data: str(a) + str(b)
> (if a and b are different types)
> b) type cast by operator: '1' + 1 = 2; '1' . 1 = '11'
> c) go really old school with: concat('1', 1); add('1', 1)
>
> IMO, since Python is strongly but dynamically typed, a) is the 'worst'
> solution. If you forget to type cast, you're boned, since you probably
> won't find the problem until the code block is actually executed and an
> exception is thrown. You could defensively type cast everything, but
> that can clutter the code, and cluttered code is harder to understand
> and keep bug free. With b) or c), the compiler will type cast as you
> intended. Again, just my opinion.
>
> Anyway, it's little things like '1' + 1 that will probably prevent
> programming syntax from ever being similar to naturally spoken language.
>

I guess it comes down to the differences in fundamental principles of
Perl and Python. Perl is developed to "Do what I mean", whereas Python
would be more like "Do as I say". Perl strives to be more like a
spoken language, Python strives to have a core set of powerful &
composable ideas.

On your specific example I'd guess that both schemes work well its
just that I am more comfortable with Pythons one set of more
overloaded operators and vice-versa for yourself, leading us both to
have problems when we switch between Perl and Python :-)

- Paddy.