Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

[Eric V. Smith]

> On Oct 12, 2018, at 7:03 PM, Martin Panter  wrote:
> 
>> On 12/10/2018, Eric V. Smith  wrote:
>>> On 10/12/2018 5:17 AM, Tal Einat wrote:
>>> 
>>>  The latest stable releases can always be found on the `Python download page
>>> -`_.  There are two recommended 
>>> production-ready
>>> -versions at this point in time, because at the moment there are two 
>>> branches of
>>> -stable releases: 2.x and 3.x.  Python 3.x may be less useful than 2.x, 
>>> since
>>> -currently there is more third party software available for Python 2 than 
>>> for
>>> -Python 3.  Python 2 code will generally not run unchanged in Python 3.
>>> +`_.  There are two production-ready 
>>> version
>>> +of Python: 2.x and 3.x, but the recommended one at this times is Python 
>>> 3.x.
>> 
>> This should be "time", not "times". I'd fix it, but I'm unsure if this
>> is being backported or not, and I don't want to mess up any merges
>> before they're done.
> 
> Or just remove “at this time[s]”; it doesn’t add much.
> 
> Also, “two . . . version” should be changed back to plural: “two . . .
> versions”.

See https://github.com/python/cpython/pull/9821 for some updates. 

Eric 

> 
>> I do think this should backported to 3.7, 3.6, and 2.7.
>> 
>>> +Although Python 2.x is still widely used, `it will not be
>>> +maintained after January 1, 2020
>>> `_.
>>> +Python 2.x was known for having more third-party libraries available,
>>> however,
>>> +by the time of this writing, most of the widely used libraries support
>>> Python 3.x,
>> 
>> Should probably be "at the time of this writing".
>> 
>>> +and some are even dropping the Python 2.x support.
>> 
>> And this would read better as "are even dropping support for Python 2.x".
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

[Martin Panter]

On 12/10/2018, Eric V. Smith  wrote:
> On 10/12/2018 5:17 AM, Tal Einat wrote:
>
>>   The latest stable releases can always be found on the `Python download page
>> -`_.  There are two recommended 
>> production-ready
>> -versions at this point in time, because at the moment there are two 
>> branches of
>> -stable releases: 2.x and 3.x.  Python 3.x may be less useful than 2.x, since
>> -currently there is more third party software available for Python 2 than for
>> -Python 3.  Python 2 code will generally not run unchanged in Python 3.
>> +`_.  There are two production-ready 
>> version
>> +of Python: 2.x and 3.x, but the recommended one at this times is Python 3.x.
>
> This should be "time", not "times". I'd fix it, but I'm unsure if this
> is being backported or not, and I don't want to mess up any merges
> before they're done.

Or just remove “at this time[s]”; it doesn’t add much.

Also, “two . . . version” should be changed back to plural: “two . . .
versions”.

> I do think this should backported to 3.7, 3.6, and 2.7.
>
>> +Although Python 2.x is still widely used, `it will not be
>> +maintained after January 1, 2020
>> `_.
>> +Python 2.x was known for having more third-party libraries available,
>> however,
>> +by the time of this writing, most of the widely used libraries support
>> Python 3.x,
>
> Should probably be "at the time of this writing".
>
>> +and some are even dropping the Python 2.x support.
>
> And this would read better as "are even dropping support for Python 2.x".
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Nathaniel Smith]

On Fri, Oct 12, 2018, 06:09 Antoine Pitrou  wrote:

> On Fri, 12 Oct 2018 08:33:32 -0400
> Sean Harrington  wrote:
> > Hi Nathaniel - this if this solution can be made performant, than I would
> > be more than satisfied.
> >
> > I think this would require removing "func" from the "task tuple", and
> > storing the "func" "once per worker" somewhere globally (maybe a class
> > attribute set post-fork?).
> >
> > This also has the beneficial outcome of increasing general performance of
> > Pool.map and friends. I've seen MANY folks across the interwebs doing
> > things like passing instance methods to map, resulting in "big" tasks,
> and
> > slower-than-sequential parallelized code. Parallelizing "instance
> methods"
> > by passing them to map, w/o needing to wrangle with staticmethods and
> > globals, would be a GREAT feature! It'd just be as easy as:
> >
> > Pool.map(self.func, ls)
> >
> > What do you think about this idea? This is something I'd be able to take
> > on, assuming I get a few core dev blessings...
>
> Well, I'm not sure how it would work, so it's difficult to give an
> opinion.  How do you plan to avoid passing "self"?  By caching (by
> equality? by identity?)?  Something else?  But what happens if "self"
> changed value (in the case of a mutable object) in the parent?  Do you
> keep using the stale version in the child?  That would break
> compatibility...
>

