Martin v. L=F6wis wrote: > "M.-A. Lemburg" <mal@lemburg.com> writes: >=20 >=20 >>>4) I've had a long outstanding patch to add methods like isalpha() to >>>string objects. The goal was to make sure that replacements exist >>>for all the tools in the string module. The hold-up has been in >>>making UniCode equivalents. If this is still wanted, I'll finish it u= p. >> >>Hmm, Unicode object already have these methods... >=20 > I think Raymond is talking about methods *like* isalpha :-) See patch > 562501, he wants ispunct, isgraph, isprint, isctrl, isxdigit, i.e. all > ctype.h macros. Unicode objects don't support these, and the ctype.h > macros aren't available for them. I see. >>I'd like to add another TODO to the list: >> >>5) Add functions sys.setdefaultsourceencoding() and >> sys.getdefaultsourceencoding() which allow setting and >> querying the Python compiler's assumption about the >> default source code encoding (currently ASCII) much in >> the same way as sys.set/getdefaultencoding() work for >> the internal string encoding assumption. >=20 > This should not go into 2.3 (just as the other features shouldn't go > there). It was planned for 2.3 several months ago. The fact that it isn't in there yet is mostly my fault: I didn't have time to cook up a patch and forgot to ask here for other volunteers. > I personally envision that this is solved in a different way: Instead > of having a global setting, there should be a context-specific one, > for use in eval/exec, and interactive mode. The "default" encoding for > source code files should not be settable, and should remain at ASCII > forever. This feature is needed to calm down concerns of non-ASCII Python users who want to customize Python to better suit their needs for both educational and production use purposes. The same disclaimers as for the sys.setdefaultencoding() pair of APIs apply to these too. The implementation should follow the same path that the default encoding is using (storing it in the interpreter state instead of a global). --=20 Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jun 21 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 3 days left
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4