Mailman 3 December 1999 - Python-Dev

Better text processing support in py2k?
by Skip Montanaro Jan. 3, 2000

Jan. 3, 2000

It just occurred to me as I was replying to a request on the main list, that Python's text handling capabilities could be a bit better than they are. This will probably not come as a revelation to many of you, but I finally put it together with the standard argument against beefing things up One fix would be to add regular expressions to the language core and have special syntax for them, as Perl has done. However, I don't like this solution because Python is a general-purpose … [View More]language, and regular expressions are used for the single application domain of text processing. For other application domains, regular expressions may be of no interest, and you might want to remove them to save memory and code size. and the observation that Python does support some builtin objects and syntax that are fairly specific to some much more restricted application domains than text processing. I stole the above quote from Andrew Kuchling's Python Warts page, which I also happened to read earlier today. What AMK says makes perfect sense until you examine some of the other things that are in the language, like the Ellipsis object and complex numbers. If I recall correctly both were added as a result of the NumPy package development. I have nothing against ellipses or complex numbers. They are fine first class objects that should remain in the language. But I have never used either one in my day-to-day work. On the other hand, I read files and manipulate them with regular expressions all the time. I rather suspect that more people use Python for some sort of text processing than any other single application domain. Python should be good at it. While I don't want to turn Python into Perl, I would like to see it do a better job of what most people probably use the language for. Here is a very short list of things I think need attention: 1. When using something like the simple file i/o idiom for line in f.readlines(): dofunstuff(line) the programmer should not have to care how big the file is. It should just work in a reasonably efficient manner without gobbling up all of memory. I realize this may require some change to the syntax of the common idiom. 2. The re module needs to be sped up, if not to catch up with Perl, then to catch up with the deprecated regex module. Depending how far people want to go with things, adding some language syntax to support regular expressions might be in order. I don't see that as compelling as adding complex numbers however. Another possibility, now that Barry Warsaw has opened the floodgates, is to add regular expression methods to strings. 3. I've not yet used it, but I am told the pattern matching in Marc-Andre Lemburg's mxTextTools (http://starship.python.net/crew/lemburg/) is both powerful and efficient (though it certainly appears complex). Perhaps it deserves consideration for incorporation into the core Python distribution. I'm sure other people will come up with other suggestions. Skip Montanaro | http://www.mojam.com/ skip(a)mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented... [View Less]

5 10

Re: [Distutils] Questions about distutils strategy
by Guido van Rossum Jan. 1, 2000

Jan. 1, 2000

[Great analysis, Tim!] > 4) The audience is Python end-users "in general", and the product is pure > Python. I think this is the most important one for Distutils to address, > and compilation isn't a part of it. So far, though, what Gordon is doing > seems more appropriate than what Distutils has been up to. I hope his work > gets folded into this. I'm not sure what stuff by which Gordon you're referring to. I am only familiar with his installer, which I thought is win32 … [View More]

14 78

Fixed-decimal types
by Jim Fulton Dec. 30, 1999

Dec. 30, 1999

While on the subject of RDBMS systems, a common need is to be able to work with fixed-decimal data. I think a standard Python fixed-decimal type would help to make Python database interfaces alot more robust. I even wonder if the Python long type might be hijacked for this purpose by adding a "scale" that indicates the number of digits to the right of the decimal point. For example, an expression like: 1000000000.2500L would create a fixed decimal number with a scale of 4. People have … [View More]

3 5

Re: [Python-Dev] Better text processing support in py2k?
by Andy Robinson Dec. 29, 1999

Dec. 29, 1999

--- Skip Montanaro <skip(a)mojam.com> wrote: > fast/memory-intensive/clear > slow/memory-conserving/not-as-clear > fast/memory-conserving/fairly-muddy > > Any particular reason that the readline method can't > return an iterator that > supports __getitem__ and buffers input? (Again, > remember this is for py2k, > so the potential breakage such a change might cause > is a consideration, but > not a showstopper.) Why not generalize fileinput … [View More]

2 1

Please test new dynamic load behavior
by Greg Stein Dec. 27, 1999

Dec. 27, 1999

Hi all, I reorganized Python's dynamic load/import code over the past few days. Gudio provided some feedback, I did some more mods, and now it is checked into CVS. The new loading behavior has been tested on Linux, IRIX, and Solaris (and probably Windows by now). For people with CVS access, I'd like to ask that you grab an updated copy and shake out the new code. There have been updates to the "configure" process, so you'll need to run configure again. Make sure that you alter your Modules/… [View More]

4 4

str(1L) -> '1' ?
by Jim Fulton Dec. 27, 1999

Dec. 27, 1999

In November there was an interesting discussion on comp.lang.python about the meaning of __str__ and __repr__. One tidbit that came out of this discussion was that __str__ for longs should drop the trailing 'L'. Was there a decision on this? I'd really like this to happen. We do alot of work with RDBMS systems and long integers seem to come up alot with these systems (as do other fix-decimal number, but that's another topic ;). For example, our latest Sybase and Oracle support in Zope … [View More]

5 7

Re: [Python-Dev] Fixed Decimal types
by Jack Jansen Dec. 27, 1999

Dec. 27, 1999

> (1) I think there is great mileage in combining the > fixed-decimal concept with Martin Fowler's Quantity > pattern, so that a variable could be defined as not > just two decimal places but also (say) "GBP" or "USD", > and it would be an error to add the two. Same applies > for adding metres, kilograms and other quantities. > There has also been discussion that the 'type' of a > quantity should determine what math should apply. Isn't this something that is ideally … [View More]

3 2

Re: [Python-Dev] Fixed Decimal types
by Andy Robinson Dec. 24, 1999

Dec. 24, 1999

> >> However, unlike RPG, we should probably ensure > >> that attempts to overflow or underflow the scale > >> result in NaN or Overflow conditions, rather > >> than assuming the user is right and losing > >> the significant digits. > > > Since this would be based on infinite-precision > numbers, I don't > > think that this would be an issue. Three very general observations before I disappear for Christmas: (1) I think there … [View More]

1 0

Re: [Python-checkins] CVS: python/dist/src/Lib getopt.py,1.7,1.8
by Fred L. Drake, Jr. Dec. 24, 1999

Dec. 24, 1999

Guido van Rossum writes: > + > + class GetoptError(Exception): > + opt = '' > + msg = '' > + def __init__(self, *args): > + self.args = args > + if len(args) == 1: > + self.msg = args[0] > + elif len(args) == 2: > + self.msg = args[0] > + self.opt = args[1] > + > + def __str__(self): > + return self.msg > > ! error = GetoptError # backward … [View More]

10 24

Re: [Python-Dev] Date and timetypes (was: Fixed-decimal types)
by Andy Robinson Dec. 24, 1999

Dec. 24, 1999

Sorry, should have replied to the list... --- Andy Robinson <captainrobbo(a)yahoo.com> wrote: > Date: Thu, 23 Dec 1999 08:37:18 -0800 (PST) > From: Andy Robinson <captainrobbo(a)yahoo.com> > Reply-to: andy(a)robanal.demon.co.uk > Subject: Re: [Python-Dev] Date and timetypes (was: > Fixed-decimal types) > To: Guido van Rossum <guido(a)CNRI.Reston.VA.US> > > --- Guido van Rossum <guido(a)CNRI.Reston.VA.US> > wrote: > > I don't know much … [View More]

3 2