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 11/14/2010 10:23 PM, MRAB wrote:
{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
MRAB <python@mrabarnett.plus.com> writes:
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 <denis.spir@gmail.com>:
{:} 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:
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? :-))
MRAB wrote:
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 <a, b> < <c, d>: ... elif <b, a> > <d, c>: ... which is too ghastly for words. Now, can we please stop bike-shedding over something so trivial as a way to write an empty set as a literal? What's wrong with just writing set()? -- Steven
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:
"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 <tjreedy@udel.edu> writes:
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
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
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 <dreamingforward@gmail.com> wrote:
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
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.
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):
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
On 2010-11-24, at 10:02 , Georg Brandl wrote: Am 24.11.2010 01:21, schrieb average:
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.
On Wed, Nov 24, 2010 at 12:05 AM, Mike Meyer < mwm-keyword-python.b4bdba@mired.org> wrote:
+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:
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:
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 <steve@pearwood.info> wrote:
Programmers choice. Use the struct module notation: (=....) Native order. (<....) Little-endian. (>....) Big-endian <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 24/11/10 23:57, Carl M. Johnson wrote:
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
Greg Ewing <greg.ewing@canterbury.ac.nz> writes:
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 Thu, 25 Nov 2010 03:01:20 +0000 MRAB <python@mrabarnett.plus.com> wrote:
+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
On 11/22/2010 04:16 AM, Jan Kaliszewski wrote:
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
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:
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,
Cordially, in any case... :) mark
On Mon, 22 Nov 2010 10:40:21 -0800 Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
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.
On 11/14/2010 10:23 PM, MRAB wrote:
{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
[sorry, sent unintentionally] On Mon, 15 Nov 2010 11:02:53 -0800 Guido van Rossum <guido@python.org> wrote:
There is nothing obvious about {:} for the empty dictionary. :-)
Anyone votes for {/} meaning empty set? Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
MRAB <python@mrabarnett.plus.com> writes:
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 <denis.spir@gmail.com>:
{:} 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:
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? :-))
MRAB wrote:
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 <a, b> < <c, d>: ... elif <b, a> > <d, c>: ... which is too ghastly for words. Now, can we please stop bike-shedding over something so trivial as a way to write an empty set as a literal? What's wrong with just writing set()? -- Steven
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:
"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 <tjreedy@udel.edu> writes:
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
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
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 <dreamingforward@gmail.com> wrote:
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
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.
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):
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
On 2010-11-24, at 10:02 , Georg Brandl wrote: Am 24.11.2010 01:21, schrieb average:
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.
On Wed, Nov 24, 2010 at 12:05 AM, Mike Meyer < mwm-keyword-python.b4bdba@mired.org> wrote:
+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:
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:
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 <steve@pearwood.info> wrote:
Programmers choice. Use the struct module notation: (=....) Native order. (<....) Little-endian. (>....) Big-endian <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 24/11/10 23:57, Carl M. Johnson wrote:
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
Greg Ewing <greg.ewing@canterbury.ac.nz> writes:
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 Thu, 25 Nov 2010 03:01:20 +0000 MRAB <python@mrabarnett.plus.com> wrote:
+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
On 11/22/2010 04:16 AM, Jan Kaliszewski wrote:
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
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:
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,
Cordially, in any case... :) mark
On Mon, 22 Nov 2010 10:40:21 -0800 Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
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