Mailman 3 May 2000 - Python-Dev

Re: [Python-checkins] CVS: python/dist/src/Tools/idle browser.py,NONE,1.1
by Guido van Rossum May 10, 2000

May 10, 2000

Fred, "browser" is a particularly non-descriptive name for this module. Perhaps it's not too late to rename it to e.g. "BrowserControl"? --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Patches] PC\config.[hc] changes for Win64
by Trent Mick May 10, 2000

May 10, 2000

On Mon, May 08, 2000 at 10:16:42AM -0400, Guido van Rossum wrote: > > The patch to config.h looks big but it really is not. These are the effective > > changes: > > - MS_WINxx are keyed off _WINxx > > - SIZEOF_VOID_P is set to 8 for Win64 > > - COMPILER string is changed appropriately for Win64 > > One thing worries me: if COMPILER is changed, that changes > sys.platform to "win64", right? I'm sure that will break plenty of > code which currently tests … [View More]

8 20

Python Query
by Christian Zupancic May 9, 2000

May 9, 2000

====================================================================== Greetings Python Developers, Please participate in a small survey about Python for BeOpen.com that we are conducting with the guidance of our advisor, and the creator of Python, Guido van Rossum. In return for answering just five short questions, I will mail you up to three (3) BeOpen T-shirts-- highly esteemed by select trade-show attendees as "really cool". In addition, three lucky survey participants will receive a Life-… [View More]

1 0

global encoding?!? (was: [Python-checkins] ... unicodeobject.c)
by Greg Stein May 9, 2000

May 9, 2000

