On Fri, 8 Oct 2021 at 03:45, S Pradeep Kumar wrote:
> Typing-sig has been discussing user-friendly syntax for the type used to
> represent callables. [1] Since this affects the Python language syntax, we
> wanted to get some high-level feedback from you before putting up a detailed
> PEP.
Dis
Hi Sam,
On Thu, Oct 07, 2021 at 03:52:56PM -0400, Sam Gross wrote:
> I've been working on changes to CPython to allow it to run without the
> global interpreter lock. I'd like to share a working proof-of-concept that
> can run without the GIL.
Getting Python to run without the GIL has never been
07.10.21 19:41, S Pradeep Kumar пише:
> 1. Syntax to replace Callable
>
> After a lot of discussion, there is strong consensus in typing-sig about
> adding syntax to replace Callable. So, the above example would be
> written as:
> ```python
> def print_purchases(
> user: User,
> formatter:
How would this work for a function that returns a function? Would you just put
it on the def line like this?
def foo() -> (int) -> str:
return some_function_from_int_to_str
Or would it have to be:
def foo() -> ((int) -> str): ...
The former is a little confusing to read - at first glance,
Hi,
I'm digging into the Python bug tracker history and I found links to
Subversion commits:
"Fixed in r77062 (trunk), r77063 (py3k)."
https://bugs.python.org/issue1811#msg96910
Roundup adds links which are redirected:
* https://hg.python.org/lookup/r77062 ->
https://svn.python.org/view?view=rev
> On 8 Oct 2021, at 10:13, Steven D'Aprano wrote:
>
> Hi Sam,
>
> On Thu, Oct 07, 2021 at 03:52:56PM -0400, Sam Gross wrote:
>
>> I've been working on changes to CPython to allow it to run without the
>> global interpreter lock. I'd like to share a working proof-of-concept that
>> can run with
To be clear, Sam’s basic approach is a bit slower for single-threaded code,
and he admits that. But to sweeten the pot he has also applied a bunch of
unrelated speedups that make it faster in general, so that overall it’s
always a win. But presumably we could upstream the latter easily,
separately
El vie, 8 oct 2021 a las 0:54, Paul Moore () escribió:
> On Fri, 8 Oct 2021 at 03:45, S Pradeep Kumar wrote:
>
> > Typing-sig has been discussing user-friendly syntax for the type used to
> represent callables. [1] Since this affects the Python language syntax, we
> wanted to get some high-level
On Fri, Oct 8, 2021 at 8:11 AM Guido van Rossum wrote:
> To be clear, Sam’s basic approach is a bit slower for single-threaded
> code, and he admits that.
>
Is it also slower even when running with PYTHONGIL=1? If it could be made
the same speed for single-threaded code when running in GIL-enabl
On Fri, Oct 8, 2021 at 8:31 AM Jelle Zijlstra
wrote:
> El vie, 8 oct 2021 a las 0:54, Paul Moore ()
> escribió:
>
>> Also, note that I automatically used a type of int->int up there. As
>> someone else asked, is that form allowed, or is it required to be
>> (int)->int? In my view, if we require t
On Fri, 8 Oct 2021 at 16:29, Jelle Zijlstra wrote:
> That's one of the differences between the proposals discussed here. The basic
> proposal Pradeep pointed out would not support named arguments, the more
> complete syntax favored by Guido (and also by me; 2(a) in Pradeep's email)
> would supp
Pradeep,
Thanks for all the clarifications. I think it's time that you put together
a formal grammar. That should also make clear that "(,) -> int" is
disallowed while "(int,) -> int" is allowed.
--Guido
On Fri, Oct 8, 2021 at 8:50 AM S Pradeep Kumar wrote:
> Thanks for the responses!
>
> 1. C
On Thu, Oct 7, 2021 at 7:54 PM Sam Gross wrote:
> Design overview:
> https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit
Whoa, this is impressive work.
I notice the fb.com address -- is this a personal project or something
facebook is working on? what's the relat
>
> To speed-up function calls, the interpreter uses a linear, resizable stack
> to store function call frames, an idea taken from LuaJIT. The stack stores
> the interpreter registers (local variables + space for temporaries) plus
> some extra information per-function call. This avoids the need for
On Fri, 8 Oct 2021 at 03:50, Sam Gross wrote:
> My goal with the proof-of-concept is to demonstrate that removing the GIL is
> feasible and worthwhile, and that the technical ideas of the project could
> serve as a basis of such an effort.
I'm a novice C programmer, but I'm unsure about the saf
Hello,
I'm happy to announce that CPython project is participating in
hacktoberfest.
I have just added the hacktoberfest topic to CPython's GitHub Repo (
https://github.com/python/cpython).
Caveat: if we end up receiving too many spammy, invalid, and low-quality
PRs which just adds burden to main
ACTIVITY SUMMARY (2021-10-01 - 2021-10-08)
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:
open7374 (+33)
closed 49772 (+38)
total 57146 (+71)
Open issues w
Thanks for thinking more deeply about how we can make type annotations for
callables more user friendly.
The intersection between the syntax for general Python code and type
annotations has been a topic of discussion within the Steering Council (on and
off) for quite some time. We intend to pr
On Oct 8, 2021, at 13:02, Sergei Lebedev wrote:
>
> I agree that type annotation syntax should be consistent with the rest of the
> language, but I'm curious why it has to be "standard Python syntax"? Could
> you elaborate a bit more on the reasoning behind that constraint?
Hi Sergei. I don’
On Fri, Oct 8, 2021 at 3:36 PM Barry Warsaw wrote:
> On Oct 8, 2021, at 13:02, Sergei Lebedev
> wrote:
> >
> > I agree that type annotation syntax should be consistent with the rest
> of the language, but I'm curious why it has to be "standard Python syntax"?
> Could you elaborate a bit more on
On 10/7/21 8:52 PM, Sam Gross wrote:
I've been working on changes to CPython to allow it to run without the
global interpreter lock.
Before anybody asks: Sam contacted me privately some time ago to pick my
brain a little. But honestly, Sam didn't need any help--he'd already
taken the proje
On Fri, Oct 8, 2021 at 12:55 PM Daniel Pope wrote:
> I'm a novice C programmer, but I'm unsure about the safety of your
> thread-safe collections description.
>
The "list" class uses a slightly different strategy than "dict", which I
forgot about
when writing the design overview. List relies on
Thanks for summarizing the PSC position, Barry!
I agree that type annotation syntax should be consistent with the rest of
the language, but I'm curious why it has to be "standard Python syntax"?
Could you elaborate a bit more on the reasoning behind that constraint?
Cheers,
Sergei
On Fri, Oct 8,
(copied from typing on advice since this affects runtime behavior)
PEP 591 for Final states "Type checkers should infer a final attribute that is
initialized in a class body as being a class variable. Variables should not be
annotated with both ClassVar and Final."
ClassVar is used to indicate l
Thanks for the responses!
1. Chris Angelico:
> it looks like the parentheses are mandatory, and they are what define it?
Yes, we always expect parens. Like you said, this keeps things consistent,
resembles the function signature, and avoids ambiguities. It also won't
look like Haskell function t
On Fri, Oct 8, 2021 at 12:24 PM Pablo Galindo Salgado
wrote:
> When you mean "an order of magnitude less overhead than the current
> CPython implementation" do you mean compared with the main branch? We
> recently implemented already almost everything is listed in this paragraph.
>
I think I wro
On Fri, Oct 8, 2021 at 8:55 PM Sam Gross wrote:
> the "nogil" interpreter stays within the same interpreter loop for many
> Python function calls, while upstream CPython
> recursively calls into _PyEval_EvalFrameDefault.
>
Not for much longer though. https://github.com/python/cpython/pull/28488
27 matches
Mail list logo
