[Patches] import floatdivision # 1/2==0.5

M.-A. Lemburg mal@lemburg.com
Tue, 13 Jun 2000 12:54:34 +0200


Greg Stein wrote:
> 
> On Tue, Jun 13, 2000 at 10:19:54AM +0200, M.-A. Lemburg wrote:
> > Moshe Zadka wrote:
> > >
> > > On Mon, 12 Jun 2000, David Scherer wrote:
> > >
> > > > This patch provides a way to make 1/2==0.5 optional without introducing any
> > > > backward incompatibilities.  It provides a pseudomodule "floatdivision"
> > > > that, when imported, changes the behavior of the importing script at compile
> > > > time:
> > > >
> > > > import floatdivision
> > > > print 3/4             # 0.75
> > >
> > > -1 on that. I don't like language to be dependant on modules: no "library"
> > > can import this module, because it might break other code. On the other
> > > hand, no "application" can import this module, because it might break
> > > library code. Plus a general -1 on thrusting floating point in innocent
> > > people's faces.
> >
> > -1 from here too for much the same reasons.
> >
> > While introducing some kind of float division is probably a good
> > idea for CP4E, I wouldn't like to have to scan 100k LOCs just to
> > figure out which of them rely on 5/2 returning 2 instead of 2.5. Some
> > time ago there was a discussion about introducing 5//2 to
> > give 2.5 (or was it the other way around ?).
> >
> > Note that writing 3/4. will solve the problem without any
> > new language features. For variable arguments you can write
> > a/float(b) which is pretty nice to read too.
> 
> Um... guys? David's patch uses lexical scoping to determine where the "/"
> operator does a float division. There isn't any cross-module or
> application-level problems.
> 
> If a module is designed to use float division, then it includes the thing at
> the top. If just a single function wants it, then the "import" (which it
> really isn't) occurs in the function body. Want it for a class? Then do the
> import in the classdef portion, before the method definitions.
> 
> Go read the patch :-)

Wasn't inlined by my mailer and I was too lazy to save
it first :-)

Still, I'd rather like to see some kind of pragma keyword
for these kind of semantic changes... I have to admit that
the hack is a cool one though -- perhaps we could use something
similar for the source code encoding stuff ?!

I'm still -1 on changing semantics/syntax via imports; +1 on
doing so via pragma or some_other_hairy_keyword_to_scare_away_newbies ;-)

Seriously, neither import nor pragma will help newbies
make use of  '·/·' ::= '·/float(·)'.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/