Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
> It still looks like an application of WSGI, not part of a reference > implementation. It seems to me that canonical exemplars are part of what a "reference" implementation should include. Otherwise it would be a "standard" implementation, which is considerably different. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
> Perhaps this could go in Demo/wsgiref/? Perhaps both Ian's and Phillip's examples could go into Demo/wsgiref/? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 open issues
Collin Winter wrote: > I'd very much like to see functional renamed to functools, and I've > cooked up the necessary changes to handle the move (SF #1478788). +1 since there are utilities like "decorator" and "deprecated" which belong in such a module, but don't fit within the "functional programming" meme suggested by the current name. If we're happy with the name change, I can make sure this change goes in before alpha 3 (probably sooner, to make it easier for anyone interested to work on a patch for @decorator). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45770 - in python/trunk:
On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote: > - Warn-raise ImportWarning when importing would have picked up a directory >as package, if only it'd had an __init__.py. This swaps two tests (for >case-ness and __init__-ness), but case-test is not really more expensive, >and it's not in a speed-critical section. For the what's new, I'd like to clarify the purpose of this change. Is the plan to make __init__.py optional in subpackages in 2.6, and this warning is a first step toward that? Or is this just to improve the error reporting when a directory lacking an __init__.py is found, and no further changes will be in 2.6? --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Crazy idea for str.join
I understand the underlying implementation of str.join can be a bit convoluted (with the auto-promotion to unicode and all), but I don't suppose there is any chance to get str.join to support objects which implement the buffer interface as one of the items in the sequence? Something like: y = 'hello world' buf1 = buffer(y, 0, 5) buf2 = buffer(y, 6) print ''.join([buf1, buf2]) should print "helloworld" It would take a PyBuffer_Check() just after the PyUnicode_Check() block. And one may be able to replace the other PyString_* calls with PyObject_AsCharBuffer() calls. I'm not going to push for this, but someone other than me may find such functionality useful. - Josiah P.S. One interesting thing to note is that quite a few underlying objects take buffer objects in lieu of strings, even when they aren't documented as doing so; file.write(), array.fromstring(), mmap[i:j] = buffer, etc. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 open issues
Neal Norwitz wrote: > Here's what's left for 2.5 after the most recent go around. > > There's no owner for these items. If no one takes them, they won't > get done and I will move them to deferred within a week: > > * Add @decorator decorator to functional, rename to functools? > What's the benefit of @decorator? Creating decorators that don't hinder introspection. > Who made functional? It's new > in 2.5, right? If so, move it or it will be functional for all 2.x. > > * Remove the fpectl module? >Does anyone use this? It can probably be removed, but someone > needs to do the work. > > * new icons is lost and needs a shepherd to make python look spiffy I've already done the work for Unixy platforms. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45770 - in python/trunk:
A.M. Kuchling wrote: > On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote: >> - Warn-raise ImportWarning when importing would have picked up a directory >>as package, if only it'd had an __init__.py. This swaps two tests (for >>case-ness and __init__-ness), but case-test is not really more expensive, >>and it's not in a speed-critical section. > > For the what's new, I'd like to clarify the purpose of this change. > Is the plan to make __init__.py optional in subpackages in 2.6, and > this warning is a first step toward that? Or is this just to improve > the error reporting when a directory lacking an __init__.py is found, > and no further changes will be in 2.6? From what I have read out of the quite lengthy thread on this topic, there's no decision yet. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45770 - in python/trunk:
A.M. Kuchling wrote: > On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote: >> - Warn-raise ImportWarning when importing would have picked up a directory >>as package, if only it'd had an __init__.py. This swaps two tests (for >>case-ness and __init__-ness), but case-test is not really more expensive, >>and it's not in a speed-critical section. > > For the what's new, I'd like to clarify the purpose of this change. > Is the plan to make __init__.py optional in subpackages in 2.6, and > this warning is a first step toward that? Or is this just to improve > the error reporting when a directory lacking an __init__.py is found, > and no further changes will be in 2.6? I think it's hard to say because that thread moved so fast :) FWIW, my interpretation was that there was some degree of consensus that better error reporting for this situation was a good thing, but Guido still has a bit of persuading to do if he wants to make an empty __init__.py optional in subpackages for Python 2.6. So the relatively non-controversial bit (improving the error reporting) was added immediately, and the controversial bit postponed to see if the better error reporting had any effect on the demand for it. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Josiah Carlson wrote: > [...] get str.join to support objects which > implement the buffer interface as one of the items in the sequence? > > Something like: > > y = 'hello world' > buf1 = buffer(y, 0, 5) > buf2 = buffer(y, 6) > print ''.join([buf1, buf2]) > > should print "helloworld" This is incompatible with the recent proposal making str.join automatically str-ify its arguments. i.e.: ''.join(['a', 12, 'b']) -> 'a12b'. I don't feel strongly about either proposal, I just thought I'd point out that they're mutually exclusive. -Edward ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Edward Loper wrote: > This is incompatible with the recent proposal making str.join > automatically str-ify its arguments. i.e.: > >''.join(['a', 12, 'b']) -> 'a12b'. > > I don't feel strongly about either proposal, I just thought I'd point > out that they're mutually exclusive. Doesn't accepting objects that support the buffer interface come for free with stringification? (My understanding of buffer objects is fairly sketchy, so I may be missing something here. . .) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Nick Coghlan wrote: > Edward Loper wrote: >> This is incompatible with the recent proposal making str.join >> automatically str-ify its arguments. i.e.: >> >>''.join(['a', 12, 'b']) -> 'a12b'. >> >> I don't feel strongly about either proposal, I just thought I'd point >> out that they're mutually exclusive. > > Doesn't accepting objects that support the buffer interface come for > free with stringification? (My understanding of buffer objects is fairly > sketchy, so I may be missing something here. . .) It's quite possible that I'm the one who was confused.. I just tried it out with string-based buffers, and for that case at least it works fine. I don't know about other buffers. So actually these two proposals might be compatible after all. -Edward ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] introducing the experimental pyref wiki
the pytut wiki (http://pytut.infogami.com/) has now been up and running for one month, and has seen well over 250 edits from over a dozen contributors. to celebrate this, and to exercise the toolchain that I've deve- loped for pytut and pyfaq (http://pyfaq.infogami.com/), I spent a few hours putting together a hyperlinked mashup of the language reference and portions of the library reference: http://pyref.infogami.com/ a couple of notes: - all important "concepts" have unique URLs: this includes key- words, types, special methods and attributes, statements, builtin functions, and exceptions. - the conversion and structure is a bit rough; especially the syntax/data model/execution model parts needs some serious refactoring. the "concept pages" are in a lot better shape. - registered users can add comments to all pages (editing is currently "by invitation only"; mail me your infogami account if you want to help!) - the documentation style used at the pyref site is tuned for authoring; an "end-user rendering" for python.org can look a lot different. (all three sites can be made available in glorious XHTML for inclusion in arbitrary toolchains). enjoy! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Edward Loper <[EMAIL PROTECTED]> wrote: > > Nick Coghlan wrote: > > Edward Loper wrote: > >> This is incompatible with the recent proposal making str.join > >> automatically str-ify its arguments. i.e.: > >> > >>''.join(['a', 12, 'b']) -> 'a12b'. > >> > >> I don't feel strongly about either proposal, I just thought I'd point > >> out that they're mutually exclusive. > > > > Doesn't accepting objects that support the buffer interface come for > > free with stringification? (My understanding of buffer objects is fairly > > sketchy, so I may be missing something here. . .) > > It's quite possible that I'm the one who was confused.. I just tried it > out with string-based buffers, and for that case at least it works fine. > I don't know about other buffers. So actually these two proposals > might be compatible after all. The point of my proposal was to prevent an unnecessary level of copying during a str.join . Right now, if one manually uses str(buf) (or indexing or slicing), it copies the contents of the buffer into a string (likely via PyString_FromStringAndSize() ). By using PyObject_AsCharBuffer(), and using memcpy on that pointer rather than the pointer returned by PyString_AsString() from any (possibly auto-stringified) strings, it would reduce memory copies by half for those non-string buffer-supporting arguments. At least for the examples of buffers that I've seen, using the buffer interface for objects that support it is equivalent to automatically applying str() to them. This is, strictly speaking, an optimization. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Josiah Carlson wrote:
> At least for the examples of buffers that I've seen, using the buffer
> interface for objects that support it is equivalent to automatically
> applying str() to them. This is, strictly speaking, an optimization.
>>> a = array.array("i", [1, 2, 3])
>>> str(a)
"array('i', [1, 2, 3])"
>>> str(buffer(a))
'\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45770 - in python/trunk:
On 4/29/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: So the relatively non-controversial bit (improving the error reporting) wasadded immediately, and the controversial bit postponed to see if the bettererror reporting had any effect on the demand for it. This is exactly how I intended it, and I believe that's Guido's desire, too. Otherwise, he would've asked me to make the warning a FutureWarning, instead. (Which could of course still happen.) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Fredrik Lundh wrote:
> Josiah Carlson wrote:
>
>> At least for the examples of buffers that I've seen, using the buffer
>> interface for objects that support it is equivalent to automatically
>> applying str() to them. This is, strictly speaking, an optimization.
>
> >>> a = array.array("i", [1, 2, 3])
> >>> str(a)
> "array('i', [1, 2, 3])"
> >>> str(buffer(a))
> '\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'
or:
[EMAIL PROTECTED]:~$ python2.4
Python 2.4.2 (#2, Sep 30 2005, 22:19:27)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> str(buffer(u"abc"))
'a\x00\x00\x00b\x00\x00\x00c\x00\x00\x00'
>>>
Thomas
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.
Hi all, Mateusz Rukowicz wrote: > I wish to participate in Google Summer of Code as a python developer. I > have few ideas, what would be improved and added to python. Since these > changes and add-ons would be codded in C, and added to python-core > and/or as modules,I am not sure, if you are willing to agree with these > ideas. > > First of all, I think, it would be good idea to speed up long int > implementation in python. Especially multiplying and converting > radix-2^k to radix-10^l. It might be done, using much faster algorithms > than already used, and transparently improve efficiency of multiplying > and printing/reading big integers. > > Next thing I would add is multi precision floating point type to the > core and fraction type, which in some cases highly improves operations, > which would have to be done using floating point instead. > Of course, math module will need update to support multi precision > floating points, and with that, one could compute asin or any other > function provided with math with precision limited by memory and time. > It would be also good idea to add function which computes pi and exp > with unlimited precision. > And last thing - It would be nice to add some number-theory functions to > math module (or new one), like prime-tests, factorizations etc. Sorry for pitching in late, I was away for a while. I'd just like to point out in the context of this discussion: http://sage.scipy.org/sage/ SAGE is a fairly comprehensive system built on top of python to do all sorts of research-level number theory work, from basic things up to unpronouncable ones. It includes wrappers to many of the major number-theory related libraries which exist with an open-source license. I am not commenting one way or another on your proposal, just bringing up a project with a lot of relevance to what you are talking about. Cheers, f ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Thomas Heller <[EMAIL PROTECTED]> wrote:
>
> Fredrik Lundh wrote:
> > Josiah Carlson wrote:
> >
> >> At least for the examples of buffers that I've seen, using the buffer
> >> interface for objects that support it is equivalent to automatically
> >> applying str() to them. This is, strictly speaking, an optimization.
> >
> > >>> a = array.array("i", [1, 2, 3])
> > >>> str(a)
> > "array('i', [1, 2, 3])"
> > >>> str(buffer(a))
> > '\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'
>
> or:
>
> [EMAIL PROTECTED]:~$ python2.4
> Python 2.4.2 (#2, Sep 30 2005, 22:19:27)
> [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> str(buffer(u"abc"))
> 'a\x00\x00\x00b\x00\x00\x00c\x00\x00\x00'
> >>>
Hrm, those are interesting examples. It would seem as though checking
to see if a passed object was a buffer itself, rather than whether it
supported the buffer interface, would be more correct.
- Josiah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3102: Keyword-only arguments
PEP: 3102
Title: Keyword-Only Arguments
Version: $Revision$
Last-Modified: $Date$
Author: Talin
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 22-Apr-2006
Python-Version: 3.0
Post-History:
Abstract
This PEP proposes a change to the way that function arguments are
assigned to named parameter slots. In particular, it enables the
declaration of "keyword-only" arguments: arguments that can only
be supplied by keyword and which will never be automatically
filled in by a positional argument.
Rationale
The current Python function-calling paradigm allows arguments to
be specified either by position or by keyword. An argument can be
filled in either explicitly by name, or implicitly by position.
There are often cases where it is desirable for a function to take
a variable number of arguments. The Python language supports this
using the 'varargs' syntax ('*name'), which specifies that any
'left over' arguments be passed into the varargs parameter as a
tuple.
One limitation on this is that currently, all of the regular
argument slots must be filled before the vararg slot can be.
This is not always desirable. One can easily envision a function
which takes a variable number of arguments, but also takes one
or more 'options' in the form of keyword arguments. Currently,
the only way to do this is to define both a varargs argument,
and a 'keywords' argument (**kwargs), and then manually extract
the desired keywords from the dictionary.
Specification
Syntactically, the proposed changes are fairly simple. The first
change is to allow regular arguments to appear after a varargs
argument:
def sortwords(*wordlist, case_sensitive=False):
...
This function accepts any number of positional arguments, and it
also accepts a keyword option called 'case_sensitive'. This
option will never be filled in by a positional argument, but
must be explicitly specified by name.
Keyword-only arguments are not required to have a default value.
Since Python requires that all arguments be bound to a value,
and since the only way to bind a value to a keyword-only argument
is via keyword, such arguments are therefore 'required keyword'
arguments. Such arguments must be supplied by the caller, and
they must be supplied via keyword.
The second syntactical change is to allow the argument name to
be omitted for a varargs argument:
def compare(a, b, *, key=None):
...
The reasoning behind this change is as follows. Imagine for a
moment a function which takes several positional arguments, as
well as a keyword argument:
def compare(a, b, key=None):
...
Now, suppose you wanted to have 'key' be a keyword-only argument.
Under the above syntax, you could accomplish this by adding a
varargs argument immediately before the keyword argument:
def compare(a, b, *ignore, key=None):
...
Unfortunately, the 'ignore' argument will also suck up any
erroneous positional arguments that may have been supplied by the
caller. Given that we'd prefer any unwanted arguments to raise an
error, we could do this:
def compare(a, b, *ignore, key=None):
if ignore: # If ignore is not empty
raise TypeError
As a convenient shortcut, we can simply omit the 'ignore' name,
meaning 'don't allow any positional arguments beyond this point'.
Function Calling Behavior
The previous section describes the difference between the old
behavior and the new. However, it is also useful to have a
description of the new behavior that stands by itself, without
reference to the previous model. So this next section will
attempt to provide such a description.
When a function is called, the input arguments are assigned to
formal parameters as follows:
- For each formal parameter, there is a slot which will be used
to contain the value of the argument assigned to that
parameter.
- Slots which have had values assigned to them are marked as
'filled'. Slots which have no value assigned to them yet are
considered 'empty'.
- Initially, all slots are marked as empty.
- Positional arguments are assigned first, followed by keyword
arguments.
- For each positional argument:
o Attempt to bind the argument to the first unfilled
parameter slot. If the slot is not a vararg slot, then
mark the slot as 'filled'.
o If the next unfilled slot is a vararg slot, and it does
not have a name, then it is an error.
o Otherwise, if the next unfilled slot is a vararg slot then
all remaining non-keyword arguments are placed
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On 4/29/06, Talin <[EMAIL PROTECTED]> wrote: > PEP: 3102 > Title: Keyword-Only Arguments > Version: $Revision$ > Last-Modified: $Date$ > Author: Talin > Status: Draft > Type: Standards > Content-Type: text/plain > Created: 22-Apr-2006 > Python-Version: 3.0 > Post-History: > > > Abstract > > This PEP proposes a change to the way that function arguments are > assigned to named parameter slots. In particular, it enables the > declaration of "keyword-only" arguments: arguments that can only > be supplied by keyword and which will never be automatically > filled in by a positional argument. +1. And I suggest this be re-targeted for Python 2.6. Now all we need is someone to implement this. ;-) By the way, I thought the "Function Calling Behavior" section was particularly clear. Thanks for that! STeVe -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
On 4/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > I understand the underlying implementation of str.join can be a bit > convoluted (with the auto-promotion to unicode and all), but I don't > suppose there is any chance to get str.join to support objects which > implement the buffer interface as one of the items in the sequence? In Py3k, buffers won't be compatible with strings -- buffers will be about bytes, while strings will be about characters. Given that future I don't think we should mess with the semantics in 2.x; one change in the near(ish) future is enough of a transition. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45770 - in python/trunk:
Actually after all the -1 responses I wasn't going to reconsider this for 2.x; maybe for py3k. Most of the -1 votes were unconditional; only a few respondents thought that I was proposing it for 2.5. --Guido On 4/29/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > On 4/29/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > So the relatively non-controversial bit (improving the error reporting) > was > > added immediately, and the controversial bit postponed to see if the > better > > error reporting had any effect on the demand for it. > > > This is exactly how I intended it, and I believe that's Guido's desire, too. > Otherwise, he would've asked me to make the warning a FutureWarning, > instead. (Which could of course still happen.) > > -- > Thomas Wouters <[EMAIL PROTECTED]> > > Hi! I'm a .signature virus! copy me into your .signature file to help me > spread! > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45770 - in python/trunk:
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Actually after all the -1 responses I wasn't going to reconsider this > for 2.x; maybe for py3k. I think there may be proposals to review and possibly revise the packing and import mechanisms for 3.0. So I think your comment about str.join "one change in the near(ish) future is enough of a transition." may turn out to be relevant here also. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > def sortwords(*wordlist, case_sensitive=False): The rationale for this is pretty obvious. But ... > The second syntactical change is to allow the argument name to > be omitted for a varargs argument: > > def compare(a, b, *, key=None): > ... > > The reasoning behind this change is as follows. Imagine for a > moment a function which takes several positional arguments, as > well as a keyword argument: > > def compare(a, b, key=None): > ... > > Now, suppose you wanted to have 'key' be a keyword-only argument. Why? Why not let the user type the additional argument(s) without the parameter name? tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] (hopefully) final draft of externally maintained code PEP
Only piece of info I am missing right now is who is in charge of expat. If no one steps forward I will just mark it as N/A. I would also like Gerhard to sign off on pysqlite section. Otherwise this PEP is finished and I will commit it once I get the info I need (or lack thereof) and Gerhard gives me an OK assuming no one else finds a problem with it. - PEP: XXX Title: Externally Maintained Packages Version: $Revision: 43251 $ Last-Modified: $Date: 2006-03-23 06:28:55 -0800 (Thu, 23 Mar 2006) $ Author: Brett Cannon <[EMAIL PROTECTED]> Status: Active Type: Informational Content-Type: text/x-rst Created: XX-XXX-2006 Abstract There are many great pieces of Python software developed outside of the Python standard library (aka, stdlib). Sometimes it makes sense to incorporate these externally maintained packages into the stdlib in order to fill a gap in the tools provided by Python. But by having the packages maintained externally it means Python's developers do not have direct control over the packages' evolution and maintenance. Some package developers prefer to have bug reports and patches go through them first instead of being directly applied to Python's repository. This PEP is meant to record details of packages in the stdlib that are maintained outside of Python's repository. Specifically, it is meant to keep track of any specific maintenance needs for each package. It also is meant to allow people to know which version of a package is released with which version of Python. Externally Maintained Packages == The section title is the name of the package as known outside of the Python standard library. The "standard library name" is what the package is named within Python. The "contact person" is the Python developer in charge of maintaining the package. The "synchronisation history" lists what external version of the package was included in each version of Python (if different from the previous Python release). ctypes -- - Web page http://starship.python.net/crew/theller/ctypes/ - Standard library name ctypes - Contact person Thomas Heller - Synchronisation history * 0.9.9.6 (2.5) Bugs can be reported to either the Python tracker [#python-tracker]_ or the ctypes tracker [#ctypes-tracker]_ and assigned to Thomas Heller. ElementTree --- - Web page http://effbot.org/zone/element-index.htm - Standard library name xml.etree - Contact person Fredrik Lundh - Synchronisation history * 1.2.6 (2.5) Patches should not be directly applied to Python HEAD, but instead reported to the Python tracker [#python-tracker]_ (critical bug fixes are the exception). Bugs should also be reported to the Python tracker. Both bugs and patches should be assigned to Fredrik Lundh. Expat XML parser - Web page http://www.libexpat.org/ - Standard library name N/A (this refers to the parser itself, and not the Python bindings) - Contact person XXX - Synchronisation history * 1.95.8 (2.4) * 1.95.7 (2.3) Optik - - Web site http://optik.sourceforge.net/ - Standard library name optparse - Contact person Greg Ward - Synchronisation history * 1.5.1 (2.5) * 1.5a1 (2.4) * 1.4 (2.3) pysqlite - Web site http://www.sqlite.org/ - Standard library name sqlite3 - Contact person Gerhard Häring - Synchronisation history * 2.2.2 (2.5) Bugs should be reported to the pysqlite bug tracker [#pysqlite-tracker]_ as well as any patches that are not deemed critical. References == .. [#python-tracker] Python tracker (http://sourceforge.net/tracker/?group_id=5470) .. [#ctypes-tracker] ctypes tracker (http://sourceforge.net/tracker/?group_id=71702) .. [#pysqlite-tracker] pysqlite tracker (http://pysqlite.org/) Copyright = This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r45770 - in python/trunk:
I may be misunderstanding what you wrote. I thought that packing and join were *only* being discussed in a py3k context? If they are being discussed in a 2.x context, then yes, these discussions ought to be moved to py3k. --Guido On 4/29/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Actually after all the -1 responses I wasn't going to reconsider this > > for 2.x; maybe for py3k. > > I think there may be proposals to review and possibly revise the packing > and import mechanisms for 3.0. So I think your comment about str.join "one > change in the near(ish) future is enough of a transition." may turn out to > be relevant here also. > > tjr > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On Sat, Apr 29, 2006, Talin wrote: > > Specification > > Syntactically, the proposed changes are fairly simple. The first > change is to allow regular arguments to appear after a varargs > argument: > > def sortwords(*wordlist, case_sensitive=False): > ... > > This function accepts any number of positional arguments, and it > also accepts a keyword option called 'case_sensitive'. This > option will never be filled in by a positional argument, but > must be explicitly specified by name. > > Keyword-only arguments are not required to have a default value. > Since Python requires that all arguments be bound to a value, > and since the only way to bind a value to a keyword-only argument > is via keyword, such arguments are therefore 'required keyword' > arguments. Such arguments must be supplied by the caller, and > they must be supplied via keyword. You should show with simulated doctests what happens when you call required keyword functions correctly and incorrectly. You should also show an example of a required keyword function where the parameter does not have a default value. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] rich comparisions and old-style classes
trying to come up with a more concise description of the rich
comparision machinery for pyref.infogami.com, I stumbled upon
an oddity that I cannot really explain:
in the attached example below, why is the rich comparision
machinery doing *four* attempts to use __eq__ in the old-
class case?
$ more test.py
class old:
def __init__(self, name):
self.name = name
def __repr__(self):
return self.name
def __eq__(self, other):
print "EQ", self, other
return NotImplemented
def __cmp__(self, other):
print "CMP", self, other
return 0
class new(object):
def __init__(self, name):
self.name = name
def __repr__(self):
return self.name
def __eq__(self, other):
print "EQ", self, other
return NotImplemented
def __cmp__(self, other):
print "CMP", self, other
return 0
a = old("A")
b = old("B")
print a == b
a = new("A")
b = new("B")
print a == b
$ python test.py
EQ A B
EQ B A
EQ B A
EQ A B
CMP A B
True
EQ A B
EQ B A
CMP A B
True
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3101: Advanced String Formatting
PEP: 3101
Title: Advanced String Formatting
Version: $Revision$
Last-Modified: $Date$
Author: Talin
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 16-Apr-2006
Python-Version: 3.0
Post-History:
Abstract
This PEP proposes a new system for built-in string formatting
operations, intended as a replacement for the existing '%' string
formatting operator.
Rationale
Python currently provides two methods of string interpolation:
- The '%' operator for strings. [1]
- The string.Template module. [2]
The scope of this PEP will be restricted to proposals for built-in
string formatting operations (in other words, methods of the
built-in string type).
The '%' operator is primarily limited by the fact that it is a
binary operator, and therefore can take at most two arguments.
One of those arguments is already dedicated to the format string,
leaving all other variables to be squeezed into the remaining
argument. The current practice is to use either a dictionary or a
tuple as the second argument, but as many people have commented
[3], this lacks flexibility. The "all or nothing" approach
(meaning that one must choose between only positional arguments,
or only named arguments) is felt to be overly constraining.
While there is some overlap between this proposal and
string.Template, it is felt that each serves a distinct need,
and that one does not obviate the other. In any case,
string.Template will not be discussed here.
Specification
The specification will consist of 4 parts:
- Specification of a set of methods to be added to the built-in
string class.
- Specification of a new syntax for format strings.
- Specification of a new set of class methods to control the
formatting and conversion of objects.
- Specification of an API for user-defined formatting classes.
String Methods
The build-in string class will gain a new method, 'format',
which takes takes an arbitrary number of positional and keyword
arguments:
"The story of {0}, {1}, and {c}".format(a, b, c=d)
Within a format string, each positional argument is identified
with a number, starting from zero, so in the above example, 'a' is
argument 0 and 'b' is argument 1. Each keyword argument is
identified by its keyword name, so in the above example, 'c' is
used to refer to the third argument.
The result of the format call is an object of the same type
(string or unicode) as the format string.
Format Strings
Brace characters ('curly braces') are used to indicate a
replacement field within the string:
"My name is {0}".format('Fred')
The result of this is the string:
"My name is Fred"
Braces can be escaped using a backslash:
"My name is {0} :-\{\}".format('Fred')
Which would produce:
"My name is Fred :-{}"
The element within the braces is called a 'field'. Fields consist
of a name, which can either be simple or compound, and an optional
'conversion specifier'.
Simple names are either names or numbers. If numbers, they must
be valid decimal numbers; if names, they must be valid Python
identifiers. A number is used to identify a positional argument,
while a name is used to identify a keyword argument.
Compound names are a sequence of simple names seperated by
periods:
"My name is {0.name} :-\{\}".format(dict(name='Fred'))
Compound names can be used to access specific dictionary entries,
array elements, or object attributes. In the above example, the
'{0.name}' field refers to the dictionary entry 'name' within
positional argument 0.
Each field can also specify an optional set of 'conversion
specifiers'. Conversion specifiers follow the field name, with a
colon (':') character separating the two:
"My name is {0:8}".format('Fred')
The meaning and syntax of the conversion specifiers depends on the
type of object that is being formatted, however many of the
built-in types will recognize a standard set of conversion
specifiers.
The conversion specifier consists of a sequence of zero or more
characters, each of which can consist of any printable character
except for a non-escaped '}'. The format() method does not
attempt to intepret the conversion specifiers in any way; it
merely passes all of the characters between the first colon ':'
and the matching right brace ('}') to the various underlying
formatters (described later.)
Standard Conversion Specifiers
For most built-in types, the conversion specifiers will be the
same or similar to the existing conversion specifiers used with
the '%' operator. Thus, instead of '%02.2x", you will say
'{0:2.2x}'.
There are a few diffe
