I remember vaguely that about two decades ago Greg Stein hatched an idea
for code objects loaded from a read-only segment in shared libraries. I
believe we went as far as ensuring that the interpreter could read bytecode
from other things that strings, and I vaguely recall seeing a design for a
On 2020-06-20 02:22, Robert DeLanghe wrote:
You can already do compact conditional returns with the current syntax:
def foo(a, b):
return (a != b or None) and a * b
or even:
foo = (lambda a, b: (a != b or None) and a * b)
both return:
foo(2, 5) # 10
foo(1, 1) #
On Fri, Jun 19, 2020 at 09:36:24AM +0100, Jonathan Fine wrote:
> What I did not say explicitly, or not clearly enough, was that the previous
> use would continue unchanged. The only change would be that a function
> object would have a flag, which would tell the interpreter whether the
>
On 20/06/20 1:15 pm, Steven D'Aprano wrote:
Here is some evidence that cache misses makes a real difference for
performance. A 70% slow down on calling functions, due to an increase in
L1 cache misses:
https://bugs.python.org/issue28618
There's no doubt that cache misses are a big issue for
On Thu, Jun 18, 2020 at 09:30:30PM -0400, Jonathan Goble wrote:
> With that said, your proposal is unclear to me on whether this would force
> immutability on all code objects (and thereby prevent all bytecode
> modification), or whether it would have an opt-out (or opt-in) mechanism.
Code
You can already do compact conditional returns with the current syntax:
def foo(a, b):
return (a != b or None) and a * b
or even:
foo = (lambda a, b: (a != b or None) and a * b)
both return:
foo(2, 5) # 10
foo(1, 1) # None
... but clarity would be better.
On Fri, Jun 19, 2020 at
On Fri, Jun 19, 2020 at 06:33:59PM +1200, Greg Ewing wrote:
> On 19/06/20 9:28 am, Steven D'Aprano wrote:
> >I know very little about how this works except a vague rule of thumb
> >that in the 21st century memory locality is king. If you want code to be
> >fast, keep it close together, not spread
This is not really the best syntax, but I thought this generator expression
might be of interest:
counter = (d.update(n=d['n']+1) or d['n'] for d in [dict(n=-1)] for _ in
iter(int,1))
It counts forever starting at 0. I was playing with only using generator
syntax...
On Fri, Jun 19, 2020 at
> On 18 Jun 2020, at 22:28, Steven D'Aprano wrote:
>
> On Thu, Jun 18, 2020 at 06:49:13PM +0100, Barry Scott wrote:
>
>> The key part of the idea is that the memory holding the ref count is
>> not adjacent to the memory holding the objects state. Further that
>> rarely modified state
> I don't see the value myself, but in theory it would make sense to
have both bounded and infinite ranges be able to be processed the same
way.
My thinking is that if we wanted to represent an unbounded range as a
mathematical entity (rather than a tool for iteration), we should let that
exist
On Fri, Jun 19, 2020 at 12:29 PM Ricky Teachey wrote:
> On Fri, Jun 19, 2020 at 12:25 PM wrote:
>
>> Proposal:
>> range(start, ..., step)
>> should function like
>> itertools.count(start, step)
>>
>> Reason:
>> It's pretty common to see people do things where they increment a count
>> within a
On Sat, Jun 20, 2020 at 2:39 AM Steele Farnsworth
wrote:
> If range were to support infinite ranges, range.__len__ would have to be
> changed to either raise an error or return float('inf') in these cases.
That would be a problem that would have to be solved, as would related
concepts like what
On 19/06/2020 17:11, ke...@edinburghacademy.org.uk wrote:
Reason:
It's pretty common to see people do things where they increment a
count within a while True loop, and it would be nice to have
something easily available for people to use to replace this.
Sorry, but I'm failing to see the use
I suppose my previous message totally ignored that you acknowledged that
itertools.count exists.
If range were to support infinite ranges, range.__len__ would have to be
changed to either raise an error or return float('inf') in these cases. I
believe __contains__ would also need to have extra
On Fri, Jun 19, 2020 at 12:25 PM wrote:
> Proposal:
> range(start, ..., step)
> should function like
> itertools.count(start, step)
>
> Reason:
> It's pretty common to see people do things where they increment a count
> within a while True loop, and it would be nice to have something easily
>
You can get this behavior with itertools.count
On Fri, Jun 19, 2020, 12:23 PM wrote:
> Proposal:
> range(start, ..., step)
> should function like
> itertools.count(start, step)
>
> Reason:
> It's pretty common to see people do things where they increment a count
> within a while True loop, and
How on earth is "count()" not easily available?
On Fri, Jun 19, 2020 at 12:23 PM wrote:
> Proposal:
> range(start, ..., step)
> should function like
> itertools.count(start, step)
>
> Reason:
> It's pretty common to see people do things where they increment a count
> within a while True loop,
Proposal:
range(start, ..., step)
should function like
itertools.count(start, step)
Reason:
It's pretty common to see people do things where they increment a count within
a while True loop, and it would be nice to have something easily available for
people to use to replace this.
Usefulness:
Hi Greg
You wrote:
On 19/06/20 9:28 am, Steven D'Aprano wrote:
> > I know very little about how this works except a vague rule of thumb
> > that in the 21st century memory locality is king. If you want code to be
> > fast, keep it close together, not spread out.
>
> Python objects are already
Hi Richard
Thank you for your interest. You wrote:
One thought that I had is the fact that this whole proposal seems to be
> based on code blocks never needing to be collected?
>
That's not quite what I meant to say. One part of the basic idea is that
permanent code objects be made available to
18.06.20 15:30, Daniel. пише:
I love the do_stuff if cond syntax in Ruby and in perl. It's very
natural to real, much more to follow than if cond: do_stuff
But still I don't think that it is enough to demand a language change.
Something near this is to have a default of none for
A if B else
Unless I've misunderstood this API, and the `ByteArray` part doesn't refer to
an array of bytes representing the value of `PyLong` in 2's complement, can we
implement this in the public header? It's already available, it's just not
exported (at least I can't use it, and it's not in the
On 19/06/20 9:28 am, Steven D'Aprano wrote:
I know very little about how this works except a vague rule of thumb
that in the 21st century memory locality is king. If you want code to be
fast, keep it close together, not spread out.
Python objects are already scattered all over memory, and a
23 matches
Mail list logo
