Mailman 3 December 2000 - Python-Dev

PEP 208 and __coerce__
by Neil Schemenauer 24 Dec '00

24 Dec '00

While working on the implementation of PEP 208, I discovered that __coerce__ has some surprising properties. Initially I implemented __coerce__ so that the numberic operation currently being performed was called on the values returned by __coerce__. This caused test_class to blow up due to code like this: class Test: def __coerce__(self, other): return (self, other) The 2.0 "solves" this by not calling __coerce__ again if the objects returned by __coerce__ are instances. This has the effect of making code like: class A: def __coerce__(self, other): return B(), other class B: def __coerce__(self, other): return 1, other A() + 1 fail to work in the expected way. The question is: how should __coerce__ work? One option is to leave it work the way it does in 2.0. Alternatively, I could change it so that if coerce returns (self, *) then __coerce__ is not called again. Neil

3 2

[Patch #102813] _cursesmodule: Add panel support
by Andrew Kuchling 24 Dec '00

24 Dec '00

On Fri, Dec 22, 2000 at 07:07:03AM -0800, noreply(a)sourceforge.net wrote: > * Guido-style: 8-column hard-tab indents. > * New style: 4-column space-only indents. > * _curses style: 2 column indents. > >I'd prefer "New style", myself. New style it is. (Barry, is the "python" style in cc-mode.el going to be changed to new style, or a "python2" style added?) I've been wanting to reformat _cursesmodule.c to match the Python style for some time. Probably I'll do that a little while after the panel module has settled down a bit. Fred, did you look at the use of the CObject for exposing the API? Did that look reasonable? Also, should py_curses.h go in the Include/ subdirectory instead of Modules/? --amk

3 3

Re: [Patches] [Patch #102955] bltinmodule.c warning fix
by Andrew Kuchling 23 Dec '00

23 Dec '00

On Tue, Dec 19, 2000 at 07:02:05PM -0800, noreply(a)sourceforge.net wrote: >Date: 2000-Dec-19 19:02 >By: tim_one >Unrelated to your patch but in the same area: the other msg, "ord() >expected string or Unicode character", doesn't read right. The type >names in question are "string" and "unicode": > >>>> type("") ><type 'string'> >>>> type(u"") ><type 'unicode'> >>>> > >"character" is out of place, or not in enough places. Just thought I'd mention that, since *you're* so cute! Is it OK to refer to 8-bit strings under that name? How about "expected an 8-bit string or Unicode string", when the object passed to ord() isn't of the right type. Similarly, when the value is of the right type but has length>1, the message is "ord() expected a character, length-%d string found". Should that be "length-%d (string / unicode) found)" And should the type names be changed to '8-bit string'/'Unicode string', maybe? --amk

3 5

Reviving the bookstore
by A.M. Kuchling 23 Dec '00

23 Dec '00

Since the PSA isn't doing anything for us any longer, I've been working on reviving the bookstore at a new location with a new affiliate code. A draft version is up at its new home, http://www.kuchling.com/bookstore/ . Please take a look and offer comments. Book authors, please take a look at the entry for your book and let me know about any corrections. Links to reviews of books would also be really welcomed. I'd like to abolish having book listings with no description or review, so if you notice a book that you've read has no description, please feel free to submit a description and/or review. --amk

1 0

PEP 222 draft
by A.M. Kuchling 23 Dec '00

23 Dec '00

I've completed a draft of PEP 222 (sort of -- note the XXX comments in the text for things that still need to be resolved). This is being posted to python-dev, python-web-modules, and python-list/comp.lang.python, to get comments on the proposed interface. I'm on all three lists, but would prefer to see followups on python-list/comp.lang.python, so if you can reply there, please do so. --amk Abstract This PEP proposes a set of enhancements to the CGI development facilities in the Python standard library. Enhancements might be new features, new modules for tasks such as cookie support, or removal of obsolete code. The intent is to incorporate the proposals emerging from this document into Python 2.1, due to be released in the first half of 2001. Open Issues This section lists changes that have been suggested, but about which no firm decision has yet been made. In the final version of this PEP, this section should be empty, as all the changes should be classified as accepted or rejected. cgi.py: We should not be told to create our own subclass just so we can handle file uploads. As a practical matter, I have yet to find the time to do this right, so I end up reading cgi.py's temp file into, at best, another file. Some of our legacy code actually reads it into a second temp file, then into a final destination! And even if we did, that would mean creating yet another object with its __init__ call and associated overhead. cgi.py: Currently, query data with no `=' are ignored. Even if keep_blank_values is set, queries like `...?value=&...' are returned with blank values but queries like `...?value&...' are completely lost. It would be great if such data were made available through the FieldStorage interface, either as entries with None as values, or in a separate list. Utility function: build a query string from a list of 2-tuples Dictionary-related utility classes: NoKeyErrors (returns an empty string, never a KeyError), PartialStringSubstitution (returns the original key string, never a KeyError) New Modules This section lists details about entire new packages or modules that should be added to the Python standard library. * fcgi.py : A new module adding support for the FastCGI protocol. Robin Dunn's code needs to be ported to Windows, though. Major Changes to Existing Modules This section lists details of major changes to existing modules, whether in implementation or in interface. The changes in this section therefore carry greater degrees of risk, either in introducing bugs or a backward incompatibility. The cgi.py module would be deprecated. (XXX A new module or package name hasn't been chosen yet: 'web'? 'cgilib'?) Minor Changes to Existing Modules This section lists details of minor changes to existing modules. These changes should have relatively small implementations, and have little risk of introducing incompatibilities with previous versions. Rejected Changes The changes listed in this section were proposed for Python 2.1, but were rejected as unsuitable. For each rejected change, a rationale is given describing why the change was deemed inappropriate. * An HTML generation module is not part of this PEP. Several such modules exist, ranging from HTMLgen's purely programming interface to ASP-inspired simple templating to DTML's complex templating. There's no indication of which templating module to enshrine in the standard library, and that probably means that no module should be so chosen. * cgi.py: Allowing a combination of query data and POST data. This doesn't seem to be standard at all, and therefore is dubious practice. Proposed Interface XXX open issues: naming convention (studlycaps or underline-separated?); need to look at the cgi.parse*() functions and see if they can be simplified, too. Parsing functions: carry over most of the parse* functions from cgi.py # The Response class borrows most of its methods from Zope's # HTTPResponse class. class Response: """ Attributes: status: HTTP status code to return headers: dictionary of response headers body: string containing the body of the HTTP response """ def __init__(self, status=200, headers={}, body=""): pass def setStatus(self, status, reason=None): "Set the numeric HTTP response code" pass def setHeader(self, name, value): "Set an HTTP header" pass def setBody(self, body): "Set the body of the response" pass def setCookie(self, name, value, path = '/', comment = None, domain = None, max-age = None, expires = None, secure = 0 ): "Set a cookie" pass def expireCookie(self, name): "Remove a cookie from the user" pass def redirect(self, url): "Redirect the browser to another URL" pass def __str__(self): "Convert entire response to a string" pass def dump(self): "Return a string representation useful for debugging" pass # XXX methods for specific classes of error:serverError, badRequest, etc.? class Request: """ Attributes: XXX should these be dictionaries, or dictionary-like objects? .headers : dictionary containing HTTP headers .cookies : dictionary of cookies .fields : data from the form .env : environment dictionary """ def __init__(self, environ=os.environ, stdin=sys.stdin, keep_blank_values=1, strict_parsing=0): """Initialize the request object, using the provided environment and standard input.""" pass # Should people just use the dictionaries directly? def getHeader(self, name, default=None): pass def getCookie(self, name, default=None): pass def getField(self, name, default=None): "Return field's value as a string (even if it's an uploaded file)" pass def getUploadedFile(self, name): """Returns a file object that can be read to obtain the contents of an uploaded file. XXX should this report an error if the field isn't actually an uploaded file? Or should it wrap a StringIO around simple fields for consistency? """ def getURL(self, n=0, query_string=0): """Return the URL of the current request, chopping off 'n' path components from the right. Eg. if the URL is "http://foo.com/bar/baz/quux", n=2 would return "http://foo.com/bar". Does not include the query string (if any) """ def getBaseURL(self, n=0): """Return the base URL of the current request, adding 'n' path components to the end to recreate more of the whole URL. Eg. if the request URL is "http://foo.com/q/bar/baz/qux", n=0 would return "http://foo.com/", and n=2 "http://foo.com/q/bar". Returned URL does not include the query string, if any. """ def dump(self): "String representation suitable for debugging output" pass # Possibilities? I don't know if these are worth doing in the # basic objects. def getBrowser(self): "Returns Mozilla/IE/Lynx/Opera/whatever" def isSecure(self): "Return true if this is an SSLified request" # Module-level function def wrapper(func, logfile=sys.stderr): """ Calls the function 'func', passing it the arguments (request, response, logfile). Exceptions are trapped and sent to the file 'logfile'. """ # This wrapper will detect if it's being called from the command-line, # and if so, it will run in a debugging mode; name=value pairs # can be entered on standard input to set field values. # (XXX how to do file uploads in this syntax?) Copyright This document has been placed in the public domain.

1 0

Re: [Python-Dev] PEP-0218
by Moshe Zadka 21 Dec '00

21 Dec '00

> BTW, one lesson to take from SETL: a vital set operation in practice is a > mutating "pick a 'random' element E from the set, remove it from the set, > and return it". An enormous number of set algorithms are of the form > > while not S.empty(): > pick some element from S > deal with it, possibly mutating S > > This operation can't be done efficiently in Python code if the set is > represented by a dict (the best you can do is materialize the full list of > keys first, and pick one of those). That means my Set class often takes > quadratic time for what *should* be linear-time algorithms. Hmmm...actually, I've been wanting a method .key() for dictionaries a long time. So if we give dictionaries this one small method, then we *can* do this in Python. -- Moshe Zadka <sig(a)zadka.site.co.il> This is a signature anti-virus. Please stop the spread of signature viruses!

16 41

Death to string functions!
by Martin v. Loewis 21 Dec '00

21 Dec '00

> I agree it would be useful to define these terms, although those > particular definitions appear to be missing the most important point > from the user's POV (not a one says "going away someday"). PEP 4 says # Usage of a module may be `deprecated', which means that it may be # removed from a future Python release. Proposals for better wording are welcome (and yes, I still have to get the comments that I got into the document). Regards, Martin

7 6

scp with SourceForge
by Fred L. Drake, Jr. 21 Dec '00

21 Dec '00

I've not been able to get scp to work with SourceForge since they upgraded their machines. ssh works fine. Is this related to the protocol mismatch problem that was discussed earlier? My ssh tells me "SSH Version OpenSSH-1.2.2, protocol version 1.5.", and the remote sshd is sending it's version as "Remote protocol version 1.99, remote software version OpenSSH_2.2.0p1". Was there a reasonable way to deal with this? I'm running Linux-Mandrake 7.1 with very little customization or extra stuff. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations

5 9

IGNORE - this is only a test
by barry＠digicool.com 20 Dec '00

20 Dec '00

Testing the new MX for python.org...

1 0

Re: [Python-Dev] Death to string functions!
by Just van Rossum 20 Dec '00

20 Dec '00

Barry wrote: >Actually, it has been debated to death. ;) This looks better: > > SPACE = ' ' > SPACE.join(aList) > >That reads good to me ("space-join this list") and that's how I always >write it. I just did a quick scan through the 1.5.2 library, and _most_ occurrances of string.join() are used with a string constant for the second argument. There is a whole bunch of one-arg string.join()'s, too. Recommending replacing all of these (not to mention all the code "out there") with named constants seems plain silly. Sure, " ".join() is the most "logical" choice for Python as it stands, but it's definitely not the most intuitive, as evidenced by the number of times this comes up on c.l.py: to many people it simply "looks wrong". Maybe this is the deal: joiner.join() makes a whole lot of sense from an _implementation_ standpoint, but a whole lot less as a public interface. It's easy to explain why join() can't be a method of sequences (in Python), but that alone doesn't justify a string method. string.join() is not quite unlike map() and friends: map() wouldn't be so bad as a sequence method, but that isn't practical for exactly the same reasons: so it's a builtin. (And not a function method...) So, making join() a builtin makes a whole lot of sense. Not doing this because people sometimes use a local reference to os.path.join seems awfully backward. Hm, maybe joiner.join() could become a special method: joiner.__join__(), that way other objects could define their own implementation for join(). (Hm, wouldn't be the worst thing for, say, a file path object...) Just

4 6