I was just suggesting that within a single call to Pool.map, it would be
reasonable optimization to only send the fn once to each worker. So e.g. if
you have 5 workers and 1000 items, you'd only pickle fn 5 times, rather
than 1000 times like we do now. I wouldn't want to get any fancier than
that with caching data between different map calls or anything.

Of course even this may turn out to be too complicated to implement in a
reasonable way, since it would require managing some extra state on the
workers. But semantically it would be purely an optimization of current
semantics.

-n

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2018-10-05 - 2018-10-12)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6824 (+10)
  closed 39893 (+49)
  total  46717 (+59)

Open issues with patches: 2721 


Issues opened (38)
==

#34908: netrc parsing is overly strict
https://bugs.python.org/issue34908  opened by ianwremmel

#34912: Update overflow checks in resize_buffer
https://bugs.python.org/issue34912  opened by Windson Yang

#34914: Clarify text encoding used to enable UTF-8 mode
https://bugs.python.org/issue34914  opened by ncoghlan

#34915: LWPCookieJar.save() creates *.lwp file in 644 mode
https://bugs.python.org/issue34915  opened by aleskva

#34916: include sqlite-3.25+ (with window functions)
https://bugs.python.org/issue34916  opened by Big Stone

#34918: Python 3 tkinter measurement problem
https://bugs.python.org/issue34918  opened by Ackbach

#34919: Crash caused by certain characters in a string
https://bugs.python.org/issue34919  opened by cwickens

#34920: PYTHONWARNINGS entries are escaped
https://bugs.python.org/issue34920  opened by nikratio

#34922: hashlib segmentation fault
https://bugs.python.org/issue34922  opened by shuoz

#34924: inspect.signature isn't aware that types.MethodType can wrap a
https://bugs.python.org/issue34924  opened by bup

#34927: Tkinter-related segfault on macOS (regression between 3.7.0 an
https://bugs.python.org/issue34927  opened by aivarannamaa

#34930: sha1module: Switch sha1 implementation to sha1dc/hardened sha1
https://bugs.python.org/issue34930  opened by antoine.pietri

#34931: os.path.splitext with more dots
https://bugs.python.org/issue34931  opened by xnovakj

#34932: Add macOS TCP_KEEPALIVE to available socket options
https://bugs.python.org/issue34932  opened by llawall

#34934: Consider making Windows select.select interruptible using WSAE
https://bugs.python.org/issue34934  opened by ondrej.kutal

#34936: tkinter.Spinbox.selection_element() raises TclError
https://bugs.python.org/issue34936  opened by j-4321-i

#34938: Fix mimetype.init() to account for from import
https://bugs.python.org/issue34938  opened by YoSTEALTH

#34939: Possibly spurious SyntaxError: annotated name can't be global
https://bugs.python.org/issue34939  opened by rohanpadhye

#34941: xml.etree.ElementTree findall() fails when using custom TreeBu
https://bugs.python.org/issue34941  opened by jackjansen

#34943: sched cancel (wrong item removed from queue)
https://bugs.python.org/issue34943  opened by ajneu

#34944: Update _dirnameW to accept long path names
https://bugs.python.org/issue34944  opened by jopamer

#34945: regression with ./python -m test and pdb
https://bugs.python.org/issue34945  opened by matrixise

#34946: inspect.getcallargs is marked as deprecated in documentation, 
https://bugs.python.org/issue34946  opened by chrisjbremner

#34947: inspect.getclosurevars() does not get all globals
https://bugs.python.org/issue34947  opened by azag0

#34948: Document __warningregister__
https://bugs.python.org/issue34948  opened by steven.daprano

