[RELEASE] Python 3.8.0b2 is now available for testing

[Łukasz Langa]

After a few days of delay, but somewhat cutely timed with the US Independence 
Day, I present you Python 3.8.0b2:

https://www.python.org/downloads/release/python-380b2/ 


This release is the second of four planned beta release previews. Beta release 
previews are intended to give the wider community the opportunity to test new 
features and bug fixes and to prepare their projects to support the new feature 
release. The next pre-release of Python 3.8 will be 3.8.0b3, currently 
scheduled for 2019-07-29.

Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.8 during the beta phase and report issues found to the Python bug tracker 
 as soon as possible. While the release is planned to 
be feature complete entering the beta phase, it is possible that features may 
be modified or, in rare cases, deleted up until the start of the release 
candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and 
no code changes after 3.8.0rc1, the release candidate. To achieve that, it will 
be extremely important to get as much exposure for 3.8 as possible during the 
beta phase.

Please keep in mind that this is a preview release and its use is not 
recommended for production environments.

No more non-bugfixes allowed on the “3.8” branch

The time has come, team. Please help make Python 3.8 as stable as possible and 
keep all features not currently landed for Python 3.9. Don’t fret, it’ll come 
faster than you think.


- Ł


signature.asc
Description: Message signed with OpenPGP
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multiprocessing and memory management

[Thomas Jollans]

On 03/07/2019 18.37, Israel Brewster wrote:
> I have a script that benefits greatly from multiprocessing (it’s generating a 
> bunch of images from data). Of course, as expected each process uses a chunk 
> of memory, and the more processes there are, the more memory used. The amount 
> used per process can vary from around 3 GB (yes, gigabytes) to over 40 or 50 
> GB, depending on the amount of data being processed (usually closer to 10GB, 
> the 40/50 is fairly rare). This puts me in a position of needing to balance 
> the number of processes with memory usage, such that I maximize resource 
> utilization (running one process at a time would simply take WAY to long) 
> while not overloading RAM (which at best would slow things down due to swap). 
>
> Obviously this process will be run on a machine with lots of RAM, but as I 
> don’t know how large the datasets that will be fed to it are, I wanted to see 
> if I could build some intelligence into the program such that it doesn’t 
> overload the memory. A couple of approaches I thought of:
>
> 1) Determine the total amount of RAM in the machine (how?), assume an average 
> of 10GB per process, and only launch as many processes as calculated to fit. 
> Easy, but would run the risk of under-utilizing the processing capabilities 
> and taking longer to run if most of the processes were using significantly 
> less than 10GB
>
> 2) Somehow monitor the memory usage of the various processes, and if one 
> process needs a lot, pause the others until that one is complete. Of course, 
> I’m not sure if this is even possible.
>
> 3) Other approaches?
>

Are you familiar with Dask? 

I don't know it myself other than through hearsay, but I have a feeling
it may have a ready-to-go solution to your problem. You'd have to look
into dask in more detail than I have...


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

Re: Handle foreign character web input

[Peter J. Holzer]

On 2019-07-03 18:13:20 -0500, Igor Korot wrote:
> But as I said, imaging the following situation:
> 
> You are somewhere in Germany and you have a German version of OS
> (any OS)
> .
> You also have a German keyboard (hardware) with German keys.
> 
> Now you are assigned to go to some international events where people
> all over the world will be coming to your presentation and they will be
> registering on you machine
> 
> Also imagine that the company policy prohibits you from  modifying the
> system settings.
> 
> My solution:
> I would probably grab a lot of registering paper and ask people to enter
> English transliteration of the names on the machine so when you come
> back to the office you can properly enter their names using all those
> different keyboards (maybe virtual ones) to associate them with
> their English counterparts.
> 
> Just curious - what would you do?

I would set up a web registration form, so people can use their own
device (phone, laptop, whatever) to enter their name. Presumably they
know how to enter their name on their device. I definitely don't know
how to enter a hand-written (or even printed) Chinese name on any
keyboard (I managed to do that recently, but that was a lot of work and
way into "a fun challenge to do once, not something I want to repeat"
territory).

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's wrong on using Popen's communicate method?

[Terry Reedy]

On 7/3/2019 7:57 PM, jf...@ms4.hinet.net wrote:

I have the test0.py below. I expect to see 'abcd' showing in the notepad window:
-
import subprocess as sp
p0 = sp.Popen('notepad.exe', stdin=sp.PIPE)
p0.communicate(input=b'abcd')
-
But nothing happens. The notepad is completely empty. What have I missed?

--Jach

PS. I am using python 3.4 on Windows Vista


Upgrade to 3.7 or 3.8 to get hundreds of bug fixes, let alone new 
features.  Both subprocess and multiprocessing have gotten fixes.


subprocess is meant for running an external program in batch mode.  It 
receives the one input byte string, sends output, and closes.  For 
interaction, try multiprocessing.


Or do what IDLE does, which is to open a two-way socket to the parent 
program.  (Managing this is not fun.)  IDLE was initially written before 
multiprocessing.  It has been suggested to me that it should switch to 
multiprocessing.  (But last I read, multiprocessing and tkinter (tcl/tk) 
do not play well together on macOS.)


If the subprocess runs a gui, the user should be able to switch focus by 
clicking on a subprocess window.



--
Terry Jan Reedy

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