Re: [Python-Dev] trunc()
Paul Moore schrieb: On 24/01/2008, Jeffrey Yasskin [EMAIL PROTECTED] wrote: int has to be a builtin because it's a fundamental type. trunc() followed round() into the builtins. I have no opinion on whether ceil and floor should move there; it probably depends on how often they're used. Suggestion: - int() has to stay in builtins for obvious reasons. - put *all* of trunc, ceil, floor, round into math. That, and making int(float) == int(trunc(float)) seems like reasonable behavior to me as a person not involved in the discussion. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r60283 - in python/trunk: Include/longintrepr.h Include/longobject.h Include/unicodeobject.h Misc/NEWS Modules/_fileio.c Objects/longobject.c Objects/unicodeobject.c
[christian.heimes] Backport of several functions from Python 3.0 to 2.6 including PyUnicode_FromString, PyUnicode_Format and PyLong_From/AsSsize_t. The functions are partly required for the backport of the bytearray type and _fileio module. They should also make it easier to port C to 3.0. Are you planning to backport bytearrays? I thought we had clearly decided to *not* backport any of the text/bytes model so that the Py2.6 string/unicode model remained pure. Guido proposed a couple of harmless aliases for annotation purposes (to help the 2-to-3 tool do the right thing) and that was it. Your reply was: Ah, you like to keep it simple. The aliases are easily to implement. Give me twenty minutes to implement it and write some unit tests. How did we get from two simple aliases to plans for backporting major chucks of the new model? I'm not seeing any limits on Py3.0--Py2.6 contamination. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
-On [20080126 09:43], Georg Brandl ([EMAIL PROTECTED]) wrote: Paul Moore schrieb: - int() has to stay in builtins for obvious reasons. - put *all* of trunc, ceil, floor, round into math. That, and making int(float) == int(trunc(float)) seems like reasonable behavior to me as a person not involved in the discussion. +1 from my side for the above. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TIOBE Programming Community Index
Sorry if this is a repeat. I don't remember seeing this in the various Python-related stuff I've received before (and no longer monitor c.l.py, only look at the weekly summary), though based on the dateline of the Slashdot item I saw (Jan 9) it should be old news. Apparently, in 2007 Python surged in the TIOBE Programming Community Index to #6, surpassing Perl: http://www.tiobe.com/tpci.htm It's got aways to go before it surpasses C++, but that's the next rung in the ladder... I'm a little suspicious of the data though. Given the huge popularity in AJAX tools I would have expected JavaScript to have increased in popularity, not decreased. Hmmm... And they have both Delphi and COBOL jumping in popularity by three rungs. At any rate, there you have it. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python] TIOBE Programming Community Index
[EMAIL PROTECTED] wrote: Sorry if this is a repeat. I don't remember seeing this in the various Python-related stuff I've received before (and no longer monitor c.l.py, only look at the weekly summary), though based on the dateline of the Slashdot item I saw (Jan 9) it should be old news. Apparently, in 2007 Python surged in the TIOBE Programming Community Index to #6, surpassing Perl: http://www.tiobe.com/tpci.htm It's got aways to go before it surpasses C++, but that's the next rung in the ladder... I'm a little suspicious of the data though. Given the huge popularity in AJAX tools I would have expected JavaScript to have increased in popularity, not decreased. Hmmm... And they have both Delphi and COBOL jumping in popularity by three rungs. This has been fairly widely reported - and in fact is on the front page of Python.org! A site with a more interesting range of metrics (in my opinion) is 'langpop': http://www.langpop.com/ In its 'Normalized Comparison' it shows Python doing well, but not *quite* having overtaken Perl yet. All the best, Michael Foord At any rate, there you have it. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
Terry Reedy wrote: Guido van Rossum [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Does no-one thinks it means round(f) either? Not me. Int should truncate, so trunc() not needed unless is does something different. Like returning a value of the same type as the input? int(), being a call to a type, should never return a value of another type. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TIOBE Programming Community Index
[EMAIL PROTECTED] wrote: Sorry if this is a repeat. I don't remember seeing this in the various Python-related stuff I've received before (and no longer monitor c.l.py, only look at the weekly summary), though based on the dateline of the Slashdot item I saw (Jan 9) it should be old news. Apparently, in 2007 Python surged in the TIOBE Programming Community Index to #6, surpassing Perl: http://www.tiobe.com/tpci.htm It's got aways to go before it surpasses C++, but that's the next rung in the ladder... I'm a little suspicious of the data though. Given the huge popularity in AJAX tools I would have expected JavaScript to have increased in popularity, not decreased. Hmmm... And they have both Delphi and COBOL jumping in popularity by three rungs. At any rate, there you have it. Python is TIOBE's Language of the Year for 2007 Python moves up from 8 to 6 in TIOBE's list of popular programming languages Published: Fri, 18 Jan 2008, 10:30 -0500 From http://python.org/, with a link to the TIOBE index. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
Raymond Hettinger wrote: but if Guido likes the idea of a standard naming convention (such as the ABC suffix) for classes that use the ABCMeta metaclass, I'd certainly be happy to go through and update the affected classes and the code which refers to them. A prefix would be better. I initially thought that, but found the suffix to be the least annoying of the ideas I had for denoting abstract base classes. To try and give some idea of how I came to that conclusion I've listed some of the other ideas I had below (again using the numeric stack as an example). INumber IComplex IReal IRational IIntegral Using a simple 'I' prefix annoys me for cases like the last one where the class name actually starts with an I, and 'interface' is a bit of a misnomer for abstract base classes anyway - they have a lot in common, but they're not the same thing. This is also an existing convention for things like zope.interface, so probably not a good idea to adopt to mean something else. ABCNumber ABCComplex ABCReal ABCRational ABCIntegral I find using the ABC acronym as a prefix ends up with too many capitals together at the start of the word and it becomes far more obtrusive than it needs to be. The main thing about these classes is what they represent - the fact that they're ABC's, while still significant enough to indicate somewhere in the name, should be of secondary importance. AbcNumber AbcComplex AbcReal AbcRational AbcIntegral This one bugs me mainly because I don't like lowercasing letters in acronyms just to try and fit in with a camel-casing scheme. It's just ugly. After those 3, I couldn't think of any other prefixes that were both short and likely to be an effective mnemonic for identifying ABC's - Abstract is too long, Abs is far too easy to associated with 'absolute' instead of Abstract base class, etc. Which lead me to the idea I actually used in my earlier post: NumberABC ComplexABC RealABC RationalABC IntegralABC That way the normal class names are still front and centre, with a short annotation tacked on to the end to say oh, by the way, this happens to be an abstract base class. I'm not sure any more discussion will be particularly useful though - any convention that gets adopted is going to be by Guido's fiat and will need to suit his aesthetic sense rather than mine :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r60283 - in python/trunk: Include/longintrepr.h Include/longobject.h Include/unicodeobject.h Misc/NEWS Modules/_fileio.c Objects/longobject.c Objects/unicodeobject.c
Raymond Hettinger wrote: Are you planning to backport bytearrays? I thought we had clearly decided to *not* backport any of the text/bytes model so that the Py2.6 string/unicode model remained pure. The idea raised when I was working on a backport of the io module. The io module requires a mutable byte type. Guido answered a question in my issue http://bugs.python.org/issue1919 Backporting bytearray should be relatively clean since it's a brand new type right? My initial question was: I'm not sure how to proceed with the missing bytearray type: * backport bytearray and the new buffer interface from 3.0 * write a replacement for 2.6 * replace the bytearray code with new code bytearray is a new type that has no equivalent in Python 2.6. Python 3.0's byte type is basically a modified string type. I don't see a problem with bytearray, do you? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple syntax proposal: not is
On Jan 25, 2008 10:50 PM, Terry Reedy [EMAIL PROTECTED] wrote: Jameson Chema Quinn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | I'm writing a source code editor that translates identifiers and keywords | on-screen into a different natural language. This tool will do no | transformations except at the reversible word level. There is one simple, | avoidable case where this results in nonsense in many languages: is not. I | propose allowing not is as an acceptable alternative to is not. I an rather sure that the tokenizer outputs is not as a single token. Otherwise 'a is not b' would likely be parsed as 'a is (not b)', which is something quit different. So your translater should recognize it as such also and output, for instance (en Espanol), 'no es'. Sorry to burst your bubble, but 'is' and 'not' are two separate tokens; the grammar handles this by giving unary 'not' a priority lower than comparison operators. | Obviously English syntax has a deep influence on python syntax, and I would | never propose deeper syntactical changes for natural-language-compatibility. | This is a trivial change, one that is still easily parseable by an | English-native mind (and IMO actually makes more sense logically, since it | does not invite confusion with the nonsensical is (not ...)). The | use-cases where you have to grep for is not are few, and the (is | not)|(not is) pattern that would replace it is still pretty simple. 'a not is b' is much worse in English than I believe 'a es no b' in Espanol. This proposal not is going to happen... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r60283 - in python/trunk: Include/longintrepr.h Include/longobject.h Include/unicodeobject.h Misc/NEWS Modules/_fileio.c Objects/longobject.c Objects/unicodeobject.c
On Jan 26, 2008 1:16 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: Are you planning to backport bytearrays? I thought we had clearly decided to *not* backport any of the text/bytes model so that the Py2.6 string/unicode model remained pure. 'bytearray' is a separate issue. It's a brand new type: a *mutable* byte array. Its status as a built-in and completely different API makes it much more convenient than using the old array module. Introducing bytearray is not going to disturb the balance between str/bytes/unicode. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python] Re: [Python-checkins] r60283 - in python/trunk: Include/longintrepr.h Include/longobject.h Include/unicodeobject.h Misc/NEWS Modules/_fileio.c Objects/longobject.c Objects/un
Guido van Rossum wrote: On Jan 26, 2008 1:16 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: Are you planning to backport bytearrays? I thought we had clearly decided to *not* backport any of the text/bytes model so that the Py2.6 string/unicode model remained pure. 'bytearray' is a separate issue. It's a brand new type: a *mutable* byte array. Its status as a built-in and completely different API makes it much more convenient than using the old array module. Introducing bytearray is not going to disturb the balance between str/bytes/unicode. I'm looking forward to having a native mutable bytes type in Python 2.x. Michael Foord ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r60283 - in python/trunk: Include/longintrepr.h Include/longobject.h Include/unicodeobject.h Misc/NEWS Modules/_fileio.c Objects/longobject.c Objects/unicodeobject.c
'bytearray' is a separate issue. It's a brand new type: a *mutable* byte array. Its status as a built-in and completely different API makes it much more convenient than using the old array module. That's reasonable. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorrect documentation of the raw_input built-in function
Incodentally, I think your example is wrong. It should be either psql /dev/null 21 or psql /dev/null Notice the reversal of redirects in the first one. Of course, this doesn't change anything about the core discussion... - C On 1/24/08, Isaac Morland [EMAIL PROTECTED] wrote: On Thu, 24 Jan 2008, [EMAIL PROTECTED] wrote: Mike 2. Is this really the hard-coded behavior we want? I don't think Mikemy use-case is that odd; in fact, what I find very odd is that Mikethe prompt output is send to stderr. I mean, I'm printing the Mikeprompt for a question, not some error message. Can there not at Mikeleast be an optional parameter to indicate that you want the Mikeoutput sent to stdout rather than stderr? I can think of situations where you don't want the output to go to stdout either (suppose it's the regular output of the file you want to save to a file). Having a choice seems the best route. What about an option (maybe even a default) to send the prompt to stdin? The Postgres command line interface psql appears to do this: $ psql 21 /dev/null Password: $ (I typed my password and then I quit by typing ^D; if I type the wrong password, it looks the same on screen but it quits right away without waiting for ^D) I think ssh also does this when it needs to prompt for a password. Really the prompt is part of the input, not part of the output, in a certain sense. Have people actually verified that the prompt is really sent to stderr right now by using 2/dev/null to attempt to suppress it? Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/shiblon%40gmail.com -- Sent from Gmail for mobile | mobile.google.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
On Jan 25, 2008 11:21 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: ... int() for making ints from the non-fractional portion of a float. This interpretation implies that complex should provide __float__() to return the non-imaginary portion of a complex number. Is that what you intend? -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
Jeffrey Yasskin wrote: This interpretation implies that complex should provide __float__() to return the non-imaginary portion of a complex number. Is that what you intend? No, please don't. If somebody wants to implement __float__ for complex numbers please define it as hypot(complex) / sqrt(c.real**2 + c.img**2). In my opinion float(complex) does do the most sensible thing. It fails and points the user to abs(). float(complex(1,1)) Traceback (most recent call last): File stdin, line 1, in module TypeError: can't convert complex to float; use abs(z) abs(complex(1,1)) 1.4142135623730951 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
On Jan 26, 2008 12:43 AM, Georg Brandl [EMAIL PROTECTED] wrote: That, and making int(float) == int(trunc(float)) seems like reasonable behavior to me as a person not involved in the discussion. That's the only position in this discussion that I don't understand. Although int() and trunc() would still have very slightly different behaviors, they seem too close together (identical on most common types) to be compatible with only one way to do it. I've been advocating trunc() under the assumption that int(float) would be deprecated and eliminated as soon as practical (with an error message similar to float(complex)). Could one of the people in favor of keeping both explain why they think that's a good idea? -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
[Christian Heimes] In my opinion float(complex) does do the most sensible thing. It fails and points the user to abs(). Right. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
I've been advocating trunc() under the assumption that int(float) would be deprecated and eliminated as soon as practical And how much code would break for basically zero benefit? This position is totally nuts. There is *nothing* wrong with int() as it stands now. Nobody has problems with it. The tools is ubiquitous in other languages, spreadsheets, and calculators. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
On Jan 26, 2008 2:46 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: [Christian Heimes] In my opinion float(complex) does do the most sensible thing. It fails and points the user to abs(). Right. To elaborate the point I was trying to make: If float() does not mean the float part of and should not take a complex argument (which I completely agree with), then int() does not mean the int part of and should not take a float argument. Even assuming that's correct, I'm not certain that it's worth breaking (well, deprecating) backwards compatibility to achieve a more consistent set of functions in this case. I think it is, but I'm happy to leave that point up to the rest of the list (which does seem to be leaning against it). -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] refleaks and caches
Around Jan 13, the refleak hunting test that is reported on python-checkins started to report refleaks on virtually every run. I suspect this is due to r59944 (at 2008-01-13 16:29:41) which was from patch #1700288 to cache methods. With this patch it makes it much harder to spot refleaks. Does anyone have ideas how to fix it? The only one I have is to disable the cache with a special flag, env't variable, sys variable/function or the like. We could make this available only in debug mode. The cache should normally be enabled, but could be disabled solely on the refleak runs. Suggestions? n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
Jeffrey Yasskin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] || To elaborate the point I was trying to make: If float() does not mean | the float part of The 'float part' of a complex number is meaningless since both components of a complex are floats (in practice, or reals in theory). The same is true in polar representation. | and should not take a complex argument (which I | completely agree with), then int() does not mean the int part of and | should not take a float argument. The 'integer (int) part' of a float/rational/real is established thru decades of usage. Your consequent is false and in no way follows from your antecendent. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Organization of ABC modules
Nick Coghlan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Raymond Hettinger wrote: | A prefix would be better. | | I initially thought that, but found the suffix to be the least annoying | of the ideas I had for denoting abstract base classes. To try and give || INumber || ABCNumber | AbcNumber | [etc] | After those 3, I couldn't think of any other prefixes that were both | short and likely to be an effective mnemonic for identifying ABC's - | instead of Abstract base class, etc. ... | NumberABC I *think* I would prefer to any of these either ANumber or aNumber, which one can read as either an abbreviation of Abstract Number or simply a contraction of 'a Number' (a Real, an Integral, etc) taken to mean the abstraction. | any convention that gets adopted is going to be by Guido's fiat and will | need to suit his aesthetic sense rather than mine :) One more possibility for him to consider. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
On Jan 26, 2008 2:53 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: [Jeffrey] I've been advocating trunc() under the assumption that int(float) would be deprecated and eliminated as soon as practical And how much code would break for basically zero benefit? We'll see. Jeffrey did say deprecated and as soon as practical. A -3 warning in 2.6 could do wonders. This position is totally nuts. Hold it right there. You may disagree, but that doesn't make it nuts. There is actually quite an important signal to the reader that is present when you see trunc(x) but absent when you see int(x): with trunc(x), the implication is that x is a (Real) number. With int(x), you can make no such assumption -- x could be a string, or it could be a totally different type that happens to define __int__, perhaps a custom date/time type (I believe mxDateTime supports this). There is *nothing* wrong with int() as it stands now. Nobody has problems with it. The tools is ubiquitous in other languages, Talk to C++ experts. They have a huge beef with C's confusing use of casts for two different purposes: reinterpretation of the same bit pattern vs. value conversion. Python problem isn't quite the same, but I still really wish I had followed Pascal's lead instead of C's here: Pascal requires you to use trunc() to convert a real to an integer. (BTW Pascal also had the division operator right, unlike C, and we're finally fixing this in Py3k by following Pascal's nearly-40-year-old lead.) If we had done it that way, we wouldn't have had to introduce the index() builtin and the corresponding infrastructure (__index__ and a whole slew of C APIs). spreadsheets, and calculators. I don't think that Excel should be held up as a shining example for Python. At least, that would be quite a change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
. You may disagree, but that doesn't make it nuts. Too many thoughts compressed into one adjective ;-) Deprecating int(float)--int may not be nuts, but it is disruptive. Having both trunc() and int() in Py2.6 may not be nuts, but it is duplicative and confusing. The original impetus for facilitating a new Real type being able to trunc() into a new Integral type may not be nuts, but the use case seems far fetched (we're never had a feature request for it -- the notion was born entirely out of numeric tower considerations). The idea that programmers are confused by int(3.7)--3 may not be nuts, but it doesn't match any experience I've had with any programmer, ever. The idea that trunc() is beneficial may not be nuts, but it is certainly questionable. In short, the idea may not be nuts, but I think it is legitimate to suggest that it is unnecessary and that it will do more harm than good. I don't think that Excel should be held up as a shining example for Python. It is simply a datapoint. We don't care why they chose int() for truncation. The important thing is the subsequent user experiences which indicates that people do not have a problem with it. When it comes to int() and round(), people just get it. I've taught spreadsheets to a lot people and no one has ever construed int() as meaning round(). What was your experience with 18 years of python? Was it a recurring a point of confusion? On the newsgroup, helplist, and tutorial list, I never seen this come up as problem. I looked in other places for corroboration. My HP-12C has intg and frac buttons. In BASIC, int() means to return the integer part of a floating point number. The surprise find was that int() in Matlab and Maple means integrate :-) FWIW, Perl's int() does what ours currently does. One other thought: In Python, it has been nice that we have simple type coercions using the type name: * set(p)--qcan accept a list, tuple, string, or any iterable and make a set * int(p)--q can accept an int, long, float, or string and make an int * float(p)--q can accept an int, long, float, or string and make an int * list(p)--qcan accept a list, tuple, string, or any iterable and make a list * unicode(p)-- can accept a str, buffer, or unicode object and make a unicode object It's a bit weird to decide that int() needs to lose that capability so we get generalized Integrals as output. What's wrong with coercion to a concrete type? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
