INADA Naoki schrieb am 07.07.2018 um 10:08:
> Thank you. Do you plan to make it default when PEP 580 is accepted
> and implemented?
It will become the default at some point, I'm sure. Note that we will still
have to support older Python versions, though, currently 2.6+, which would
not have the
On Sat, Jul 7, 2018 at 4:35 PM Stefan Behnel wrote:
>
> INADA Naoki schrieb am 07.07.2018 um 06:10:
> > How often "custom method type" are used?
> >
> > I thought Cython use it by default.
> > But when I read code generated by Cython, I can't find it.
> > It uses normal PyMethodDef and
Jeroen Demeyer schrieb am 05.07.2018 um 16:53:
> The only case when this handling of keywords is suboptimal is when using
> **kwargs. In that case, a dict must be converted to a tuple. It looks hard
> to me to support efficiently both the case of fixed keyword arguments
> (f(foo=x)) and a keyword
INADA Naoki schrieb am 07.07.2018 um 06:10:
> How often "custom method type" are used?
>
> I thought Cython use it by default.
> But when I read code generated by Cython, I can't find it.
> It uses normal PyMethodDef and tp_methods.
>
> I found CyFunction in Cython repository, but I can't find
>
On 7/6/2018 9:01 PM, Terry Reedy wrote:
In any case, Python's comprehensions use an English-syntax version of
extended set builder notation. "In Python, the set-builder's braces
are replaced with square brackets, parentheses, or curly braces,
giving list, generator, and set objects,
05.07.18 17:53, Jeroen Demeyer пише:
In other words: I see nothing to improve in the calling convention of
METH_FASTCALL. I suggest to keep it and make it public as-is.
You have considered the bytecode for calling functions, but this
actually is not directly related to the calling convention.
On 7 July 2018 at 01:25, Ned Deily wrote:
> On Jul 6, 2018, at 19:43, Alexander Belopolsky
> wrote:
>> I think it will be prudent to get this command back in Python 3.7.1. My
>> work-around was to simply copy the 20-something lines that define
>> install_misc from Python 3.6 to my setup.py
Hi Serhiy!
Serhiy Storchaka schrieb am 07.07.2018 um 10:55:
> There is my idea. Split every of keyword argument parsing functions on two
> parts. The first part linearize keyword arguments, it converts positional
> and keyword arguments (in whatever form they were presented) into a linear
> array
On 07/07/18 00:02, Jeroen Demeyer wrote:
On 2018-07-06 23:12, Guido van Rossum wrote:
It's your PEP. And you seem to be struggling with something. But I can't
tell quite what it is you're struggling with.
To be perfectly honest (no hard feelings though!): what I'm struggling
with is getting
Hi,
We seem to have a plethora of PEPs where we really ought to have one (or
none?).
Traditionally when writing a new piece of software, one gathered
requirements before implementing the code. Let us return to that
venerable tradition.
IMO, mailing lists are a terrible way to do software
On 7 July 2018 at 23:38, Mark Shannon wrote:
> Hi,
>
> We seem to have a plethora of PEPs where we really ought to have one (or
> none?).
>
> Traditionally when writing a new piece of software, one gathered
> requirements before implementing the code. Let us return to that venerable
> tradition.
Nick Coghlan schrieb am 07.07.2018 um 16:14:
> when the new calling
> convention is tied to a protocol that any type can implement (as PEP
> 580 proposes), the concern doesn't even arise.
Nick, +1 to all of what you said in your reply, and I also really like the
fact that this proposal is
> IMO, mailing lists are a terrible way to do software design, but a good
> way to gather requirements as it makes less likely that someone will be
> forgotten.
>
Agreed. There are several topics we should discuss for these PEPs.
Mailing list is hard to follow.
Can we have other communication
INADA Naoki schrieb am 07.07.2018 um 17:16:
>> 2. The new API should be used internally so that 3rd party extensions
>> are not second class citizens in term of call performance.
>
> These PEPs proposes new public protocol which can be implemented
> by 3rd party extensions, especially Cython.
>
This seems more suitable for a style guide.
Enforcing such restrictions in the grammar would actually be complicated,
due to nesting -- but even if it wasn't, I wouldn't want to, as I don't
want to limit future generations to only the benefits of the new construct
that we can now come up with.
Sorry in advance for opening yet another topic about PEP-572. With PEP-572
being officially accepted I know debating its inclusion in the language is
a useless exercise at this point, but since it's still in "draft" status I
would like to express my opinion as I think this is a feature which can
On 7 July 2018 at 07:12, Guido van Rossum wrote:
> On Fri, Jul 6, 2018 at 2:52 AM Jeroen Demeyer wrote:
>> The Cython developers (in particular Stefan Behnel) certainly support my
>> work. I have talked with them in person at a workshop and they posted a
>> few emails to python-dev and they also
> > > 5. It should speed up CPython for the standard benchmark suite.
...
> >
> > I don't think point 5 is a goal here either, as the problem isn't that
> > these calling optimisations don't exist, it's that they don't
> > currently have a public API that third party projects can access (the
> >
There has been off-list discussion with the authors, for sure. But most of the
recent threads are disputes and not useful.
At this point, if you're not helping clarify what’s in the PEP, you’re not
helping by posting an opinion.
But since we can’t possibly convince everyone not to post their
On Sun, 8 Jul 2018 00:14:13 +1000
Nick Coghlan wrote:
>
> > So, let us gather the requirements for a new calling API.
>
> > Here are my starting suggestions:
> >
> > 1. The new API should be fully backwards compatible and shouldn't break the
> > ABI
> > 2. The new API should be used
On Sat, Jul 7, 2018 at 12:19 AM, Stefan Behnel wrote:
> Typically, it's calls with 1 to ~3 positional arguments that occur in
> performance critical situations. Often just one, rarely more, and zero
> arguments is a fast case anyway. Keyword arguments will always suffer some
> kind of penalty
On Sat, Jul 7, 2018 at 11:09 PM, Giampaolo Rodola' wrote:
> To me this looks like the perfect example of where this functionality can be
> abused. Also, I'm not clear what PEP-572 intend to do about "all other
> places". E.g. should these cases be allowed? (IMO no)
>
> >>> yield x := 3
>
On Sat, 7 Jul 2018 16:39:08 +0200
Stefan Behnel wrote:
> Nick Coghlan schrieb am 07.07.2018 um 16:14:
> > when the new calling
> > convention is tied to a protocol that any type can implement (as PEP
> > 580 proposes), the concern doesn't even arise.
>
> Nick, +1 to all of what you said in
[Guido]
> ...
> As to why you might want to use := in a function call, I could imagine
> writing
>
> if validate(name := re.search(pattern, line).group(1)):
> return name
>
When I was staring at my code, I never mentioned the very first plausible
use I bumped into (in code I was
On 7/7/2018 12:53 PM, Tim Peters wrote:
[Guido]
...
As to why you might want to use := in a function call, I could
imagine writing
if validate(name := re.search(pattern, line).group(1)):
return name
If name has to be non-blank to pass validate, one can avoid
On 2018-07-07 15:38, Mark Shannon wrote:
Hi,
We seem to have a plethora of PEPs where we really ought to have one (or
none?).
- PEP 575 has been withdrawn.
- PEP 579 is an informational PEP with the bigger picture; it does
contain some of the requirements that you want to discuss here.
- PEP
On Fri, Jul 6, 2018, 16:32 Guido van Rossum, wrote:
> On Fri, Jul 6, 2018 at 4:19 PM Terry Reedy wrote:
>
>> Since Guido, the first respondent, did not immediately shoot the idea
>> down, I intend to flesh it out and make it more concrete.
>>
>
> Maybe I should have shot it down. The term is
On Sat, Jul 7, 2018, 08:17 INADA Naoki, wrote:
> > IMO, mailing lists are a terrible way to do software design, but a good
> > way to gather requirements as it makes less likely that someone will be
> > forgotten.
> >
>
> Agreed. There are several topics we should discuss for these PEPs.
>
Hi folks,
After review from Barry & Guido, I've just merged an update to PEP 1
and the PEP index generator that separates out provisionally accepted
PEPs to their own state in the PEP flow:
https://github.com/python/peps/commit/307dda38d4e7a5760dd4979ae9978a4eb1e70589
To date, that status has
On 8 July 2018 at 12:48, Guido van Rossum wrote:
> Should we update some PEPs with the new status? E.g. PEP 484.
Aye, 3 PEPs were given the new status as part of the commit:
- 484 (type hinting syntax)
- 518 (pyproject.toml/[build-system].requires)
- 517 (pyproject.toml/[build-system].backend)
On 2018-07-07 14:54, Mark Shannon wrote:
There is a minimal implementation and has been for a while.
There is a link at the bottom of the PEP.
Yes, I saw that but the implementation does not correspond to the PEP.
In particular, this sentence from the PEP has not been implemented:
When
Should we update some PEPs with the new status? E.g. PEP 484.
On Sat, Jul 7, 2018 at 7:46 PM Nick Coghlan wrote:
> Hi folks,
>
> After review from Barry & Guido, I've just merged an update to PEP 1
> and the PEP index generator that separates out provisionally accepted
> PEPs to their own state
Thanks!
On Sat, Jul 7, 2018 at 8:29 PM Nick Coghlan wrote:
> On 8 July 2018 at 12:48, Guido van Rossum wrote:
> > Should we update some PEPs with the new status? E.g. PEP 484.
>
> Aye, 3 PEPs were given the new status as part of the commit:
>
> - 484 (type hinting syntax)
> - 518
On 2018-07-07 06:09, Giampaolo Rodola' wrote:
I initially found myself disliking the idea as a whole but
https://github.com/python/cpython/pull/8122 made me (and others) reconsider it
quite a bit (see: https://twitter.com/grodola/status/1015251302350245888).
PR-8122 clearly shows an
On Sat, Jul 7, 2018 at 6:38 AM, Mark Shannon wrote:
> 1. The new API should be fully backwards compatible and shouldn't break the
> ABI
Which ABI? The stable ABI (PEP 384)? I don't think object layout is
exposed there, though I'm not sure of the details.
The regular ABI that almost everyone
>
> [Tim]
> > When I was staring at my code, I never mentioned the very first
> > plausible use I bumped into (in code I was actively working on at the
> time):
> >
> > while not probable_prime(p := randrange(lo, hi)):
> > pass
> > # and now `p` is likely a random prime in range
>
{Terry
36 matches
Mail list logo
