I've submitted the "Keyword-Only Arguments" PEP that we've been discussing. You
can also read it here:
http://www.viridia.org/python/doc/PEP_KeywordOnlyArguments.txt
-- Talin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/ma
On 4/23/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
> >
> > A long-standing part of Py3K is removing 'old style slices' (meaning the
> > __get/set/delslice__ methods and the sq_slice/sq_ass_slice sequence-struct
> > functions, but not slice objects.) I started removing them,
On Sun, 23 Apr 2006 05:36 am, Talin wrote:
> @precondition( y=NotNegative )
> def power( x, y ):
> ...
> ...where 'NotNegative' is a function which simply does an assert( value >=
0 )
The phrase "y=NotNegative" is a classic type constraint predicate.
Given that type expressions will be dynamic
Greg Ewing a écrit :
> Jim Jewett wrote:
>
>
>>It has not yet been specified what would happen to additional
>>positional arguments that get passed in anyway. (Swallow or raise an
>>Exception?)
>
>
> I've always intended that there would be an exception.
>
If so, why not replace the lone star
On Sun, 23 Apr 2006 12:53 am, Fredrik Lundh wrote:
> Guido van Rossum wrote:
> > It's an interesting idea; it's been brought up before but nobody AFAIK
> > has ever implemented it. I like the scoping requirement.
>
> can we add support for XML literals while we're at it?
>
> http://effbot.org/z
Bill Birch tpg.com.au> writes:
>
> On Sun, 23 Apr 2006 05:36 am, Talin wrote:
> > precondition( y=NotNegative )
> > def power( x, y ):
> >...
> > ...where 'NotNegative' is a function which simply does an assert( value >=
> 0 )
> The phrase "y=NotNegative" is a classic type constraint pred
Nick Coghlan wrote:
> [...]
>> The second method, 'fformat', is identical to the first, except that it
>> takes an additional first argument that is used to specify a 'custom
>> formatter' object, which can override the normal formatting rules for
>> specific fields:
>>
>> "More on {0}, {1}, and {c
Greg Ewing wrote:
>> Both should be optimized away by the compiler.
>
> How? I don't see how the compiler can know either of
> those things.
As you then discussed: it can do that for local variables
(it might even *warn* about the redundant assignment, though).
OTOH, for local variables, it might
It seems that the history of the Python mailing lists are littered with the
decayed corpses of various ideas related to "metaprogramming", that is, programs
that write programs, either at compile time.
We've seen proposals for C-style macros, Lisp-style macros, programmable syntax
(guilty!), AST a
Talin wrote:
> Anyway, I wanted to throw this out there for discussion. I'm mainly interested
> in a discussion of ways that we could facilitate additional metaprogramming in
> Python, with the tiniest possible changes to the language
PEP 3099 contains Guido's explicit pronouncement against this,
Having been shot down so hard on my request to bring for loops into
symetry with list comprehensions, I have a new proposal - stackable
blocks.
This is a very _small_ amount of syntax sugar, the basic idea is that
any block headers can be stacked on the same line. This changes no
semantics, nor do
On 4/23/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
For pointer that live on the heap, Py_[X]DECREF is usuallydone because eithera) the memory block containing the pointer is about to be released (e.g. when a tuple is deallocated), orb) the pointer is about to be changed to point to somethin
Crutcher Dunnavant wrote:
> for file in open_files: if file.readable():
> ...
>
> for line in open(file): if line.strip():
I don't like this. It looks unclean and adds an exception to the
conventional Python rules while yielding no particular or significant
benefit.
--
Ivan Krstic <[EMAIL PRO
Baptiste Carvello <[EMAIL PROTECTED]> wrote:
>
> Greg Ewing a écrit :
> > Jim Jewett wrote:
> >
> >
> >>It has not yet been specified what would happen to additional
> >>positional arguments that get passed in anyway. (Swallow or raise an
> >>Exception?)
> >
> >
> > I've always intended that
Ivan Krstic fas.harvard.edu> writes:
> Talin wrote:
> > Anyway, I wanted to throw this out there for discussion. I'm mainly
> > interested in a discussion of ways that we could facilitate
> > additional metaprogramming in Python, with the tiniest possible changes
> > to the language
>
> PEP 3099
On 4/21/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Another (similar) way would be to let the user pay for the high typechecking
> price in normal cases *but* provide a list[int] class, which is a list
> decorated with typechecks on modification operations. We could have
> list[int|float]() to
On 4/23/06, Ivan Krstic <[EMAIL PROTECTED]> wrote:
> Crutcher Dunnavant wrote:
> > for file in open_files: if file.readable():
> > ...
> >
> > for line in open(file): if line.strip():
>
> I don't like this. It looks unclean and adds an exception to the
> conventional Python rules while yielding n
On Apr 23, 2006, at 5:12 PM, Crutcher Dunnavant wrote:
> On 4/23/06, Ivan Krstic <[EMAIL PROTECTED]> wrote:
>> Crutcher Dunnavant wrote:
>>> for file in open_files: if file.readable():
>>> ...
>>>
>>> for line in open(file): if line.strip():
>>
>> I don't like this. It looks unclean and adds an
On 4/23/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
>
> On Apr 23, 2006, at 5:12 PM, Crutcher Dunnavant wrote:
>
> > On 4/23/06, Ivan Krstic <[EMAIL PROTECTED]> wrote:
> >> Crutcher Dunnavant wrote:
> >>> for file in open_files: if file.readable():
> >>> ...
> >>>
> >>> for line in open(file): if l
On Apr 23, 2006, at 6:32 PM, Crutcher Dunnavant wrote:
> On 4/23/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
>>
>> I think what Ivan meant is that the normal Python rule is that if you
>> have a full-colon (ANYWHERE), and you put something after it on the
>> same line, then you're done the block. T
On 4/23/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
>
> On Apr 23, 2006, at 6:32 PM, Crutcher Dunnavant wrote:
>
> > On 4/23/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
> >>
> >> I think what Ivan meant is that the normal Python rule is that if you
> >> have a full-colon (ANYWHERE), and you put somethi
There have been a number of interesting suggestions as to whether
string.format should support pipelined conversion specifiers, nested
conversion specifiers, and so forth.
I'm going to follow in Guido's lead at this point, and say that perhaps
these kinds of decisions should be made after looking
Crutcher Dunnavant gmail.com> writes:
>
> On 4/23/06, Jay Parlar cogeco.ca> wrote:
> >
> > What's the use case for doing this with method and class defs?
>
> They're blocks, what would be the use case for having the
> for/while/with/if stuff be treated different from class/def ? Besides,
> it
On Apr 23, 2006, at 6:56 PM, Crutcher Dunnavant wrote:
>>
>
> They're blocks, what would be the use case for having the
> for/while/with/if stuff be treated different from class/def ? Besides,
> it comes up in platform handling code.
>
> if sys.platform == 'foo': class Bar:
> ...
>
> class Foo:
Crutcher Dunnavant wrote:
> Having been shot down so hard on my request to bring for loops into
> symetry with list comprehensions, I have a new proposal - stackable
> blocks.
>
> This is a very _small_ amount of syntax sugar, the basic idea is that
> any block headers can be stacked on the same l
Talin wrote:
> Here's a condensed list of the open issues that have been raised by people
> so far:
>
> (Well, edited somewhat - I'm including 'major' issues, not minor nits -- we
> can discuss those once the major issues are settled.)
>
> 1) Whether to drop the optional parts of the proposal:
>
Ian Bicking colorstudy.com> writes:
>
> Talin wrote:
> > Here's a condensed list of the open issues that have been raised by people
> > so far:
> >
> > (Well, edited somewhat - I'm including 'major' issues, not minor nits -- we
> > can discuss those once the major issues are settled.)
> >
> >
"Talin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> For some reason, I have stuck in my head the idea that this concept of
> 'quoting'
> is central to the whole business
I agree. And in Python, the main means of implicit (unwritten) quoting is
to use a statement instead of a
28 matches
Mail list logo
