Mailman 3 April 2000 - Python-Dev

Re: [Python-Dev] PYTHON_API_VERSION and threading
by Jack Jansen April 7, 2000

April 7, 2000

> > Something that just struck me: couldn't we use a couple of bits in the > > PYTHON_API_VERSION to check various other things that make dynamic modules > > break? WITH_THREAD is the one I just ran in to, but there's a few others such > > as the object refcounting statistics and platform-dependent things like the > > debug/nodebug compilation on Windows. > > I'm curious what combination didn't work? The thread APIs are > supposed to be designed so … [View More]

1 0

Why do we need Traceback Objects?
by Christian Tismer April 7, 2000

April 7, 2000

Hi, while fixing my design flaws after Just's Stackless Mac port, I was dealing with some overflow conditions and tracebacks. When there is a recursion depth overflow condition, we create a lot of new structure for the tracebacks. This usually happens in a situation where memory is quite exhausted. Even worse if we crash because of a memory error: The system will not have enough memory to build the traceback structure, to report the error. Puh :-) When I look into tracebacks, it turns out to … [View More]

5 10

default encoding for 8-bit string literals (was Unicode and comparisons)
by pf＠artcom-gmbh.de April 7, 2000

April 7, 2000

Hi! [me]: > > From my POV (using ISO Latin-1 all the time) it would be > > "intuitive"(TM) to assume ISO Latin-1 when interpreting u'äöü' in a > > Python source file so that (u'äöü' == 'äöü') == 1. This is what I see > > on *my* screen, whether there is a 'u' in Front of the string or not. M.-A. Lemburg: > u"äöü" is being interpreted as Latin-1. The problem is the > string 'äöü' to the right: during coercion this string is > being interpreted as UTF-8 and … [View More]this causes the failure. > > You could say: ok, all my strings use Latin-1, but that would > introduce other problems... esp. when you take different > modules with different encoding assumptions and try to > integrate them into an application. Okay. This wouldn't occur here but we have deal with this possibility. > > In dist/src/Misc/unicode.txt you wrote: > > > > > Note that you should provide some hint to the encoding you used to > > > write your programs as pragma line in one the first few comment lines > > > of the source file (e.g. '# source file encoding: latin-1'). [me]: > > The upcoming 1.6 documentation should probably clarify whether > > the interpreter pays attention to "pragma"s or not. > > This is otherwise misleading. > > This "pragma" is nothing more than a hint for the source code > reader to switch his viewing encoding. The interpreter doesn't > treat the file differently. In fact, Python source code is > supposed to tbe 7-bit ASCII ! Sigh. In our company we use 'german' as our master language so we have string literals containing iso-8859-1 umlauts all over the place. Okay as long as we don't mix them with Unicode objects, this doesn't hurt anybody. What I would love to see, would be a well defined way to tell the interpreter to use 'latin-1' as default encoding instead of 'UTF-8' when dealing with string literals from our modules. The tokenizer in Python 1.6 already contains smart logic to get the size of TABs right (pasting from tokenizer.c): /* Skip comment, while looking for tab-setting magic */ if (c == '#') { static char *tabforms[] = { "tab-width:", /* Emacs */ ":tabstop=", /* vim, full form */ ":ts=", /* vim, abbreviated form */ "set tabsize=", /* will vi never die? */ /* more templates can be added here to support other editors */ }; .. It wouldn't be to hard to add something there to recognize other "pragma" comments like for example: #content-transfer-encoding: iso-8859-1 But what to do with it? May be adding a default encoding to every string object? Is this bloat? Just an idea. Regards, Peter [View Less]

4 9

Pythons (Like Buses) Considered Harmful
by Ka-Ping Yee April 7, 2000

April 7, 2000

So, has anyone not seen Doctor Fun today yet? http://metalab.unc.edu/Dave/Dr-Fun/latest.jpg :) :) -- ?!ng

2 1

DLL in the system directory on Windows
by Thomas Heller April 7, 2000

April 7, 2000

> However, as we import data from Python16.dll rather then purely > addresses, we can't use any of these interception solutions. What's wrong with: #define PyClass_Type *(GetProcAddress(hdll, "PyClass_Type")) I have only looked at PythonCOM15.dll, and it seems that there are only references to a handfull of exported data items: some Py*_Type, plus _PyNone_Struct, _PyTrue_Struct, _PyZero_Struct. Thomas Heller

2 3

DLL in the system directory on Windows.
by Mark Hammond April 6, 2000

April 6, 2000

The 1.6a1 installer on Windows copies Python16.dll into the Python directory, rather than the system32 directory like 1.5.x. We discussed too long ago on this list not why this was probably not going to work. I guess Guido decided to "suck it and see" - which is fine. But guess what - it doesnt work :-( I couldnt get past the installer! The win32all installer executes some Python code at the end of the install (to generate the .pyc files and install the COM objects). This Python code is … [View More]

8 35

Unicode documentation
by Fred L. Drake, Jr. April 6, 2000

April 6, 2000

I've added Marc-Andre's documentation updates for Unicode to the Python CVS repository; I don't think I've done any damage. Marc-Andre, please review and let me know if I've missed anything! Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

1 0

Re: unicode: strange exception
by Fredrik Lundh April 6, 2000

April 6, 2000

>>> None in "abc" Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: coercing to Unicode: need string or charbuffer now that's an interesting error message. I think the old one was better ;-) </F>

3 2

Unicode and comparisons
by M.-A. Lemburg April 6, 2000

April 6, 2000

Fredrik bug report made me dive a little deeper into compares and contains tests. Here is a snapshot of what my current version does: >>> '1' == None 0 >>> u'1' == None 0 >>> '1' == 'aäöü' 0 >>> u'1' == 'aäöü' Traceback (most recent call last): File "<stdin>", line 1, in ? UnicodeError: UTF-8 decoding error: invalid data >>> '1' in ('a', None, 1) 0 >>> u'1' in ('a', None, 1) 0 >>> '1' in (u'aäöü', None, 1) 0 >>> … [View More]

10 16

_PyUnicode_New/PyUnicode_Resize
by Bill Tutt April 6, 2000

April 6, 2000

should be exported as part of the unicode object API. Otherwise, external C codec developers have to jump through some useless and silly hoops in order to construct a PyUnicode object. Additionally, you mentioned to Andrew that the decoders don't have to return a tuple anymore. Thats currently incorrect with whats currently in CVS: Python\codecs.c:PyCodec_Decode() current requires, but ignores the integer returned in the tuple. Should this be fixed, or must codecs return the integer as Misc\… [View More]

3 3