Re: tkinter MP working like a charm

[Abdur-Rahmaan Janhangeer]

@Chris

hum nice point

it seems to be related to namespace convenience

like

1 from x import *

is likelier to cause conflicts than

2 import x

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com

On 31 Dec 2017 05:00, "Wu Xi"  wrote:

> from tkinter import *#I cant see
> anything wrong with this , it works like a charm
> from tkinter import messagebox   #is there a
> serious concern doing things his way ?
> import asyncio , threading ,  random #goal is
> multi tasking with the GUI not freezing before loop completed
>  #which is
> being achieved here !
> def _asyncio_thread(async_loop):
> async_loop.run_until_complete(do_urls())
>
> def do_work(async_loop):
> """ Button-Event-Handler starting stuff """
> threading.Thread(target=_asyncio_thread, args=(async_loop,)).start()
>
> async def one_url(url):
> """ One task. """
> sec = random.randint(1, 8)
> await asyncio.sleep(sec  )
> return 'url: {}  ---  sec: {}'.format(url, sec)
>
> async def do_urls():
> """ Creating and starting 10 tasks. """
> tasks   = [one_url(url)  for url  in range(10)]
> completed, pending =  await asyncio.wait(tasks)
> results = [task.result() for task in completed]
> print('\n'.join(results))
>
>
> def do_nofreeze():
> messagebox.showinfo(message='see, Tkinter is still responsive')
>
> def submain(async_loop):
> root = Tk()
> b1 = Button(master=root, text='do work',   command=
> lambda:do_work( async_loop)).pack()
> b2 = Button(master=root, text='Frozen?',   command=do_nofreeze
>  ).pack()
> root.mainloop()
>
>
> if __name__ == '__main__':
> async_loop = asyncio.get_event_loop()#  all in this loop
> submain(async_loop)
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter MP working like a charm

[Chris Angelico]

On Sun, Dec 31, 2017 at 8:03 PM, Abdur-Rahmaan Janhangeer
 wrote:
> @Chris
>
> hum nice point
>
> it seems to be related to namespace convenience
>
> like
>
> 1 from x import *
>
> is likelier to cause conflicts than
>
> 2 import x

This is correct. Also, when you read the code, you can instantly tell
that "x.ALL" is not the same as the built-in "all" function, but it's
less obvious if they're both just simple names. Some modules are
designed to be star-imported (tkinter being one of them), but even
there - and *definitely* for other modules - it's much clearer to use
module imports.

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

Re: tkinter MP working like a charm

[Wu Xi]

OK, I never figured out that "import *" business...


I was originally referring to the handling of multi-tasking via the 

root.mainloop()


if __name__ == '__main__':
async_loop = asyncio.get_event_loop()#  all in this loop
submain(async_loop)



business , which some found a bit outlandish.

I cannot see why, though.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: a nice editor in 100 lines

[Wu Xi]

wxjmfa...@gmail.com:
> Le dimanche 31 décembre 2017 10:33:03 UTC+1, wxjm...@gmail.com a écrit :
>> Le samedi 30 décembre 2017 23:02:41 UTC+1, Wu Xi a écrit :

> Addendum
> 
> This one is also not working.
> 
> https://www.reddit.com/r/Python/comments/7murk2/a_python_ide_made_with_tkinter_it_should_be




nice find!


works smoothly here, except running the opened file kinda not path finding...  
gotta be easy to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: a nice editor in 100 lines

[Wu Xi]

https://github.com/morten1982/crossviper

> 
> nice find!
> 
> 
> works smoothly here, except running the opened file kinda not path finding... 
>  gotta be easy to fix.
> 



take that back


in xterm mode , path is no problem. nice IDE !
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to exec a string which has an embedded '\n'?

[jfong]

Random832於 2017年12月31日星期日 UTC+8下午1時25分50秒寫道：
> On Sat, Dec 30, 2017, at 23:57, jf...@ms4.hinet.net wrote:
> > I have a multiline string, something like '''...\nf.write('\n')\n...'''
> > when pass to exec(), I got
> > SyntaxError: EOL while scanning string literal
> > 
> > How to get rid of it?
> 
> Use \\n for this case, since you want the \n to be interpreted by the exec 
> parser rather than the newline being part of the string.

Thank you, it's very helpful. This answer makes me think about '\' more 
thoughtful:-)

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

Mr. Conway in 50 lines of code

[Wu Xi]

import time , itertools
__doc__=" Mr Conway_s   Game Of Life   simulation in python 2 and 3 "

width = 55 ;  height = 55# size of life habitat , e.g. a simulated 
meteorite, bolide , etc.

vmap  = [['D' for w  in range(width)] for h in range(height)]   # D = 
Dead at first

def neighbours(point):
 x,y = point
 
 yield x + 1 , y
 yield x - 1 , y
 yield x , y + 1
 yield x , y - 1 #this is proof that life can emerge 
inside of computers and cellular automatons,
  
 yield x + 1 , y + 1 #and evolve through memory, attack 
other cells and morph into toads, pulsars, etc..
 yield x + 1 , y - 1
 yield x - 1 , y + 1 #spray your memory with space alien 
patterns and life evolution will start in your machine !
 yield x - 1 , y - 1
 
def ageing(habitat):
 newstate = set()
 recalc   = habitat | set(itertools.chain(*map(neighbours,  habitat)))
 for point in recalc:
  count = sum((neigh in habitat) for neigh in  neighbours(  point))
  if count == 3 or (count == 2 and point in   habitat):  # 