#34949: ntpath.abspath no longer uses normpath
https://bugs.python.org/issue34949  opened by rhwlo

#34950: Parse trusted and signature information from X509 certificate
https://bugs.python.org/issue34950  opened by famendola

#34951: cookielib/cookiejar cookies' Expires date parse fails with lon
https://bugs.python.org/issue34951  opened by alb_moral

#34952: Problems with the warningregistry() decorator in Lib/unittest/
https://bugs.python.org/issue34952  opened by serhiy.storchaka

#34953: Implement `mmap.mmap.__repr__`
https://bugs.python.org/issue34953  opened by cool-RR

#34956: _tkinter built on macOS 10.14 does not link to Tcl and Tk in /
https://bugs.python.org/issue34956  opened by wordtech

#34957: Segementation faults on ARM and ARM64
https://bugs.python.org/issue34957  opened by stefanr...@yahoo.com

#34958: urllib.error.HTTPError.fp is not closed when error is finalize
https://bugs.python.org/issue34958  opened by puxlit

#34960: macOS builds expose stack_size option in LINKEDFOORSHARED and 
https://bugs.python.org/issue34960  opened by xzcvczx

#34961: Global scoping when shadowing local names in class definitions
https://bugs.python.org/issue34961  opened by multun

#34963: String representation for types created with typing.NewType(â€
https://bugs.python.org/issue34963  opened by fish2000

#34965: Python on Docker container using flask is going down after som
https://bugs.python.org/issue34965  opened by sri_spl

#34966: Pydoc: better support of method aliases
https://bugs.python.org/issue34966  opened by serhiy.storchaka



Most recent 15 issues with no replies (15)
==

#34966: Pydoc: better support of method aliases
https://bugs.python.org/issue34966

#34963: String representation for types created with typing.NewType(â€

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Antoine Pitrou]

Le 12/10/2018 à 16:49, Sean Harrington a écrit :
> Yes - “func” (and “self” which func is bound to) would be copied to each
> child worker process, where they are stored and applied to each element
> of the iterable being mapped over.

Only if it has changed, then, right?

I suspect that would work, but it will break compatibility in some cases
(think of a mutable object that hasn't defined equality - so it defaults
to identity).  It's also introducing a complication in the API which
people didn't have to think of before.

The fact that you're doing all this in order to eschew global variables
for global resources doesn't warm me much to the idea.  Unless other
core developers are enthusiastic I'm not willing to integrate such a change.

Regards

Antoine.


> On Fri, Oct 12, 2018 at 10:41 AM Antoine Pitrou  > wrote:
> 
> On Fri, 12 Oct 2018 09:42:50 -0400
> Sean Harrington mailto:seanhar...@gmail.com>>
> wrote:
> > I would contend that this is much more granular than Dask - this
> is just an
> > optimization of Pool.map() to avoid redundantly passing the same
> `func`
> > repeatedly, once per task, to each worker, with the primary goal of
> > eliminating redundant serialization of large-memory-footprinted
> Callables.
> > This is a different use case than Dask - I don't intend to
> approach the
> > shared memory or distributed computing realms.
> >
> > And the second call to Pool.map would update the cached "self" as
> a part of
> > its initialization workflow, s.t. "the latest version of self when
> map() is
> > called is taken into account".
> 
> I still don't understand how that works.  If you "updated the cached
> self", then surely you must transmit it to the child, right?
> 
> Regards
> 
> Antoine.
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org 
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/seanharr11%40gmail.com
> 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Sean Harrington]

Yes - “func” (and “self” which func is bound to) would be copied to each
child worker process, where they are stored and applied to each element of
the iterable being mapped over.
On Fri, Oct 12, 2018 at 10:41 AM Antoine Pitrou  wrote:

> On Fri, 12 Oct 2018 09:42:50 -0400
> Sean Harrington  wrote:
> > I would contend that this is much more granular than Dask - this is just
> an
> > optimization of Pool.map() to avoid redundantly passing the same `func`
> > repeatedly, once per task, to each worker, with the primary goal of
> > eliminating redundant serialization of large-memory-footprinted
> Callables.
> > This is a different use case than Dask - I don't intend to approach the
> > shared memory or distributed computing realms.
> >
> > And the second call to Pool.map would update the cached "self" as a part
> of
> > its initialization workflow, s.t. "the latest version of self when map()
> is
> > called is taken into account".
>
> I still don't understand how that works.  If you "updated the cached
> self", then surely you must transmit it to the child, right?
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/seanharr11%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Antoine Pitrou]