On Tue, 9 May 2000, Fred Drake wrote: > Update of /projects/cvsroot/python/dist/src/Objects > In directory seahag.cnri.reston.va.us:/home/fdrake/projects/python/Objects > > Modified Files: > unicodeobject.c > Log Message: > > M.-A. Lemburg <mal(a)lemburg.com>: > Added support for user settable default encodings. The > current implementation uses a per-process global which > defines the value of the encoding parameter in case it > is set to NULL (… [View More]

3 3

Re: [Patches] make 'b','h','i' raise overflow exception
by Trent Mick May 9, 2000

May 9, 2000

On Mon, May 08, 2000 at 10:00:30AM -0400, Guido van Rossum wrote: > > Changes the 'b', 'h', and 'i' formatters in PyArg_ParseTuple to raise an > > Overflow exception if they overflow (previously they just silently > > overflowed). > > Trent, > > There's one issue with this: I believe the 'b' format is mostly used > with unsigned character arguments in practice. >However on systems > with default signed characters, CHAR_MAX is 127 and values 128-255 are &… [View More]gt; rejected. I'll change the overflow test to: > > else if (ival > CHAR_MAX && ival >= 256) { > > if that's okay with you. > Okay, I guess. Two things: 1. In a way this defeats the main purpose of the checks. Now a silent overflow could happen for a signed byte value over CHAR_MAX. The only way to automatically do the bounds checking is if the exact type is known, i.e. different formatters for signed and unsigned integral values. I don't know if this is desired (is it?). The obvious choice of 'u' prefixes to specify unsigned is obviously not an option. Another option might be to document 'b' as for unsigned chars and 'h', 'i', 'l' as signed integral values and then set the bounds checks ([0, UCHAR_MAX] for 'b') appropriately. Can we clamp these formatters so? I.e. we would be limiting the user to unsigned or signed depending on the formatter. (Which again, means that it would be nice to have different formatters for signed and unsigned.) I think that the bounds checking is false security unless these restrictions are made. 2. The above aside, I would be more inclined to change the line in question to: else if (ival > UCHAR_MAX) { as this is more explicit about what is being done. > Another issue however is that there are probably cases where an 'i' > format is used (which can't overflow on 32-bit architectures) but > where the int value is then copied into a short field without an > additional check... I'm not sure how to fix this except by a complete > inspection of all code... Not clear if it's worth it. Yes, a complete code inspection seems to be the only way. That is some of what I am doing. Again, I have two questions: 1. There are a fairly large number of downcasting cases in the Python code (not necessarily tied to PyArg_ParseTuple results). I was wondering if you think a generalized check on each such downcast would be advisable. This would take the form of some macro that would do a bounds check before doing the cast. For example (a common one is the cast of strlen's size_t return value to int, because Python strings use int for their length, this is a downcast on 64-bit systems): size_t len = strlen(s); obj = PyString_FromStringAndSize(s, len); would become size_t len = strlen(s); obj = PyString_FromStringAndSize(s, CAST_TO_INT(len)); CAST_TO_INT would ensure that 'len'did not overflow and would raise an exception otherwise. Pros: - should never have to worry about overflows again - easy to find (given MSC warnings) and easy to code in (staightforward) Cons: - more code, more time to execute - looks ugly - have to check PyErr_Occurred every time a cast is done I would like other people's opinion on this kind of change. There are three possible answers: +1 this is a bad change idea because...<reason> -1 this is a good idea, go for it +0 (mostly likely) This is probably a good idea for some case where the overflow *could* happen, however the strlen example that you gave is *not* such a situation. As Tim Peters said: 2GB limit on string lengths is a good assumption/limitation. 2. Microsofts compiler gives good warnings for casts where information loss is possible. However, I cannot find a way to get similar warnings from gcc. Does anyone know if that is possible. I.e. int i = 123456; short s = i; // should warn about possible loss of information should give a compiler warning. Thanks, Trent -- Trent Mick trentm(a)activestate.com [View Less]

3 4

Cannot declare the largest integer literal.
by Trent Mick May 8, 2000

May 8, 2000

>>> i = -2147483648 OverflowError: integer literal too large >>> i = -2147483648L >>> int(i) # it *is* a valid integer literal -2147483648 As far as I traced back: Python/compile.c::com_atom() calls Python/compile.c::parsenumber(s = "2147483648") calls Python/mystrtoul.c::PyOS_strtol() which returns the ERANGE errno because it is given 2147483648 (which *is* out of range) rather than -2147483648. My question: Why is the minus sign not considered part of the "… [View More]

5 8

Re: Python 1.6a2 Unicode bug (was Re: comparing strings and ints)
by Just van Rossum May 8, 2000

May 8, 2000

I wrote: >A utf-8-encoded 8-bit string in Python is *not* a string, but a "ByteArray". Another way of putting this is: - utf-8 in an 8-bit string is to a unicode string what a pickle is to an object. - defaulting to utf-8 upon coercing is like implicitly trying to unpickle an 8-bit string when comparing it to an instance. Bad idea. Defaulting to Latin-1 is the only logical choice, no matter how western-culture-centric this may seem. Just

16 66

Re: [XML-SIG] Re: [I18n-sig] Re: [Python-Dev] Unicode debate
by ht＠cogsci.ed.ac.uk May 7, 2000

May 7, 2000

Guido van Rossum <guido(a)python.org> writes: > Paul, we're both just saying the same thing over and over without > convincing each other. I'll wait till someone who wasn't in this > debate before chimes in. OK, I've never contributed to this discussion, but I have a long history of shipping widely used Python/Tkinter/XML tools (see my homepage). I care _very_ much that heretofore I have been unable to support full XML because of the lack of Unicode support in Python. I've … [View More]

4 5

should a float overflow or just equal 'inf'
by Trent Mick May 6, 2000

May 6, 2000

Hi all, I submitted a patch a coupld of days ago to have the 'b', 'i', and 'h' formatter for PyArg_ParseTuple raise an Overflow exception if they overflow (currently they just silently overflow). Presuming that this is considered a good idea, should this be carried to floats. Floats don't really overflow, they just equal 'inf'. Would it be more desireable to raise an Overflow exception for this? I am inclined to think that this would *not* be desireable based on the following quote: """ the-… [View More]

2 1

Pickle diffs anyone?
by Jim Fulton May 5, 2000

May 5, 2000

Someone recently made a cool proposal for utilizing diffs to save space taken by old versions in the Zope object database: http://www.zope.org/Members/jim/ZODB/ReverseDiffVersioning To make this work, we need a good way of diffing pickles. I thought maybe someone here would have some good suggestions. I do think that the topic is sort of interesting (for some definition of "interesting" ;). The page above is a Wiki page. (Wiki is awesome. If you haven't seen it before, check out http://… [View More]

3 2