- the concept of a nullable thing in Python doesn't exist; why not "optional"?

That's not what it means. Python parameters are "optional" if they
have a default value.  These parameters are "nullable", in the sense
that they can be either of a specific type or "None".  (But "Noneable"
seemed like a bad name).  They are not necessarily optional.

My inspiration for the name was Nullable in C#:

http://msdn.microsoft.com/en-us/library/1t3y8s4s.aspx

Argument Clinic already has converters that support "nullable":
str, UNICODE, and Py_buffer.  These map to the semantics of 'z', 'S*', etc.  I guess we could change it if it were a terrible name, but it isn't.


> - why is there a "error" field in the new structs?

It seemed like a good idea at the time.  Maybe it's redundant.  Can I get back to you?


> - the fact that the structs are defined in longobject.h looks bonkers

Okay.  What would be better?  modsupport.h?


> - boolean fields can be "char" instead of "int" (and moved at the
>   end to pack the structure more efficiently)

Is Python really compiled with packed structures?  I assumed -O3 turned on dword alignment in structures.

Aligned accesses are faster, and the additional memory use would be negligible.  These will only ever be declared as stack variables in parsing functions.


> - PyLong_AsSsize_t can't fail?

Not on an object returned by PyNumber_Index().  And by the way I literally copied and pasted the code that implements 'n'--it does that too.


> - does this change have a performance impact?

Compared to just using "i", it adds the converter call and the "== Py_None" check.  The performance impact should be so small as to be difficult to measure.