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
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?
$
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):
> ...
>
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
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
"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:
>
>
"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
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
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
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
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
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
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
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",
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
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)
"
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
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
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
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
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
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
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
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:
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,
>
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
> 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
> 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
29 matches
Mail list logo
