Mailman 3 June 2000 - Python-Dev

[Fwd: Re: Case sensitivity]
by Paul Prescod June 8, 2000

June 8, 2000

Here's a good summary of how XML's case sensitivity came to be. -------- Original Message -------- Subject: Re: Case sensitivity Date: Mon, 3 Apr 2000 12:44:37 -0400 From: Steve DeRose <Steven_DeRose(a)brown.edu> To: xml-dev(a)lists.oasis-open.org References: <B50E2EFA.1B57%soord(a)vda.nl> Languages with no need for case folding are not much of a problem: the case-folding table or program would merely have no effect on characters belonging to such languages: It would change 26 of … [View More]

1 0

Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26
by Greg Stein June 8, 2000

June 8, 2000

On Wed, Jun 07, 2000 at 05:08:17PM -0700, Greg Ward wrote: > Update of /cvsroot/python/distutils/distutils/command > In directory slayer.i.sourceforge.net:/tmp/cvs-serv15881 > > Modified Files: > sdist.py > Log Message: > Made all debug output go through the 'debug_print()' method instead of > directly printing to stdout. This was a bit more work than it sounds like > it should have been: > * turned 'select_pattern()' and 'exclude_pattern()' from functions … [View More]

3 2

Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22
by Greg Stein June 8, 2000

June 8, 2000

On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg <mal(a)lemburg.com>: > Change the default encoding to 'ascii' (it was previously > defined as UTF-8). > > Note: The implementation still uses UTF-8 to implement > the buffer protocol, so C … [View More]

2 1

Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5)
by pf＠artcom-gmbh.de June 8, 2000

June 8, 2000

Hi, Marc-Andre Lemburg: [...] > Added a new locale name aliasing engine which also supports > locale encodings, a feature which is used by the new default > encoding support in site.py. > > Index: locale.py [...] > + ### C lib locale APIs > + > + from _locale import * Wouldn't it be clever to provide some dummy stubs on those platforms, where the _locale module was not enabled? try: from _locale import * except: def setlocale(.... def localeconv(.... … [View More]

3 3

Package ambiguities
by andy＠robanal.demon.co.uk June 8, 2000

June 8, 2000

We hit some very weird behaviour recently while setting up a package hierarchy. Robin Becker managed to distil this into a simple example. Can anyone shed any light on what is happening below? Is Python behaving as it should? Create a package A, empty __init__.py, with modules as follows: --------parent.py---------- class Parent: pass --------child.py------------ from parent import Parent class Child(Parent): pass ---------test.py-------- from parent import * class Examiner: … [View More]

7 10

Package Style Guide
by Andy Robinson June 8, 2000

June 8, 2000

Thanks for all the replies. We really need a 'style guide' on package use, so I hope this example can be thrashed out and used to help others. We need to decide something and release next week, and also provide good docs for other users who will be new to Python. Apart from the ambiguity, which was a surprise but which we can work around, I have some general questions on the "right thing". Here are my examples: 1. use of __init__ to save users work ------------------------------------ … [View More]ReportLab has a subpackage called 'platypus' which we have just reorganized and not yet released. The division into subpackages is clear - each exposes a different kind of functionality - but the division of each package into modules is based on keeping a sane length for each and not on providing a friendly user interface. reportlab pdfgen canvas.py defines class Canvas textobject.py defines class TextObject pathobject.py defines class PathObject platypus (the same problem, but 3x worse) lib (loads of modules, all independent) We reached a point where users need to import eight or ten classes to do useful work and were having to put eight or ten different import lines at the top of every script. This just feels dumb and wrong. So, the 'least messy' idea was to put __init__.py methods in each subpackage which explicitly import what they need. (We have not used "import *") ---reportlab/pdfgen/__init__.py-------- from canvas import Canvas from textobject.py import TextObject from pathobject.py impory PathObject Then users can just do: from reportlab.pdfgen import Canvas, PathObject, TextObject It seems that this (a) makes life easier for users, and (b) gives us freedom to refactor code as it grows, without changing the user interface. Is this style evil? If so, why? 2. Ambiguities running scripts within package --------------------------------------------- We have various test functions scattered throughout our distribution. A control script iterates through the lot and kicks them off before every release, executing everything with an 'if __name__=='__main__' handler. If these were standalone scripts just for testing, they could import "reportlab.platypus.tables" or whatever. But if I just want to put a test routine at the end of "reportlab.platypus.tables" then I seem destined to run into exactly the ambiguity outlined before. Should test scripts all be moved out of the package? Indeed, is Python behaving the way it ought to? 3. Preferred subpackage import technique ---------------------------------------- I have two scripts 'spam.py' and 'eggs.py' in subpackage 'A.B'. spam imports eggs. Should it say... import eggs or... import A.B.eggs? Both work sometimes, but can lead to different behavious sometimes. Which is the preferred style? Thanks, Andy Robinson [View Less]

