...

...

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 It's never too late to have a happy childhood.

From: "Greg Ewing"

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.

From: "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 ;-)

these are trying times: http://online.effbot.org/2003_02_01_archive.htm#python-dev

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:

http://online.effbot.org/2003_02_01_archive.htm#python-dev

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

From: "Guido van Rossum"

...

these are trying times:

http://online.effbot.org/2003_02_01_archive.htm#python-dev

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.

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/)

<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

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

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" To: "Raymond Hettinger" Cc: 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

################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################

-----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

[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()).

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

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

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

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 *

[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.

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/)

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.

[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>.

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)

...

...

...

...

"GvR" == Guido van Rossum 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

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/

Guido van Rossum :

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>

...

...

...

...

"BAW" == Barry A Warsaw 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

[Barry A. Warsaw]

...

...

...

...

...

"JH" == Jeremy Hylton 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

[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

[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

...

...

...

...

"RH" == Raymond Hettinger 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

[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.

Samuele Pedroni wrote:

From: "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 ;-)

these are trying times:

http://online.effbot.org/2003_02_01_archive.htm#python-dev

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/

...

these are trying times:

http://online.effbot.org/2003_02_01_archive.htm#python-dev

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/)

"M.-A. Lemburg" 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 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

Jeremy Hylton wrote:

...

...

...

...

...

"MAL" == M 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/