> 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
> 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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
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 program
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,
>
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:
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 th
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
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
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 "h
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 a
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 mut
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 putti
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
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)
"
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 bel
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",
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 wi
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 spe
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
assi
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
>
> T
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
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 <[EM
"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 y
"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:
>
>
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 give
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 R
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):
> ...
>
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?
$
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
oper
29 matches
Mail list logo
