🌐 Mailman 3 June 2002 - Python-list - python.org

Re: The email package and KLEZ mails
by Kragen Sitaker June 1, 2002

June 1, 2002

pinard(a)iro.umontreal.ca (François Pinard) writes: > For example, I expect compilers to raise diagnostics and help me at being > strict, because being overly liberal for a compiler is just not helpful. > Another example, a sad one, is the messy state of HTML all around us, > it comes from browsers having been by far too liberal, and for too long. If you had designed the early web browsers, the web never would have caught on, as indeed many other networked hypertext systems predating the Web did not; being liberal in what you accept is a crucial principle in building decentralized systems, and its embodiment in the Web made the Web possible. Having "bad HTML" warnings is, of course, extremely helpful. It makes it possible to be conservative in what you send.

1 0

Re: matching one time through a loop
by vvainio＠tp.spt.fi June 1, 2002

June 1, 2002

"David K. Trudgett" <dkt(a)registriesltd.com.au> wrote in message news:<mailman.1022806551.14232.python-list(a)python.org>... > with other factors like cleanness, readability, and so on. Obviously, > Python comes down on the cleanness/readability side, at the expense of > programmer productivity in text processing. I dunno about you, but I spend at least 8.4 seconds each time I think up & type a non-trivial regular expression. Compare that to the 1.3 seconds it takes to type re.search or re.sub (and I guess it takes you some time also to type those tildes, ='s and /'s. Hint: you do *not* have to compile the regexp beforehand. BTW, how does perl do re.findall()? Or re.sub using function return values to dynamically determine the replacement? I can't remember I ever used such features with perl. My experience is that Python regexps are better when you go beyond non-trivial, with clear group & matchobject semantics (and using return values instead of in-place replacement). Or target something apart from $_. Perl regexps were special back when others used old-style regexps, but those times are over - python provides perl-style regexps. > Don't know about that. I don't personally find that a problem. If I > had learned Python first, I might have had a different opinion, > perhaps ;-) I don't think it has much significance. Most people here probably learned perl first.

2 1

Re: matching one time through a loop
by Peter Hansen June 1, 2002

June 1, 2002

"David K. Trudgett" wrote: > > On Friday 2002-05-31 at 09:55:04 +1000, Delaney, Timothy wrote: > > > Seriously here ... by not having regular expressions be an integral part of > > the language, I believe they become much more understandable. It is always > > There might be something in that. However, having learned Perl before > Python, I just find it really clunky and slow to do regex stuff in > Python. I find that I miss the power that direct language syntax > support for regexes gives me. There's obviously a value judgement > there, of course: one needs to weigh up ease and speed of programming > with other factors like cleanness, readability, and so on. Obviously, > Python comes down on the cleanness/readability side, at the expense of > programmer productivity in text processing. I believe "programmer productivity" is significantly improved when using Python, especially because of the emphasis on readability. Productivity needs to include not just the time to type the statement, which is a miniscule portion of the overall effort, but also the time to revise the design repeatedly (assuming code-and-fix, which 95% of programmers use) or the time to write test cases, whether after (for 4% of programmers) or incrementally during (for those using Test-Driven Development). In all cases, code maintenance is a far greater proportion of the work than mere typing, and I really don't believe the minor time savings when typing provided by Perl

2 1

semi-concatenated strings
by Grant Griffin June 1, 2002

June 1, 2002

Hi Gang, I discovered today that strings can sometimes be concatenated without using a "+": ActivePython 2.2.1 Build 222 (ActiveState Corp.) based on Python 2.2.1 (#34, Apr 15 2002, 09:51:39) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> a = 'one' ' plus ' 'two' >>> a 'one plus two' I discovered this, of course, while making a mistake like this: >>> a = ['zero', 'one' ... 'two', 'three'] >>> a ['zero', 'onetwo', 'three'] (Note the missing comma after 'one'.) Is there some grand purpose here, or is this just a bug in the parser? errors-should-never-pass-silent-ly y'rs, =g2

8 8

Re: Generating unique numbers?
by Jiri Baum June 1, 2002

June 1, 2002

Jeff (jepler(a)unpythonic.net) wrote: > Yeah, but it was fun to try to ballpark the numbers. One thing I didn't > mention in my earlier message is that 2**65 unique IDs is right around > the number necessary to see birthday-paradox collisions in 128-bit hashes > such as MD5 with p=0.5. Still very uncommon for a 160-bit hash like SHA, > though. Personally, I'd be more comfortable with random numbers than with the IP/process-id/etc thing, because random numbers eliminate the human factor. As has been noted, lots of people use 10.0.0.1. *I* use 10.0.0.1. There are ethernet cards with the same ether addresses. Random numbers can at least be analyzed mathematically and relied-upon to obey the predictions. Jiri -- Jiri Baum <jiri(a)baum.com.au> http://www.csse.monash.edu.au/~jirib MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

1 0

Re: Why no open(f, "w").write()?
by John La Rooy June 1, 2002

June 1, 2002

On 30 May 2002 10:10:52 -0400 pinard(a)iro.umontreal.ca (François Pinard) wrote: > [Delaney, Timothy] > > > Why don't we have > > > while a = file.readline(): > > pass > > > while we're at it? After all, it's the same principle - you're trading > > off safety for saving a line or two. > > The Python language is oriented towards legibility and clarity, and I > would guess that the above has been rejected as lacking legibility, much > more than for safety considerations. > > Doing `lines = open(file).readlines()' looks perfectly safe to me, so I'm > not trading any safety. The goal of using such writing is not "saving a > line or two", but writing more legibly, by eliminating unnecessary noise. > Saving lines is not very important. Saving spurious lines is, however. > > All those things are quite debatable, there is some aesthetic considerations > associated with legibility; moreover, aesthetics do not alway yield to > legibility. I think Python is nice because it has _one_ artist in charge, > able to impose a common view. If it was "democratic", it would loose much. > > -- > François Pinard http://www.iro.umontreal.ca/~pinard > And certainly if something looks safe, ideally it should be so. Why do we close files at all ever? Explicitly closing a file *should* be as rare as explicitly deleting a variable. The reason we do it is because we *know* something about the underlying implementation i.e. that files are buffered. I hope that CPython is never going to change that behaviour of closing the file for me when refcount=0 and I think the Jython developers should consider a mechanism for doing it too. When refcount gets down to 0 and we make an object available for GC can't we ask is it a file? If so we better flush and close it? One of the reasons Python is quick to develop in is that we don't have to worry about memory management much (but we can if we need to). Likewise the less I have to deal with the fact that some I/O is buffered in my day to day work the better (as long as I can if I need to). John

1 0

Re: Python/Scripting language performance
by Curtis Jensen June 1, 2002

June 1, 2002

Skip Montanaro wrote: > Curtis> I'm looking for an explicit explination of why Scripting > Curtis> languages, specificaly Python, are slow compared to compiled > Curtis> languages. > > Languages like Python and Perl (I think you do both a disservice by calling > them "scripting" languages) are compiled to fairly high-level virtual > machines. The bytecode is then interpreted at run-time. Interpreting > bytecode is much less efficient than executing native machine code on real > hardware. Compiling dynamically types languages to efficient machine code > is difficult. C, C++ and Java are easier to compile to fairly efficient > machine code because they are statically typed. Dynamic typing means you > can't know ahead of time that (for example) the variable named "x" will > always be an int. C knows that "int x;" means that it can generate a very > efficient sequence of machine instructions to perform the expression "x + > 5". The Python compiler doesn't know what "x + 5" means because it doesn't > know, a priori, what the type of x is and thus what the semantics of the > addition operator are going to be. > > That's not the end of the story, however. Take a look at the Psyco project > for a system that provides some tantalizing performance improvements: > > http://sourceforge.net/projects/psyco > > I believe the Parrot project is also working on a more efficient virtual > machine for Perl (and eventually other languages). > Thanks for the responce. Though, I still have some questions. If Python and Perl are not scripting languages, then what are they? Also, is dynamic typing the only reason for python's performance hit? Does this mean that if I use something like Numeric arrays (from the Numeric Module), which pretty much staticaly types it's variables, and define these variables at the top of a function or in the constructor of a class, that I would avoid the performance hit of dynamic typing? Are there other performance penalties in Python other than dynamic typeing? What are they? I'm still lost on the point of the byte code. What's the point? If it's still line by line interpreted, why not just skip the byte code compilation and line by line interpret the source? Is there some optimization in the byte code? I looked at psyco. From the documentation it looks like it does code prediction; both on variable values and also on conditional branches. No matter what the language, better prediction will always yeild a performance speed up. Also, it looks as if psyco has a staticaly typed (32-bit) untyped typed. :) (one type for doubles ints, long ints, etc.). I assume this is an attempt to work around the dynamicaly typed variable performance hit. From this I am again left wondering if dynamic typing is the main reason for the performance hit. Ineficient pre-processing (byte code) would be the other main performance problem. Thanks for any further comments. -- Curtis Jensen cjensen(a)bioeng.ucsd.edu http://www-bioeng.ucsd.edu/~cjensen/ FAX (425) 740-1451

2 1

Re: Crashing IDLE
by Peter Hansen June 1, 2002

June 1, 2002

David LeBlanc wrote: > > Peter Hansen wrote: > > Instructions like HALT simply put the CPU into a state where > > *all* it does is sit and check for interrupts, and sometimes > > bump timer registers along. It is in suspended animation, > > not reading or writing memory or incrementing the program > > counter. > > "HALT" is often implemented as a "jump to self" in the chip's microcode. > This is a simple way of taking it through the microcode > sense/dispatch/process loop that is the basis of all macro ("regular") > instructions. I think you're right. Probably STOP is what I meant, which would be one step closer towards completely frozen than HALT. I may have the names wrong (and relatively few micros support something like STOP) but the idea is that there is an instruction that does not even execute that loop in microcode, so that the main clock can be stopped and power consumption lowered. This sort of thing is no doubt uncommon in generic CPUs used in PCs, but in embedded micros, and probably laptop CPUs, it's very important. > I really meant assembler as an analogy - Python's VM (interpreter if you > prefer) is quite analgous to a CPU with C as the microcode for the > underlying "simple" CPU. Too bad none of the user microcodable chips ever > made it into production/broadspread use. It would be interesting to create a > truly microcoded Python chip. Perhaps one of those 200,000 gate FPLA's.... > hmmmmmmm. I'm not expert, but the little time I've spent looking into the heart of the Python interpreter tells me it would be *much* more difficult to do that than with, say, the Java engine. Java has much lower level bytecode than does Python, and it's much less dynamic. It would be very cool to see though. And a blend of microcoded and non-microcoded routines could be effective. -Peter

2 1

Re: Generating unique numbers?
by Irmen de Jong June 1, 2002

June 1, 2002

> > Is there a good algorithm for generating unique numbers > > (ints, specifically) that can be used as object identifiers? > > id(x) If you need IDs that are unique across - different Python processes - different machines id(x) won't work. Irmen

3 4

file.readlines() question
by Ken June 1, 2002

June 1, 2002

Can someone give me example on how to use: file.readlines() with sizehint? (Say I want to find "guest434" from the list.) Thanks

2 1