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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4