[Python-Dev] Propose rejection of PEPs 239 and 240 -- a builtin rational type and rational literals
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 rational literal have already been addressed by the decimal module (and the expected future integration of decimal literals). From rationale section of the PEPs: “””Rational numbers are useful for exact and unsurprising arithmetic. They give the correct results people have been taught in various math classes. Making the "obvious" non-integer type one with more predictable semantics will surprise new programmers less than using floating point numbers. As quite a few posts on c.l.py and on tutor@python.org have shown, people often get bit by strange semantics of floating point numbers: for example, round(0.98, 2) still gives 0.97998.“”” The future direction of the decimal module likely entails literals in the form of 123.45d with binary floats continuing to have the form 123.45. This conflicts with the rational literal proposal of having 123.45 interpreted as 123 + 45/100. There may still be a use for a rational module in the standard library, but builtin support is no longer needed or desirable. The PEPs also touch on division ambiguities which were largely resolved by the acceptance of PEP 238 which introduced the floor division operator and from __future__ import division. The rational proposal also has an intrinsic weakness shared with Java’s prior versions of BigDecimal which they found to be unworkable in practice. The weakness was that repeated operations caused the internal number of digits to grow beyond reason. For this reason, the PEP proposes some arbitrary level of truncation which conflicts with the goals of having “obvious and exact” arithmetic. The proposed truncation methodology was undeveloped and made no proposal for the same fine level of control as its counterpart in the decimal module where issues of variable precision, multiple contexts, and alternate rounding modes have been fully thought out. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
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:
> Ugh. Having actually emulated co-routines using generators, I have to tell
> you that I don't find generator attributes natural for this at all;
> returning a value or error (via PEP 343's throw()) from a yield expression
> as in PEP 342 is just what I've been wanting.
We've been essentially emulating co-routines using generators embedded
into a class to give us the equivalent of generator attributes. We've found
this very natural for system composition. (Essentially it's a CSP type system,
though with an aim of ease of use)
I've written up my talk from ACCU/Python UK this year, and it's available
here: http://www.bbc.co.uk/rd/pubs/whp/whp113.shtml
I'll also be talking about it at Europython later this month.
At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote:
>Someone should really come up with some realistic coroutine examples
>written using PEP 342 (with or without "continue EXPR").
On Friday 17 Jun 2005 05:07:22, Phillip J. Eby wrote:
> How's this?
>
>def echo(sock):
>while True:
>try:
>data = yield nonblocking_read(sock)
>yield nonblocking_write(sock, data)
... snip ...
For comparison, our version of this would be:
from Axon.Component import component
from Kamaelia.SimpleServerComponent import SimpleServer
class Echo(component):
def mainBody(self):
while True:
if self.dataReady("inbox"):
self.send(data,"outbox")
yield1
SimpleServer(protocol=EchoProtocol, port=1501).run()
For more interesting pipelines we have:
pipeline(TCPClient("127.0.0.1",1500),
VorbisDecode(),
AOAudioPlaybackAdaptor()
).run()
Which works in the same way as a Unix pipeline. I haven't written the
"pipegraph" or similar component yet that could allow this:
graph(A=SingleServer("0.0.0.0", 1500),
B=Echo(),
layout = { "A:outbox": "B:inbox", "B:outbox" : "A:inbox" } )
(Still undecided on API for that really, currently the above is a lot more
verbose -)
By contrast I really can't see how passing attributes in via .next() helps
this approach in any way (Not that that's a problem for us :).
I CAN see though it helps if you're taking the approach for generator
composition if you're using twisted.flow (though I'll defer a good example
for that to someone else since although I've been asked for a comparison in
the past, I don't think I'm sufficiently twisted to do so!).
Michael.
--
Michael Sparks, Senior R&D Engineer, Digital Media Group
[EMAIL PROTECTED], http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP
This e-mail may contain personal views which are not the views of the BBC.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
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 flexible way by date and time specific modules. The use case is also somewhat unique. Recalling 25 years of programming, almost every real case of repeated divmod() calls have been in a loop with a single constant denominator (i.e. dividing by a base in a radix conversion). The PEP does suggest other applications but they are all narrow offerings (gallon/quart/pint/ounce, miles/yards/feet, pound/shilling/pence) that are extremely rare in real apps. More importantly, the gain in succinctness is offset by a loss of clarity. Consider: dist, inches = divmod(dist, 12) yards, feet = divmod(dist, 3) versus a proposed: yards, feet, inches = divmod(dist, 3, 12) The latter form makes it difficult to visually confirm the correct number of target variables. Likewise, it is not at all obvious that the order of the 3 and 12 are correct. Users from other languages will tend to automatically understand the current form and be mystified by the second (especially given how infrequently it will arise). The PEP draws its inspiration from an APL operator. APL imbues many of its operators with scalar/scalar, scalar/array, and array/array capabilities. But in Python (not numeric) we tend to leave the operators in simple form and abstract the vectorization into operator independent primitives (i.e. map and reduce). Mathematica takes a similar approach by offering functions like NestList(). So, instead of a vectorized divmod(), it is wiser for someone to post a single accumulation recipe that would work with a variety of binary operators. Executive summary: cute, but unpersuasive and unnecessary, not worth the time to code, test, document, maintain, and explain. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
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 whole discussion, but I leave it here
as another example of python pseudo-threads. I also am very much in
favour of having yield receive return values or exceptions, as this
would make pseudo-threads much more elegant. And I very much wish
python had this builtin or in std library.
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 as one found glib (gtk+'s underlying library). I
already pointed out one such implementation that I use for one of my
projects, and it already has unit tests to prove that it works.
This is also related to the "deprecate asyncore/asynchat" discussions
going on earlier. IMHO, they should really be deprecated, and a
pseudo-threads solution could be used instead.
Anyway, I'd love to help more in this area, but unfortunately I don't
have time for these endless discussions... :P
Best regards.
On Fri, 2005-06-17 at 10:12 +0100, Michael Sparks wrote:
> 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:
> > Ugh. Having actually emulated co-routines using generators, I have to tell
> > you that I don't find generator attributes natural for this at all;
> > returning a value or error (via PEP 343's throw()) from a yield expression
> > as in PEP 342 is just what I've been wanting.
>
> We've been essentially emulating co-routines using generators embedded
> into a class to give us the equivalent of generator attributes. We've found
> this very natural for system composition. (Essentially it's a CSP type
> system,
> though with an aim of ease of use)
>
> I've written up my talk from ACCU/Python UK this year, and it's available
> here: http://www.bbc.co.uk/rd/pubs/whp/whp113.shtml
>
> I'll also be talking about it at Europython later this month.
>
> At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote:
> >Someone should really come up with some realistic coroutine examples
> >written using PEP 342 (with or without "continue EXPR").
>
> On Friday 17 Jun 2005 05:07:22, Phillip J. Eby wrote:
> > How's this?
> >
> >def echo(sock):
> >while True:
> >try:
> >data = yield nonblocking_read(sock)
> >yield nonblocking_write(sock, data)
> ... snip ...
>
> For comparison, our version of this would be:
>
> from Axon.Component import component
> from Kamaelia.SimpleServerComponent import SimpleServer
> class Echo(component):
>def mainBody(self):
> while True:
> if self.dataReady("inbox"):
> self.send(data,"outbox")
> yield1
>
> SimpleServer(protocol=EchoProtocol, port=1501).run()
>
>
> For more interesting pipelines we have:
>
> pipeline(TCPClient("127.0.0.1",1500),
> VorbisDecode(),
> AOAudioPlaybackAdaptor()
> ).run()
>
> Which works in the same way as a Unix pipeline. I haven't written the
> "pipegraph" or similar component yet that could allow this:
>
> graph(A=SingleServer("0.0.0.0", 1500),
>B=Echo(),
>layout = { "A:outbox": "B:inbox", "B:outbox" : "A:inbox" } )
>
> (Still undecided on API for that really, currently the above is a lot more
> verbose -)
>
> By contrast I really can't see how passing attributes in via .next() helps
> this approach in any way (Not that that's a problem for us :).
>
> I CAN see though it helps if you're taking the approach for generator
> composition if you're using twisted.flow (though I'll defer a good example
> for that to someone else since although I've been asked for a comparison in
> the past, I don't think I'm sufficiently twisted to do so!).
>
>
> Michael.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
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): remainders = [] for denominator in reversed(denominators): numerator, remainder = divmod(numerator, denominator) remainders.insert(0, remainder) return tuple(remainders) OK, 5 lines. Anyway, not very hard to write for anyone with a genuine use case - and, like you, I've never used divmod for anything other than extracting digits (or groups of digits) from numbers. I also don't buy the 'tedious and easy to get wrong each time you need it' justification in the PEP. Getting the argument order to the extended divmod wrong seems to be even easier. For each of the cited use cases, a well-named function, or a proper class seems like a much cleaner solution. e.g. class Declination(object): def __init__(self, value): try: # Copy a duck-typed declination self.degrees = value.degrees self.minutes = value.minutes self.seconds = value.seconds except AttributeError: try: # Allow any three-value sequence self.degrees, self.minutes, self.seconds = value except TypeError: # Divide a number value, self.seconds = divmod(value, 60) value, self.minutes = divmod(value, 60) value, self.degrees = divmod(value, 360) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 304 "Controlling Generation of Bytecode Files" - patch updated
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 generated with a slightly different version of autoconf than what's in the current Python distro so people don't need to have autoconf installed to work with the patch. I've attached a gzipped version of the patch (bcb.diffs.gz). Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Request to rewrite PEP 206
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 check that this is OK with him, and am waiting for a response. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 313 -- Adding Roman Numeral Literals to Python
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 compatibility argument. I'm as anal as anyone about PEP 8 style, but that's still no reason to break code like >>> MIX = True I wouldn't be opposed to a library that provided a function to convert to and from Romans but I don't think Python needs Roman numeral literal support. +1 for rejecting. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
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 zero learning curve for people migrating from other > languages. > > Any urge to complicate these basic statements should be seriously > scrutinized and held to high standards of clarity, explainability, > obviousness, usefulness, and necessity. IMO, it fails most of those > tests. > > I would not look forward to explaining "continue EXPR" in the tutorial > and think it would stand out as an anti-feature. I'm sympathetic to this argument. I also find yield expressions jarring. I don't have any better suggestions though. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 336 -- Make None Callable
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 obviousness and necessity. I agree. The fact that None is not callable is a /feature/ IMO. +1 for rejecting this PEP. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
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 datetime.time object. This PEP might have come in handy there, but OTOH, I'm not so sure that's enough justification to accept the PEP. > 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 flexible way by date and time specific modules. Actually, no, because datetime.time(seconds=50227) throws an exception. But in my specific case, I didn't find the need for three divmod calls nearly as frustrating as the lack of a datetime.time.fromseconds() call. > More importantly, the gain in succinctness is offset by a loss of > clarity. Consider: > >dist, inches = divmod(dist, 12) >yards, feet = divmod(dist, 3) > > versus a proposed: > >yards, feet, inches = divmod(dist, 3, 12) > > The latter form makes it difficult to visually confirm the correct > number of target variables. Likewise, it is not at all obvious that the > order of the 3 and 12 are correct. I agree. My three divmod solution is perfectly readable and simple to write. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 313 -- Adding Roman Numeral Literals to Python
[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), and an additional XXI% not opposed (+roman(0), really -- I'm not sure how to spell zero in Roman numerals, but trust that the new `roman()` builtin will handle it correctly). > In over 10 years of Python programming, I've never once needed a Roman > number literal. Who cares what someone still stuck on Python Challenge #XVII thinks? Input from real Python programmers would be appreciated, though. For example, I'm eager to switch ZODB's object ids to Roman numerals. For example, as Raymond acknowledged, that would make it much easier to produce ZODB PowerPoint slides. > Worse, I don't buy the compatibility argument. I'm as anal as anyone about > PEP 8 style, but that's still no reason to break code like > > >>> MIX = True And you care nothing for the possibility that an ancient Roman explorer found frozen in the Arctic may be revived, and find such code incomprehensibly obscure? Python should be for everyone, not just the living. BTW, you might want to reread Raymond's post -- he was having an indecently good time at, well, someone's expense . ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 313 -- Adding Roman Numeral Literals to Python
+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 early April 2003). > > Most agree that there should be only-one-way-to-do-it; however, the > proponents are evenly split into two camps, with the modernists > preferring IX for nine and the classicists preferring V which was > the most likely spelling in ancient Rome. > > The classicists not only rely on set-in-stone tradition, they point to > pragmatic issues such as avoidance of subtraction, ease of coding, > easier mental parsing (much less error prone), and ease of teaching to > beginners. They assert that the modernists have introduced unnecessary > algorithmic complexity just to save two keystrokes. > > The modernists point to compatible Java implementations and current > grade school textbooks. They believe that users from other languages > will expect the IX form. Note however, not all the modernists agree on > whether MXM would be a well-formed spelling of 1990; most, but not all > prefer MCMXC despite its likelihood of being mis-parsed on a first > reading. > > There is also a small but vocal user group demanding that lowercase > forms be allowed. Their use cases fall into four categories: (i) > academia, (ii) the legal profession, (iii) research paper writing, and > (iv) powerpoint slideshows. Reportedly, this is also a common > convention among Perl programmers. > > Links: > > http://hrsbstaff.ednet.ns.ca/waymac/History%20A/A%20Term%201/1.%20Rome/R > oman_Numerals.htm > http://www.sizes.com/numbers/roman_numerals.htm > > > Raymond > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
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 as one found glib (gtk+'s underlying library). I >already pointed out one such implementation that I use for one of my >projects, and it already has unit tests to prove that it works. I think it's important to point out that such a "main loop" needs to be defined as an interface, rather than an implementation, because there are many such "main loops" out there as far as GTK, wx, OS X, etc. that have different implementation details as to how timeouts and I/O have to be managed. Since I see from your web page that you've looked at peak.events, I would refer you to the IEventLoop interface as an example of such an interface; any Twisted reactor can be adapted to provide most of the IEventLoop features (and vice versa) which means an interface like it should be usable on a variety of platforms. Of course, I also think that before proposing an event loop facility for the stdlib, we should actually succeed in implementing next(arg), yield expressions, and throw(). I'll probably take a look at next()/throw() this weekend to see if there's anything I can contribute to the ceval.c part; I'm a bit less likely to be able to help on the compilation side of things, though. (Apart from maybe adding a POP_TOP after existing yield statements.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
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 and being easy to explain. I guess I really mean "the use case is obscure enough that simply writing the 5-line function is better than cluttering the API of a builtin", but that doesn't have quite the same ring to it ;) > There > are tons of exceptions. Guido's new any() and all() replace only a > single line. The sorted() builtin was very successful and it only > replaced a couple of lines. The key= argument is also successful but > replaces a simple, three-line Schwarzian transform. Reading DictMixin > shows that most dictionary methods are trivially expressed in terms of a > few primitives; however, we've learned that the mapping API is > excellent, expressive, and useful (except for setdefault which I've > grown to hate ;-). IOW, the quip is food for thought but not > necessarily either a positive or negative point about a proposal. That's basically what I meant - and what I take the phrase to mean when someone else uses it. If something is simple to write, but the use case is obscure, then that's an argument *against* making it a builtin, since half the time you'll have the function written before you remember there's a builtin for it. On the other hand, if the use case is common enough, rewriting it every time you need it is just a pain. The 'not every . . .' comment just tries to say all that using only ten words. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 336 -- Make None Callable
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 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 obviousness and necessity. > > I agree. The fact that None is not callable is a /feature/ IMO. +1 for > rejecting this PEP. > > -Barry > > > > BodyID:129997985.2.n.logpart (stored separately) > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose to reject PEP 336 -- Make None Callable
[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 index a list like this: x[i] could index it like this instead: i(*x) Punchline: I didn't make this up -- that's how integers work in Icon! Kinda. y := 2 y(x, y, z) := 3 also works to bind `y` to 3. Python is falling _way_ behind . ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
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 convert from > seconds into a datetime.time object. You don't need any divmods for that ... ... > Actually, no, because datetime.time(seconds=50227) throws an exception. That's right: the time class models a time of day, not "seconds from Barry's implied midnight epoch" (or something like that). What you wanted was a timedelta instead. Converting that to a time is then simplicity itself : >>> print (datetime(1, 1, 1) + timedelta(seconds=50227)).time() 13:57:07 You have to go thru a datetime object first because time objects don't support arithmetic either. That isn't all bad. By going thru a datetime first, it's clear what happens if the number of seconds you feed in exceeds a day's worth. You can check for that or ignore it then, depending on what your app wants (it may or may not be "an error", depending on the app). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request to rewrite PEP 206
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 > 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 check that this is OK > with him, and am waiting for a response. > > --amk > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEPs 239 and 240 -- a builtin rational type and rational literals
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, 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 rational literal have already been addressed by the > decimal module (and the expected future integration of decimal literals). > From rationale section of the PEPs: > > """ > Rational numbers are useful for exact and unsurprising arithmetic. They > give the correct results people have been taught in various math classes. > Making the "obvious" non-integer type one with more predictable semantics > will surprise new programmers less than using floating point numbers. As > quite a few posts on c.l.py and on tutor@python.org have shown, people often > get bit by strange semantics of floating point numbers: for example, > round(0.98, 2) still gives 0.97998. > """ > > The future direction of the decimal module likely entails literals in the > form of 123.45d with binary floats continuing to have the form 123.45. This > conflicts with the rational literal proposal of having 123.45 interpreted as > 123 + 45/100. > > There may still be a use for a rational module in the standard library, but > builtin support is no longer needed or desirable. > > The PEPs also touch on division ambiguities which were largely resolved by > the acceptance of PEP 238 which introduced the floor division operator and > from __future__ import division. > > The rational proposal also has an intrinsic weakness shared with Java's > prior versions of BigDecimal which they found to be unworkable in practice. > The weakness was that repeated operations caused the internal number of > digits to grow beyond reason. For this reason, the PEP proposes some > arbitrary level of truncation which conflicts with the goals of having > "obvious and exact" arithmetic. The proposed truncation methodology was > undeveloped and made no proposal for the same fine level of control as its > counterpart in the decimal module where issues of variable precision, > multiple contexts, and alternate rounding modes have been fully thought out. > > > > Raymond > > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Propose rejection of PEPs 239 and 240 -- a builtin rational type and rational literals
"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 which they found to be unworkable in > practice. The weakness was that repeated operations caused the internal > number of digits to grow beyond reason. For this reason, the PEP > proposes some arbitrary level of truncation which conflicts with the > goals of having "obvious and exact" arithmetic. The proposed truncation > methodology was undeveloped and made no proposal for the same fine level > of control as its counterpart in the decimal module where issues of > variable precision, multiple contexts, and alternate rounding modes have > been fully thought out. Here is an option: exploit all of the thought and effort that has gone into decimals. Offer a "context" argument which handles the precision and rounding of the rational numerator and denominator as necessary, defaulting to the current decimal context, with automatic rounding (using the same kinds of semantics that decimals currently uses). Offer a mechanism by which one can use exact rationals, which use longs rather than decimals. The idea obviously needs fleshing out, but perhaps it is a start for someone who wants rationals in the standard library. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] refcounting vs PyModule_AddObject
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 to use the feature should fix it themselves. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
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 deferred function arguments. Like decorators, this helps out programmers who understand and use this technique, and it is harmless and invisible for the rest. It is especially handy in the absence of an if-then-else expression. The PEP is backwards compatible. Recommend accepting just the basic PEP which only targets simple, obvious cases. The discussed extensions are unattractive and should be skipped. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
[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 usable syntax for > specifying deferred function arguments. Like decorators, this helps out > programmers who understand and use this technique, and it is harmless > and invisible for the rest. It is especially handy in the absence of an > if-then-else expression. The PEP is backwards compatible. > > 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
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 can be marked as final. We've done all we're > going to do. For 2.x, yes. I'm fine with marking it as Final and adding this to PEP 3000 instead. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
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 PEP 313 has been rejected, the trailing L no longer introduces ambiguity in the representation of roman(40) vs. roman(10L). --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recommend accepting PEP 312 -- Simple Implicit Lambda
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 (ala generator expressions) to make it easier to see where the deferred expression ends. But all my use cases that I can think off the top of my head involve 'sorted', where it wouldn't help at all because of the need for an argument. So I'd rather see a serious discussion regarding giving lambdas a more Pythonic syntax in general, rather than one that only applied to the 'no-argument' case [1] Cheers, Nick. [1] http://wiki.python.org/moin/AlternateLambdaSyntax The 'expression-before-args' version using just the 'from' keyword is still my favourite. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Implementing PEP 342 (was Re: Withdrawn PEP 288 and thoughts on PEP 342)
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 implementation nightmares. (If >someone wants to start implementing these two now, go right ahead!) FYI, I've started work on a patch. I've got argument passing into generators working, and compiling of parenthesized yield expressions, in both the C and Python compilers (although the output of the compiler package isn't tested yet). I haven't implemented no-argument yields yet, either, or unparenthesized yields on the far RHS of an assignment. I do plan to implement throw() as part of the same patch. Much of what remains is expanding the test suite and writing documentation, though. It turns out that making 'next(EXPR)' work is a bit tricky; I was going to use METH_COEXIST and METH_VARARGS, but then it occurred to me that METH_VARARGS adds overhead to normal Python calls to 'next()', so I implemented a separate 'send(EXPR)' method instead, and left 'next()' a no-argument call. Whether this is the way it should really work or not is a PEP discussion, of course, but it does seem to me that making send(ob) and throw(typ,val,tb) separate methods from the iterator protocol is a reasonable thing to do. Anyway, the patch isn't ready yet, but I hope to be able to post something for review before the weekend is out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
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
>non-Boolean example).
>
>Anyway, "continue EXPR" was born as I was thinking of a way to do this
>kind of thing in Python, since I didn't want to give up return as a
>way of breaking out of a loop (or several!) and returning from a
>function.
>
>But I'm the first to admit that the use case is still very much
>hypothetical -- unlike that for g.next(EXPR) and VAR = yield.
>
>
>
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 like:
DONOTDESCEND=1
for path in mywalk("/usr/src"):
if os.path.isdir(path) and os.path.basename(path) == "CVS":
continue DONOTDESCEND
# do something with path
Of course there are different solutions to this problem with callbacks
or filters but i like this one as the most elegant.
Joachim
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
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 descend into it.
>
> Something like:
>
> DONOTDESCEND=1
> for path in mywalk("/usr/src"):
> if os.path.isdir(path) and os.path.basename(path) == "CVS":
> continue DONOTDESCEND
> # do something with path
>
> Of course there are different solutions to this problem with callbacks
> or filters but i like this one as the most elegant.
I have implemented almost exactly this use-case using the standard
Python generators, and shudder at the complexity something like this
would introduce.
For me, the right solution would be to either write your own generator
that "wraps" the other generator and filters it, or just make the
generator with additional (default value) parameters that support the
DONOTDECEND filtering.
FWIW, my usecase is a directory comparison generator that walks two
directorys producing tuples of corresponding files. It optionally will
not decend directories in either tree that do not have a corresponding
directory in the other tree. See;
http://minkirri.apana.org.au/~abo/projects/utils/
--
Donovan Baarda <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342
[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 like:
> >
> > DONOTDESCEND=1
> > for path in mywalk("/usr/src"):
> > if os.path.isdir(path) and os.path.basename(path) == "CVS":
> > continue DONOTDESCEND
> > # do something with path
> >
> > Of course there are different solutions to this problem with
callbacks
> > or filters but i like this one as the most elegant.
[Donovan Baarda]
> I have implemented almost exactly this use-case using the standard
> Python generators, and shudder at the complexity something like this
> would introduce.
>
> For me, the right solution would be to either write your own generator
> that "wraps" the other generator and filters it, or just make the
> generator with additional (default value) parameters that support the
> DONOTDECEND filtering.
>
> FWIW, my usecase is a directory comparison generator that walks two
> directorys producing tuples of corresponding files. It optionally will
> not decend directories in either tree that do not have a corresponding
> directory in the other tree. See;
>
> http://minkirri.apana.org.au/~abo/projects/utils/
Thank both of you for the excellent posts. This is exactly kind of
feedback and analysis that will show whether continue EXPR is worth it.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP for RFE 46738 (first draft)
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 (gherkin.py).
Critcism and comments on the PEP and the implementation are appreciated.
Simon Wittber.
PEP: XXX
Title: Serialization of Simple Python Types
Version: $Revision: $
Last-Modified: $Date: $
Author: Simon Wittber <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Python-Version: 2.4
Content-Type: text/plain
Created: 19-Jun-2005
Post-History:
Abstract
This PEP suggests the addition of a module to the standard library,
which provides a serialization class for simple Python types.
Copyright
This document is placed in the public domain.
Motivation
The standard library currently provides two modules which are used
for object serialization. Pickle is not secure by its very nature,
and the marshal module is clearly marked as being not secure in the
documentation. The marshal module does not guarantee compatibility
between Python versions. The proposed module will only serialize
simple built-in Python types, and provide compatibility across
Python versions.
See RFE 467384 (on SourceForge) for past discussions on the above
issues.
Specification
The proposed module should use the same API as the marshal module.
dump(value, file)
#serialize value, and write to open file object
load(file)
#read data from file object, unserialize and return an object
dumps(value)
#return the string that would be written to the file by dump
loads(value)
#unserialize and return object
Reference Implementation
Please see attached sencode.py
Rationale
An algorithm using a single encode function, in which an if/elif
structure is used, rather than a dict lookup by type, proved to
be slower than the algorithm used in the reference implementation.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:
from types import
IntType,TupleType,StringType,FloatType,LongType,ListType,DictType,NoneType,BooleanType,UnicodeType
from struct import pack, unpack
from cStringIO import StringIO
class EncodeError(Exception): pass
class DecodeError(Exception): pass
SIZEOF_INT = 4
SIZEOF_FLOAT = 8
UNICODE_CODEC = 'utf-8'
class Gherkin(object):
def __init__(self):
self.header = 'GHE'
self.version = 0
self.protocol = {
TupleType :"T",
ListType :"L",
DictType :"D",
LongType :"B",
IntType:"I",
FloatType :"F",
StringType :"S",
NoneType :"N",
BooleanType:"b",
UnicodeType:"U"
}
self.encoder = {}
self.decoder = {}
self.int_size = SIZEOF_INT
self.float_size = SIZEOF_FLOAT
self.encoder[DictType] = self.enc_dict_type
self.encoder[ListType] = self.enc_list_type
self.encoder[TupleType] = self.enc_list_type
self.encoder[IntType] = self.enc_int_type
self.encoder[FloatType] = self.enc_float_type
self.encoder[LongType] = self.enc_long_type
self.encoder[UnicodeType] = self.enc_unicode_type
self.encoder[StringType] = self.enc_string_type
self.encoder[NoneType] = self.enc_none_type
self.encoder[BooleanType] = self.enc_bool_type
self.decoder[self.protocol[TupleType]] = self.dec_tuple_type
self.decoder[self.protocol[ListType]] = self.dec_list_type
self.decoder[self.protocol[DictType]] = self.dec_dict_type
self.decoder[self.protocol[LongType]] = self.dec_long_type
self.decoder[self.protocol[StringType]] = self.dec_string_type
self.decoder[self.protocol[FloatType]] = self.dec_float_type
self.decoder[self.protocol[IntType]] = self.dec_int_type
self.decoder[self.protocol[NoneType]] = self.dec_none_type
self.decoder[self.protocol[BooleanType]] = self.dec_bool_type
self.decoder[self.protocol[UnicodeType]] = self.dec_unicode_type
def enc_dict_type(self, obj):
data = "".join([self.encoder[type(i)](i) for i in obj.items()])
return "%s%s%s" % (self.protocol[DictType], pack("!L", len(data)), data)
def enc_list_type(self, obj):
data = "".join([self.encoder[type(i)](i) for i in obj])
return "%s%s%s" % (self.protocol[type(obj)], pack("!L", len(data)),
data)
def enc_int_type(self, obj):
return "%s%s" % (self.protocol[IntType], pack("!i", obj))
def enc_float_type(self, obj):
return "%s%s" % (self.protocol[FloatType], pack("!d", obj))
def enc_long_type(self, obj):
obj = hex(obj)[2:-1]
return "%s%s%s" % (self.protocol[LongType], pack("
