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
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
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
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. :)
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
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
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.
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
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
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
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.
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
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
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
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
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
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.
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
.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()
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,
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
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
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
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
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
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
[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
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
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
45 matches
Mail list logo