standard rule def. - a life cell having less than 2 alive neighbours will die
   newstate.add(point)
 return newstate

glider   = set([ (40,40) , (41,40) , (42,40) , (40,41) , (41,42)   ])# 
patterns of life: gliders, boats, guns, imps, toads, pulsars and so on
previous = set([ ( 0, 0) , ( 1, 0) , ( 2, 0) , ( 0, 1) , ( 1, 2)   ])# 
offset on screen / place during last step in life

for lifetime in range(300):  # 
number of simulated lifetime steps (e.g. 300 / 0.1 sleep = 30 seconds) before 
death occurs
  try:
   time.sleep( 0.1 ) # slow 
it down
   previous  = glider  ;  glider = ageing(glider)
   for  tup   in  glider   :  
 el=tup ; xx=el[0] % width; yy =el[1] % height ; 
vmap[xx][yy]='L'   # Live cell has emerged
   for  tup   in  previous :  
 el=tup ; xx=el[0] % width; yy =el[1] % height  
 if tup not   in  glider   :   vmap[xx][yy]='D' 
# Dead cell 
   # put more life patterns in this lifespan loop and let them evolutionize!
   vtxt = [''.join('*' if cell=='L' else ' ' for cell in row) for row in vmap]  
  
   print('\033[H\033[J')
# clear screen
   print('\n'.join(reversed(vtxt))) 
  except: pass
print("Simulated lifetime of the glider is over. May there live soon a new 
glider in the life habitat of your screen.") 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 23:54, Chris Angelico wrote:

On Sun, Dec 31, 2017 at 10:45 AM, bartc  wrote:

On 30/12/2017 23:26, Gregory Ewing wrote:


bartc wrote:


B and C occur twice, so a goto is a quick way to reuse B and C without
needing to duplicate code,



This only works if the repeated part happens to be at the
tail of each case.



IME that seems to be the most common situation.



I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.


The problem is having to stare at the code for even longer to figure out 
the even dirtier tricks you had to use to avoid gotos.



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

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 11:33 PM, bartc  wrote:
> On 30/12/2017 23:54, Chris Angelico wrote:
>>
>> On Sun, Dec 31, 2017 at 10:45 AM, bartc  wrote:
>>>
>>> On 30/12/2017 23:26, Gregory Ewing wrote:


 bartc wrote:
>
>
> B and C occur twice, so a goto is a quick way to reuse B and C without
> needing to duplicate code,



 This only works if the repeated part happens to be at the
 tail of each case.
>>>
>>>
>>>
>>> IME that seems to be the most common situation.
>>>
>>
>> I've written code that uses dirty tricks like that to avoid
>> duplication. It's at least as much of a problem as actual duplication
>> is. Generally, the 'goto' solution results in subsequent programmers
>> (such as my future selves) staring at the code for 30-60 seconds to
>> figure out what it's doing. I don't like to do that to myself, much
>> less to people I actually admire and respect.
>
>
> The problem is having to stare at the code for even longer to figure out the
> even dirtier tricks you had to use to avoid gotos.
>

Dirtier tricks like... named functions?

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

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 12:41, Chris Angelico wrote:

On Sun, Dec 31, 2017 at 11:33 PM, bartc  wrote:

On 30/12/2017 23:54, Chris Angelico wrote:



I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.



The problem is having to stare at the code for even longer to figure out the
even dirtier tricks you had to use to avoid gotos.



Dirtier tricks like... named functions?


I like to write clean and readable code. If I thought introducing 
functions, whether local or not, as a way of avoiding goto was worth 
doing, I would do so.


So in this case I disagree with dragging in named functions and 
introducing an extra level of control flow just to avoid duplicating 
half a dozen lines of code. I would just duplicate those lines (with a 
comment that they have to match the other set so that they are 
maintained in sync).


For other uses of goto, I've introduced (not in Python or C but my own 
stuff) features to avoid the need some of those uses.


For example, extra loop controls, and loop controls that work with 
nested loops. I've also experimented with a feature intended purely to 
get to common clean-up code, but that had little advantage over using 
goto other than not writing 'goto', and thus avoiding some of the stigma 
(but you will also know it will do a one-off forward jump to a common 
point).


(Actually, none of my code ever needs to use 'goto' anyway, as I can 
also write it as 'go to'. That's effective if anyone does a 'grep' on my 
code looking for 'goto' instances...)


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

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 31/12/2017 12:41, Chris Angelico wrote:
>> On Sun, Dec 31, 2017 at 11:33 PM, bartc  wrote:
>>> On 30/12/2017 23:54, Chris Angelico wrote:
>
 I've written code that uses dirty tricks like that to avoid
 duplication. It's at least as much of a problem as actual duplication
 is. Generally, the 'goto' solution results in subsequent programmers
 (such as my future selves) staring at the code for 30-60 seconds to
 figure out what it's doing. I don't like to do that to myself, much
 less to people I actually admire and respect.
>>>
>>> The problem is having to stare at the code for even longer to figure out the
>>> even dirtier tricks you had to use to avoid gotos.
>>
>> Dirtier tricks like... named functions?
>
> I like to write clean and readable code. If I thought introducing
> functions, whether local or not, as a way of avoiding goto was worth
> doing, I would do so.

I think there's a problem with that.  Standard C does not have them, you
said your language does not implement them properly and I think you are
new(ish) to Python.  What language did you try them in?  It may be that
it was overly complex in that language.  The idea is clean and simple.

