exception message output problem

[Russ P.]

I am baffled about why my exception messages are not displaying
properly.

I have a class that represents physical scalars with units. If I type

>>3 * s + 4 * m

I should get something like this:

scalar.Inconsis tentUnits: 3 s, 4 m

to show that seconds cannot be added to meters. Instead, the message
is broken up into individual characters, like this:

scalar.Inconsis tentUnits: ('3', ' ', 's', ',', ' ', '4', ' ', 'm')

This worked correctly for months, so I don't understand what went
wrong. I am using version 2.5.1 on a Dell workstation with Red Hat
Enterprise WS Linux.

As far as I can tell, I am doing everything "by the book." Here is my
exception class:

class InconsistentUni ts(Exception):
def __init__(self, args=""): self.args = args

and here is my instantiation of it:

raise scalar.Inconsis tentUnits, str(self) + ", " + str(other)

I've tried various little changes, but nothing seems to make any
difference. Has anyone else noticed this sort of behavior? Thanks.

By the way, my scalar class is available for free from http://RussP.us/scalar.htm
.. A complete user guide is available. Check it out. I think you'll
like it.

[Lie]

On Dec 22, 2:57*am, "Russ P." <Russ.Paie...@g mail.comwrote:

I am baffled about why my exception messages are not displaying
properly.

I have a class that represents physical scalars with units. If I type

>3 * s + 4 * m

I should get something like this:

scalar.Inconsis tentUnits: 3 s, 4 m

to show that seconds cannot be added to meters. *Instead, the message
is broken up into individual characters, like this:

scalar.Inconsis tentUnits: ('3', ' ', 's', ',', ' ', '4', ' ', 'm')

This worked correctly for months, so I don't understand what went
wrong. I am using version 2.5.1 on a Dell workstation with Red Hat
Enterprise WS Linux.

As far as I can tell, I am doing everything "by the book." Here is my
exception class:

* * class InconsistentUni ts(Exception):
* * * * def __init__(self, args=""): self.args = args

and here is my instantiation of it:

* * * * raise scalar.Inconsis tentUnits, str(self) + ", " + str(other)

I've tried various little changes, but nothing seems to make any
difference. Has anyone else noticed this sort of behavior? Thanks.

By the way, my scalar class is available for free fromhttp://RussP.us/scalar.htm
. A complete user guide is available. Check it out. I think you'll
like it.

The problem is in the InconsistentUni ts Exception. It seems that the
act of:
self.args = 'Some String'
would break the string into chars, possibly because self.args think
'Some String' is a tuple of some sort.

Change the exception into this:
class InconsistentUni ts(Exception):
def __init__(self, args=""): self.args = (args,)
# Python have an odd (read: broken) singleton implementation
# single member tuple must have a comma behind it

[Bruno Desthuilliers]

Lie a écrit :
(snip)

# Python have an odd (read: broken) singleton implementation
# single member tuple must have a comma behind it

You may call it weird or even a wart if you want, but given that what
makes the tuple is the comma - not the parens[1] -, it is _not_ broken.

[1] with the exception of the empty tuple.

[Russ P.]

On Dec 21, 2:58 pm, Lie <Lie.1...@gmail .comwrote:

Change the exception into this:
class InconsistentUni ts(Exception):
def __init__(self, args=""): self.args = (args,)
# Python have an odd (read: broken) singleton implementation
# single member tuple must have a comma behind it

Hey, that worked. Thanks.

Actually, the parens aren't needed, so this works too:

def __init__(self, args=""): self.args = args,

The trailing comma wasn't necessary a while back (pre 2.5?), so
something in Python must have changed. I'd say that it looks a bit
cleaner without the trailing comma, so maybe whatever changed should
get changed back.

[Lie]

On Dec 22, 6:18*am, Bruno Desthuilliers
<bdesth.quelque [e-mail] quepart.frwrote :

Lie a écrit :
(snip)

# Python have an odd (read: broken) singleton implementation
# single member tuple must have a comma behind it

