Re: Why Python don't accept 03 as a number?
On Tue, Dec 11, 2018 at 1:12 PM Avi Gross wrote: > I would then "generate" all possible combinations of digits 0-9 of length N. > There are an amazing number of ways to do that ranging from taking a > range(10**N) and converting it to a string then a list of numeral characters > then tossing out any that have any duplicates, to creating a recursive > function that passes along what has been used so far to the next call. Since > many of these problems only need ONE solution, the generator would only > iterate as many times as needed and no giant lists of numbers or strings need > be in memory at any time. > First off, you can slash that number significantly, as there are only 10! (not 10**10) possibilities. Secondly, you can eliminate zero from consideration from any letter that starts a sequence other than a single digit, as demonstrated previously. So there are 9! * x, where x is the number of letters that could potentially be zero. That cuts your total possibilities from 10,000,000,000 down to, at worst, 3,628,800. > For each tuple returned by the generator, you can iterate on the set of > unique letters and use string functions to substitute the digits, or perhaps > do this all at once. You would do this to all the items in what I call the > left list as well as all the items on the right list. These would not be > "numeric" so using int() on each item would work EVEN with leading zeroes. > Seems safe enough. > Use str.replace() and int(), job done. > Yes, this is brute force. Using range(1,000,000) (no commas in real use) Use underscores instead: >>> range(1_000_000) range(0, 100) > would be a million iterations when there are six unique characters in the > puzzle and as many as 10 billion if all ten are in use. If you use nested > loops like I showed a while ago (albeit to make arbitrary ones for many sizes > could require multiple functions or use of an eval on one built by hand) you > can cut down the number of iterations as the nested loops count down with > each one doing one less than the one before it. Same goes for the recursive > function call method as it passes along what numerals have already been > used. There may already be a permutation function that does this efficiently > in C. > Yeah, check itertools :) > The real cost that dominates here is not memory, albeit garbage collection > may be busy as it generates lots of temporary small bits of data. It is how > the number of iterations grows. Correct. And that's why a pure brute-force solution needs some refinement. Algorithmic improvements almost always trump mechanical improvements. > I have looked at a somewhat related issue of how you generate all possible > SCRABBLE words (or BOGGLE or ...) given specific starting letters. > One way to make all possible combinations is along the lines above with many > needed changes as there can (in theory) be as many as 26 unique letters (in > English) and you can have multiple copies of some letters. If you allow other > languages, the problem grows to the point where brute force is not realistic. > And, ideally, you winnow down your choices by checking each word against a > large dictionary. Hmm, IMO that's the wrong way around. Instead, *start* with the dictionary, and winnow down the possibilities to the words you have. A decent word list will probably have 100K-1M words in it, which is a small enough corpus to go through them all. > Anyone know of one that has a decent selection and can be freely imported? I > mean one word per line. > What OS are you on? For my usage, I just read from /usr/share/dict/words and it's usually there. On Debian Linux, that's provided by the dictionaries-common package, or the wbritish or wamerican Ditch-side-specific packages. In fact, using that file makes your code independent of language (although you may need to concern yourself with different alphabets if you want to support Russian/Greek, and anything involving "letters" doesn't really work with Chinese), so I would strongly recommend it. On Windows, where that path doesn't exist, and there probably aren't standard dictionaries, you could download one of them from wordlist.aspell.net or wordlist.sourceforge.net - they're freely available, but you would have to go fetch them. > I apologize for the length. The main question was whether eval is > particularly expensive. Well, yes it IS expensive... but the cost of it is less significant than the algorithm and consequent number of iterations/attempts. Using eval() on three million possibilities is going to be WAY cheaper than a more efficient calculation technique used on ten billion. Write your code with two main priorities: 1) Get your algorithm right 2) Express your algorithm cleanly in code. Don't worry about performance until you've done the above two steps, *measured*, and found that it's taking too long. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: Why Python don't accept 03 as a number?
taking any chances on rogue code. Mind you, in the above I would remove everything except [a-zA-Z=+] including parentheses and periods so damage from a carefully crafted text should be limited to over-riding a global variable name and even that can be handled by supplying a minimal environment to the eval call. The real cost that dominates here is not memory, albeit garbage collection may be busy as it generates lots of temporary small bits of data. It is how the number of iterations grows. I have looked at a somewhat related issue of how you generate all possible SCRABBLE words (or BOGGLE or ...) given specific starting letters. That problem allows duplicate letters but it has to handle quite large words (even weird medical terms like Pneumonoultramicroscopicsilicovolcanoconiosis but SCRABBLE words cannot possible be larger than the seven letters you have added to whatever is on the board that it connects to and in any case, the board can only fit 19 letters.) One way to make all possible combinations is along the lines above with many needed changes as there can (in theory) be as many as 26 unique letters (in English) and you can have multiple copies of some letters. If you allow other languages, the problem grows to the point where brute force is not realistic. And, ideally, you winnow down your choices by checking each word against a large dictionary. Anyone know of one that has a decent selection and can be freely imported? I mean one word per line. Of course, in this case, there is room for improvement such as by making a tree out of the dictionary and pruning any attempts if the word you are building wanders off a leaf. Another story. I apologize for the length. The main question was whether eval is particularly expensive. -Original Message- From: Python-list On Behalf Of Antoon Pardon Sent: Monday, December 10, 2018 5:00 AM To: python-list@python.org Subject: Re: Why Python don't accept 03 as a number? On 8/12/18 06:00, Cameron Simpson wrote: > On 07Dec2018 20:24, Jach Fong wrote: >> Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: >>> What is it exactly that you're trying to accomplish with this? >>> Perhaps there's a better way than using eval. >> >> This problem comes from solving a word puzzle, >>ab + aa + cd == ce >> Each character will be translate to a digit and evaluate the >> correctness, >>03 + 00 + 15 == 18 > > Then you should be evaluating the digits and assembling values from > them. Not trying to shoehorn a string through something that _might_ > accept this string and do what you want. In Python 2 it will accept > your string and not do what you want; at least in Python 3 it doesn't > accept your string. > > My point here is that the structure of your puzzle doesn't map > directly into a naive python statement, and you shouldn't be > pretending it might. How do you figure? As far as I understand he is trying to solve this kind of puzzle: SEND MORE + MONEY Where every letter is to be replaced by a digit in such a way that the sum checks out. Sure trying to solve this by starting with the string: "SEND + MORE == MONEY" and doing replaces until eval comes up with true is not very sofisticated but I wouldn't call it shoehorning either. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 10/12/18 11:16, Chris Angelico wrote: > On Mon, Dec 10, 2018 at 9:11 PM Antoon Pardon wrote: >> On 10/12/18 11:03, Chris Angelico wrote: >>> Considering that, in a problem of that description, neither S nor M >>> may represent zero, I don't think there's a problem here. >> Not all such problems have that condition. > They should. Every published set of problems that I've ever solved by > hand has. I went searching online for some, and found this page: > > http://puzzlepicnic.com/genre?alphametic > > which clearly states that exact restriction. Why should they? Is this some holy restriction a puzzle maker has to follow on pain of excommunication somehow? Not all replacement puzzles are alphametic puzzles. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Mon, Dec 10, 2018 at 10:31 PM wrote: > > Chris Angelico於 2018年12月10日星期一 UTC+8下午7時09分01秒寫道： > > Yet most human beings will agree that you don't write out an > > arithmetic problem as: > > > >0 1 9 8 > > + 7 1 3 > > = > > Python3 gives me the error message is because of the number 0198, not because > of 0198 + 713. As would humans, yes. You don't write numbers with leading zeros in normal grade-school arithmetic. Or at least, I was taught not to. (Except in special circumstances.) > > > I prefer to buy the reason that this restriction was bring in is because > > > of the puzzle's author know it will cause trouble without this, not > > > because of our written habit. > > > > > > > No, it's a restriction because it is unsatisfactory without it. The > > point of a puzzle is to be fun, and fun means having restrictions that > > fit what people expect. > > The fun is from solving the puzzle, not from its restriction, unless the > puzzle has no fun without this restriction. > Okay. Here, solve this one. send + more = digits There are absolutely no restrictions. A letter could represent the square root of negative one, or the base of natural logarithms, or anything at all. Is that fun? Or would you prefer to have normal and sane restrictions? Restrictions are there to create fun. Restrictions make it into an interesting puzzle instead of a "gotcha" that makes you feel stupid when someone points it out (for instance, you say "there's no solution" and someone says "ah ha, but you see, the letter 's' represents the colour green, not a digit"). In terms of game/puzzle design, the restriction is a good one. In terms of programming language design, it's also a good restriction, though for different reasons (mainly the conflict between the C-derived expectation and the human-derived expectation, and the subtle confusion that would be caused). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
Chris Angelico於 2018年12月10日星期一 UTC+8下午7時09分01秒寫道： > On Mon, Dec 10, 2018 at 9:46 PM wrote: > > > > Chris Angelico於 2018年12月10日星期一 UTC+8下午6時17分14秒寫道： > > > On Mon, Dec 10, 2018 at 9:11 PM Antoon Pardon > > > wrote: > > > > > > > > On 10/12/18 11:03, Chris Angelico wrote: > > > > > Considering that, in a problem of that description, neither S nor M > > > > > may represent zero, I don't think there's a problem here. > > > > > > > > Not all such problems have that condition. > > > > > > They should. Every published set of problems that I've ever solved by > > > hand has. I went searching online for some, and found this page: > > > > > > http://puzzlepicnic.com/genre?alphametic > > > > > > which clearly states that exact restriction. The implication is that > > > you're solving a puzzle in arithmetic (usually addition or long > > > multiplication), and it is *exactly* as you would have written it with > > > digits, save that the digits have been replaced with letters (and > > > carries have been omitted, since that'd make it too easy). You > > > wouldn't write a leading zero on a number in standard grade-school > > > arithmetic, so you also won't use a leading zero in anything here. > > > > > > ChrisA > > > > All I know is that when I write a number 03, there is no any human being > > will say it's an illegal number. > > > > Yet most human beings will agree that you don't write out an > arithmetic problem as: > >0 1 9 8 > + 7 1 3 > = Python3 gives me the error message is because of the number 0198, not because of 0198 + 713. > > I prefer to buy the reason that this restriction was bring in is because of > > the puzzle's author know it will cause trouble without this, not because of > > our written habit. > > > > No, it's a restriction because it is unsatisfactory without it. The > point of a puzzle is to be fun, and fun means having restrictions that > fit what people expect. The fun is from solving the puzzle, not from its restriction, unless the puzzle has no fun without this restriction. --Jach > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Mon, Dec 10, 2018 at 9:46 PM wrote: > > Chris Angelico於 2018年12月10日星期一 UTC+8下午6時17分14秒寫道： > > On Mon, Dec 10, 2018 at 9:11 PM Antoon Pardon wrote: > > > > > > On 10/12/18 11:03, Chris Angelico wrote: > > > > Considering that, in a problem of that description, neither S nor M > > > > may represent zero, I don't think there's a problem here. > > > > > > Not all such problems have that condition. > > > > They should. Every published set of problems that I've ever solved by > > hand has. I went searching online for some, and found this page: > > > > http://puzzlepicnic.com/genre?alphametic > > > > which clearly states that exact restriction. The implication is that > > you're solving a puzzle in arithmetic (usually addition or long > > multiplication), and it is *exactly* as you would have written it with > > digits, save that the digits have been replaced with letters (and > > carries have been omitted, since that'd make it too easy). You > > wouldn't write a leading zero on a number in standard grade-school > > arithmetic, so you also won't use a leading zero in anything here. > > > > ChrisA > > All I know is that when I write a number 03, there is no any human being will > say it's an illegal number. > Yet most human beings will agree that you don't write out an arithmetic problem as: 0 1 9 8 + 7 1 3 = > I prefer to buy the reason that this restriction was bring in is because of > the puzzle's author know it will cause trouble without this, not because of > our written habit. > No, it's a restriction because it is unsatisfactory without it. The point of a puzzle is to be fun, and fun means having restrictions that fit what people expect. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
Chris Angelico於 2018年12月10日星期一 UTC+8下午6時17分14秒寫道： > On Mon, Dec 10, 2018 at 9:11 PM Antoon Pardon wrote: > > > > On 10/12/18 11:03, Chris Angelico wrote: > > > Considering that, in a problem of that description, neither S nor M > > > may represent zero, I don't think there's a problem here. > > > > Not all such problems have that condition. > > They should. Every published set of problems that I've ever solved by > hand has. I went searching online for some, and found this page: > > http://puzzlepicnic.com/genre?alphametic > > which clearly states that exact restriction. The implication is that > you're solving a puzzle in arithmetic (usually addition or long > multiplication), and it is *exactly* as you would have written it with > digits, save that the digits have been replaced with letters (and > carries have been omitted, since that'd make it too easy). You > wouldn't write a leading zero on a number in standard grade-school > arithmetic, so you also won't use a leading zero in anything here. > > ChrisA All I know is that when I write a number 03, there is no any human being will say it's an illegal number. I prefer to buy the reason that this restriction was bring in is because of the puzzle's author know it will cause trouble without this, not because of our written habit. --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Mon, Dec 10, 2018 at 9:11 PM Antoon Pardon wrote: > > On 10/12/18 11:03, Chris Angelico wrote: > > Considering that, in a problem of that description, neither S nor M > > may represent zero, I don't think there's a problem here. > > Not all such problems have that condition. They should. Every published set of problems that I've ever solved by hand has. I went searching online for some, and found this page: http://puzzlepicnic.com/genre?alphametic which clearly states that exact restriction. The implication is that you're solving a puzzle in arithmetic (usually addition or long multiplication), and it is *exactly* as you would have written it with digits, save that the digits have been replaced with letters (and carries have been omitted, since that'd make it too easy). You wouldn't write a leading zero on a number in standard grade-school arithmetic, so you also won't use a leading zero in anything here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 10/12/18 11:03, Chris Angelico wrote: > On Mon, Dec 10, 2018 at 9:01 PM Antoon Pardon wrote: >> On 8/12/18 06:00, Cameron Simpson wrote: >>> On 07Dec2018 20:24, Jach Fong wrote: Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: > What is it exactly that you're trying to accomplish with this? Perhaps > there's a better way than using eval. This problem comes from solving a word puzzle, ab + aa + cd == ce Each character will be translate to a digit and evaluate the correctness, 03 + 00 + 15 == 18 >>> Then you should be evaluating the digits and assembling values from >>> them. Not trying to shoehorn a string through something that _might_ >>> accept this string and do what you want. In Python 2 it will accept >>> your string and not do what you want; at least in Python 3 it doesn't >>> accept your string. >>> >>> My point here is that the structure of your puzzle doesn't map >>> directly into a naive python statement, and you shouldn't be >>> pretending it might. >> How do you figure? As far as I understand he is trying to solve this kind of >> puzzle: >> >> SEND >> MORE >> + >>MONEY >> >> Where every letter is to be replaced by a digit in such a way that the sum >> checks out. Sure trying to >> solve this by starting with the string: "SEND + MORE == MONEY" and doing >> replaces until eval comes up >> with true is not very sofisticated but I wouldn't call it shoehorning either. >> > Considering that, in a problem of that description, neither S nor M > may represent zero, I don't think there's a problem here. Not all such problems have that condition. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 8/12/18 07:59, Serhiy Storchaka wrote: > 08.12.18 03:17, jf...@ms4.hinet.net пише: > 00 >> 0 > 03 >> File "", line 1 >> 03 >> ^ >> SyntaxError: invalid token > > > In Python 3.8 the error message will be more informative: > 03 > File "", line 1 > SyntaxError: leading zeros in decimal integer literals are not > permitted; use an 0o prefix for octal integers > That is not helpful if it makes the code more meaningful to write 073 and I want it to have the value 73 not 0o73. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Mon, Dec 10, 2018 at 9:01 PM Antoon Pardon wrote: > > On 8/12/18 06:00, Cameron Simpson wrote: > > On 07Dec2018 20:24, Jach Fong wrote: > >> Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: > >>> What is it exactly that you're trying to accomplish with this? Perhaps > >>> there's a better way than using eval. > >> > >> This problem comes from solving a word puzzle, > >>ab + aa + cd == ce > >> Each character will be translate to a digit and evaluate the > >> correctness, > >>03 + 00 + 15 == 18 > > > > Then you should be evaluating the digits and assembling values from > > them. Not trying to shoehorn a string through something that _might_ > > accept this string and do what you want. In Python 2 it will accept > > your string and not do what you want; at least in Python 3 it doesn't > > accept your string. > > > > My point here is that the structure of your puzzle doesn't map > > directly into a naive python statement, and you shouldn't be > > pretending it might. > > How do you figure? As far as I understand he is trying to solve this kind of > puzzle: > > SEND > MORE > + >MONEY > > Where every letter is to be replaced by a digit in such a way that the sum > checks out. Sure trying to > solve this by starting with the string: "SEND + MORE == MONEY" and doing > replaces until eval comes up > with true is not very sofisticated but I wouldn't call it shoehorning either. > Considering that, in a problem of that description, neither S nor M may represent zero, I don't think there's a problem here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 8/12/18 06:00, Cameron Simpson wrote: > On 07Dec2018 20:24, Jach Fong wrote: >> Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: >>> What is it exactly that you're trying to accomplish with this? Perhaps >>> there's a better way than using eval. >> >> This problem comes from solving a word puzzle, >> ab + aa + cd == ce >> Each character will be translate to a digit and evaluate the >> correctness, >> 03 + 00 + 15 == 18 > > Then you should be evaluating the digits and assembling values from > them. Not trying to shoehorn a string through something that _might_ > accept this string and do what you want. In Python 2 it will accept > your string and not do what you want; at least in Python 3 it doesn't > accept your string. > > My point here is that the structure of your puzzle doesn't map > directly into a naive python statement, and you shouldn't be > pretending it might. How do you figure? As far as I understand he is trying to solve this kind of puzzle: SEND MORE + MONEY Where every letter is to be replaced by a digit in such a way that the sum checks out. Sure trying to solve this by starting with the string: "SEND + MORE == MONEY" and doing replaces until eval comes up with true is not very sofisticated but I wouldn't call it shoehorning either. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 8/12/18 09:35, Ian Kelly wrote: > On Fri, Dec 7, 2018 at 11:56 PM Henrik Bengtsson > wrote: >> A comment from the sideline: one could imagine extending the Python syntax >> with a (optional) 0d prefix that allows for explicit specification of >> decimal values. They would "complete" the family: >> >> * 0b: binary number >> * 0o: octal number >> * 0d: decimal number >> * 0x: hexadecimal number > That's nice and elegant, but what would be the use case? A use case is that sometimes numbers are a code for something else and this something else is more recognizable if all such coded numbers are written in a common length. The normal way to write such numbers in a common length is to start the number with sufficient zeroes. But that can now only be done in binary, octal and hexadecimal notation. Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Sat, Dec 8, 2018 at 7:57 PM wrote:
>
> Grant Edwards於 2018年12月9日星期日 UTC+8上午12時52分04秒寫道：
> > Just to be clear: you do _not_ want to use eval on the string.
> >
> > If you're not the one who created the string, it might wipe your hard
> > drive or empty your bank account. If you _are_ the one who created
> > the string, then generate the desired result instead.
> >
> > --
> > Grant
>
> I didn't evaluate the input string directly. It's the translated "digit"
> string been evaluated, so shouldn't have any danger on using eval().
Replacing the first five letters of the alphabet is not sufficient to
sanitize untrusted input for eval. Here's a simple example that avoids
using any of those letters:
py> eval(re.sub(r'[a-e]', '0',
"__import__('su\\x62pro\\x63\\x65ss').run('\\x65\\x63ho rm -rf /',
**{'sh\\x65ll': 1})"))
rm -rf /
CompletedProcess(args='echo rm -rf /', returncode=0)
Now, if you remove *all* the characters that could possibly start
identifiers
(https://docs.python.org/3/reference/lexical_analysis.html#identifiers)
then you might be safe. Possibly just removing all the ones in ASCII
(A-Z + a-z + _) would suffice. I make no guarantees either way.
I wish I could say you should just use ast.literal_eval instead.
Unfortunately it doesn't seem to support ==:
py> ast.literal_eval('10 + 20 == 30')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/ast.py", line 84, in literal_eval
return _convert(node_or_string)
File "/usr/lib/python3.5/ast.py", line 83, in _convert
raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Compare object at 0x78172bee5358>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
> 'b' : b,
> 'c' : 'any digit',
> 'd' : d,
> 'e' : e
> }
> print(solution)
>
> ### END CODE ##
> ### BEGIN OUTPUT ##
> SOLVING FOR: 21*a + b + d - e == 0
> matches found in batches of 10: 32
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 2, 'e': 3}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 3, 'e': 4}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 4, 'e': 5}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 5, 'e': 6}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 6, 'e': 7}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 7, 'e': 8}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 8, 'e': 9}
> {'a': 0, 'b': 2, 'c': 'any digit', 'd': 1, 'e': 3}
> {'a': 0, 'b': 2, 'c': 'any digit', 'd': 3, 'e': 5}
> {'a': 0, 'b': 2, 'c': 'any digit', 'd': 4, 'e': 6}
> {'a': 0, 'b': 2, 'c': 'any digit', 'd': 5, 'e': 7}
> {'a': 0, 'b': 2, 'c': 'any digit', 'd': 6, 'e': 8}
> {'a': 0, 'b': 2, 'c': 'any digit', 'd': 7, 'e': 9}
> {'a': 0, 'b': 3, 'c': 'any digit', 'd': 1, 'e': 4}
> {'a': 0, 'b': 3, 'c': 'any digit', 'd': 2, 'e': 5}
> {'a': 0, 'b': 3, 'c': 'any digit', 'd': 4, 'e': 7}
> {'a': 0, 'b': 3, 'c': 'any digit', 'd': 5, 'e': 8}
> {'a': 0, 'b': 3, 'c': 'any digit', 'd': 6, 'e': 9}
> {'a': 0, 'b': 4, 'c': 'any digit', 'd': 1, 'e': 5}
> {'a': 0, 'b': 4, 'c': 'any digit', 'd': 2, 'e': 6}
> {'a': 0, 'b': 4, 'c': 'any digit', 'd': 3, 'e': 7}
> {'a': 0, 'b': 4, 'c': 'any digit', 'd': 5, 'e': 9}
> {'a': 0, 'b': 5, 'c': 'any digit', 'd': 1, 'e': 6}
> {'a': 0, 'b': 5, 'c': 'any digit', 'd': 2, 'e': 7}
> {'a': 0, 'b': 5, 'c': 'any digit', 'd': 3, 'e': 8}
> {'a': 0, 'b': 5, 'c': 'any digit', 'd': 4, 'e': 9}
> {'a': 0, 'b': 6, 'c': 'any digit', 'd': 1, 'e': 7}
> {'a': 0, 'b': 6, 'c': 'any digit', 'd': 2, 'e': 8}
> {'a': 0, 'b': 6, 'c': 'any digit', 'd': 3, 'e': 9}
> {'a': 0, 'b': 7, 'c': 'any digit', 'd': 1, 'e': 8}
> {'a': 0, 'b': 7, 'c': 'any digit', 'd': 2, 'e': 9}
> {'a': 0, 'b': 8, 'c': 'any digit', 'd': 1, 'e': 9}
>
> SOLVING FOR: b + d == e
> matches found in batches of 10: 32
> {'a': '0', 'b': 1, 'c': 'any digit', 'd': 2, 'e': 3}
> {'a': '0', 'b': 1, 'c': 'any digit', 'd': 3, 'e': 4}
> {'a': '0', 'b': 1, 'c': 'any digit', 'd': 4, 'e': 5}
> {'a': '0', 'b': 1, 'c': 'any digit', 'd': 5, 'e': 6}
> {'a': '0', 'b': 1, 'c': 'any digit', 'd': 6, 'e': 7}
> {'a': '0', 'b': 1, 'c': 'any digit', 'd': 7, 'e': 8}
> {&#
Re: Why Python don't accept 03 as a number?
Grant Edwards於 2018年12月9日星期日 UTC+8上午12時52分04秒寫道： > On 2018-12-08, Cameron Simpson wrote: > > On 07Dec2018 20:24, Jach Fong wrote: > >>Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: > >>> What is it exactly that you're trying to accomplish with this? Perhaps > >>> there's a better way than using eval. > >> > >>This problem comes from solving a word puzzle, > >>ab + aa + cd == ce > >>Each character will be translate to a digit and evaluate the correctness, > >>03 + 00 + 15 == 18 > > > > Then you should be evaluating the digits and assembling values from > > them. Not trying to shoehorn a string through something that _might_ > > accept this string and do what you want. In Python 2 it will accept your > > string and not do what you want; at least in Python 3 it doesn't accept > > your string. > > Just to be clear: you do _not_ want to use eval on the string. > > If you're not the one who created the string, it might wipe your hard > drive or empty your bank account. If you _are_ the one who created > the string, then generate the desired result instead. > > -- > Grant I didn't evaluate the input string directly. It's the translated "digit" string been evaluated, so shouldn't have any danger on using eval(). --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 12/8/18 6:23 PM, Avi Gross wrote: > [DISCLAIMER: less about python than analysis of a puzzle] > > Richard, > > Thank you for pointing out that c in the puzzle is constrained. That > explains why my 320 answers are too many. It cannot be 0 as "a" is always > zero and it cannot be the three other values that b,d,e are using at the > time. So my earlier solution should say c is any of six available choices. > > So 6 * 32 is 192 solutions. > > Your analysis requires considering a carry from the right column into the > left. I skipped that by converting something like ab to 10*a+b. > > This all began with someone trying to enter 03 which suggests they may have > been starting to look at it your way. As a logic puzzle to do those with > pencil and paper, your analysis is spot on. There is additional info to be > gleaned by looking at adding columns. I chose a perspective on more brute > force methods and whittled it down to less forceful. Given that c was > removed from the equation, though, and that only 6 of 10 options are > available for any given time, I would need another pass at the answers and > for each solution for the others (b,d,e if we agree a is always 0) I would > need to make six entries with c set successively to digits-set(0,b,d,e} or > something like that. > > I note that programming some of the kinds of analysis some of these puzzles > use is not as easy in programming languages as a more brute-force approach > that computers are better at than humans. Actually, part of my point was that we are often tempted to go simple brute force when a bit of analysis can often vastly simplify the problem to be solved. Now, the brute force program, if done right, could also handle other related problems like SEND+MORE=MONEY But now, the input equation isn't controlled by the program, so you need to be very careful about using it for something that gets sent to eval, and by the time you take that care, perhaps it is easier to do the safer way. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
RE: Why Python don't accept 03 as a number?
[DISCLAIMER: less about python than analysis of a puzzle] Richard, Thank you for pointing out that c in the puzzle is constrained. That explains why my 320 answers are too many. It cannot be 0 as "a" is always zero and it cannot be the three other values that b,d,e are using at the time. So my earlier solution should say c is any of six available choices. So 6 * 32 is 192 solutions. Your analysis requires considering a carry from the right column into the left. I skipped that by converting something like ab to 10*a+b. This all began with someone trying to enter 03 which suggests they may have been starting to look at it your way. As a logic puzzle to do those with pencil and paper, your analysis is spot on. There is additional info to be gleaned by looking at adding columns. I chose a perspective on more brute force methods and whittled it down to less forceful. Given that c was removed from the equation, though, and that only 6 of 10 options are available for any given time, I would need another pass at the answers and for each solution for the others (b,d,e if we agree a is always 0) I would need to make six entries with c set successively to digits-set(0,b,d,e} or something like that. I note that programming some of the kinds of analysis some of these puzzles use is not as easy in programming languages as a more brute-force approach that computers are better at than humans. -Original Message- From: Python-list On Behalf Of Richard Damon Sent: Saturday, December 8, 2018 5:30 PM To: python-list@python.org Subject: Re: Why Python don't accept 03 as a number? On 12/8/18 12:40 PM, Avi Gross wrote: > You are solving for: ab + aa + cd == ce Actually, an even quicker analysis for this particular problem is: from the 10s digits, a + a + c + carryin = c Thus a and carryin must both be 0 (carryin can not be negative, nor any of the variables) thus the final solution space is: b + d = e a = 0 c any other digit (6 possible values for every combo of b, d, e) if b is <= 4, there are 8-b possible values of d that will have a legal value of e. b = 1, we get d = 2, 3, 4, ... 7, 8 b = 2, we get d = 1, 3, 4, ... 6, 7 (8 would generate carry) b = 3, we get d = 1, 2, 4, 5, 6 b = 4, we get d = 1, 2, 3, 5 if b >= 5 we get 9-b possible values of d (we no longer have to omit the possible value of b = d) So the number of possible answers are: (7+6+5+4+4+3+2+1)*6 = 192 (your 320 was you gave c 10 possible values, but you need to remove the duplicates). -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 12/8/18 12:40 PM, Avi Gross wrote: > You are solving for: ab + aa + cd == ce Actually, an even quicker analysis for this particular problem is: from the 10s digits, a + a + c + carryin = c Thus a and carryin must both be 0 (carryin can not be negative, nor any of the variables) thus the final solution space is: b + d = e a = 0 c any other digit (6 possible values for every combo of b, d, e) if b is <= 4, there are 8-b possible values of d that will have a legal value of e. b = 1, we get d = 2, 3, 4, ... 7, 8 b = 2, we get d = 1, 3, 4, ... 6, 7 (8 would generate carry) b = 3, we get d = 1, 2, 4, 5, 6 b = 4, we get d = 1, 2, 3, 5 if b >= 5 we get 9-b possible values of d (we no longer have to omit the possible value of b = d) So the number of possible answers are: (7+6+5+4+4+3+2+1)*6 = 192 (your 320 was you gave c 10 possible values, but you need to remove the duplicates). -- https://mail.python.org/mailman/listinfo/python-list
RE: Why Python don't accept 03 as a number?
x27;, 'd': 4, 'e': 5}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 5, 'e': 6}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 6, 'e': 7}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 7, 'e': 8}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 8, 'e': 9}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 1, 'e': 3}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 3, 'e': 5}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 4, 'e': 6}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 5, 'e': 7}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 6, 'e': 8}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 7, 'e': 9}
{'a': 0, 'b': 3, 'c': 'any digit', 'd': 1, 'e': 4}
{'a': 0, 'b': 3, 'c': 'any digit', 'd': 2, 'e': 5}
{'a': 0, 'b': 3, 'c': 'any digit', 'd': 4, 'e': 7}
{'a': 0, 'b': 3, 'c': 'any digit', 'd': 5, 'e': 8}
{'a': 0, 'b': 3, 'c': 'any digit', 'd': 6, 'e': 9}
{'a': 0, 'b': 4, 'c': 'any digit', 'd': 1, 'e': 5}
{'a': 0, 'b': 4, 'c': 'any digit', 'd': 2, 'e': 6}
{'a': 0, 'b': 4, 'c': 'any digit', 'd': 3, 'e': 7}
{'a': 0, 'b': 4, 'c': 'any digit', 'd': 5, 'e': 9}
{'a': 0, 'b': 5, 'c': 'any digit', 'd': 1, 'e': 6}
{'a': 0, 'b': 5, 'c': 'any digit', 'd': 2, 'e': 7}
{'a': 0, 'b': 5, 'c': 'any digit', 'd': 3, 'e': 8}
{'a': 0, 'b': 5, 'c': 'any digit', 'd': 4, 'e': 9}
{'a': 0, 'b': 6, 'c': 'any digit', 'd': 1, 'e': 7}
{'a': 0, 'b': 6, 'c': 'any digit', 'd': 2, 'e': 8}
{'a': 0, 'b': 6, 'c': 'any digit', 'd': 3, 'e': 9}
{'a': 0, 'b': 7, 'c': 'any digit', 'd': 1, 'e': 8}
{'a': 0, 'b': 7, 'c': 'any digit', 'd': 2, 'e': 9}
{'a': 0, 'b': 8, 'c': 'any digit', 'd': 1, 'e': 9}
SOLVING FOR: b + d == e
matches found in batches of 10: 32
{'a': '0', 'b': 1, 'c': 'any digit', 'd': 2, 'e': 3}
{'a': '0', 'b': 1, 'c': 'any digit', 'd': 3, 'e': 4}
{'a': '0', 'b': 1, 'c': 'any digit', 'd': 4, 'e': 5}
{'a': '0', 'b': 1, 'c': 'any digit', 'd': 5, 'e': 6}
{'a': '0', 'b': 1, 'c': 'any digit', 'd': 6, 'e': 7}
{'a': '0', 'b': 1, 'c': 'any digit', 'd': 7, 'e': 8}
{'a': '0', 'b': 1, 'c': 'any digit', 'd': 8, 'e': 9}
{'a': '0', 'b': 2, 'c': 'any digit', 'd': 1, 'e': 3}
{'a': '0', 'b': 2, 'c': 'any digit', 'd': 3, 'e': 5}
{'a': '0', 'b': 2, 'c': 'any digit', 'd': 4, 'e': 6}
{'a': '0', 'b': 2, 'c': 'any digit', 'd': 5, 'e': 7}
{'a': '0', 'b': 2, 'c': 'any digit', 'd': 6, 'e': 8}
{'a': '0', 'b': 2, 'c': 'any digit', 'd': 7, 'e': 9}
{'a': '0', 'b': 3, 'c': 'any dig
Re: Why Python don't accept 03 as a number?
On 2018-12-08, Cameron Simpson wrote: > On 07Dec2018 20:24, Jach Fong wrote: >>Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: >>> What is it exactly that you're trying to accomplish with this? Perhaps >>> there's a better way than using eval. >> >>This problem comes from solving a word puzzle, >>ab + aa + cd == ce >>Each character will be translate to a digit and evaluate the correctness, >>03 + 00 + 15 == 18 > > Then you should be evaluating the digits and assembling values from > them. Not trying to shoehorn a string through something that _might_ > accept this string and do what you want. In Python 2 it will accept your > string and not do what you want; at least in Python 3 it doesn't accept > your string. Just to be clear: you do _not_ want to use eval on the string. If you're not the one who created the string, it might wipe your hard drive or empty your bank account. If you _are_ the one who created the string, then generate the desired result instead. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 12/7/18 11:24 PM, jf...@ms4.hinet.net wrote: > Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: >> What is it exactly that you're trying to accomplish with this? Perhaps >> there's a better way than using eval. > This problem comes from solving a word puzzle, > ab + aa + cd == ce > Each character will be translate to a digit and evaluate the correctness, > 03 + 00 + 15 == 18 > For the classic version of that problem, a = 0 is not allowed, since you never in 'normal' life write number with leading zeros, the alpha-math problems never have leading zeros either. As other have said, the work to compute the value yourself rather than due the text substitution and eval is close to comparable. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
Avi Gross at 2018/12/8 UTC+8 PM2:09:20 wrote:
> [[READERS DIGEST CONDENSED ANSWER: use int("string") ]]
>
> Since we all agree python will not make notations like "05" work
> indefinitely, and the need expressed is how to solve a symbolic puzzle (see
> message below) then it makes sense to look at alternate representations.
>
> I have a question first. How are you solving your puzzles?
>
> ab + aa + cd == ce
Try all the combinations:-)
The only way I can think of is try-error. It takes no more 10 lines to go from
"ab + aa + cd == ce" to yield one correct answer, such as "03 + 00 + 15 == 18",
using itertools' permutations(), string's translate() and re.
> Why does 05 ever even appear in your solution?
I don't know. There is total 192 answers for this puzzle anyway.
> Are you generating all possible answers by setting each variable to one of 0
> to 9 then the second to any of the remaining nine choices then the third to
> the remaining 8 and so on? For any method like that, you can presumably make
> each component like
>
> ab = 10*a + b
>
> in the loop.
>
> Similarly for aa and cd and ce. If the equality above is true, you found the
> solution and break out. If there can be multiple solutions, note the
> solution and keep going. But note for the 5 variables above, you are testing
> 10*9*8*7*6 combinations.
>
> Another idea is to use strings like "05" as bizarrely, the function int()
> seems to be an ex eption that does NOT care about leading whitespace or
> zeroes:
>
> >>> int("05")
> 5
> >>> int(" 0005")
> 5
>
> And even handles all zeroes:
>
> >>> int("00")
> 0
>
> You can also use lstrip() with an argument to remove zeros:
>
> >>> a = eval("05".lstrip("0"))
>
> >>> a
>
> 5
>
> If you are in a situation where you only want to remove leading zeroes if
> the following character is a digit and not "o" or "b" or "x", use regular
> expressions or other techniques.
As far as the leading zero problem was concerned, the simplest way is using
re.sub()
> I will just toss in the possible use of the SymPy module to do actual
> symbolic computations to solve some of these. Perhaps a tad advanced.
I don't know SymPy and if it can shorten the execution time. But I am very
curious about if there is other algorithm which can apply to this problem:-)
--Jach
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
08.12.18 08:53, Henrik Bengtsson пише:
A comment from the sideline: one could imagine extending the Python syntax
with a (optional) 0d prefix that allows for explicit specification of
decimal values. They would "complete" the family:
* 0b: binary number
* 0o: octal number
* 0d: decimal number
* 0x: hexadecimal number
I understand that changing the syntax/parser is a major move. I wouldn't be
surprised if others brought up 0d before.
It is more likely that 'd' will be used for Decimal literals.
1d-2 == Decimal('0.01')
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Fri, Dec 7, 2018 at 11:56 PM Henrik Bengtsson wrote: > > A comment from the sideline: one could imagine extending the Python syntax > with a (optional) 0d prefix that allows for explicit specification of > decimal values. They would "complete" the family: > > * 0b: binary number > * 0o: octal number > * 0d: decimal number > * 0x: hexadecimal number That's nice and elegant, but what would be the use case? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
08.12.18 03:17, jf...@ms4.hinet.net пише: 00 0 03 File "", line 1 03 ^ SyntaxError: invalid token In Python 3.8 the error message will be more informative: 03 File "", line 1 SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
A comment from the sideline: one could imagine extending the Python syntax with a (optional) 0d prefix that allows for explicit specification of decimal values. They would "complete" the family: * 0b: binary number * 0o: octal number * 0d: decimal number * 0x: hexadecimal number I understand that changing the syntax/parser is a major move. I wouldn't be surprised if others brought up 0d before. My $.02 Henrik On Fri, Dec 7, 2018, 21:12 Cameron Simpson On 07Dec2018 20:24, Jach Fong wrote: > >Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: > >> What is it exactly that you're trying to accomplish with this? Perhaps > >> there's a better way than using eval. > > > >This problem comes from solving a word puzzle, > >ab + aa + cd == ce > >Each character will be translate to a digit and evaluate the correctness, > >03 + 00 + 15 == 18 > > Then you should be evaluating the digits and assembling values from > them. Not trying to shoehorn a string through something that _might_ > accept this string and do what you want. In Python 2 it will accept your > string and not do what you want; at least in Python 3 it doesn't accept > your string. > > My point here is that the structure of your puzzle doesn't map directly > into a naive python statement, and you shouldn't be pretending it might. > > Cheers, > Cameron Simpson > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: Why Python don't accept 03 as a number?
[[READERS DIGEST CONDENSED ANSWER: use int("string") ]]
Since we all agree python will not make notations like "05" work
indefinitely, and the need expressed is how to solve a symbolic puzzle (see
message below) then it makes sense to look at alternate representations.
I have a question first. How are you solving your puzzles?
ab + aa + cd == ce
Why does 05 ever even appear in your solution?
Are you generating all possible answers by setting each variable to one of 0
to 9 then the second to any of the remaining nine choices then the third to
the remaining 8 and so on? For any method like that, you can presumably make
each component like
ab = 10*a + b
in the loop.
Similarly for aa and cd and ce. If the equality above is true, you found the
solution and break out. If there can be multiple solutions, note the
solution and keep going. But note for the 5 variables above, you are testing
10*9*8*7*6 combinations.
Another idea is to use strings like "05" as bizarrely, the function int()
seems to be an ex eption that does NOT care about leading whitespace or
zeroes:
>>> int("05")
5
>>> int(" 0005")
5
And even handles all zeroes:
>>> int("00")
0
You can also use lstrip() with an argument to remove zeros:
>>> a = eval("05".lstrip("0"))
>>> a
5
If you are in a situation where you only want to remove leading zeroes if
the following character is a digit and not "o" or "b" or "x", use regular
expressions or other techniques.
I will just toss in the possible use of the SymPy module to do actual
symbolic computations to solve some of these. Perhaps a tad advanced.
-Original Message-
From: Python-list On
Behalf Of jf...@ms4.hinet.net
Sent: Friday, December 7, 2018 11:25 PM
To: python-list@python.org
Subject: Re: Why Python don't accept 03 as a number?
Ian at 2018/12/8 UTC+8 AM11:28:34 wrote:
> What is it exactly that you're trying to accomplish with this? Perhaps
> there's a better way than using eval.
This problem comes from solving a word puzzle,
ab + aa + cd == ce
Each character will be translate to a digit and evaluate the correctness,
03 + 00 + 15 == 18
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 07Dec2018 20:24, Jach Fong wrote: Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: What is it exactly that you're trying to accomplish with this? Perhaps there's a better way than using eval. This problem comes from solving a word puzzle, ab + aa + cd == ce Each character will be translate to a digit and evaluate the correctness, 03 + 00 + 15 == 18 Then you should be evaluating the digits and assembling values from them. Not trying to shoehorn a string through something that _might_ accept this string and do what you want. In Python 2 it will accept your string and not do what you want; at least in Python 3 it doesn't accept your string. My point here is that the structure of your puzzle doesn't map directly into a naive python statement, and you shouldn't be pretending it might. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
I can understand the difficulty of throwing old thing away and accept new one in human. There seems have a huge inertia there. This phenomenon appears on every aspects, not only on the transition from Python2 to Python3. But, as a new comer of Python like me, I have no difficulty to accept it because of 03 is a valid number in my daily life and never had the experience of treating 010 as 8:-) MBAB wrote: > We could just wait until all the old C programmers have died. :-) Yes, it's the nature way. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: > What is it exactly that you're trying to accomplish with this? Perhaps > there's a better way than using eval. This problem comes from solving a word puzzle, ab + aa + cd == ce Each character will be translate to a digit and evaluate the correctness, 03 + 00 + 15 == 18 -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 2018-12-08 03:49, Joe Pfeiffer wrote:
jf...@ms4.hinet.net writes:
MRAB at 2018/12/8 UTC+8 AM10:04:51 wrote:
Before Python 3, a leading 0 in an integer literal would indicate an
octal (base 8) number.
So, the reason is historical.
The old form is now invalid in order to reduce the chance of bugs.
I encounter this problem on trying to do something like this:
eval('03 + 00 + 15')
It takes me some efforts to get rid of those leading zeros:-(
Hope someday 03 can be accepted as a valid decimal number in Python 3.
Thank you for explaining.
--Jach
I'd say we *really* don't want that. We'd have old C programmers (like
me) expecting 010 to mean 8, and getting really confused...
We could just wait until all the old C programmers have died. :-)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
jf...@ms4.hinet.net writes:
> MRAB at 2018/12/8 UTC+8 AM10:04:51 wrote:
>> Before Python 3, a leading 0 in an integer literal would indicate an
>> octal (base 8) number.
>
> So, the reason is historical.
>
>> The old form is now invalid in order to reduce the chance of bugs.
>
> I encounter this problem on trying to do something like this:
> eval('03 + 00 + 15')
> It takes me some efforts to get rid of those leading zeros:-(
>
> Hope someday 03 can be accepted as a valid decimal number in Python 3.
>
> Thank you for explaining.
>
> --Jach
I'd say we *really* don't want that. We'd have old C programmers (like
me) expecting 010 to mean 8, and getting really confused...
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Fri, Dec 7, 2018 at 7:47 PM wrote:
>
> MRAB at 2018/12/8 UTC+8 AM10:04:51 wrote:
> > Before Python 3, a leading 0 in an integer literal would indicate an
> > octal (base 8) number.
>
> So, the reason is historical.
>
> > The old form is now invalid in order to reduce the chance of bugs.
>
> I encounter this problem on trying to do something like this:
> eval('03 + 00 + 15')
> It takes me some efforts to get rid of those leading zeros:-(
What is it exactly that you're trying to accomplish with this? Perhaps
there's a better way than using eval.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Sat, Dec 8, 2018 at 1:46 PM wrote:
>
> MRAB at 2018/12/8 UTC+8 AM10:04:51 wrote:
> > Before Python 3, a leading 0 in an integer literal would indicate an
> > octal (base 8) number.
>
> So, the reason is historical.
>
> > The old form is now invalid in order to reduce the chance of bugs.
>
> I encounter this problem on trying to do something like this:
> eval('03 + 00 + 15')
> It takes me some efforts to get rid of those leading zeros:-(
>
> Hope someday 03 can be accepted as a valid decimal number in Python 3.
>
Definitely not. What happens to all the code that used to be legal and
meant octal, and would become legal again but with a different
meaning? It'd be bad enough to have Python interpret something in a
way that's subtly different from the way other languages do (annoying,
but livable), but to do that across versions of the language would be
an incredibly bad idea.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
MRAB at 2018/12/8 UTC+8 AM10:04:51 wrote:
> Before Python 3, a leading 0 in an integer literal would indicate an
> octal (base 8) number.
So, the reason is historical.
> The old form is now invalid in order to reduce the chance of bugs.
I encounter this problem on trying to do something like this:
eval('03 + 00 + 15')
It takes me some efforts to get rid of those leading zeros:-(
Hope someday 03 can be accepted as a valid decimal number in Python 3.
Thank you for explaining.
--Jach
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 2018-12-08 01:17, jf...@ms4.hinet.net wrote: 00 0 03 File "", line 1 03 ^ SyntaxError: invalid token Any particular reason? Before Python 3, a leading 0 in an integer literal would indicate an octal (base 8) number. In Python 2.7: >>> 010 8 That notation was borrowed from C. The hexadecimal (base 16) notation of a leading 0x was also borrowed from C (it was a later introduction to the language). Python also has the binary (base 2) notation of a leading 0b. For Python 3, it was felt that it would be clearer to have an octal notation that didn't use just a leading 0, so it was changed to a leading 0o. The old form is now invalid in order to reduce the chance of bugs. If you're coming from Python 2, you might expect that 010 is still octal, and if you're not familiar with that notation, you might expect that it's decimal. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
Às 01:17 de 08/12/18, jf...@ms4.hinet.net escreveu: 00 > 0 03 > File "", line 1 > 03 > ^ > SyntaxError: invalid token > > Any particular reason? > Not sure but I think that after 0 it expects x for hexadecimal, o for octal, b for binary, ... may be others. 0xa 10 0o10 8 0b10 2 -- https://mail.python.org/mailman/listinfo/python-list
Why Python don't accept 03 as a number?
>>> 00 0 >>> 03 File "", line 1 03 ^ SyntaxError: invalid token >>> Any particular reason? -- https://mail.python.org/mailman/listinfo/python-list
