The support of hexadecimal floating literals (like 0xC.68p+2) is
included in just released C++17 standard. Seems this becomes a mainstream.
In Python float.hex() returns hexadecimal string representation. Is it a
time to add more support of hexadecimal floating literals? Accept them
in float c
On Thu, Sep 7, 2017 at 8:11 PM, Eric Snow wrote:
> First of all, thanks for the feedback and encouragement! Responses
> in-line below.
I hope it's helpful! More responses in-line as well.
> On Thu, Sep 7, 2017 at 3:48 PM, Nathaniel Smith wrote:
>> My concern about this is the same as it was la
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. That being
> said, here
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
>> this.
>
> This all sounds very reasonable. Thanks for t
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
> (basically it's J
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 transf
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]: data
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
> > transfer data between subinterpreters)
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 p
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,
>> because I think the semantics would genu
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 threads, but they'r
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 merges them with the generic
>> docs.python.org/3/),
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 API
> simple. Please let me kn
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 isolation?
The GIL is still proce
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 description. Again, this is pro
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
may evolve it over t
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. expand the queue's supported ty
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 technically its helper class)?
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)')
>>
>> would be precisely as safe as
>>
>> interp.ca
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 unpack(computation()) as result:
> d
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 3.2, 3.3
> etc. of the doc
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):
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
> im
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
Python's documentation is
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 unsafe, and/or
> difficul
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
elsehttp://
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. Please let me know what you thi
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
https://www.python.org/dev/peps/pep
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 i
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?
>
> You should try DuckDu
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.
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 th
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 for the benefit of the
> 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 language design and
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 standards
in proprietary ways lies a ma
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 be
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
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 ... ]
> 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:
>> do_something_with_result(result)
>
> Hi - thanks for
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 quite a lot
in t
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 b
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 contact Google to alte
42 matches
Mail list logo