Re: Why Python don't accept 03 as a number?

[Chris Angelico]

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?

[Avi Gross]

READERS DIGEST CONDENSED QUESTION: How expensive is eval("123 + 456 == 975") 
versus other ways?

The discussion started by Jach has spread away from discussing how python deals 
with numbers starting with leading zeroes such as "03". I note there are many 
ID numbers like social security that have a leading zero so if converted to an 
int for storage reasons, ...

The TOPIC I want to discuss is the concerns about Jach wanting to use "eval()". 
Besides security concerns, I want to know if it is particularly expensive.

It was suggested that you might solve a range of problems like puzzles asking 
you to substitute unique digits for letters. Some of  these puzzles are  
normally solved with logic a step at a time but the techniques used may require 
a specific order and may not be easy to program for a more general case so can 
it be solved using what might be termed brute force. I mean try EVERYTHING that 
might work, including some that might not.

A particular example was: SEND + MORE = MONEY.

Jach's suggestion was to take every possible combination of digits and make the 
substitutions for the letters in that puzzle: then do something like this:

>>> eval ("9567+1085==10652")
True
>>> eval("123+456==975")
False

So, although better algorithms exist, no doubt, I considered what it would take 
to do this without an eval. I came up with the following as an outline.

Accept the puzzle as a string with any number of items to the right or left of 
an "=" as long as they only have whitespace and plus signs in addition to 
alphabetic characters. So "AE + DF = CE + AB + AA" would be fine. This model 
does not include doing subtraction or other things, just a simple model like 
that, for now.

You can easily remove whitespace, force everything to one case, split it into a 
left/right on "=" and then split those into lists on "+.

You now have two lists of alphabetic strings that ultimately must become lists 
of integers and then the sums can be compared.

To get the number of unique letters in the puzzle, N, you throw all the list 
items as individual characters into a set. Clearly, for this kind of puzzle, 
there cannot be more than ten unique letters or there can be no unique mapping 
for 0-9.

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.

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.

Finally, with no eval needed, you take the sum of the numbers in a list of the 
left and compare to the sum on the right and if equal, you present the solution 
in whatever way works. If no more solutions are needed, you quit. I might write 
this part as a generator too, that can be called once or to completion.

Yes, this is brute force. Using range(1,000,000) (no commas in real use) 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.

The above description includes parts that may also be used in the eval 
situation. The main difference may be that my method uses int() and perhaps 
some string functions. So, does eval just divert the attention of the 
interpreter as may happen with importing a module, or does it invoke a second 
copy of the interpreter as may happen with some multitasking methods? I would 
guess the former. But it may also have to first compile the text into byte 
code. However, a full eval is like using a sledgehammer when a thumbtack might 
be enough. Then again, it is already sitting there so a little extra use might 
be cheap.

So a main reason for my variant might still be to avoid taking any chances on 
rogue code. Mind you, in the above I would remove everything except [a-zA-Z=+] 
including parentheses and 

Re: tkinter resizable text with grid

[lizhollinshead5]

On Thursday, 6 December 2018 07:02:50 UTC, Paulo da Silva  wrote:
> Hi!
> 
> Does anybody know why this code does not expand the text widget when I
> increase the window size (with mouse)? I want height and width but as
> minimum (or may be initial) size.
> 
> import tkinter as tk
> 
> class App:
>   def __init__(self,master):
>   self.tboard=tk.Text(master,height=40,width=50)
>   self.tboard.grid(row=1,column=1,sticky="nsew")
>   self.tboard.grid_rowconfigure(1,weight=1)
>   self.tboard.grid_columnconfigure(1,weight=1)
> 
> root=tk.Tk()
> app=App(root)
> 
> root.mainloop()
> 
> Thanks

Others here have commented about Tkinter.  I'm not a professional programmer, 
and I struggled with Python2 and Tkinter for a while.  It worked, but it was a 
struggle.
*
A few years ago I started using Glade and Python3 (and gi.repository).  Much 
easier, much less Python code, much easier to maintain.
*
Not that I'm much of a critic of Tkinter, just that the alternative is simpler 
and easier.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: polar coordinates?

[Cousin Stanley]

Brian Christiansen wrote:

> 
> I guess my question is if python can do this natively 
> or if there is a package somewhere ( polar.py ? ) that can do this
> 

  You might consider  matplotlib  for polar coordinate plotting ...

https://matplotlib.org/examples/pylab_examples/polar_demo.html


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to host python micro-services on windows machine?

[oliver]

You might also find that
https://www.raymond.cc/blog/keep-application-running-by-automatically-rerun-when-closed/
lists some useful options.

But most solutions I read about for Windows seem to be based on its
Services subsystem and its ability to restart and control how many time to
retry.

