Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 6:14 PM, Matthew Rocklin wrote: > Those numbers were for common use in Python tools and reflected my anecdotal > experience at the time with normal Python tools. I'm sure that there are > mechanisms to achieve faster speeds than what I experienced.

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 12:44 PM, Paul Moore wrote: > On 7 September 2017 at 20:14, Eric Snow wrote: >> I didn't include such a queue in this proposal because I wanted to >> keep it as focused as possible. I'll add a note to the PEP about >>

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

First of all, thanks for the feedback and encouragement! Responses in-line below. -eric On Thu, Sep 7, 2017 at 3:48 PM, Nathaniel Smith wrote: > My concern about this is the same as it was last time -- the work > looks neat, but right now, almost no-one uses subinterpreters >

[Python-ideas] Lazy creation of module level functions and classes

This is an idea that come out of the lazy loading modules idea. Larry Hastings mentioned what a good improvement this was for PHP. I think it would help a lot of Python too. Very many functions and classes are not actually needed but are instantiated anyhow. Back of napkin idea: Write AST

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

Those numbers were for common use in Python tools and reflected my anecdotal experience at the time with normal Python tools. I'm sure that there are mechanisms to achieve faster speeds than what I experienced. That being said, here is a small example. In [1]: import multiprocessing In [2]:

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 5:15 PM Nathaniel Smith wrote: > On Thu, Sep 7, 2017 at 4:23 PM, Nick Coghlan wrote: > > The gist of the idea is that with subinterpreters, your starting point > > is multiprocessing-style isolation (i.e. you have to use pickle to > >

Re: [Python-ideas] Extension of python/json syntax to support explicitly sets and ordered dict.

a json-like format (pyson maybe ?). I gonna pyson is a fine idea. But don't call it extended JSON ;-) For me, the point would be to capture Python' s richer data types. But would you need an OrderedDict? As pointed out, in recent cPython ( and pypy) dicts are ordered by default, but it's not

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 4:23 PM, Nick Coghlan wrote: > On 7 September 2017 at 15:48, Nathaniel Smith wrote: >> I've actually argued with the PyPy devs to try to convince them to add >> subinterpreter support as part of their experiments with GIL-removal, >>

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On 7 September 2017 at 15:48, Nathaniel Smith wrote: > I've actually argued with the PyPy devs to try to convince them to add > subinterpreter support as part of their experiments with GIL-removal, > because I think the semantics would genuinely be nicer to work with > than raw

Re: [Python-ideas] Adding "View Python 3 Documentation" to all Python 2 documentation URLs

On 7 September 2017 at 12:24, Sebastian Krause wrote: > Sebastian Krause wrote: >> This is why if you search for "python 3 $module" in Google, you'll >> never see a direct link to the 3.5 or 3.6 versions of the >> documentation (because Google

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 11:26 AM, Eric Snow wrote: > Hi all, > > As part of the multi-core work I'm proposing the addition of the > "interpreters" module to the stdlib. This will expose the existing > subinterpreters C-API to Python code. I've purposefully kept the

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 1:14 PM, Sebastian Krause wrote: > How is the GIL situation with subinterpreters these days, is the > long-term goal still "solving multi-core Python", i.e. using > multiple CPU cores from within the same process? Or is it mainly > used for

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 12:44 PM, Paul Moore wrote: > Ah, OK. so if I create a new interpreter, none of the classes, > functions, or objects defined in my calling code will exist within the > target interpreter? That makes sense, but I'd missed that nuance from > the

Re: [Python-ideas] lazy import via __future__ or compiler analysis

Barry Warsaw wrote: > There are a few other things that might end up marking a module as > "industrious" (my thesaurus's antonym for "lazy"). Good points. The analysis can be simple at first and then we can enhance it to be smarter about what is okay and still lazy load. We

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

Eric Snow wrote: > 1. add a basic queue class for passing objects between interpreters > * only support strings at first (though Nick pointed out we could > fall back to pickle or marshal for unsupported objects) > 2. implement CSP on top of subinterpreters > 3.

Re: [Python-ideas] if as

On Fri, Sep 8, 2017 at 5:40 AM, Philipp A. wrote: > sorry, it’s a bit more difficult. this works: > https://gist.github.com/flying-sheep/86dfcc1bdd71a33fa3483b83e254084c If this can be made to work - even hackily - can it be added into contextlib.contextmanager (or

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On 7 September 2017 at 20:14, Eric Snow wrote: > On Thu, Sep 7, 2017 at 11:52 AM, Paul Moore wrote: >> Is there any reason why passing a callable and args is unsafe, and/or >> difficult? Naively, I'd assume that >> >> interp.call('f(a)') >>

Re: [Python-ideas] if as

sorry, it’s a bit more difficult. this works: https://gist.github.com/flying-sheep/86dfcc1bdd71a33fa3483b83e254084c Philipp A. schrieb am Do., 7. Sep. 2017 um 21:18 Uhr: > Sadly it’s hard to create a context manager that skips its body like this: > > with

Re: [Python-ideas] Adding "View Python 3 Documentation" to all Python 2 documentation URLs

Sebastian Krause wrote: > This is why if you search for "python 3 $module" in Google, you'll > never see a direct link to the 3.5 or 3.6 versions of the > documentation (because Google merges them with the generic > docs.python.org/3/), but you still results for versions

Re: [Python-ideas] if as

Sadly it’s hard to create a context manager that skips its body like this: with unpack(computation()) as result: do_something_with_result(result) You can do it with some hackery like described here: https://stackoverflow.com/a/12594789/247482 class unpack: def __init__(self, pred):

Re: [Python-ideas] lazy import via __future__ or compiler analysis

Neil Schemenauer wrote: > Introduce a lazy module import process that modules can opt-in to. > The opt-in would either be with a __future__ statement or the > compiler would statically analyze the module and determine if it is > safe. E.g. if the module has no module level statements besides >

Re: [Python-ideas] Adding "View Python 3 Documentation" to all Python 2 documentation URLs

Guido van Rossum wrote: > We just need someone with SEO experience to fix this for us. I'm not an SEO expert, but I think a possible approach would be using (or partly abusing) the element on the documentation pages: https://support.google.com/webmasters/answer/139066

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 11:52 AM, Paul Moore wrote: > The only quibble I have is that I'd prefer it if we had a > run(callable, *args, **kwargs) method. Either instead of, or as well > as, the run(string) one here. > > Is there any reason why passing a callable and args is

Re: [Python-ideas] Extension of python/json syntax to support explicitly sets and ordered dict.

IIRC in CPython 3.6 and PyPy dicts are ordered based on insertion anyway; although it's an implementation-specific detail, realistically it removes some of the use cases for ordered dictionary literals. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On 7 September 2017 at 19:26, Eric Snow wrote: > As part of the multi-core work I'm proposing the addition of the > "interpreters" module to the stdlib. This will expose the existing > subinterpreters C-API to Python code. I've purposefully kept the API > simple.

[Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

Hi all, As part of the multi-core work I'm proposing the addition of the "interpreters" module to the stdlib. This will expose the existing subinterpreters C-API to Python code. I've purposefully kept the API simple. Please let me know what you think. -eric

[Python-ideas] lazy import via __future__ or compiler analysis

This is a half baked idea that perhaps could work. Maybe call it 2-stage module load instead of lazy. Introduce a lazy module import process that modules can opt-in to. The opt-in would either be with a __future__ statement or the compiler would statically analyze the module and determine if it

Re: [Python-ideas] Adding "View Python 3 Documentation" to all Python 2 documentation URLs

We just need someone with SEO experience to fix this for us. On Thu, Sep 7, 2017 at 9:13 AM, Steven D'Aprano wrote: > On Thu, Sep 07, 2017 at 05:51:31AM +, Bar Harel wrote: > > A bit radical but do you believe we can contact Google to alter the > search > > results? > >

Re: [Python-ideas] if as

On Thu, Sep 07, 2017 at 04:36:40PM +0200, Jason H wrote: > I also often wonder why we are left doing an assignment and test. You have > two options: > 1. assign to a variable then test and use > 2. repeat the function call Personally, I don't see what's wrong with the "assign then test" idiom.

Re: [Python-ideas] Adding "View Python 3 Documentation" to all Python 2 documentation URLs

On Thu, Sep 07, 2017 at 05:51:31AM +, Bar Harel wrote: > A bit radical but do you believe we can contact Google to alter the search > results? You should try DuckDuckGo, it recognises "python" searches and quotes from, and links to, the Python 3 documentation at the top of the page before

Re: [Python-ideas] Adding "View Python 3 Documentation" to all Python 2 documentation URLs

A sitemap.xml may be helpful for indicating search relevance to search crawlers? https://www.google.com/search?q=sphinx+sitemap On Thursday, September 7, 2017, Bar Harel wrote: > A bit radical but do you believe we can contact Google to alter the search > results? > It's

Re: [Python-ideas] if as

> Sent: Thursday, September 07, 2017 at 6:43 AM > From: "Denis Krienbühl" > To: python-ideas@python.org > Subject: [Python-ideas] if as > > Hi! > > I’ve been having this idea for a few years and I thought I finally see if > what others think of it. I have no experience in

Re: [Python-ideas] Extension of python/json syntax to support explicitly sets and ordered dict.

On Thu, Sep 7, 2017 at 9:59 PM, Matteo Nastasi wrote: > I was thinking about an extended json too, not just python syntax. > > What do you think about it ? > > Regards and thank you for your time. Extend JSON? No thank you. Down the path of extending simple

Re: [Python-ideas] Extension of python/json syntax to support explicitly sets and ordered dict.

I was thinking about an extended json too, not just python syntax. What do you think about it ? Regards and thank you for your time. Matteo. On Thu, Sep 07, 2017 at 09:54:15PM +1000, Steven D'Aprano wrote: > On Thu, Sep 07, 2017 at 01:36:31PM +0200, Matteo Nastasi wrote: > > > A set could

Re: [Python-ideas] Extension of python/json syntax to support explicitly sets and ordered dict.

On Thu, Sep 07, 2017 at 01:36:31PM +0200, Matteo Nastasi wrote: > A set could be defined as { item1, item2, item3[...] } Guido's time machine strikes again. Python 3: py> s = {1, 2, 3} py> type(s) > with {,} as an empty set That looks like a typo. I don't think that having a literal for

[Python-ideas] Extension of python/json syntax to support explicitly sets and ordered dict.

Hi all, few days ago I thought about a way to rapresent sets and ordered dicts using a json compatible syntax, these are my conclusions: A set could be defined as { item1, item2, item3[...] } with {,} as an empty set An ordered dict could be defined as [ item1: value1, item2: value2 ... ]

Re: [Python-ideas] if as

> On 7 Sep 2017, at 13:11, Paul Moore wrote: > > On 7 September 2017 at 11:43, Denis Krienbühl wrote: >> What I would love to see is the following syntax instead, which to me is >> much cleaner: >> >> if computation() as result: >>

Re: [Python-ideas] if as

On 7 September 2017 at 11:43, Denis Krienbühl wrote: > What I would love to see is the following syntax instead, which to me is much > cleaner: > >if computation() as result: >do_something_with_result(result) Hi - thanks for your suggestion! This has actually come up

[Python-ideas] if as

Hi! I’ve been having this idea for a few years and I thought I finally see if what others think of it. I have no experience in language design and I don’t know if this is something I’ve picked up in some other language. I also do not know what the ramifications of implementing this idea would

Re: [Python-ideas] Adding "View Python 3 Documentation" to all Python 2 documentation URLs

A progmatic workaround for yourself: https://addons.mozilla.org/de/firefox/addon/py3direct/ https://chrome.google.com/webstore/detail/py3redirect/codfjigcljdnlklcaopdciclmmdandig Bar Harel schrieb am Do., 7. Sep. 2017 um 07:52 Uhr: > A bit radical but do you believe we can