> So in this case I disagree with dragging in named functions and
> introducing an extra level of control flow just to avoid duplicating
> half a dozen lines of code. I would just duplicate those lines (with a
> comment that they have to match the other set so that they are
> maintained in sync).

The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.


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

emacsclient does not select frame?

[Rustom Mody]

With a lot of jumping through hoops Ive managed to get firefox to
call emacs(client) and save links+description(title)+selection(in firefox; 
optional) into an org mode capture buffer.

However the call to emacsclient does not raise the frame... At least not 
consistently?

Currently my hack is to write my own shell wrapper to emacsclient doing

wmctrl -c emacs
emacsclient -c $*
wmctrl -a emacs

Is there some other thing I dont know to raise the emacs frame?

Also the -c I am forced to use because without it, if there is not an existing 
frame (emacs started in --daemon mode) it does not work


Emacs 25.1.1
Gnome-Unity
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: emacsclient does not select frame?

[Rustom Mody]

On Sunday, December 31, 2017 at 9:00:53 PM UTC+5:30, Rustom Mody wrote:
> With a lot of jumping through hoops Ive managed to get firefox to
> call emacs(client) and save links+description(title)+selection(in firefox; 
> optional) into an org mode capture buffer.
> 
> However the call to emacsclient does not raise the frame... At least not 
> consistently?
> 
> Currently my hack is to write my own shell wrapper to emacsclient doing
> 
> wmctrl -c emacs
> emacsclient -c $*
> wmctrl -a emacs
> 
> Is there some other thing I dont know to raise the emacs frame?
> 
> Also the -c I am forced to use because without it, if there is not an 
> existing 
> frame (emacs started in --daemon mode) it does not work
> 
> 
> Emacs 25.1.1
> Gnome-Unity

Oops
Wrong list
Apologies
And happy new year!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 15:02, Ben Bacarisse wrote:

bartc  writes:



I think there's a problem with that.  Standard C does not have them, you
said your language does not implement them properly


(The real problem is I don't remember local functions being used 
anywhere else. It's an idiom I'm not used to and that apparently few 
other people use. Except perhaps in Python where they do to use advanced 
features over simpler ones.)


 and I think you are

new(ish) to Python.  What language did you try them in?  It may be that
it was overly complex in that language.  The idea is clean and simple.


It's not simple to implement. Not if you want full access to the 
non-static variables of the containing function(s). It doesn't sound 
that efficient either.



So in this case I disagree with dragging in named functions and
introducing an extra level of control flow just to avoid duplicating
half a dozen lines of code. I would just duplicate those lines (with a
comment that they have to match the other set so that they are
maintained in sync).


The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.


The blocks don't need to be dragged; they are already in place!

It's funny because in c.l.c you're always advocating keep declarations 
as close to the point of use as possible. Here you appear to be saying 
the opposite: taking code away from the primary point of use.


(Which is likely to cause problems if the code includes breaks, or gotos 
if the language has them.)


I think there is a way to solve this pattern via special language 
features, while writing the main code primarily inline and in a natural 
structure, but I haven't found a satisfactory method yet. I don't think 
local functions is it.