On Fri, 12 Oct 2018 09:42:50 -0400
Sean Harrington  wrote:
> I would contend that this is much more granular than Dask - this is just an
> optimization of Pool.map() to avoid redundantly passing the same `func`
> repeatedly, once per task, to each worker, with the primary goal of
> eliminating redundant serialization of large-memory-footprinted Callables.
> This is a different use case than Dask - I don't intend to approach the
> shared memory or distributed computing realms.
> 
> And the second call to Pool.map would update the cached "self" as a part of
> its initialization workflow, s.t. "the latest version of self when map() is
> called is taken into account".

I still don't understand how that works.  If you "updated the cached
self", then surely you must transmit it to the child, right?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Sean Harrington]

I would contend that this is much more granular than Dask - this is just an
optimization of Pool.map() to avoid redundantly passing the same `func`
repeatedly, once per task, to each worker, with the primary goal of
eliminating redundant serialization of large-memory-footprinted Callables.
This is a different use case than Dask - I don't intend to approach the
shared memory or distributed computing realms.

And the second call to Pool.map would update the cached "self" as a part of
its initialization workflow, s.t. "the latest version of self when map() is
called is taken into account".

Do you see a difficulty in accomplishing the second behavior?

On Fri, Oct 12, 2018 at 9:25 AM Antoine Pitrou  wrote:

>
> Le 12/10/2018 à 15:17, Sean Harrington a écrit :
> > The implementation details need to be flushed out, but agnostic of
> > these, do you believe this a valid solution to the initial problem? Do
> > you also see it as a beneficial optimization to Pool, given that we
> > don't need to store funcs/bound-methods/partials on the tasks themselves?
>
> I'm not sure, TBH.  I also think it may be better to leave this to
> higher levels (for example Dask will intelligently distribute data on
> workers and let you work with a kind of proxy object in the main
> process, transfering data only when necessary).
>
> > The latter concern about "what happens if `self` changed value in the
> > parent" is the same concern as "what happens if `func` changes in the
> > parent?" given the current implementation. This is an assumption that is
> > currently made with Pool.map_async(func, ls). If "func" changes in the
> > parent, there is no communication with the child. So one just needs to
> > be aware that calling "map_async(self.func, ls)" while the state of
> > "self" is changing, will not communicate changes to each worker. The
> > state is frozen when Pool.map is called, just as is the case now.
>
> If you cache "self" between pool.map calls, then the question is not
> "what happens if self changes *during* a map() call" but "what happens
> if self changes *between* two map() calls"?  While the former is
> intuitively undefined, current users would expect the latter to have a
> clear answer, which is: the latest version of self when map() is called
> is taken into account.
>
> Regards
>
> Antoine.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/seanharr11%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Antoine Pitrou]

Le 12/10/2018 à 15:17, Sean Harrington a écrit :
> The implementation details need to be flushed out, but agnostic of
> these, do you believe this a valid solution to the initial problem? Do
> you also see it as a beneficial optimization to Pool, given that we
> don't need to store funcs/bound-methods/partials on the tasks themselves?

I'm not sure, TBH.  I also think it may be better to leave this to
higher levels (for example Dask will intelligently distribute data on
workers and let you work with a kind of proxy object in the main
process, transfering data only when necessary).

> The latter concern about "what happens if `self` changed value in the
> parent" is the same concern as "what happens if `func` changes in the
> parent?" given the current implementation. This is an assumption that is
> currently made with Pool.map_async(func, ls). If "func" changes in the
> parent, there is no communication with the child. So one just needs to
> be aware that calling "map_async(self.func, ls)" while the state of
> "self" is changing, will not communicate changes to each worker. The
> state is frozen when Pool.map is called, just as is the case now.

