Re: [Python-Dev] why is mmap a builtin module on windows?
Ralf Schmitt wrote: i.e. create visual studio project files for those modules? and make them built automatically? It's not that simple. You also have to integrate it into the build and carefully arrange the dependencies. You also have to find a free and sensible base address for the dll. At last the new modules must be integrated into the MSI installer script. 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] why is mmap a builtin module on windows?
On Jan 23, 2008 10:12 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: On Windows lots of modules are linked into the python main dll. The file PC/config.c contains a list of all modules. From the point of the maintainer it's much easier to link the modules into the main dll instead of creating standalone dlls. I also suspect that it's much faster because relocation is slow (see PC/dllbase_nt.txt). Martin or Mark can give you a better answer. Actually, that *is* the current answer. That plus a remark Contributions are welcome, as long as they a) come with a clear, objective policy on what should go into pythonxy.dll and what not, and I'd say anything that is needed by import sys, os is a candidate for being included. Currently even the _csv module is a builtin module on windows. But then I don't know how much slower importing from a .pyd file is.. b) automate all aspects of adding modules that should not go into pythonxy.dll according to the policy. i.e. create visual studio project files for those modules? and make them built automatically? Regards, - Ralf ___ 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: On Jan 24, 2008 1:11 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: [...] One of my goals for trunc() is to replace the from-float use of int(), even though we can't remove it for backward-compatibility reasons. PEP 3141 says: Because the int() conversion implemented by float (and by decimal.Decimal) is equivalent to but less explicit than trunc(), let's remove it. (Or, if that breaks too much, just add a deprecation warning.) That needs to be updated and implemented. I think the decision was that removing float.__int__() would break too much, so it needs a deprecation warning in 3.0. It seems strange to me that a release that has the avowed intention of producing a more rational language by breaking backwards compatibility should start out with deprecation warnings of this type. What's next: This isn't Perl when someone tries to add a number and a string? Surely the place to raise warnings is in 2to3. 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] trunc()
2008/1/25, Jeffrey Yasskin [EMAIL PROTECTED]: decision comes to be that int(float) should be blessed as a correct way to truncate a float, I'd agree with Raymond that trunc() is just duplication and should be eliminated. I'd, of course, rather have a spelling that says what it means. :) Mmm... no. int() is a builtin way to transform the builtin data type float into the builtin data type float. There's no correct way for a float to become an integer, but in the math module you have several ways to do it (floor, ceil, round, trunc, choose the one that you want, but you're notified wink/2 that there're different ways to do it). -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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()
Raymond Hettinger python at rcn.com writes: Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art: Well, for what it's worth, here are MySQL's own two cents: mysql create table t (a int); Query OK, 0 rows affected (0.00 sec) mysql insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql select * from t; +--+ | a| +--+ |1 | |2 | | -2 | | -1 | +--+ 4 rows in set (0.00 sec) ___ 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
Jeffrey Yasskin wrote: That's a good point. Someone already convinced me to name the test for numbers.py, test_abstract_numbers.py, so renaming the module makes sense too, although I agree that collections, which contains some concrete classes, should keep its current name. If others agree, want to send a patch? I'm not so worried about the name of the numbers module, 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. 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] Organization of ABC modules
On Jan 25, 2008 9:31 PM, Nick Coghlan [EMAIL PROTECTED] wrote: Raymond Hettinger wrote: If you want ABCs to be more easily recognizable as such, perhaps we could use a naming convention, Essentially, that's all I was asking for. It doesn't really matter to me whether numbers.py gets called abc_numbers or abc.numbers. Either one would be an improvement. I think the module level is the wrong granularity to be thinking about this - look at a module like collections, which contains not only ABC's related to containers, but also some useful concrete containers like deque and namedtuple. Any naming convention would have to be at the class level. For example: class NumberABC(metaclass=ABCMeta): ... class ComplexABC(NumberABC): ... class RealABC(ComplexABC): ... class RationalABC(NumberABC): ... class IntegralABC(RationalABC): ... I think adopting such a convention (at least for the standard library) would actually be useful. Normally, finding isinstance() type checks in code bothers me severely as it usually indicates that duck-typing has been broken. On the other hand, if I find a check in code that does something like: if not isinstance(x, NumberABC): raise TypeError(Not a number!) it would clearly still be extensible, as I would know just from the naming convention that a third party can register their type with NumberABC to make it usable with this function. Without a naming convention, I would always have to go check the definition of the type in the isinstance() call to see if the code was legitimate. That's a good point. Someone already convinced me to name the test for numbers.py, test_abstract_numbers.py, so renaming the module makes sense too, although I agree that collections, which contains some concrete classes, should keep its current name. If others agree, want to send a patch? -- 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()
Jeroen Ruigrok van der Werven wrote: Can I assume we are all familiar with the concept of significant digits and that we agree that from this point of view 2 != 2.0? And that results such as the above would be a regression and loss in precision? Not really, because if someone cares about precision to that extent they won't be using binary floats anyway (they'll be using Decimal, or something like it). Besides, for trunc, ceil and floor, it's all zeroes after the decimal point by definition (no matter how many significant digits you started with). 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] Organization of ABC modules
Raymond Hettinger wrote: If you want ABCs to be more easily recognizable as such, perhaps we could use a naming convention, Essentially, that's all I was asking for. It doesn't really matter to me whether numbers.py gets called abc_numbers or abc.numbers. Either one would be an improvement. I think the module level is the wrong granularity to be thinking about this - look at a module like collections, which contains not only ABC's related to containers, but also some useful concrete containers like deque and namedtuple. Any naming convention would have to be at the class level. For example: class NumberABC(metaclass=ABCMeta): ... class ComplexABC(NumberABC): ... class RealABC(ComplexABC): ... class RationalABC(NumberABC): ... class IntegralABC(RationalABC): ... I think adopting such a convention (at least for the standard library) would actually be useful. Normally, finding isinstance() type checks in code bothers me severely as it usually indicates that duck-typing has been broken. On the other hand, if I find a check in code that does something like: if not isinstance(x, NumberABC): raise TypeError(Not a number!) it would clearly still be extensible, as I would know just from the naming convention that a third party can register their type with NumberABC to make it usable with this function. Without a naming convention, I would always have to go check the definition of the type in the isinstance() call to see if the code was legitimate. 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] Simple syntax proposal: not is
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'. | 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. -1 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
Raymond Hettinger wrote: If you want ABCs to be more easily recognizable as such, perhaps we could use a naming convention, Essentially, that's all I was asking for. It doesn't really matter to me whether numbers.py gets called abc_numbers or abc.numbers. Either one would be an improvement. abstract_numbers would seem to express the essence without focusing on the mechanism unduly. Of course no sane person would suggest using a keyword, like import abstract numbers Wouldn't want to let reader know what was going on ... 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
[Python-Dev] Organization of ABC modules
All of the abstract base classes should be collected in one place. I propose that the modules be collected into a package so that we can write: import abc.numbers import abc.collections . . . Besides collecting all the relevant code in one place, it has a nice additional benefit of clearly designating when you're working with one of the provided abstract base classes. When I see import numbers, I don't immediately recognize this as being somehow different from import math or some other concrete implementation. IMO. the emerging practice of spreading modules these across the library isn't serving us well. 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()
trunc() has well-defined semantics -- it takes a Real instance and converts it to an Integer instance using round-towards-zero semantics. int() has undefined semantics -- it takes any object and converts it to an int (a concrete type!) So, the problem is basically this: Since int(o) must return an int, you're precluded from defining a new Real class with an __int__() method that returns an instance of some new Integral class that isn't an int. And the proposed solution is: Introduce trunc(o) which calls o.__trunc__() which can return any Integral type. And, client code must use trunc() instead of int(); otherwise, the two new numeric types won't be exercised. Is that basically what trunc() is all about -- a variant of int() that can return something other than an int type -- something that behaves just like the new math.floor() for positive numbers and math.ceil() for negative numbers? If so, I think we would be *much* better-off leaving trunc() out entirely and seeing if any use cases arise that aren't handled by math.floor() and math.ceil() with their precise semantics, unambigous naming, and ability to handle generic Reals and Integrals. The existence of trunc() clashes so severely with existence of int(), that we need to be damned sure that there are real-world, worthwhile problems that are not readily solved with floor() and ceil() for rounding Reals into Integrals or with int() for making ints from the non-fractional portion of a float. 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] Organization of ABC modules
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. 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] Organization of ABC modules
If you want ABCs to be more easily recognizable as such, perhaps we could use a naming convention, Essentially, that's all I was asking for. It doesn't really matter to me whether numbers.py gets called abc_numbers or abc.numbers. Either one would be an improvement. 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()
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. And I would prefer the float-input-only converters be in math. There is nothing second-class, really, about functions in modules. Just more specific. 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()
Hello, Two points. Firstly, regarding MySQL as authoritative from a standards point of view is bound to lead to trouble, since they have always played fast and loose with the standard for reasons (I suspect) of implementation convenience. To that I heartily agree. I was just pointing out that implicit conversion of float to int did not always use the moral equivalent of trunc() under all programming platforms. That said, I don't think it's that important, it's just something you have to learn. Regards Antoine. ___ 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
Guido van Rossum wrote: On Jan 25, 2008 8:13 AM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: 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. 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. Sorry, but this use case just doesn't sound strong enough to change a programming language's grammar. While I promise you I will remain -1 on the proposal simply because it doesn't serve any programmer's goals, you've piqued my curiosity -- can you give an example of what your tool does? From your description I actually have no clue. It not does sound like a very good idea to me. 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] trunc()
On Jan 25, 2008, at 1:22 PM, Raymond Hettinger wrote: I wouldn't fret about this too much. Intrepreting int(f) as meaning truncate has a *long* history in *many* programming languages. It is a specious argument int(f) is ambiguous. No one thinks it means ceil(f). Not that I think my opinion will have any weight in this discussion, but I'd agree that int has a long history not likely to be misinterpreted when applied to real numbers. Quoting from Graham, Knuth and Patashnik Concrete Mathematics...2nd edition page 67: We start by covering the floor (greatest integer) and ceiling (least integer) functions, which are defined for all real x... ...some pocket calculators have an INT function, defined as floor(x) when x is positive and ceil(x) when x is negative. The designers of these calculators probably wanted their INT function to satisfy the identity INT(-X) = -INT(X). But we'll stick to our floor and ceiling functions, because they have even nicer properties than this. jared ___ 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 am still recovering, so if I say something totally misinformed I blame my recovery. :) ] -On [20080125 15:12], Christian Heimes ([EMAIL PROTECTED]) wrote: Python 3:0 2.4 ( 2, 3, 2, 2, 2) 2.6 ( 2, 3, 3, 2, 2) -2.4 (-3, -2, -2, -2, -2) -2.6 (-3, -2, -3, -2, -2) Python 2.6: 2.4 ( 2.0, 3.0, 2.0, 2, 2) 2.6 ( 2.0, 3.0, 3.0, 2, 2) -2.4 (-3.0, -2.0, -2.0, -2, -2) -2.6 (-3.0, -2.0, -3.0, -2, -2) Am I the only one who wonders about the sudden change in decimal significance? Especially given the fact that the ISO C standard specifies floor(), for example, as returning a floating point value and the above in Python 3.0 deviates to just returning an integer. Which is also different from 2.5's behaviour. Can I assume we are all familiar with the concept of significant digits and that we agree that from this point of view 2 != 2.0? And that results such as the above would be a regression and loss in precision? -- 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
Re: [Python-Dev] trunc()
If the decision comes to be that int(float) should be blessed as a correct way to truncate a float, I'd agree with Raymond that trunc() is just duplication and should be eliminated. Yay, we've make progress! I'd,of course, rather have a spelling that says what it means. :) I wouldn't fret about this too much. Intrepreting int(f) as meaning truncate has a *long* history in *many* programming languages. It is a specious argument int(f) is ambiguous. No one thinks it means ceil(f). Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art: SQL: The INT() function returns its numeric argument with any fractional digits removed and truncates all digits to the right of the decimal point. www.basis.com/onlinedocs/documentation/b3odbc/bbjds_int_function.htm VB: Both the Int and Fix functions remove the fractional part of Number and return the resulting integer value. http://msdn2.microsoft.com/en-us/library/xh29swte.aspx Excel: The Int function returns the integer portion of a number. http://www.techonthenet.com/excel/formulas/int.php These docs suggest where the thinking has gone wrong. Writing int(f) doesn't mean arbritrary select one of round|ceil|floor|trunc as a way of getting to an integer; instead, it means return the integer portion (non-fractional component) of a number. The latter definition seems common and is entirely unambiguous. 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] Simple syntax proposal: not is
On Jan 25, 2008 8:13 AM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: 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. 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. Sorry, but this use case just doesn't sound strong enough to change a programming language's grammar. While I promise you I will remain -1 on the proposal simply because it doesn't serve any programmer's goals, you've piqued my curiosity -- can you give an example of what your tool does? From your description I actually have no clue. -- --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()
On Jan 25, 2008 9:45 AM, Facundo Batista [EMAIL PROTECTED] wrote: 2008/1/25, Jeffrey Yasskin [EMAIL PROTECTED]: decision comes to be that int(float) should be blessed as a correct way to truncate a float, I'd agree with Raymond that trunc() is just duplication and should be eliminated. I'd, of course, rather have a spelling that says what it means. :) Mmm... no. int() is a builtin way to transform the builtin data type float into the builtin data type float. I assume you meant int instead of your second float. There doesn't have to be a way to convert from every builtin type to every other builtin type. Take dict(float), for example. Further, if there is a conversion, no law says it has to be named the same as the target type. If there are two plausible ways to get from the source to the target, using just the target's name to pick out one of them is really a terrible idea. But, just because the designers of C made a bad decision that we've inherited, doesn't mean that it's a terrible idea to keep it. As Nick said, defining int(float) as truncation has a long history, and there are some obvious costs to breaking away from that. I think it is time to correct the mistake, but it's not an open and shut case. -- 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()
On Jan 25, 2008 5:53 AM, Paul Moore [EMAIL PROTECTED] wrote: 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. - make int(float) an error I'd deal with Facundo's objection that you should be able to convert between builtin datatypes without the use of a module by leaving trunc in the builtins, but it looks like I'm in the minority here. If the decision comes to be that int(float) should be blessed as a correct way to truncate a float, I'd agree with Raymond that trunc() is just duplication and should be eliminated. I'd, of course, rather have a spelling that says what it means. :) The only fly in the ointment is that 2to3 can't handle the semantic issues around converting int(n) to math.trunc(n) because it can't detect the type of n. So why not make int(float) warn in -3 mode on 2.6, and then let 2to3 do the conversion (on the basis that 2to3 should only be run on code that is -3 warning free)? I'd be happy with that too. -- 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] Simple syntax proposal: not is
Jameson Chema Quinn wrote: 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. Your editor is going to have to deal with code written the normal way anyway - given that this is a pretty special case, the special handling should stay in the tool that needs it (your editor) not in the programming language. As you say, Python is heavily influenced by English, and in English a not is b is out-and-out nonsense (there is no way to build a coherent parse tree with that word order), while not a is b and a is not b both make sense (although you are correct in pointing out that the latter is technically ambiguous as an English phrase). is not and not in are just normal binary operators that happen to consist of two words in the concrete syntax - your editor is going to need to be able to deal with that (even if that means having to handle translations that span multiple words). 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
[Python-Dev] Simple syntax proposal: not is
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. 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. ___ 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()
Paul Moore wrote: 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. - make int(float) an error Slightly different suggestion: - define int(float) as int(trunc(float)) In my humble opinion lots of people expect int(-2.5) == -2 and int(2.5) == 2. Or in other words: int(float) chops of the digits after the dot. As far as I can see float.__int__ already behaves like int(trunc(float)) for n in (2.4, 2.6, -2.4, -2.6): ... print(n, (math.floor(n), math.ceil(n), round(n), trunc(n), int(n))) ... Python 3:0 2.4 ( 2, 3, 2, 2, 2) 2.6 ( 2, 3, 3, 2, 2) -2.4 (-3, -2, -2, -2, -2) -2.6 (-3, -2, -3, -2, -2) Python 2.6: 2.4 ( 2.0, 3.0, 2.0, 2, 2) 2.6 ( 2.0, 3.0, 3.0, 2, 2) -2.4 (-3.0, -2.0, -2.0, -2, -2) -2.6 (-3.0, -2.0, -3.0, -2, -2) 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] trunc()
On 25/01/2008, Facundo Batista [EMAIL PROTECTED] wrote: - make int(float) an error -0 (you should be able to convert between builtin datatypes without the use of a module). Good point. +1 to keep it and define exactly the behaviour, and point to math module in the documentation if you want better control over the conversion. Sonds good. Paul ___ 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()
2008/1/25, Paul Moore [EMAIL PROTECTED]: - int() has to stay in builtins for obvious reasons. +1 - put *all* of trunc, ceil, floor, round into math. +1 - make int(float) an error -0 (you should be able to convert between builtin datatypes without the use of a module). +1 to keep it and define exactly the behaviour, and point to math module in the documentation if you want better control over the conversion. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
On Jan 25, 2008 3:15 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: All of the abstract base classes should be collected in one place. I propose that the modules be collected into a package so that we can write: import abc.numbers import abc.collections . . . Besides collecting all the relevant code in one place, it has a nice additional benefit of clearly designating when you're working with one of the provided abstract base classes. When I see import numbers, I don't immediately recognize this as being somehow different from import math or some other concrete implementation. IMO. the emerging practice of spreading modules these across the library isn't serving us well. I don't think so. Things should be grouped by application area, not by some property like uses metaclasses or defines abstract base classes or overrides operators. The old types module collected all built-in types and it was a mistake. You might as well propose that all decorators should live in the same package, or all generic functions (if we ever have them). There's a lot more synergy between the collection ABCs and other collections than between collection ABCs and number ABCs. Another angle: the io.py module also uses ABCs. Should it therefore be a subpackage of ABC? No way! If you want ABCs to be more easily recognizable as such, perhaps we could use a naming convention, though personally I think we don't need that either -- the generic names like Sequence or Real are enough of a tip-off that these are type categories and not implementation types. -- --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] trunc()
Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | If the ambiguity is that 'int' behaviour is unspecified for floats - is | it naive to suggest we specify the behaviour? | | The concern is that whatever gets specified is arbitrary. There are many | ways how an int can be constructed from a float, so why is any such way | better than the others, and deserves to be the meaning of int()? Decades of usage, in English, with the meaning it already has in Python. ___ 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 2008-01-25 21:26, Steve Holden wrote: Antoine Pitrou wrote: Raymond Hettinger python at rcn.com writes: Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art: Well, for what it's worth, here are MySQL's own two cents: mysql create table t (a int); Query OK, 0 rows affected (0.00 sec) mysql insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql select * from t; +--+ | a| +--+ |1 | |2 | | -2 | | -1 | +--+ 4 rows in set (0.00 sec) Two points. Firstly, regarding MySQL as authoritative from a standards point of view is bound to lead to trouble, since they have always played fast and loose with the standard for reasons (I suspect) of implementation convenience. Second, that example isn't making use of the INT() function. I was going to show you result of taking the INT() of a float column containing your test values. That was when I found out that MySQL (5.0.41, anyway) doesn't implement the INT() function. What was I saying about standards? FWIW, here's what IBM has to say to this: http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r814.htm If the argument is a numeric-expression, the result is the same number that would occur if the argument were assigned to a large integer column or variable. If the whole part of the argument is not within the range of integers, an error occurs. The decimal part of the argument is truncated if present. AFAIK, the INTEGER() function is not part of the SQL standard, at least not of SQL92: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt The way to convert a value to an integer is by casting it to one, e.g. CAST (X AS INTEGER). The INT() function is basically a short-cut for this. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 25 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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 25/01/2008, Guido van Rossum [EMAIL PROTECTED] wrote: Does no-one thinks it means round(f) either? That's the main confusion here (plus the fact that in C it's undefined -- or at some point was undefined). Not me. My intuition agrees with Raymond that int means the integer part of, i.e. trunc(), when dealing with a numeric argument. (int(string) is a different matter, and I have no problem having different intuitions for that. So sue me) I'd like to keep trunc (as math.trunc) for those cases where I want to be completely explicit, but it's not a big deal to me. BTW the list of functions considered here should include round() in addition to ceil(), floor(), and trunc(), even if 2-arg round() doesn't quite fit. My original message suggested that round go into math as well. It didn't get much comment, though, as everyone latched onto the more controversial suggestion that int(float) be an error - which is the bit I was least concerned about, ironically. Paul. ___ 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 8:13 AM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: 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. 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. not is makes no sense to -- and is not easily parsed by -- my English-native mind. Collin Winter ___ 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()
.some pocket calculators have an INT function, defined as floor(x) when x is positive and ceil(x) when x is negative That's the mathematical definition. The way they explain it is dirt simple: return the integer portion of a number. Some of the calculators that have int() also have frac() which has the obvious interpretation. 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 Fri, Jan 25, 2008 at 11:32:54AM -0800, Guido van Rossum wrote: Does no-one thinks it means round(f) either? I don't think so. I often emulate round(f) as int(f + 0.5). Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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 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. - make int(float) an error The only fly in the ointment is that 2to3 can't handle the semantic issues around converting int(n) to math.trunc(n) because it can't detect the type of n. So why not make int(float) warn in -3 mode on 2.6, and then let 2to3 do the conversion (on the basis that 2to3 should only be run on code that is -3 warning free)? Did I miss a requirement here? Paul. ___ 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 9:13 AM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: 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. -1. There should be one obvious way to do it. And honestly, if you're dealing with natural language, and your system is not able to change word order words between languages, you're in a lot of trouble already. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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 wrote: Paul Moore wrote: Suggestion: - int() has to stay in builtins for obvious reasons. - put *all* of trunc, ceil, floor, round into math. - make int(float) an error Slightly different suggestion: - define int(float) as int(trunc(float)) In my humble opinion lots of people expect int(-2.5) == -2 and int(2.5) == 2. Or in other words: int(float) chops of the digits after the dot. FWIW, this approach gets a +1 from me (although I'm -0 on taking round() out of builtins - that seems like a pointless incompatibility to me). Yes, blessing 'trunc' as the default mechanism for converting a non-integral number to an integer is somewhat arbitrary, but it's a piece of arbitrariness with a very long history behind it. For that matter, we could even formally define int() as falling back to trunc() if there is no direct conversion (i.e. int knows about the type natively, or the type provides an __int__ method). That way non-integral types could just implement __trunc__ without having to worry about adding __int__ = __trunc__ to the class definition. We would still have operator.index to identify types which can be losslessly converted to a builtin integer. 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] trunc()
On Jan 25, 2008 4:28 AM, Facundo Batista [EMAIL PROTECTED] wrote: 2008/1/24, Guido van Rossum [EMAIL PROTECTED]: So you won't be able to construct an int from a float? That sucks (and is unintuitive). Yes, you can, but you have to specify how you want it done by using trunc() or round() or ceil() or floor(). (In 3.0, round(x) will return an int, not a float.) 2008/1/24, Jeffrey Yasskin [EMAIL PROTECTED]: That needs to be updated and implemented. I think the decision was that removing float.__int__() would break too much, so it needs a deprecation warning in 3.0. What I understand here is as int() is ambiguous, in the future if you want to specify how you want to convert a float to int. But ceil and floor returns a float. And round and trunc will return an int. So, how I could convert a float to its upper int? Like this?: trunc(math.ceil(.3)) 1 Like this, in 3.0: math.ceil(2.2) 3 There was a previous thread in which we decided not to change that behavior in 2.6. BTW, int is not giving me a deprecation warning: int(.1) 0 Correct; that's not implemented yet. -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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 12:45 PM, Facundo Batista [EMAIL PROTECTED] wrote: Mmm... no. int() is a builtin way to transform the builtin data type float into the builtin data type float [sic]. There's no correct way for a float to become an integer, but in the math module you have several ways to do it (floor, ceil, round, trunc, choose the one that you want, but you're notified wink/2 that there're different ways to do it). In keeping with this theme, why not define int() for floats (and other real types) as def __int__(n, method=math.trunc) or something similar, so that, by default, int() provides the same functionality as before (or whatever is decided to be preferred, I'm making no judgements on that end), but has a way --- by passing a different function --- of changing the way it rounds? The other (probably preferred) option, I suppose, would be to provide a few constants (float.FLOOR_METHOD et al.) instead of passing an arbitrary function (which, of course, makes me a bit uncomfortable). -- Cheers, Leif ___ 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()
Does no-one thinks it means round(f) either? That's the main confusion here (plus the fact that in C it's undefined -- or at some point was undefined). BTW the list of functions considered here should include round() in addition to ceil(), floor(), and trunc(), even if 2-arg round() doesn't quite fit. --Guido On Jan 25, 2008 11:22 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: If the decision comes to be that int(float) should be blessed as a correct way to truncate a float, I'd agree with Raymond that trunc() is just duplication and should be eliminated. Yay, we've make progress! I'd,of course, rather have a spelling that says what it means. :) I wouldn't fret about this too much. Intrepreting int(f) as meaning truncate has a *long* history in *many* programming languages. It is a specious argument int(f) is ambiguous. No one thinks it means ceil(f). Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art: SQL: The INT() function returns its numeric argument with any fractional digits removed and truncates all digits to the right of the decimal point. www.basis.com/onlinedocs/documentation/b3odbc/bbjds_int_function.htm VB: Both the Int and Fix functions remove the fractional part of Number and return the resulting integer value. http://msdn2.microsoft.com/en-us/library/xh29swte.aspx Excel: The Int function returns the integer portion of a number. http://www.techonthenet.com/excel/formulas/int.php These docs suggest where the thinking has gone wrong. Writing int(f) doesn't mean arbritrary select one of round|ceil|floor|trunc as a way of getting to an integer; instead, it means return the integer portion (non-fractional component) of a number. The latter definition seems common and is entirely unambiguous. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
[GvR] Does no-one thinks it means round(f) either? Heck no. The int() and round() functions have been in Lotus and Excel for an eternity and nobody has a problem learning what those functions do. Also, the extra argument for round(f, n) makes it clear that it can return other floats rounded to n-digits. I've taught a lot of classes to spreadsheet users and have observed that people get it right away. 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()
Antoine Pitrou wrote: Raymond Hettinger python at rcn.com writes: Go ask a dozen people if they are surprised that int(3.7) returns 3. No one will be surprised (even folks who just use Excel or VB). It is foolhardy to be a purist and rage against the existing art: Well, for what it's worth, here are MySQL's own two cents: mysql create table t (a int); Query OK, 0 rows affected (0.00 sec) mysql insert t (a) values (1.4), (1.6), (-1.6), (-1.4); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql select * from t; +--+ | a| +--+ |1 | |2 | | -2 | | -1 | +--+ 4 rows in set (0.00 sec) Two points. Firstly, regarding MySQL as authoritative from a standards point of view is bound to lead to trouble, since they have always played fast and loose with the standard for reasons (I suspect) of implementation convenience. Second, that example isn't making use of the INT() function. I was going to show you result of taking the INT() of a float column containing your test values. That was when I found out that MySQL (5.0.41, anyway) doesn't implement the INT() function. What was I saying about standards? 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] why is mmap a builtin module on windows?
b) automate all aspects of adding modules that should not go into pythonxy.dll according to the policy. i.e. create visual studio project files for those modules? and make them built automatically? And adjust msi.py to package them automatically. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