On Mon., Dec. 10, 2018, 07:17 oliver,  wrote:

> There are a few options in https://stackoverflow.com/q/7629813/869951,
> esp the third answer.
>
> On Mon., Dec. 10, 2018, 02:41 ,  wrote:
>
>> I am developing some micro-services in python. I want to host that
>> micro-services on windows machine. For ubuntu I am using Supervisord. What
>> should I use for Windows ? Please help
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
> --
> Oliver Schoenborn
>   || Cloud Application Engineer, Owner || Sentian Software Engineering ||
> Ottawa, ON, Canada
>   || +1-613-552-4466 (mobile) || @schollii2 (Twitter) || schoenborno (
> Skype)
>   || LinkedIn  || StackOverFlow
>  || CodeProject
>  || GitHub
> 
>
> --
Oliver Schoenborn
  || Cloud Application Engineer, Owner || Sentian Software Engineering ||
Ottawa, ON, Canada
  || +1-613-552-4466 (mobile) || @schollii2 (Twitter) || schoenborno (Skype)
  || LinkedIn  || StackOverFlow
 || CodeProject
 || GitHub

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Program to keep track of success percentage

[Cousin Stanley]

Musatov wrote:

> I am thinking about a program where the only user input is win/loss. 
> 
> The program let's you know if you have won 
> more than 31% of the time or not. 
> 
> Any suggestions about how to approach authoring
> such a program? Thanks.

  The following results are from a python  toss_up  program
  using the python random.choice module where  win  or  lose  
  was chosen randomly for each try for various numbers of tries 

  For random choice of  win  or  lose 
  distribution seems to be very even 
  for each result  

 # tries   win %   lose %

10 50.0050.00
   100 52.0048.00
  1000 48.4051.60
 1 49.7550.25
10 50.1749.83
   100 50.0050.00


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to host python micro-services on windows machine?

[oliver]

There are a few options in https://stackoverflow.com/q/7629813/869951, esp
the third answer.

On Mon., Dec. 10, 2018, 02:41 ,  wrote:

> I am developing some micro-services in python. I want to host that
> micro-services on windows machine. For ubuntu I am using Supervisord. What
> should I use for Windows ? Please help
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
Oliver Schoenborn
  || Cloud Application Engineer, Owner || Sentian Software Engineering ||
Ottawa, ON, Canada
  || +1-613-552-4466 (mobile) || @schollii2 (Twitter) || schoenborno (Skype)
  || LinkedIn  || StackOverFlow
 || CodeProject
 || GitHub

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python don't accept 03 as a number?

[Antoon Pardon]

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?

[Chris Angelico]

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?

[jfong]

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?

[Chris Angelico]

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?

[jfong]

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?

[Chris Angelico]

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?

[Antoon Pardon]

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?

[Antoon Pardon]

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?

[Chris Angelico]

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?

[Antoon Pardon]

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?

[Antoon Pardon]

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: Basic pynomo instructions not working

[Adam Funk]

On 2018-11-22, dieter wrote:

> The "pynomo" version you have installed may have been developped for
> Python 2 and not run in "python3".
>
> In Python 2, you have implicit relative imports.
> As an example, it allows modules in the package "pynomo"
> to use "import nomo_wrapper" to import the submodule "nomo_wrapper".
> Python 3 has discarded implicit relative imports. In
> the example above, "import nomo_wrapper" must become
> "from . import nomo_wrapper" (explicit relative import)
> or "import pynomo.nomo_wrapper as nomo_wrapper" (absolute import).
>
> For the time being, you still find many packages which run
> only under Python 2. Failing relative imports or syntax errors
> are a frequent indication towards this.

Yup, that's the problem --- it does work in Python 2.  I didn't think
of that at first because there was a pip3 package for it!


-- 
Growth for growth's sake is the ideology of the cancer cell.
 ---Edward Abbey
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating type evaluation annotation

[Marek Mosiewicz]

W dniu 09.12.2018, nie o godzinie 15∶50 -0500, użytkownik Terry Reedy
napisał:
> 
> Mypy recognizes this sublanguage to 'compute' whether calls conform
> to 
> the defined interfaces.
> 
As far as I understand currently it computes if declaration commits to
static type. What I propose is to annotate type with "duck" typing
checker and futher it could make suggester for duck typing. We can
imagine duck typing suggester for imaginary entity class which accepts
finders like in Ruby on rails : "find_by_name" "find_by_id"
"find_by_name_and_something"

Then when you type "find_" it will suggest futher method name. When you
finish typing "find_by_name_and_length" for example it will force you
to put two paramters of type string and int
> 
> -- 
> Terry Jan Reedy
> 
-- 
https://mail.python.org/mailman/listinfo/python-list