4 4

release forms? (was: [Patches] New sys method to return total reference count in debug builds.)
by Greg Stein June 8, 2000

June 8, 2000

Given the New World Order, how does that impact the need for these release statements and/or wet signatures? Or a better way to put it, who "owns" Python now? Given a "who", then we can ask that person/entity whether they want release statements. Given that Python is now on SourceForge, and there are multiple people (at CNRI and otherwise) that can directly make modifications, then the release below is certainly a bit "off". For example, David Ascher has commit privs, so at his "sole … [View More]

5 7

Re: [Python-Dev] hey, who broke the array module?
by Jack Jansen June 7, 2000

June 7, 2000

Recently, Guido van Rossum <guido(a)python.org> said: > > On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote: > > > > I broke it with my patches to test overflow for some of the PyArg_Parse > *() > > > > formatting characters. The upshot of testing for overflow is that now t > hose > > > > formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or > > > > unsigned-ness as appropriate (you have to know if the value … [View More]is signed o > r > > > > unsigned to know what limits to check against for overflow). Two > > > > possibilities presented themselves: > > > > > > I think this is a _very_ bad idea. I have a few thousand (literally) rout > ines > > > calling to Macintosh system calls that use "h" for 16 bit flag-word value > s, > > > and the constants are all of the form > > > > > > kDoSomething = 0x0001 > > > kDoSomethingElse = 0x0002 > > > ... > > > kDoSomethingEvenMoreBrilliant = 0x8000 > > > > > > I'm pretty sure other operating systems have lots of calls with similar > > > problems. I would strongly suggest using a new format char if you want > > > overflow-tested integers. > > > > Sigh. What do you think Guido? This is your call. > > > > 1. go back to no bounds testing > > 2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and > > unsigned values but is sort of false security for bounds checking) > > 3. keep it the way it is: 'b' is unsigned and the rest are signed > > 4. add new format characters or a modifying character for signed and unsign > ed > > versions of these. > > Sigh indeed. Ideally, we'd introduce H for unsigned and then lock > Jack in a room with his Macintosh computer for 48 hours to fix all his > code... Hmm, hmm. As stated before I'm not too fond of this as it is a gratuitous change that breaks lots of things (not only in Mac modules: the array module was what started this discussion, test_cPickle and test_pkg crash, socketmodule, os.stat() and I assume all code that uses structmodule will also have to be looked at, and quite possibly there's a lot more) and for which I don't really see all that much benefit. As a datapoint: a quick search for 8-digit hex numbers starting with digit 8-F and not suffixed with an L throughout the Python files in the distribution found a stunning 464 matches. Add another 1147 4-digit hex numbers with the sign bit on and there are an awful lot of candidates for breaking... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm [View Less]

1 0

Revised 1.6 jobs list
by Andrew Kuchling June 7, 2000

June 7, 2000

I've slightly revised the 1.6 jobs list at http://www.python.net/crew/amk/python/1.6-jobs.html . Things still on the TODO list, maybe: Import hooks revamp (or is this a post-1.6 thing?) Update the documentation to match 1.6 changes. Document more undocumented modules (goes without saying, really...) : codecs, unicodedata, mmap, pyexpat, curses, regrtest. Unicode: Compress the size of unicodedatabase Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch) Unicode: the various … [View More]

13 27

Fwd: Hmmmm... (Jim Anderson)
by Jeremy Hylton June 7, 2000

June 7, 2000

You guys haven't seen more Perl traffic on this list have you? :-) Jeremy

1 0