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

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?

[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

[issue28353] os.fwalk() unhandled exception when error occurs accessing symbolic link target

[Xiang Zhang]

Xiang Zhang added the comment:

Serhiy, after your commits, test_os requires root privileges or it'll fail. 
This is not the case before.

[cpython]$ ./python -m test test_os
Run tests sequentially
0:00:00 [1/1] test_os
test test_os crashed -- Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/libregrtest/runtest.py", line 164, in 
runtest_inner
test_runner()
  File "/home/angwer/cpython/Lib/test/libregrtest/runtest.py", line 163, in 
test_runner
support.run_unittest(tests)
  File "/home/angwer/cpython/Lib/test/support/__init__.py", line 1849, in 
run_unittest
_run_suite(suite)
  File "/home/angwer/cpython/Lib/test/support/__init__.py", line 1824, in 
_run_suite
raise TestFailed(err)
test.support.TestFailed: multiple errors occurred; run in verbose mode for 
details

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/libregrtest/runtest.py", line 167, in 
runtest_inner
test_time = time.time() - start_time
  File "/home/angwer/cpython/Lib/test/libregrtest/save_env.py", line 278, in 
__exit__
restore(original)
  File "/home/angwer/cpython/Lib/test/libregrtest/save_env.py", line 235, in 
restore_files
support.rmtree(fn)
  File "/home/angwer/cpython/Lib/test/support/__init__.py", line 377, in rmtree
_rmtree(path)
  File "/home/angwer/cpython/Lib/shutil.py", line 474, in rmtree
_rmtree_safe_fd(fd, path, onerror)
  File "/home/angwer/cpython/Lib/shutil.py", line 412, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/home/angwer/cpython/Lib/shutil.py", line 412, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/home/angwer/cpython/Lib/shutil.py", line 408, in _rmtree_safe_fd
onerror(os.open, fullname, sys.exc_info())
  File "/home/angwer/cpython/Lib/shutil.py", line 406, in _rmtree_safe_fd
dirfd = os.open(name, os.O_RDONLY, dir_fd=topfd)
PermissionError: [Errno 13] Permission denied: 'SUB21'

'test_os' left behind directory '@test_23400_tmp' and it couldn't be removed: 
[Errno 13] Permission denied: 'SUB21'
test_os failed

1 test failed:
test_os

Total duration: 292 ms
Tests result: FAILURE
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/support/__init__.py", line 914, in 
temp_dir
yield path
  File "/home/angwer/cpython/Lib/test/support/__init__.py", line 963, in 
temp_cwd
yield cwd_dir
  File "/home/angwer/cpython/Lib/test/libregrtest/main.py", line 468, in main
self._main(tests, kwargs)
  File "/home/angwer/cpython/Lib/test/libregrtest/main.py", line 497, in _main
sys.exit(len(self.bad) > 0 or self.interrupted)
SystemExit: True

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/home/angwer/cpython/Lib/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/home/angwer/cpython/Lib/test/__main__.py", line 2, in 
main()
  File "/home/angwer/cpython/Lib/test/libregrtest/main.py", line 532, in main
Regrtest().main(tests=tests, **kwargs)
  File "/home/angwer/cpython/Lib/test/libregrtest/main.py", line 468, in main
self._main(tests, kwargs)
  File "/home/angwer/cpython/Lib/contextlib.py", line 100, in __exit__
self.gen.throw(type, value, traceback)
  File "/home/angwer/cpython/Lib/test/support/__init__.py", line 963, in 
temp_cwd
yield cwd_dir
  File "/home/angwer/cpython/Lib/contextlib.py", line 100, in __exit__
self.gen.throw(type, value, traceback)
  File "/home/angwer/cpython/Lib/test/support/__init__.py", line 917, in 
temp_dir
rmtree(path)
  File "/home/angwer/cpython/Lib/test/support/__init__.py", line 377, in rmtree
_rmtree(path)
  File "/home/angwer/cpython/Lib/shutil.py", line 474, in rmtree
_rmtree_safe_fd(fd, path, onerror)
  File "/home/angwer/cpython/Lib/shutil.py", line 412, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/home/angwer/cpython/Lib/shutil.py", line 412, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/home/angwer/cpython/Lib/shutil.py", line 412, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/home/angwer/cpython/Lib/shutil.py", line 408, in _rmtree_safe_fd
onerror(os.open, fullname, sys.exc_info())
  File "/home/angwer/cpython/Lib/shutil.py", line 406, in _rmtree_safe_fd
dirfd = os.open(name, os.O_RDONLY, dir_fd=topfd)
PermissionError: [Errno 13] Permission denied: 'SUB21'

--
nosy: +xiang.zhang
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 

[issue28544] Implement asyncio.Task in C

[Yury Selivanov]

Yury Selivanov added the comment:

> - and `tasks.py` imports `futures.py` to have `isfuture`.

And tasks.py also imports coroutines.py (which was importing futures.py), 
making the cycle even worse.  Anyways, I don't see a problem in moving a 
function or two that everybody uses into a separate module.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Yury Selivanov]

