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
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 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
[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
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
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
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
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
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
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
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
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
[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
[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
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
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
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
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
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
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
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
Peter HansenOr 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
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
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
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
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
--
[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
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
[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
[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
Roy SmithWe 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
[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:
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
[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
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,
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
55 matches
Mail list logo