If you cache "self" between pool.map calls, then the question is not
"what happens if self changes *during* a map() call" but "what happens
if self changes *between* two map() calls"?  While the former is
intuitively undefined, current users would expect the latter to have a
clear answer, which is: the latest version of self when map() is called
is taken into account.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Sean Harrington]

The implementation details need to be flushed out, but agnostic of these,
do you believe this a valid solution to the initial problem? Do you also
see it as a beneficial optimization to Pool, given that we don't need to
store funcs/bound-methods/partials on the tasks themselves?

The latter concern about "what happens if `self` changed value in the
parent" is the same concern as "what happens if `func` changes in the
parent?" given the current implementation. This is an assumption that is
currently made with Pool.map_async(func, ls). If "func" changes in the
parent, there is no communication with the child. So one just needs to be
aware that calling "map_async(self.func, ls)" while the state of "self" is
changing, will not communicate changes to each worker. The state is frozen
when Pool.map is called, just as is the case now.

On Fri, Oct 12, 2018 at 9:07 AM Antoine Pitrou  wrote:

> On Fri, 12 Oct 2018 08:33:32 -0400
> Sean Harrington  wrote:
> > Hi Nathaniel - this if this solution can be made performant, than I would
> > be more than satisfied.
> >
> > I think this would require removing "func" from the "task tuple", and
> > storing the "func" "once per worker" somewhere globally (maybe a class
> > attribute set post-fork?).
> >
> > This also has the beneficial outcome of increasing general performance of
> > Pool.map and friends. I've seen MANY folks across the interwebs doing
> > things like passing instance methods to map, resulting in "big" tasks,
> and
> > slower-than-sequential parallelized code. Parallelizing "instance
> methods"
> > by passing them to map, w/o needing to wrangle with staticmethods and
> > globals, would be a GREAT feature! It'd just be as easy as:
> >
> > Pool.map(self.func, ls)
> >
> > What do you think about this idea? This is something I'd be able to take
> > on, assuming I get a few core dev blessings...
>
> Well, I'm not sure how it would work, so it's difficult to give an
> opinion.  How do you plan to avoid passing "self"?  By caching (by
> equality? by identity?)?  Something else?  But what happens if "self"
> changed value (in the case of a mutable object) in the parent?  Do you
> keep using the stale version in the child?  That would break
> compatibility...
>
> Regards
>
> Antoine.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/seanharr11%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Antoine Pitrou]

On Fri, 12 Oct 2018 08:33:32 -0400
Sean Harrington  wrote:
> Hi Nathaniel - this if this solution can be made performant, than I would
> be more than satisfied.
> 
> I think this would require removing "func" from the "task tuple", and
> storing the "func" "once per worker" somewhere globally (maybe a class
> attribute set post-fork?).
> 
> This also has the beneficial outcome of increasing general performance of
> Pool.map and friends. I've seen MANY folks across the interwebs doing
> things like passing instance methods to map, resulting in "big" tasks, and
> slower-than-sequential parallelized code. Parallelizing "instance methods"
> by passing them to map, w/o needing to wrangle with staticmethods and
> globals, would be a GREAT feature! It'd just be as easy as:
> 
> Pool.map(self.func, ls)
> 
> What do you think about this idea? This is something I'd be able to take
> on, assuming I get a few core dev blessings...

Well, I'm not sure how it would work, so it's difficult to give an
opinion.  How do you plan to avoid passing "self"?  By caching (by
equality? by identity?)?  Something else?  But what happens if "self"
changed value (in the case of a mutable object) in the parent?  Do you
keep using the stale version in the child?  That would break
compatibility...

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Sean Harrington]

Hi Nathaniel - this if this solution can be made performant, than I would
be more than satisfied.

I think this would require removing "func" from the "task tuple", and
storing the "func" "once per worker" somewhere globally (maybe a class
attribute set post-fork?).

This also has the beneficial outcome of increasing general performance of
Pool.map and friends. I've seen MANY folks across the interwebs doing
things like passing instance methods to map, resulting in "big" tasks, and
slower-than-sequential parallelized code. Parallelizing "instance methods"
by passing them to map, w/o needing to wrangle with staticmethods and
globals, would be a GREAT feature! It'd just be as easy as:

Pool.map(self.func, ls)

