PyExpat update

Fred L. Drake, Jr. fdrake at acm.org
Mon Feb 7 14:43:35 EST 2000


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, 

 > 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.
  My inclination is to stick with IDs (numeric or string) and map that 
to natural language in the application.

 > IIRC, Python is smart about checking for pointer equality before string
 > equality, right?) 

  Yes.

 > 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?

 > -----------------
 > 
 > Here are the new features I have already added.

  Cool!

 >  * new error handling:
 > 
 > setjmp/longjmp is gone
...
 >  * bug fixes:
 > 
 > setattr throws an proper exeption when you do a bad assignment
 > setjmp/longjmp works on Windows

  So is setjmp/longjmp still used, or not?


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives




More information about the Python-list mailing list