[XML-SIG] Re: PyExpat update

Paul Prescod paul@prescod.net
Mon, 07 Feb 2000 15:21:47 -0600


I'll take this to xml-sig where I meant to post in the first place.

"Fred L. Drake, Jr." wrote:
> 
> Paul Prescod writes:
>  > 1. Attributes would be returned as a mapping {key:value, key:value} and
>  > not a list [key,value,key,value] . Obviously this will break code that
>  > expected the former.
> 
>   This is good.
> 
>  > 2. Errors will be returned as strings, not integers. You can check for
>  > string equality using "==" The intention is not that you would hard-code
>  > strings into your code, but would rather use pre-defined string
>  > constants:
> 
>   Please explain *why* you need this change; could the constants not
> still be numbers?  (I'm not saying they *should* be numbers, just
> trying to understand the rationale for the change.)they're just IDs,

Well, why use numbers? The numbers are meaningless. Strings are at least
meaningful for some percentage of the world.

>  > foo = parser.Parse( data )
>  > if foo is pyexpat.unclosed_token:
>  >      print "Oops:"+pyexpat.unclosed_token
> 
>   Are the strings the error messages or some sort of identifier?  If
> they're IDs, this code fragment doesn't make sense.  If they're
> messages, you tie the C component to a specific (human) language.\

They are both messages and identifiers. As you can see above they can be
used as "dumb" identifiers (just like the integers) and they can be used
as strings if you happen to want to output English error messages (which
will be the case in the vast majority of situations just because most
programmers are too lazy/busy to localize).

>   My inclination is to stick with IDs (numeric or string) and map that
> to natural language in the application.

If you want to map in your application, you can do that. If you want to
print out the string, you can do that too. Think of them as IDs that
have a __str__ that happens to be English readable. Oh, and they happen
to be implemented as Python strings. :)

>  > 3. There will be no list of exceptions in the modules interface. Here's
>  > what it looks like now:
> ...
>  > I would rather move all of these to an "errors" dictionary so they don't
>  > clutter up the main module namespace (after converting them to strings
>  > instead of integers).
> 
>   So what's the dictionary look like?  I imagine something like:
> 
> errors = {
>     "XML_ERROR_SYNTAX": "Syntax error!",
>     ...
> }
> 
> or are the integers still there?

No integers.

On second thought, instead of a dictionary I'll use an instance so that
you can say 

if rv == errors.XML_ERROR_SYNTAX:
  ...

>  > setattr throws an proper exeption when you do a bad assignment
>  > setjmp/longjmp works on Windows
> 
>   So is setjmp/longjmp still used, or not?

No. I meant to say that handler error reporting now works on Windows.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"If I say something, yet it does not fill you with the immediate
burning desire to voluntarily show it to everyone you know, well then,
it's probably not all that important."
    - http://www.bespoke.org/viridian/