[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
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 probab
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 b
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 smal
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
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.
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.
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
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 sa
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.
>>
>>E
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
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 mak
[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 th
[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 cre
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
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 whe
"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
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 unconvince
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 gro
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
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 t
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 num
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,
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 num
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_
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 fou
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 id
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 rea
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 jiggl
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
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
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 woul
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 Pyth
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. Firstl
[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 str
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::
> >>
> >>
[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
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 0x60
[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 sai
[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
int
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,
[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.
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
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
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
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
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
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 = 9
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 discus
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 s
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
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
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
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_
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
55 matches
Mail list logo
