> 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 i
""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 i
"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
nothi
"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 s
> 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
__
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 numb
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
>
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 pre
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
>
> 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
__
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 c
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 c
> 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
___
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
On 2008-01-25 21:26, Steve Holden wrote:
> Antoine Pitrou wrote:
>> Raymond Hettinger 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 th
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.
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.
Antoine Pitrou wrote:
> Raymond Hettinger 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 wor
[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
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,
> avoid
>.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()
w
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 opi
Raymond Hettinger 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 ce
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,
[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,
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
> 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 f
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 t
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,
> avoid
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 elim
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. :)
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;
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
>
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
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,
> avoid
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
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 humbl
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
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
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()
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/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
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 la
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
> > instea
46 matches
Mail list logo
