On 15/09/14 12:31, Tal Einat wrote:
On Mon, Sep 15, 2014 at 6:18 AM, Harish Tech wrote:
I had a list
a = [1, 2, 3]
when I did
a.insert(100, 100)
[1, 2, 3, 100]
as list was originally of size 4 and I was trying to insert value at index
100 , it behaved like append instead of throwing an
Hi,
http://speed.python.org/
could do with some love.
Cheers,
Mark.
On 01/10/14 08:35, Shorya Raj wrote:
Hello
Just curious, is there any sort of tasklist for any sort of sysadmin
sort of work surrounding CPython development? There seem to be plenty of
tasks for the actual coding part, but it
Hi,
The problem is a side effect of the fact that old-style classes are
implemented on top of new-style meta-classes.
Consequently although C is the "class" of C() it is not its "type".
>>> type(C())
>>> type(C()).__mro__
(, )
therefore
>>> issubclass(type(C()), object)
True
which implies
>
Hi,
I think this might be a bit off-topic for this mailing list,
code-qual...@python.org is the place for discussing static analysis tools.
Although if anyone does have any comments on any particular checks
they would like, I would be interested as well.
Cheers,
Mark.
On 17/11/14 14:49, Stefa
Hi,
I have serious concerns about this PEP, and would ask you to reconsider it.
[ Very short summary:
Generators are not the problem. It is the naive use of next() in an
iterator that is the problem. (Note that all the examples involve calls
to next()).
Change next() rather than fiddl
On 23/11/14 22:54, Chris Angelico wrote:
On Mon, Nov 24, 2014 at 7:18 AM, Mark Shannon wrote:
Hi,
I have serious concerns about this PEP, and would ask you to reconsider it.
Hoping I'm not out of line in responding here, as PEP author. Some of
your concerns (eg "5 days is too s
On 29/11/14 01:59, Nathaniel Smith wrote:
Hi all,
[snip]
Option 3: Make it legal to assign to the __dict__ attribute of a
module object, so that we can write something like
new_module = MyModuleSubclass(...)
new_module.__dict__ = sys.modules[__name__].__dict__
sys.modules[__name_
On 29/11/14 19:37, Nathaniel Smith wrote:
[snip]
- The "new module" object has to be a subtype of ModuleType, b/c there
are lots of places that do isinstance(x, ModuleType) checks (notably
It has to be a *subtype* is does not need to be a *subclass*
class M:
...__class__ = ModuleType
Hi,
This discussion has been going on for a while, but no one has questioned
the basic premise. Does this needs any change to the language or
interpreter?
I believe it does not. I'm modified your original metamodule.py to not
use ctypes and support reloading:
https://gist.github.com/marksha
On 06/03/15 16:34, Brett Cannon wrote:
Over on the import-sig I proposed eliminating the concept of .pyo files
since they only signify that /some/ optimization took place, not
/what/ optimizations took place. Everyone on the SIG was positive with
the idea so I wrote a PEP, got positive feedback
On 29/03/15 19:16, Paul Sokolovsky wrote:
Hello,
I looked into porting Python3 codecs module to MicroPython and saw
rather strange behavior, which is best illustrated with following
testcase:
==
def foo(a):
print("func:", a)
import _codecs
fun = _codecs.utf_8_encode
#fun = hash
Hi,
I was looking at PEP 492 and it seems to me that no new syntax is required.
Looking at the code, it does four things; all of which, or a functional
equivalent, could be done with no new syntax.
1. Make a normal function into a generator or coroutine. This can be
done with a decorator.
2. S
On 26/04/15 21:40, Yury Selivanov wrote:
Hi Mark,
On 2015-04-26 4:21 PM, Mark Shannon wrote:
Hi,
I was looking at PEP 492 and it seems to me that no new syntax is
required.
Mark, all your points are explained in the PEP in a great detail:
I did read the PEP. I do think that clarifying the
x27;t think I was clear enough. I said that "await" *is* a function,
not that is should be disguised as one. Reading the code,
"GetAwaitableIter" would be a better name for that element of the
implementation. It is a straightforward non-blocking function.
On Sun, Apr 26, 2
On 26/04/15 23:24, Nick Coghlan wrote:
On 27 Apr 2015 07:50, "Mark Shannon" mailto:m...@hotpy.org>> wrote:
> On 26/04/15 21:40, Yury Selivanov wrote:
>>
>> But it's hard. Iterating through something asynchronously? Write a
>> 'while Tru
Hi,
I still think that there are several issues that need addressing with
PEP 492. This time, one issue at a time :)
"async"
The "Rationale and Goals" of PEP 492 states that PEP 380 has 3 shortcomings.
The second of which is:
"""It is not possible to natively define a coroutine which has
On 28/04/15 20:24, Paul Sokolovsky wrote:
Hello,
[snip]
Based on all this passage, my guess is that you miss difference
between C and Python functions.
This is rather patronising, almost to the point of being insulting.
Please keep the debate civil.
[snip]
Cheers,
Mark.
_
On 28/04/15 20:39, Paul Sokolovsky wrote:
Hello,
On Tue, 28 Apr 2015 19:44:53 +0100
Mark Shannon wrote:
[]
A coroutine without a yield statement can be defined simply and
concisely, thus:
@coroutine
def f():
return 1
[]
A pure-python definition of the "coroutine" de
On 28/04/15 21:06, Guido van Rossum wrote:
On Tue, Apr 28, 2015 at 11:44 AM, Mark Shannon mailto:m...@hotpy.org>> wrote:
Hi,
I still think that there are several issues that need addressing
with PEP 492. This time, one issue at a time :)
"async"
The &quo
On 16/11/17 04:53, Guido van Rossum wrote:
[snip]
They then go on to explain that sometimes vulnerabilities can be
exploited, but I object to calling all bugs vulnerabilities -- that's
just using a scary word to get attention for a sleep-inducing document
containing such gems as "Use floa
Hi,
Overall I am strongly in favour of this PEP. It pretty much cures all
the ongoing pain of using PEP 3017 annotations for type hints.
There is one thing I don't like however, and that is treating strings as
if the quotes weren't there.
While this seems like a superficial simplification to
Hi,
I am very concerned by this PEP.
By far and away the largest change in PEP 560 is the change to the
behaviour of object.__getitem__. This is not mentioned in the PEP at
all, but is explicit in the draft implementation.
The implementation could implement `type.__getitem__` instead of
chang
Hi,
Just one comment. Could the new behaviour of attribute lookup on a
module be spelled out more explicitly please?
I'm guessing it is now something like:
`module.__getattribute__` is now equivalent to:
def __getattribute__(mod, name):
try:
return object.__getattribute__(mod, n
On 19/11/17 20:41, Serhiy Storchaka wrote:
19.11.17 22:24, Mark Shannon пише:
Just one comment. Could the new behaviour of attribute lookup on a
module be spelled out more explicitly please?
I'm guessing it is now something like:
`module.__getattribute__` is now equivalent to:
On 19/11/17 22:36, Ivan Levkivskyi wrote:
On 19 November 2017 at 21:06, Mark Shannon <mailto:m...@hotpy.org>> wrote:
By far and away the largest change in PEP 560 is the change to the
behaviour of object.__getitem__. This is not mentioned in the PEP at
all, but is explic
T -> bytecode conversion remains the same, I
think it is OK to change source -> AST conversion.
Last week, Mark Shannon reported issue about this backward incompatibility.
As he said, this change losted lineno and column of docstring from AST.
https://bugs.python.org/issue32911#msg3125
On 12/04/18 17:12, Jeroen Demeyer wrote:
Dear Python developers,
I would like to request a review of PEP 575, which is about changing the
classes used for built-in functions and Python functions and methods.
The text of the PEP can be found at
The motivation of PEP 575 is to allow introspe
Hi,
On 17/04/18 08:46, Chris Angelico wrote:
Having survived four rounds in the boxing ring at python-ideas, PEP
572 is now ready to enter the arena of python-dev.
I'm very strongly opposed to this PEP.
Would Python be better with two subtly different assignment operators?
The answer of "no"
Hi all,
Just a reminder that PEP 576 still exists as a lightweight alternative
to PEP 575/580. It achieves the same goals as PEP 580 but is much smaller.
https://github.com/markshannon/pep-576
Unless there is a big rush, I would like to do some experiments as to
whether the new calling conve
On 21/05/15 16:01, Guido van Rossum wrote:
Hi Mark,
We're down to the last few items here. I'm CC'ing python-dev so folks
can see how close we are. I'll answer point by point.
On Thu, May 21, 2015 at 6:24 AM, Mark Shannon mailto:m...@hotpy.org>> wrote:
Hi,
Hello all,
I am pleased to announce that I am accepting PEP 484 (Type Hints).
Given the proximity of the beta release I thought I would get this
announcement out now, even though there are some (very) minor details to
iron out.
(If you want to know the details, it's all at
https://github.com/
On 24/05/15 10:35, Nick Coghlan wrote:
On 24 May 2015 at 15:53, Eric Snow wrote:
On May 23, 2015 10:47 PM, "Guido van Rossum" wrote:
How will __definition_order__ be set in the case where __prepare__ doesn't
return an OrderedDict? Or where a custom metaclass's __new__ calls its
superclass
Hi,
On 22/07/15 09:25, Ronald Oussoren wrote:> Hi,
>
> Another summer with another EuroPython, which means its time again to
> try to revive PEP 447…
>
IMO, there are two main issues with the PEP and implementation.
1. The implementation as outlined in the PEP is infinitely recursive, since t
> On 26 July 2015 at 10:41 Ronald Oussoren wrote:
>
>
>
> > On 26 Jul 2015, at 09:14, Ronald Oussoren wrote:
> >
> >
> >> On 25 Jul 2015, at 17:39, Mark Shannon >> <mailto:m...@hotpy.org>> wrote:
> >>
> >> Hi,
> &
In a word, No.
Try https://www.python.org/jobs/
On 02/09/15 21:57, Linda Ryan wrote:
Dear Admin,
I am an IT/Project Management recruiter looking to increase the
available pool of talent for available job placements.
Currently I have an opening for a python programmer/developer. Could I
post op
On 11/01/16 16:49, Victor Stinner wrote:
Hi,
After a first round on python-ideas, here is the second version of my
PEP. The main changes since the first version are that the dictionary
version is no more exposed at the Python level and the field type now
also has a size of 64-bit on 32-bit pla
On 04/06/16 10:02, Eric Snow wrote:
You should get in touch with Mark Shannon, while you're working on
ceval. He has some definite improvements that can be made to the eval
loop.
See http://bugs.python.org/issue17611 for my suggested improvements.
I've made a new comment there.
Ch
On 06/01/14 13:24, Victor Stinner wrote:
Hi,
bytes % args and bytes.format(args) are requested by Mercurial and
[snip]
I'm opposed to adding methods to bytes for this, as I think it goes
against the reason for the separation of str and bytes in the first place.
str objects are pieces of tex
On 09/01/14 00:07, Ben Finney wrote:
Kristján Valur Jónsson writes:
Believe it or not, sometimes you really don't care about encodings.
Sometimes you just want to parse text files.
Files don't contain text, they contain bytes. Bytes only become text
when filtered through the correct encoding
On 12/01/14 16:52, Kristján Valur Jónsson wrote:
Now you're just splitting hairs, Nick.
An explicit operator, %s, _defined_ to be "encode a string object using
strict ascii",
I don't like this because '%s' reads to me as "insert *string* here".
I think '%a' which reads as "encode as ASCII and
Why not just use six.byte_format(fmt, *args)?
It works on both Python2 and Python3 and accepts the numerical format
specifiers, plus '%b' for inserting bytes and '%a' for converting text
to ascii.
Admittedly it doesn't exist yet,
but it could and it would save a lot of arguing :)
(Apologies t
On 13/01/14 03:47, Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 6:24 PM, Ethan Furman wrote:
On 01/12/2014 06:16 PM, Ethan Furman wrote:
If you do :
--> b'%s' % 'some text'
Ignore what I previously said. With no encoding the result would be:
b"'some text'"
So an encoding should def
On 13/01/14 09:19, Glenn Linderman wrote:
On 1/13/2014 12:46 AM, Mark Shannon wrote:
On 13/01/14 03:47, Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 6:24 PM, Ethan Furman wrote:
On 01/12/2014 06:16 PM, Ethan Furman wrote:
If you do :
--> b'%s' % 'some text
On 16/01/14 19:43, Larry Hastings wrote:
On 01/16/2014 04:21 AM, MRAB wrote:
On 2014-01-16 05:32, Larry Hastings wrote:
[snip]
We could add a special value, let's call it
sys.NULL, whose specific semantics are "turns into NULL when passed into
builtins". This would solve the problem but it's
On 27/02/14 13:06, Kristján Valur Jónsson wrote:
-Original Message-
From: Victor Stinner [mailto:victor.stin...@gmail.com]
Sent: 27. febrúar 2014 10:47
To: Kristján Valur Jónsson
Cc: Python-Dev (python-dev@python.org)
Subject: Re: [Python-Dev] Start writing inlines rather than macros
On 08/03/14 15:30, Maciej Fijalkowski wrote:
On Sat, Mar 8, 2014 at 5:14 PM, Victor Stinner wrote:
2014-03-08 14:33 GMT+01:00 Antoine Pitrou :
Ok, it's actually quite trivial. The whole chain is kept alive by the
"fut" global variable. If you arrange for it to be disposed of:
fut = async
On 18/03/14 07:52, Maciej Fijalkowski wrote:
Hi
I have a question about calling __eq__ in some cases.
We're thinking about doing an optimization where say:
if x in d:
return d[x]
where d is a dict would result in only one dict lookup (the second one
being constant folded away). The ques
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 f
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 d
On 07/07/18 22:11, Jeroen Demeyer wrote:
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
Hi,
Can I request a review of https://github.com/python/cpython/pull/6641.
It has been open for a few months now.
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://
Hi Petr,
Regarding PEPs 576 and 580.
Over the new year, I did a thorough analysis of possible approaches to
possible calling conventions for use in the CPython ecosystems and came
up with a new PEP.
The draft can be found here:
https://github.com/markshannon/peps/blob/new-calling-convention/pe
Hi Petr,
On 27/03/2019 1:50 pm, Petr Viktorin wrote:
On Sun, Mar 24, 2019 at 4:22 PM Mark Shannon wrote:
Hi Petr,
Regarding PEPs 576 and 580.
Over the new year, I did a thorough analysis of possible approaches to
possible calling conventions for use in the CPython ecosystems and came
up
Hi,
On 01/04/2019 6:31 am, Jeroen Demeyer wrote:
I added benchmarks for PEP 590:
https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248
Thanks. As expected for calls to C function for both PEPs and master
perform about the same, as they are using almost the same calling
conventio
Hi,
On 02/04/2019 1:49 pm, Petr Viktorin wrote:
On 3/30/19 11:36 PM, Jeroen Demeyer wrote:
On 2019-03-30 17:30, Mark Shannon wrote:
2. The claim that PEP 580 allows "certain optimizations because other
code can make assumptions" is flawed. In general, the caller cannot make
assumpt
Hi, Petr
On 10/04/2019 5:25 pm, Petr Viktorin wrote:
Hello!
I've had time for a more thorough reading of PEP 590 and the reference
implementation. Thank you for the work!
Overall, I like PEP 590's direction. I'd now describe the fundamental
difference between PEP 580 and PEP 590 as:
- PEP 580
Hi Petr,
Thanks for spending time on this.
I think the comparison of the two PEPs falls into two broad categories,
performance and capability.
I'll address capability first.
Let's try a thought experiment.
Consider PEP 580. It uses the old `tp_print` slot as an offset to mark
the location o
Hi,
On 12/04/2019 2:44 pm, Inada Naoki wrote:
Hi, all.
I propose adding new method: dict.with_values(iterable)
You can already do something like this, if memory saving is the main
concern. This should work on all versions from 3.3.
def shared_keys_dict_maker(keys):
class C: pass
i
Hi Jeroen,
On 15/04/2019 9:38 am, Jeroen Demeyer wrote:
On 2019-04-14 13:30, Mark Shannon wrote:
PY_VECTORCALL_ARGUMENTS_OFFSET exists so that callables that make onward
calls with an additional argument can do so efficiently. The obvious
example is bound-methods, but classes are at least as
Hi,
On 15/04/2019 9:34 am, Jeroen Demeyer wrote:
On 2019-04-14 13:34, Mark Shannon wrote:
I'll address capability first.
I don't think that comparing "capability" makes a lot of sense since
neither PEP 580 nor PEP 590 adds any new capabilities to CPython. They
are
Hi Petr,
On 24/04/2019 11:24 pm, Petr Viktorin wrote:
So, I spent another day pondering the PEPs.
I love PEP 590's simplicity and PEP 580's extensibility. As I hinted
before, I hope they can they be combined, and I believe we can achieve
that by having PEP 590's (o+offset) point not just to f
Hi Petr,
On 24/04/2019 11:24 pm, Petr Viktorin wrote:
On 4/10/19 7:05 PM, Jeroen Demeyer wrote:
On 2019-04-10 18:25, Petr Viktorin wrote:
Hello!
I've had time for a more thorough reading of PEP 590 and the reference
implementation. Thank you for the work!
And thank you for the review!
I'd
Hi Jeroen,
On 25/04/2019 3:42 pm, Jeroen Demeyer wrote:
On 2019-04-25 00:24, Petr Viktorin wrote:
I believe we can achieve
that by having PEP 590's (o+offset) point not just to function pointer,
but to a {function pointer; flags} struct with flags defined for two
optimizations:
What's the rat
Hi,
How do I redo a failed PR check?
The appveyor failure for https://github.com/python/cpython/pull/13181
appears to be spurious, but there is no obvious way to redo it.
BTW, this is not the first time I've seen a PR blocked by a spurious
appveyor failure.
Cheers,
Mark.
___
Hi,
I'd like to get https://github.com/python/cpython/pull/6641 merged.
I keep having to rebase it and regenerate all the importlib header
files, which is becoming a bit annoying.
So, I can I ask that if you are going to modify Python/ceval.c can
you hold on just a little while, until #6641 is
On 07/06/2019 11:41 am, Jeroen Demeyer wrote:
Hello,
I'm starting this thread to brainstorm for using vectorcall to speed up
creating instances of Python classes.
Currently the following happens when creating an instance of a Python
class X using X(.) and assuming that __new__ and __i
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 failed.
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 nex
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?
https://github.com/markshannon/faster-cpython/blob/mast
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
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
n't slowdown CPython.
But that has always been the case.
Cheers,
Mark.
[the first discussion]:
https://mail.python.org/archives/list/python-dev@python.org/thread/PQBGECVGVYFTVDLBYURLCXA3T7IPEHHO/#Q4IPXMQIM5YRLZLHADUGSUT4ZLXQ6MYY
[the second discussion]:
https://mail.python.org/arch
Hi Greg,
On 21/10/2020 11:57 pm, Greg Ewing wrote:
A concern I have about this is what effect it will have on the
complexity of CPython's implementation.
CPython is currently very simple and straightforward. Some parts
are not quite as simple as they used to be, but on the whole it's
fairly eas
However, on a few simple benchmarks I'm seeing about a 70% speedup vs
master for both default and LTO configures.
I would expect a lower speedup on a wider range of benchmarks with a
PGO/LTO build. But 50% is definitely achievable.
Cheers,
Mark.
-n
On Tue, Oct 20, 2020 at 6:00
Hi Paul,
On 22/10/2020 1:18 pm, Paul Moore wrote:
On Thu, 22 Oct 2020 at 12:52, Mark Shannon wrote:
Getting a PGO/LTO comparison against 3.10 is tricky.
Mainly because I'm relying on merging a bunch of patches and expecting
it to work :)
However, on a few simple benchmarks I'm seei
this
is the case before merging the
implementation (with the pyperformance test suite, for example).
Performance compared to what?
The current behavior of `f_lineno` is ill-defined, so mimicking it would
be tricky.
What's the reason for supposing that it will be slower?
Cheers,
Mark.
print(sys._getframe(1).f_lineno)
def test():
print_line()
sys._getframe(0).f_trace = True
print_line()
print_line()
test()
$ python3.9 ~/test/test.py
7
8
8
With PEP 626 this is required to print:
7
9
10
Cheers,
Mark.
Cheers,
Pablo
On Thu, 29 O
Hi Pablo,
On 29/10/2020 11:08 am, Pablo Galindo Salgado wrote:
> The new semantics may well result in some slowdowns. That's stated in
the PEP.I don't think I can reliably isolate the effects of the (very
slight)
change in the behavior of f_lineno.
Ok, then let's make at least we measure the
Hi everyone,
PEP 634/5/6 presents a possible implementation of pattern matching for
Python.
Much of the discussion around PEP 634, and PEP 622 before it, seems to
imply that PEP 634 is synonymous with pattern matching; that if you
reject PEP 634 then you are rejecting pattern matching.
Tha
Hi Brandt,
On 30/10/2020 4:09 pm, Brandt Bucher wrote:
Can we discuss whether we want pattern matching in Python and the broader
semantics first, before dealing with low level details?
This is a huge step backward. These discussions have already taken place, over
the last 10 years.
So what
Hi Thomas,
I have to assume that this isn't a rejection of my proposal, since I
haven't actually made a proposal to the SC yet :)
Thanks for the feedback though, it's very valuable to know the SC's
thinking on this matter.
I have a few comments inline below.
On 04/11/2020 12:27 pm, Thomas
Hi Tobias,
A couple of questions about the DLS 2020 paper.
1. Why do you use the term "validate" rather than "test" for the process
of selecting a match?
It seems to me, that this is a test, not a validation, as no exception
is raised if a case doesn't match.
2. Is the error in the ast ma
Hi everyone,
There has been much discussion on the syntax of pattern matching for
Python (in case you hadn't noticed ;)
Unfortunately the semantics seem to have been somewhat overlooked.
What pattern matching actually does seems at least as important as the
syntax.
I believe that a pattern
Hi,
I'm wondering why
```
x = "value"
try:
1/0
except Exception as x:
pass
```
does not restore "value" to x after
the `except` block.
There doesn't seem to be an explanation for this behavior in the docs or
PEPs, that I can find.
Nor does there seem to be any good technical reason fo
Hi Chris,
On 17/11/2020 11:03 am, Chris Angelico wrote:
On Tue, Nov 17, 2020 at 9:44 PM Steven D'Aprano wrote:
`try...except` is no different.
...
The only wrinkle in the case of `try...except` is that the error
variable is deleted, even if it wasn't actually used. If you look at the
byte-code
On 17/11/2020 10:22 am, Cameron Simpson wrote:
On 17Nov2020 09:55, Mark Shannon wrote:
I'm wondering why
```
x = "value"
try:
1/0
except Exception as x:
pass
```
does not restore "value" to x after
the `except` block.
Because the except is not a new sc
This only saves globals and function-locals, class-locals and
non-locals are unchanged. I'd probably want to emit a syntax warning for
non-locals, as the semantics are a bit weird).
Cheers,
Mark.
On 17/11/2020 9:55 am, Mark Shannon wrote:
Hi,
I'm wondering why
```
x = "value"
mapping, and I don't think it will.
I'm not familiar enough with ever corner of PEP 634 to do that.
I could add a general "how to" guide though. It fairly straightforward
conceptually but, as you know, the devil is in the details.
Cheers,
Mark.
--Guido
On Mon, Nov 16
mplementation dependent and then fixed, it
shouldn't break anything (it's like the change in dictionary order
moving to "undefined/arbitrary" to "preserving insertion order") and
can be done later one
I think it is important that *all* implementat
Hi,
I'd like to request that any pattern matching PEP and its implementation
meet certain standards before acceptance.
As one of the maintainers of the AST-to-bytecode part of the compiler
and the bytecode interpreter, I don't want to be in the situation where
we are forced to accept a sub-sta
low and how they apply to PEP-634.
I'm also answering personally, with a reasonable guess about what the
other authors of 634-636 would agree, but they may correct me if I'm
wrong.
On Mon, 16 Nov 2020 at 14:44, Mark Shannon <mailto:m...@hotpy.org>> wrote:
(...)
I bel
Hi Eric,
On 23/11/2020 9:32 pm, Eric V. Smith wrote:
On 11/23/2020 3:44 PM, David Mertz wrote:
I have a little bit of skepticism about the pattern matching syntax,
for similar reasons to those Larry expresses, and that Steve Dower
mentioned on Discourse.
Basically, I agree matching/destruct
Hi everyone,
Should the optimizer eliminate tests that it can prove have no effect on
the control flow of the program, even if that may eliminate some side
effects in __bool__()?
For several years we have converted
if a and b:
...
to
if a:
if b:
...
whi
Hi Rob,
On 13/01/2021 12:18 pm, Rob Cliffe wrote:
On 12/01/2021 15:53, Mark Shannon wrote:
In master we convert `if x: pass` to `pass` which is equivalent,
unless bool(x) has side effects the first time it is called. This is a
recent change.
Can you please confirm that this optimisation
Hi everyone,
It's time for yet another PEP :)
Fortunately, this one is a small one that doesn't change much.
It's aim is to make the VM more robust.
Abstract
This PEP proposes that machine stack overflow is treated differently
from runaway recursion. This would allow programs to set
On 19/01/2021 2:38 pm, Terry Reedy wrote:
On 1/19/2021 8:31 AM, Mark Shannon wrote:
Hi everyone,
It's time for yet another PEP :)
Fortunately, this one is a small one that doesn't change much.
It's aim is to make the VM more robust.
Abstract
This PEP proposes tha
On 19/01/2021 3:40 pm, Antoine Pitrou wrote:
On Tue, 19 Jan 2021 13:31:45 +
Mark Shannon wrote:
Hi everyone,
It's time for yet another PEP :)
Fortunately, this one is a small one that doesn't change much.
It's aim is to make the VM more robust.
On the principle, no
On 19/01/2021 3:43 pm, Sebastian Berg wrote:
On Tue, 2021-01-19 at 13:31 +, Mark Shannon wrote:
Hi everyone,
It's time for yet another PEP :)
Fortunately, this one is a small one that doesn't change much.
It's aim is to make the VM more robust.
Abstract
This PE
On 19/01/2021 4:15 pm, Antoine Pitrou wrote:
On Tue, 19 Jan 2021 15:54:39 +
Mark Shannon wrote:
On 19/01/2021 3:40 pm, Antoine Pitrou wrote:
On Tue, 19 Jan 2021 13:31:45 +
Mark Shannon wrote:
Hi everyone,
It's time for yet another PEP :)
Fortunately, this one is a smal
erflow handling is here:
https://github.com/python/cpython/compare/master...markshannon:pep-overflow-implementation
Cheers,
Mark.
On Tue, Jan 19, 2021 at 5:38 AM Mark Shannon <mailto:m...@hotpy.org>> wrote:
Hi everyone,
It's time for yet another PEP :)
Fortunately,
1 - 100 of 431 matches
Mail list logo