You may call it weird or even a wart if you want, but given that what
makes the tuple is the comma - not the parens[1] -, it is _not_ broken.

[1] with the exception of the empty tuple.

I also realized that you don't need to use parens to make tuple, it's
rather my habit to always use parens in making a tuple (because "print
'%s + %s + %s' % (a, b, c)" _must_ have a parens (otherwise Python
thinks b and c is arguments for the print not for the string
formatting) and because Python always return a tuple w/ parens)

PS: My wording on broken doesn't actually means broken so it won't
work, but rather broken syntactically, making the syntax inconsistent,
funny, illogical, etc. One could argue though that the trailing comma
is a formalized workaround.

[Lie]

PPS: Actually, what makes a tuple is both the parens and the comma,
with comma as the minimum signifier, inspect this: "str(a) +
str((a,b,c))", you have to use the double parens, one to make the
tuple and the other as part of the str. This harmless little case
gives error if done without the double parens, but what would happen
if we exchange the str into a function that accepts one argument and
several optional arguments (or better yet, one argument and an
optional * argument)?

[Fredrik Lundh]

Russ P. wrote:

Actually, the parens aren't needed, so this works too:

def __init__(self, args=""): self.args = args,

The trailing comma wasn't necessary a while back (pre 2.5?), so
something in Python must have changed. I'd say that it looks a bit
cleaner without the trailing comma, so maybe whatever changed should
get changed back.

as the name implies, "args" is supposed to be a sequence, and is stored
internally as a tuple. if something has changed, it's probably that 2.5
enforces this behaviour via a property.

to fix your code, just replace your own __init__ method with a "pass",
and leave the initialization to the Exception class itself.

</F>

[Mel]

Lie wrote:

PPS: Actually, what makes a tuple is both the parens and the comma,
with comma as the minimum signifier, inspect this: "str(a) +
str((a,b,c))", you have to use the double parens, one to make the
tuple and the other as part of the str. This harmless little case
gives error if done without the double parens, but what would happen
if we exchange the str into a function that accepts one argument and
several optional arguments (or better yet, one argument and an
optional * argument)?

I think the effect there is operator precedence. In

str(a,b,c)

the function-calling operator () takes over, and the commas are
considered as argument separators. In

str ((a,b,c))

the inner parens present a single tuple-expression to the
function-calling operator.

Just like a+b/c as against (a+b)/c but with esoteric overloading
of ( ) and , .
Mel.

[Bruno Desthuilliers]

Lie a écrit :

PPS: Actually, what makes a tuple is both the parens and the comma,

Nope, it's definively the comma. You can check the language's grammar,
it's part of the doc. Or just test FWIW:

Python 2.4.3 (#1, Mar 12 2007, 23:32:01)
[GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on
linux2
Type "help", "copyright" , "credits" or "license" for more information.

>>a = 1,
type(a)

<type 'tuple'>

>>>

with comma as the minimum signifier, inspect this: "str(a) +
str((a,b,c))", you have to use the double parens, one to make the
tuple and the other as part of the str.

This is a problem of operator precedence.

[Lie]

On Dec 23, 4:30*am, Bruno Desthuilliers
<bdesth.quelque [e-mail] quepart.frwrote :

Lie a écrit :

PPS: Actually, what makes a tuple is both the parens and the comma,

Nope, it's definively the comma. You can check the language's grammar,
it's part of the doc. Or just test FWIW:

Python 2.4.3 (#1, Mar 12 2007, 23:32:01)
[GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on
linux2
Type "help", "copyright" , "credits" or "license" for more information.
*>>a = 1,
*>>type(a)
<type 'tuple'>
*>>>

with comma as the minimum signifier, inspect this: "str(a) +
str((a,b,c))", you have to use the double parens, one to make the
tuple and the other as part of the str.

This is a problem of operator precedence.

I think some people have misunderstood me, I know parens isn't a
formal definition for tuples, but it's more or less a de facto
grammar, as it is hard to create parens-less tuples without the
interpreter mistaking it for other things, except for a few cases.