What do you think about this idea? This is something I'd be able to take
on, assuming I get a few core dev blessings...

On Thu, Oct 4, 2018 at 6:15 AM Nathaniel Smith  wrote:

> On Wed, Oct 3, 2018 at 6:30 PM, Sean Harrington 
> wrote:
> > with Pool(func_kwargs={"big_cache": big_cache}) as pool:
> > pool.map(func, ls)
>
> I feel like it would be nicer to spell this:
>
> with Pool() as pool:
> pool.map(functools.partial(func, big_cache=big_cache), ls)
>
> And this might also solve your problem, if pool.map is clever enough
> to only send the function object once to each worker?
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] bpo-34203: FAQ now recommends python 3.x over 2.x (GH-9796)

[Eric V. Smith]

On 10/12/2018 5:17 AM, Tal Einat wrote:


  The latest stable releases can always be found on the `Python download page
-`_.  There are two recommended 
production-ready
-versions at this point in time, because at the moment there are two branches of
-stable releases: 2.x and 3.x.  Python 3.x may be less useful than 2.x, since
-currently there is more third party software available for Python 2 than for
-Python 3.  Python 2 code will generally not run unchanged in Python 3.
+`_.  There are two production-ready version
+of Python: 2.x and 3.x, but the recommended one at this times is Python 3.x.


This should be "time", not "times". I'd fix it, but I'm unsure if this 
is being backported or not, and I don't want to mess up any merges 
before they're done.


I do think this should backported to 3.7, 3.6, and 2.7.


+Although Python 2.x is still widely used, `it will not be
+maintained after January 1, 2020 `_.
+Python 2.x was known for having more third-party libraries available, however,
+by the time of this writing, most of the widely used libraries support Python 
3.x,


Should probably be "at the time of this writing".


+and some are even dropping the Python 2.x support.


And this would read better as "are even dropping support for Python 2.x".

Eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

[Steven D'Aprano]

On Thu, Oct 11, 2018 at 01:27:08PM -0400, Chris Barker - NOAA Federal via 
Python-Dev wrote:
> > On the server side, the application could be doing something like
> > assuming that the kwargs are e.g. column names
> 
> This is exactly a use-case for non-identifier strings in kwargs.

Why not just pass a dict as an argument, rather than (ab)using kwargs?

Instead of:

- building a dict containing non-identifiers;
- unpacking it in the function call;
- have the interpreter re-pack it to a **kwargs;
- and then process it as a dict

we can cut out the two middle steps. So I must admit, I'm perplexed as 
to why people use an extra (superfluous?) ** to unpack a dict that's 
just going to be packed again. I just don't get it. *shrug*

I also wonder whether the use-cases for this would be reduced if we 
introduced verbatim names? 

https://mail.python.org/pipermail/python-ideas/2018-May/050791.html

Keys containing non-identifier characters like spaces and hyphens would 
still need the kwargs trick, but for reserved words you could just 
escape the argument:

def spam(eggs, \while=None):
...

spam(eggs=1234, \while=5678)


which frankly looks much better to me than 

spam(eggs=1234, **{"while": 5678})



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

[Samuele Pedroni]

On Thu, Oct 4, 2018 at 10:58 AM Steven D'Aprano  wrote:

> While keyword arguments have to be identifiers, using **kwargs allows
> arbitrary strings which aren't identifiers:
>
> py> def spam(**kwargs):
> ... print(kwargs)
> ...
> py> spam(**{"something arbitrary": 1, '\n': 2})
> {'something arbitrary': 1, '\n': 2}
>
>
> There is some discussion on Python-Ideas on whether or not that
> behaviour ought to be considered a language feature, an accident of
> implementation, or a bug.
>
>
I would expect this to be costly/annoying for implementations to enforce,
doing it at call time is probably too late to be efficient, it would need
help from dicts themselves or even strings.

A hack that currently works because of this is with dict itself:

>>> d = {'a-1': 1, 'a-2': 2, 'a-3': 3}
>>> d1 = dict(d, **{'a-2': -2, 'a-1': -1})
>>> d1 is d
False
>>> d1
{'a-1': -1, 'a-2': -2, 'a-3': 3}
>>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com