I still don't have time to read this thread :-(, but I had a new idea that I'd like to fly here. If we want to support thunks that blend into the scope of their environment as well as thunks that introduce a new local scope, here's one possible way to do it: Thunk blending in: [<variable> =] <expression>: <block> Thunk introducing a new local scope: [<variable> =] <expression> lambda: <block> (Never mind the ugly things I've said about lambda in the past. :-) I'm confident that the parser can distinguish these, and I'm confident that the scope blending can be implemented using nested-scope cells. Adding formal parameters to the second case would go like this: [<variable> =] <expression> lambda <arguments>: <block> One concern I have in both cases: I think there are use cases for wanting more than one block. Glyph's example wants to define various callbacks for a remote call, and this would need multiple blocks. I think the syntax for this would have to use some kind of keyword-based continuation, e.g. [<variable> =] <expression> lambda: <block> and <expression> lambda: <block> ... Disclaimer: this is a half-baked idea. --Guido van Rossum (home page: http://www.python.org/~guido/)
What about my idea (I have another posting to python-dev probably unnoticed) code_thunk = ``` if Guido.let_it_fly(): print "This is my syntax for inline code block" ``` Any other operations (even adding parameters) - thru function application. Sincerely yours, Roman Suzi -- rnd@onego.ru =\= My AI powered by Linux RedHat 7.3
Roman Suzi <rnd@onego.ru>:
code_thunk = ``` if Guido.let_it_fly(): print "This is my syntax for inline code block" ```
-1, too ugly! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Roman Suzi wrote
What about my idea (I have another posting to python-dev probably unnoticed)
code_thunk = ``` if Guido.let_it_fly(): print "This is my syntax for inline code block" ```
Are these backticks/backquotes? If so, I'm -severalmillion on this. Backticks are a pain to distinguish from forwards ticks in too many fonts. Even Guido (in his 'python regrets' talk) dislikes them for the `foo` shorthand for repr(foo). Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
From: "Guido van Rossum" <guido@python.org>
I still don't have time to read this thread :-(, but I had a new idea that I'd like to fly here.
If we want to support thunks that blend into the scope of their environment as well as thunks that introduce a new local scope, here's one possible way to do it:
Thunk blending in:
[<variable> =] <expression>: <block>
Thunk introducing a new local scope:
[<variable> =] <expression> lambda: <block>
(Never mind the ugly things I've said about lambda in the past. :-)
I'm confident that the parser can distinguish these, and I'm confident that the scope blending can be implemented using nested-scope cells.
Adding formal parameters to the second case would go like this:
[<variable> =] <expression> lambda <arguments>: <block>
One concern I have in both cases: I think there are use cases for wanting more than one block. Glyph's example wants to define various callbacks for a remote call, and this would need multiple blocks. I think the syntax for this would have to use some kind of keyword-based continuation, e.g.
[<variable> =] <expression> lambda: <block> and <expression> lambda: <block> ...
Disclaimer: this is a half-baked idea.
Is lambda for generalizing 'class'?? It is worth to rember that 'class' has different scoping rules than def!
def c(): ... x = 1 ... class B: ... x=2 ... def f(self): ... return x ... return B() ... b=c() b.x 2 b.f() # not 2 1
On Mon, Feb 03, 2003 at 11:53:50AM -0500, Guido van Rossum wrote:
Thunk blending in:
[<variable> =] <expression>: <block>
Thunk introducing a new local scope:
[<variable> =] <expression> lambda: <block>
(Never mind the ugly things I've said about lambda in the past. :-)
I'm confident that the parser can distinguish these, and I'm confident that the scope blending can be implemented using nested-scope cells.
Why not treat the "blended" version as just another nested block, like for, if, while etc? Thinking in terms of "thunks" is useful if you intend to keep a reference to this code that can be executed after the function containing it has exited. Is there any reason to use a *blended* block for this purpose? A piece of code modifies local variables of a dead function? Just think how messy it's going to be if it modifies the locals of the function while it is still running. I think it's best not to have any reference to it or not make it an object at all. See my previous posting on how this type of "blended blocks" can be imlemented mostly by reusing the generator mechanisms. Using iterators for the "with" statement may be a little ugly, but it shows how this problem can be approached without thinking in thunks. The non-blended version seems more suitable for defining things like functions, classes, properties, widgets etc. I would prefer for it to have a syntax more similar to functions or classes - a syntax that binds exactly one name in the scope containing it and uses the form keyword-introducer NAME {other stuff}: suite rather than assignment. I think it will be a good cue to the fact that these blocks are definitions with their own scope, not control flow structures that blend into their surroundings.
Adding formal parameters to the second case would go like this:
[<variable> =] <expression> lambda <arguments>: <block>
If a non-blended block wants to define multiple entry points it can just use functions, like methods in a class. This requires that this block be executed immediately and the resulting dictionary stored for later use. I think the remembering the convention for naming the functions in this block is preferred to this mixed syntax. thunk-you-very-much, Oren
Guido:
If we want to support thunks that blend into the scope of their environment as well as thunks that introduce a new local scope, here's one possible way to do it:
Do we actually want both kinds of thunk? Why, exactly? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
From: "Greg Ewing" <greg@cosc.canterbury.ac.nz>
Guido:
If we want to support thunks that blend into the scope of their environment as well as thunks that introduce a new local scope, here's one possible way to do it:
Do we actually want both kinds of thunk? Why, exactly?
The second kind (lambda) are essentially just function objects and their corresponding syntax is just sugar. We need a third too, because 'class' has still different rules wrt scoping. The first kind is needed to do even more general things than what 'with' would allow. From the prososal it seems that now they cannot take parameters.
--On Monday, February 03, 2003 11:53:50 -0500 Guido van Rossum <guido@python.org> wrote:
I still don't have time to read this thread :-(, but I had a new idea that I'd like to fly here.
If we want to support thunks that blend into the scope of their environment as well as thunks that introduce a new local scope, here's one possible way to do it:
Thunk blending in:
[<variable> =] <expression>: <block>
Thunk introducing a new local scope:
[<variable> =] <expression> lambda: <block>
(Never mind the ugly things I've said about lambda in the past. :-)
I'm confident that the parser can distinguish these, and I'm confident that the scope blending can be implemented using nested-scope cells.
Adding formal parameters to the second case would go like this:
[<variable> =] <expression> lambda <arguments>: <block>
+1 on all these :-) Great stuff.
One concern I have in both cases: I think there are use cases for wanting more than one block. Glyph's example wants to define various callbacks for a remote call, and this would need multiple blocks. I think the syntax for this would have to use some kind of keyword-based continuation, e.g.
[<variable> =] <expression> lambda: <block> and <expression> lambda: <block> ...
Disclaimer: this is a half-baked idea.
--Guido van Rossum (home page: http://www.python.org/~guido/)
What about: with: n1 = x1 lambda: <block> n2 = x2 lambda: <block2> do expression as a way to pass keyword arguments to expression? That would do it. The only issue would then be passing multiple blocks with the same name, a la try: except: except:, but I don't think that's to bad a thing to lose. Andrew
From: "Guido van Rossum" <guido@python.org>
Thunk blending in:
[<variable> =] <expression>: <block>
these need use cases that go beyond what 'with' can do. If multiple execution of the thunk is allowed and control over break, one usage would be: loop: <block> # can contain break/continue instead of: while 1: <block> Another, if in a program one uses often the if some_cond, e.g. if ctl.mode == INTERACTIVE: <block> if ctl.mode != INTERACTIVE: <block> one could define: interactive: <block> notinteractive: <block> ...
Tim, what have you been putting into Guido's coffee the last few days ? Colons seem to have grown magical expressiveness and now he even likes lambdas ;-) Guido van Rossum wrote:
I still don't have time to read this thread :-(, but I had a new idea that I'd like to fly here.
If we want to support thunks that blend into the scope of their environment as well as thunks that introduce a new local scope, here's one possible way to do it:
Thunk blending in:
[<variable> =] <expression>: <block>
Thunk introducing a new local scope:
[<variable> =] <expression> lambda: <block>
(Never mind the ugly things I've said about lambda in the past. :-)
I'm confident that the parser can distinguish these, and I'm confident that the scope blending can be implemented using nested-scope cells.
Adding formal parameters to the second case would go like this:
[<variable> =] <expression> lambda <arguments>: <block>
One concern I have in both cases: I think there are use cases for wanting more than one block. Glyph's example wants to define various callbacks for a remote call, and this would need multiple blocks. I think the syntax for this would have to use some kind of keyword-based continuation, e.g.
[<variable> =] <expression> lambda: <block> and <expression> lambda: <block> ...
Disclaimer: this is a half-baked idea.
--Guido van Rossum (home page: http://www.python.org/~guido/)
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
From: "M.-A. Lemburg" <mal@lemburg.com>
Tim, what have you been putting into Guido's coffee the last few days ? Colons seem to have grown magical expressiveness and now he even likes lambdas ;-)
these are trying times: http://online.effbot.org/2003_02_01_archive.htm#python-dev
these are trying times:
What a shame. Fredrik has been absent in spirit for a long time. When was the last time he participated in any kind of technical discussion, blue-sky or other? All we've heard from him recently were the occasional snide remark aimed at new visitors who violate the unspoken code of behavior here. I haven't seen him fix any SRE bugs either, SF bugs assigned to him for ages notwithstanding. --Guido van Rossum (home page: http://www.python.org/~guido/)
Whatever he is doing now, his past contributions are worthy of our gratitude and best wishes IMO. Thanks Fredrik and best wishes! sic transit gloria mundi. (Ok, that's a little over the top ;)) David LeBlanc Seattle, WA USA
-----Original Message----- From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On Behalf Of Guido van Rossum Sent: Tuesday, February 04, 2003 12:57 To: Samuele Pedroni Cc: M.-A. Lemburg; Tim Peters; python-dev@python.org; Fredrik Lundh Subject: Re: trying times [Python-Dev] thunks
these are trying times:
What a shame.
Fredrik has been absent in spirit for a long time. When was the last time he participated in any kind of technical discussion, blue-sky or other? All we've heard from him recently were the occasional snide remark aimed at new visitors who violate the unspoken code of behavior here. I haven't seen him fix any SRE bugs either, SF bugs assigned to him for ages notwithstanding.
--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
Whatever he is doing now, his past contributions are worthy of our gratitude and best wishes IMO.
Absolutely.
Thanks Fredrik and best wishes!
I expect we haven't heard the last of him. --Guido van Rossum (home page: http://www.python.org/~guido/)
From: "Guido van Rossum" <guido@python.org>
these are trying times:
What a shame.
Fredrik has been absent in spirit for a long time. When was the last time he participated in any kind of technical discussion, blue-sky or other? All we've heard from him recently were the occasional snide remark aimed at new visitors who violate the unspoken code of behavior here. I haven't seen him fix any SRE bugs either, SF bugs assigned to him for ages notwithstanding.
Whatever, I have re-read my recent posts: I have posted too much and repeated myself a bit, I don't think I have posted too much garbage. On the other hand it is such unexplored territory that it is hard to second-guess you. And the discussion was sometimes very unfocused. I think that people should have at least some kind of conceptual model or impl idea of what they are talking about, unless it's you who are brainstorming. Otherwise the other should invent it for them and it is basically working from scratch and guess-work. I hope people know they should do their homework or S/N suffers, OTOH sometimes people are bad at judging themselves [apply recursively to the post]. I read comp.lang.lisp, I'm open-minded about snide remarks.
On Tuesday 04 February 2003 03:57 pm, Guido van Rossum wrote:
these are trying times:
What a shame.
Fredrik has been absent in spirit for a long time. When was the last time he participated in any kind of technical discussion, blue-sky or other? All we've heard from him recently were the occasional snide remark aimed at new visitors who violate the unspoken code of behavior here. I haven't seen him fix any SRE bugs either, SF bugs assigned to him for ages notwithstanding.
It looks like Fredrik is drifting away from Python development because Python has been drifting away from the original small-is-beautiful design. The energy going into the thunks and Extended Function threads has me baffled. Will the marginal gain in new applications that will be enabled by these features exceed the marginal loss in new Python programmers due to the increased learning threshold? The creep is slow, but it is happening. Generators are cool once you understand them, but they raise the bar for someone new to the language. The same is true for list comprehension. And the proposed syntax changes I've seen in these thrreads are ugly. Please don't turn Python into Perl. I thought the focus of development was going to put more energy into improving the standard library. For instance, Zope often works with SQL databases and those databases often contain financial data. How well does Python support this numerical requirement? According to IBM Technical Report TR03.413 [1], the numeric column breakdown by data type is: Type Columns percent Decimal 251038 55.0 SmallInt 120464 26.4 Integer 78842 17.3 Float 6180 1.4 The Decimal type is the overwhelming winner because the Decimal type is required for financial calculations. This is a huge and important IT market segment. I submitted a patch that added a native fixed type to Python using Tim Peter's FixedPoint module, but it was rejected because I added syntax support for the new type. Please at least add Tim's FixedPoint module to the 2.3 release. (The class should probably be renamed to something shorter like fpoint or fixed when it is added to the standard library.) [1] http://www2.hursley.ibm.com/decimal/decifaq1.html#dbstats
Hi Michael, That's a slightly sneaky subject line for a feature request. But I'll forgive you because you got my attention. :-)
It looks like Fredrik is drifting away from Python development because Python has been drifting away from the original small-is-beautiful design. The energy going into the thunks and Extended Function threads has me baffled.
No need to be baffled. There are many different people here with vastly different interests and ideas. That's what I like about this community: there's always something new being explored. Sometimes a bunch of people get excited over a new idea and try to hash out what the best way to implement is. Sometimes they get a little too excited; then it stops. Sometimes it's decimal numbers, another time it's thunks.
Will the marginal gain in new applications that will be enabled by these features exceed the marginal loss in new Python programmers due to the increased learning threshold? The creep is slow, but it is happening.
Understood. I hope you also understand that the syntax extension ideas being discussed are (a) far from sure to have any impact on Python's design at all, and (b) certain not to affect Python 2.3.
Generators are cool once you understand them, but they raise the bar for someone new to the language.
That all depends. You don't have to teach generators at all in an introductory course -- you don't even have to teach iterators. But all this has been discussed many times before here in numerous threads. My personal opinion is that generators make certain kinds of code so much easier to write that the benefits far outweigh the cost.
The same is true for list comprehension. And the proposed syntax changes I've seen in these thrreads are ugly. Please don't turn Python into Perl.
Maybe they're ugly because I had to withdraw (temporarily) from the thread due to lack of time? These days, I can only argue about language changes in my spare time...
I thought the focus of development was going to put more energy into improving the standard library. For instance, Zope often works with SQL databases and those databases often contain financial data. How well does Python support this numerical requirement? According to IBM Technical Report TR03.413 [1], the numeric column breakdown by data type is:
Type Columns percent Decimal 251038 55.0 SmallInt 120464 26.4 Integer 78842 17.3 Float 6180 1.4
The Decimal type is the overwhelming winner because the Decimal type is required for financial calculations. This is a huge and important IT market segment. I submitted a patch that added a native fixed type to Python using Tim Peter's FixedPoint module, but it was rejected because I added syntax support for the new type. Please at least add Tim's FixedPoint module to the 2.3 release. (The class should probably be renamed to something shorter like fpoint or fixed when it is added to the standard library.)
[1] http://www2.hursley.ibm.com/decimal/decifaq1.html#dbstats
Very sneaky, to start with a gripe about language growth and end with a plea for your favorite language addition. :-) I'm not convinced that decimal arithmetic is Python's next frontier or that it would make a difference to improve Python's adoption. I'm also not convinced that it makes no difference, but as you know, you can prove anything with statistics (not to mention the fact that 90% of statistics are made up), and I note that the URL you quote mentions commercial databases owned by major organizations. This is a specific segment of the IT market where it's no surprise that decimal numbers are in the majority. Let me counter with some more statistics. The FixedPont module is available from SourceForge. It doesn't look like it's wildly popular though: it has been downloaded 236 times since the first release last August. Some more statistics (that I swear I am not making up): during the life of this project (since last August) a total of 3 bugs were reported, zero patches, and one feature request. I'll leave it to Tim to explain why he doesn't think this module should be added to the standard library. If he thinks it belongs there, I certainly won't argue against it! --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
... Let me counter with some more statistics. The FixedPont module is available from SourceForge. It doesn't look like it's wildly popular though: it has been downloaded 236 times since the first release last August. Some more statistics (that I swear I am not making up): during the life of this project (since last August) a total of 3 bugs were reported, zero patches, and one feature request.
The audience for decimal arithmetic isn't capable of implementing it, so the lack of patches is no surprise. The lack of bugs and feature requests is largely explained by that I originally wrote it <wink>. Meaning that it set itself a well-defined task, and did the best possible numeric job within that design from its first release. There were never any bugs, although rounding behavior is something different apps need to do in different ways, and Doug Fort addressed that without going thru the SF bug/patch machinery.
I'll leave it to Tim to explain why he doesn't think this module should be added to the standard library. If he thinks it belongs there, I certainly won't argue against it!
I suggested adding it months ago, and you approved the idea then, provided that I didn't do the work. That's been communicated on python-dev and c.l.py multiple times, but, so far, nobody has bit.
<snip>
I suggested adding it months ago, and you approved the idea then, provided that I didn't do the work. That's been communicated on python-dev and c.l.py multiple times, but, so far, nobody has bit.
What _exactly_ would have to be done to prepare FixedPoint for 2.3? this-is-a-nibble-not-a-bite-ly-yours Dave LeBlanc Seattle, WA USA
[David LeBlanc]
What _exactly_ would have to be done to prepare FixedPoint for 2.3?
You can't know until you try and see who whines about what. For starters, a naming debate. Regardless, docs and test suite and code. Doug Fort has an excellent starti at: http://fixedpoint.sourceforge.net/
this-is-a-nibble-not-a-bite-ly-yours
If you need all questions answered in advance, let go. If I had time for that, I'd have 10x more time than I needed to just do it <0.50001 wink>.
I suggested adding it months ago, and you approved the idea then, provided that I didn't do the work. That's been communicated on python-dev and c.l.py multiple times, but, so far, nobody has bit.
Okay, I'll bite. I read through SF site and the package looks substantially complete. What still needs to be done? Raymond Hettinger
[Raymond Hettinger]
... What still needs to be done?
Heh. You know the drill: proceed as if it is essentially complete, and then endure complaints <wink>. As Michael noted, it needs a different name, and one chosen with the possibility that Aahz will finish his decimal library some day (no time to look up references, but it's all been discussed on Python-Dev before).
Okay, consider me volunteered. David, if you want to team up, please send a private email so we won't eat-up Tim's time just discussing it. Raymond Hettinger ----- Original Message ----- From: "Tim Peters" <tim_one@email.msn.com> To: "Raymond Hettinger" <python@rcn.com> Cc: <python-dev@python.org> Sent: Tuesday, February 04, 2003 10:21 PM Subject: RE: [Python-Dev] Why did Fredrik leave the party?
[Raymond Hettinger]
... What still needs to be done?
Heh. You know the drill: proceed as if it is essentially complete, and then endure complaints <wink>. As Michael noted, it needs a different name, and one chosen with the possibility that Aahz will finish his decimal library some day (no time to look up references, but it's all been discussed on Python-Dev before).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
I know no one asked for my opinion, but if you will indulge me for a moment -- i think the most important concern is to keep the type simple, minimal, and above all *immutable*. Thus: 1. Prevent setting of attributes. 2. Turn 'precision' into a read-only attribute. To set precision, just make a new number with decimal(x, new_precision). 3. But don't call it 'precision'. The word 'precision' usually means either the total number of significant digits, or the least significant distinguishable unit. What we're talking about (number of digits after the decimal point) is neither. I believe the correct term is 'scale' (from SQL). See also http://www2.hursley.ibm.com/decimal/. 4. Get rid of copy(); it's unnecessary if you're immutable. 5. Get rid of 'frac()'. I don't see how it would be needed very often, and it's easy to do x - long(x). That leaves a simple immutable numeric type with no public methods and just one attribute -- hence the least possible burden on a future version of Python, if this type eventually becomes built-in. (And the least possible burden is a good goal in general anyway.) Also: 6. No global mutable state. That means no global settings for default precision or rounding mode. Either pick a standard precision or always require the second constructor argument. Rounding mode is a tougher problem; i see two solutions: (a) Eliminate variable rounding; always round half to even. (b) Set rounding function as an attribute of the number. Operators use the rounding function of the first operand. This lets modules control module-local rounding behaviour if they really want to do so, without interfering with the rest of the program. This may sound like a harsh requirement, but i am convinced that global mutable settings will cause nightmares for people who try to make their modules and programs interoperate. * * * I know the name is a relatively small issue, but my vote would be for the type to be called either "fixpoint" or "decimal". The type name should definitely be lowercase for something as basic as a number, and also lowercase if it's to be a candidate for a future built-in. Arguments for "fixpoint": F1. Shorter than "fixedpoint". It's okay to drop "-ed", since "floating point" -> "float" is accepted. F2. "fix" alone is too unspecific. F3. The important difference between "fixpoint" and "float" is that the precision doesn't change. F4. Already the name of some fixed-point number packages. Arguments for "decimal": D1. Simple, short, friendly. D2. The important difference between "decimal" and "float" is that the fractional part is decimal. D3. Already the name of a SQL standard data type. I think i am currently leaning toward "decimal", because D2 holds a few microlitres more water than F3 for me. -- ?!ng
-----Original Message----- From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On Behalf Of Ka-Ping Yee Sent: Tuesday, February 04, 2003 22:55 To: Raymond Hettinger Cc: David LeBlanc; python-dev@python.org Subject: [Python-Dev] Fixed-point numeric type
I know no one asked for my opinion, but if you will indulge me for a moment -- i think the most important concern is to keep the type simple, minimal, and above all *immutable*.
Thus:
1. Prevent setting of attributes.
2. Turn 'precision' into a read-only attribute. To set precision, just make a new number with decimal(x, new_precision).
Hmmm... and what shall the precision of 4.5 + 2.331 be? I see this as being some sort of output attribute and not an inherent property of the stored value.
3. But don't call it 'precision'. The word 'precision' usually means either the total number of significant digits, or the least significant distinguishable unit. What we're talking about (number of digits after the decimal point) is neither. I believe the correct term is 'scale' (from SQL). See also http://www2.hursley.ibm.com/decimal/.
I would think that calling it what most mathematicians would call it would be most appropriate.
4. Get rid of copy(); it's unnecessary if you're immutable.
Are floats and ints immutable? This should follow the standard for existing numeric types IMO.
5. Get rid of 'frac()'. I don't see how it would be needed very often, and it's easy to do x - long(x).
That leaves a simple immutable numeric type with no public methods and just one attribute -- hence the least possible burden on a future version of Python, if this type eventually becomes built-in. (And the least possible burden is a good goal in general anyway.)
No public methods? No math operators? Is this a fixed point numeric constant?
Also:
6. No global mutable state. That means no global settings for default precision or rounding mode. Either pick a standard precision or always require the second constructor argument. Rounding mode is a tougher problem; i see two solutions:
Disagree. there is a "natural" precision that most people would tend to use and I think it's 2 places to the right of the decimal point. Rounding varies according to need and, again, I think there's a "natural" preference, although in this case I don't know what it would be.
(a) Eliminate variable rounding; always round half to even.
I suspect financial people would not like this. See the discussion of banker's rounding in the doc. Ideally, as is already built, rounding should be both defaulted and overridable by a derivative class, for example "class money (fixedpoint):"
(b) Set rounding function as an attribute of the number. Operators use the rounding function of the first operand. This lets modules control module-local rounding behaviour if they really want to do so, without interfering with the rest of the program.
I thend to think that I want rounding to be a display function and not something that effects the stored value. Otherwise you propegate rounding loss.
This may sound like a harsh requirement, but i am convinced that global mutable settings will cause nightmares for people who try to make their modules and programs interoperate.
How?
* * *
I know the name is a relatively small issue, but my vote would be for the type to be called either "fixpoint" or "decimal". The type name should definitely be lowercase for something as basic as a number, and also lowercase if it's to be a candidate for a future built-in.
Arguments for "fixpoint":
F1. Shorter than "fixedpoint". It's okay to drop "-ed", since "floating point" -> "float" is accepted.
F2. "fix" alone is too unspecific.
F3. The important difference between "fixpoint" and "float" is that the precision doesn't change.
F4. Already the name of some fixed-point number packages.
I like FixedPoint, Fixedpoint or fixedpoint - whatever the capitalization of other Python types is.
Arguments for "decimal":
D1. Simple, short, friendly.
D2. The important difference between "decimal" and "float" is that the fractional part is decimal.
D3. Already the name of a SQL standard data type.
I suspect decimal might impact Aahz' decimal.py. I have downloaded but not looked at it yet; but perhaps it's worthy of inclusion into Tim's package. What does decimal imply to a user that might not be true in fixedpoint? I resist the idea of naming it to suggest any relation with an SQL datatype unless it precisely mimics that datatype and there's a good reason for mimicing it in the first place!
I think i am currently leaning toward "decimal", because D2 holds a few microlitres more water than F3 for me.
I am currently leaning towards running and hiding behind Tim ;)
-- ?!ng
Some rather more prosaic questions: 1. Should it work on versions of Python before 2.3? 2. Are there more unit tests required that need to be added to the Python test suite? 3. What is the procedure for getting it into the distro, both bits and docs? 4. Is the class complete? Can it be pickled? Does it play well with floats and ints? Does it have a to/from string method? 5. Does it have an impact on other classes? 6. Does it have any impact on string format specifiers? (It should IMO.) 7. Does Tim have enough time to look over our shoulders, channel Guido and get this done right without taking up too much of his time? I think the idea should be to get the package into the distro and not start a rethink/redesign at this stage - otherwise it won't appear until Python 3000 ;). gee-this-was-supposed-to-be-easily-yours Dave LeBlanc Seattle, WA USA
On Wed, 5 Feb 2003, David LeBlanc wrote:
Hmmm... and what shall the precision of 4.5 + 2.331 be? I see this as being some sort of output attribute and not an inherent property of the stored value.
Already covered -- read the documentation at http://fixedpoint.sf.net/. I'm starting with what's specified there and proposing adjustments.
Are floats and ints immutable?
Yes, and it's essential.
No public methods? No math operators? Is this a fixed point numeric constant?
No need for methods. Other numeric types don't have them. (Well, complex has .conjugate(), but that's very complex-specific.)
6. No global mutable state. That means no global settings for default precision or rounding mode. Either pick a standard precision or always require the second constructor argument. Rounding mode is a tougher problem; i see two solutions:
Disagree. there is a "natural" precision that most people would tend to use and I think it's 2 places to the right of the decimal point.
I didn't contradict your suggestion. A default of 2 places is fine. But there must be a fixed default; no global mutable setting.
Rounding varies according to need and, again, I think there's a "natural" preference, although in this case I don't know what it would be.
I believe the natural preference is round-half-to-even, also known as "banker's rounding", which is the current default in FixedPoint.
I thend to think that I want rounding to be a display function and not something that effects the stored value. Otherwise you propegate rounding loss.
There must be some limit to storage precision. If you want to avoid propagating loss, use high precision, then round when you're done.
This may sound like a harsh requirement, but i am convinced that global mutable settings will cause nightmares for people who try to make their modules and programs interoperate.
How?
Suppose two modules use different default precisions or rounding modes, and they set this by changing a global flag. If you use both modules, one will break, and it will be practically impossible to fix.
I think the idea should be to get the package into the distro and not start a rethink/redesign at this stage - otherwise it won't appear until Python 3000 ;).
The adjustments i'm suggesting look pretty small to me: remove mutability, remove global state. When in doubt, simplify or remove features. Features can be always added later; but once a feature is in, dependencies force it to stay. -- ?!ng
[Ka-Ping Yee]
No need for methods. Other numeric types don't have them. (Well, complex has .conjugate(), but that's very complex-specific.)
Please drop this one -- "no methods" remains a non-goal. Strings didn't have methods either, now use of string methods is ubiquitous, and Guido approved of adding methods to numbers too years ago (but nobody ever got around to adding some; e.g., long.numbits()).
Just as data point: I started developing mxNumber to experiment with fixed point and rational numeric types (supplied by GMP). My original intention was to make use of these in mxODBC since databases rather commonly use DECIMAL as database column type. The net-interest was next to zero which is why I stopped bothering. I may still continue due to reasons of roundtrip safety in database interfacing, but I'm inclined to believe that Python users in the financial business either have no interest or have found their own particular solutions to the problem of dealing with fixed point arithmetic (mostly to store monetary values) -- provided that rounding pays off for them, I don't think that they are bothered at all with using floats ;-) BTW, mxNumber types implement many of Ping's requests. And they are fast as hell, since the underlying GMP implementation uses assembler where possible. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
On Wed, 5 Feb 2003, M.-A. Lemburg wrote:
Just as data point:
I started developing mxNumber to experiment with fixed point and rational numeric types (supplied by GMP). My original intention was to make use of these in mxODBC since databases rather commonly use DECIMAL as database column type.
The net-interest was next to zero which is why I stopped bothering.
I'm finding that this is a problem in education, not desire. Once you educate developers, they will demand decimal types. Unfortunately, I've found that many db developers are completely ignorant of the caveats of both fixed and floating point arithmetic. They naively "just want things to work" and aren't too worried about the details or the corner-cases. (I blame this on the cruddy computer science content of many CIS degree programs, but that is a topic for a different rant.) Nevertheless, I would like to seeing proper fixed point support in the Python standard library with integration advise in a DB-API extension standard or PEP. As it is, our applications patch many of the DB-API modules to add support for our own homebrew decimal types, and it is fairly cumbersome to maintain.
I may still continue due to reasons of roundtrip safety in database interfacing, but I'm inclined to believe that Python users in the financial business either have no interest or have found their own particular solutions to the problem of dealing with fixed point arithmetic [...]
We (my company) are in the latter camp. However, I've talked to a number of developers who decided not to use Python for financial apps because DB-API drivers punt on decimal types. Maybe that is why it is so quiet on this front? Regards, -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
[Kevin Jacobs]
I'm finding that this is a problem in education, not desire. Once you educate developers, they will demand decimal types. Unfortunately, I've found that many db developers are completely ignorant of the caveats of both fixed and floating point arithmetic. They naively "just want things to work" and aren't too worried about the details or the corner-cases. (I blame this on the cruddy computer science content of many CIS degree programs, but that is a topic for a different rant.)
Or they have a COBOL background. COBOL has always supported decimal arithmetic, and it can be hard to get across to a COBOL'er that getting the pennies right can be a problem in other languages. It's part of the air they breathe, beneath conscious attention.
Nevertheless, I would like to seeing proper fixed point support in the Python standard library
What does "proper" mean? The implementation of FixedPoint was easy for me, but getting users to spell out what they really needed proved impossible. "Proper" isn't a specification all by itself <wink>.
with integration advise in a DB-API extension standard or PEP. As it is, our applications patch many of the DB-API modules to add support for our own homebrew decimal types, and it is fairly cumbersome to maintain.
Is FixedPoint usable for you? This person seemed to think it helped: http://mailman.tux4web.de/pipermail/orm-devel/2002-December/000083.html """ o I've created a numeric datatype and a numericColumn. They use the FixedPoint module you can find at http://fixedpoint.sourceforge.net/html/lib/module-FixedPoint.html This lets you use arbitrary precision/exact math just like pgsql does internally. """
On Wed, 5 Feb 2003, Tim Peters wrote:
Nevertheless, I would like to seeing proper fixed point support in the Python standard library
What does "proper" mean? The implementation of FixedPoint was easy for me, but getting users to spell out what they really needed proved impossible. "Proper" isn't a specification all by itself <wink>.
with integration advise in a DB-API extension standard or PEP. As it is, our applications patch many of the DB-API modules to add support for our own homebrew decimal types, and it is fairly cumbersome to maintain.
Is FixedPoint usable for you? This person seemed to think it helped:
I'm in the process of evaluating it as a replacement for our homebrew decimal package. Once I have a reasonable compatiblity interface, I'll run it through our test suite and let you know. -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
[Ka-Ping Yee]
I know no one asked for my opinion, but if you will indulge me for a moment -- i think the most important concern is to keep the type simple, minimal, and above all *immutable*.
Thus:
1. Prevent setting of attributes.
Good idea.
2. Turn 'precision' into a read-only attribute. To set precision, just make a new number with decimal(x, new_precision).
The existing set_precision() name still seems fine, though. It's not necessarily a "new" precision; set_precision says what it means.
3. But don't call it 'precision'. The word 'precision' usually means either the total number of significant digits, or the least significant distinguishable unit. What we're talking about (number of digits after the decimal point) is neither. I believe the correct term is 'scale' (from SQL). See also http://www2.hursley.ibm.com/decimal/.
Opposed. Users had no trouble understanding what precision means in this context (the module has been in use for a few years).
4. Get rid of copy(); it's unnecessary if you're immutable.
Agreed.
5. Get rid of 'frac()'. I don't see how it would be needed very often, and it's easy to do x - long(x).
Don't care much, but gratuitous fiddling will turn this into a bottomless pit.
That leaves a simple immutable numeric type with no public methods
"no public methods" is a non-goal to me.
and just one attribute -- hence the least possible burden on a future version of Python, if this type eventually becomes built-in. (And the least possible burden is a good goal in general anyway.)
I hope that an implementation of Mike Cowlishaw's nascent standard gets that honor instead.
Also:
6. No global mutable state. That means no global settings for default precision or rounding mode. Either pick a standard precision or always require the second constructor argument. Rounding mode is a tougher problem; i see two solutions:
(a) Eliminate variable rounding; always round half to even.
Too unrealistic to consider -- a slew of silly rounding modes is a requirement for commercial use.
(b) Set rounding function as an attribute of the number.
Bleech.
Operators use the rounding function of the first operand. This lets modules control module-local rounding behaviour if they really want to do so, without interfering with the rest of the program.
This may sound like a harsh requirement, but i am convinced that global mutable settings will cause nightmares for people who try to make their modules and programs interoperate.
Tough luck. Practicality beats purity here: the pure solution is to pass a "numeric context" object to each operation, which some implementations actually require. The resulting source code is tedious and unreadable. The practical alternative is what you live with every day in FP arithmetic, yet don't even notice: thread-local state holding the current IEEE-754 rounding mode and precision control (etc) settings, implicitly an input to every operation (and assorted 754 status flags are also implicitly outputs from every operation). It works fine, but requires some care in programs living on the edge. People will screw it sometimes, but so it goes.
On Wed, 5 Feb 2003, Tim Peters wrote:
2. Turn 'precision' into a read-only attribute. To set precision, just make a new number with decimal(x, new_precision).
The existing set_precision() name still seems fine, though. It's not necessarily a "new" precision; set_precision says what it means.
Methods named "set-whatever" are typically understood to change a component of something. If this must be done with a method, the method should be called something like "with_scale(x)" instead of "set_scale(x)". But i think the method is unnecessary -- the constructor already provides a perfectly good way to make a new number with an altered precision, so why provide a second way to do the same thing? There should be OOWTDI.
3. But don't call it 'precision'. The word 'precision' usually means either the total number of significant digits, or the least significant distinguishable unit. What we're talking about (number of digits after the decimal point) is neither. I believe the correct term is 'scale' (from SQL). See also http://www2.hursley.ibm.com/decimal/.
Opposed. Users had no trouble understanding what precision means in this context (the module has been in use for a few years).
That's not an argument that 'precision' is the right name. That's just a claim that we can confuse people into believing that 'precision' is not so bad. 'precision' is simply the *wrong word*. Using it would create confusion. Let's use the correct word while we have the option to do so. pre-ci-sion, n. 1. The state or quality of being precise; exactness. 2. a. The ability of a measurement to be consistently reproduced. b. The number of significant digits to which a value has been reliably measured. -- The American Heritage Dictionary, 4th Edition. In the context of floating-point numbers, which i think is likely the most common context for programmers to encounter this word, 'precision' refers to significant digits. And in the context of SQL, which will probably be familiar to a significant part of this type's target audience, 'precision' also refers to significant digits. The attribute we're talking about represents something *completely different*.
"no public methods" is a non-goal to me. [...and later...] Please drop this one -- "no methods" remains a non-goal. Strings didn't have methods either, now use of string methods is ubiquitous, and Guido approved of adding methods to numbers too years ago (but nobody ever got around to adding some; e.g., long.numbits()).
Sorry, i didn't express myself very well. I'm not arguing for "zero methods just for the sake of zero methods". My position is "no unnecessary methods". Actually it's "no unnecessary anything" -- the overall idea is to make the type as minimal as possible. If we can get away with few methods, or no methods at all, so much the better. For example, i'm arguing against a set_precision/set_scale/with_scale method on the grounds of TOOWTDI, not because i have a particular dislike for all methods.
and just one attribute -- hence the least possible burden on a future version of Python, if this type eventually becomes built-in. (And the least possible burden is a good goal in general anyway.)
I hope that an implementation of Mike Cowlishaw's nascent standard gets that honor instead.
Sure. We should still aim for minimality though.
6. No global mutable state. That means no global settings for default precision or rounding mode. Either pick a standard precision or always require the second constructor argument. Rounding mode is a tougher problem; i see two solutions:
(a) Eliminate variable rounding; always round half to even.
Too unrealistic to consider -- a slew of silly rounding modes is a requirement for commercial use.
Okay, granted.
(b) Set rounding function as an attribute of the number.
Bleech.
Can you, er, elaborate? And, can we reduce the issue to the rounding mode? Can we agree on no global mutable default precision, at least? The cost is minimal, and the introduction of a commonly-mutated default would be dangerous and expensive in the long run.
Tough luck. Practicality beats purity here: the pure solution is to pass a "numeric context" object to each operation, which some implementations actually require. The resulting source code is tedious and unreadable. The practical alternative is what you live with every day in FP arithmetic, yet don't even notice:
I don't notice it only because i don't ever care to change the rounding mode. If i did try, i'd be in trouble. Same with the decimal fixed-point type: if no one wants to change the rounding mode, no one notices. I'm assuming we both believe that people will want to adjust rounding modes more often with fixed-point than with floating-point. The question is what happens to people who do mess with such things. Should such people find interoperability impossible, or merely tedious? In such a dilemma, i'm arguing for tedious. I feel pretty hard-line about the default precision, but i may be willing to concede the rounding issue if you have a good story for interoperability. -- ?!ng
[Ka-Ping Yee]
Methods named "set-whatever" are typically understood to change a component of something. If this must be done with a method, the method should be called something like "with_scale(x)" instead of "set_scale(x)".\
I still like set_precision(). You ignore that this module has happy users -- I know that the current names make sense to them. I don't know that abstract arguments will.
But i think the method is unnecessary -- the constructor already provides a perfectly good way to make a new number with an altered precision, so why provide a second way to do the same thing? There should be OOWTDI.
It's a dedicated method for a common case. I doubt many (if any) current module users realize that precision can be changed via the constructor, and doing it that way seems strained even to me. Presumably you would be happier then if the constructor lost this ability.
... That's not an argument that 'precision' is the right name. That's just a claim that we can confuse people into believing that 'precision' is not so bad.
I don't care whether it's "right", I only care that it's proven itself to work in practce.
... The attribute we're talking about represents something *completely different*.
As I said before, existing users have had no problems with this.
(b) Set rounding function as an attribute of the number.
Bleech.
Can you, er, elaborate?
Desired rounding is a function of the operand(s) and the operation they're combined with. The idea that there's a "round to even" 4.1 and a "add a half and chop" 4.1 is simply bizarre. It would make *some* kind of sense to say there are "round to even" and "add a half and chop" flavors of the addition operator, but then that multiplies too. Real apps overwhelmingly want "round to even" on every operation over some stretch, or overwhelmingly want "add a half and chop" rounding on every operation over some stretch.
And, can we reduce the issue to the rounding mode? Can we agree on no global mutable default precision, at least?
FixedPoint never had global mutable default precision, and I don't believe Doug added it. The default precision is 2, period. Cowlishaw's proposal has other kinds of "input state", though.
... I'm assuming we both believe that people will want to adjust rounding modes more often with fixed-point than with floating-point.
I don't, at least not in a problematic sense. A commerical app has to adhere to financial rounding rules that, like time zone rules, are often more informed by arbitrary political foolishness than sense. I expect the typical case is for an app to set the rounding mode once at its start, and never change it again.
The question is what happens to people who do mess with such things. Should such people find interoperability impossible, or merely tedious?
Tedious, surprising, and error-prone, but easy and pleasant for most people most of the time.
... I feel pretty hard-line about the default precision, but i may be willing to concede the rounding issue if you have a good story for interoperability.
There isn't a "default precision issue" that I can see, unless you object to the current default of 2; if "interoperability" is a real issue I expect that one of the module's users might have mentioned it by now <wink>.
Displaying FixedPoints: Python 2.2.1 (#34, Jul 16 2002, 16:25:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. Alternative ReadLine 1.5 -- Copyright 2001, Chris Gonnerman
from fixedpoint import * a = FixedPoint(2.135) print '%d' % (a) 2 print '%4d' % (a) 2 print '%e' % (a) 2.130000e+000 print '%f' % (a) 2.130000 print '%2f' % (a) 2.130000 print '%.2d' % (a) 02 print '%s' % (a) 2.13 a.set_precision(4) print '%s' % (a) 2.1300
I naively expected the %d to produce 2.315 - and it would be nice, after the manner of C, to be able to specify the precision (or scale if you prefer) of the output as I attempted in '%.2d' and also (not shown) '%2.2d'. This might need some work since %<num>d is a field filler spec. It would be nice if given 2.135: %d 2 - int part %2d __2 - filled int part (_'s represent spaces) %.2d 2.13 - ?rounded? to two places %2.2d __2.13 - filled and ?rounded? to 2 places %2.5d __2.13500 - filled and zero extended %.3d 2.135 - etc. If rounding vs. truncation is done for a 'short' (less than actual precision) specifier , then string formatting needs to know something about FixedPoints IMO. Displaying a frac part would require extraction and use of 'd' as in a normal int. The '%s' output just looks suspicious, especially after setting the precision to 4! The '%s' smells of bug to me, although I see the code forces the initializer value to round to DEFAULT_PRECISION if a precision isn't given ("you lost my work!"). IMO the precision of the initializer should become the precision of the value and not the default if a (seems redundant to me) precision isn't given. David LeBlanc Seattle, WA USA N.B: this needs to be added to the distro (assuming it lives in lib/site_packages/fixedpoint?): #__init__.py ---------------------------- # FixedPoint from fixedpoint import *
Displaying FixedPoints:
Python 2.2.1 (#34, Jul 16 2002, 16:25:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. Alternative ReadLine 1.5 -- Copyright 2001, Chris Gonnerman
from fixedpoint import * a = FixedPoint(2.135) print '%d' % (a) 2 print '%4d' % (a) 2 print '%e' % (a) 2.130000e+000 print '%f' % (a) 2.130000 print '%2f' % (a) 2.130000 print '%.2d' % (a) 02 print '%s' % (a) 2.13 a.set_precision(4) print '%s' % (a) 2.1300
I naively expected the %d to produce 2.315
Eh? In C as well as Python, %d means decimal *integer*. The format specifier to use fixed point notation is %f. Please don't change this! --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
Eh? In C as well as Python, %d means decimal *integer*. The format specifier to use fixed point notation is %f.
Please don't change this!
I sure wouldn't <wink>. Note that use of %f ends up calling FixedPoint.__float__(), though, and so sucks users right back into binary fp surprises:
t = FixedPoint.FixedPoint(".1") print t 0.10 print "%.17f" % t 0.10000000000000001 float(t) == 0.1 True
FixedPoint does the best possible job of converting 1/10 to a float, but it's exactly as surprising as the float literal 0.1 then.
Tim Peters wrote:
I sure wouldn't <wink>. Note that use of %f ends up calling FixedPoint.__float__(), though, and so sucks users right back into binary fp surprises:
Perhaps FixedPoint should not have a __float__ method. Instead it could have something like as_float(). That would give people a clue they are getting into trouble. Neil
I sure wouldn't <wink>. Note that use of %f ends up calling FixedPoint.__float__(), though, and so sucks users right back into binary fp surprises:
Hm, maybe we should have an optional __format_as_float_string__ method that the %f and %g specifiers can use. --Guido van Rossum (home page: http://www.python.org/~guido/)
Let me be the first to state, most emphatically, that I'm not about to change anything, ESPECIALLY the Python core! Besides, I don't have check-in priviledges AFAIK and burgling Tim's pockets for the keys would probably yield only pickles ;) still-nibblingly-yours David LeBlanc Seattle, WA USA
-----Original Message----- From: guido@python.org [mailto:guido@python.org] Sent: Wednesday, February 05, 2003 17:01 To: David LeBlanc Cc: python-dev@python.org Subject: Re: [Python-Dev] FixedPoint and % specifiers.
Displaying FixedPoints:
Python 2.2.1 (#34, Jul 16 2002, 16:25:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. Alternative ReadLine 1.5 -- Copyright 2001, Chris Gonnerman
from fixedpoint import * a = FixedPoint(2.135) print '%d' % (a) 2 print '%4d' % (a) 2 print '%e' % (a) 2.130000e+000 print '%f' % (a) 2.130000 print '%2f' % (a) 2.130000 print '%.2d' % (a) 02 print '%s' % (a) 2.13 a.set_precision(4) print '%s' % (a) 2.1300
I naively expected the %d to produce 2.315
Eh? In C as well as Python, %d means decimal *integer*. The format specifier to use fixed point notation is %f.
Please don't change this!
--Guido van Rossum (home page: http://www.python.org/~guido/)
There are no ways for classes to hook into % formats, short of that if you use %d, __int__ will be called; if you use a float format code, __float__ will be called; if you use %s, __str__ will be called. [David]
Displaying FixedPoints:
Python 2.2.1 (#34, Jul 16 2002, 16:25:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. Alternative ReadLine 1.5 -- Copyright 2001, Chris Gonnerman
from fixedpoint import * a = FixedPoint(2.135)
Note that the docs strongly advise against initializing a FixedPoint from a float. Until a decimal literal notation is added to the core (if ever), you're much better off passing a string literal. The docs contain examples of why.
print '%d' % (a) 2 print '%4d' % (a) 2 print '%e' % (a) 2.130000e+000 print '%f' % (a) 2.130000 print '%2f' % (a) 2.130000 print '%.2d' % (a) 02 print '%s' % (a) 2.13 a.set_precision(4) print '%s' % (a) 2.1300
I naively expected the %d to produce 2.315
Why? %d is an integer format code, so of course it produces an integer. You can't start reading, e.g., "%d" as "decimal" just because you imported a module <wink>.
- and it would be nice, after the manner of C, to be able to specify the precision (or scale if you prefer) of the output as I attempted in '%.2d' and also (not shown) '%2.2d'. This might need some work since %<num>d is a field filler spec. It would be nice if given 2.135: %d 2 - int part %2d __2 - filled int part (_'s represent spaces) %.2d 2.13 - ?rounded? to two places %2.2d __2.13 - filled and ?rounded? to 2 places %2.5d __2.13500 - filled and zero extended %.3d 2.135 - etc.
Hooks would have to be added to the core to support any of that. Piles of new features requiring core changes are out of scope for 2.3 at this stage.
... The '%s' output just looks suspicious, especially after setting the precision to 4! The '%s' smells of bug to me, although I see the code forces the initializer value to round to DEFAULT_PRECISION if a precision isn't given ("you lost my work!"). IMO the precision of the initializer should become the precision of the value and not the default if a (seems redundant to me) precision isn't given.
floats have no inherent precision in this sense, and the number you passed to the constructor was not decimal 2.135. Appendix A of the Tutorial explains this; the number you actually passed was 1201898150554501 / 2**49 == 2.1349999999999997868371792719699442386627197265625 and FixedPoint rounded that correctly to 2 decimal digits after the radix point. You would have been more surprised if FixedPoint had said the precision was 49, but it does require exactly 49 digits after the decimal point to capture your input number without loss of information.
print FixedPoint.FixedPoint(2.135, 51) 2.134999999999999786837179271969944238662719726562500
print FixedPoint.FixedPoint("2.135", 51) 2.135000000000000000000000000000000000000000000000000
Now forget literals -- they really aren't very interesting. You normally have computed quantities, and there's no hope of *guessing* "the inherent precision" from those, unless they're also FixedPoints and so explicitly support a reasonable notion of precision. You can't guess this from a float in isolation, and you can't guess anything about how many digits after the decimal point are implied by an integer. You either accept the constructor's default (2), or explicitly tell it how much precision you believe the input has.
Well sheesh, I guess this just points to how long it's been since I've done any serious C/C++ involving format specifiers. %f does what I expect given a string initializer of a FixedPoint. It's confusing to think of FixedPoints as really being Floats though. If FixedPoint is going to be oriented towards business app programmers and/or edu-kids, isn't the need to pass a string a bit counter intuitive? Has the parser hacked the arg into a float by the time the __init__ sees it? (I suppose, come to think of it, that's an obvious "yes".) I suggest that DEFAULT_PRECISION should be 4. From the dim recesses of my pre-history, I seem to recall that the money programmers liked that - they _saved_ the round-offs into what was called a "penny register" and accumulated them. When you're dealing with millions, a drip here and a drop there and pretty soon, if you're dishonest, you can add a check to the check processing run for some serious pocket change (this actually happened) ;) More below: <snip>
floats have no inherent precision in this sense, and the number you passed to the constructor was not decimal 2.135. Appendix A of the Tutorial explains this; the number you actually passed was
1201898150554501 / 2**49 == 2.1349999999999997868371792719699442386627197265625
and FixedPoint rounded that correctly to 2 decimal digits after the radix point. You would have been more surprised if FixedPoint had said the precision was 49, but it does require exactly 49 digits after the decimal point to capture your input number without loss of information.
print FixedPoint.FixedPoint(2.135, 51) 2.134999999999999786837179271969944238662719726562500
print FixedPoint.FixedPoint("2.135", 51) 2.135000000000000000000000000000000000000000000000000
Ok, so FixedPoint is really just a subterfuge for floats? Seems less than useful to our money and edu-kid users? (I think I'm hinting here that FixedPoint should be a distinct type if it's really going to have the semantics the intended audience expects. That probably kills it for 2.3 I guess.)
Now forget literals -- they really aren't very interesting. You normally have computed quantities, and there's no hope of *guessing* "the inherent precision" from those, unless they're also FixedPoints and so explicitly support a reasonable notion of precision. You can't guess this from a float in isolation, and you can't guess anything about how many digits after the decimal point are implied by an integer. You either accept the constructor's default (2), or explicitly tell it how much precision you believe the input has.
Agreed - internally, a FixedPoint should retain all it's digits and only have any idea of precision at display time IMO. Dave LeBlanc Seattle, WA USA
[David LeBlanc]
Well sheesh, I guess this just points to how long it's been since I've done any serious C/C++ involving format specifiers. %f does what I expect given a string initializer of a FixedPoint.
Then you haven't tried enough examples yet (one of my last two msgs showed a surprising result from "%.17f" % FixedPoint("0.1")).
It's confusing to think of FixedPoints as really being Floats though.
They aren't floats, but they participate in Python's numeric protocols, and "silently coerce when in a float context" is one I don't personally like but is generally expected. FixedPoint plays along with it, although in a perverse way (it usually coerces the float to a FixedPoint instead of vice versa, since that's probably less surprising more often).
If FixedPoint is going to be oriented towards business app programmers and/or edu-kids, isn't the need to pass a string a bit counter intuitive?
Yes, but, as before, inputs to FixedPoint constructors are unlikely to be literals. In business apps, they're likely to be sucked out of databases, most of which support a native decimal type of their own. In that context there's no cause for any loss of information.
Has the parser hacked the arg into a float by the time the __init__ sees it? (I suppose, come to think of it, that's an obvious "yes".)
Two points! That's right.
I suggest that DEFAULT_PRECISION should be 4. From the dim recesses of my pre-history, I seem to recall that the money programmers liked that - they _saved_ the round-offs into what was called a "penny register" and accumulated them. When you're dealing with millions, a drip here and a drop there and pretty soon, if you're dishonest, you can add a check to the check processing run for some serious pocket change (this actually happened) ;)
This module has been in use for a few years already. If the people who actually used it suggested this, I'd be happy to oblige. But this is the first time it's been suggested, and by someone who hasn't used it "for real", so I'm inclined to let it go at that.
Ok, so FixedPoint is really just a subterfuge for floats?
No. Read the docs and play more with the module. For example, FixedPoint + and - are always exact. Float + and - are not.
Seems less than useful to our money and edu-kid users? (I think I'm hinting here that FixedPoint should be a distinct type if it's really going to have the semantics the intended audience expects. That probably kills it for 2.3 I guess.)
FixedPoint is already a distinct type, but if you mix one with a float, you're going to get surprised. The surprise will come from the float part, though, not from the FixedPoint part. Don't mix FixedPoints with floats, or use them in float contexts, and you won't get surprises.
... Agreed - internally, a FixedPoint should retain all it's digits and only have any idea of precision at display time IMO.
I don't know what this means, or do but assure you it can't be implemented. For example, the mathematical result of FixedPoint(1)/7 doesn't have a finite decimal representation -- "all its digits" is unbounded. As implemented, the result inherits its precision from the FixedPoint operand, which can be as large as you like, but must be specified in advance.
print FixedPoint(1, 70)/7 0.1428571428571428571428571428571428571428571428571428571428571428571429
Try that with floats and see what you get <wink>.
Let's continue all of this in a private discussion. If Tim had time to answer these emails, then it would already be done; the problem is 95% solved and it won't take rocket science to cover the last 5%. Raymond ----- Original Message ----- From: "Tim Peters" <tim_one@email.msn.com> To: "David LeBlanc" <whisper@oz.net> Cc: <python-dev@python.org> Sent: Wednesday, February 05, 2003 9:35 PM Subject: RE: [Python-Dev] RE: FixedPoint and % specifiers.
[David LeBlanc]
Well sheesh, I guess this just points to how long it's been since I've done any serious C/C++ involving format specifiers. %f does what I expect given a string initializer of a FixedPoint.
Then you haven't tried enough examples yet (one of my last two msgs showed a surprising result from "%.17f" % FixedPoint("0.1")).
It's confusing to think of FixedPoints as really being Floats though.
They aren't floats, but they participate in Python's numeric protocols, and "silently coerce when in a float context" is one I don't personally like but is generally expected. FixedPoint plays along with it, although in a perverse way (it usually coerces the float to a FixedPoint instead of vice versa, since that's probably less surprising more often).
If FixedPoint is going to be oriented towards business app programmers and/or edu-kids, isn't the need to pass a string a bit counter intuitive?
Yes, but, as before, inputs to FixedPoint constructors are unlikely to be literals. In business apps, they're likely to be sucked out of databases, most of which support a native decimal type of their own. In that context there's no cause for any loss of information.
Has the parser hacked the arg into a float by the time the __init__ sees it? (I suppose, come to think of it, that's an obvious "yes".)
Two points! That's right.
I suggest that DEFAULT_PRECISION should be 4. From the dim recesses of my pre-history, I seem to recall that the money programmers liked that - they _saved_ the round-offs into what was called a "penny register" and accumulated them. When you're dealing with millions, a drip here and a drop there and pretty soon, if you're dishonest, you can add a check to the check processing run for some serious pocket change (this actually happened) ;)
This module has been in use for a few years already. If the people who actually used it suggested this, I'd be happy to oblige. But this is the first time it's been suggested, and by someone who hasn't used it "for real", so I'm inclined to let it go at that.
Ok, so FixedPoint is really just a subterfuge for floats?
No. Read the docs and play more with the module. For example, FixedPoint + and - are always exact. Float + and - are not.
Seems less than useful to our money and edu-kid users? (I think I'm hinting here that FixedPoint should be a distinct type if it's really going to have the semantics the intended audience expects. That probably kills it for 2.3 I guess.)
FixedPoint is already a distinct type, but if you mix one with a float, you're going to get surprised. The surprise will come from the float part, though, not from the FixedPoint part. Don't mix FixedPoints with floats, or use them in float contexts, and you won't get surprises.
... Agreed - internally, a FixedPoint should retain all it's digits and only have any idea of precision at display time IMO.
I don't know what this means, or do but assure you it can't be implemented. For example, the mathematical result of FixedPoint(1)/7 doesn't have a finite decimal representation -- "all its digits" is unbounded. As implemented, the result inherits its precision from the FixedPoint operand, which can be as large as you like, but must be specified in advance.
print FixedPoint(1, 70)/7 0.1428571428571428571428571428571428571428571428571428571428571428571429
Try that with floats and see what you get <wink>.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
Guido wrote:
Generators are cool once you understand them, but they raise the bar for someone new to the language.
That all depends. You don't have to teach generators at all in an introductory course -- you don't even have to teach iterators. But all this has been discussed many times before here in numerous threads.
Not true. I don't think people on python-dev are in touch with the impacts of their changes on the Python learning curve. In every organization, there will be both advanced programmers and beginners. And in every organization, there will be at least one advanced programmer who will discover and use the new cool features, and thus impose them upon everyone else. Trust me on this. I've met these people; hell, I used to be one of these people :-). The fact is, today, some of the most common questions I get in Python classes have to do with new things like list comprehensions and generators, regardless of class makeup. I don't have time to argue the merits of adding new features in the first place. But please, let's not be naive about their impact on the perceived simplicity of Python. Like it or not, beginners do need to know about new things, even if they will not be coding them. And like it or not, Python has indeed lost much of the simplicity that attracted some. There's always been a dichotomy of people who want to keep it simple, and people who want to add new features. After just updating Learning Python, it's pretty obvious that the latter group has won the tug of war in recent years. Try explaining the current 3 flavors of division to a beginner sometime and you'll see what I mean. --Mark Lutz (http://www.rmi.net/~lutz)
[Michael]
Generators are cool once you understand them, but they raise the bar for someone new to the language.
[Guido]
That all depends. You don't have to teach generators at all in an introductory course -- you don't even have to teach iterators. But all this has been discussed many times before here in numerous threads.
[Mark]
Not true. I don't think people on python-dev are in touch with the impacts of their changes on the Python learning curve.
In every organization, there will be both advanced programmers and beginners. And in every organization, there will be at least one advanced programmer who will discover and use the new cool features, and thus impose them upon everyone else.
Trust me on this. I've met these people; hell, I used to be one of these people :-). The fact is, today, some of the most common questions I get in Python classes have to do with new things like list comprehensions and generators, regardless of class makeup.
I don't have time to argue the merits of adding new features in the first place. But please, let's not be naive about their impact on the perceived simplicity of Python. Like it or not, beginners do need to know about new things, even if they will not be coding them.
And like it or not, Python has indeed lost much of the simplicity that attracted some. There's always been a dichotomy of people who want to keep it simple, and people who want to add new features. After just updating Learning Python, it's pretty obvious that the latter group has won the tug of war in recent years. Try explaining the current 3 flavors of division to a beginner sometime and you'll see what I mean.
Thanks for the reality check! One of the problems with "improving" a complex software system is that, no matter how hard you try, it's nearly impossible to take away thing, so that when a new solution for an old issue is added, the old solution stays around. The division operator is a case in point: in Python 3.0, there will only be two division operators: floor division and true division. Arguably, this is no more complex than the situation before // was introduced: while there was only one division operator, there were two kinds of semantics that one had to learn and watch out for. (I assure you we've all been bitten by this more than once. Most recently, I saw it on the review page of a certain conference, in the calculation of the average score of submitted papers. [*]) But the transitional situation has the union of the old and the new world, and hence is more messy than either. There's also the tension between making the language simpler (to learn) and making programs simpler (to read). For example, *if* (and that's still a very big if) we were to add a language feature that would let you write synchronized(lock): BLOCK instead of lock.aqcuire() try: BLOCK finally: lock.release() I assure you that this makes programs that use locks more readable, which reduces maintenance costs down the road. But at the same time we can't hope to reduce every idiom to a single statement, and we must be careful not to destroy the language by adding too many "neat tricks". It's a delicate balance, and the occasional reality check from the field is much appreciated. _____ [*] In 3.0, you'll have to remember that if you want integer division, you must write // instead of /. But the problems caused by writing / where you intended // are usually immediately obvious (often the program won't even run, if the resulting float is used as an index somewhere); while the problems caused by silent truncation of int/int are often only discovered by careful checking of actual results with expected results. --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> There's also the tension between making the language simpler GvR> (to learn) and making programs simpler (to read). For GvR> example, *if* (and that's still a very big if) we were to add GvR> a language feature that would let you write | synchronized(lock): | BLOCK GvR> instead of | lock.aqcuire() | try: | BLOCK | finally: | lock.release() The real problem is that the second example isn't even correct, if you want to be totally anal about it. ;) You really need an atomic operation to acquire the lock and enter the try block, which the second example doesn't give you. It's a narrow window of failure but it exists, and you have to decide whether you care. So the first example doesn't /just/ improve readability, it improves correctness too (assuming it is also atomic). -Barry
[Barry A. Warsaw]
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> There's also the tension between making the language simpler GvR> (to learn) and making programs simpler (to read). For GvR> example, *if* (and that's still a very big if) we were to add GvR> a language feature that would let you write
| synchronized(lock): | BLOCK
GvR> instead of
| lock.aqcuire() | try: | BLOCK | finally: | lock.release()
The real problem is that the second example isn't even correct, if you want to be totally anal about it. ;) You really need an atomic operation to acquire the lock and enter the try block, which the second example doesn't give you. It's a narrow window of failure but it exists, and you have to decide whether you care. So the first example doesn't /just/ improve readability, it improves correctness too (assuming it is also atomic).
What about having keywords that denote that something be executed as atomic? I assume the issue is being in the middle of executing bytecode and then switching threads in the middle of the bytecode for the method execution. Would it be reasonable (and feasible) to implement some way to shut down thread switching in the interpreter and thus guarantee that something gets fully executed before allowing thread switching (I am thinking of something along the lines of a lock that keeps track of the number of thread switching shutdown calls and then turns back on switching when the counter hits back down to 0). Or am I missing something critical and thus I should just shut up? =) -Brett
Guido van Rossum wrote:
There's also the tension between making the language simpler (to learn) and making programs simpler (to read). For example, *if* (and that's still a very big if) we were to add a language feature that would let you write
synchronized(lock): BLOCK
instead of
lock.aqcuire() try: BLOCK finally: lock.release()
I assure you that this makes programs that use locks more readable, which reduces maintenance costs down the road. But at the same time we can't hope to reduce every idiom to a single statement, and we must be careful not to destroy the language by adding too many "neat tricks".
I think you're getting this wrong: By introducing meta-constructs like the thunk idea to raise the expressiveness of random program blocks you do make the program simpler to read, but certainly not easier to comprehend. The reason is that arbitrary code gets hidden from the user in a way which makes it hard to actually follow the flow of commands. The above lock example is perfect for this: the try:finally: approach is clear and explicit whereas the synchronized(lock): block introduces a layer of abstraction that is not easy to comprehend: because the flow of control is not obvious anymore and because it is hidden in some definition of synchronized() which the maintainer will have to look up somewhere (where somewhere could be inside some .zip archive holding the great new toolbox some geek developer which has long left the company found cool to use... :-/). We have already introduced such a meta-contruct feature in a few places, e.g. importers and meta-classes... both are hardly ever used and that's good, because understanding, maintaining and possibly debugging these is a nightmare for much the same reason that thunks are. Now, we're lucky since meta-classes or writing importers is not all that easy. With thunks the situation will be much like giving macros to Python programmers: you'll see a proliferation of new meta-constructs in all kinds of programs and in the end lose the maintainability argument which is still one of the strongest ones for using Python in the first place. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
On Wed, Feb 05, 2003, M.-A. Lemburg wrote:
Now, we're lucky since meta-classes or writing importers is not all that easy. With thunks the situation will be much like giving macros to Python programmers: you'll see a proliferation of new meta-constructs in all kinds of programs and in the end lose the maintainability argument which is still one of the strongest ones for using Python in the first place.
That's true only if we permit generalized thunks. I've been pushing for simplified thunks; nevertheless "thunk" is a useful term for the discussions we're having. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Register for PyCon now! http://www.python.org/pycon/reg.html
Guido van Rossum <guido@python.org>:
synchronized(lock): BLOCK
instead of
lock.aqcuire() try: BLOCK finally: lock.release()
I assure you that this makes programs that use locks more readable, which reduces maintenance costs down the road. But at the same time we can't hope to reduce every idiom to a single statement, and we must be careful not to destroy the language by adding too many "neat tricks".
I'm going to have to come out against this idea. I think it violates "explicit is better than implicit", and is perilously close to being mere syntactic sugar. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
"ESR" == Eric S Raymond <esr@thyrsus.com> writes:
ESR> I'm going to have to come out against this idea. I think it ESR> violates "explicit is better than implicit", and is ESR> perilously close to being mere syntactic sugar. Except that it's not, because of the lack of atomic acquire-and-enter-try. You could probably code this specific example like so: try: lock.acquire() dosomething() finally: try: lock.release() except NotLocked: pass but you still have the problem of ironclad resource release in other situations, such as the cursor opening scenario (I think) I posted before. Brett (I think) suggested that there may be alternatives to a syntactic approach, e.g. one that prohibits thread switching between the resource acquisition and the entering of the try. That might be interesting to explore, but I worry about deadlock possibilities. -Barry
"BAW" == Barry A Warsaw <barry@python.org> writes: BAW> Except that it's not, because of the lack of atomic BAW> acquire-and-enter-try.
BAW> You could probably code this specific example like so: BAW> try: BAW> lock.acquire() dosomething() BAW> finally: BAW> try: BAW> lock.release() BAW> except NotLocked: BAW> pass BAW> but you still have the problem of ironclad resource release in BAW> other situations, such as the cursor opening scenario (I think) BAW> I posted before. BAW> Brett (I think) suggested that there may be alternatives to a BAW> syntactic approach, e.g. one that prohibits thread switching BAW> between the resource acquisition and the entering of the try. BAW> That might be interesting to explore, but I worry about BAW> deadlock possibilities. There was a good paper on this subject at LL2. You can find it here: http://www.cs.williams.edu/~freund/papers.html Jeremy
"JH" == Jeremy Hylton <jeremy@zope.com> writes:
JH> There was a good paper on this subject at LL2. You can find JH> it here: http://www.cs.williams.edu/~freund/papers.html Search for "Safe Asynchronous Exceptions For Python". Nice paper. I don't much like the nested block:/unblock: construction (too much indentation), but the initially: part is nice. -Barry
[Barry A. Warsaw]
"JH" == Jeremy Hylton <jeremy@zope.com> writes:
JH> There was a good paper on this subject at LL2. You can find JH> it here: http://www.cs.williams.edu/~freund/papers.html
Search for "Safe Asynchronous Exceptions For Python".
Nice paper. I don't much like the nested block:/unblock: construction (too much indentation), but the initially: part is nice.
Since Guido seems to have his summaries, I am going to assume the discussion ban has been lifted (if I am wrong, Guido, let me know). So I read the paper and it is kind of what I was thinking of. I was actually thinking more along the lines of having something like:: atomic: lock() ... with atomic basically shutting down threading temporarily until everything in its body is executed. This would basically make sure that no issues would occur with code being changed while executing from other threads. I would think this could be done by holding on to the GIL and not releasing it under any conditions until the body is executed. So with no threading occuring you can be sure that your data will not be changed in any *extremely* unexpected way (obviously you can write bad code that can do unexpected things, but I am going to assume you are not going to). Now obviously this could be abused, but as the if-then-else proposal as pointed out, almost anything can be abused. So maybe a good idea? Totally hair-brained? -Brett
Brett> I was actually thinking more along the lines of having something Brett> like:: Brett> atomic: Brett> lock() Brett> ... Brett> with atomic basically shutting down threading temporarily until Brett> everything in its body is executed. This would presumably generate bytecode something like: GRAB_GIL lock() ... execute the block's code ... unlock() RELEASE_GIL Suppose code in your block makes a call to a threading-aware extension module. Won't it obligingly release the GIL if it goes to do some longish operation? If so, wouldn't you then be screwed? Skip
[Skip Montanaro]
Brett> I was actually thinking more along the lines of having something Brett> like::
Brett> atomic: Brett> lock() Brett> ...
Brett> with atomic basically shutting down threading temporarily until Brett> everything in its body is executed.
This would presumably generate bytecode something like:
GRAB_GIL lock() ... execute the block's code ... unlock() RELEASE_GIL
Suppose code in your block makes a call to a threading-aware extension module. Won't it obligingly release the GIL if it goes to do some longish operation? If so, wouldn't you then be screwed?
Yes, you would be screwed. As I said, you could screw yourself with your code. But could you do something like keep a list of what threads were running while this atomic state is being run, and then when the GIL is released that list is checked before any threads just randomly grab for the GIL? That would make sure things are still done synchronously. You would also have to temporarily disable the bytecode instruction counter while this atomic state is in affect. But if the consensus is that this is too difficult to implement or not worth it I will just drop the idea. -Brett
Since Guido seems to have his summaries, I am going to assume the discussion ban has been lifted (if I am wrong, Guido, let me know).
Not exactly wrong, but I still have no time to devote to this all. However, I see that a few PEPs have been added already. I suggest that people get together and write PEPs about the other proposals as well, so we can focus and record the discussion in PEPs rather than in python-dev archives. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Barry A. Warsaw]
Brett (I think) suggested that there may be alternatives to a syntactic approach, e.g. one that prohibits thread switching between the resource acquisition and the entering of the try. That might be interesting to explore, but I worry about deadlock possibilities.
Yes, I suggested this, but at an improper time. I had forgotten Guido had asked that new ideas that tied into the syntax proposals not be brought up until summaries of the old ideas were done. My bad. =) Anyway, so I am going to read the paper that Jeremy posted the link to, but I am going to ask that we save discussing this until we get those summaries (or discuss it off-list if anyone cares to). Maybe this will motivate me to come up with some half-assed summary just to have one done and force people to clean them up if they care about the proposal. =) -Brett
I don't have time to argue the merits of adding new features in the first place. But please, let's not be naive about their impact on the perceived simplicity of Python. Like it or not, beginners do need to know about new things, even if they will not be coding them.
I don't disagree that 2.3 is more complex than 1.5.2. However, *some* of the changes made python easier to learn and use. At one time, every beginner had to learn: * how to override __getitem__ and throw away the index to simulate iteration * to add 1L to their factorial function which worked fine for small parameters but crashed with larger ones * to clutter code with x=x, y=y, etc to simulate nested scope * funky code contortions to simulate lockstep iteration * use of the lineinput module to read files line-by-line For users of non-ascii charactersets, life has gotten much easier. Raymond Hettinger ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
"RH" == Raymond Hettinger <python@rcn.com> writes:
RH> * how to override __getitem__ and throw away the index to RH> simulate iteration * to add 1L to their factorial function RH> which worked fine for small parameters but crashed with larger RH> ones * to clutter code with x=x, y=y, etc to simulate nested RH> scope * funky code contortions to simulate lockstep iteration RH> * use of the lineinput module to read files line-by-line Don't forget ugly and unique foo = foo + 1 -Barry
Barry A. Warsaw wrote:
"RH" == Raymond Hettinger <python@rcn.com> writes:
RH> * how to override __getitem__ and throw away the index to RH> simulate iteration * to add 1L to their factorial function RH> which worked fine for small parameters but crashed with larger RH> ones * to clutter code with x=x, y=y, etc to simulate nested RH> scope * funky code contortions to simulate lockstep iteration RH> * use of the lineinput module to read files line-by-line
Don't forget ugly and unique
foo = foo + 1
Or my favorite wart fixed in 2.3 bigstring.index(smallstring) != -1 (or was that bigstring.find(smallstring) != -1 ? :-) --david
[Michael McLay]
... I thought the focus of development was going to put more energy into improving the standard library.
2.3 has been very much about that, as Guido intended. For example, I've done no Python work beyond datetime and pickle development for nearly two months now. I doubt Guido wants focus to remain on the library exclusively and forever more, though.
For instance, Zope often works with SQL databases and those databases often contain financial data. How well does Python support this numerical requirement?
IMO, poorly out of the box. But at the same time nobody in my Zope mgmt chain has shown any interest in supporting work in this area (and yes, I've asked -- it doesn't even get to the point of being a wish-list item, there's simply no interest at all).
According to IBM Technical Report TR03.413 [1], the numeric column breakdown by data type is:
Type Columns percent Decimal 251038 55.0 SmallInt 120464 26.4 Integer 78842 17.3 Float 6180 1.4
The Decimal type is the overwhelming winner because the Decimal type is required for financial calculations. This is a huge and important IT market segment. I submitted a patch that added a native fixed type to Python using Tim Peter's FixedPoint module, but it was rejected because I added syntax support for the new type.
Consistent with Guido's "new new syntax for 2.3" position.
Please at least add Tim's FixedPoint module to the 2.3 release. (The class should probably be renamed to something shorter like fpoint or fixed when it is added to the standard library.)
[1] http://www2.hursley.ibm.com/decimal/decifaq1.html#dbstats
Who are you asking? I've said several times on python-dev and on c.l.py that (a) Guido has already approved adding FixedPoint to 2.3; and, (b) I can't make time for it (neither to do it, nor even to offer non-trivial help). If I can't make time for it, it's a sure bet nobody else at PLabs will either. In someone cares enough to do it and can make time for it, there's nothing stopping it.
Guido van Rossum wrote:
here. I haven't seen him fix any SRE bugs either, SF bugs assigned to him for ages notwithstanding.
On the other hand, "unsubscribing from python-dev" != "ending all Python development". Maybe we should draw up a list of what needs to get done before 2.3alpha2 can be released; are any of the bugs critical? I certainly understand where he's coming from, though. Rational number threads are my particular pet peeve, because discussions never converge on a solution, making it unlikely that any way will ever be found to add rationals to the language, yet rational threads seem to go on endlessly. Working on language features seems like misdirected activity to me, and perhaps to Fredrik as well, when other activities might be more beneficial for Python, e.g. finishing and implementing Moshe's Batteries Included PEP, adding numarray, or things like that. (Overall I'm really pleased with 2.3 because the library additions -- logging, register.py, PyBSDDB, tarfile, and the CSV API, should it go in -- plug a number of gaps in the stdlib.) --amk (www.amk.ca) LEAR: O, that way madness lies. -- _King Lear_, III, iv
Samuele Pedroni wrote:
From: "M.-A. Lemburg" <mal@lemburg.com>
Tim, what have you been putting into Guido's coffee the last few days ? Colons seem to have grown magical expressiveness and now he even likes lambdas ;-)
these are trying times:
Trying is fine, but Fredrik has a point there. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
Samuele Pedroni wrote:
From: "M.-A. Lemburg" <mal@lemburg.com>
Tim, what have you been putting into Guido's coffee the last few days ? Colons seem to have grown magical expressiveness and now he even likes lambdas ;-)
these are trying times:
Trying is fine, but Fredrik has a point there.
If that weren's enough, python-dev is topping itself: """ python-dev is discussing decimal arithmetics in a thread titled "why did fredrik leave the party" """ http://online.effbot.org/2003_02_01_archive.htm#irony Subject lines seem to have no relevance any longer in this list. Let's continue this way and see more people saying good-bye. -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
these are trying times:
Trying is fine, but Fredrik has a point there.
Followup: http://online.effbot.org/2003_02_01_archive.htm#irony """ # irony: python-dev is discussing decimal arithmetics in a thread titled "why did fredrik leave the party". to the extent yesterday's post had a point, I think this proves it ;-) """ --Guido van Rossum (home page: http://www.python.org/~guido/)
these are trying times:
Trying is fine, but Fredrik has a point there.
Followup:
http://online.effbot.org/2003_02_01_archive.htm#irony
""" # irony: python-dev is discussing decimal arithmetics in a thread titled "why did fredrik leave the party". to the extent yesterday's post had a point, I think this proves it ;-) """
It's often hard to guess what /F's points are. In this case, it's about getting a library into 2.3, where the idea to get it into 2.3 was approved no later than last September: From: Tim Peters <tim.one@comcast.net> Date: Thu Sep 19 14:20:22 2002 To: python-list@python.org Subject: RE: monetary applications [was: Python GUI app to impress the bos s?] About http://starship.python.net/crew/aahz/FixedPoint.py If someone is willing and able to do the work (sorry, I can't make time for it), Guido will accept this into the standard library for 2.3. It's a small, self-contained, pure Python module; it's been in use for a few years with no bugs reported; and is unencumbered by any license (a lawyer has told me that an individual in the USA cannot meaningfully disclaim copyright, so fine, the copyright I didn't want is hereby transferred to the PSF <wink>). What work remains: + Write docs for the Library Reference manual. I expect the existing module docstring will be a good start. + Create a test driver for Python's regression suite. + Have fun modernizing it, if you like (for example, "/" should be changed to "//" where integer division is intended; playing with __slots__ may yield some nice savings; whatever). This should be a fun and comparatively easy task -- if you ever wanted to get your name into the ACKS file, here's one way to do it without tithing you income directly to Guido <wink>. although-tithing-saves-me-time-ly y'rs - tim
"M.-A. Lemburg" <mal@lemburg.com> writes:
these are trying times: http://online.effbot.org/2003_02_01_archive.htm#python-dev
Trying is fine, but Fredrik has a point there.
Yes: he needs a better mail reader. mostly-serious-ly y'rs, M. (actually someone has already suggesting throwing a newsreader at the problem, to judge by the follow-up). -- If you don't have friends with whom to share links and conversation, you have social problems and you should confront them instead of joining a cultlike pseudo-community. -- "Quit Slashdot.org Today!" (http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq)
"MAL" == M <M.-A.> writes:
MAL> Tim, what have you been putting into Guido's coffee the last MAL> few days ? Right idea, wrong question. The only thing we've got in the office is a colored beverage that is reminiscent of coffee. You should ask what Tim is putting in Guido's pickles. Jeremy
Gee, I knew that timbot channeled Guido, but never knew about Tim and Guido's pickles... Perhaps this should be left as a personal matter ;) David LeBlanc Seattle, WA USA
-----Original Message----- From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On Behalf Of Jeremy Hylton Sent: Tuesday, February 04, 2003 13:38 To: M.-A. Lemburg Cc: Tim Peters; python-dev@python.org Subject: Re: [Python-Dev] thunks
"MAL" == M <M.-A.> writes:
MAL> Tim, what have you been putting into Guido's coffee the last MAL> few days ?
Right idea, wrong question. The only thing we've got in the office is a colored beverage that is reminiscent of coffee. You should ask what Tim is putting in Guido's pickles.
Jeremy
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
Jeremy Hylton wrote:
"MAL" == M <M.-A.> writes:
MAL> Tim, what have you been putting into Guido's coffee the last MAL> few days ?
Right idea, wrong question. The only thing we've got in the office is a colored beverage that is reminiscent of coffee. You should ask what Tim is putting in Guido's pickles.
At least that's more or less documented in a PEP (hmm, perhaps he forgot to update the TBD section ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
[M.-A. Lemburg]
Tim, what have you been putting into Guido's coffee the last few days ? Colons seem to have grown magical expressiveness and now he even likes lambdas ;-)
Guido recently had a birthday, and I think he finally realized that, if things continue this way, someday he'll be as old as I am. Strange things happen when you realize your useful life is nearly over. For example, when that happened to me, I moved to Virginia. Now Guido is about the age I was then, so it's his turn to ruin his life. Unfortunately, unlike me, he can take the rest of us down with him <wink>. first-you-soften-toward-lambda-then-you-seek-lawrence-welk-reruns-ly y'rs - tim
participants (29)
-
A.M. Kuchling -
Aahz -
Andrew McGregor -
Anthony Baxter -
barry＠python.org -
Brett Cannon -
Christian Tismer -
David Ascher -
David LeBlanc -
Eric S. Raymond -
Greg Ewing -
Guido van Rossum -
Jeremy Hylton -
jeremy＠zope.com
-
Ka-Ping Yee -
Kevin Jacobs -
M.-A. Lemburg -
Mark Lutz -
Michael Hudson -
Michael McLay -
Neil Schemenauer -
Oren Tirosh -
Raymond Hettinger -
Raymond Hettinger -
Roman Suzi -
Samuele Pedroni -
Skip Montanaro -
Tim Peters -
Tim Peters