(And perhaps a solution lies outside the language such as within an 
editor, to allow sharing of the same block of code in multiple locations.)


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

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Mon, Jan 1, 2018 at 3:55 AM, bartc  wrote:
>> The suggestion was to use them to avoid gotos.  If duplicating is a good
>> idea (and it's a hard line to draw) then we are not talking about the
>> same cases.  Given the choice of "dragging in named functions" and
>> dragging in named blocks and gotos, I would choose the functions every
>> time.
>
>
> The blocks don't need to be dragged; they are already in place!
>
> It's funny because in c.l.c you're always advocating keep declarations as
> close to the point of use as possible. Here you appear to be saying the
> opposite: taking code away from the primary point of use.

I don't understand the issue here. All you need to do is add a "def"
statement header in front of the block of code. And maybe indent it
further, although if you're unifying "if/elif" subtrees, that'll
cancel out the indentation level change. The block of code stays at or
near its first use.

Once again, Bart, you're scorning something that you don't have much
(any?) experience with. Look at how the feature is used before you
hate on it.

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

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Sunday, December 31, 2017 at 3:02:41 PM UTC, Ben Bacarisse wrote:
> bartc  writes:
> 
> > On 31/12/2017 12:41, Chris Angelico wrote:
> >> On Sun, Dec 31, 2017 at 11:33 PM, bartc  wrote:
> >>> On 30/12/2017 23:54, Chris Angelico wrote:
> >
>  I've written code that uses dirty tricks like that to avoid
>  duplication. It's at least as much of a problem as actual duplication
>  is. Generally, the 'goto' solution results in subsequent programmers
>  (such as my future selves) staring at the code for 30-60 seconds to
>  figure out what it's doing. I don't like to do that to myself, much
>  less to people I actually admire and respect.
> >>>
> >>> The problem is having to stare at the code for even longer to figure out 
> >>> the
> >>> even dirtier tricks you had to use to avoid gotos.
> >>
> >> Dirtier tricks like... named functions?
> >
> > I like to write clean and readable code. If I thought introducing
> > functions, whether local or not, as a way of avoiding goto was worth
> > doing, I would do so.
> 
> I think there's a problem with that.  Standard C does not have them, you
> said your language does not implement them properly and I think you are
> new(ish) to Python.  What language did you try them in?  It may be that
> it was overly complex in that language.  The idea is clean and simple.
> 
> > So in this case I disagree with dragging in named functions and
> > introducing an extra level of control flow just to avoid duplicating
> > half a dozen lines of code. I would just duplicate those lines (with a
> > comment that they have to match the other set so that they are
> > maintained in sync).
> 
> The suggestion was to use them to avoid gotos.  If duplicating is a good
> idea (and it's a hard line to draw) then we are not talking about the
> same cases.  Given the choice of "dragging in named functions" and
> dragging in named blocks and gotos, I would choose the functions every
> time.
> 
> 
> -- 
> Ben.

I would use functions every time as a modern compiler can inline them, 
something described here https://en.wikipedia.org/wiki/Inline_expansion for the 
benefit of newbies.  Further I've never once in 17 years of using Python been 
tearing my hair out over the lack of goto as there are numerous examples of how 
to avoid them.  This thread is yet another storm in a thimble.

--
Kindest regards.

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

Copy-on-write friendly Python garbage collection

[breamoreboy]

An interesting write up on something that is incorporated into Python 3.7 
https://engineering.instagram.com/copy-on-write-friendly-python-garbage-collection-ad6ed5233ddf

--
Kindest regards.

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

Re: Copy-on-write friendly Python garbage collection

[Wu Xi]

breamore...@gmail.com:
> An interesting write up on something that is incorporated into Python 3.7 
> https://engineering.instagram.com/copy-on-write-friendly-python-garbage-collection-ad6ed5233ddf

kewl

py 3.7 does not fully make install here, but it built and works, as far as I 
can tell
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Copy-on-write friendly Python garbage collection

[Wu Xi]

they said they run the largest deployment of Django world-wide.

be it as it may...

many still consider the web guys to be the "funny people".

Why did they not switch over to Erlang ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 17:06, Chris Angelico wrote:

On Mon, Jan 1, 2018 at 3:55 AM, bartc  wrote:

The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.



The blocks don't need to be dragged; they are already in place!

It's funny because in c.l.c you're always advocating keep declarations as
close to the point of use as possible. Here you appear to be saying the
opposite: taking code away from the primary point of use.


I don't understand the issue here. All you need to do is add a "def"
statement header in front of the block of code. And maybe indent it
further, although if you're unifying "if/elif" subtrees, that'll
cancel out the indentation level change. The block of code stays at or
near its first use.


You'll need to give an example I think. Suppose I start with this:

def fn(a):
if a==1:
print ("One")
print ("Two")
print ("Three")
elif a==2:
print ("Four")
else:
print ("Other")
print ("One")
print ("Two")
print ("Three")

I want to share the lines that print One Two Three, so I create an 
inline function, defined as close as possible to the original code:


def fn2(a):
if a==1:
def F123():
print ("One")
print ("Two")
print ("Three")
F123()
elif a==2:
print ("Four")
else:
print ("Other")
F123()

However, if I call this with fn2(3), it says that variable F123 has not 
been assigned.


(I'm not sure what overheads are associated with nested functions. 
Presumably its byte-code is done once, but is there any other setup of 
F123 associated with each call of fn2()? Even when a==2 so that F123() 
is not called?


A brief test [not using print()] showed it was a little slower having 
F123 inside fn2() - and outside the if-statement to make it work - than 
having F123 outside. And having to call F123() anyway instead of just 
having the inline code makes it a little slower too.


Although this would need to be balanced by the cost of the alternative, 
whether a goto or whatever.)


Note also that a goto, and a function call, don't do the same thing. The 
function will return, the goto won't. In my example all paths will 
return, in others this will have to be taken care of.


--
bartc












 Don't forget that after turning a block into a def-function in-place, 
it will need to be followed by a call to it:


  if X:
 A
 B
 C
  elif ...
  else:
 A
 B
 C

This becomes:

   if X:
  def F():
 A
 B
 C
  F()
   elif...
   else
  F()

(Is the def statement executed once during byte-code compilation? Or can 
it give different result each time depending on what globals are visible 
within F? Will there at least be a set-up overhead for F each time



Note that calling a local function is not quite a drop-in replacement for



Once again, Bart, you're scorning something that you don't have much
(any?) experience with. Look at how the feature is used before you
hate on it.

ChrisA



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

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 19:29, bartc wrote:

[Ignore the original, incomplete version of my post, which appears after 
the sig.


I decided to actually try it out for real instead of just guessing!

Good thing too.]
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Mon, Jan 1, 2018 at 6:29 AM, bartc  wrote:
> You'll need to give an example I think. Suppose I start with this:
>
> def fn(a):
> if a==1:
> print ("One")
> print ("Two")
> print ("Three")
> elif a==2:
> print ("Four")
> else:
> print ("Other")
> print ("One")
> print ("Two")
> print ("Three")
>
> I want to share the lines that print One Two Three, so I create an inline
> function, defined as close as possible to the original code:
>
> def fn2(a):
> if a==1:
> def F123():
> print ("One")
> print ("Two")
> print ("Three")
> F123()
> elif a==2:
> print ("Four")
> else:
> print ("Other")
> F123()
>
> However, if I call this with fn2(3), it says that variable F123 has not been
> assigned.

Right, so you'd move it one line up (or move the 'if' down to below
the function definition), thus the larger block of code stays where it
is.

> Note also that a goto, and a function call, don't do the same thing. The
> function will return, the goto won't.

Not sure what you mean by "return", because what you effectively do is
create a name for a block of code, and then use (call) that block of
code more than once. That makes it easy to comprehend. With the goto,
you have to go look at the body below to figure out what happens.

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

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 31/12/2017 15:02, Ben Bacarisse wrote:
>> bartc  writes:
>
>> I think there's a problem with that.  Standard C does not have them, you
>> said your language does not implement them properly
>
> (The real problem is I don't remember local functions being used
> anywhere else. It's an idiom I'm not used to and that apparently few
> other people use. Except perhaps in Python where they do to use
> advanced features over simpler ones.)
>
>  and I think you are
>> new(ish) to Python.  What language did you try them in?  It may be that
>> it was overly complex in that language.  The idea is clean and simple.
>
> It's not simple to implement. Not if you want full access to the
> non-static variables of the containing function(s). It doesn't sound
> that efficient either.

No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.

>>> So in this case I disagree with dragging in named functions and
>>> introducing an extra level of control flow just to avoid duplicating
>>> half a dozen lines of code. I would just duplicate those lines (with a
>>> comment that they have to match the other set so that they are
>>> maintained in sync).
>>
>> The suggestion was to use them to avoid gotos.  If duplicating is a good
>> idea (and it's a hard line to draw) then we are not talking about the
>> same cases.  Given the choice of "dragging in named functions" and
>> dragging in named blocks and gotos, I would choose the functions every
>> time.
>
> The blocks don't need to be dragged; they are already in place!
>
> It's funny because in c.l.c you're always advocating keep declarations
> as close to the point of use as possible. Here you appear to be saying
> the opposite: taking code away from the primary point of use.

If a language allowed me to declare a local function at the point of
first use, I'd do that, but there are special reasons why that is not a
reasonable thing to do in most cases.  None the less, it's not
inconsistent to prefer one less than perfect option to another much less
than perfect option.

However, we're debating an entirely abstract notion.  What is a typical
use for this "re-use" goto idiom?  Maybe I'll prefer the goto version
over any of the alternatives when I see an actual use.

> (Which is likely to cause problems if the code includes breaks, or
> gotos if the language has them.)

Good grief!  That is exactly the sort of code you should not re-use by
jumping to it.  There are myriad potential problems and putting the code
into a function will allow the compiler to diagnose lots of them.

If you really are jumping to re-use code that includes gotos I suggest
the whole thing needs re-design.

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

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 22:09, Ben Bacarisse wrote:


No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.


What makes you think I had a bad experience? I posted a version using 
Python a few hours ago (which needs the local function to be moved to 
work properly).


The same example works in my language (one of them anyway), but I still 
find a quick goto the simplest thing to do especially when the code is 
not complete so I don't know what will be added or changed or moved, 
which will be harder as soon a specific sequence is extracted into a 
function.


Also, what would be the duplicated code is seen to 'belong' to one of 
the options, rather than be anonymous.


(Here is the same example in my static language: 
https://pastebin.com/raw/dX2FNK7a


fn1 uses goto. fn2 uses a local function (not very demanding here so it 
works). fn3 uses the special 'block-call' feature which I no longer use 
(but I haven't yet got rid of it).


I prefer fn1 and fn3 because the code stays inline. If I had some 
inspiration for a better feature then I'd have fn4 and maybe fn5 too.)


Within Python, I touched on performance issues in my earlier post. (A 
local function apparently involves an extra assignment - per function - 
each time the containing function is called.)



(Which is likely to cause problems if the code includes breaks, or
gotos if the language has them.)


Good grief!  That is exactly the sort of code you should not re-use by
jumping to it.  There are myriad potential problems and putting the code
into a function will allow the compiler to diagnose lots of them.


OK, forget the gotos then. But a block can still contain break or return 
(and in my syntax, several other loop controls). It loses context as 
soon as it's hoisted into a function.


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

Re: tkinter MP working like a charm (Posting On Python-List Prohibited)

[Wu Xi]

Lawrence D’Oliveiro:
> On Sunday, December 31, 2017 at 10:23:32 PM UTC+13, Wu Xi wrote:
>>
>> I was originally referring to the handling of multi-tasking... which
>> some found a bit outlandish.
>>
>> I cannot see why, though.
> 
> I just can’t help thinking that you are using two threads to handle what can 
> be done with one.
> 


my question is:  is the event loop business done OK in the sample programme ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python: asyncio and Tkinter (Posting On Python-List Prohibited)

[Wu Xi]

Lawrence D’Oliveiro:
> On Sunday, December 31, 2017 at 12:47:21 PM UTC+13, Wu Xi wrote:
>> this is kinda interesting. seems there is no easy way though
> 
> If I could do it for GTK/GLib , I don’t see 
> why Tk should be hard. ;)


well, hard or no, but glibcoro is a no workie here.  2-3 chaos, as intended by 
Guido.

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

Re: Goto (Posting On Python-List Prohibited)

[MRAB]

On 2017-12-31 23:21, bartc wrote:

On 31/12/2017 22:09, Ben Bacarisse wrote:


No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.


What makes you think I had a bad experience? I posted a version using
Python a few hours ago (which needs the local function to be moved to
work properly).

The same example works in my language (one of them anyway), but I still
find a quick goto the simplest thing to do especially when the code is
not complete so I don't know what will be added or changed or moved,
which will be harder as soon a specific sequence is extracted into a
function.

Also, what would be the duplicated code is seen to 'belong' to one of
the options, rather than be anonymous.

(Here is the same example in my static language:
https://pastebin.com/raw/dX2FNK7a

fn1 uses goto. fn2 uses a local function (not very demanding here so it
works). fn3 uses the special 'block-call' feature which I no longer use
(but I haven't yet got rid of it).

I prefer fn1 and fn3 because the code stays inline. If I had some
inspiration for a better feature then I'd have fn4 and maybe fn5 too.)


The compiler could inline automatically, or you could be explicit:

proc fn2(int a)=
inline proc f123=
println "One"
println "Two"
println "Three"
end

case a
when 1 then
f123()

when 2 then
println "Four"

else
println "Other"
f123()
esac
end

(or possibly "inline f123=").

[snip]

OT: if "case ... esac" and "if ... fi", why not "proc ... corp"? :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 31/12/2017 22:09, Ben Bacarisse wrote:
>
>> No, you missed the point and did not address the question.  You said (now
>> cut)
>>
>> | If I thought introducing functions, whether local or not, as a way of
>> | avoiding goto was worth doing, I would do so.
>>
>> but I'm not sure you know if it's worth it or not.  So here's my
>> question again: what language (or languages) were you using when you
>> concluded that it was not worth using local functions to avoid gotos?
>> Maybe you had a bad experience from some language that did it badly.
>
> What makes you think I had a bad experience?

Nothing.  I was asking what experience you had that led to your
conclusion.  Knowing the language might explain the conclusion you came
to.

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

you shortened it, but you broke it too... ;-)

[Wu Xi]

import time , itertools
__doc__=" Mr Conway_s   Game Of Life   simulation in python 2 and 3 "

width = 100 ;  height = 50# size of life habitat , e.g. a simulated 
meteorite, bolide , etc.

vmap  = [['D' for w  in range(width)] for h in range(height)]   # D = 
Dead at first

def neighbours(point):
 x,y = point
  
 yield x + 1 , y
 yield x - 1 , y
 yield x , y + 1
 yield x , y - 1 #this is proof that life can emerge 
inside of computers and cellular automatons,
  
 yield x + 1 , y + 1 #and evolve through memory, attack 
other cells and morph into toads, pulsars, etc..
 yield x + 1 , y - 1
 yield x - 1 , y + 1 #spray your memory with space alien 
patterns and life evolution will start in your machine !
 yield x - 1 , y - 1
 
 '''
 for i in range(-1, 2) :
for j in range(-1, 2) :
if i != j :
yield x + i, y + j

 '''
 # yield from [(x+i, x+j) for i in [-1,1] for j in [-1,1]]
 
 
 
 
 
 
def ageing(habitat):
 newstate = set()
 recalc   = habitat | set(itertools.chain(*map(neighbours,  habitat)))
 for point in recalc:
  count = sum((neigh in habitat) for neigh in  neighbours(  point))
  if count == 3 or (count == 2 and point in   habitat):  # 
standard rule def. - a life cell having less than 2 alive neighbours will die
   newstate.add(point)
 return newstate

glider   = set([ (40,40) , (41,40) , (42,40) , (40,41) , (41,42)   ])# 
patterns of life: gliders, boats, guns, imps, toads, pulsars and so on
previous = set([ ( 0, 0) , ( 1, 0) , ( 2, 0) , ( 0, 1) , ( 1, 2)   ])# 
offset on screen / place during last step in life

for lifetime in range(300):  # 
number of simulated lifetime steps (e.g. 300 / 0.1 sleep = 30 seconds) before 
death occurs
  try:
   time.sleep( 0.1 ) # slow 
it down
   previous  = glider  ;  glider = ageing(glider)
   for  tup   in  glider   :  
 el=tup ; xx=el[0] % width; yy =el[1] % height ; 
vmap[xx][yy]='L'   # Live cell has emerged
   for  tup   in  previous :  
 el=tup ; xx=el[0] % width; yy =el[1] % height  
 if tup not   in  glider   :   vmap[xx][yy]='D' 
# Dead cell 
   # put more life patterns in this lifespan loop and let them evolutionize!
   vtxt = [''.join('*' if cell=='L' else ' ' for cell in row) for row in vmap]  
  
   print('\033[H\033[J')
# clear screen
   print('\n'.join(reversed(vtxt))) 
  except: pass
print("Simulated lifetime of the glider is over. May there live soon a new 
glider in the life habitat of your screen.") 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to exec a string which has an embedded '\n'? (Posting On Python-List Prohibited)

[jfong]

Lawrence D’Oliveiro於 2018年1月1日星期一 UTC+8上午7時56分02秒寫道：
> On Sunday, December 31, 2017 at 11:04:19 PM UTC+13, jf...@ms4.hinet.net wrote:
> >
> > This answer makes me think about '\' more thoughtful:-)
> 
> Python generating HTML containing JavaScript which generates HTML:
> 
> out.write \
>   (
> "\nfunction %(paramname)s_UpdateProjects()\n"
> # /* refreshes the project list to show enabled and/or disabled 
> projects as appropriate. */
> "  {\n"
> "var IncludeEnabled = document.forms[\"%(formname)s\"]."
> "elements[\"%(paramname)s_show_enabled\"].checked\n"
> "var IncludeDisabled = document.forms[\"%(formname)s\"]."
> "elements[\"%(paramname)s_show_disabled\"].checked\n"
> "var TheList = \"\"\n"
> "for (var i = 0; i < %(paramname)s_ProjectList.length; ++i)\n"
> "  {\n"
> "var ThisProject = %(paramname)s_ProjectList[i]\n"
> "if (ThisProject.enabled ? IncludeEnabled : 
> IncludeDisabled)\n"
> "  {\n"
> "TheList += \" " \"\\\"\" + (ThisProject.selected ? \" SELECTED\" : \"\") + 
> \">\" +"
> " ThisProject.name + \"\\n\"\n"
> "  } /*if*/\n"
> "  } /*for*/\n"
> "DocumentElt(\"%(formname)s_%(paramname)s_list\").innerHTML 
> =\n"
> "\" SIZE=\\\"5\\\"\"%(on_selection_changed)s"
> " + \">\\n\" + TheList + \"\\n\"\n"
> "  } /*%(paramname)s_UpdateProjects*/\n"
> %
> {
> "formname" : FormName,
> "paramname" : ParamName,
> "on_selection_changed" : OnSelectionChanged,
> }
>   )

I don't even dare to read through this code:-( 

How to run it?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter MP working like a charm

[Terry Reedy]

On 12/30/2017 7:57 PM, Wu Xi wrote:

from tkinter import *#I cant see 
anything wrong with this , it works like a charm


This imports about 200 names.  A reader may not know which names are 
builtins and which are imports.  There may also be accidental name 
conflicts.



from tkinter import messagebox   #is there a 
serious concern doing things his way ?


This is the normal way to import tkinter subpackages.


import asyncio , threading ,  random #goal is multi 
tasking with the GUI not freezing before loop completed
 #which is being 
achieved here !


I verified that this works in 3.7.0a3 as I believe you intend.  So it is 
possible to create and run a tk loop in the main thread and run async 
loop (created in the main thread) in a subthread.  I don't think anyone 
knows when this will and will not work.


What you show below is that asyncio.sleep and asyncio.wait work under 
this circumstance.  Actually fetching even one url and making it 
readable from the main thread, so it can be displayed in a tk Text 
widget, would be even more impressive, and useful.



def _asyncio_thread(async_loop):
 async_loop.run_until_complete(do_urls())

def do_work(async_loop):
 """ Button-Event-Handler starting stuff """
 threading.Thread(target=_asyncio_thread, args=(async_loop,)).start()

async def one_url(url):
 """ One task. """
 sec = random.randint(1, 8)
 await asyncio.sleep(sec  )
 return 'url: {}  ---  sec: {}'.format(url, sec)

async def do_urls():
 """ Creating and starting 10 tasks. """
 tasks   = [one_url(url)  for url  in range(10)]
 completed, pending =  await asyncio.wait(tasks)
 results = [task.result() for task in completed]
 print('\n'.join(results))

def do_nofreeze():
 messagebox.showinfo(message='see, Tkinter is still responsive')

def submain(async_loop):
 root = Tk()
 b1 = Button(master=root, text='do work',   command= lambda:do_work( 
async_loop)).pack()
 b2 = Button(master=root, text='Frozen?',   command=do_nofreeze 
).pack()


.pack() returns None, and binding None to b1 and b2 is useless.  Either 
skip the assignment or call .pack after the assignment.


Button(master=root, text='do work',
   command= lambda:do_work( async_loop)).pack()

b1 = Button(master=root, text='do work',
command= lambda:do_work( async_loop))
b1.pack()

Since b1 and b2 here are local variables not accessible output submain, 
do the former.  If submain were a method, 'self.b1 = Button...' would 
make it easy to access the button from elsewhere, as for testing.  (It 
is also possible to introspect root for its contents.)



 root.mainloop()

if __name__ == '__main__':
 async_loop = asyncio.get_event_loop()#  all in this loop
 submain(async_loop)


To do everything in the main thread, one can replace 'root.mainloop' 
with loop.run_forever (in the main thread) and repeated root.update calls.


--
Terry Jan Reedy

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

OK, now one main block only , but loop.run_forever() ? idk...

[Wu Xi]

from tkinter import *#I cant see 
anything wrong with the async_loop business here. It works like a charm.
from tkinter import messagebox   #is there a 
serious concern doing things his way ? 
import asyncio , threading ,  random #goal is multi 
tasking with the GUI not freezing before loop completed
 #which is being 
achieved here !works in py 3.7 of 2018
def _asyncio_thread(async_loop):
async_loop.run_until_complete(do_urls())

def do_work(async_loop):
""" Button-Event-Handler starting stuff """
threading.Thread(target=_asyncio_thread, args=(async_loop,)).start()

async def one_url(url):
""" One task. """
global root
sec = random.randint(1, 8)
root.update() # more often   
await asyncio.sleep(sec  )
return 'url: {}  ---  sec: {}'.format(url, sec)

async def do_urls():
""" Creating and starting 10 tasks. """
tasks   = [one_url(url)  for url  in range(10)]
completed, pending =  await asyncio.wait(tasks)
results = [task.result() for task in completed]
print('\n'.join(results))

def do_notfreeze():  messagebox.showinfo(message='see, Tkinter is still 
responsive')



if __name__ == '__main__':
global root
async_loop = asyncio.get_event_loop()#  all in this loop
 
root = Tk()
Button(master=root, text='do work',   command= lambda:do_work( 
async_loop )).pack()
Button(master=root, text='Frozen?',   command= do_notfreeze 
   ).pack()
root.update()   
#async_loop.run_forever() #  <  uncomment, then it won"t 
work anymore
root.mainloop() # how to replace ? 
   

  # To do everything in the main thread, 
  # one can replace 'root.mainloop' with loop.run_forever (in the main thread) 
  # and repeated root.update calls.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[mm0fmf]

On 31/12/2017 17:01, breamore...@gmail.com wrote:

I would use functions every time as a modern compiler can inline them


This


Further I've never once in 17 years of using Python been tearing my hair out 
over the lack of goto


And this. (In my case only 6 years.)


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

Re: Copy-on-write friendly Python garbage collection

[Wu Xi]

breamore...@gmail.com:
> An interesting write up on something that is incorporated into Python 3.7 
> https://engineering.instagram.com/copy-on-write-friendly-python-garbage-collection-ad6ed5233ddf

Appearantly, Erlang is the way to go, when it comes to web frameworks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 17:01, breamore...@gmail.com wrote:


Further I've never once in 17 years of using Python been tearing my hair out 
over the lack of goto


Neither have I over all the advanced features of Python I never use, and 
for double that number of years.


Yet for some they will be as indispensable as they are incomprehensible 
to others.


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

Re: Mr. Conway in 50 lines of code (Posting On Python-List Prohibited)

[Lawrence D’Oliveiro]

On Sunday, December 31, 2017 at 11:13:41 PM UTC+13, Wu Xi wrote:
>  yield x + 1 , y
>  yield x - 1 , y
>  yield x , y + 1
>  yield x , y - 1 #this is proof that life can emerge 
> inside of computers and cellular automatons,
>   
>  yield x + 1 , y + 1 #and evolve through memory, attack 
> other cells and morph into toads, pulsars, etc..
>  yield x + 1 , y - 1
>  yield x - 1 , y + 1 #spray your memory with space alien 
> patterns and life evolution will start in your machine !
>  yield x - 1 , y - 1

for i in range(-1, 2) :
for j in range(-1, 2) :
if i != j :
yield x + i, y + j
#end if
#end for
#end for

which is half the number of lines of code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter MP working like a charm

[Terry Reedy]

On 12/31/2017 8:52 PM, Terry Reedy wrote:

To do everything in the main thread, one can replace 'root.mainloop' 
with loop.run_forever (in the main thread) and repeated root.update calls.


Wu Xi's example, rewritten more or less as suggested:

from tkinter import *
from tkinter import messagebox
import asyncio
import random

async def one_url(url):
""" One task. """
sec = random.randint(1, 8)
await asyncio.sleep(sec  )
return 'url: {}  ---  sec: {}'.format(url, sec)

async def do_urls():
""" Creating and starting 10 tasks. """
tasks   = [one_url(url)  for url  in range(10)]
completed, pending =  await asyncio.wait(tasks)
results = [task.result() for task in completed]
print('\n'.join(results))


def do_nofreeze():
messagebox.showinfo(message='see, Tkinter is still responsive')

def widgets(master):
Button(master, text='Frozen?', command=do_nofreeze).pack()

# A production version of this should make it possible to cancel.
# However, when loop stops, updates will stop.
def tk_update(interval):
root.update()
loop.call_later(interval, tk_update)

if __name__ == '__main__':
root = Tk()
widgets(root)
loop = asyncio.get_event_loop()
tk_update(.01)
loop.run_until_complete(do_urls())



--
Terry Jan Reedy

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

Scientific Python moving to Python 3 only.

[Terry Reedy]

https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst

Numpy people currently plan to stop adding features to their 2.7 branch 
after Dec 31, 2018 and stop adding bug fixes to the last version 
supporting 2.7 a year later, Dec 31, 2019.  It will remain available for 
pip installation, and possible support by other (most likely commercial) 
parties.


http://www.python3statement.org/
About 30 other projects, including other part of the python-science 
stack, have 'pledged' to so something similar.


--
Terry Jan Reedy

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

Re: tkinter MP working like a charm

[Abdur-Rahmaan Janhangeer]

it seems that the original poster's mail went missing

leugenpresse means lying press btw

weird

i doubt the author wanted to prank us by announcing i did this and that.

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com

On 31 Dec 2017 5:00 am, "Wu Xi"  wrote:

> from tkinter import *#I cant see
> anything wrong with this , it works like a charm
> from tkinter import messagebox   #is there a
> serious concern doing things his way ?
> import asyncio , threading ,  random #goal is
> multi tasking with the GUI not freezing before loop completed
>  #which is
> being achieved here !
> def _asyncio_thread(async_loop):
> async_loop.run_until_complete(do_urls())
>
> def do_work(async_loop):
> """ Button-Event-Handler starting stuff """
> threading.Thread(target=_asyncio_thread, args=(async_loop,)).start()
>
> async def one_url(url):
> """ One task. """
> sec = random.randint(1, 8)
> await asyncio.sleep(sec  )
> return 'url: {}  ---  sec: {}'.format(url, sec)
>
> async def do_urls():
> """ Creating and starting 10 tasks. """
> tasks   = [one_url(url)  for url  in range(10)]
> completed, pending =  await asyncio.wait(tasks)
> results = [task.result() for task in completed]
> print('\n'.join(results))
>
>
> def do_nofreeze():
> messagebox.showinfo(message='see, Tkinter is still responsive')
>
> def submain(async_loop):
> root = Tk()
> b1 = Button(master=root, text='do work',   command=
> lambda:do_work( async_loop)).pack()
> b2 = Button(master=root, text='Frozen?',   command=do_nofreeze
>  ).pack()
> root.mainloop()
>
>
> if __name__ == '__main__':
> async_loop = asyncio.get_event_loop()#  all in this loop
> submain(async_loop)
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list