Yury Selivanov added the comment:

> Why isfuture() is moved, and asyncio.coroutine uses
> base_futures.isfuture() instead of futures.isfuture()?

Import cycles: 

- `_asyncio` module is now being imported from `futures.py`
- and `_asyncio` is now imported from `tasks.py`; 
- and `tasks.py` imports `futures.py` to have `isfuture`.

Long story short, I don't see a way of keeping `isfuture` in `futures.py`.  The 
easiest option is to have it in a separate module.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[INADA Naoki]

INADA Naoki added the comment:

Why isfuture() is moved, and asyncio.coroutine uses
base_futures.isfuture() instead of futures.isfuture()?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Yury Selivanov]

Yury Selivanov added the comment:

Uploading a new patch: sorted imports; added a unittest that exceptions in 
loop.call_soon aren't breaking Task.__init__.

--
Added file: http://bugs.python.org/file45248/ctask3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28088] Document Transport.set_protocol and get_protocol

[INADA Naoki]

INADA Naoki added the comment:

LGTM

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28088] Document Transport.set_protocol and get_protocol

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

I added a note like this. 


.. note::
   Switching protocol should only be done when both protocols are
   documented to support the switch.


Would this work? Would appreciate any feedback of how to properly document this 
behavior.

Thanks.

--
Added file: http://bugs.python.org/file45247/issue28088v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28531] Improve utf7 encoder memory usage

[Xiang Zhang]

Xiang Zhang added the comment:

Actually the patch is not going to speed up the encoder but just make the 
memory allocation strategy better, make the memory upper bound tighter. The 
speedup is just a good side effect. 

> It is rather in the line of idna and punycode than UTF-8 and UTF-32.

Agree.

> This encoder was omitted form _PyBytesWriter-using optimizations for purpose. 
> The patch complicates the implementation.

Not much. I think the implementation still remains simple.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28541] Improve test coverage for json library - loading bytes

[Eric Appelt]

Eric Appelt added the comment:

Thanks for the feedback. I agree that the comment is incorrect for several 
iterations of the loop that really don't need to be tested at all for '5'. I 
read the previous issue 17909 more carefully along with RFC 4627, 7159, and 
EMCA 404 to properly understand the context here.

I notice that although the issue 17909 patch was written in order to implement 
the patterns in RFC 4627, it is also valid for the additional pattern 
introduced for utf-16-le in RFC 7159 as described in [1].

Specifically, in RFC 4627 the only valid pattern for utf-16-le begins with XX 
00 XX 00 since the first two characters must represent ASCII codepoints. With 
strings the second character can be higher codepoints allowing for XX 00 XX XX 
or XX 00 00 XX. In the implementation from issue 17909 the pattern XX 00 XX is 
first detected and results in utf-16-le, and then the 4th byte is checked for 
the pattern XX 00 00 XX or XX 00 00 00 to result in utf-16-le or utf-32 
respectively.

In the issue 17909 patch the special case of a single character JSON document 
(i.e. '5') is also specifically accounted for. This case is not mentioned in 
[1].

