Phillip J. Eby wrote:
> At 05:19 PM 4/27/05 -0700, Guido van Rossum wrote:
> >I'm not convinced of that, especially since all *generators* will
> >automatically be usable as templates, whether or not they were
> >intended as such. And why *shouldn't* you be allowed to use a block
> >for looping, if
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
On 4/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > And surely you exaggerate. How about this then:
> >
> > The with-statement is similar to the for-loop. Until you've
> > learned about the differences in detail, the only time you should
> > write a with-st
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 Stop
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
>
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 cou
On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The discussion on the meaning of break when nesting a PEP 340 block statement
> inside a for loop has given me some real reasons to prefer PEP 310's single
> pass
> semantics for user defined statements (more on that at the end). The
> suggesti
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
dis
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.)
>
>
lose()
Used as follows:
block opening_w_error("/etc/passwd", "a") as f, err:
if err:
print "IOError:", err
else:
f.write("guido::0:0::/:/bin/sh\n")
Acknowledgements
In no useful ord
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?
On 5/11/05, Russell E. Owen <[EMAIL PROTECTED]> wrote:
> I think this would be a useful enhancement. It simplifies the published
> documentation a bit (no need to document try/except as a separate entity
> from try/finally) and I have plenty of cases where I'd like to take
> advantage of it.
I hav
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 do-
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:
>
[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__(se
On 5/12/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Yeah, I figured out a tidier way to handle it after reading Phillip's message
> earlier today. My idea is similar to your second solution, but with an early
> exit via break, continue or return still indicated to the __exit__() method
> via
> T
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
On 5/12/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Steve Bethard has this example:
>
> stmt = EXPR1
> VAR1 = stmt.__enter__()
> exc = () # or (None, None, None) if you prefer
> try:
> try:
> BLOCK1
> except:
> exc = sys.exc_info()
>
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 conv
On 5/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
>From there I see the semantics:
VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
exc = (None, None, None)
try:
try:
BLOCK1
except:
exc = sys.exc_info()
fin
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.
Havi
On 5/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
In reading over PEP 3XX again, it struck me that I'd been having a
really hard time grasping exactly when I needed to use the
"needs_finish" decorator. Am I right in saying that I shoul
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 oppo
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:
> >
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(chun
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:
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 sug
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'v
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 (amon
On 2/21/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> The question which still remains in my mind, which I previously asked,
> is whether the use cases are compelling enough to warrant the feature
> addition.
I don't know whether I support the proposal or not, but in reading
Mark Russel's email,
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():
>
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
On 2/22/06, Almann T. Goo <[EMAIL PROTECTED]> wrote:
> Since the current semantics allow *evaluation* to an enclosing scope's
> name by an "un-punctuated" name, "var" is a synonym to ".var" (if
> "var" is bound in the immediately enclosing scope). However for
> *re-binding* to an enclosing scope's
On 2/25/06, Almann T. Goo <[EMAIL PROTECTED]> wrote:
> On 2/23/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 2/22/06, Almann T. Goo <[EMAIL PROTECTED]> wrote:
> > > def incrementer_getter(val):
> > >def incrementer():
>
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. s
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
> >
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.
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, here's the summary for the second half of February. Again,
comments and corrections are greatly appreciated! (And thanks to
those who already gave me some for the last summary.)
=
Announcements
=
---
Python release schedule
---
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 webaliz
The "make" 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
On 4/13/06, Travis Oliphant <[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
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
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 __meta*cla
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
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 th
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 sa
On 4/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> >make :
> >
>
> I don't like the position of the name being defined.
> It should be straight after the opening keyword, as
> with 'def' and 'class
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 pytho
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 definitio
e='second') as h1:
h1.text = 'second h1'
h1.tail = 'after second h1'
And if the repetition of the element names here is too much of a DRY
violoation, it is also possible to eliminate all as-clauses except
for the first by adding a few methods to Element. [9]_
So a
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 explici
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 5/7/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> I do know enough about Python to know that the make_person function is
> a really bad example.
Totally agreed. I've been ignoring most of that discussion because it
seemed really irrelevant.
> would be nice to instead see some real examples
On 5/7/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > Braces can be escaped using a backslash:
> >
> > "My name is {0} :-\{\}".format('Fred')
> >
> > Which would produce:
> >
> > "My name is Fred :-{}"
>
> Do backslashes also need to be backslashed then?
On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
> I've updated PEP 3101 based on the feedback collected so far.
[snip]
> Compound names are a sequence of simple names seperated by
> periods:
>
> "My name is {0.name} :-\{\}".format(dict(name='Fred'))
>
> Compound names can be use
On 5/21/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum:
> > This was proposed and rejected before.
>
> I haven't seen this proposed before (at least not in PEP form, or with a
> working implementation against the current trunk, or just in some f
On 5/26/06, Facundo Batista <[EMAIL PROTECTED]> wrote:
> All this different ways enforce my vote: we should get an error...
Perhaps you missed Tim's post, so here's a few lines of my own code
that I know would break:
padding = [None] * (self.width - len(leaves))
left_padding = [None]
Sorry I'm so far behind -- I'm aiming to get mostly caught up this
week. Please read through the summary if you have the time and send
me any comments or corrections.
Thanks!
=
Announcements
=
---
Python 2.5 schedule
---
Python 2.5 is mo
``ir`` prefixes, and it would
have forced some rewriting of the tools that currently do string
extraction using ``_()``, so the idea was rejected.
Contributing thread:
- `The "i" string-prefix: I18n'ed strings
<http://mail.python.org/pipermail/python-dev/2006-April/063488.ht
On 5/29/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
> >> .. _contributor agreement:
> >> http://www.python.org/psf/contrib-form-python.html
> >
> > By itself, this link is inadequate since there is a blank for 'Initial
> > License' with no choices indicated. So the summary nee
[Steven Bethard]
> I think that having a package level that exactly matches the divisions
> in the Library Reference (http://docs.python.org/lib/lib.html) would
> be great.
[Brett Cannon]
> Makes sense to me.
>
[snip]
> > 5. Miscellaneous Services
>
> I don't
Ok, here's the summary for the second half of April. My brain is numb
from the setuptools ane PEP 343 discussions, so please have a look
over it and see what I messed up. ;-)
As always, if you have any corrections or comments, please let me know.
=
Announcements
=
-
Ok, here's the frist half or May. I'd almost feel like I was catching
up if there wasn't going to be another summary waiting for me in two
days. ;-)
As always, please look it over and let me know if you have any
corrections/comments.
Thanks!
=
Announcements
=
-
Ok, for the first time in a few months, you're getting this summary
before the next one is due. Woo-hoo! (Yes, I know I'm not even a day
ahead. Let me enjoy my temporary victory.) =)
Here's the draft summary for the second half of May. Let me know what
comments/corrections you have. Thanks!
[delurking in response to the first really decisive message in the thread] ;-)
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition.
FWIW, +1.
Here's the summary for the first half of June. Thanks in advance for
your comments and corrections!
=
Announcements
=
---
Python 2.5 schedule
---
Python 2.5 is moving steadily towards its next release. See `PEP
356`_ for more details and
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
--
T
On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> print """Usage: dostuff
>
> Options:
> -c - blah blah
> -f - do stuff with file "filename"
> -s - more blah"""
Isn't the standard idiom for this already:
import textwrap
...
print textwrap.dedent("""\
Usage: dos
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)
--
Mar
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.
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
Martin v. Löwis wrote:
> So I would propose the syntax
>
> lst.sort(key=virtual.lower) # where virtual is functional.virtual
Shane Hathaway wrote:
> class virtual:
> def __getattr__(self, name):
> return lambda obj: getattr(obj, name)()
> virtual = virtual()
I think (perhaps beca
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:
&
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 ex
[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 behavi
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 t
[EMAIL PROTECTED] wrote:
> I don't find either the trailing comma or >> redirection ugly. If I have a
> long print line that's hard to read because it extends past column 80 (the
> print statement, not the output), it's easy to hit NL at an intermediate
> comma, then just type "print ", perhaps fo
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 newlin
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> 'f
[EMAIL PROTECTED] wrote:
> the print statement is more convenient. Maybe a print builtin wouldn't kill
> me. In that case I'd want both output redirection and newline suppression
> though. I guess you'd have to use a keyword arg to specify an alternate
> stream. Perhaps if the last non-keyword
[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.
Paul Moore wrote:
> On 9/2/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> [...]
> > Since
> > the print function seems to be intended mainly for newbies and simple
> > debugging,
>
> I think there have been quite a few comments here from people who
>
Paul Moore wrote:
> Interestingly enough, the other languages I use most (C, Java,
> VB(Script) and Javascript (under Windows Scripting Host)) all use
> functions for output. Except for C, I uniformly dislike the resulting
> code - the output structure gets hopelessly lost under the weight of
> str
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 b
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
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 th
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 statemen
[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.
[Fredr
Brett Cannon wrote:
> Is anyone truly attached to nested tuple function parameters; ``def
> fxn((a,b)): print a,b``?
I find 54 instances in my Python installation.
>grep -r "def.*([^=]*([^)]*,[^)]*).*):" *
aifc.py:def setparams(self, (nchannels, sampwidth, framerate,
nframes, comptype, compna
Sokolov Yura wrote:
> Would it be usefull to define new magic class variable __mixins__ for a
> new style classes, which
> will accept list of classes and will drop all members of them into
> definition of class before they went to metaclass.
First off, this is probably more appropriate for comp.l
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
> shou
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.
--- Buc
Guido van Rossum wrote:
> I think I'd prefer (if then else ) 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 -- remove t
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 selec
Jim Fulton wrote:
> A common use of read descriptors is for lazily computed data:
>
>class readproperty(object):
>"Create a read descriptor from a function"
>
>def __init__(self, func):
>self.func = func
>
>def __get__(self, inst, class_):
>if ins
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 internall
201 - 300 of 320 matches
Mail list logo
