[Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source

noreply@sourceforge.net noreply@sourceforge.net
Sun, 26 May 2002 09:38:48 -0700


Patches item #557946, was opened at 2002-05-19 14:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470

Category: Core (C code)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Yves MENGANT (jymen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ebcdic compliancy in stringobject source

Initial Comment:
the printable character set test made inside
strincgobject.c is not compliant with EBCDIC
systems(OS390 or OS400)

----------------------------------------------------------------------

>Comment By: Jean-Yves MENGANT (jymen)
Date: 2002-05-26 16:38

Message:
Logged In: YES 
user_id=513881

The last attached diff files contains a more robust patch by
defining the HAVE_EBCDIC inside the pyconfig.h and using
this file inside the stringobject.c 

----------------------------------------------------------------------

Comment By: Jean-Yves MENGANT (jymen)
Date: 2002-05-23 11:47

Message:
Logged In: YES 
user_id=513881

I am still 100% with you on that ,my only remark here is that 
those are mainly either modules or py lib which are not part 
of python basic kernel. And the idea here is to be able to get 
a running minimal python kernel on an EBCDIC machine.

After that when the basic kernel is up in EBCDIC mode you'll 
need to deal with some module/lib EBCDIC portability and 
decide wether or not to adress them if you need to use 
them.... But the important idea here is to have the python 
kernel running in order not to be obliged to use REXX if 
you're prefering python :=) 



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-23 09:54

Message:
Logged In: YES 
user_id=21627

I believe there are a number of places where the code
assumes that 'a' .. 'z' covers all Latin letters, and only
those, e.g. pypcre.c, regexpr.c, sre.py.

----------------------------------------------------------------------

Comment By: Jean-Yves MENGANT (jymen)
Date: 2002-05-23 08:38

Message:
Logged In: YES 
user_id=513881

when porting to OS390(EBCDIC os) , the only place I found  
a bad ASCII asumption which leeds to further python's 
startup interpreter troubles is the one pointed here. When I 
fixed it I have been able to use the python interpreter kernel 
without troubles.Some modules like xmllib may make some 
ascii asumption but modules portability is a different story 
since those modules may be declared non EBCDIC 
compliant.

On the second topic using a C library function I am 100% ok 
the only question is that I am persuaded that using for 
instance the isascii XPG C function will generate more 
complex and slower code when trying to keep it in 
compliancy both with EBCDIC/ASCII targets. Having a more 
generic #define like :
#define EBCDIC inside the config.h set by ./configure when 
platform is EBCDIC is IMO the best compromise here.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-22 17:09

Message:
Logged In: YES 
user_id=21627

Is it really worth fixing this? Python assumes that the
character set of byte strings is an ASCII superset in many
places. If there is any change made here, it should be based
on C library functions, rather than on static knowledge of
the operating system.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470