Re: lxml and xpath(?)

[Pete Forman]

Peter Otten <__pete...@web.de> writes:

> root = etree.fromstring(s)
> for server in root.xpath("./server"):
> servername = server.xpath("./name/text()")[0]

When working with lxml I prefer to use this Python idiom.

servername, = server.xpath("./name/text()")

That enforces a single result. The original code will detect a lack of
results but if the query returns multiple results when only one is
expected then it silently returns the first.

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

Re: Why doesn't Python include non-blocking keyboard input function?

[Terry Reedy]

On 10/27/2016 1:49 AM, Marko Rauhamaa wrote:

Terry Reedy :


On 10/26/2016 8:33 AM, Marko Rauhamaa wrote:

Maybe there should be some way to get the raw events from the PTY.


PTY?  Must be Linux-specific.  Most beginners are not on Linux.


A PTY is an emulated console (https://en.wikipedia.org/wiki/Pseudoterminal>). I don't know Windows but
I would guess cmd.exe does something similar there.

Also, I have no statistics on most beginning programmers operating
systems.


But what would be wrong in a GUI PTY API? No windowing,


'No windowing'? Python normally runs in a text widget in a window,
programmed to emulate a dumb terminal.


Must be Windows-specific.


Not as I meant the above.

When I used unix in the 1980s, the full screen ran csh until one started 
another full screen application.  MSDOS was the same. Every contemporary 
photo of modern Linux or Mac I have seen has a desktop with windows just 
like Windows.  Do people on Linux still commonly use full-screen, no 
window text editors like the one I had?  On Windows, there are full 
screen games, but I have never seen a full-screen, no-window text 
application.


Since modern screen are pixel graphics screens, rather than character 
screens, there must be a widget, whether standard with the OS or custom 
to the console, that emulates the old fixed-pitch character screens.  At 
least on Windows, C Programs that run with the console still get 
characters entered by users and send characters to be displayed.


--
Terry Jan Reedy

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

Re: lxml and xpath(?)

[Peter Otten]

Pete Forman wrote:

> Peter Otten <__pete...@web.de> writes:
> 
>> root = etree.fromstring(s)
>> for server in root.xpath("./server"):
>> servername = server.xpath("./name/text()")[0]
> 
> When working with lxml I prefer to use this Python idiom.
> 
> servername, = server.xpath("./name/text()")
> 
> That enforces a single result. The original code will detect a lack of
> results but if the query returns multiple results when only one is
> expected then it silently returns the first.

Good suggestion, and for those who find the trailing comma easy to overlook: 

 [servername] = server.xpath("./name/text()")


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

Re: Why doesn't Python include non-blocking keyboard input function?

[D'Arcy Cain]

On 2016-10-27 03:05 AM, Terry Reedy wrote:

When I used unix in the 1980s, the full screen ran csh until one started
another full screen application.  MSDOS was the same. Every contemporary
photo of modern Linux or Mac I have seen has a desktop with windows just
like Windows.  Do people on Linux still commonly use full-screen, no
window text editors like the one I had?  On Windows, there are full
screen games, but I have never seen a full-screen, no-window text
application.


You must lead a sheltered life then.


Since modern screen are pixel graphics screens, rather than character


Not always.  I have many Unix systems that don't run X.  A GUI is not 
essential to running a useful Unix server.


You may be correct that Linux systems tend to run GUIs but even then it 
isn't mandatory.


--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
--
https://mail.python.org/mailman/listinfo/python-list

Re: Reversing \N{...} notation?

[Serhiy Storchaka]

On 26.10.16 23:47, Peter Otten wrote:

def mynamereplace(exc):
return u"".join(
"\\N{%s}" % unicodedata.name(c)
for c in exc.object[exc.start:exc.end]
), exc.end
codecs.register_error("namereplace", mynamereplace)


Not all characters has standard name. This fails with say '\x80'. Use 
backslash escaping as a fallback:


try:
ascii
except NameError:
ascii = repr
def mynamereplace(exc):
repl = []
for c in exc.object[exc.start:exc.end]:
try:
repl.append("\\N{%s}" % unicodedata.name(c))
except ValueError:
repl.append(ascii(c)[1:-1])
return u"".join(repl), exc.end


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

Re: Iteration, while loop, and for loop

[Veek M]

Elizabeth Weiss wrote:

> words=["hello", "world", "spam", "eggs"]
> counter=0
> max_index=len(words)-1
> 
> while counter<=max_index:
> word=words[counter]
> print(word + "!")
> counter=counter + 1


while 0 < 10:
  get 0'th element
  do something with element
  increment 0 to 1
(repeat)


words[0] gets the 0'th word (arrays/lists start at 0, not 1)


That example of his is badly presented..

1. use i, x, y, z, count in that order for integers
2. do your dirty work in a function
3. keep loops clean and tidy
4. keep data far away from code
5. avoid " when ' does the trick
6. try to create black box functions - that work no matter what you 
throw at them.. without sacrificing readability - programming is about 
aesthetics and readability - quite artsy..

(I'm not an expert so.. some of this might be outright wrong)

words=['hello', 'world', 'spam', 'eggs']

def display(txt, decoration='!'):
  message = str(txt) + str(decoration)
  print(message)

i = 0
i_max = len(words) - 1

while i <= i_max:
  word = words[i]
  i += 1
  display(word)

languages that don't have 'for' like C, will use 'while' - in python 
'for' is preferred - faster, readable - especially for the example you 
cited.

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

AsyncSSH and timeout

[mantaselprj]

Good day,
I'm trying to run multiple SSH clients using AsyncSSH lib. This is an example 
from manual, which works fine:
http://pastebin.com/zh4zymeQ

The problem is, it is not possible to directly set connect timeout in 
run_client() function. However, the manual says: 
"asyncio calls can be wrapped in a call to asyncio.wait_for() or asyncio.wait() 
which takes a timeout and provides equivalent functionality."

So I tried to modify run_client() like this:
http://pastebin.com/mH7pBuuf

But it spits out a syntax error. I also tried countless variations of it, but 
still no luck. Could someone more knowledgeable help me to set the damn timeout?
-- 
https://mail.python.org/mailman/listinfo/python-list

AsyncSSH and timeout

[Standard User]

Good day,
I'm trying to run multiple SSH clients using AsyncSSH lib. This is an example 
from manual, which works fine: http://pastebin.com/zh4zymeQ

The problem is, it is not possible to directly set connect timeout in 
run_client() function. However, the manual says:
"asyncio calls can be wrapped in a call to asyncio.wait_for() or asyncio.wait() 
which takes a timeout and provides equivalent functionality."

So I tried to modify run_client() like this: http://pastebin.com/mH7pBuuf
But it spits out a syntax error. I also tried countless variations of it, but 
still no luck. Could someone more knowledgeable help me to set the damn timeout?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why doesn't Python include non-blocking keyboard input function?

[Terry Reedy]

On 10/26/2016 9:12 PM, BartC wrote:

On 27/10/2016 00:30, Terry Reedy wrote:



Bart, you appear to have been fortunate enough to be spoiled by learning
programming on microcomputers, where the terminal and computer are
combined into one unit, so that the computer, and potentially the
programmer, have access to user input actions.


Actually, I first used machines such as pdp10 and pdp11. Those mostly
used serial terminals, a mystery to me, and they still are. It seems
Unix is keen to propagate the mystery.


OK, you got spoiled later ;-).  I share your frustration a bit.


However, Python was not
developed on, and in not limited to use on, such machines.  Today,
ethernet-connected *nix servers have no keyboard, mouse, or even a
directly connected terminal.


So how does your tkinter example work in such a server?


Without X-windows available, there would be no point, and it will not 
work.  I presume including the X window subsystem on a linux (server) 
build is optional.  Last I knew, all of the linux machines with a 
CPython buildbot either do not have X or prohibit the buildbot from 
using it.


Compiling _tkinter.c is optional and many (most?) Linux distributions 
put tkinter.py, idlelib/*.py, and turtle.py in a separate package.  If a 
buildbot tries to run gui tests on linux machines without X available, 
an exception is raised, something like 'Failed to connect to the X 
subsystem'.  (It has been 3 years since I cause one of those.)


If the server includes X and tkinter and one connects (likely as admin) 
with a X-terminal or emulator, I expect that tk and tkinter should work. 
 Whether X will let an invisible window keep keyboard focus, I will not 
know until someone tries it.  Perhaps 99+% of Tcl/tk works the same 
across platforms.



As I don't
understand the argument that a language shouldn't have a basic keyboard
API because some computers it could run on might not have a keyboards.


As I and others have said, those keyboard functions are not available on 
text terminals.  I predict that keyboard functions that so not work on 
all systems will never become built-ins.  But some are available with an 
import.


Python optionally comes with a sophisticated keyboard api.  The PSF 
(python.org) CPython builds for Windows and Mac include that API.  On 
Windows, so is the required tcl/tk build.  The premise of the subject 
line, that Python does not include 'non-blocking keyboard input 
functions', is not true.


Some things *can* be simplified.  I gave one example previously.  While 
writing this, I realized that with a little work, I could automate all 
the bindings for IDLE menu item event handlers.



(I've looked at X Windows; bloody hell, it makes Win32/GDI look like
child's play.)


This may have helped persuade three different language groups to 
piggyback on the work of tcl folk.  Keeping up with Apple's series of 
graphics systems has also been a hassle.


--
Terry Jan Reedy

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

Re: How to use two threads (GUI and backend)

[pozz]

Il 26/10/2016 16:18, jmp ha scritto:

On 10/26/2016 02:45 PM, pozz wrote:

Il 26/10/2016 13:16, jmp ha scritto:

[...]
I suggest you write a GUI that make synchronouscalls to a remote
application, if possible. If the remote app is in python, you have
access to remote protocols already written for you, Pyro is one of them,
you can skip the low level communication part.


I'm not sure Pyro (or similar alternatives) helps in my case.

The real problem is that retrieving status from remote device is a slow
operation.  If the GUI thread blocks waiting for the answer, the GUI
blocks and the user complains.

 From Pyro documentation:
---
Normal method calls always block until the response is returned. This
can be any normal return value, None, or an error in the form of a
raised exception. The client code execution is suspended until the
method call has finished and produced its result.
---

So, even with Pyro, I need to have another thread that manages Pyro
communication (instead of serial communication)... additional problems.



Also from the Pyro doc:

You can execute a remote method call and tell Pyro: “hey, I don’t need
the results right now. Go ahead and compute them, I’ll come back later
once I need them”. The call will be processed in the background and you
can collect the results at a later time.

[...]

It is possible to define one or more callables (the “call chain”) that
should be invoked automatically by Pyro as soon as the result value
becomes available.


I already read that, it is the feature "Asynchronous ('future') remote 
calls & call chains".


This approach can be taken also without pyro at all, just using pyserial 
module (and I think all the communication libraries).

With pyserial, I can set a read timeout value of zero:

 timeout = 0: non-blocking mode, return immediately in
 any case, returning zero or more, up to the requested
 number of bytes

In this way, I can implement exactly the same mechanism of pyro in 
asyncronous mode.  With pyserial I could avoid setting timeout=0, using 
in_waiting property ("number of bytes in the input buffer").


Anyway I don't like this approach, because the main (and single) thread 
should check in_waiting every X milliseconds.
If X is too high, I could wait for the answer even if it is already 
ready in the input buffer.
If X is too low, the application consumes a lot of clocks to check 
in_waiting.


I would prefer to have a callback automatically called when the read 
operation is complete.  And I think the only method is using another 
(blocking) thread. The blocking function read returns *immediately* when 
all the bytes are received.  And I think during blocking time, the 
thread isn't consuming CPU clocks.


I could try with asyncio feature of pyserial, but it is classified as 
"experimental".



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

Re: How to use two threads (GUI and backend)

[Demosthenes Koptsis]

Here is an example about threads and PyQT

https://www.youtube.com/watch?v=ivcxZSHL7jM&index=2



On 10/27/2016 01:22 PM, pozz wrote:

Il 26/10/2016 16:18, jmp ha scritto:

On 10/26/2016 02:45 PM, pozz wrote:

Il 26/10/2016 13:16, jmp ha scritto:

[...]
I suggest you write a GUI that make synchronouscalls to a remote
application, if possible. If the remote app is in python, you have
access to remote protocols already written for you, Pyro is one of 
them,

you can skip the low level communication part.


I'm not sure Pyro (or similar alternatives) helps in my case.

The real problem is that retrieving status from remote device is a slow
operation.  If the GUI thread blocks waiting for the answer, the GUI
blocks and the user complains.

 From Pyro documentation:
---
Normal method calls always block until the response is returned. This
can be any normal return value, None, or an error in the form of a
raised exception. The client code execution is suspended until the
method call has finished and produced its result.
---

So, even with Pyro, I need to have another thread that manages Pyro
communication (instead of serial communication)... additional problems.



Also from the Pyro doc:

You can execute a remote method call and tell Pyro: “hey, I don’t need
the results right now. Go ahead and compute them, I’ll come back later
once I need them”. The call will be processed in the background and you
can collect the results at a later time.

[...]

It is possible to define one or more callables (the “call chain”) that
should be invoked automatically by Pyro as soon as the result value
becomes available.


I already read that, it is the feature "Asynchronous ('future') remote 
calls & call chains".


This approach can be taken also without pyro at all, just using 
pyserial module (and I think all the communication libraries).

With pyserial, I can set a read timeout value of zero:

 timeout = 0: non-blocking mode, return immediately in
 any case, returning zero or more, up to the requested
 number of bytes

In this way, I can implement exactly the same mechanism of pyro in 
asyncronous mode.  With pyserial I could avoid setting timeout=0, 
using in_waiting property ("number of bytes in the input buffer").


Anyway I don't like this approach, because the main (and single) 
thread should check in_waiting every X milliseconds.
If X is too high, I could wait for the answer even if it is already 
ready in the input buffer.
If X is too low, the application consumes a lot of clocks to check 
in_waiting.


I would prefer to have a callback automatically called when the read 
operation is complete.  And I think the only method is using another 
(blocking) thread. The blocking function read returns *immediately* 
when all the bytes are received.  And I think during blocking time, 
the thread isn't consuming CPU clocks.


I could try with asyncio feature of pyserial, but it is classified as 
"experimental".





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

Re: Why doesn't Python include non-blocking keyboard input function?

[BartC]

On 27/10/2016 07:51, Steven D'Aprano wrote:

On Thursday 27 October 2016 12:12, BartC wrote:


I don't
understand the argument that a language shouldn't have a basic keyboard
API because some computers it could run on might not have a keyboards.


That's not the argument. The argument is that Python has a basic keyboard API:
raw_input (in Python 2) or input (in 3).

This supports 97% of keyboard-based interaction, namely blocking line-based
text input. Ctrl-C (KeyboardInterrupt) can be co-opted to support maybe another
one or two percent.

The question is, what are the use-cases for the sorts of key APIs you are
asking for? Who needs them? Why should it be a language feature?


If a language (or more likely an OS such as Unix) doesn't natively 
provide a certain feature, then it's not surprising that 97% of 
applications don't use it!


"There's a room in your house with no door to it; how do I get in?"

"There's no need for a door because no one ever uses that room! But you 
can get in through the chimney - if you /have/ to."




Those are not rhetoricial questions.

Python falls neatly into the same niche of languages as (for example) Ruby,
Javascript, Lua, Swift, Tcl, and (not quite as well) bash, Java, Julia. Which
of these languages offer non-blocking keyboard input as a standard part of the
language?


That doesn't surprise me either. Even implementation languages such as C 
tend to shy away from the issue. And since C was intimately associated 
with Unix, it starts to get even less surprising!


But I seem to remember in a previous thread that Python had some problem 
even with line-buffered input. Something to do with only getting a line 
of input as a string then needed to do some processing to read 
individual elements, IIRC.


(FWIW my own language does strive to have this basic stuff built it. But 
getting full keyboard and console handling working as I want it across 
both Windows and Linux is challenging. It's a bit easier on Windows as, 
even though you're using a console, you have the full resources of the 
Win32 API to draw on.


On Linux you can't assume any such resources except some apparently 
1970s-style terminal handling, from what I can figure out.)



Python has no "peek" and "poke" memory access commands either. It's not 1972
and programming has moved on. The utility of something like this feature is
very low, the amount of effort needed for a cross-platform solution is very
high.


My language:

function peek(p,t=byte)=
return makeref(p,t)^
end
...
print peek(0x400'000)

It 'works' on both Windows and Linux, although you need to know what 
addresses to safely peek. (I didn't try poke but that's also easy, if 
more dangerous. But usually I use such pointer accesses for known data 
structures and memory blocks.)


On a machine with a certain memory-mapped device, then this would be ideal.

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

Re: Why doesn't Python include non-blocking keyboard input function?

[Marko Rauhamaa]

Terry Reedy :
> Do people on Linux still commonly use full-screen, no window text
> editors like the one I had?

I occasionally switch on one of the alternate VTs, which are not running
any GUI.

However, I constantly use -- in fact, as I type, I'm using -- a program
running in a PTY environment. IOW, the program "thinks" it's running on
a dedicated text-only terminal. The news program (GNUS/emacs in my case)
is not conscious of pixels, keycodes or the mouse. I must use keyboard
commands to navigate.

> On Windows, there are full screen games, but I have never seen a
> full-screen, no-window text application.

As I'm typing, I have two other, unrelated windows on the screen. I'm
using LXDE, which is a classical GUI environment.

It is my understanding that both Windows and Gnome are moving to a
de-facto full-screen GUI. The GUI strongly prefers you opening windows
in full-screen mode.


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

Re: Why doesn't Python include non-blocking keyboard input function?

[Marko Rauhamaa]

BartC :

> "There's a room in your house with no door to it; how do I get in?"
>
> "There's no need for a door because no one ever uses that room! But
> you can get in through the chimney - if you /have/ to."

+1

> On Linux you can't assume any such resources except some apparently
> 1970s-style terminal handling, from what I can figure out.)

Correct.

> My language:
>
> function peek(p,t=byte)=
> return makeref(p,t)^
> end
> ...
> print peek(0x400'000)
>
> It 'works' on both Windows and Linux

So how do you draw a big, yellow happy face in the top right corner
using your language?


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

Re: Why doesn't Python include non-blocking keyboard input function?

[BartC]

On 27/10/2016 11:07, Terry Reedy wrote:

On 10/26/2016 9:12 PM, BartC wrote:

On 27/10/2016 00:30, Terry Reedy wrote:



So how does your tkinter example work in such a server?


Without X-windows available, there would be no point, and it will not
work.  I presume including the X window subsystem on a linux (server)
build is optional.



Compiling _tkinter.c is optional and many (most?) Linux distributions
put tkinter.py, idlelib/*.py, and turtle.py in a separate package.


I tried your example. It sort of worked but was a bit temperamental when 
pressing Rshift.


But I also tried it in a virtual Ubuntu which said that tkinter was not 
installed.


And I tried it on Debian on a raspberry pi without X-windows running, 
and there it also failed even though it didn't use a window.


So even with a supposedly standard library such as tkinter, relying on 
it can give problems. (Apart from to switch between between Tkinter and 
tkinter depending on Python version.)


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

Re: How to use two threads (GUI and backend)

[jmp]

On 10/27/2016 12:22 PM, pozz wrote:

Anyway I don't like this approach, because the main (and single) thread
should check in_waiting every X milliseconds.
If X is too high, I could wait for the answer even if it is already
ready in the input buffer.
If X is too low, the application consumes a lot of clocks to check
in_waiting.

I would prefer to have a callback automatically called when the read
operation is complete.  And I think the only method is using another
(blocking) thread. The blocking function read returns *immediately* when
all the bytes are received.  And I think during blocking time, the
thread isn't consuming CPU clocks.


Threads do consume CPU clocks.
An operation within a thread will not consume less CPU clocks, however, 
the scheduler will interrupt the thread and give other 
threads/operations a chance to process as well.

Threads implement paralellism, not performances.

From what I understand of your context, you don't want you GUI to 
"freeze" when waiting for the remote application. That's a valid concern.


You can use threads to fix that(or you can use already written working 
python libraries that would mask this low level programing, it's up to you).


What you should not do is focus on gaining "CPU clocks". You just don't 
care. It's probably not an issue. If it is, drop python and implement 
your app in C.


JM


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

Re: How to use two threads (GUI and backend)

[Chris Angelico]

On Thu, Oct 27, 2016 at 10:33 PM, jmp  wrote:
> On 10/27/2016 12:22 PM, pozz wrote:
>>
>> Anyway I don't like this approach, because the main (and single) thread
>> should check in_waiting every X milliseconds.
>> If X is too high, I could wait for the answer even if it is already
>> ready in the input buffer.
>> If X is too low, the application consumes a lot of clocks to check
>> in_waiting.
>>
>> I would prefer to have a callback automatically called when the read
>> operation is complete.  And I think the only method is using another
>> (blocking) thread. The blocking function read returns *immediately* when
>> all the bytes are received.  And I think during blocking time, the
>> thread isn't consuming CPU clocks.
>
>
> Threads do consume CPU clocks.
> An operation within a thread will not consume less CPU clocks, however, the
> scheduler will interrupt the thread and give other threads/operations a
> chance to process as well.
> Threads implement paralellism, not performances.

Blocked threads don't consume CPU time. Why would they?

Remember, folks, *EVERY* program has at least one thread. Threads
aren't some weird and magical thing that you have to be scared of.
They're things you use *all the time*, and they are exactly what
you're used to.

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

Re: Why doesn't Python include non-blocking keyboard input function?

[Steve D'Aprano]

On Thu, 27 Oct 2016 09:42 pm, BartC wrote:

> On 27/10/2016 07:51, Steven D'Aprano wrote:
>> On Thursday 27 October 2016 12:12, BartC wrote:
>>
>>> I don't
>>> understand the argument that a language shouldn't have a basic keyboard
>>> API because some computers it could run on might not have a keyboards.
>>
>> That's not the argument. The argument is that Python has a basic keyboard
>> API: raw_input (in Python 2) or input (in 3).
>>
>> This supports 97% of keyboard-based interaction, namely blocking
>> line-based text input. Ctrl-C (KeyboardInterrupt) can be co-opted to
>> support maybe another one or two percent.
>>
>> The question is, what are the use-cases for the sorts of key APIs you are
>> asking for? Who needs them? Why should it be a language feature?
> 
> If a language (or more likely an OS such as Unix) doesn't natively
> provide a certain feature, then it's not surprising that 97% of
> applications don't use it!

Perhaps you should read my statement again.

My claim (plucked from thin air, of course, but nevertheless I'm sticking by
it) is that for 97% of use-cases, when a non-GUI program needs text input
from the user, the *right solution* is blocking line-based text input.

I don't need one character at a time. I want to pause everything else, ask
the user a question, and wait for them to enter an entire line.

And no, I don't want to reinvent the wheel and build up line editing from
character editing myself. I don't want to have to handle backspacing and
navigation myself.



>> Those are not rhetoricial questions.

Feel free to give an answer. Apart from reinventing the wheel and building
functionality that Python already supports, what do you use non-blocking
keyboard input for? Can you give some examples of how you might use it?


>> Python falls neatly into the same niche of languages as (for example)
>> Ruby, Javascript, Lua, Swift, Tcl, and (not quite as well) bash, Java,
>> Julia. Which of these languages offer non-blocking keyboard input as a
>> standard part of the language?
> 
> That doesn't surprise me either. 

That was a question, not a statement.

You claim that this sort of low-level non-blocking keyboard input is
a "basic" API. Okay, then which other languages offer this?

If Python is the odd one out, if every other programming language bar Python
provides this API, then I'll cheerfully acknowledge that I'm terribly
wrong. I don't understand what this function is good for myself, but
obviously thousands of others do, so I'll learn something from them.

Or... if no other language offers this "basic" API, then maybe its not that
useful or simple, and perhaps not that basic.


> Even implementation languages such as C 
> tend to shy away from the issue. And since C was intimately associated
> with Unix, it starts to get even less surprising!

How about Lisp? Scheme? Fortran? Java? C#? Objective-C? Dylan? Forth? Well
I'd completely believe Forth has this, I think you'd like Chuck Moore, I
think the two of you think in similar ways.

Cobol? Hypertalk? Inform 7? Bash? Haskell?

There must be *some* language other than your own that offers this feature,
if it is as obvious, useful, simple and basic and you claim.



> But I seem to remember in a previous thread that Python had some problem
> even with line-buffered input. Something to do with only getting a line
> of input as a string then needed to do some processing to read
> individual elements, IIRC.

O_o

Um, of course it gets a line of input as a text string. What would you
expect to get the user's text as? A bitmap?


> (FWIW my own language does strive to have this basic stuff built it. But
> getting full keyboard and console handling working as I want it across
> both Windows and Linux is challenging. It's a bit easier on Windows as,
> even though you're using a console, you have the full resources of the
> Win32 API to draw on.
> 
> On Linux you can't assume any such resources except some apparently
> 1970s-style terminal handling, from what I can figure out.)

And possibly not even that. If your script is running as a cron job, I
believe that there's no terminal attached, and possibly no stdin or stdout.
I don't remember the details.





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: How to use two threads (GUI and backend)

[pozz]

Il 27/10/2016 13:33, jmp ha scritto:

On 10/27/2016 12:22 PM, pozz wrote:

Anyway I don't like this approach, because the main (and single) thread
should check in_waiting every X milliseconds.
If X is too high, I could wait for the answer even if it is already
ready in the input buffer.
If X is too low, the application consumes a lot of clocks to check
in_waiting.

I would prefer to have a callback automatically called when the read
operation is complete.  And I think the only method is using another
(blocking) thread. The blocking function read returns *immediately* when
all the bytes are received.  And I think during blocking time, the
thread isn't consuming CPU clocks.


Threads do consume CPU clocks.
An operation within a thread will not consume less CPU clocks, however,
the scheduler will interrupt the thread and give other
threads/operations a chance to process as well.
Threads implement paralellism, not performances.


Yes of course, but when the backend thread calls the *blocking* function 
pyserial.read(), it *doesn't* consume CPU clocks (at least, I hope).
The low-level implementation of pyserial.read() should move the thread 
in a "suspend" or "waiting" state, so the thread scheduler shouldn't 
activate it. The suspend state is exited (automatically from OS, I 
think) when one or more bytes are ready in the input buffer.




From what I understand of your context, you don't want you GUI to
"freeze" when waiting for the remote application. That's a valid concern.

You can use threads to fix that(or you can use already written working
python libraries that would mask this low level programing, it's up to
you).

What you should not do is focus on gaining "CPU clocks". You just don't
care. It's probably not an issue. If it is, drop python and implement
your app in C.


Because I don't want to drop python, I want to learn the best tecnique 
to use to have the best performance.


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

Re: How to use two threads (GUI and backend)

[Chris Angelico]

On Thu, Oct 27, 2016 at 10:56 PM, pozz  wrote:
> Yes of course, but when the backend thread calls the *blocking* function
> pyserial.read(), it *doesn't* consume CPU clocks (at least, I hope).
> The low-level implementation of pyserial.read() should move the thread in a
> "suspend" or "waiting" state, so the thread scheduler shouldn't activate it.
> The suspend state is exited (automatically from OS, I think) when one or
> more bytes are ready in the input buffer.

Exactly.

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

Re: How to use two threads (GUI and backend)

[jmp]

On 10/27/2016 01:43 PM, Chris Angelico wrote:

Blocked threads don't consume CPU time. Why would they?

ChrisA



Agreed. My point being that a blocked thread achieve nothing, except 
parallelism, i.e. other threads can be processed.


To be more specific, if you compute factorial(51354) in a thread, it 
will still require approx. the same amount of CPU clocks than in a main 
thread (probably slightly more due to the scheduler overhead).


jm


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

Re: How to use two threads (GUI and backend)

[Chris Angelico]

On Thu, Oct 27, 2016 at 11:33 PM, jmp  wrote:
> On 10/27/2016 01:43 PM, Chris Angelico wrote:
>>
>> Blocked threads don't consume CPU time. Why would they?
>>
>> ChrisA
>>
>
> Agreed. My point being that a blocked thread achieve nothing, except
> parallelism, i.e. other threads can be processed.
>
> To be more specific, if you compute factorial(51354) in a thread, it will
> still require approx. the same amount of CPU clocks than in a main thread
> (probably slightly more due to the scheduler overhead).
>
> jm

Of course. But the OP wants to do blocking calls, which don't cost you
like that. So it's fine.

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

Re: Why doesn't Python include non-blocking keyboard input function?

[BartC]

[repost as original disappeared]
On 27/10/2016 12:41, Steve D'Aprano wrote:

On Thu, 27 Oct 2016 09:42 pm, BartC wrote:



I don't need one character at a time. I want to pause everything else, ask
the user a question, and wait for them to enter an entire line.

And no, I don't want to reinvent the wheel and build up line editing from
character editing myself. I don't want to have to handle backspacing and
navigation myself.


You're just throwing the ball into someone else's court then.

YOU don't want such features to be part of a language, but you expect 
others to be able to write text-mode editors, IDEs, file-managers, games 
etc without them?


Presumably you're OK with those features being available in a GUI 
environment? So why the discrimination?


Text-apps aren't so common now but I get the impression that you would 
never have found this stuff useful.



Feel free to give an answer. Apart from reinventing the wheel and building
functionality that Python already supports, what do you use non-blocking
keyboard input for? Can you give some examples of how you might use it?


I didn't even know what non-blocking meant until this thread.

But suppose you're writing an app such as a debugger, or interpreter, or 
anything that keeps going until interrupted or controlled by some key 
event. If you're executing a billion instructions per second you don't 
want to keep stopping every N instructions to ask the user for any 
special requests, or to press Enter to continue.


Is that good enough?

Doubtless your solution would be some large sledgehammer to crack this 
particular nut.



How about Lisp? Scheme? Fortran? Java? C#? Objective-C? Dylan? Forth? Well
I'd completely believe Forth has this, I think you'd like Chuck Moore, I
think the two of you think in similar ways.

Cobol? Hypertalk? Inform 7? Bash? Haskell?



There must be *some* language other than your own that offers this feature,
if it is as obvious, useful, simple and basic and you claim.


I'm not familiar with that many languages. However if you google for 
' non-blocking keyboard' then it seems quite a few people are 
interested in the feature!



But I seem to remember in a previous thread that Python had some problem
even with line-buffered input. Something to do with only getting a line
of input as a string then needed to do some processing to read
individual elements, IIRC.


O_o

Um, of course it gets a line of input as a text string. What would you
expect to get the user's text as? A bitmap?


  print "Enter 3 numbers: "
  readln a,b,c

I'm fairly sure this kind of input was common in plenty of other 
languages. But maybe even that is being frowned on now; /that/ wouldn't 
surprise me either.





(FWIW my own language does strive to have this basic stuff built it. But
getting full keyboard and console handling working as I want it across
both Windows and Linux is challenging. It's a bit easier on Windows as,
even though you're using a console, you have the full resources of the
Win32 API to draw on.

On Linux you can't assume any such resources except some apparently
1970s-style terminal handling, from what I can figure out.)


And possibly not even that. If your script is running as a cron job, I
believe that there's no terminal attached, and possibly no stdin or stdout.
I don't remember the details.


The same argument as before. So we don't have print() as part of the 
language either before there might not be a stdout?!


The fact is that if I want to run an editor under Linux, I will need a 
display, and a keyboard, and I want to have the means to use them.


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

Re: How to use two threads (GUI and backend)

[jmp]

On 10/27/2016 02:55 PM, Chris Angelico wrote:

On Thu, Oct 27, 2016 at 11:33 PM, jmp  wrote:

On 10/27/2016 01:43 PM, Chris Angelico wrote:


Blocked threads don't consume CPU time. Why would they?

ChrisA



Agreed. My point being that a blocked thread achieve nothing, except
parallelism, i.e. other threads can be processed.

To be more specific, if you compute factorial(51354) in a thread, it will
still require approx. the same amount of CPU clocks than in a main thread
(probably slightly more due to the scheduler overhead).

jm


Of course. But the OP wants to do blocking calls, which don't cost you
like that. So it's fine.

ChrisA


Sure but the OP is very focus on performance(that's a mistake imo).

"Because I don't want to drop python, I want to learn the best technique 
to use to have the best performance. "


I just wanted to point that using thread implements parallelism, not 
performance. And that's probably what its gui needs. And that's probably 
why using a higher level API would have been acceptable.


JM

Best performance is achieved by sacrificing a lot in python. A better 
technique than polling threads would be sleeping thread where the thread 
is put to hold until a hardware interrupt wakes up the thread.







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

Re: Why doesn't Python include non-blocking keyboard input function?

[Marko Rauhamaa]

BartC :
> If you're executing a billion instructions per second you don't want
> to keep stopping every N instructions to ask the user for any special
> requests, or to press Enter to continue.

In mobile computing, such wakeups drain the battery.


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

Re: Why doesn't Python include non-blocking keyboard input function?

[Grant Edwards]

On 2016-10-27, Marko Rauhamaa  wrote:
> Grant Edwards :
>> I've offered a few times to extend the Linux pty driver to support the
>> same set of ioctl calls that a tty does (so that it could be used in
>> place of a tty generally), but I've never gotten any response.
>
> Ah, Linux kernel politics are Byzantine. It's virtually impossible to
> get a hearing at the linux-kernel main mailing list. Did you try one of
> the targeted mailing lists on  http://vger.kernel.org/vger-lists.html>?

Yes, I posted my proposal to the linux-serial list -- which I _think_
is the right one for the pty driver, but that may not have been the
right list.

I suspect proposals like mine generally just get ignored unless you
can show code to back them up.

-- 
Grant Edwards   grant.b.edwardsYow! My face is new, my
  at   license is expired, and I'm
  gmail.comunder a doctor's care

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

Re: Why doesn't Python include non-blocking keyboard input function?

[Grant Edwards]

On 2016-10-27, Terry Reedy  wrote:

> When I used unix in the 1980s, the full screen ran csh until one started 
> another full screen application.  MSDOS was the same. Every contemporary 
> photo of modern Linux or Mac I have seen has a desktop with windows just 
> like Windows.  Do people on Linux still commonly use full-screen,

It depends on your definition of "commonly".  I do it fairly
regularly, but only for short periods of time while doing system
maintenance stuff.

> no  window text editors like the one I had?

Don't know what you mean by "window text editors"

> On Windows, there are full screen games, but I have never seen a
> full-screen, no-window text application.

Just con't conflate "full-screen" with "command-line" or "terminal"
applications.  I do use terminal applications all day, every day, but
I mostly run them in terminal emulator windows on top of X11 (that way
I can have lots of terminals of various sizes and shapes).

> Since modern screen are pixel graphics screens, rather than character 
> screens, there must be a widget, whether standard with the OS or custom 
> to the console, that emulates the old fixed-pitch character screens.

Yes.  On Unix they're called terminal emulators, and I use lots of
them them constantly.  This post is being edited in one.

> At least on Windows, C Programs that run with the console still get
> characters entered by users and send characters to be displayed.

On Unix, a terminal emulator on an X11/Wayland desktop, a linux video
console, a real serial terminal connected to an RS-232C serial port,
or a "screen" session  all
behave pretty much the same.  The API supported by the pty driver, the
video console tty driver, and the real serial-port tty driver, all
provide a common set of API calls.

-- 
Grant Edwards   grant.b.edwardsYow! I wish I was on a
  at   Cincinnati street corner
  gmail.comholding a clean dog!

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

Re: How to use two threads (GUI and backend)

[D'Arcy Cain]

On 2016-10-27 07:33 AM, jmp wrote:

On 10/27/2016 12:22 PM, pozz wrote:

(blocking) thread. The blocking function read returns *immediately* when
all the bytes are received.  And I think during blocking time, the
thread isn't consuming CPU clocks.


Threads do consume CPU clocks.


Sometimes they do but read what pozz wrote.  "during blocking time, the 
thread isn't consuming CPU clocks".  That means that if you have two 
threads with one computing π and the other blocked waiting for user 
input then the first one is using CPU cycles - as many as it can get - 
and the other is using none until the user enters something.  This is 
kind of the point of threads - only things that need cycles get cycles.



An operation within a thread will not consume less CPU clocks, however,


It will if it blocks for something.  A simple sleep will also give up 
the processor.



From what I understand of your context, you don't want you GUI to
"freeze" when waiting for the remote application. That's a valid concern.


And that's why you use threads.  You can also use select in a state 
machine loop.  Depends on your model and somewhat on your preferences.



What you should not do is focus on gaining "CPU clocks". You just don't
care. It's probably not an issue. If it is, drop python and implement
your app in C.


In fact, going to C often is less of a win than you may think.  Python 
is pretty damn efficient if you write good code.


--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
--
https://mail.python.org/mailman/listinfo/python-list

Windows switch between python 2 and 3

[Daiyue Weng]

Hi, I installed Python 2.7 and Python 3.5 64 bit versions on Win 10. Under

C:\Python35

C:\Python27

Both have been set in environment variable Path.

When I type python in cmd, it only gives me python 2.7, I am wondering how
to switch between 2 and 3 in command prompt.

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

Re: multiprocess passing arguments double asterisks

[ricemom]

On Wednesday, October 26, 2016 at 5:31:18 PM UTC-5, MRAB wrote:
> On 2016-10-26 21:44, pic8...@gmail.com wrote:
> > On Monday, October 24, 2016 at 12:39:47 PM UTC-5, Thomas Nyberg wrote:
> >> On 10/24/2016 12:45 PM, pic8...@gmail.com wrote:
> >> > Thanks for the reply.
> >> >
> >> > The code snippet given by Peter is not very clear
> >> >
> >> > I would like to multiprocess a function which is written in python of 
> >> > the form bar(**kwargs) which returns a value.  This example does not 
> >> > return anything
> >> >
> >> > Would you please use my example for the map function?
> >> >
> >> > I appreciate your help,
> >> >
> >> I'm honestly not totally sure what you want to do. However, say you want
> >> to do the following (btw this is basically what Dennis said i nhis last
> >> email, but maybe I can help clarify):
> >>
> >>kwargs = {'param1': val1, 'param2': val2})
> >>
> >> Then you'd like to have the following two operations performed in
> >> separate processes:
> >>
> >>bar(param1=val1)
> >>bar(param2=val2)
> >>
> >> In that case, I guess I would do something like the following. First
> >> define bar_wrapper as follows (*I haven't tested any code here!):
> >>
> >> def bar_wrapper(pair):
> >>key, val = pair
> >>return bar(**{key: val})
> >>
> >> Then I would probably do something like
> >>
> >> map(bar_wrapper, kwargs.items())
> >>
> >> I.e. basically what I'm doing is taking the key-val pairs and producing
> >> a list of them (as tuples). This is something that you can apply map
> >> too, but not with the original function. So then the wrapper function
> >> converts the tuple back to what you want originally.
> >>
> >> Hopefully I'm understanding correctly and hopefully this helps.
> >>
> >> Cheers,
> >> Thomas
> >
> > Thomas,
> >
> > I have strings & numpy.ndarray as arguments.  The wrapper function works 
> > great for strings.
> >
> > Here's what I'm trying to do...
> > **
> >
> > I have a serial python fn of the form
> >
> > def bar(**kwargs):
> >   a=kwargs.get("name")
> >   print a
> >   self.a1d=ma.asanyarray(kwargs.get('a1d'), dtype=float)
> >   (more calculations--takes a long time to compute
> >   returns an object)
> >
> > I am trying to run this function in parallel.
> >
> > Here's my Main program
> >
> > import numpy as np
> > import numpy.ma as ma
> > from delegate import parallelize
> > from hashlib import sha1
> > a1d=np.zeros((32))
> > b1d=np.zeros((32))
> > p=open("/tmp/pdata","rb")
> > pdata=np.load(p)
> > for i in range(0,10):
> >   a1d=pdata['t1d']
> >   b1d=pdata['gz1d']
> >   print a1d,b1d
> >   kwargs={'name':'special','a':a1d,'b':b1d}
> >   val=parallelize(bar,kwargs)
> > ***
> > Error:
> > line 30, in 
> > val=parallelize(bar,kwargs)
> >delegate.py", line 311, in process
> > item, items = items[0], items[1:]
> > KeyError: 0
> > **
> > Error: (with the wrapper function)
> > val=parallelize(bar_wrapper,kwargs.items())
> > TypeError: unhashable type: 'numpy.ndarray'
> > ***
> >
> > How do I pass the string & numpy.ndarray to the function bar(**kwargs)?
> >
> > Thank you for suggestions & help,
> >
> >
> > a1d=np.zeros((32))
> > b1d=np.zeros((32))
> > p=open("/tmp/pdata","rb")
> > pdata=np.load(p)
> > for i in range(0,100):
> >   a1d=pdata['t1d']
> >   b1d=pdata['gz1d']
> >   print a1d,b1d
> >   kwargs={'name':'special','a':a1d,'b':b1d}
> >   val=parallelize(bar,kwargs)
> >
> 'parallelize' expects a function and a list of items. It calls the 
> function with each item in the list in parallel, passing the item as the 
> argument of the function.
> 
> That _single_ argument item can be a tuple or a dict.

--if the dict has numpy arrays it fails..

In the above example if
   kwargs={'name':'special','a':2}
   val=parallelize(bar_wrapper,kwargs.items()) it works fine

But if
 kwargs={'name':'special','a':a1d,'b':b1d}
it fails  (a1d & b1d are numpy arrays)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows switch between python 2 and 3

[Peter Otten]

Daiyue Weng wrote:

> Hi, I installed Python 2.7 and Python 3.5 64 bit versions on Win 10. Under
> 
> C:\Python35
> 
> C:\Python27
> 
> Both have been set in environment variable Path.
> 
> When I type python in cmd, it only gives me python 2.7, I am wondering how
> to switch between 2 and 3 in command prompt.
> 
> cheers

https://docs.python.org/3.5/using/windows.html#python-launcher-for-windows

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

Re: Windows switch between python 2 and 3

[Veek M]

Daiyue Weng wrote:

> Hi, I installed Python 2.7 and Python 3.5 64 bit versions on Win 10.
> Under
> 
> C:\Python35
> 
> C:\Python27
> 
> Both have been set in environment variable Path.
> 
> When I type python in cmd, it only gives me python 2.7, I am wondering
> how to switch between 2 and 3 in command prompt.
> 
> cheers

you could try typing the path to the interpreter:
c:\Python35\bin\python.exe foo.py

or changing the path ordering using 'set /?' i think - google
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows switch between python 2 and 3

[Steve D'Aprano]

On Fri, 28 Oct 2016 02:11 am, Daiyue Weng wrote:

> Hi, I installed Python 2.7 and Python 3.5 64 bit versions on Win 10. Under
> 
> C:\Python35
> 
> C:\Python27
> 
> Both have been set in environment variable Path.
> 
> When I type python in cmd, it only gives me python 2.7, I am wondering how
> to switch between 2 and 3 in command prompt.

I don't use Windows, so I am guessing, but you could try:

python2
python27

python3
python35




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Windows switch between python 2 and 3

[Zachary Ware]

On Thu, Oct 27, 2016 at 10:11 AM, Daiyue Weng  wrote:
> Hi, I installed Python 2.7 and Python 3.5 64 bit versions on Win 10. Under
>
> C:\Python35
>
> C:\Python27
>
> Both have been set in environment variable Path.
>
> When I type python in cmd, it only gives me python 2.7, I am wondering how
> to switch between 2 and 3 in command prompt.

Along with Python 3.5, the Python Launcher for Windows (py.exe) was
installed in C:\Windows, unless you unchecked it.  You can choose
which interpreter you want to run by an argument to py.exe; for Python
2.7, use `py -2.7`; for Python 3.5, use `py -3.5`.  There are also
shortcuts for "latest Python 2" and "latest Python 3", `py -2` and `py
-3` respectively.  Calling `py` on its own will default to matching
`py -2`, but settings can be changed in C:\Windows\py.ini.  See
https://docs.python.org/using/windows.html#launcher for more details.

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

Re: problem using pickle

[Veek M]

Rustom Mody wrote:

> On Saturday, July 2, 2016 at 9:17:01 AM UTC+5:30, Veek. M wrote:
>> object is a keyword and you're using it as an identifier
> 
> keyword and builtin are different
> In this case though the advice remains the same
> In general maybe not...
> Just sayin'
np - feel free to correct me
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: problem using pickle

[Veek M]

Ben Finney wrote:

> "Veek. M"  writes:
> 
>> class Foo(object):
>>   pass
>>
>> object is a keyword and you're using it as an identifier
> 
> Python does not have ‘object’ as a keyword. ‘and’ is a keyword.
> 
> Here's the difference::
> 
> >>> object
> 
> >>> object = "Lorem ipsum"
> >>> object
> 'Lorem ipsum'
> 
> >>> and
>   File "", line 1
> and
>   ^
> SyntaxError: invalid syntax
> >>> and = "Lorem ipsum"
>   File "", line 1
> and = "Lorem ipsum"
>   ^
> SyntaxError: invalid syntax
> 
> Here is how you can test whether a word is a Python keyword::
> 
> >>> import keyword
> >>> keyword.iskeyword('object')
> False
> >>> keyword.iskeyword('and')
> True
> 
> The set of keywords in Python is quite small.
> 
> >>> len(keyword.kwlist)
> 33
> 
Oh awesome - thanks - that's a neat module. Yeah, basically keywords are 
part of the language but not punctuation - kind of like how you had to 
do: print 'foo' in 2.x - part of the grammar of the language. Dunno why 
i muffed that.. 'object's a class anyhow so it couldn't be a keyword 
(inherited with its methods etc) - thanks for catching that and sorry 
for the delay.. saw that today.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why doesn't Python include non-blocking keyboard input function?

[Steve D'Aprano]

On Fri, 28 Oct 2016 12:13 am, BartC wrote:

> [repost as original disappeared]
> On 27/10/2016 12:41, Steve D'Aprano wrote:
>> On Thu, 27 Oct 2016 09:42 pm, BartC wrote:
> 
>> I don't need one character at a time. I want to pause everything else,
>> ask the user a question, and wait for them to enter an entire line.
>>
>> And no, I don't want to reinvent the wheel and build up line editing from
>> character editing myself. I don't want to have to handle backspacing and
>> navigation myself.
> 
> You're just throwing the ball into someone else's court then.


Well of course I am. I don't program my code from bare metal. Nobody with
any sense does that, at least not on a PC. Maybe on embedded systems.

I don't write my own memory management, or my own file system, or my own
process scheduler, or any of the other dozens of things that the OS does
much, much better than anything I can do.

Including line editing.


> YOU don't want such features to be part of a language, but you expect
> others to be able to write text-mode editors, IDEs, file-managers, games
> etc without them?

Ah, now we're getting somewhere: I'm starting to get a hint of what this
feature might be useful for. Okay.

Sure, I'll accept that perhaps this feature of non-blocking keyboard input
does have its use-cases. I might even revise my plucked-from-thin-air
figure of 97% down to allow for "text-mode editors, IDEs, file-managers,
games, etc.".

All of those are big, complex applications. Not Microsoft Office big, or
Oracle database big, but still, you need things like windows, dialog boxes,
animation, sprites, etc. If I were writing any of those, I would absolutely
want to start with an existing framework or library that provides things
like windows, menus, icons, and text input widgets. Whether I'm doing a GUI
application or a text-based application, I wouldn't be writing this stuff
from scratch like it was 1973.

And yes, that's "throwing the ball into someone else's court". There's no
shame in that.


> Presumably you're OK with those features being available in a GUI
> environment? So why the discrimination?

What discrimination? They're available in text environments too. You just
have to use a good text-based UI library, like curses.


> Text-apps aren't so common now but I get the impression that you would
> never have found this stuff useful.
> 
>> Feel free to give an answer. Apart from reinventing the wheel and
>> building functionality that Python already supports, what do you use
>> non-blocking keyboard input for? Can you give some examples of how you
>> might use it?
> 
> I didn't even know what non-blocking meant until this thread.

When you call (raw_)input(), Python stops processing until the user hits
Enter, at which point it returns whatever they typed.

Earlier, I mistakenly posted a recipe that works similarly: it pauses until
the user hits a key. It *blocks* until the user hits a key, then returns
that key and continues.

A non-blocking function might return None if there is no character in the
input buffer, or that character. I don't know -- I'm not sure how the API
would be designed.

 
> But suppose you're writing an app such as a debugger, or interpreter, or
> anything that keeps going until interrupted or controlled by some key
> event. If you're executing a billion instructions per second you don't
> want to keep stopping every N instructions to ask the user for any
> special requests, or to press Enter to continue.
> 
> Is that good enough?
> 
> Doubtless your solution would be some large sledgehammer to crack this
> particular nut.

*shrug*

Python's a pretty high-level language. Not every low-level feature needs to
be part of the Python language. This sounds like something you would write
in a low-level language like C or Rust, turn it into a extension file, and
call it from Python.

You could always check the source code to the Python debugger. Presumably it
already solves this. There has to be *some* solution. After all, operating
systems, text editors, shells, GUI frameworks, etc. all support this.


>> How about Lisp? Scheme? Fortran? Java? C#? Objective-C? Dylan? Forth?
>> Well I'd completely believe Forth has this, I think you'd like Chuck
>> Moore, I think the two of you think in similar ways.
>>
>> Cobol? Hypertalk? Inform 7? Bash? Haskell?
> 
>> There must be *some* language other than your own that offers this
>> feature, if it is as obvious, useful, simple and basic and you claim.
> 
> I'm not familiar with that many languages. However if you google for
> ' non-blocking keyboard' then it seems quite a few people are
> interested in the feature!

*shrug* My very first response suggested that many people ask for this
feature, but then after writing code to implement it, they find they don't
actually need it. Maybe I'm wrong. But if this is so useful, outside of
specialist areas, why do so few languages support it?


>>> But I seem to remember in a previous thread that Python had some problem
>>> even

Re: Windows switch between python 2 and 3

[Daiyue Weng]

python windows launcher seems like the best option here.

thanks

On 27 October 2016 at 16:49, Zachary Ware 
wrote:

> On Thu, Oct 27, 2016 at 10:11 AM, Daiyue Weng 
> wrote:
> > Hi, I installed Python 2.7 and Python 3.5 64 bit versions on Win 10.
> Under
> >
> > C:\Python35
> >
> > C:\Python27
> >
> > Both have been set in environment variable Path.
> >
> > When I type python in cmd, it only gives me python 2.7, I am wondering
> how
> > to switch between 2 and 3 in command prompt.
>
> Along with Python 3.5, the Python Launcher for Windows (py.exe) was
> installed in C:\Windows, unless you unchecked it.  You can choose
> which interpreter you want to run by an argument to py.exe; for Python
> 2.7, use `py -2.7`; for Python 3.5, use `py -3.5`.  There are also
> shortcuts for "latest Python 2" and "latest Python 3", `py -2` and `py
> -3` respectively.  Calling `py` on its own will default to matching
> `py -2`, but settings can be changed in C:\Windows\py.ini.  See
> https://docs.python.org/using/windows.html#launcher for more details.
>
> --
> Zach
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[PyQT] After MessageBox app quits...why?

[Demosthenes Koptsis]

Hello, i have a PyQT systray app with a menu and two actions.

Action1 is Exit and action2 display a MessageBox with Hello World message.

When i click OK to MessageBox app quits...why?

http://pastebin.com/bVA49k1C

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

Re: Why doesn't Python include non-blocking keyboard input function?

[BartC]

On 27/10/2016 17:13, Steve D'Aprano wrote:

On Fri, 28 Oct 2016 12:13 am, BartC wrote:



Doubtless your solution would be some large sledgehammer to crack this
particular nut.


*shrug*

Python's a pretty high-level language. Not every low-level feature needs to
be part of the Python language. This sounds like something you would write
in a low-level language like C or Rust, turn it into a extension file, and
call it from Python.


I tend not to separate out which applications which are suitable for 
low-level and which are better for high-level languages.


And I've seen things like 'import msvcrt', 'import winapi' in Python 
code, and then there's all that stuff with ctypes.


It look like other people don't worry about that either. Although if the 
language is really unsuitable then they'll find out when it runs too 
slowly to be practical.



You could always check the source code to the Python debugger. Presumably it
already solves this. There has to be *some* solution. After all, operating
systems, text editors, shells, GUI frameworks, etc. all support this.


Yes, all those kinds of application need these basic features. Isn't it 
odd then that not a single mainstream language provides them as standard?


(From my point of view the discussion has been about any key-at-a-time 
events rather than blocking or not. Those are also problematical.)



I'm not familiar with that many languages. However if you google for
' non-blocking keyboard' then it seems quite a few people are
interested in the feature!


*shrug* My very first response suggested that many people ask for this
feature, but then after writing code to implement it, they find they don't
actually need it. Maybe I'm wrong. But if this is so useful, outside of
specialist areas, why do so few languages support it?


For years I've had discussions in comp.lang.c about things that C should 
or should not have. What usually happens is that someone comes up with 
some crude workaround using macros, so there is less need to have some 
feature built-in (and the language fails to a acquire a slick new 
enhancement).


But with the usual trouble that everyone then has to re-invent the same 
macro but in a different way to everyone else.


The same thing probably happens with a low-level keyboard API. There are 
half a dozen ways of achieving the same functionality (with varying 
degrees of hassle), so maybe the language doesn't need to provide a 
standard solution after all.


You talk about not wanting to re-invent things, but that's exactly what 
everyone ends up doing!



   print "Enter 3 numbers: "
   readln a,b,c


How is the interpreter supposed to know that a, b, c are numbers? What sort
of numbers? 16-bit integers, 80-bit floats, Bignums, complex, Fractions, or
something else?



But in a dynamically typed language, the compiler has no idea what you
expect a, b and c to be. So it returns text, and you can convert it
yourself.


So you tell it what to expect. The above example is from a dynamic 
language, and will assume integers unless told otherwise. This:


  readln a:"h", b:"r", c:"s"

reads a hex integer, floating point number and a string respectively 
(with a default set of separators delimiting the string, or "..." can be 
used). Or values can be read one at a time:


 readln
 read a:"h"

I think this came up when someone wanted to switch from Visual Basic to 
Python. The above is not a very sophisticated approach but it is very 
simple and intuitive.


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

Re: Windows switch between python 2 and 3

[eryk sun]

On Thu, Oct 27, 2016 at 3:41 PM, Steve D'Aprano
 wrote:
> On Fri, 28 Oct 2016 02:11 am, Daiyue Weng wrote:
>
>> Hi, I installed Python 2.7 and Python 3.5 64 bit versions on Win 10. Under
>>
>> C:\Python35
>>
>> C:\Python27
>>
>> Both have been set in environment variable Path.
>>
>> When I type python in cmd, it only gives me python 2.7, I am wondering how
>> to switch between 2 and 3 in command prompt.
>
> I don't use Windows, so I am guessing, but you could try:
>
> python2
> python27
>
> python3
> python35

These links aren't created by the installer, but you can create them
if that's your preference. Execute the following in an admin command
prompt:

mklink C:\Python27\python2.7.exe C:\Python27\python.exe
mklink C:\Python27\python2.exe C:\Python27\python.exe
mklink C:\Python35\python3.5.exe C:\Python35\python.exe
mklink C:\Python35\python3.exe C:\Python35\python.exe
-- 
https://mail.python.org/mailman/listinfo/python-list

How to execute "gksudo umount VirtualDVD"

[Demosthenes Koptsis]

I want to execute the command "gksudo umount VirtualDVD"

My code is this but it fails:

def umount(self):
'''unmounts VirtualDVD''' cmd ='gksudo umount VirtualDVD' proc = 
subprocess.Popen(str(cmd),shell=True,stdout=subprocess.PIPE).stdout.read()
print proc

It pops up the gksudo dialog, and then fails. But i don't get any stdout 
or stderror.


I tried cmd='gksudo ls' and it succeeds.

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

Re: Why doesn't Python include non-blocking keyboard input function?

[Gregory Ewing]

BartC wrote:

"There's a room in your house with no door to it; how do I get in?"

"There's no need for a door because no one ever uses that room! But you 
can get in through the chimney - if you /have/ to."


It's not like that. The room *does* have a door, it's just
that it's in different places in different houses, and may
require a different key to open it.


function peek(p,t=byte)=
return makeref(p,t)^
end


You can achieve similar things in Python using ctypes if
you really need to live that dangerously.

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

Re: How to execute "gksudo umount VirtualDVD"

[Ian Kelly]

On Thu, Oct 27, 2016 at 3:30 PM, Demosthenes Koptsis
 wrote:
> I want to execute the command "gksudo umount VirtualDVD"
>
> My code is this but it fails:
>
> def umount(self):
> '''unmounts VirtualDVD''' cmd ='gksudo umount VirtualDVD' proc =
> subprocess.Popen(str(cmd),shell=True,stdout=subprocess.PIPE).stdout.read()
> print proc

It looks like your code pasted incorrectly.

> It pops up the gksudo dialog, and then fails. But i don't get any stdout or
> stderror.

Fails how? Is there an error? Does it hang? Does nothing happen at all?

My initial thought is that you might want to try using
Popen.communicate instead of stdout.read in case you're getting
deadlocked. See the big red warning below
https://docs.python.org/3/library/subprocess.html#subprocess.Popen.stdout
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why doesn't Python include non-blocking keyboard input function?

[BartC]

On 27/10/2016 19:09, BartC wrote:

On 27/10/2016 17:13, Steve D'Aprano wrote:

On Fri, 28 Oct 2016 12:13 am, BartC wrote:



   print "Enter 3 numbers: "
   readln a,b,c


How is the interpreter supposed to know that a, b, c are numbers? What
sort
of numbers? 16-bit integers, 80-bit floats, Bignums, complex,
Fractions, or
something else?



But in a dynamically typed language, the compiler has no idea what you
expect a, b and c to be. So it returns text, and you can convert it
yourself.


I notice that when it comes to reading command-line arguments, then 
Python's sys.argv presents them as a list, not one long string.


And the list is just a series of strings, so needing to know whether any 
parameter was a number or whatever obviously wasn't a problem. It just 
makes each item into a string (actually that might be a better default 
than mine).


This is a very similar issue to reading items from a line of user input.

So why doesn't sys.argv just return a single string if a line is so easy 
to parse?


(That's exactly what Windows' WinMain() function does - optional entry 
point for executables under Windows. But C's main() entry point chops 
the command line up into separate strings like Python.


Also - this might some bearing on why Python does it that way - under 
Linux, a parameter such as *.py is replaced by the names of ALL the 
files that end in .py. (I was rather astonished when I find out. But 
I've recently had to deal with a directory containing 3,400,000 files so 
having a single "*" converted into 3.4 million filenames would be 
unwelcome.))


--
Bartc


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

Re: Why doesn't Python include non-blocking keyboard input function?

[Chris Angelico]

On Fri, Oct 28, 2016 at 9:02 AM, BartC  wrote:
>
> I notice that when it comes to reading command-line arguments, then Python's
> sys.argv presents them as a list, not one long string.
>
> And the list is just a series of strings, so needing to know whether any
> parameter was a number or whatever obviously wasn't a problem. It just makes
> each item into a string (actually that might be a better default than mine).
>
> This is a very similar issue to reading items from a line of user input.
>
> So why doesn't sys.argv just return a single string if a line is so easy to
> parse?

Because the OS provides a series of strings, not just one string. When
you exec to a process, you provide multiple arguments, not a single
combined string.

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

Installing Python on Windows 7

[Karen Hermann]

I just downloaded Python 3.5.2 for Windows, which I installed on a Windows 7 
laptop.  Disclaimer up front, I am a former lapsed programmer that has been 
away from it and all things Windows since Windows XP.  :)I’m back to being 
a bit of a newbie again.  

It’s a relatively clean laptop, just got it, and rarely use it, and there’s 
nothing else on it except Microsoft Office 2013.  I downloaded Python, 
installed it, tried to run it, and got this message:   The program can’t start 
because api-ms-win-crd-runtime-l1-1-0.dll is missing from your computer.  Try 
reinstalling the program to fix this problem. 

I’ve redownloaded it and reinstalled it several times, each time deleting all 
traces of it before trying again.  I’ve even disabled my virus-scanner 
(Sophos), thinking that might be interfering but that didn’t help either.  

Nothing is helping, I can’t get past this. 

Can you help please, is there something wrong with my system / setup, should I 
be downloading a different Python version?

Thanks in advance for any help you can give! 

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

Re: Why doesn't Python include non-blocking keyboard input function?

[BartC]

On 27/10/2016 23:31, Chris Angelico wrote:

On Fri, Oct 28, 2016 at 9:02 AM, BartC  wrote:


I notice that when it comes to reading command-line arguments, then Python's
sys.argv presents them as a list, not one long string.

And the list is just a series of strings, so needing to know whether any
parameter was a number or whatever obviously wasn't a problem. It just makes
each item into a string (actually that might be a better default than mine).

This is a very similar issue to reading items from a line of user input.

So why doesn't sys.argv just return a single string if a line is so easy to
parse?


Because the OS provides a series of strings, not just one string.


I don't think that's the case on Windows. Perhaps on Unix.

 When

you exec to a process, you provide multiple arguments, not a single
combined string.


Really, there could be dozens of arguments? Windows' CreateProcess() (if 
that's the same thing) has ten of which one is the command-line as a 
single string, while C's system() just has one.


This might just be one of those Unixisms that doesn't apply on all 
platforms.



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

Re: Installing Python on Windows 7

[eryk sun]

On Thu, Oct 27, 2016 at 10:10 PM, Karen Hermann  wrote:
>
> Can you help please, is there something wrong with my system / setup, should 
> I be
> downloading a different Python version?

The system is missing the new C runtime. Enable Windows Update and
install the recommended updates.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why doesn't Python include non-blocking keyboard input function?

[Chris Angelico]

On Fri, Oct 28, 2016 at 10:45 AM, BartC  wrote:
> On 27/10/2016 23:31, Chris Angelico wrote:
>>
>> When
>> you exec to a process, you provide multiple arguments, not a single
>> combined string.
>
>
> Really, there could be dozens of arguments? Windows' CreateProcess() (if
> that's the same thing) has ten of which one is the command-line as a single
> string, while C's system() just has one.

system() passes its argument through to the shell for parsing. In the
same way, Python's Popen constructor can either take a list of
strings, or a single string.

> This might just be one of those Unixisms that doesn't apply on all
> platforms.

Or maybe the single-string form is a Windowsism that doesn't apply on
any other platforms. Let me go dig up my OS/2 Assembly Language
Programming Reference...

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

Re: Why doesn't Python include non-blocking keyboard input function?

[BartC]

On 28/10/2016 01:08, Chris Angelico wrote:

On Fri, Oct 28, 2016 at 10:45 AM, BartC  wrote:

On 27/10/2016 23:31, Chris Angelico wrote:


When
you exec to a process, you provide multiple arguments, not a single
combined string.



Really, there could be dozens of arguments? Windows' CreateProcess() (if
that's the same thing) has ten of which one is the command-line as a single
string, while C's system() just has one.


system() passes its argument through to the shell for parsing. In the
same way, Python's Popen constructor can either take a list of
strings, or a single string.


This might just be one of those Unixisms that doesn't apply on all
platforms.


Or maybe the single-string form is a Windowsism that doesn't apply on
any other platforms. Let me go dig up my OS/2 Assembly Language
Programming Reference...


OK. What comes out of this is that single- or multi-string ways passing 
the contents of a line of input are both workable.


So perhaps my way of allowing more general line-input to be read an 
item-at-a-time instead of as a single string isn't that off-the-wall either.


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

Re: Why doesn't Python include non-blocking keyboard input function?

[Michael Torrie]

On 10/27/2016 04:07 AM, Terry Reedy wrote:
> As I and others have said, those keyboard functions are not available on 
> text terminals.  I predict that keyboard functions that so not work on 
> all systems will never become built-ins.  But some are available with an 
> import.

Sure you can't get a keyboard scancode when you're in terminal. But you
can get "keystrokes" as it were, without having to read an entire line
from standard in.  I use editors and programs all the time which are
interactive (they don't buffer keyboard input into lines) in the
terminal.  vim, nano, pico, mc, etc.

Is this not what BartC is talking about?  A way of reading in
"keystrokes" in a terminal.  Whether this is coming from a canned file
via a pipe or a real keyboard and screen attached to a TTY doesn't
really matter.  There are implementations of curses for the Windows
console, but I doubt they are supported by the python curses module.
But at least curses provides a means of doing this for programmers in a
unix environment.

For mostly nostalgic reasons I play around with the FreeBASIC compiler
and it tries to faithfully emulate the old key input that BASICs of yore
did. Such as inkey$ (which returns nothing if no keystroke is
available).  It runs more or less as advertised in a terminal window on
Linux, or the console on Windows. They even go so far as to emulate the
old MS-DOS keycodes for things like arrow keys so that old code can
still run faithfully.  I think this is the sort of thing BartC would
like to see in Python.  It's certainly possible, even on terminals, but
unlikely to happen for reasons that have been well-stated already by others.

> Python optionally comes with a sophisticated keyboard api.  The PSF 
> (python.org) CPython builds for Windows and Mac include that API.  On 
> Windows, so is the required tcl/tk build.  The premise of the subject 
> line, that Python does not include 'non-blocking keyboard input 
> functions', is not true.

I would think curses would provide the needed functionality without
tkinter or an X server.  It's limited in that only key combinations that
have control code representation can be detected, but you can definitely
use arrow keys, function keys, etc.  And I've seen curses interactive
games so I know they can be read without blocking the whole program.

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

Re: Why doesn't Python include non-blocking keyboard input function?

[Michael L Torrie]

On 10/27/2016 11:05 PM, Michael Torrie wrote:
> On 10/27/2016 04:07 AM, Terry Reedy wrote:
>> As I and others have said, those keyboard functions are not available on 
>> text terminals.  I predict that keyboard functions that so not work on 
>> all systems will never become built-ins.  But some are available with an 
>> import.

> Is this not what BartC is talking about?  

I see that BartC is wanting to detect keys like left shift and right
shift.  Even back in QB MS-DOS days when the program was running very
close to bare metal that wasn't possible using a QB construct.

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

Re: Why doesn't Python include non-blocking keyboard input function?

[Christian Gollwitzer]

Am 28.10.16 um 07:05 schrieb Michael Torrie:

On 10/27/2016 04:07 AM, Terry Reedy wrote:

As I and others have said, those keyboard functions are not available on
text terminals.  I predict that keyboard functions that so not work on
all systems will never become built-ins.  But some are available with an
import.


Sure you can't get a keyboard scancode when you're in terminal. But you
can get "keystrokes" as it were, without having to read an entire line
from standard in.  I use editors and programs all the time which are
interactive (they don't buffer keyboard input into lines) in the
terminal.  vim, nano, pico, mc, etc.

Is this not what BartC is talking about?  A way of reading in
"keystrokes" in a terminal.


You can do this, if you want, by setting the terminal to raw mode. On 
Linux and OSX you can call "stty" to do that which should not be too 
difficult. Then you need a second thread or switch to non-blocking I/O 
from stdin, maybe asyncio can do that. On Windows OTOH you have to 
switch to a whole different API instead of reading from a file descripor 
AFAIK.


I still believe that it is not a "basic functionality". You need it, if 
you want to program a text editor or similar thing, but without using a 
real GUI. This is a small niche. It is both easier and more functional 
to use a real GUI library.


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