Raymond Hettinger [EMAIL PROTECTED] wrote:
[Steven Bethard]
For Python 2.5, I'd like to add a keyword argument 'key' to min and
max like we have now for list.sort and sorted.
. . .
This means that a 'key'
argument can *only* be specified as a keyword parameter, thus giving
us
On Wed, 12 Jan 2005 16:07:37 -0600, Ian Bicking [EMAIL PROTECTED] wrote:
One case occurred to me with the discussion of strings and files, i.e.,
adapting from a string to a file. Let's say an IReadableFile, since
files are too ambiguous.
Consider the case where we are using a path object,
Nick Coghlan wrote:
In the example below (printing the first 3 items of a sequence), the fact that
sorted() produces a new iterable list, while reversed() produces an iterator
over the original list *should* be an irrelevant implementation detail from
the
programmer's point of view.
You
Raymond Hettinger [EMAIL PROTECTED] wrote:
FWIW, someone (Bengt Richter perhaps) once suggested syntactic support
differentiated from sequences but less awkward than a call to
itertools.islice().
itertools.islice(someseq, lo, hi) would be rendered as someseq'[lo:hi].
Just to make sure I'm
Fernando Perez [EMAIL PROTECTED] wrote:
Alan Green [EMAIL PROTECTED] wrote:
Steven Bethard is proposing a new collection class named Bunch. I had
a few suggestions which I attached as comments to the patch - but what
is really required is a bit more work on the draft PEP
On Thu, 27 Jan 2005 18:31:55 -0700, Fernando Perez [EMAIL PROTECTED] wrote:
However, I think it would perhaps be best to advertise any methods of Bunch as
strictly classmethods from day 1. Otherwise, you can have:
b = Bunch()
b.update(otherdict) - otherdict happens to have an 'update' key
On Sat, 26 Feb 2005 19:26:11 -0500, Raymond Hettinger [EMAIL PROTECTED] wrote:
Are you sure about that? Contriving examples is easy, but download a
few modules, scan them for use cases, and you may find, as I did, that
partial() rarely applies. The argument order tends to be problematic.
Peter Harris [EMAIL PROTECTED] wrote:
However, I sympathise with anyone who feels unhappy about a new module
just for what amounts to one function.
Well, since it seems that the emphasis in Python development is now
moving more towards expanding the standard library, a module that has
only one
Here's another two skipped threads. Ditto Tim Lesher's comments,
criticisms, or rotten tomatoes request. =)
-
2.3.5 and 2.4.1 release plans
-
Anthony Baxter, Alex Martelli and Tim Peters squelched a bug where
deepcopy failed
On Sat, 5 Mar 2005 11:39:42 -0500, Greg Ward [EMAIL PROTECTED] wrote:
On 05 March 2005, Nick Coghlan said:
Steven Bethard has put together some text to add __new__ to the list of
Basic Customisation methods in the language reference. Would one of the
documentation folks care to take a look
Thomas Heller [EMAIL PROTECTED] wrote:
[About an ordered dictionary]
[snip]
I cannot understand why people are against adding it to stdlib (after
the name, the implementation, and the exact place have been decided).
It's certainly a useful data type, isn't it?
Well, that was basically the
Delaney, Timothy C (Timothy) [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
def filterdups(iterable):
seen = set()
for item in iterable:
if item not in seen:
seen.add(item)
yield item
Adding this to, say, itertools would cover all my
Brian Sabbey [EMAIL PROTECTED] wrote:
(I) Give generators a __call__ method as an alternative to 'next'.
Method __call__ should take a single parameter: a function. Using
__call__ will cause the generator to start executing normally, but when a
'yield' is reached, the generator will invoke
Brian Sabbey [EMAIL PROTECTED] wrote:
I agree that this is a confusing way to use generators. But it is the
expected way to use code blocks as found in other languages. It would
take some getting used to that 'for' can be used this way, but I think it
would be worth it.
I guess I need some
On Apr 5, 2005 8:46 PM, Brett C. [EMAIL PROTECTED] wrote:
Alex A. Naanou wrote:
Here there are two problems, the first is minor, and it is that
anything assigned to the __dict__ attribute is checked to be a
descendant of the dict class (mixing this in does not seem to work)...
and the
On 4/19/05, Alex Martelli [EMAIL PROTECTED] wrote:
Well, one obvious use might be, say:
@withfile('foo.bar', 'r'):
content = thefile.read()
but that would require the decorator and block to be able to interact
in some way, so that inside the block 'thefile' is defined suitably.
Greg Ewing wrote:
Steven Bethard wrote:
Of course, even with the unpack list, you still have to know what kind
of arguments the function calls your block with. And because these
only appear within the code, e.g.
block(openfile)
you can't rely on easily accessible things like
On 4/21/05, Guido van Rossum [EMAIL PROTECTED] wrote:
It strikes me that with something like this lexical declaration, we
could abuse decorators as per Carl Banks's recipe[1] to get the
equivalent of thunks:
abuse being the operative word.
Yup. I was just drawing the parallel between:
Ka-Ping Yee wrote:
It seems to me that, in general, Python likes to use keywords for
statements and operators for expressions.
Probably worth noting that 'for', 'in' and 'if' in generator
expressions and list comprehensions blur this distinction somewhat...
Steve
--
You can wordify anything
On 4/27/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
So block-statements would be very much like for-loops, except:
(1) iter() is not called on the expression
(2) the fact
On 4/28/05, Steven Bethard [EMAIL PROTECTED] wrote:
however, the iterable object is notified whenever a 'continue',
'break', or 'return' statement is executed inside the block-statement.
This should read:
however, the iterable object is notified whenever a 'continue',
'break' or 'return
On 4/28/05, Greg Ewing [EMAIL PROTECTED] wrote:
Neil Schemenauer wrote:
The translation of a block-statement could become:
itr = EXPR1
arg = None
while True:
try:
VAR1 = next(itr, arg)
except StopIteration:
On 5/4/05, Nick Coghlan [EMAIL PROTECTED] wrote:
With single-pass semantics, an iterator used in a block statement would have
it's .next() method called exactly once, and it's __exit__ method called
exactly
once if the call to .next() does not raise StopIteration. And there's no need
to
On 5/5/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
Makes me wonder if we shouldn't just return to the __enter__() and
__exit__() names of PEP 310[1] where for a generator __enter__() is
just an alias for next(). We could even require Phillip J. Eby's
blockgenerator
On 5/5/05, Paul Moore [EMAIL PROTECTED] wrote:
And does your proposal allow for continue EXPR as supported by PEP
340? I can't see that it could, given that your proposal treats block
statements as not being loops.
Read PEP 340 again -- the continue EXPR syntax is orthogonal to the
discussion
On 5/6/05, Paul Moore [EMAIL PROTECTED] wrote:
I don't think it damages any features. Are there features you still
think the non-looping proposal removes? (I'm not counting orthogonal
feautres like continue EXPR which could easily be added as an
entirely separate PEP.)
I *am*
,
Jim Jewett, Josiah Carlson, Ka-Ping Yee, Michael Chermside,
Michael Hudson, Neil Schemenauer, Nick Coghlan, Paul Moore,
Phillip Eby, Raymond Hettinger, Reinhold Birkenfeld, Samuele
Pedroni, Shannon Behrens, Skip Montanaro, Steven Bethard, Terry
Reedy, Tim Delaney, Aahz, and others
On 5/6/05, Paul Moore [EMAIL PROTECTED] wrote:
On 5/6/05, Steven Bethard [EMAIL PROTECTED] wrote:
PEP: XXX
Title: Enhanced Iterators
Strawman question - as this is the uncontroversial bit, can this
part be accepted as it stands? :-)
FWIW, I'm +1 on this. Enhanced Iterators
* updates
On 5/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
The gist is that the alternative is to require an __exit__() method to raise
TerminateBlock in order to suppress an exception.
So I didn't see any examples that really needed TerminateBlock to
suppress an exception. If the semantics of a
On 5/11/05, Steven Bethard [EMAIL PROTECTED] wrote:
If you want the default to be that the exception gets re-raised
(instead of being suppressed as it is above), I think you could just
change the finally block to something like:
finally:
if stmt_exit(*exc):
raise exc
[Guido]
Going for all-out simplicity, I would like to be able to write these examples:
class locking:
def __init__(self, lock): self.lock = lock
def __enter__(self): self.lock.acquire()
def __exit__(self, *args): self.lock.release()
class opening:
def __init__(self,
On 5/12/05, Michele Simionato [EMAIL PROTECTED] wrote:
In my experience super is a huge can of worms and actually I have a
non-feature
request about the descriptor aspect of super: I would like super's
__get__ method
and the possibily to call super with just one argument to be removed
in
On 5/13/05, Guido van Rossum [EMAIL PROTECTED] wrote:
So then the all-important question I want to pose is: do we like the
idea of using a (degenerate, decorated) generator as a template for
the do-statement enough to accept the slightly increased complexity?
+0. I'm not thoroughly convinced
On 5/15/05, Paul Moore [EMAIL PROTECTED] wrote:
There were a *lot* of nice features with PEP 340. The initial
discussion had a lot of people enthusiastic about all the neat things
they could do with it. That's disappeared now, in a long series of
attempts to fix the looping issue.
Having done
Jp Calderone:
for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''):
f2.write(chunk)
Phillip J. Eby:
More seriously, I think your translation makes an excellent argument in
*favor* of having a do/while statement for greater clarity. :)
Michael Chermside
Interesting... I had the opposite
On 6/15/05, Benji York [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I would prefer that the alternate iter() form was broken off into
another separate function, say, iterfunc(), that would let me write
Jp's solution something like:
for chunk in iterfunc('', f1.read, CHUNK_SIZE
Steven Bethard wrote:
I would prefer that the alternate iter() form was broken off into
another separate function, say, iterfunc(), that would let me write
Jp's solution something like:
for chunk in iterfunc('', f1.read, CHUNK_SIZE):
f2.write(chunk)
Benji York wrote:
for chunk in iter
Raymond Hettinger wrote:
May I suggest rejecting PEP 265.
As of Py2.4, its use case is easily solved with:
sorted(d.iteritems(), key=itemgetter(1), reverse=True)
[('b', 23), ('d', 17), ('c', 5), ('a', 2), ('e', 1)]
+1.
I find that usually when I want something like this, I use:
Here's the May 01-15 draft. Sorry for the delay. Please check the
Unicode summary at the end especially closely; I'm not entirely sure I
got that one all right. Thanks!
As always, please let us know if you have any corrections!
Steve
==
Summary Announcements
Here's our draft of the summary for the second half of June. As
usual, please let me, Tony or Tim know if you have any comments or
corrections.
-- Steven Bethard
=
Summary Announcements
=
--
OSCON Registration
--
Though
On 7/5/05, Andrew Durdin [EMAIL PROTECTED] wrote:
print Usage: dostuff options
Options:
-c - blah blah
-f filename - do stuff with file filename
-s - more blah
Isn't the standard idiom for this already:
import textwrap
...
print textwrap.dedent(\
Usage:
Here's the draft for the first half of July. Please look especially
close at the GCC/G++ Issues on Linux thread; I'm not sure I got all
the details right.
=
Announcements
=
--
QOTF (Quotes of the Fortnight)
--
Raymond Hettinger wrote:
If the PEP can't resist the urge to create new intermediate groupings,
then start by grepping through tons of Python code to find-out which
exceptions are typically caught on the same line. That would be a
worthwhile empirical study and may lead to useful insights.
I
Raymond Hettinger wrote:
[Ian Bicking]
I think partial() misses an important use case of method getting, for
instance:
lst = ['A', 'b', 'C']
lst.sort(key=partialmethod('lower'))
We've already got one:
lst.sort(key=operator.attrgetter('lower'))
Doesn't that just
Josiah Carlson wrote:
Steven Bethard [EMAIL PROTECTED] wrote:
If we're going to move away from the itemgetter() and attrgetter()
style, then we should be consistent about it and provide a solution
(or solutions) that answers all of these problems:
obj.attr
obj.attr(*args
Martin v. Löwis wrote:
Steven Bethard wrote:
I thought that:
operator.attrgetter() was for obj.attr
operator.itemgetter() was for obj[integer_index]
My point exactly. If we're sticking to the same style, I would expect that
for
obj.method(*args, **kwargs)
we would have
[Guido van Rossum]
And good riddance! The print statement harks back to ABC and even
(unvisual) Basic. Out with it!
[Barry Warsaw]
I have to strongly disagree. The print statement is simple, easy to
understand, and easy to use.
[Paul Moore]
I agree with Barry. In particular, the behaviour
Reinhold Birkenfeld wrote:
Raymond Hettinger wrote:
Actually, formatting needs to become a function. The overloading of the
arithmetic mod operator has proven to be unfortunate (if only because of
precedence issues).
But then, a format() function would be necessary (equivalent to
Charles Cazabon wrote:
Fredrik Lundh [EMAIL PROTECTED] wrote:
next use case:
print 'foo:', foo, 'bar:', bar, 'baz:', baz,
if frobble 0:
print 'frobble', frobble
else:
print 'no frobble today'
The need to print /and/ not add a newline isn't nearly as
On 9/2/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Steven print 'foo:', foo, 'bar:', bar, 'baz:', baz,
Steven print 'frobble', frobble
Steven In my proposed function:
Steven print('foo:', foo, 'bar:', bar, 'baz:', baz,
Steven 'frobble',
[EMAIL PROTECTED] wrote:
Perhaps if the last non-keyword argument was exactly one space, the
newline could be suppressed, e.g.:
print(foo, bar, baz, , stream=sys.stderr)
Sorry, I missed the newline-suppression idea in my first reply. I
think the rule above is too confusing. I'm also
Nick Coghlan wrote:
I actually hope that extended function call syntax in Py3k will
use iterators rather than tuples so that this problem goes away.
I suggested this a while back on the Python list:
http://mail.python.org/pipermail/python-list/2004-December/257282.html
Raymond Hettinger
Fredrik Lundh wrote:
Steven Bethard wrote:
- Error and help messages, often with print sys.stderr
Use the print() method of sys.stderr:
sys.stderr.print('error or help message')
so who's going to add print methods to all file-like objects?
The same people that added __iter__
Guido van Rossum wrote:
If there's demand, we could also introduce printf(), which would work
just like C's printf() except it takes a keyword argument to redirect
the output.
I think this is probably unnecessary if string formatting becomes a
function instead of the % operator (as has been
Bill Janssen wrote:
So here's the summary of the arguments against: two style points
(trailing comma and stream) (from the man who approved the current
decorator syntax!), and it's hard to extend. (By the way, I agree that
the syntax is ugly, and IMO a bad idea in general. Shame the @
Bill Janssen wrote:
I think what Nick really is asking for is a better print statement --
and there's no particularly good reason to move to a function to
attain that end.
Well one reason (you can judge for yourself whether it's good or
not) is that adding more syntax to the print statement
[Raymond Hettinger]
Actually, formatting needs to become a function. The overloading of the
arithmetic mod operator has proven to be unfortunate (if only because of
precedence issues).
[Guido van Rossum]
For me, it's not so much the precedence, but the fact that %s % x
doesn't work as
[Greg Ewing]
While we're on the subject, in Py3k I'd like to see
readline(), readlines(), etc. removed from file objects
and made builtin functions instead. It should only
be necessary to implement read() and write() to get
a file-like object having equal status with all
others.
[Fredrik
Greg Ewing wrote:
François Pinard wrote:
The only practical reason to like this feature is sparing the need of
finding an otherwise useless name for the formal argument.
If the argument represents a coherent enough concept
to be passed in as a tuple in the first place, it
should be
Guido van Rossum wrote:
Also, I bet many people will be surprised to know that this code doesn't work:
add = lambda (x, y): x+y
print add(1, 2)
What, an example using lambda syntax that's unintuitive? Never! ;-)
STeVe
--
You can wordify anything if you just verb it.
--- Bucky
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use colons.
FWIW, I find this quite intuitive. It follows the same pattern as LCs
and GEs
Adam wrote:
So looking at a few alternatives ...
[snip]
(e ? (e1 ? a1 : b1) : (e2 ? a2 : b2))
[snip]
(if e, (if e1, a1 else b1) else (if e2, a2 else b2))
[snip]
(if e then (if e1 then a1 else b1) else (if e2 then a2 else b2))
[snip
(e selects (e1 selects a1 else b1) else (e2 selects a2
On 9/29/05, Robey Pointer [EMAIL PROTECTED] wrote:
Yesterday I ran into a bug in the C API docs. The top of this page:
http://docs.python.org/api/unicodeObjects.html
says:
Py_UNICODE
This type represents a 16-bit unsigned storage type which is
used by Python internally as basis
On 9/29/05, Guido van Rossum wrote:
After a long discussion I've decided to add a shortcut conditional
expression to Python 2.5.
The syntax will be
A if C else B
[snip]
Congratulations gracefully accepted.
Congratulations, and many thanks for making this decision before the
threads
Nick Coghlan wrote:
So my vote would actually go for deprecating the use of square brackets to
surround an assignment target list - it makes it look like an actual list
object should be involved somewhere, but there isn't one.
I've found myself using square brackets a few times for more
Nick Coghlan wrote:
Having module attribute access obey the descriptor protocol (__get__, __set__,
__delete__) sounds like a pretty good option to me.
It would even be pretty backwards compatible, as I'd be hardpressed to think
why anyone would have a descriptor *instance* as a top-level
Barry Warsaw wrote:
On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:
Let's change the property built-in so that its arguments can be either
functions or strings (or None). If they are functions or None, it
behaves exactly like it always has.
If an argument is a string, it should be
Michele Simionato wrote:
This reminds me of an idea I have kept in my drawer for a couple of years or
so.
Here is my proposition: we could have the statement syntax
callable name tuple:
definitions
to be syntactic sugar for
name = callable(name, tuple, dict-of-definitions)
[snip]
I wrote (in the summary):
While there is no interface to the AST yet, one is
intended for the not-so-distant future.
Simon Burton wrote:
who is doing this ? I am mad keen to get this happening.
Brett Cannon wrote:
No one yet. Some ideas have been tossed around (read the thread for
Barry Warsaw wrote:
On Fri, 2005-12-09 at 15:38 -0600, Ian Bicking wrote:
Also decide whether your attributes should be private or not.
The difference between private and non-public is that the former
will never be useful for a derived class, while the latter might
Jim Fulton wrote:
Can we officially mark __private as a mistake. Perhaps:
- Strongly discourage it in the style guide
+1
- Mark it in the language reference as a deprecated feature
+1
- Generate deprecation warnings when it is used?
-0
I don't see that this gains us much. It will
On 12/11/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 12/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Keeping it for Py3K would be fine, if the mechanism was changed so that it
actually worked right. That is, the mechanics would be such that any two
concurrently existing classes would
On 12/12/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 12/11/05, Steven Bethard [EMAIL PROTECTED] wrote:
class Document(_cdm.Document):
...
# add convenience methods here
...
Personally, I find that naming convention a mistake. Call it
MyDocument or EnhancedDocument
Martin v. Löwis wrote:
Steven Bethard wrote:
I didn't really feel like the proposal was out of the blue. The
proposal has been brought up before, both on python-dev[1] and the
python-list[2]. ElementTree has a pretty large following - if you
look at XML-based questions on the python
Here's the summary for the first half of November -- sorry for the bit
of a delay. As always, let me or Tony know if you have any
corrections!
=
Summary Announcements
=
--
Reminder: Python is now on Subversion!
Raymond Hettinger wrote:
[Phillip J. Eby]
The only case that looks slightly less than optimal is:
set((1, 2, 3, 4, 5))
But I'm not sure that it warrants a special syntax just to get rid of the
extra ().
The PEP records that Tim argued for leaving the extra parentheses.
What
Guido van Rossum wrote:
After so many attempts to come up with an alternative for lambda,
perhaps we should admit defeat. I've not had the time to follow the
most recent rounds, but I propose that we keep lambda, so as to stop
wasting everybody's talent and time on an impossible quest.
Robert Brewer wrote:
Community consensus on syntax is a pipe dream.
+1 QOTF
And trust me, it'll be in there, since I'm one of the summary writers. ;-)
STeVe
--
Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy
___
Guido van Rossum wrote:
Alternative A: add a new method to the dict type with the semantics of
__getattr__ from the last proposal, using default_factory if not None
(except on_missing is inlined).
I'm not certain I understood this right but (after
s/__getattr__/__getitem__) this seems to
I wrote:
# I want to do ``dd[item] += 1``
Guido van Rossum wrote:
You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
is perfectly fine there and hard to improve upon.
Alex Martelli wrote:
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, I've now
On 2/20/06, Dan Gass [EMAIL PROTECTED] wrote:
Why not have the factory function take the key being looked up as an
argument? Seems like there would be uses to customize the default based on
the key. It also forces you to handle list factory functions and constant
factory functions (amongst
On 2/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Here's a crazy idea, that AFAIK has not been suggested before and could
work for both globals and closures: using a leading dot, ala the new
relative import feature. e.g.:
def incrementer(val):
def inc():
.val +=
Steven Bethard wrote:
And, as you mention, it's consistent with the relative import feature.
Greg Ewing wrote:
With imports, .foo is an abbreviation for myself.foo,
where myself is the absolute name for the current module,
and you could replace all instances of .foo with that.
Phillip J. Eby
On 3/1/06, Nicolas Fleury [EMAIL PROTECTED] wrote:
Basically, should staticmethods be made callable so that the following
would not raise an exception:
class A:
@staticmethod
def foo(): pass
bar = foo()
There's workarounds, but it's really just about usability.
On 3/12/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Nick Coghlan]
I agree it makes sense to have decorator, memoize, deprecated and
partial all being members of the same module, whether the name be
functools or functional (although I have a slight preference for
functools due to the
Georg Brandl wrote:
Nick Coghlan wrote:
Georg Brandl wrote:
some time ago, someone posted in python-list about icons using the Python
logo from the new site design [1]. IMO they are looking great and would
be a good replacement for the old non-scaling snakes on Windows in 2.5.
Those
Sorry about the delay folks. Here's the summary for the first half of
February. I'm going to try to get the ones out for the second half of
February and first half of March shortly.
Please send me any comments/corrections!
=
Announcements
=
Ok, if I summarize any more of python-dev, my brain's going to explode. ;-)
Here's the summaries for the first half of March. Let me know what to fix!
=
Announcements
=
---
Webstats for python.org
---
Thomas Wouters set up
Statement
Version: $Revision: 45366 $
Last-Modified: $Date: 2006-04-13 07:36:24 -0600 (Thu, 13 Apr 2006) $
Author: Steven Bethard [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006, 06-Apr-2006
Abstract
On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I know 2.5's not out yet, but since I now have a PEP number, I'm going
to go ahead and post this for discussion. Currently, the target
version is Python 2.6. You can also see the PEP at:
http://www.python.org
On 4/13/06, Ian D. Bollinger [EMAIL PROTECTED] wrote:
I guess I fail to see how this syntax is a significant improvement over
metaclasses (though __metaclass__ = xyz may not be the most aesthetic
construct.)
It doesn't seem strange to you to have to use a *class* statement and
a
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:05 PM 4/13/2006 -0600, Steven Bethard wrote:
On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I know 2.5's not out yet, but since I now have a PEP number, I'm going
to go ahead and post
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
Sorry, I'm not clear on exactly what you're suggesting. Are you
suggesting I try to implement the make-statement using context
managers? Or that I use a context manager to address Martin's
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote:
[snip examples using class/__metaclass__ statements to create non-types]
The question is, is the intent still clear?
Depends on your use case. I'm just saying that the PEP would be tons
On 4/15/06, Greg Ewing [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
make callable name tuple:
block
I don't like the position of the name being defined.
It should be straight after the opening keyword, as
with 'def' and 'class'.
I see where you're coming from
On 4/17/06, Russell E. Owen [EMAIL PROTECTED] wrote:
At some point folks were discussing use cases of make where it was
important to preserve the order in which items were added to the
namespace.
I'd like to suggest adding an implementation of an ordered dictionary to
standard python (e.g.
On 4/17/06, Ian Bicking [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
This PEP proposes a generalization of the class-declaration syntax,
the ``make`` statement. The proposed syntax and semantics parallel
the syntax for class definition, and so::
make callable name tuple
2006) $
Author: Steven Bethard [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006, 06-Apr-2006, 13-Apr-2006
Abstract
This PEP proposes a generalization of the class-declaration syntax,
the ``make
On 4/18/06, Steven Bethard [EMAIL PROTECTED] wrote:
I've updated PEP 359 with a bunch of the recent suggestions. The
patch is available at:
http://bugs.python.org/1472459
and I've pasted the full text below.
I've tried to be more explicit about the goals -- the make statement
is mostly
On 4/29/06, Talin [EMAIL PROTECTED] wrote:
PEP: 3102
Title: Keyword-Only Arguments
Version: $Revision$
Last-Modified: $Date$
Author: Talin talin at acm.org
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 22-Apr-2006
Python-Version: 3.0
Post-History:
Abstract
1 - 100 of 270 matches
Mail list logo
