Hello Chaps,
The attached PEP (pep.txt) is for RFE 46738, which you can view here:
http://sourceforge.net/tracker/index.php?func=detail&aid=467384&group_id=5470&atid=355470
It provides a safe, documented class for serialization of simple python types.
A sample implementation is also attached (g
[Joachim Koenig-Baltes]
> > My use case for this is a directory tree walking generator that
> > yields all the files including the directories in a depth first
manner.
> > If a directory satisfies a condition (determined by the caller) the
> > generator shall not descend into it.
> >
> > Something
On Fri, 2005-06-17 at 13:53, Joachim Koenig-Baltes wrote:
[...]
> My use case for this is a directory tree walking generator that
> yields all the files including the directories in a depth first manner.
> If a directory satisfies a condition (determined by the caller) the
> generator shall not des
Guido van Rossum wrote:
>
>However, I can see other uses for looping over a sequence using a
>generator and telling the generator something interesting about each
>of the sequence's items, e.g. whether they are green, or should be
>printed, or which dollar value they represent if any (to make up a
At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote:
>I do like "continue EXPR" but I have to admit I haven't even tried to
>come up with examples -- it may be unnecessary. As Phillip says, yield
>expressions and g.next(EXPR) are the core -- and also incidentally
>look like they will cause the most
Guido van Rossum wrote:
>>Recommend accepting just the basic PEP which only targets simple,
>>obvious cases. The discussed extensions are unattractive and should be
>>skipped.
>
>
> -1. The "unary colon" looks unPythonic to me.
>
Step 1 would be to require parentheses around the whole thing (a
Guido van Rossum wrote:
> On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>IIRC, there was a decision to not implement phase C and to keep the
>>trailing L in representations of long integers.
> For 2.x, yes. I'm fine with marking it as Final and adding this to PEP
> 3000 instead.
Since
On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> IIRC, there was a decision to not implement phase C and to keep the
> trailing L in representations of long integers.
Actually, the PEP says phase C will be implemented in Python 3.0 and
that's still my plan.
> If so, I believe the PEP ca
IIRC, there was a decision to not implement phase C and to keep the
trailing L in representations of long integers.
If so, I believe the PEP can be marked as final. We've done all we're
going to do.
Raymond
___
Python-Dev mailing list
Python-Dev@pyth
[Raymond Hettinger]
> This PEP is an excellent example of improving readability and usability
> by omitting a keyword and simplifying syntax. It neither provides nor
> takes away functionality; instead, it is a bit of a beautification
> effort.
>
> Essentially it creates a lighter-weight, more us
This PEP is an excellent example of improving readability and usability
by omitting a keyword and simplifying syntax. It neither provides nor
takes away functionality; instead, it is a bit of a beautification
effort.
Essentially it creates a lighter-weight, more usable syntax for
specifying defer
Michael Hudson wrote:
> I've been looking at this area partly to try and understand this bug:
>
> [ 1163563 ] Sub threads execute in restricted mode
>
> but I'm not sure the whole idea of multiple interpreters isn't
> inherently doomed :-/
That's what Tim asserts, saying that people who want
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> There may still be a use for a rational module in the standard library,
> but builtin support is no longer needed or desirable.
Sounds good.
> The rational proposal also has an intrinsic weakness shared with Java's
> prior versions of BigDecimal w
Agreed. Rational arithmetic was the default "exact" arithmetic in ABC
and it did not work out as expected.
On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> These PEPs are four years old. Nothing is intrinsically wrong with them,
> but they have garnered little enthusiasm, discussion
Sounds great! If Moshe doesn't respond within a reasonable time, you
can take it over by default IMO.
On 6/17/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> Just a note, sparked by Raymond's recent work cleaning up old PEPs:
> I'd like to take over PEP 206, the "Batteries Included" PEP, and
> rewr
About PEP 303, I use divmod for lots (and lots) of things, but I've
got no real use for an extended divmod() either. -1: it would be
low-use, confusing clutter.
[Barry]
> Interesting. Just yesterday I wrote a simple stopwatch-like timer
> script and I found that I needed three divmod calls to c
[Raymond Hettinger]
> After nine months, no support has grown beyond the original poster.
Never will, either -- even Roman numeral literals are more Pythonic
than this one.
More Pythonic: make integers callable: i(arglist) returns the i'th
argument. So, e.g., people who find it inconvenient to
Yes please. That one will never get past me as long as I'm alive.
(At PyCon I met one person who proposed an even more radical approach;
I think he wanted getattr(None, ) to return None. But he was
certified insane. :-)
On 6/17/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-06-17 at 0
Raymond Hettinger wrote:
>>Plus, it fails the "not every 3-line function has to be a builtin"
>>guideline:
>
>
> Not to pick, but I hope this doesn't become a recurring refrain. That
> isn't a real guideline, it's more of a snipe. It also runs counter to
> Zen about proposals not being complex
At 11:29 AM 6/17/2005 +0100, Gustavo J. A. M. Carneiro wrote:
> In conjunction with pseudo-threads, I think a "python main loop"
>implementation is fundamental. Such main loop with permit the programmer
>to register callbacks for events, such as timeouts, IO conditions, idle
>tasks, etc., such a
+M to reject.
On 6/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> While the majority of Python users deem this to be a nice-to-have
> feature, the community has been unable to reach a consensus on the
> proper syntax after more than two years of intensive debate (the PEP was
> introduced in
[Raymond Hettinger]
>> While the majority of Python users deem this to be a nice-to-have
>> feature
[Barry Warsaw]
> Really? Where's the supporting poll data?
We've run IV polls since this PEP was introduced, and the geometric
mean of those shows LXVIII% of Python users strongly in favor (+I),
a
On Fri, 2005-06-17 at 05:57, Raymond Hettinger wrote:
> This PEP has been open for two and half years without generating
> discussion or support.
Interesting. Just yesterday I wrote a simple stopwatch-like timer
script and I found that I needed three divmod calls to convert from
seconds into a da
On Fri, 2005-06-17 at 02:55, Raymond Hettinger wrote:
> After nine months, no support has grown beyond the original poster. The
> PEP did however generate some negative responses when brought-up on
> comp.lang.python (it made some people's stomach churn).
>
> The PEP fails the tests of obviousnes
On Fri, 2005-06-17 at 00:43, Raymond Hettinger wrote:
> Let me go on record as a strong -1 for "continue EXPR". The for-loop is
> our most basic construct and is easily understood in its present form.
> The same can be said for "continue" and "break" which have the added
> advantage of a near zer
On Fri, 2005-06-17 at 02:39, Raymond Hettinger wrote:
> While the majority of Python users deem this to be a nice-to-have
> feature
Really? Where's the supporting poll data? In over 10 years of Python
programming, I've never once needed a Roman number literal. Worse, I
don't buy the compatibili
Just a note, sparked by Raymond's recent work cleaning up old PEPs:
I'd like to take over PEP 206, the "Batteries Included" PEP, and
rewrite it to describe a "Python Advanced Library", a set of
third-party packages to complement the standard library.
I've written to Moshe, the original author, to
Skip> http://python.org/sf/677103
Thomas> There's no patch attached.
*sigh*
Thanks for noticing the problem. Apparently, since I last updated the
patch, SF implemented a 250kbyte limit on file uploads. This one is big
because it includes a suitably modified configure script that was ge
Raymond Hettinger wrote:
> Executive summary: cute, but unpersuasive and unnecessary, not worth
> the time to code, test, document, maintain, and explain.
Plus, it fails the "not every 3-line function has to be a builtin"
guideline:
def extended_divmod(numerator, *denominators):
remainde
Hello,
I found your paper very interesting. I have also written a very
minimalistic white paper, mostly aimed at the PyGTK community, with a
small module for pseudo-threads using python generators:
http://www.gnome.org/~gjc/gtasklet/gtasklets.html
I don't have time to follow this
This PEP has been open for two and half years without generating
discussion or support.
Its primary case (converting cumulative seconds into a tuple days,
hours, minutes, and seconds) is a bit wanting because it doesn't
generalize to months and years. That need is already met in a more
robust and
At 08:24 PM 6/16/2005 -0400, Raymond Hettinger wrote:
> As a further benefit, using
>attributes was a natural approach because that same technique has long
>been used with classes (so no new syntax was needed and the learning
>curve was zero).
On Friday 17 Jun 2005 02:53, Phillip J. Eby wrote:
> U
These PEPs are four years old. Nothing is intrinsically wrong with them, but they have garnered little enthusiasm, discussion, or support, suggesting that the original need was somewhat modest. In addition, the principal (but not only) use cases for a builtin rational type and corresponding
33 matches
Mail list logo
