Re: Underscores in Python numbers
[EMAIL PROTECTED] (Bengt Richter) writes: >>Eric Jacoboni, ne il y a 1435938104 secondes > Um, about your sig ... ;-) Well, i confess it's Ruby code... Maybe, one day, i will try to write a Python Version (with DateTime, i guess?) but i'm afraid it doesn't change the result. -- Eric Jacoboni, ne il y a 1436041406 secondes -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Nov 19, Steven D'Aprano wrote: > Perhaps Python should concatenate numeric literals at compile time: > > 123 456 is the same as 123456. +1 for readability. But in support of no change, When was the last time you looked at long sequences of python digits outside of your editor/IDE? You probably don't deal with them interactively (and if you do you probably paste them in). So reasonable editors could just color groups differently. E.g.: 123456789012345 ^^^ red blue red -- _ _ ___ |V|icah |- lliott <>< [EMAIL PROTECTED] " " """ -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Bruno Desthuilliers wrote:
> So even if it's far from a common use case for *most* Python users, it
> may be a common use case for *some* Python users.
>
> Also, someone mentionned the use of Python as a configuration langage -
> which is probably a much more common use case.
>
> So FWIW, I'd be +1 on adding it *if and only if*:
> - it's trivial to implement [1]
> - it doesn't break older code
>
> and +1 on the space as group delimiter BTW.
>
> [1]: I never wrote a language by myself, but I've played a bit with
> parsers and lexers, and I _guess_ (which implies I may be wrong !-) it
> wouldn't require much work to add support for a "literal numeric
> grouping" syntax in Python.
Since I've been trying to speed up the digit-scan code, I can say that
any ignorable will slow the loop (counting digits gives you an integral
logarithm to the base, and you can tell if you can convert quickly).
However, Unicode must have ignore ables apparently, so (at least in the
Unicode case) they may have to be dealt with.
Also, a parser hack won't do (for speed), you have to get the entire
number and translate it at one go. The space smacks of expecting a
parser change, where you might expect:
pi = (3.1415926535 8979323846 2643383279 5028841971 6939937510
5820974944 5923078164 0628620899 8628034825 3421170679
8214808651 3282306647 0938446095 5058223172 5359408128 )
to work (allowing any whitespace and line breaks and ...).
Also, it would be a trifle frustrating to translate:
distance = (1 000 000 000 000 000
000 000 000 000 000.)
Which looks like an integer for a long time. I'd say if we go for
anything, we should follow the Ada lead of allowing underscore, only
allow single underscores (so 1__000 is an error). I am happier with
those applications that want this using their own function, however:
pi = FloatConv('3.1415926535 8979323846 2643383279 5028841971 '
'6939937510 5820974944 5923078164 0628620899 '
'8628034825 3421170679 8214808651 3282306647 '
'0938446095 5058223172 5359408128')
Since the use case is long constants, can we generally agree they
should be named and set out as globals in the module? And in such
a case, the cost of calling something like FloatConv (or whatever)
becomes negligible. As to interactive use, I just don't see that
having things like IntConv, FloatConv around strings is a real
hardship -- for me the hardship is almost always trying to verify
the digits are typed in correctly, not the extra function call.
--
-Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Op 2005-11-20, Roy Smith schreef <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] (David M. Cooke) wrote: > >> One example I can think of is a large number of float constants used >> for some math routine. In that case they usually be a full 16 or 17 >> digits. It'd be handy in that case to split into smaller groups to >> make it easier to match with tables where these constants may come >> from. Ex: >> >> def sinxx(x): >> "computes sin x/x for 0 <= x <= pi/2 to 2e-9" >> a2 = -0.1 4 >> a4 = 0.00833 33315 >> a6 = -0.00019 84090 >> a8 = 0.0 27526 >> a10= -0.0 00239 >> x2 = x**2 >> return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10 >> >> (or least that's what I like to write). Now, if I were going to higher >> precision, I'd have more digits of course. > > You have described, if memory serves, a Taylor series, and those > coefficients are 1/3!, 1/5!, 1/7!, etc. Well if you had infinite precision numbers you might be right. However in numerial analysis, one often uses numbers which are slightly different, in order to have a more uniform error spread over the interval used. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Peter Hansen>Or maybe one should instead interpret this as "numeric literals need more bells and whistles, and I don't care which of these two we add, but we have to do *something*!". :-) The purpose of my words was: when you think about adding a new syntax/functionality to a language, you have to think well if the same syntax can be used for something more important or more natural for it, so later you can avoid later problems and silly compromises. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Sun, 20 Nov 2005 15:50:10 +0100, Eric Jacoboni <[EMAIL PROTECTED]> wrote: >Mike Meyer <[EMAIL PROTECTED]> writes: > >> I've seen at least one language (forget which one) that allowed such >> separators, but only for groups of three. So 123_456 would be valid, >> but 9_1 would be a syntax error. > >Ada allows underscores in numeric literals since 1983, without >enforcing any grouping. The Ruby language allows also this >notation. You may write 1_000_001 or 1000_001 or 10_00_001, etc. (the >same for real numbers...). > Actually, I guess I could be convinced, even though I posted a you-can-do-this-now decorator to bracket the op's desired function defs. >When you have the habit to represent literals like that, all other >big numeric literals or workarounds to create grouping seem cryptic. > >-- >Eric Jacoboni, ne il y a 1435938104 secondes My previous smiley re your sig in this thread context still applies ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Sun, 20 Nov 2005 15:50:10 +0100, Eric Jacoboni <[EMAIL PROTECTED]> wrote: >Mike Meyer <[EMAIL PROTECTED]> writes: > >> I've seen at least one language (forget which one) that allowed such >> separators, but only for groups of three. So 123_456 would be valid, >> but 9_1 would be a syntax error. > >Ada allows underscores in numeric literals since 1983, without >enforcing any grouping. The Ruby language allows also this >notation. You may write 1_000_001 or 1000_001 or 10_00_001, etc. (the >same for real numbers...). > >When you have the habit to represent literals like that, all other >big numeric literals or workarounds to create grouping seem cryptic. > >-- >Eric Jacoboni, ne il y a 1435938104 secondes Um, about your sig ... ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Sun, 20 Nov 2005 15:37:40 +, Steve Holden <[EMAIL PROTECTED]> wrote:
>David M. Cooke wrote:
>> Peter Hansen <[EMAIL PROTECTED]> writes:
>>
>>
>>>Steven D'Aprano wrote:
>>>
Dealing with numeric literals with lots of digits is
a real (if not earth-shattering) human interface problem: it is hard for
people to parse long numeric strings.
>>>
>>>I'm totally unconvinced that this _is_ a real problem, if we define
>>>"real" as being even enough to jiggle my mouse, let alone shattering the
>>>planet.
>>>
>>>What examples does anyone have of where it is necessary to define a
>>>large number of large numeric literals? Isn't it the case that other
>>>than the odd constants in various programs, defining a large number of
>>>such values would be better done by creating a data file and parsing
>>>it?
>>
>>
>> One example I can think of is a large number of float constants used
>> for some math routine. In that case they usually be a full 16 or 17
>> digits. It'd be handy in that case to split into smaller groups to
>> make it easier to match with tables where these constants may come
>> from. Ex:
>>
>> def sinxx(x):
>> "computes sin x/x for 0 <= x <= pi/2 to 2e-9"
>> a2 = -0.1 4
>> a4 = 0.00833 33315
>> a6 = -0.00019 84090
>> a8 = 0.0 27526
>> a10= -0.0 00239
>> x2 = x**2
>> return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10
>>
>> (or least that's what I like to write). Now, if I were going to higher
>> precision, I'd have more digits of course.
>>
>Right, this is clearly such a frequent use case it's worth changing the
>compiler for.
>
Agreed, let the OP hack a special-purpose solution for a special-case problem,
e.g.
(tested just enough to show the idea on this post ;-)
>>> def fundef(funsrc, preprocess=None):
... def doprep(f):
... protect_f = {}
... try:
... src = funsrc.lstrip().rstrip()+'\n' # remove leading/trailing
blank lines
... exec (preprocess and preprocess(src) or src) in protect_f
... return type(f)(protect_f[f.func_name].func_code,
... f.func_globals, f.func_name, f.func_defaults,
f.func_closure)
... except Exception, e:
... raise ValueError, 'Unable to translate %r ... due to\n%s'%(
... funsrc.lstrip().splitlines()[0][:30], '%s:
%s'%(e.__class__.__name__, e))
... return doprep
...
Now that decorator allows you to pre-process a function source
(e.g. according to what the OP might want for a preprocess argument):
>>> import re
>>> numgap = re.compile(r'(\d+) (?=\d)')
>>> def prep(s): return numgap.sub(r'\1', s)
...
Then use it on the OP's example [1]
>>> @fundef("""
... def sinxx(x):
... "computes sin x/x for 0 <= x <= pi/2 to 2e-9"
... a2 = -0.1 4
... a4 = 0.00833 33315
... a6 = -0.00019 84090
... a8 = 0.0 27526
... a10= -0.0 00239
... x2 = x**2
... return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10
... """, preprocess=prep)
... def sinxx(x): pass # (defines signature and defaults in current scope)
...
[1] Note that no editing of previous source
is required except bracketing like
@fundef("""
... """, preprocess=prep)
That last line is required for the decorator, but also (I think, not tested)
defines
the signature and arg defaults in the current scope, as opposed to where exec
compiles
in the decorator.
>>> sinxx
>>> import math
>>> def mxx(x): return x and math.sin(x)/x or 1.0
...
>>> sinxx(0), mxx(0)
(1.0, 1.0)
>>> sinxx(.1), mxx(.1)
(0.99833416647076856, 0.99833416646828155)
>>> sinxx(.2), mxx(.2)
(0.99334665398326816, 0.99334665397530608)
>>>
Seems to work, approximately ;-)
>>> @fundef("""
... def poo()
... syntax problems
... """)
... def poo(): pass
...
Traceback (most recent call last):
File "", line 1, in ?
File "", line 10, in doprep
ValueError: Unable to translate 'def poo()' ... due to
SyntaxError: invalid syntax (line 1)
Some hope of somewhat useful exceptions too ;-)
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Peter Hansen wrote: > [EMAIL PROTECTED] wrote: > > Peter Hansen wrote: > > > >>But why would anyone want to create numeric literals for credit card > >>numbers? > >> > > May be for space saving ? But storage space being so cheap, this is not > > a very good reason, but still a reason. > > Space saving where? Why would you have any credit card numbers stored > in any application? Even a credit card company isn't going to write > code that has the numbers stored as *literals*! I am not the one asking for it, only guessing the reason and credit card company does save it in the database. So saving as half byte numeric(or 64 bit integer) does save a bit of space comparing with string. > > There's only one place I can think of right now where you might want > that: in automated tests for code that processes credit card numbers. > And you definitely do not need to "save space" in that situation... > That usually don't need it as one big number but usually more easier to code if treating as string(like checksum), something like: for digits in cc: checksum += int(digits) -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Raymond Hettinger a écrit : > Gustav Hållberg wrote: > >>I tried finding a discussion around adding the possibility to have >>optional underscores inside numbers in Python. This is a popular option >>available in several "competing" scripting langauges, that I would love >>to see in Python. >> >>Examples: >> 1_234_567 >> 0xdead_beef >> 3.141_592 > > > I suppose it could be done. OTOH, one could argue that most production > code has no business hardwiring-in numerical constants greater than 999 > ;-) > That's what I thought at first, but Steven D'Aprano made some good points here IMHO, ie : """ Not all numeric constants used have simple formulae, or *any* formulae, or can be calculated on the fly in any reasonable time. Numeric programming often uses magic constants which truly are "magic" (in the sense that where they come from requires deep, difficult, and sometimes hidden knowledge). Nobody sensible wants to be typing in long strings of digits, but sometimes it is unavoidable. """ and """ Another sensible usage case is in the interactive interpreter. If you are using Python interactively, you may wish to use numeric literals with large numbers of digits. It is not feasible to read them from a data file, and using a special converter function is impractical and unnecessary. """ So even if it's far from a common use case for *most* Python users, it may be a common use case for *some* Python users. Also, someone mentionned the use of Python as a configuration langage - which is probably a much more common use case. So FWIW, I'd be +1 on adding it *if and only if*: - it's trivial to implement [1] - it doesn't break older code and +1 on the space as group delimiter BTW. [1]: I never wrote a language by myself, but I've played a bit with parsers and lexers, and I _guess_ (which implies I may be wrong !-) it wouldn't require much work to add support for a "literal numeric grouping" syntax in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Sun, 20 Nov 2005 15:52:29 -0500, Roy Smith wrote: > You have described, if memory serves, a Taylor series, and those > coefficients are 1/3!, 1/5!, 1/7!, etc. What I would do, rather than > embedding the numeric constants in the code, is embed the formula and have > the machine compute the actual values at import time. At the very least, > have them machine generated and saved. You certainly don't want to be > typing in long strings of digits like that. Not all numeric constants used have simple formulae, or *any* formulae, or can be calculated on the fly in any reasonable time. Numeric programming often uses magic constants which truly are "magic" (in the sense that where they come from requires deep, difficult, and sometimes hidden knowledge). Nobody sensible wants to be typing in long strings of digits, but sometimes it is unavoidable. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Sun, 20 Nov 2005 09:27:28 -0500, Peter Hansen wrote: > But why would anyone want to create numeric literals for credit card > numbers? Credit card numbers is not a sensible usage case. Neither are books' ISBNs, or tax file numbers, or telephone numbers -- these are all instances where it makes sense to read them from a data file and use a converter function. One sensible usage case is numeric calculations, where you often are using numeric constants in some formula, and those constants may have ten, twelve, fifteen digits. Being able to group digits makes it considerable easier to enter the numbers, as well as proof-read your code. c = 25.173 268 901 910 023 is considerably easier for the human reader to parse than: c = 25.173268901910023 Calculating the number in place is not an acceptable solution: c = 25.173 + 268e-3 + 901e-6 + 910e-9 + 23e-12 is bad for a number of reasons: - it implies c is a calculated sum when it is not; - it harms comprehension; - it may very well lose accuracy; - it is easy to miscalculate and end up with a completely wrong number; - it complicates and obfuscates the compiled code. Another sensible usage case is in the interactive interpreter. If you are using Python interactively, you may wish to use numeric literals with large numbers of digits. It is not feasible to read them from a data file, and using a special converter function is impractical and unnecessary. I don't know whether these two usage cases will be enough to justify changing the way Python handles numeric literals -- Guido seems quite conservative in what he adds to the language, so unless there is either great demand or it scratches a particular itch he has personally, I doubt it will fly. But we'll never know unless we try, hey? *wink* -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
[EMAIL PROTECTED] (David M. Cooke) wrote: > One example I can think of is a large number of float constants used > for some math routine. In that case they usually be a full 16 or 17 > digits. It'd be handy in that case to split into smaller groups to > make it easier to match with tables where these constants may come > from. Ex: > > def sinxx(x): > "computes sin x/x for 0 <= x <= pi/2 to 2e-9" > a2 = -0.1 4 > a4 = 0.00833 33315 > a6 = -0.00019 84090 > a8 = 0.0 27526 > a10= -0.0 00239 > x2 = x**2 > return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10 > > (or least that's what I like to write). Now, if I were going to higher > precision, I'd have more digits of course. You have described, if memory serves, a Taylor series, and those coefficients are 1/3!, 1/5!, 1/7!, etc. What I would do, rather than embedding the numeric constants in the code, is embed the formula and have the machine compute the actual values at import time. At the very least, have them machine generated and saved. You certainly don't want to be typing in long strings of digits like that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
[EMAIL PROTECTED] wrote: > Peter Hansen wrote: > >>But why would anyone want to create numeric literals for credit card >>numbers? >> > May be for space saving ? But storage space being so cheap, this is not > a very good reason, but still a reason. Space saving where? Why would you have any credit card numbers stored in any application? Even a credit card company isn't going to write code that has the numbers stored as *literals*! There's only one place I can think of right now where you might want that: in automated tests for code that processes credit card numbers. And you definitely do not need to "save space" in that situation... -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
D H wrote:
> Steve Holden wrote:
> > David M. Cooke wrote:
> >> One example I can think of is a large number of float constants used
> >> for some math routine. In that case they usually be a full 16 or 17
> >> digits. It'd be handy in that case to split into smaller groups to
> >> make it easier to match with tables where these constants may come
> >> from. Ex:
> >>
> >> def sinxx(x):
> >> "computes sin x/x for 0 <= x <= pi/2 to 2e-9"
> >> a2 = -0.1 4
> >> a4 = 0.00833 33315
> >> a6 = -0.00019 84090
> >> a8 = 0.0 27526
> >> a10= -0.0 00239
> >> x2 = x**2
> >> return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10
> >>
> >> (or least that's what I like to write). Now, if I were going to higher
> >> precision, I'd have more digits of course.
> >>
> > Right, this is clearly such a frequent use case it's worth changing the
> > compiler for.
>
> Yes it is.
> In that one example he used digit grouping 5 more times than I've
> used lambda in my life. Remember people use python as a data format as
> well (see for example JSON).
> It's a simple harmless change to the parser: ignore underscores or
> spaces in numeric literals. As others have mentioned, Ruby supports
> this already, as do Ada, Perl, ML variants, VHDL, boo, nemerle, and others.
But that requirement can be served easily with something like this :
a2=my_decimal("-0.1 4")
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steve Holden wrote: > David M. Cooke wrote: >> One example I can think of is a large number of float constants used >> for some math routine. In that case they usually be a full 16 or 17 >> digits. It'd be handy in that case to split into smaller groups to >> make it easier to match with tables where these constants may come >> from. Ex: >> >> def sinxx(x): >> "computes sin x/x for 0 <= x <= pi/2 to 2e-9" >> a2 = -0.1 4 >> a4 = 0.00833 33315 >> a6 = -0.00019 84090 >> a8 = 0.0 27526 >> a10= -0.0 00239 >> x2 = x**2 >> return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10 >> >> (or least that's what I like to write). Now, if I were going to higher >> precision, I'd have more digits of course. >> > Right, this is clearly such a frequent use case it's worth changing the > compiler for. Yes it is. In that one example he used digit grouping 5 more times than I've used lambda in my life. Remember people use python as a data format as well (see for example JSON). It's a simple harmless change to the parser: ignore underscores or spaces in numeric literals. As others have mentioned, Ruby supports this already, as do Ada, Perl, ML variants, VHDL, boo, nemerle, and others. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
"Dan Bishop" <[EMAIL PROTECTED]> wrote:
> creditCardNumber = int('1234''5678''9012''3456''789')
Wow, I didn't know you could do that. That's better than my idea.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
David M. Cooke wrote: > Peter Hansen <[EMAIL PROTECTED]> writes: > > >>Steven D'Aprano wrote: >> >>>Dealing with numeric literals with lots of digits is >>>a real (if not earth-shattering) human interface problem: it is hard for >>>people to parse long numeric strings. >> >>I'm totally unconvinced that this _is_ a real problem, if we define >>"real" as being even enough to jiggle my mouse, let alone shattering the >>planet. >> >>What examples does anyone have of where it is necessary to define a >>large number of large numeric literals? Isn't it the case that other >>than the odd constants in various programs, defining a large number of >>such values would be better done by creating a data file and parsing >>it? > > > One example I can think of is a large number of float constants used > for some math routine. In that case they usually be a full 16 or 17 > digits. It'd be handy in that case to split into smaller groups to > make it easier to match with tables where these constants may come > from. Ex: > > def sinxx(x): > "computes sin x/x for 0 <= x <= pi/2 to 2e-9" > a2 = -0.1 4 > a4 = 0.00833 33315 > a6 = -0.00019 84090 > a8 = 0.0 27526 > a10= -0.0 00239 > x2 = x**2 > return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10 > > (or least that's what I like to write). Now, if I were going to higher > precision, I'd have more digits of course. > Right, this is clearly such a frequent use case it's worth changing the compiler for. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Mike Meyer <[EMAIL PROTECTED]> writes: > I've seen at least one language (forget which one) that allowed such > separators, but only for groups of three. So 123_456 would be valid, > but 9_1 would be a syntax error. Ada allows underscores in numeric literals since 1983, without enforcing any grouping. The Ruby language allows also this notation. You may write 1_000_001 or 1000_001 or 10_00_001, etc. (the same for real numbers...). When you have the habit to represent literals like that, all other big numeric literals or workarounds to create grouping seem cryptic. -- Eric Jacoboni, ne il y a 1435938104 secondes -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Peter Hansen wrote: > But why would anyone want to create numeric literals for credit card > numbers? > May be for space saving ? But storage space being so cheap, this is not a very good reason, but still a reason. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Dan Bishop wrote:
> Roy Smith wrote:
>>creditCardNumber = myInt ("1234 5678 9012 3456 789")
>
> Or alternatively, you could write:
>
> creditCardNumber = int('1234''5678''9012''3456''789')
Or creditCardNumber = int("1234 5678 9012 3456 789".replace(' ',''))
Or make a little function that does the same job and looks cleaner, if
you need this more than once.
But why would anyone want to create numeric literals for credit card
numbers?
-Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Roy Smith wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> > That's a tad unfair. Dealing with numeric literals with lots of digits is
> > a real (if not earth-shattering) human interface problem: it is hard for
> > people to parse long numeric strings.
>
> There are plenty of ways to make numeric literals easier to read without
> resorting to built-in language support. One way is:
>
> sixTrillion = 6 * 1000 * 1000 * 1000 * 1000
>
> Or, a more general solution might be to write a little factory function
> which took a string, stripped out the underscores (or spaces, or commas, or
> whatever bit of punctuation turned you on), and then converted the
> remaining digit string to an integer. You could then write:
>
> creditCardNumber = myInt ("1234 5678 9012 3456 789")
Or alternatively, you could write:
creditCardNumber = int('1234''5678''9012''3456''789')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Peter Hansen <[EMAIL PROTECTED]> writes: > Steven D'Aprano wrote: >> Dealing with numeric literals with lots of digits is >> a real (if not earth-shattering) human interface problem: it is hard for >> people to parse long numeric strings. > > I'm totally unconvinced that this _is_ a real problem, if we define > "real" as being even enough to jiggle my mouse, let alone shattering the > planet. > > What examples does anyone have of where it is necessary to define a > large number of large numeric literals? Isn't it the case that other > than the odd constants in various programs, defining a large number of > such values would be better done by creating a data file and parsing > it? One example I can think of is a large number of float constants used for some math routine. In that case they usually be a full 16 or 17 digits. It'd be handy in that case to split into smaller groups to make it easier to match with tables where these constants may come from. Ex: def sinxx(x): "computes sin x/x for 0 <= x <= pi/2 to 2e-9" a2 = -0.1 4 a4 = 0.00833 33315 a6 = -0.00019 84090 a8 = 0.0 27526 a10= -0.0 00239 x2 = x**2 return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10 (or least that's what I like to write). Now, if I were going to higher precision, I'd have more digits of course. -- |>|\/|< /--\ |David M. Cooke |cookedm(at)physics(dot)mcmaster(dot)ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Roy Smith <[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> wrote: >> I've seen at least one language (forget which one) that allowed such >> separators, but only for groups of three. > That seems a bit silly. Not all numbers are naturally split into groups of > three. Credit card numbers are (typically) split into groups of four. > Account numbers are often split into all sorts of random groupings. True. But how often do you want to add two account numbers, or multiply two credit card numbers? Or display them in hex, or otherwise treat them as something other than a string that happens to be composed of digits? http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Gustav Hållberg wrote: > I tried finding a discussion around adding the possibility to have > optional underscores inside numbers in Python. This is a popular option > available in several "competing" scripting langauges, that I would love > to see in Python. > > Examples: > 1_234_567 > 0xdead_beef > 3.141_592 I suppose it could be done. OTOH, one could argue that most production code has no business hardwiring-in numerical constants greater than 999 ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Mike Meyer <[EMAIL PROTECTED]> wrote: > I've seen at least one language (forget which one) that allowed such > separators, but only for groups of three. That seems a bit silly. Not all numbers are naturally split into groups of three. Credit card numbers are (typically) split into groups of four. Account numbers are often split into all sorts of random groupings. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Sat, 19 Nov 2005 13:08:57 -0500, Peter Hansen wrote: >> Umm... in other words, "the underscore is under-used so let's assign >> some arbitrary meaning to it" (to make the language more like Perl >> perhaps?). > > +1 > > I *really* don't like the idea of allowing underscores in numeric > literals. Firstly, for aesthetic reasons: I think 123_456 is seriously > ugly. Secondly, for pragmatic reasons, I think it is too easy to mistype > as 123-456. I know that Python can't protect you from typing 9-1 instead > of 901, but why add special syntax that makes that sort of error MORE > common?) I've seen at least one language (forget which one) that allowed such separators, but only for groups of three. So 123_456 would be valid, but 9_1 would be a syntax error. This kind of thing might help with the detecting typos issue, and probably won't be noticed by most users. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> That's a tad unfair. Dealing with numeric literals with lots of digits is
> a real (if not earth-shattering) human interface problem: it is hard for
> people to parse long numeric strings.
There are plenty of ways to make numeric literals easier to read without
resorting to built-in language support. One way is:
sixTrillion = 6 * 1000 * 1000 * 1000 * 1000
Or, a more general solution might be to write a little factory function
which took a string, stripped out the underscores (or spaces, or commas, or
whatever bit of punctuation turned you on), and then converted the
remaining digit string to an integer. You could then write:
creditCardNumber = myInt ("1234 5678 9012 3456 789")
Perhaps not as convenient as having it built into the language, but
workable in those cases which justify the effort.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steven D'Aprano wrote: > Dealing with numeric literals with lots of digits is > a real (if not earth-shattering) human interface problem: it is hard for > people to parse long numeric strings. I'm totally unconvinced that this _is_ a real problem, if we define "real" as being even enough to jiggle my mouse, let alone shattering the planet. What examples does anyone have of where it is necessary to define a large number of large numeric literals? Isn't it the case that other than the odd constants in various programs, defining a large number of such values would be better done by creating a data file and parsing it? And if that's the case, one could easily define any convention one desired for formatting the raw data. And for the odd constant, either take a moment to verify the value, or define it in parts (e.g. 24*60*60*1000*1000 microseconds per day), or write a nice little variant on int() that can do exactly what you would have done for the external data file if you had more values. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Sun, 20 Nov 2005 01:39:04 +, Steve Holden wrote: > Steven D'Aprano wrote: > [...] >> Likewise, base conversion into arbitrary bases is not, in my opinion, >> common enough a task that support for it needs to be built into the syntax >> for literals. If somebody cares enough about it, write a module to handle >> it and try to get it included with the Python standard modules. >> > In fact Icon managed to offer a syntax that allowed every base up to 36 > to be used: an "r" was used to indicate the radix of the literal, so hex > 453FF would be represented as "16r453FF". This worked fine. Upper- and > lower-case letters werw regarded as equivalent. Forth goes significantly further than that: you can tell the Forth interpreter what base you are using, and all numbers are then read and displayed using that base. Numbers were case sensitive, which meant Forth understood bases to at least 62. I don't remember whether it allows non-alphanumeric digits, and therefore higher bases -- I think it does, but am not sure. Nevertheless, I don't believe that sort of functionality belongs in the language itself. It is all well and good to be able to write 32r37gm, but how often do you really need to write numbers in base 32? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steven D'Aprano wrote: > That's a tad unfair. Dealing with numeric literals with lots of digits is > a real (if not earth-shattering) human interface problem: it is hard for > people to parse long numeric strings. In the wider world outside of IT, > people deal with long numeric digits by grouping. This is *exceedingly* > common: mathematicians do it, economists do it, everybody who handles long > numeric literals does it *except* computer language designers. However, what is the percentage of these big number literals appears in source code ? I believe most of them either appears in some data file(thus is nothing but string) or during data input(again string). Why change the language when we just want a smarter string converter ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steve Holden wrote: > Being European myself I am well aware of the notational differences of > the different locales, and I am perfectly happy that users can enter > numbers in their preferred format when they execute a program. > > However, I am not happy about the idea that a program source would need > to be edited before it would work after being moved to another locale. > Huh ? Up to now, all I am talking about is making the three init function(int/float/decimal) to be smarter on coverting string to their type. It doesn't affect the code in anyway if you don't need it or want to use it. It is more like a helper function for the issue of people are so concern about the seperators in big numbers. It introduce no new syntax to the language at all. And should you say use the imaginary format "E500.000,23", it still works no matter where your program is running or what the hosting locale is. Don't understand what changes you are referring to. We are facing similar issue today. A typical case is MM/DD/ date format. Or may be I need to import text file(csv for example) which may already contain numbers in this format. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steven D'Aprano wrote: [...] > Likewise, base conversion into arbitrary bases is not, in my opinion, > common enough a task that support for it needs to be built into the syntax > for literals. If somebody cares enough about it, write a module to handle > it and try to get it included with the Python standard modules. > In fact Icon managed to offer a syntax that allowed every base up to 36 to be used: an "r" was used to indicate the radix of the literal, so hex 453FF would be represented as "16r453FF". This worked fine. Upper- and lower-case letters werw regarded as equivalent. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Sat, 19 Nov 2005 13:08:57 -0500, Peter Hansen wrote: > Umm... in other words, "the underscore is under-used so let's assign > some arbitrary meaning to it" (to make the language more like Perl > perhaps?). +1 I *really* don't like the idea of allowing underscores in numeric literals. Firstly, for aesthetic reasons: I think 123_456 is seriously ugly. Secondly, for pragmatic reasons, I think it is too easy to mistype as 123-456. I know that Python can't protect you from typing 9-1 instead of 901, but why add special syntax that makes that sort of error MORE common?) > Or maybe one should instead interpret this as "numeric literals need > more bells and whistles, and I don't care which of these two we add, but > we have to do *something*!". :-) -1 That's a tad unfair. Dealing with numeric literals with lots of digits is a real (if not earth-shattering) human interface problem: it is hard for people to parse long numeric strings. In the wider world outside of IT, people deal with long numeric digits by grouping. This is *exceedingly* common: mathematicians do it, economists do it, everybody who handles long numeric literals does it *except* computer language designers. Depending on personal preference and context, we use any of comma, period, dash or space as a separator. Underscore is never used. Of these, the comma clashes with tuples, the period opens a rather large can of worms vis-a-vis internationalisation, and the dash clashes with the minus sign. Allowing spaces to group digits is subtle but effective, doesn't clash with other syntax, and is analogous to string concatenation. I don't believe it is either practical or desirable for a computer language to accept every conceivable digit separator in literals. If you need full support for internationalised numbers, that should go into a function. But the question of including a digit separator for numeric literals does solve a real problem, it isn't just meaningless bells and whistles. Likewise, base conversion into arbitrary bases is not, in my opinion, common enough a task that support for it needs to be built into the syntax for literals. If somebody cares enough about it, write a module to handle it and try to get it included with the Python standard modules. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
[EMAIL PROTECTED] wrote: > Steve Holden wrote: [...] >>I really wouldn't want it to become possible to write Python code in one >>locale that had to be edited before the numeric literals were valid in >>another locale. That way madness lies. > > That is the fact, from the very beginning. 1.234 striaightly speaking > can have different meaning,. So if you don't want, don't support it and > always use the non-European notation. > Being European myself I am well aware of the notational differences of the different locales, and I am perfectly happy that users can enter numbers in their preferred format when they execute a program. However, I am not happy about the idea that a program source would need to be edited before it would work after being moved to another locale. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steve Holden wrote:
> [EMAIL PROTECTED] wrote:
> > Stefan Rank wrote:
> >
> >>The other idea of teaching int() about separator characters has
> >>internationalis/zation issues:
> >>In many European countries, one would naturally try::
> >>
> >> int('500.000,23')
> >>
> >>instead of::
> >>
> >> int('500,000.23')
> >
> >
> > That is why I said
> >
> > "Of course, also support the locale variant where the meaning of ","
> > and
> > "." is swapped in most European countries. "
> >
> > We are seeing the same about base 2, 8, 10, 16.
> >
> > May be :
> >
> > int("E500.000,23")
> >
> > as we are using :
> >
> > 0x
> >
> > already for hex number
> >
> I really wouldn't want it to become possible to write Python code in one
> locale that had to be edited before the numeric literals were valid in
> another locale. That way madness lies.
That is the fact, from the very beginning. 1.234 striaightly speaking
can have different meaning,. So if you don't want, don't support it and
always use the non-European notation.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
[EMAIL PROTECTED] wrote: > Steven D'Aprano: >>Perhaps Python should concatenate numeric literals at compile time: >>123 456 is the same as 123456. > > I think using the underscore it is more explicit: > n = 123_456 > > Alternatively the underscore syntax may be used to separate the number > from its base: > 22875 == 22875_10 == 595b_16 == 123456_7 > But probably this is less commonly useful (and not much explicit). Umm... in other words, "the underscore is under-used so let's assign some arbitrary meaning to it" (to make the language more like Perl perhaps?). Or maybe one should instead interpret this as "numeric literals need more bells and whistles, and I don't care which of these two we add, but we have to do *something*!". :-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Roy Smith>We already have a perfectly good syntax for entering octal
and hex integers,
There is this syntax:
1536 == int("600", 16)
that accepts strings only, up to a base of 36.
There are the hex() and oct() functions.
There is the %x and %o sintax, that isn't easy to remember.
There are the 0x600 and 0600 syntaxes that probably look good only from
the point of view of a C programmer.
I think some cleaning up, with a simpler and more consistent and
general way of converting bases, can be positive. But probably no one
shares this point of view, and compatibility with C syntax is probably
positive, so you are right. I am still learning the correct way of
thinking in python.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
[EMAIL PROTECTED] wrote:
> Stefan Rank wrote:
>
>>The other idea of teaching int() about separator characters has
>>internationalis/zation issues:
>>In many European countries, one would naturally try::
>>
>> int('500.000,23')
>>
>>instead of::
>>
>> int('500,000.23')
>
>
> That is why I said
>
> "Of course, also support the locale variant where the meaning of ","
> and
> "." is swapped in most European countries. "
>
> We are seeing the same about base 2, 8, 10, 16.
>
> May be :
>
> int("E500.000,23")
>
> as we are using :
>
> 0x
>
> already for hex number
>
I really wouldn't want it to become possible to write Python code in one
locale that had to be edited before the numeric literals were valid in
another locale. That way madness lies.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
[EMAIL PROTECTED] wrote: > Alternatively the underscore syntax may be used to separate the number > from its base: > 22875 == 22875_10 == 595b_16 == 123456_7 > But probably this is less commonly useful (and not much explicit). We already have a perfectly good syntax for entering octal and hex integers, because those are commonly used in many applications. There are, on occasion, need for other bases, but they are so rare, specialized, and non-standard (RFC-1924, for example, uses an interesting flavor of base-85) that having syntax built into the language to support them would be completely unjustified. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Sybren Stuvel wrote:
> [EMAIL PROTECTED] enlightened us with:
> > Of course, also support the locale variant where the meaning of ","
> > and "." is swapped in most European countries.
>
> This is exactly why I wouldn't use that notation. What happens if it
> is hardcoded into the source? I mean, that's what we're talking about.
> Then the program would have to have an indication of which locale is
> used for which source file. Without that, a program would be
> interpreted in a different way on different computers. I think that
> would be rather messy.
>
As mentioned in another post, we have that situation in all other
places. Such as
mm/dd/ vs dd/mm/
decimal("10.23") - would european people expect decimal("10,23") to
work ?
0x - a notation for base 16
why can't I have "E100.000,23" to mean "100,000.23" ? Nothing but
notation.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
[EMAIL PROTECTED] enlightened us with: > Of course, also support the locale variant where the meaning of "," > and "." is swapped in most European countries. This is exactly why I wouldn't use that notation. What happens if it is hardcoded into the source? I mean, that's what we're talking about. Then the program would have to have an indication of which locale is used for which source file. Without that, a program would be interpreted in a different way on different computers. I think that would be rather messy. I'm in favour of using spaces or underscores. Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Sat, 19 Nov 2005 01:33:40 -0800, bearophileHUGS wrote: > Steven D'Aprano: >> Perhaps Python should concatenate numeric literals at compile time: >> 123 456 is the same as 123456. > > I think using the underscore it is more explicit: > n = 123_456 It is also easy to make a typo: n = 123-456 -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Stefan Rank wrote:
> The other idea of teaching int() about separator characters has
> internationalis/zation issues:
> In many European countries, one would naturally try::
>
>int('500.000,23')
>
> instead of::
>
>int('500,000.23')
That is why I said
"Of course, also support the locale variant where the meaning of ","
and
"." is swapped in most European countries. "
We are seeing the same about base 2, 8, 10, 16.
May be :
int("E500.000,23")
as we are using :
0x
already for hex number
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steven D'Aprano: > Perhaps Python should concatenate numeric literals at compile time: > 123 456 is the same as 123456. I think using the underscore it is more explicit: n = 123_456 Alternatively the underscore syntax may be used to separate the number from its base: 22875 == 22875_10 == 595b_16 == 123456_7 But probably this is less commonly useful (and not much explicit). Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
on 19.11.2005 06:56 Steven D'Aprano said the following:
[snip]
>
> Perhaps Python should concatenate numeric literals at compile time:
>
> 123 456 is the same as 123456.
>
> Off the top of my head, I don't think this should break any older code,
> because 123 456 is not currently legal in Python.
+1
but only allow (a single ?) space(s), otherwise readability issues ensue.
The other idea of teaching int() about separator characters has
internationalis/zation issues:
In many European countries, one would naturally try::
int('500.000,23')
instead of::
int('500,000.23')
--
stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Steven D'Aprano wrote:
> On Fri, 18 Nov 2005 16:26:08 -0800, [EMAIL PROTECTED] wrote:
>
> > Personally, I would rather see the int() and float() function be
> > smarter to take what is used for this, i.e. :
> >
> > a = int("1,234,567")
>
> But the problem isn't just with conversion of strings. It is also
> with literals.
>
> n = 999
>
> Without counting, how many nines?
For readability, I don't see why it cannot be written as :
n = int("99,999,999,999")
we already needs to do this for decimal("9.9")
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On Fri, 18 Nov 2005 16:26:08 -0800, [EMAIL PROTECTED] wrote:
> Personally, I would rather see the int() and float() function be
> smarter to take what is used for this, i.e. :
>
> a = int("1,234,567")
But the problem isn't just with conversion of strings. It is also
with literals.
n = 999
Without counting, how many nines?
Obviously repeated digits is an extreme case, but even different digits
are easier to process if grouped. That's why we write phone numbers like
62 3 9621 2377 instead of 62396212377.
Here is a thought: Python already concatenates string literals:
"abc" "def" is the same as "abcdef".
Perhaps Python should concatenate numeric literals at compile time:
123 456 is the same as 123456.
Off the top of my head, I don't think this should break any older code,
because 123 456 is not currently legal in Python.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Personally, I would rather see the int() and float() function be
smarter to take what is used for this, i.e. :
a = int("1,234,567")
Of course, also support the locale variant where the meaning of "," and
"." is swapped in most European countries.
Gustav Hållberg wrote:
> I tried finding a discussion around adding the possibility to have
> optional underscores inside numbers in Python. This is a popular option
> available in several "competing" scripting langauges, that I would love
> to see in Python.
>
> Examples:
> 1_234_567
> 0xdead_beef
> 3.141_592
>
> Would appreciate if someone could find a pointer to a previous
> discussion on this topic, or add it to a Python-feature-wishlist.
>
> - Gustav
--
http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Sorry for the delayed response. I somehow missed this earlier. On Tue, 8 Nov 2005 15:39:09 + (UTC) in comp.lang.python, [EMAIL PROTECTED] (Roy Smith) wrote: >Dave Hansen <[EMAIL PROTECTED]> wrote: >> Of course, I write _far_ more code in C than Python. But I've seen >> enough bugs of the sort where someone wrote 120 when they meant Digression: 1 was enough. >> 1200, that I see great value in being able to specify 12_000_000. > >I'll admit that being able to write 12_000_000 would be convenient. >On the other hand, writing 12 * 1000 * 1000 is almost as clear. In C, Perhaps, but it's pretty obvious that something's wrong when you have to resort to ugly tricks like this to make the value of a simple integer constant "clear." And think about 64 (or longer) -bit unsigned long long hexadecimal values. How much nicer is 0xFFF0_FF0F_F0FF_0FFF_ULL than 0xFFF0FF0FF0FF0FFFULL? I guess we could do something like 0xFFF0ULL<<16)|0xFF0FULL)<<16)|0xF0FFULL)<<16)|0x0FFFULL), but I'm not sure it's any better. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Dave Hansen <[EMAIL PROTECTED]> wrote: > Of course, I write _far_ more code in C than Python. But I've seen > enough bugs of the sort where someone wrote 120 when they meant > 1200, that I see great value in being able to specify 12_000_000. I'll admit that being able to write 12_000_000 would be convenient. On the other hand, writing 12 * 1000 * 1000 is almost as clear. In C, the multiplication would be done at compile time, so it's not even any less efficient. I'm not sure how Python handles that, but if it turned out to be a serious run-time performance issue, it's easy enough to factor it out into something that's done once and stored. Bottom line, embedded no-op underscores in numbers would be nice (and, IHMO, should be added), but the lack of such a feature should not be used as an excuse to write such unreadable monstrosities as 1200 in source code. Semi-related: see Jakob Nielsen's complaint about having to enter credit card numbers as 16-digit strings with no breaks on web forms (http://www.useit.com/alertbox/designmistakes.html, item #7, last bullet point). -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
On 7 Nov 2005 18:02:09 -0800 in comp.lang.python, "Gustav Hållberg" <[EMAIL PROTECTED]> wrote: >I tried finding a discussion around adding the possibility to have >optional underscores inside numbers in Python. This is a popular option >available in several "competing" scripting langauges, that I would love >to see in Python. > >Examples: > 1_234_567 > 0xdead_beef > 3.141_592 > >Would appreciate if someone could find a pointer to a previous >discussion on this topic, or add it to a Python-feature-wishlist. I've never needed them in Python, but I've very often wished for them in C. Along with 0b(0|1)* for binary numbers, where they'd be even more useful. Of course, I write _far_ more code in C than Python. But I've seen enough bugs of the sort where someone wrote 120 when they meant 1200, that I see great value in being able to specify 12_000_000. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Gustav Hållberg wrote: > I tried finding a discussion around adding the possibility to have > optional underscores inside numbers in Python. This is a popular option > available in several "competing" scripting langauges, that I would love > to see in Python. > > Examples: > 1_234_567 > 0xdead_beef > 3.141_592 > > Would appreciate if someone could find a pointer to a previous > discussion on this topic, or add it to a Python-feature-wishlist. Perhaps these threads, via Google? http://groups.google.com/group/comp.lang.python/search?group=comp.lang.python&q=numeric+literals+underscores -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Gustav Hållberg wrote:
> I tried finding a discussion around adding the possibility to have
> optional underscores inside numbers in Python. This is a popular option
> available in several "competing" scripting langauges, that I would love
> to see in Python.
>
> Examples:
> 1_234_567
> 0xdead_beef
> 3.141_592
>
> Would appreciate if someone could find a pointer to a previous
> discussion on this topic, or add it to a Python-feature-wishlist.
>
> - Gustav
I'm not sure what the _s are for, but I'm guessing they serve as
separators ("." or "," depending on where you're from). I think the _s
look ugly to me, besides, underscores look more like spaces than
separators.
--
http://mail.python.org/mailman/listinfo/python-list