So for everything I can try (or think of), this implementation can correctly 
determine the encoding of any valid JSON document according to RFC 7159. This 
is good since the documentation [2] makes no distinction that json.loads() 
would only accept JSON documents in bytes if they adhere to 4627.

The encoding failure mode described in issue 17909 is still an invalid JSON 
document according to RFC 7159 as the control character \u is not escaped.

So I think overall the implementation is perfectly valid for RFC 7159 / EMCA 
404 as suggested by the standard library documentation [2].

To me it seems reasonable to have a unit test to specifically check that the 
pattern XX 00 00 XX works. For the goal of hitting 100% test coverage as 
measured by line, I believe that the 2-byte case still needs to be tested.

I have attached a patch that covers these cases along with (maybe too) verbose 
comments explaining the edge cases. I also changed the comments in the 
json/__init__.py module itself to clarify the detection patterns as implemented.

I'm not sure how helpful this is to the improvement in of the standard library, 
but it has been very educational to be so far.

[1] http://www.ietf.org/mail-archive/web/json/current/msg01959.html
[2] https://docs.python.org/3.7/library/json.html

--
Added file: http://bugs.python.org/file45246/mywork3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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?

[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: 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?

[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

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?

[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

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: 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?

[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

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Steve Dower]

Steve Dower added the comment:

Fixed and added a test. (Yes I know that it's not the most efficient algorithm 
for joining the strings together, but I consider correctness to be more 
important here.)

--
stage: needs patch -> commit review
type:  -> crash
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Roundup Robot]

Roundup Robot added the comment:

New changeset eea669163131 by Steve Dower in branch '3.6':
Issue #28522: Fixes mishandled buffer reallocation in getpathp.c
https://hg.python.org/cpython/rev/eea669163131

New changeset 72e64fc8746b by Steve Dower in branch 'default':
Issue #28522: Fixes mishandled buffer reallocation in getpathp.c
https://hg.python.org/cpython/rev/72e64fc8746b

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Yury Selivanov]

Yury Selivanov added the comment:

Guido, Ned, thanks!  Andrew already glanced through the code, let's see what 
Inada-san says.

I'm uploading an updated patch addressing Andrew's review.

--
Added file: http://bugs.python.org/file45245/ctask2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Ned Deily]

Ned Deily added the comment:

I also trust Yury to do the right thing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Guido van Rossum]

Guido van Rossum added the comment:

I don't want to be the decider here. I don't have time to review the
code. I trust you all to do the right thing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue22949] fnmatch.translate doesn't add ^ at the beginning

[Roundup Robot]

Roundup Robot added the comment:

New changeset a1aef5f84142 by Serhiy Storchaka in branch '3.5':
Issue #22949: Documented that fnmatch.translate() is for use with re.match().
https://hg.python.org/cpython/rev/a1aef5f84142

New changeset 8a564ab1d208 by Serhiy Storchaka in branch '2.7':
Issue #22949: Documented that fnmatch.translate() is for use with re.match().
https://hg.python.org/cpython/rev/8a564ab1d208

New changeset dfda2f33fd08 by Serhiy Storchaka in branch '3.6':
Issue #22949: Documented that fnmatch.translate() is for use with re.match().
https://hg.python.org/cpython/rev/dfda2f33fd08

New changeset d103ee917342 by Serhiy Storchaka in branch 'default':
Issue #22949: Documented that fnmatch.translate() is for use with re.match().
https://hg.python.org/cpython/rev/d103ee917342

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22949] fnmatch.translate doesn't add ^ at the beginning

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22493] Deprecate the use of flags not at the start of regular expression

[Roundup Robot]

Roundup Robot added the comment:

New changeset c04a56b3a4f2 by Serhiy Storchaka in branch '3.6':
Issue #22493: Updated an example for fnmatch.translate().
https://hg.python.org/cpython/rev/c04a56b3a4f2

New changeset ded9a3c3bbb6 by Serhiy Storchaka in branch 'default':
Issue #22493: Updated an example for fnmatch.translate().
https://hg.python.org/cpython/rev/ded9a3c3bbb6

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28212] Closing server in asyncio is not efficient

