Mailman 3 December 2003 - Python-Dev

Re: [Python-Dev] Re: "groupby" iterator
by Samuele Pedroni Dec. 3, 2003

Dec. 3, 2003

At 07:00 03.12.2003 -0800, Guido van Rossum wrote: > > The old lambda would have to be kept around for a while for programs > > relying on the old semantics, but it could be deprecated, and > > removed in 3.0. > >I'm not sure that the -> notation is more understandable than lambda; >it would surely confuse C/C++ programmers who are new to Python. > >Scary thought: how about simply introducing early-binding semantics >for lambda in 3.0? that would confuse … [View More]

2 1

"groupby" iterator
by Greg Ball Dec. 3, 2003

Dec. 3, 2003

Here's a reworking which returns iterators. I had to decide what to do if the user tries to access things out of order; I raise an exception. Anything else would complicate the code quite a lot I think. def groupby(key, iterable): it = iter(iterable) value = it.next() # If there are no items, this takes an early exit oldkey = [key(value)] cache = [value] lock = [] def grouper(): yield cache.pop() for value in it: newkey = key(value) … [View More]

12 28

RE: [Python-Dev] Tutorial: Brief Introduction to the Standard Libary
by Edward Loper Dec. 3, 2003

Dec. 3, 2003

> Attached is a revised draft. Comments, suggestions, nitpicks, > complaints, and accolades are welcome. General comments: - Overall, it looks very good. :) - Since your descriptions are so brief, you should probably provide links to the reference documentation for each module/function that you reference. - You might also want to mention pydoc. Not only is it a very useful module for beginners in its own right, but it would give them a way to learn more … [View More]about the other modules that you describe. > >>>import os > >>>os.system('copy /data/mydata.fil /backup/mydata.fil') > 0 > > >>>os.getcwd() > 'C:\\Python24' > > >>>os.chdir('/server/accesslogs') You might want to add short "#" comments for these, saying what they do. (Some novices won't recognize what system() is doing; and not everyone immediately associates cwd with current working directory.) Nothing fancy, just something like: >>> os.getcwd() # Return the current working directory > Be sure to use the "import os" style instead of "from os import *". > This will keep os.open() from shadowing __builtin__.open() which > operates much differently. This sentence would be more accessible to beginners if you said "from shadowing the builtin open() function, which operates much differently." >>>>optlist, args = getopt.getopt(sys.argv[1:], 'abc:d:') It might be worth including an option that doesn't get used, just to show that they're optional. > because they are easier to read and debug. For more sophisticated applications, I would replace s/For/But for/ > >>>import urllib That should be "import urllib2" > For example, it may be tempting to use the tuple packing and unpacking feature > instead of the traditional approach to swapping arguments. The timeit module > quickly demonstrates that the traditional approach is faster: I think that you should add a caveat here. Something along the lines of "But the tuple method is much easier to read, and not much faster, so unless it's in a really tight loop where speed is critical, you should use the tuple method." > In contrast to timeit's fine level of granularity, the profile and pstats modules > provide tools for identifying time critical sections of larger blocks of code. I think it's worth noting that profile & pstats are generally much more useful for optimizing code than timeit is. (That fact might not be obvious to beginners.) > Batteries Included > > Python has a "batteries included" philosophy. The is best seen through the > sophisticated and robust capabilites of its larger packages: s/packages:/packages, including:/ Also, I'm not sure if the meaning of "batteries included" will be obvious to people who haven't seen the term before. Perhaps you could steal some text from PEP 206; so something like: Python has a "batteries included" philosophy -- it includes a rich and versatile standard library which is immediately available, without making the user download separate packages. The is best seen through the sophisticated and robust capabilites of its larger packages, including: -Edward [View Less]

1 0

Python suggestions mostly from C99
by Edward C. Jones Dec. 3, 2003

Dec. 3, 2003

Here are a few suggestions for Python: Extend hex() and %x to work on longs, floats, and strings. Add the C99 %a and %A formats. Add a module that wraps the C99 macros and functions that work with special floating point values and floating point exceptions. Since most C compilers are not C99 compliant, some of these ideas might need to be written in C rather than just wrapped.

2 1

Re: [Python-Dev] Re: "groupby" iterator
by Phillip J. Eby Dec. 3, 2003

Dec. 3, 2003

At 07:00 AM 12/3/03 -0800, Guido van Rossum wrote: >It is also somewhat weak in that it only addresses lambdas with one >argument, and only allows a single reference to that argument in the >resulting expression, and can't really be made to handle method calls >without more gross notational hacks -- even though it *can* be made to >handle arbitrary binary and unary operators. > >Yet, it captures 90% of the use cases quite well. I also wonder if >the simple trick of … [View More]

1 0

Re: [Python-Dev] Re: "groupby" iterator
by Phillip J. Eby Dec. 3, 2003

Dec. 3, 2003

At 11:18 AM 12/3/03 -0500, Greg Ball wrote: >Would it work to generalise generator expressions in the following way: > >(x[1] for x) == lambda x:x[1] >(x.score for x) == lambda x: x.score >(x+y for x,y) == lambda x,y: x+y >(len(x) for x) == lambda x,len=len: len(x) # roughly equivalent -1. It looks like a generator expression, but the semantics are way too different. Unless you intended that it should be invoked with .next() rather than __call__, but then there's no way … [View More]

1 0

unittest output
by Raymond Hettinger Dec. 3, 2003

Dec. 3, 2003

When a test fails, it is accompanied by tracebacks that include all the processing within the unittest module itself. This makes it darned difficult to see at a glance what went wrong. If like me, you use unittest as part of the development process, then you run it hundreds of times each week and this eyesore gets to be a real PITA. I don't recall when or where, but someone has proposed a fix. But, like many great ideas, it got stymied because someone, somewhere has a use for the rest of the … [View More]

4 6

Re: [Python-Dev] "groupby" iterator
by Phillip J. Eby Dec. 3, 2003

Dec. 3, 2003

At 04:18 PM 11/30/03 -0800, Guido van Rossum wrote: > > How about: > > > > extract(attr='grade') > > extract(item=2) > > extract(method='foo') # returns the result of calling 'ob.foo()' > > > > And following the pattern of Zope's old "query" package: > > > > extract(extract(attr='foo'), attr='bar') # extracts ob.foo.bar > > extract(extract(item=10), method='spam') # extracts ob[10].spam() > > > > i.e., the first (… [View More]

9 16

Tutorial: Brief Introduction to the Standard Libary
by Raymond Hettinger Dec. 3, 2003

Dec. 3, 2003

I'm adding section to the tutorial with a brief sampling of library offerings and some short examples of how to use them. My first draft included: copy, glob, shelve, pickle, os, re, math/cmath, urllib, smtplib Guido's thoughts: - copy tends to be overused by beginners - the shelve module has pitfalls for new users - cmath is rarely needed and some folks are scared of complex numbers - urllib2 is be a better choice than urllib I'm interested to know what your experiences have been with … [View More]teaching python. Which modules are necessary to start doing real work (like pickle and os), which are most easily grasped (like glob or random), which have impressive examples only a few lines long (i.e. urllib), and which might just be fun (turtle would be a candidate if it didn't have a Tk dependency). Note, re was included because everyone should know it's there and everyone should get advice to not use it when string methods will suffice. I'm especially interested in thoughts on whether shelve should be included. When I first started out, I was very impressed with shelves because they were the simplest way to add a form of persistence and because they could be dropped in place of a dictionary in scripts that were already built. Also, it was trivially easy to learn based on existing knowledge of dictionaries. OTOH, that existing knowledge is what makes the pitfalls so surprising. Likewise, I was impressed with the substitutability of line lists, text splits, file.readlines(), and urlopen(). While I think of copy() and deepcopy() as builtins that got tucked away in module, Guido is right about their rarity in well-crafted code. Some other candidates (let's pick just a two or three): - csv (basic tool for sharing data with other applications) - datetime (comes up frequently in real apps and admin tasks) - ftplib (because the examples are so brief) - getopt or optparse (because the task is common) - operator (because otherwise, the functionals can be a PITA) - pprint (because beauty counts) - struct (because fixed record layouts are common) - threading/Queue (because without direction people grab thread and mutexes) - timeit (because it answers most performance questions in a jiffy) - unittest (because TDD folks like myself live by it) I've avoided XML because it is a can of worms and because short examples don't do it justice. OTOH, it *is* the hot topic of the day and seems to be taking over the world one angle bracket at a time. Ideally, the new section should be relatively short but leave a reader with a reasonable foundation for crafting non-toy scripts. A secondary goal is to show-off the included batteries -- I think it is common for someone to download several languages and choose between them based on their tutorial experiences (so, a little flash and sizzle might be warranted). Raymond [View Less]

9 9

Tutorial: Brief Introduction to the Standard Libary
by Arthur Dec. 3, 2003

Dec. 3, 2003

No mention of the copy module. Is this open for discussion? Raymond had written: >My first draft included: > copy, glob, shelve, pickle, os, re, math/cmath, urllib, smtplib >Guido's thoughts: >- copy tends to be overused by beginners While Guido offers no evidence, I have no evidence to dispute him. Let's accept it as true. [Snip] >While I think of copy() and deepcopy() as builtins that got tucked away >in module, Guido is right about their rarity in well-crafted … [View More]

2 1