Hi, I am sure this has come up before and if it doesn't exist I believe there is a good reason for it. Anyway, here's my thought: how about having a syntax representation for sets? A mix of a dict and list/tuple syntax would make the most sense, such as:
isinstance({"foo", "bar"}, set) True
The problem here is: how to represent an empty set as {} would conflict with the dict repr. Then how about using a brand new "container" syntax that wouldn't conflict with existing ones?
<"foo", "bar"> == set(("foo", "bar")) True
<> == set() True
-- Alex | twitter.com/alexconrad
On 15/11/2010 03:15, Alexandre Conrad wrote:
Hi,
I am sure this has come up before and if it doesn't exist I believe there is a good reason for it. Anyway, here's my thought: how about having a syntax representation for sets? A mix of a dict and list/tuple syntax would make the most sense, such as:
[snip] This already exists in Python 2.7 and Python 3.
Oh! ... That is something I missed. I'll have a look at it. Thanks.
2010/11/14 MRAB
On 15/11/2010 03:15, Alexandre Conrad wrote:
Hi,
I am sure this has come up before and if it doesn't exist I believe there is a good reason for it. Anyway, here's my thought: how about having a syntax representation for sets? A mix of a dict and list/tuple syntax would make the most sense, such as:
[snip] This already exists in Python 2.7 and Python 3. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Alex | twitter.com/alexconrad
On 11/14/2010 10:23 PM, MRAB wrote:
On 15/11/2010 03:15, Alexandre Conrad wrote:
Hi,
I am sure this has come up before and if it doesn't exist I believe there is a good reason for it. Anyway, here's my thought: how about having a syntax representation for sets? A mix of a dict and list/tuple syntax would make the most sense, such as:
[snip] This already exists in Python 2.7 and Python 3.
{1,2,3} == set((1,2,3)) True
The *only* glitch is the lack of an empty set notation. The idea of dict() == {:}; set()=={}; which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3. -- Terry Jan Reedy
There is nothing obvious about {:} for the empty dictionary. :-)
On Mon, Nov 15, 2010 at 10:45 AM, Terry Reedy
On 11/14/2010 10:23 PM, MRAB wrote:
On 15/11/2010 03:15, Alexandre Conrad wrote:
Hi,
I am sure this has come up before and if it doesn't exist I believe there is a good reason for it. Anyway, here's my thought: how about having a syntax representation for sets? A mix of a dict and list/tuple syntax would make the most sense, such as:
[snip] This already exists in Python 2.7 and Python 3.
{1,2,3} == set((1,2,3)) True
The *only* glitch is the lack of an empty set notation. The idea of dict() == {:}; set()=={}; which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3.
-- Terry Jan Reedy
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
On Mon, Nov 15, 2010 at 3:35 PM, Alexandre Conrad < alexandre.conrad@gmail.com> wrote:
2010/11/15 MRAB
: On 15/11/2010 20:02, spir wrote:
Anyone votes for {/} meaning empty set?
No, but I would vote for {,}.
I tend to like that.
I agree. I think this would be a good syntax alternative to "set()".
--
Alex | twitter.com/alexconrad
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
MRAB
No, but I would vote for {,}.
−1. The comma in the set literal syntax is used to separate items, and so that looks like a set that explicitly *not* empty, but rather containing (unspecified) items. -- \ “Broken promises don't upset me. I just think, why did they | `\ believe me?” —Jack Handey | _o__) | Ben Finney
2010/11/15 spir
[sorry, sent unintentionally]
On Mon, 15 Nov 2010 11:02:53 -0800 Guido van Rossum
wrote: There is nothing obvious about {:} for the empty dictionary. :-)
{:} for empty dict could make some sense. If that is ever accepted, it will probably go in Python 4 as the change is so important.
Anyone votes for {/} meaning empty set?
-1. List, tuple and dict have their own literals. Now sets shares dict's literals. That's why I proposed using a new container literal for sets, such as <1, 2, 3> where an empty set would be <>. As lists and tuples are the mutable/immutable pairs, I thought we could have literals for frozenset as well. But I can no longer find available opening/closing symbols on my keyboard. Darn. I also thought about doubling braces, such as {{1, 2, 3}}, then {{}} for an empty set would work. (and probably break some templating engines out there ;)). But it conflicts with "a dict in a set" (which is unhashable anyway, but that's not a valid reason). -- Alex | twitter.com/alexconrad
On 15/11/2010 20:34, Alexandre Conrad wrote:
2010/11/15 spir
: [sorry, sent unintentionally]
On Mon, 15 Nov 2010 11:02:53 -0800 Guido van Rossum
wrote: There is nothing obvious about {:} for the empty dictionary. :-)
{:} for empty dict could make some sense. If that is ever accepted, it will probably go in Python 4 as the change is so important.
Anyone votes for {/} meaning empty set?
-1.
List, tuple and dict have their own literals. Now sets shares dict's literals. That's why I proposed using a new container literal for sets, such as<1, 2, 3> where an empty set would be<>. As lists and tuples are the mutable/immutable pairs, I thought we could have literals for frozenset as well. But I can no longer find available opening/closing symbols on my keyboard. Darn.
I also thought about doubling braces, such as {{1, 2, 3}}, then {{}} for an empty set would work. (and probably break some templating engines out there ;)). But it conflicts with "a dict in a set" (which is unhashable anyway, but that's not a valid reason).
I set is unordered, like a dict, so using {...} for both kind of makes sense, with the entries in the dict literal consisting of pairs separated by ":", which is why I would've liked {:}. Let's leave <...> for some future use. (Could they have been used for tuples, thus avoiding all the discussions about how "," builds tuples, apart from the empty tuple? :-))
On 2010-11-15, at 21:52 , MRAB wrote:
I set is unordered, like a dict, so using {...} for both kind of makes sense, with the entries in the dict literal consisting of pairs separated by ":", which is why I would've liked {:}.
And as somebody suggested a few days/weeks ago, it leaves the door open to `[k:v]` as an ordereddict literal, as a parallel to {}/{:}.
MRAB wrote:
Let's leave <...> for some future use. (Could they have been used for tuples, thus avoiding all the discussions about how "," builds tuples, apart from the empty tuple? :-))
But comma *is* the tuple-building operator. This allows us to write:
x, y = p, q
return x, y, z
instead of being forced to including brackets. Are you suggesting that
commas should be optional?
t = <x y z>
This will be an unfortunate source of errors unless we also drop
implicit string concatenation (which is too useful to drop!)
t = <"a" "b" 2> # 2-tuple, not 3
As for using < > for tuples, that leads to such horrors as:
if <
On Mon, Nov 15, 2010 at 1:04 PM, Greg Ewing
Alexandre Conrad wrote:
That's why I proposed using a new container literal for sets, such as <1, 2, 3>
Please, no angle brackets. They're ugly and too easily confused with comparison operators, at least by humans trying to read the code.
Hmm, I find them easy to read and no harder on the eyes than {}, but then I seldom have large numbers of < and > in my code. Geremy Condra
Guido van Rossum wrote:
There is nothing obvious about {:} for the empty dictionary. :-)
I think it has about the same level of obviousness as (x,) for a 1-element tuple. You would have to learn it, but after that you could easily remember which is which, because dicts are made with colons and sets aren't. A backwards-compatible alternative would be to use {.} for an empty set. Think of a set as half a dict, and the dot as half a colon. :-) -- Greg
On 11/15/2010 02:56 PM, Greg Ewing wrote:
Guido van Rossum wrote:
There is nothing obvious about {:} for the empty dictionary. :-)
I think it has about the same level of obviousness as (x,) for a 1-element tuple. You would have to learn it, but after that you could easily remember which is which, because dicts are made with colons and sets aren't.
A backwards-compatible alternative would be to use {.} for an empty set. Think of a set as half a dict, and the dot as half a colon. :-)
"set()" is only two chars longer than any of the suggestions. It's also clear about what it is. The spelling isn't the issue. In fact, if we can optimise some common constructors, such as in the cases of an empty containers, we can toss out the special syntax's. ra:~$ python3.2 -m timeit "dict()" 1000000 loops, best of 3: 0.401 usec per loop ra:~$ python3.2 -m timeit "{}" 10000000 loops, best of 3: 0.0649 usec per loop ra:~$ python3.2 -m timeit "list()" 1000000 loops, best of 3: 0.284 usec per loop ra:~$ python3.2 -m timeit "[]" 10000000 loops, best of 3: 0.0724 usec per loop ra:~$ python3.2 -m timeit "tuple()" 1000000 loops, best of 3: 0.222 usec per loop ra:~$ python3.2 -m timeit "()" 10000000 loops, best of 3: 0.0456 usec per loop ra@Gutsy:~$ python3.2 -m timeit "set()" 1000000 loops, best of 3: 0.234 usec per loop Not seriously*, ;-) Ron * IMO: The real value of the special syntax is that it makes it easy to write out nested objects in a concise way. The missing empty set syntax doesn't cause much problems with that. line_data = {'points':[(1 , 2), (3, 4)], 'color':'blue', 'style':'dotted'}
On 11/15/2010 2:02 PM, Guido van Rossum wrote:
There is nothing obvious about {:} for the empty dictionary. :-)
'Obvious' is always relative to the beholder ;-). Let me try again: If I were designing a new language and had already decided on {}, {1}, {1,2} ... for set displays and ??, {1:'one'} ... for dict displays and on the corresponding comprehension forms as in Python, then one 'obvious' choice *to me' for ?? would be '{:}'. Substitute any other shifted char, preferably typed by the right hand, if you want. However, the hypothetical de novo choice of something other than '{}' for ?? is irrelevant to the fact the Python 3 was not a new language and that changing the meaning of a syntactic constant like '{}' would have caused problems. I am more appreciative of that after seeing the problems people have had the the shift of meaning for unprefixed string constants. -- Terry Jan Reedy
Terry Reedy
On 11/15/2010 2:02 PM, Guido van Rossum wrote:
There is nothing obvious about {:} for the empty dictionary. :-)
'Obvious' is always relative to the beholder ;-).
The proposed syntax is non-obvious if you're Dutch, perhaps? :-) -- \ “Sometimes I — no, I don't.” —Steven Wright | `\ | _o__) | Ben Finney
Terry Reedy
The *only* glitch is the lack of an empty set notation.
It's a very small glitch, especially because ‘set()’ is so few characters. I see no pressing need to have syntactic sugar for that. -- \ “Crime is contagious… if the government becomes a lawbreaker, | `\ it breeds contempt for the law.” —Justice Louis Brandeis | _o__) | Ben Finney
The *only* glitch is the lack of an empty set notation. The idea of
dict() == {:}; set()=={}; which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3.
I have to say that the *lack*of those two suggested literals are a sore point for me (that along with the fact that dict doesn't inherit from set). Call me a nit-picker, but (without them) they are like sand in the vast gearbox of my mind when using python3: small but disruptive. I would argue that the lack of them is what is *preventing* the adoption of python3. And although I appreciate the kind reluctance to change the long-standing {} for the empty dict, I hasten to mention that the universe will naturally gravitate to that which is most elegant, so better to feel the pain at the beginning than a long demise without them. (I suspect there would even be a small but measurable increase in downloads should python offer the option. ) Along those lines of simple ease-of-use issues, help() should have a verbose option, so that doctests don't clutter up basic interface information. And I put another vote (from a discussion long ago) in favor of a test() built-in to make test-driven development a core part of the language. This would be a quite novel and powerful step in front of any other known language. Just some minor thoughts from nobody in particular .... :) marcos
average, 16.11.2010 04:16:
The *only* glitch is the lack of an empty set notation. The idea of
dict() == {:}; set()=={}; which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3.
I have to say that the *lack*of those two suggested literals are a sore point for me (that along with the fact that dict doesn't inherit from set). Call me a nit-picker, but (without them) they are like sand in the vast gearbox of my mind when using python3: small but disruptive. I would argue that the lack of them is what is *preventing* the adoption of python3.
I doubt that. Stefan
On 16/11/2010 11:59, Stefan Behnel wrote:
average, 16.11.2010 04:16:
The *only* glitch is the lack of an empty set notation. The idea of
dict() == {:}; set()=={}; which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3.
I have to say that the *lack*of those two suggested literals are a sore point for me (that along with the fact that dict doesn't inherit from set). Call me a nit-picker, but (without them) they are like sand in the vast gearbox of my mind when using python3: small but disruptive. I would argue that the lack of them is what is *preventing* the adoption of python3.
I doubt that.
I doubt it too.
On 16/11/2010 11:59, Stefan Behnel wrote:
average, 16.11.2010 04:16:
The *only* glitch is the lack of an empty set notation. The idea of
dict() == {:}; set()=={};
which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3.
I have to say that the *lack*of those two suggested literals are a sore point for me (that along with the fact that dict doesn't inherit from set). Call me a nit-picker, but (without them) they are like sand in the vast gearbox of my mind when using python3: small but disruptive. I would argue that the lack of them is what is *preventing* the adoption of python3.
I doubt that.
I doubt it too.
Haha, of course you do. If you didn't, it would've already been done. But don't mislead yourselves either, as members of the old guard (?), you never get to measure the users that walk away. And you run into the easy
On Tue, Nov 16, 2010 at 11:32 AM, MRAB
That would explain why no one uses C, C++, C#, Ruby, Java, Basic, Fortran,
etc. None of these languages have a simple literal for an empty set.
That's why we're all using Pascal which does have a set literal [].
--- Bruce :-)
Learn about security: http://j.mp/gruyere-security
On Tue, Nov 16, 2010 at 9:02 PM, average
On Tue, Nov 16, 2010 at 11:32 AM, MRAB
wrote: On 16/11/2010 11:59, Stefan Behnel wrote:
average, 16.11.2010 04:16:
The *only* glitch is the lack of an empty set notation. The idea of
dict() == {:}; set()=={};
which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3.
I have to say that the *lack*of those two suggested literals are a sore point for me (that along with the fact that dict doesn't inherit from set). Call me a nit-picker, but (without them) they are like sand in the vast gearbox of my mind when using python3: small but disruptive. I would argue that the lack of them is what is *preventing* the adoption of python3.
I doubt that.
I doubt it too.
Haha, of course you do. If you didn't, it would've already been done. But don't mislead yourselves either, as members of the old guard (?), you never get to measure the users that walk away. And you run into the easy trap of "false neutrals".
marcos
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
average writes:
But don't mislead yourselves either, as members of the old guard (?), you never get to measure the users that walk away.
Nobody does, though. At some point a project has to go with the information it has, and the users it has. Anyway, the only literal that matters whose invention is (more or less) recorded in history is "0". All the rest are syntactic artificial sweeteners.
But don't mislead yourselves either, as members of the old guard (?), you
never get to measure the users that walk away.
Nobody does, though. At some point a project has to go with the information it has, and the users it has.
Truly. But the point is that the universe will inevitably evolve towards elegance. To only "go on with the information it has and the users it has" ensures that it remains merely a branch off the trunk of the ideal (consequently drawing few new users), that eventually will need either to be *deliberately* pruned, or will wither and break off unexpectedly at some future point. Remember, the bulk of new, loyal, users are drawn by an ideal (you might remember yourself being among them), not even necessarily by how big the library is. Just some thoughts to consider.... marcos
average wrote:
Truly. But the point is that the universe will inevitably evolve towards elegance.
"Inevitably"? I think the only think we can say that the universe will inevitably evolve towards is a state of maximum entropy. But frankly, I don't see the relevance to the future heat death of the universe in hundreds of billions of years to Python's syntax.
To only "go on with the information it has and the users it has" ensures that it remains merely a branch off the trunk of the ideal (consequently drawing few new users), that eventually will need either to be *deliberately* pruned, or will wither and break off unexpectedly at some future point. Remember, the bulk of new, loyal, users are drawn by an ideal (you might remember yourself being among them), not even necessarily by how big the library is.
I beg to differ... it seems to me that users are drawn to languages for many reasons, and while elegance can be one of them, it is fairly low down the list. Why else would C++, VB and PHP be so popular, while Haskell and Scheme remain tiny and unpopular (although very influential)? Besides, how do you define "elegant"? I've heard it said, in full seriousness, that BrainF*** is the most elegant language because it is a fully Turing-complete language in only six commands (plus two more for IO). Personally, I see Python as an extremely elegant language, but that elegance is tempered by a very strong dose of practicality and realism. Gratuitously breaking backwards compatibility just so that there is a literal for the empty set is not what I call either practical or realistic. -- Steven
Terry Reedy dixit (2010-11-15, 13:45):
The *only* glitch is the lack of an empty set notation. The idea of dict() == {:}; set()=={}; which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3.
I'd be happy with: * {:} for empty dict() (as a collection of key-value *pairs*) * {.} for empty set() (as a similar collection of *single* elements) And {} for empty dict() as well -- to keep compatibility (maybe to be deprecated later). Regards, *j
Jan Kaliszewski dixit (2010-11-22, 11:16):
I'd be happy with:
* {:} for empty dict() (as a collection of key-value *pairs*) * {.} for empty set() (as a similar collection of *single* elements)
And {} for empty dict() as well -- to keep compatibility (maybe to be deprecated later).
PS. Another argument: {} is criticized for its similarity to () (when using some fonts).
On Mon, Nov 22, 2010 at 3:23 AM, Jan Kaliszewski
I'd be happy with:
* {:} for empty dict() (as a collection of key-value *pairs*) * {.} for empty set() (as a similar collection of *single* elements)
And {} for empty dict() as well -- to keep compatibility (maybe to be deprecated later).
PS. Another argument: {} is criticized for its similarity to () (when using some fonts).
That is sometimes true, but one should bend towards fixing the font problem
rather than adapting to brokenness.... m
Am 24.11.2010 01:21, schrieb average:
On Mon, Nov 22, 2010 at 3:23 AM, Jan Kaliszewski
mailto:zuo@chopin.edu.pl> wrote: > I'd be happy with: > > * {:} for empty dict() (as a collection of key-value *pairs*) > * {.} for empty set() (as a similar collection of *single* elements) > > And {} for empty dict() as well -- to keep compatibility (maybe to be > deprecated later).
PS. Another argument: {} is criticized for its similarity to () (when using some fonts).
That is sometimes true, but one should bend towards fixing the font problem rather than adapting to brokenness....
Yep. Otherwise you would also need to forbid "1" in identifiers because it can easily be confused with "l" in some fonts. (And of course, let's not speak of identifiers in Python 3 in this context...) Georg
On 2010-11-24, at 10:02 , Georg Brandl wrote: Am 24.11.2010 01:21, schrieb average:
On Mon, Nov 22, 2010 at 3:23 AM, Jan Kaliszewski
mailto:zuo@chopin.edu.pl> wrote: I'd be happy with:
* {:} for empty dict() (as a collection of key-value *pairs*) * {.} for empty set() (as a similar collection of *single* elements)
And {} for empty dict() as well -- to keep compatibility (maybe to be deprecated later). PS. Another argument: {} is criticized for its similarity to () (when using some fonts).
That is sometimes true, but one should bend towards fixing the font problem rather than adapting to brokenness....
Yep. Otherwise you would also need to forbid "1" in identifiers because it can easily be confused with "l" in some fonts. (And of course, let's not speak of identifiers in Python 3 in this context...)
Georg
Since 1s will be in the code source in any case (as free-standing integers or as part of floats) wouldn't it be more sensible to ban `l` from identifiers? As well as uppercase O just to be on the safe side? As an alternative, I would modestly propose banning integer literals altogether in favor of english-spelled constants: `ONE` can hardly be confused with the letter `l`, and having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code.
"Masklinn"
As an alternative, I would modestly propose banning integer literals altogether in favor of english-spelled constants: `ONE` can hardly be confused with the letter `l`, and having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code.
Given that roman numeral literals have already been rejected, I'd like to propose them as an alternative alternative. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Wed, Nov 24, 2010 at 12:05 AM, Mike Meyer < mwm-keyword-python.b4bdba@mired.org> wrote:
"Masklinn"
wrote: As an alternative, I would modestly propose banning integer literals altogether in favor of english-spelled constants: `ONE` can hardly be confused with the letter `l`, and having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code.
+1 If it's good enough for my banker when writing checks, it should be good enough for Python. But it might be safer if we required the Arabic numerals in parentheses following the English. If the two don't match, we could raise a CheckingError. Seems to be a basically self-documenting error type to me.
On 2010-11-24, at 11:57 , Carl M. Johnson wrote:
On Wed, Nov 24, 2010 at 12:05 AM, Mike Meyer < mwm-keyword-python.b4bdba@mired.org> wrote:
"Masklinn"
wrote: As an alternative, I would modestly propose banning integer literals altogether in favor of english-spelled constants: `ONE` can hardly be confused with the letter `l`, and having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code. +1 If it's good enough for my banker when writing checks, it should be good enough for Python. But it might be safer if we required the Arabic numerals in parentheses following the English. If the two don't match, we could raise a CheckingError. Seems to be a basically self-documenting error type to me.
But then we're back with the possible confusion between arabic numerals and ascii characters. Still, I think this idea is a good one, we need some kind of checksum. Maybe it could be merged with Mike's proposal: the "basic english" number is followed by the same number written using roman numerals and the two versions are checked against one another to ensure consistency.
Masklinn wrote:
On 2010-11-24, at 11:57 , Carl M. Johnson wrote:
On Wed, Nov 24, 2010 at 12:05 AM, Mike Meyer < mwm-keyword-python.b4bdba@mired.org> wrote:
"Masklinn"
wrote: As an alternative, I would modestly propose banning integer literals altogether in favor of english-spelled constants: `ONE` can hardly be confused with the letter `l`, and having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code. +1 If it's good enough for my banker when writing checks, it should be good enough for Python. But it might be safer if we required the Arabic numerals in parentheses following the English. If the two don't match, we could raise a CheckingError. Seems to be a basically self-documenting error type to me.
But then we're back with the possible confusion between arabic numerals and ascii characters.
Still, I think this idea is a good one, we need some kind of checksum. Maybe it could be merged with Mike's proposal: the "basic english" number is followed by the same number written using roman numerals and the two versions are checked against one another to ensure consistency.
Is this thread happening four months early or eight months late? But in the spirit of this discussion, can I propose that Python require all numeric literals be written out in full English words, followed by the binary expansion in brackets, so as to ensure that the value generated by Python matches the programmers expectation? n = ONE THOUSAND FOUR HUNDRED AND FIFTY SEVEN (10110110001) This will especially be useful for float literals, since the programmer will no longer be able to feign ignorance of the complexities of binary floating point, but will have to deal with them explicitly: x = FORTY-TWO POINT ONE \ (100000001000101000011001100110011001100110011001100110011001101) Never again will we have to answer questions about why Python's floating point maths is inaccurate! Should we enter the binary expansion in big-endian or little-endian format? -- Steven
On Thu, 25 Nov 2010 00:28:41 +1100
Steven D'Aprano
But in the spirit of this discussion, can I propose that Python require all numeric literals be written out in full English words, followed by the binary expansion in brackets, so as to ensure that the value generated by Python matches the programmers expectation?
n = ONE THOUSAND FOUR HUNDRED AND FIFTY SEVEN (10110110001)
This will especially be useful for float literals, since the programmer will no longer be able to feign ignorance of the complexities of binary floating point, but will have to deal with them explicitly:
x = FORTY-TWO POINT ONE \ (100000001000101000011001100110011001100110011001100110011001101)
Never again will we have to answer questions about why Python's floating point maths is inaccurate!
Should we enter the binary expansion in big-endian or little-endian format?
Programmers choice. Use the struct module notation:
(=....) Native order.
(<....) Little-endian.
(>....) Big-endian
On Wed, Nov 24, 2010 at 5:37 AM, Masklinn
On 2010-11-24, at 11:57 , Carl M. Johnson wrote:
On Wed, Nov 24, 2010 at 12:05 AM, Mike Meyer < mwm-keyword-python.b4bdba@mired.org> wrote:
"Masklinn"
wrote: As an alternative, I would modestly propose banning integer literals altogether in favor of english-spelled constants: `ONE` can hardly be confused with the letter `l`, and having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code. +1 If it's good enough for my banker when writing checks, it should be good enough for Python. But it might be safer if we required the Arabic numerals in parentheses following the English. If the two don't match, we could raise a CheckingError. Seems to be a basically self-documenting error type to me.
But then we're back with the possible confusion between arabic numerals and ascii characters.
Still, I think this idea is a good one, we need some kind of checksum. Maybe it could be merged with Mike's proposal: the "basic english" number is followed by the same number written using roman numerals and the two versions are checked against one another to ensure consistency.
Wow. We are in the Twilight Zone. Queue music... mark
The idea is flawed. No, really! People would start writing integer literals as floats. And the scheme doesn't cover floats (there is no standard way of writing decimal places in Roman numerals AFAIK). Rob Cliffe On 24/11/2010 23:52, average wrote:
On Wed, Nov 24, 2010 at 5:37 AM, Masklinn
mailto:masklinn@masklinn.net> wrote: On 2010-11-24, at 11:57 , Carl M. Johnson wrote: > On Wed, Nov 24, 2010 at 12:05 AM, Mike Meyer < > mwm-keyword-python.b4bdba@mired.org mailto:mwm-keyword-python.b4bdba@mired.org> wrote: >> "Masklinn"
mailto:masklinn@masklinn.net> wrote: >>> As an alternative, I would modestly propose banning integer literals >>> altogether in favor of english-spelled constants: `ONE` can hardly be >>> confused with the letter `l`, and having to write `FIVE HUNDRED >>> FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY >>> ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would >>> surely reduce the usage of redundant magic numbers in the code. > +1 If it's good enough for my banker when writing checks, it should be good > enough for Python. But it might be safer if we required the Arabic numerals > in parentheses following the English. If the two don't match, we could raise > a CheckingError. Seems to be a basically self-documenting error type to me. But then we're back with the possible confusion between arabic numerals and ascii characters.
Still, I think this idea is a good one, we need some kind of checksum. Maybe it could be merged with Mike's proposal: the "basic english" number is followed by the same number written using roman numerals and the two versions are checked against one another to ensure consistency.
Wow. We are in the Twilight Zone. Queue music...
mark
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 24/11/10 23:57, Carl M. Johnson wrote:
But it might be safer if we required the Arabic numerals in parentheses following the English. If the two don't match, we could raise a CheckingError.
Also require the rest of the line to be filled with "*" characters (up to the PEP-8 standard line length of 80 chars) to verify that nothing has been added or removed since the program was written. You can't be too careful when numeric-literal-eating nanoviruses are around... -- Greg
On 24/11/10 22:40, Masklinn wrote:
Since 1s will be in the code source in any case (as free-standing integers or as part of floats) wouldn't it be more sensible to ban `l` from identifiers? As well as uppercase O just to be on the safe side?
Don't forget Z, A and S to eliminate confusion with 2, 4 and 5.
having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code.
Please, no. We'd have endless arguments over whether it should be NINE HUNDRED TWENTY ONE or NINE HUNDRED AND TWENTY ONE. :-( -- Greg
Greg Ewing
Please, no. We'd have endless arguments over whether it should be NINE HUNDRED TWENTY ONE or NINE HUNDRED AND TWENTY ONE. :-(
Clearly there needs to be a compile-time option to enable the user to select which one is correct. -- \ “Odious ideas are not entitled to hide from criticism behind | `\ the human shield of their believers' feelings.” —Richard | _o__) Stallman | Ben Finney
On 25/11/2010 02:42, Greg Ewing wrote:
On 24/11/10 22:40, Masklinn wrote:
Since 1s will be in the code source in any case (as free-standing integers or as part of floats) wouldn't it be more sensible to ban `l` from identifiers? As well as uppercase O just to be on the safe side?
Don't forget Z, A and S to eliminate confusion with 2, 4 and 5.
having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code.
Please, no. We'd have endless arguments over whether it should be NINE HUNDRED TWENTY ONE or NINE HUNDRED AND TWENTY ONE. :-(
Shouldn't it be in Dutch?
On Thu, 25 Nov 2010 03:01:20 +0000
MRAB
On 25/11/2010 02:42, Greg Ewing wrote:
On 24/11/10 22:40, Masklinn wrote:
Since 1s will be in the code source in any case (as free-standing integers or as part of floats) wouldn't it be more sensible to ban `l` from identifiers? As well as uppercase O just to be on the safe side?
Don't forget Z, A and S to eliminate confusion with 2, 4 and 5.
having to write `FIVE HUNDRED FORTY-ONE BILLION FOUR HUNDRED FIFTY ONE MILLION NINE HUNDRED EIGHTY ONE THOUSAND NINE HUNDRED TWENTY ONE` rather than 514451981921 would surely reduce the usage of redundant magic numbers in the code.
Please, no. We'd have endless arguments over whether it should be NINE HUNDRED TWENTY ONE or NINE HUNDRED AND TWENTY ONE. :-(
Shouldn't it be in Dutch?
+1 PS: google translate: VIJFHONDERD eenenveertig miljard vierhonderd Fifty One miljoen negenhonderd eenentachtig duizend Negen honderd twintig ONE (I wonder about its casing algorithm ;-) ...and don't want to have to fix it.) denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
spir wrote:
PS: google translate: VIJFHONDERD eenenveertig miljard vierhonderd Fifty One miljoen negenhonderd eenentachtig duizend Negen honderd twintig ONE
(I wonder about its casing algorithm ;-) ...and don't want to have to fix it.)
I also wonder about its knowledge of basic vocabulary, since Fifty and One don't seem to have been translated... -- Greg
On 11/25/2010 02:07 PM, Greg Ewing wrote:
spir wrote:
PS: google translate: VIJFHONDERD eenenveertig miljard vierhonderd Fifty One miljoen negenhonderd eenentachtig duizend Negen honderd twintig ONE
(I wonder about its casing algorithm ;-) ...and don't want to have to fix it.)
I also wonder about its knowledge of basic vocabulary, since Fifty and One don't seem to have been translated...
Why bother, it's just matter of time before we will be switching to a quantum based decimal module with infinite precision for intermediate operations. As for set syntax, I don't think it's needed. -1 Cheers, Ron
On 11/22/2010 04:16 AM, Jan Kaliszewski wrote:
Terry Reedy dixit (2010-11-15, 13:45):
The *only* glitch is the lack of an empty set notation. The idea of dict() == {:}; set()=={}; which would be the obvious choice if starting fresh, was considered but rejected by Guido as too disruptive and introducing another barrier between Python 2 and 3.
I'd be happy with:
* {:} for empty dict() (as a collection of key-value *pairs*) * {.} for empty set() (as a similar collection of *single* elements)
And {} for empty dict() as well -- to keep compatibility (maybe to be deprecated later).
Maybe it's not intentional, but where ever a colon is used, it tends to mean "make an association to". (except in slicing) Key : value # This is also name : object. class name : class body function name : function body And where ever a '.' is, it tends to mean "get a sub-part of: class name . method name So the {.} doesn't really fit with this idea. Probably the correct set notation would have been {} if it was put into python before dictionaries. If you follow this line of reasoning, then a dictionary is a set of associations. ie... {} for set, and : for associated to, and put those together and we have {:}. An interesting "wild" idea might be to delay defining weather it's a dictionary or a set depending on how it's first used. Then {} could be both an empty set and an empty dictionary, but I think there are probably are a lot of reasons not to do that. Ron
Ron Adam wrote:
An interesting "wild" idea might be to delay defining weather it's a dictionary or a set depending on how it's first used. Then {} could be both an empty set and an empty dictionary, but I think there are probably are a lot of reasons not to do that.
I'd say the challenge is wider, there are various corners where a "generic zero value/factory" feels like a desirable feature, just waiting to be correctly designed... Cheers, BB
I'd be happy with:
* {:} for empty dict() (as a collection of key-value *pairs*) * {.} for empty set() (as a similar collection of *single* elements)
And {} for empty dict() as well -- to keep compatibility (maybe to be deprecated later).
I'm curious why you guys think you *need* an empty set literal. The current spelling using set() and frozenset() is unambiguous. So what's the point of trying to shoehorn-in a new literal? AFAICT, this discussion has been solely motivated by a shallow itch, "dicts have one, so sets have to have one too". If there were a clean, beautiful, obvious correct answer, it would have already been done. Since there isn't, we have to ask, who cares? Raymond
On Mon, Nov 22, 2010 at 11:40 AM, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
I'd be happy with:
* {:} for empty dict() (as a collection of key-value *pairs*) * {.} for empty set() (as a similar collection of *single* elements)
And {} for empty dict() as well -- to keep compatibility (maybe to be deprecated later).
I'm curious why you guys think you *need* an empty set literal. The current spelling using set() and frozenset() is unambiguous. So what's the point of trying to shoehorn-in a new literal?
AFAICT, this discussion has been solely motivated by a shallow itch, "dicts have one, so sets have to have one too".
Because those forms (to the starting programmer especially) make it seem like a second-class citizen. That may seem a trivial objection, but those "sensitive initial conditions" set up trajectories which have (eventually) far-reaching consequences. Separately, but along those lines, if mutability and immutability are frequent enough concerns, then perhaps some thought should be given to how one might address that with a simple syntactical or general, object-wise methodology. Perhaps this thread is not appropriate to pose the question, but should there be a general mutable bit attached to any given object? If there were a clean, beautiful, obvious correct answer,
it would have already been done. Since there isn't, we have to ask, who cares?
No! there is a clean, beautiful, obvious correct answer! The problem is *only* backwards-compatibility. That is why we care.
Cordially, in any case... :) mark
On Mon, 22 Nov 2010 10:40:21 -0800
Raymond Hettinger
If there were a clean, beautiful, obvious correct answer, it would have already been done.
Are you predicting everything we will add from now on to the language will be filthy, ugly and confusingly (in)correct? :) Regards Antoine.
participants (25)
-
Alexander Belopolsky
-
Alexandre Conrad
-
Antoine Pitrou
-
average
-
Ben Finney
-
Boris Borcic
-
Bruce Leban
-
Carl M. Johnson
-
Daniel da Silva
-
Georg Brandl
-
geremy condra
-
Greg Ewing
-
Guido van Rossum
-
Jan Kaliszewski
-
Masklinn
-
Mike Meyer
-
MRAB
-
Raymond Hettinger
-
Rob Cliffe
-
Ron Adam
-
spir
-
Stefan Behnel
-
Stephen J. Turnbull
-
Steven D'Aprano
-
Terry Reedy