[Andrew Svetlov]

Andrew Svetlov added the comment:

>From my perspective the problem is: many asyncio calls schedules a delayed 
>activity internally.
E.g. `task.cancel()` doesn't cancels immediately but requires at least one 
extra loop iteration.
The same is true for `transport.close()` -- it doesn't close socket in the call.
This behavior is encouraged by asyncio design and many third-party libraries 
just call `transp.close()` without waiting for upcoming 
`protocol.connection_lost()` callback.

I don't think it's a big problem, especially for server code.
But when users write small client tool they need to do extra no-op loop 
iterations before `loop.close()` call.

Waiting for no scheduled by `loop.call_soon()` callbacks makes no sense I 
believe. I could open a can of worms by introducing another weird side effects.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Andrew Svetlov]

Andrew Svetlov added the comment:

Very impressive.
I've left a couple comments in rietveld though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Steve Dower]

Steve Dower added the comment:

It's a genuine bug in path processing, specifically how we handle buffer 
resizing. I'll make a fix.

--
assignee:  -> steve.dower
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28496] Mark up constants 0, 1, -1 in C API docs

[Roundup Robot]

Roundup Robot added the comment:

New changeset e90fe2209276 by Serhiy Storchaka in branch '2.7':
Issue #28496: Mark up constants 0, 1 and -1 that denote return values or
https://hg.python.org/cpython/rev/e90fe2209276

New changeset 04065efd7747 by Serhiy Storchaka in branch '3.5':
Issue #28496: Mark up constants 0, 1 and -1 that denote return values or
https://hg.python.org/cpython/rev/04065efd7747

New changeset de00be368f0b by Serhiy Storchaka in branch '3.6':
Issue #28496: Mark up constants 0, 1 and -1 that denote return values or
https://hg.python.org/cpython/rev/de00be368f0b

New changeset e19f2428b15a by Serhiy Storchaka in branch 'default':
Issue #28496: Mark up constants 0, 1 and -1 that denote return values or
https://hg.python.org/cpython/rev/e19f2428b15a

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28545] socket.bind to AF_PACKET should use passed interface name

[Martin Turon]

Martin Turon added the comment:

Just for clarity, the high level bug is that when binding to an interface using 
AF_PACKET, transmissions work, but receive does not:

sock = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, ETH_P_IEEE802154)
sock.bind(("monitor0", ETH_P_IEEE802154))

sock.send(test_frame)   # transmission works fine
pkt = sock.recv(127)# never receives, though C test works fine

The same test written in C that calls ioctl(sockfd, SIOCGIFNAME, ) to 
lookup ifindex for bind from ifname="monitor0" works fine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28496] Mark up constants 0, 1, -1 in C API docs

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Ned Deily]

Ned Deily added the comment:

If it's OK with Guido, it's OK with me for 360b3. (That's Monday.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28528] Pdb.checkline()

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
nosy: +xdegaye

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28426] PyUnicode_AsDecodedObject can only return unicode now

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks Xiang.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28545] socket.bind to AF_PACKET should use passed interface name

[Martin Turon]

New submission from Martin Turon:

When binding to AF_PACKET linux kernel sockets, the interface name is not 
passed in when given -- it is always "".  This causes problems, for example, 
receiving packets to a "monitor0" interface doesn't work.

