I can't say that I like the look of pseudo-assignment to question mark:
for ? in range(20):
...
but I could probably learn to live with it. But one of your
rationalisations:
> and makes it more obvious that
> the actual intent is for the value to be unused -- since it is entirely
19.10.20 20:39, Marco Sulla пише:
> TL;DR Is it possible to use C code to implement the (un)pickling of an
> type written in a C extension, as it was written in _pickle.c?
>
> Long explaining: I'm trying to create a C extension for frozendict. For
> simplicity, first I wrote it in CPython, then I
On 20Oct2020 1021, Steven D'Aprano wrote:
In my opinion, having a convention to treat certain variables as
"unused" is great (I'm partial to `__` myself, to avoid clobbering the
special variable `_` in the REPL). But having that be a pseudo-variable
which is *actually* unused and unuseable
On Tue, Oct 20, 2020 at 11:26 AM Steven D'Aprano
wrote:
> I can't say that I like the look of pseudo-assignment to question mark:
>
> for ? in range(20):
> ...
>
> but I could probably learn to live with it. But one of your
> rationalisations:
>
>
> > and makes it more obvious that
>
On 20Oct2020 0520, Rob Cliffe wrote:
On 19/10/2020 12:42, Steve Dower wrote:
On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote:
TLDR: In os.scandir directory entries, atime is always a copy of
mtime rather than the actual access time.
Correction - os.stat() updates the access time to _now_,
On Tue, 20 Oct 2020 at 13:13, Thomas Wouters wrote:
> The reason for this PEP is that pattern matching will make '_' (but not any
> other names) have the behaviour suggested in this PEP, but *only* in pattern
> matching.
That's something that should be addressed or debated in the pattern
On Tue, 20 Oct 2020 at 14:26, Thomas Wouters wrote:
> I'm not sure how to put it differently than I have in the PEP or the email: I
> proposed they use ? instead of _ and also apply that to regular unpacking
> (because it is very easy to see pattern matching as an extension of unpacking
>
A very interesting proposal.
A couple of thoughts...
Can we have an executive summary of how your proposed approach differs
from those of PyPy, Unladen Swallow, and various other attempts?
You suggest that payment should be on delivery, or meeting the target,
rather than up-front. That's good
On 10/19/20, Greg Ewing wrote:
> On 20/10/20 4:52 am, Gregory P. Smith wrote:
>> Those of us with a traditional posix filesystem background may raise
>> eyeballs at this duplication, seeing a directory as a place that merely
>> maps names to inodes
>
> This is probably a holdover from MS-DOS,
Where is your working code for the first stage?
October 20, 2020 8:53 AM, "Mark Shannon" wrote:
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years.
On Mon, Oct 19, 2020 at 3:11 PM Thomas Wouters wrote:
> PEP: 640
> Title: Unused variable syntax
> Author: Thomas Wouters
>
...
> In Python it is somewhat common to need to do an assignment without
> actually
> needing the result. Conventionally, people use either ``"_"`` or a name
> such
> as
On Tue, Oct 20, 2020 at 2:02 PM Chris Jerdonek
wrote:
> On Mon, Oct 19, 2020 at 3:11 PM Thomas Wouters wrote:
>
>> PEP: 640
>> Title: Unused variable syntax
>> Author: Thomas Wouters
>>
> ...
>
>> In Python it is somewhat common to need to do an assignment without
>> actually
>> needing the
On 20Oct2020 1309, Thomas Wouters wrote:
The reason for this PEP is that pattern matching will make '_' (but not
any other names) have the behaviour suggested in this PEP, but *only* in
pattern matching.
Then why is this PEP proposing a different syntax?
At the very least, wait for pattern
On Tue, 20 Oct 2020 at 13:25, Thomas Wouters wrote:
>
> On Tue, Oct 20, 2020 at 2:22 PM Paul Moore wrote:
>>
>> On Tue, 20 Oct 2020 at 13:13, Thomas Wouters wrote:
>> > The reason for this PEP is that pattern matching will make '_' (but not
>> > any other names) have the behaviour suggested in
On Tue, Oct 20, 2020 at 2:22 PM Paul Moore wrote:
> On Tue, 20 Oct 2020 at 13:13, Thomas Wouters wrote:
> > The reason for this PEP is that pattern matching will make '_' (but not
> any other names) have the behaviour suggested in this PEP, but *only* in
> pattern matching.
>
> That's something
Hi everyone,
CPython is slow. We all know that, yet little is done to fix it.
I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years. But it needs funding.
I am aware that there have been several promised speed ups in the past
that have
On Tue, Oct 20, 2020 at 2:44 PM Paul Moore wrote:
> On Tue, 20 Oct 2020 at 13:25, Thomas Wouters wrote:
> >
> > On Tue, Oct 20, 2020 at 2:22 PM Paul Moore wrote:
> >>
> >> On Tue, 20 Oct 2020 at 13:13, Thomas Wouters wrote:
> >> > The reason for this PEP is that pattern matching will make '_'
On Tue, 20 Oct 2020 13:53:34 +0100
Mark Shannon wrote:
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> I am aware that
Ah, okay. This is a problem for me, since I can't pass the 5th argument to
__reduce__, since it's an immutable type.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
On Tue, Oct 20, 2020 at 01:41:02PM +0200, Thomas Wouters wrote:
> > a, *?, b = expression
> > print(?) # wait this doesn't work;
> >
>
> I'm not sure how this is different than, say,
>
> a, _, _ = range(3)
> print(_)
For starters, that will actually print something, not fail
On 20/10/2020 5:48 pm, Chris Angelico wrote:
On Wed, Oct 21, 2020 at 3:31 AM Mark Shannon wrote:
Hi Chris,
On 20/10/2020 4:37 pm, Chris Angelico wrote:
On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:
Hi everyone,
CPython is slow. We all know that, yet little is done to fix it.
On Wed, Oct 21, 2020 at 02:38:25AM +1100, Chris Angelico wrote:
> On Wed, Oct 21, 2020 at 12:55 AM Steven D'Aprano wrote:
> > A minor point, and I realise that the costs are all in very round
> > figures, but they don't quite match up: $2 million split over five
> > stages is $400K per stage, not
On Wed, Oct 21, 2020 at 3:38 AM Steven D'Aprano wrote:
>
> On Wed, Oct 21, 2020 at 02:37:02AM +1100, Chris Angelico wrote:
>
> > Do you have any details to back this up? You're not just asking for a
> > proposal to be accepted, you're actually asking for (quite a bit of)
> > money, and then
Brett Cannon wrote:
> On Mon, Oct 19, 2020 at 4:43 PM Kevin Adler kad...@linux.vnet.ibm.com
> wrote:
> > Should this list be updated to mention that AIX 5.3 and below are no
> > longer supported?
> > Only if we are going to rip out all AIX-related code.
Ok. Looking through the history, I think I
Hi Antoine,
On 20/10/2020 2:32 pm, Antoine Pitrou wrote:
On Tue, 20 Oct 2020 13:53:34 +0100
Mark Shannon wrote:
Hi everyone,
CPython is slow. We all know that, yet little is done to fix it.
I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:
>
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> The overall aim is
I'd love to hear more about what workloads you're targeting and how you
came up with the anticipated numbers for the improvements. For comparison,
our new jit provides a single-digit-percentage speedup on our django and
flask benchmarks.
On Tue, Oct 20, 2020 at 9:03 AM Mark Shannon wrote:
> Hi
On Mon, Oct 19, 2020 at 4:43 PM Kevin Adler
wrote:
> Brett Cannon wrote:
> > > Updated how? AIX is not mentioned in that PEP anywhere, so I'm not
> quite
> > sure what update you're suggesting.
>
> I'm referring to
> https://www.python.org/dev/peps/pep-0011/#unsupporting-platforms.
>
> "If a
On Tue, Oct 20, 2020 at 9:33 AM Steven D'Aprano wrote:
> > What would happen if $2M were spent on improving PyPy3 instead?
>
> Then both of the PyPy3 users will be very happy *wink*
>
Wow, I didn't know I was 50% of Pypy3 users :)
Anyway, Pypy3 is already pretty great. I'm sure it can be
Hi Chris,
On 20/10/2020 4:37 pm, Chris Angelico wrote:
On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:
Hi everyone,
CPython is slow. We all know that, yet little is done to fix it.
I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years.
On 20/10/2020 2:47 pm, Steven D'Aprano wrote:
A very interesting proposal.
A couple of thoughts...
Can we have an executive summary of how your proposed approach differs
from those of PyPy, Unladen Swallow, and various other attempts?
On Tue, 20 Oct 2020 at 14:01, Mark Shannon wrote:
>
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> I am aware that there
Since HPy was mentioned, hello from the HPy team!
If anyone is thinking about Python performance or new Python VMs, we'd
love them to take a look at HPy and come and talk to us. HPy is meant
to provide a new C API layer that any Python VM could implement in
order to efficiently support Python
On Wed, Oct 21, 2020 at 02:37:02AM +1100, Chris Angelico wrote:
> Do you have any details to back this up? You're not just asking for a
> proposal to be accepted, you're actually asking for (quite a bit of)
> money, and then hoping to find a contractor to do the actual work.
Payment is on
On 10/20/20 2:53 PM, Mark Shannon wrote:
> I'd love to hear your thoughts on this.
a VM needs a separate backend for each architecture (maybe even OS)
- which architectures do you include into your proposal?
what's your estimate for a new port?
- do you plan for a fall-back to a slow
On Wed, Oct 21, 2020 at 12:55 AM Steven D'Aprano wrote:
> A minor point, and I realise that the costs are all in very round
> figures, but they don't quite match up: $2 million split over five
> stages is $400K per stage, not $500K.
The proposal is for four stages.
ChrisA
On Wed, Oct 21, 2020 at 3:31 AM Mark Shannon wrote:
>
> Hi Chris,
>
> On 20/10/2020 4:37 pm, Chris Angelico wrote:
> > On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:
> >>
> >> Hi everyone,
> >>
> >> CPython is slow. We all know that, yet little is done to fix it.
> >>
> >> I'd like to
On 10/20/2020 2:49 PM, Dan Stromberg wrote:
I suspect what it needs most is HPY work, which could benefit a lot of
Python language implementations in the long term:
https://github.com/hpyproject/hpy
$2e6 spent on HPY could be pretty amazing.
I don't think the two projects are mutually
On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> What I don't see is where the money's coming from. It's fine to ask,
> but will anyone come up with that sort of funding?
I don't think Mark is asking for you or I to fund the exercise. He's
asking for the PSF to fund it.
I think
On Tue, Oct 20, 2020 at 5:59 AM Mark Shannon wrote:
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> I am aware that there
Hello,
On Tue, 20 Oct 2020 00:00:49 +0200
Thomas Wouters wrote:
> One of the problems I have with the Pattern Matching proposal (PEP 622
> originally, now PEPs 634, 635, 636) is the special-casing of '_' to
> not actually assign to the name, which is a subtle but meaningful
> divergence from
41 matches
Mail list logo