diff -r a6548e230ed6 Modules/socketmodule.c
--- a/Modules/socketmodule.cThu Oct 27 19:33:22 2016 +0300
+++ b/Modules/socketmodule.cThu Oct 27 11:13:12 2016 -0700
@@ -1344,6 +1344,7 @@
 {
 struct sockaddr_ll *a = (struct sockaddr_ll *)addr;
 char *ifname = "";
+// ^^ ifname should be set to interface name passed in via sockaddr.
 struct ifreq ifr;
 /* need to look up interface name give index */
 if (a->sll_ifindex) {

--
messages: 279558
nosy: mturon
priority: normal
severity: normal
status: open
title: socket.bind to AF_PACKET should use passed interface name

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue28426] PyUnicode_AsDecodedObject can only return unicode now

[Roundup Robot]

Roundup Robot added the comment:

New changeset 15a494886c5a by Serhiy Storchaka in branch '3.6':
Issue #28426: Deprecated undocumented functions PyUnicode_AsEncodedObject(),
https://hg.python.org/cpython/rev/15a494886c5a

New changeset 50c28727d91c by Serhiy Storchaka in branch 'default':
Issue #28426: Deprecated undocumented functions PyUnicode_AsEncodedObject(),
https://hg.python.org/cpython/rev/50c28727d91c

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28531] Improve utf7 encoder memory usage

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The performance of the UTF-7 codec is not important. Unlikely to other UTF-* 
encodings this is not standard Unicode encoding. It is used in minority of 
applications and unlikely is a bottleneck. It is rather in the line of idna and 
punycode than UTF-8 and UTF-32. Actually I'm going to propose replacing it with 
Python implementation.

This encoder was omitted form _PyBytesWriter-using optimizations for purpose. 
The patch complicates the implementation. Since the codec is rarely used some 
bugs lived long time in it. Any change risks to add new long living bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception

[Mark Dickinson]

Mark Dickinson added the comment:

Actually, here's a patch.

--
keywords: +patch
Added file: http://bugs.python.org/file45244/math-degrees-overflow.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Yury Selivanov]

Yury Selivanov added the comment:

> Yury, would you like to merge this before 3.6b3?

Yes!

> I'll look this as soon as possible.

Thanks a lot!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[INADA Naoki]

INADA Naoki added the comment:

Wow! Great Job!
Yury, would you like to merge this before 3.6b3?
I'll look this as soon as possible.

(nit fix) Some modules doesn't sort imports in lexicography.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Big Stone]

Big Stone added the comment:

maybe click on the "WinPython Command Prompt.exe" and do "pip uninstall IDLEX" 
as a first step. so you should see IDLE working

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Big Stone]

Big Stone added the comment:

hi Steve,

You can grab it there 
https://sourceforge.net/projects/winpython/files/WinPython_3.6/3.6.0.0/betas/WinPython-64bit-3.6.0.0Zerorc2.exe/download
 MD5 | SHA-1| 
SHA-256  | Binary   
   | Size  
-|--|--|-|---
dd946ed17ee86ea035361d2e757a1cc1 | f0ec7ffac477a220dd24aea3fb70afaba579df00 | 
af6536f1922a044ac74300efcd275c9e25c5eb56140ded84a99f11d38ae5ac7b | 
WinPython-64bit-3.6.0.0Zerorc2.exe |   24 196 083 Bytes
dabae69ad09e1646625d3a8995a75056 | aaece4907096422c1df78f80a42a2268369d7697 | 
0d530b84f29481e7f03e4615c9da489711ca6883b49996219d9cd13aa5393330 | 
WinPython-64bit-3.6.0.0rc2.exe  |  208 255 944 Bytes

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28531] Improve utf7 encoder memory usage

[Xiang Zhang]

Xiang Zhang added the comment:

v2 uses _PyBytesWriter so we can use on stack buffer for short string.

--
Added file: http://bugs.python.org/file45243/utf7_encoder_v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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

[issue28544] Implement asyncio.Task in C

[Yury Selivanov]

Yury Selivanov added the comment:

Also, with this patch uvloop becomes ~3-5% faster too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Elvis Pranskevichus]

Changes by Elvis Pranskevichus :


--
nosy: +Elvis.Pranskevichus

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28526] Use PyUnicode_AsEncodedString instead of PyUnicode_AsEncodedObject

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for your review Josh.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28526] Use PyUnicode_AsEncodedString instead of PyUnicode_AsEncodedObject

[Roundup Robot]

Roundup Robot added the comment:

New changeset bea48e72cae5 by Serhiy Storchaka in branch '3.5':
Issue #28526: Use PyUnicode_AsEncodedString() instead of
https://hg.python.org/cpython/rev/bea48e72cae5

New changeset fe9f361f3751 by Serhiy Storchaka in branch '3.6':
Issue #28526: Use PyUnicode_AsEncodedString() instead of
https://hg.python.org/cpython/rev/fe9f361f3751

New changeset a6548e230ed6 by Serhiy Storchaka in branch 'default':
Issue #28526: Use PyUnicode_AsEncodedString() instead of
https://hg.python.org/cpython/rev/a6548e230ed6

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28544] Implement asyncio.Task in C

[Yury Selivanov]

New submission from Yury Selivanov:

The attached patch implements asyncio.Task in C.  Besides that, it also 
implements Argument Clinic for C Future.

Performance improvement on a simple echo server implementation using 
asyncio.streams:

Python Future & Task   |   C Future & Py Task   |   C Future & C Task
  23K req/s|   26K  |  30K
   |  ~10-15% boost | ~15%

Both Task and Future implemented in C, make asyncio programs up to 25-30% 
faster.

The patch is 100% backwards compatible.  I modified asyncio tests to cross test 
Tasks and Futures implementations, i.e. to run Task+Future, Task+CFuture, 
CTask+Future, CTask+CFuture tests.  No refleaks or other bugs.  All uvloop 
functional tests pass without any problem.

Ned, Guido, are you OK if I merge this in 3.6 before beta 3?  I'm confident 
that the patch is stable and even if something comes up we have time to fix it 
or even retract the patch.  The performance boost is very impressive, and I can 
also make uvloop simpler.

--
assignee: yselivanov
components: asyncio
files: ctask.patch
keywords: patch
messages: 279546
nosy: asvetlov, gvanrossum, haypo, inada.naoki, ned.deily, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Implement asyncio.Task in C
type: performance
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45242/ctask.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23262] webbrowser module broken with Firefox 36+

[Oleg Broytman]

Oleg Broytman added the comment:

Then I don't have any objections. But I also couldn't test the change — I only 
use Firefox (and sometimes Chrome).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23262] webbrowser module broken with Firefox 36+

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Currently Netscape is just an alias to Mozilla. Since SeaMonkey is synchronized 
with Firefox, I suppose it dropped the support of the -remote option at the 
same time. Debian rebranded Firefox and SeaMonkey at 2006, therefore IceWeasel 
and IceApe always supported -new-win and -new-tab options. The last IceWeasel 
version was 38, it didn't supported the -remote option.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

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
>>> 

[issue28541] Improve test coverage for json library - loading bytes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The patch in issue17909 was written to implement encoding detecting described 
in RFC 4627 [1]. And the test uses RFC 4627 conforming data. A single codepoint 
"5" is not valid in RFC 4627, but is valid in RFC 7159 [2].

The comment in your patch is not accurate since '5' is encoded to 1 byte with 
utf-8 and 4 bytes with utf-32*.

[1] https://tools.ietf.org/html/rfc4627
[2] https://tools.ietf.org/html/rfc7159

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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: 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: 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

[issue28401] Don't support the PEP384 stable ABI in pydebug builds

[Stefano Rivera]

Stefano Rivera added the comment:

I wouldn't say it's *entirely* Debian-specific. It just bites anyone who 
actually needs these tags to differentiate between built extensions. (Mostly 
Debian)

Yes, changing the tag is a more complete solution. It just seemed that that 
option was decided against, in the relevant PEPs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28401] Don't support the PEP384 stable ABI in pydebug builds

[Matthias Klose]

Matthias Klose added the comment:

I'm not sure that you really want this, because it would make it impossible to 
build an extension for the stable ABI for a debug build.  The problem is Debian 
specific, because we install the extension modules for normal and debug builds 
in the same location.  A Debian solution would be to use a different soname for 
stable API debug mode extensions.

--
nosy: +doko

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue23262] webbrowser module broken with Firefox 36+

[Oleg Broytman]

Oleg Broytman added the comment:

I'd rather rename the new class to something like Firefox. So there will be 3 
classes — Netscape, Mozilla and Firefox. Firefox only for firefox executable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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: 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

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

[issue28542] document cross compilation

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
components: +Cross-Build, Documentation
nosy: +Alex.Willmer

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Steve Dower]

Steve Dower added the comment:

I suspect there's a .pth file in site-packages that is importing something to 
trigger the failure. Without a crash dump (or debug build) it's going to be 
difficult to find it, but it is certainly an unwrapped invalid parameter 
termination.

To save me some time, where can I get that build of WinPython from?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue28543] Incomplete fast path codecs aliases in codecs doc

[Xiang Zhang]

New submission from Xiang Zhang:

The fast path codec aliases in codecs doc is complete especially after 
99818330b4c0.

--
assignee: docs@python
components: Documentation
files: codecs_doc.patch
keywords: patch
messages: 279538
nosy: docs@python, haypo, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Incomplete fast path codecs aliases in codecs doc
type: enhancement
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45241/codecs_doc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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: 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?

[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: 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?

[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)

[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: 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

[issue28541] Improve test coverage for json library - loading bytes

[Eric Appelt]

Eric Appelt added the comment:

I looked back and something is clearly wrong with my coverage reporting setup, 
sorry :(

When I move the test introduced in issue 17909, 'test_bytes_decode' from the 
module Lib/test/test_json/test_unicode.py to Lib/test/test_json/test_decode.py 
that particular test is properly traced and I see that the function is mostly 
covered, so I need to figure out what is going wrong in my setup.

The test already present is more comprehensive as it includes BOM, so I believe 
what I wrote is generally not helpful.

I did notice that the existing test does not cover the edge-case of a 2-byte 
utf-16 sequence that can be generated for a valid JSON object represented by a 
single codepoint, for example '5' or '7'. I created a new patch to augment the 
existing test to cover this special case rather than adding a test.

--
Added file: http://bugs.python.org/file45240/mywork2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception

[Mark Dickinson]

Mark Dickinson added the comment:

Francisco: would you be interested in writing a patch?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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)

[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

[issue28540] math.degrees(sys.float_info.max) should throw an OverflowError exception

[Mark Dickinson]

Mark Dickinson added the comment:

I agree in principle.

On one hand, it's difficult to care too much, since `math.degrees` is going to 
be all-but-useless for inputs larger than `1e20` or so anyway (the actual angle 
represented is getting lost in floating-point noise by that point).

OTOH, *because* of the above, at least making the change shouldn't break any 
code that wasn't broken already.

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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)

[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: 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: 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: 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?

[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?

[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: 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=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

[issue28509] dict.update allocates too much

[INADA Naoki]

Changes by INADA Naoki :


--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28509] dict.update allocates too much

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8c2615decd2e by INADA Naoki in branch '3.6':
Issue #28509: dict.update() no longer allocate unnecessary large memory
https://hg.python.org/cpython/rev/8c2615decd2e

New changeset deb3e5857d8c by INADA Naoki in branch 'default':
Issue #28509: dict.update() no longer allocate unnecessary large memory
https://hg.python.org/cpython/rev/deb3e5857d8c

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue28444] Missing extensions modules when cross compiling python 3.5.2 for arm on Linux

[Xavier de Gaye]

Xavier de Gaye added the comment:

New patch taking into account Martin last review and some updated comments.

>> Why do you remove the code that loops over Modules/Setup? Maybe is it 
>> redundant with the other code for removing the already-built-in modules?
> Yes because this is redundant, maybe not the case when this was written 15 
> years ago.

* sys.builtin_module_names are the modules listed in the _PyImport_Inittab[] 
array that is built by Modules/makesetup from Modules/config.c.in and the 
'*static*' modules configured in the Setup files (those Setup files that are 
listed in the rule of the 'Makefile' target of the Makefile).  This list is 
missing the '*shared*' modules configured in the Setup files and that should 
not be built by setup.py.
* The setup.py code that loops over and loosely parses some of the 
Modules/Setup files, excludes both '*static*' and '*shared*' modules from the 
built modules.
* 'MODNAMES' does the same thing in the patch accurately as the list is built 
by makesetup.

New issue 28542 to document the cross-compilation.

--
Added file: http://bugs.python.org/file45239/removed_modules_3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com