[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

r do anything else. I hope that makes sense. On Wed, Mar 3, 2021 at 7:32 PM Sven R. Kunze <mailto:srku...@mail.de>> wrote: Hey Irit, find my 3 answers below: On 03.03.21 13:17, Irit Katriel wrote: > Hi Sven, > > I like your formatting suggestio

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hey Irit, find my 3 answers below: On 03.03.21 13:17, Irit Katriel wrote: Hi Sven, I like your formatting suggestion, thanks. I will do something like that. You're welcome. I'm not sure I understand your question. ExceptionGroup is a subclass of Exception (which is a subclass of

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hey Irit, cool proposal. I just have two questions regarding "except Exception" or "except BaseException" as it is used e.g. by concurrent.futures.process (def _process_worker) from the stdlib. Almost similarly, I maintain a library using this pattern to wrap/unwrap exceptions from remote

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Just to be on the safe side here, I would want to asked a little bit further. On 02.03.21 12:22, Irit Katriel wrote: 1) What is the right "except pattern" when ExceptionGroup is introduced for the use cases described above (remote or concurrent python processes)? If you want to

[Python-Dev] Re: Comments on PEP 558

Hi Mark, On 04.02.21 12:47, Mark Shannon wrote: Hi Sven, On 04/02/2021 9:06 am, Sven R. Kunze wrote: As long as it is possible to **write** to existing keys to **add new keys** to frame.f_locals, I am actually quite happy. Out of interest, why would you want to add new keys to the locals

[Python-Dev] Re: Comments on PEP 558

On 03.02.21 23:37, Nick Coghlan wrote: No, PEP 558 doesn't remove it, it enhances it to be a live view of the frame state instead of an inconsistently updated snapshot. As long as it is possible to **write** to existing keys to **add new keys** to frame.f_locals, I am actually quite happy.

[Python-Dev] Re: Comments on PEP 558

Hi Mark, I've been working on a project heavily relying on frame.f_locals. Are you planning to remove it? On 30.01.21 13:18, Mark Shannon wrote: Given that f_locals is broken, why is keeping compatibility for this obscure, and probably unused case worthwhile? The break in compatibility

Re: [Python-Dev] Examples for PEP 572

On 04.07.2018 21:18, Steven D'Aprano wrote: Read the Appendix to the PEP: https://github.com/python/peps/blob/master/pep-0572.rst Yes, I did after I realized where that example came from. But my point was actually to understand the evaluation order because Uncle Timmy won't be around to

Re: [Python-Dev] Examples for PEP 572

Sorry for adding yet another mail. :-( On 04.07.2018 10:54, Serhiy Storchaka wrote: Sorry, this PEP was rewritten so many times that I missed your Appendix. while total != (total := total + term):     term *= mx2 / (i*(i+1))     i += 2 return total This very example here caught my eye.

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On 24.04.2018 11:21, Victor Stinner wrote: I have been asked to express myself on the PEP 572. +1 I knew about the relationship between read and write. But your stance on debugging just makes it a thing. Thanks a lot! ___ Python-Dev mailing list

Re: [Python-Dev] PEP 572: Assignment Expressions

On 25.04.2018 01:19, Steven D'Aprano wrote: Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that sometimes g is better. [...] We were talking about the real-world code snippet of Tim (as a justification of := ) and alternative rewritings of it without resorting to new

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 23:41, Tim Peters wrote: Why? "Give the result of an expression a name" is already heavily used in Python - it's just that the _contexts_ in which it can be done are very limited now. Which is a good thing IMO. It keeps stuff simple to reason about. At least to me, the objective

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 23:19, Barry Warsaw wrote: I also think it effectively solves the switch-statement problem: if (get_response() as answer) == 'yes': do_it() elif answer == 'no': skip_it() elif answer == 'maybe' okay_then() That’s Pythonic enough for jazz! Is it just me or since

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 22:37, Chris Angelico wrote: Ah, are you one of those programmers who writes code once and it's instantly perfect? I apologize, I didn't realize I was in the presence of a unicorn. Wow, constructive. Nothing is perfect, but if you don't consider your surroundings when doing

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 19:31, Tim Peters wrote: Surely you're joking. This is math.gcd(), which is expensive for multi-thousand bit integers, and the interpreter knows nothing about it. Adding a cache of _any_ kind (LRU or otherwise) would make it even slower. Alright, if that problem is just about

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 19:24, Chris Angelico wrote: On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze <srku...@mail.de> wrote: diff = x - x_base if diff and gcd(diff, n) > 1: return gcd(diff, n) # or if (x - x_base) and gcd(x - x_base, n) > 1: return gcd(x - x_base, n

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 17:59, Steve Holden wrote: While Tim's expression might look (superficially) like C, the five-line alternative isn't exactly an inspiring example of Pythonicity, is it? What about diff = x - x_base if diff and gcd(diff, n) > 1: return gcd(diff, n) # or if (x - x_base)

Re: [Python-Dev] Is static typing still optional?

On 21.12.2017 11:22, Terry Reedy wrote: @dataclass class C: a: int # integer field with no default b: float = 0.0 # float field with a default And the types will be recognized by type checkers such as mypy. And I think the non-typed examples should go first in the docs. I still

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

On 23.11.2017 08:38, Ivan Levkivskyi wrote: I think this code should be just equivalent to this code     def g():     temp = [(yield i) for i in range(10)]     return (v for v in temp) Semantics of the comprehension should be clear here (just an equivalent for-loop without name

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

Isn't yield like a return? A return in a list/dict/set comprehension makes no sense to me. So, +1 on SyntaxError from me too. Cheers. On 22.11.2017 21:29, David Mertz wrote: Inasmuch as I get to opine, I'm +1 on SyntaxError. There is no behavior for that spelling that I would find intuitive

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

+1 from me too. On 04.11.2017 21:55, Jim Baker wrote: +1, as Guido correctly recalls, this language guarantee will work well with Jython when we get to the point of implementing 3.7+. On Sat, Nov 4, 2017 at 12:35 PM, Guido van Rossum > wrote:

Re: [Python-Dev] Remove typing from the stdlib

On 03.11.2017 21:34, Paul Moore wrote: Consider someone who's downloaded Python and PyCharm (or Visual Studio). They want to get the benefit of the IDE code completion facilities, so they declare their argument as List[int], following the information they've found on how to declare lists of

Re: [Python-Dev] PEP 557: Data Classes

Thanks for the PEP! :) I like the naming. ;) Though, I would like to add to Michel's argument in favor of a base class. On 11.09.2017 08:38, Michel Desmoulin wrote: - I read Guido talking about some base class as alternative to the generator version, but don't see it in the PEP. Is it still

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

Why not adding both? Properties do have their uses as does __getattr__. Cheers, Sven On 13.09.2017 11:43, Larry Hastings wrote: On 09/12/2017 12:38 AM, Larry Hastings wrote: On 09/11/2017 07:22 PM, Guido van Rossum wrote: The prototype is linked to from the PEP; for your convenience

Re: [Python-Dev] PEP 550 v4

On 26.08.2017 19:23, Yury Selivanov wrote: ChainMap is constrained to be a Mapping-like object, but I get your point. Let's see what others say about the "lookup()". It is kind of an experiment to try a name and see if it fits. I like "get" more. ;-) Best, Sven PS: This might be a result

Re: [Python-Dev] PEP 550 v4

On 26.08.2017 04:19, Ethan Furman wrote: On 08/25/2017 03:32 PM, Yury Selivanov wrote: A *context variable* is an object representing a value in the execution context. A new context variable is created by calling the ``new_context_var()`` function. A context variable object has two methods:

Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

On 07.03.2017 19:37, Jelle Zijlstra wrote: 2017-03-07 10:15 GMT-08:00 Ethan Furman >: On 03/07/2017 09:41 AM, Brett Cannon wrote: I don't think a common practice has bubbled up yet for when there's both synchronous and

Re: [Python-Dev] GitHub migration scheduled for Friday

On 09.02.2017 00:03, Victor Stinner wrote: 2017-02-08 23:42 GMT+01:00 Brett Cannon : Don't forget we are doing squash merges, Ah, I didn't know. Why not using merges? Same question here. I see no benefit just overhead, mistakes and longer processes. Sven

Re: [Python-Dev] re performance

On 26.01.2017 22:33, Vlastimil Brom wrote: Hi, I can't speak about the details of mrab's implementation, but using regex, I get the resulting match instantly: [...] Nice! I focused on the stdlib re module as this is mainly used by other frameworks (like Django). (I personally prefer to use

[Python-Dev] re performance

Hi folks, I recently refreshed regular expressions theoretical basics *indulging in reminiscences* So, I read https://swtch.com/~rsc/regexp/regexp1.html However, reaching the chart in the lower third of the article, I saw Python 2.4 measured against a naive Thompson matching implementation.

Re: [Python-Dev] Generator objects and list comprehensions?

On 25.01.2017 07:28, Joe Jevnik wrote: That was a long way to explain what the problem was. I think that that solution is to stop using `yield` in comprehensions because it is confusing, or to make `yield` in a comprehension a syntax error. Same here; mixing comprehensions and yield

Re: [Python-Dev] Imports with underscores

Interesting to see that others have the same problem. We also had this kind of "over-protective" behavior. As far as I know, our devs stopped doing it as it feels cumbersome. Another argument for this is: when using PyCharm, this IDE will suggest imports from those modules which aren't the

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On 13.09.2016 20:21, Tres Seaver wrote: *Lots* of library authors have to straddle Python versions: consumers of those libraries only get to pick and choose when their code is at the "leaf" of the dependency tree (the application). Maybe, I didn't express myself well but this was not my

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On 13.09.2016 19:59, MRAB wrote: The recommended way of dealing with features across different versions of Python is to check for them and see if they raise NameError or whatever, but I wonder if there would be any benefit to recording such things somewhere, e.g. sys.features['ordered_args']

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On 11.09.2016 01:41, Nathaniel Smith wrote: I feel like I'm missing something here... by this reasoning, we should *never* change the language spec when new features are added. E.g. if people use async/await in 3.5 then their code won't be compatible with 3.4, but async/await are still part of

Re: [Python-Dev] A Pseudo-Post-Mortem (not dead yet) on my Multi-Core Python Project.

Thanks for the post. :) There's some typo in the title and url. :/ :D On 07.09.2016 01:56, Eric Snow wrote: I'm not anticipating much discussion on this, but wanted to present a summary of my notes from the project I proposed last year and have since tabled.

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

Didn't Koos say this works more like an expression annotation? IMO, the type of the expression is what is specified but the type of the variable can change over time (as you demonstrated). Sven PS: thinking this way, the new syntax is actually confusing as it annotates the variable not the

Re: [Python-Dev] Please reject or postpone PEP 526

Hi Mark, I agree with you about postponing. Not so much because of the issues you mentioned. Those all seem resolvable to me and mostly concerns type checkers, linters and coding styles not Python itself. However, I also don't like the rushing through as if this beta were the only chance to

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

Thanks Guido, also to the rest of the PEP team (4 people) :) On 30.08.2016 23:20, Guido van Rossum wrote: I'm happy to present PEP 526 for your collective review: https://www.python.org/dev/peps/pep-0526/ (HTML) https://github.com/python/peps/blob/master/pep-0526.txt (source) There's also an

Re: [Python-Dev] PEP 525

On 24.08.2016 21:05, Yury Selivanov wrote: Sorry for making you irritated. Please feel free to remind me about any concrete changes to the PEP that I promised to add on python-ideas. I'll go and re-read that thread right now anyways. No problem as it seems I wasn't the only one. So, it

Re: [Python-Dev] PEP 525

On 24.08.2016 21:00, Yury Selivanov wrote: For an async generator there are two cases: either it tries to yield another value (the first time this happens you can throw an error back into it) or it tries to await -- in that case you can also throw an error back into it, and if the error

Re: [Python-Dev] PEP 525

On 24.08.2016 18:35, Guido van Rossum wrote: On Wed, Aug 24, 2016 at 8:17 AM, Yury Selivanov > wrote: On 2016-08-23 10:38 PM, Rajiv Kumar wrote: I was playing with your implementation to gain a better understanding

Re: [Python-Dev] The devguide is now hosted on GitHub

Thanks a lot. :) On 22.07.2016 22:04, Brett Cannon wrote: https://github.com/python/devguide I have also moved all issues over as well and hooked up Read The Docs so that there's a mirror which is always up-to-date (vs. docs.python.org/devguide which is on

Re: [Python-Dev] Request for CPython 3.5.3 release

On 03.07.2016 16:39, Guido van Rossum wrote: Another thought recently occurred to me. Do releases really have to be such big productions? A recent ACM article by Tom Limoncelli[1] reminded me that we're doing releases the old-fashioned way -- infrequently, and with lots of manual labor. Maybe we

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

I also think it’s a great module for providing defaults that we can’t provide in os.urandom, like the number of bytes that are considered “secure” [1]. What I don’t think is that the secrets module means that all of a sudden os.urandom is no longer an API that is primarily used in a security

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 10.06.2016 21:17, Donald Stufft wrote: On Jun 10, 2016, at 3:05 PM, David Mertz > wrote: OK. My understanding is that Guido ruled out introducing an os.getrandom() API in 3.5.2. But would you be happy if that interface is added to 3.6? It

Re: [Python-Dev] Adding Type[C] to PEP 484

On 15.05.2016 19:30, Guido van Rossum wrote: Right. I still have no good intuition for what Type[BasicUser, ProUser] would mean so I think you should be required to use the Union, which is clear. Type[] should only allow one parameter. Type[A, B] reminds me of isinstance(obj, (A, B)). Sven

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 18:43, Chris Angelico wrote: https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Check https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_CheckExact Thanks for pointing me at this. I searched via github and found usages only:

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 17:29, Brett Cannon wrote: Purposeful change. It was what I had in my head after I posted my "groups" breakdown email and what Guido suggested as well independently. This helps alleviate any perf worries as type checks in C are pointer checks that are cheap to make compared to

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 11:48, Koos Zevenhoven wrote: This issue is coupled with the future optimization questions. AFAIC coupling API design to optimization is called premature optimization. However, the proposed semantics will change if the checks are swapped. So, my actual question is: Is that an

Re: [Python-Dev] file system path protocol PEP

semantics to the PEP. While I hope Brett is asleep in his time zone, I'm guessing he will agree (just saying this because you write "@Brett"). -- Koos On Fri, May 13, 2016 at 10:58 AM, Sven R. Kunze <srku...@mail.de> wrote: On 12.05.2016 18:24, Guido van Rossum wrote: def fspath(p:

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 18:24, Guido van Rossum wrote: def fspath(p: Union[str, bytes, PathLike]) -> Union[str, bytes]: if isinstance(p, (str, bytes)): return p try: return p.__fspath__ except AttributeError: raise TypeError(...) @Brett Would you think it makes sense

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 19:27, Ethan Furman wrote: Maybe, but a bad idea for two reasons: 1) Reducing a str to the exact same str is silly; and, more importantly Finding something silly is no technical argument. Best, Sven ___ Python-Dev mailing list

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 18:56, Ethan Furman wrote: On 05/12/2016 09:26 AM, Sven R. Kunze wrote: str and bytes will receive the __fspath__ attribute when this PEP is accepted? No, they won't. The __fspath__ protocol will reduce the rich path object down to a str/bytes object. Would this make

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 17:42, Ethan Furman wrote: On 05/12/2016 01:31 AM, Sven R. Kunze wrote: I think the "Rationale" section ignores the fact the Path also supports the .path attribute now. Which indeed defines a common interface between path objects. The version of Python that has Pat

Re: [Python-Dev] file system path protocol PEP

On 11.05.2016 23:57, Brett Cannon wrote: On Wed, 11 May 2016 at 14:29 Nikolaus Rath > wrote: On May 11 2016, Brett Cannon > wrote: > This PEP proposes a protocol for classes which represent a

Re: [Python-Dev] file system path protocol PEP

Thanks Brett for your hard work. My comments below: On 11.05.2016 18:43, Brett Cannon wrote: Rationale = Historically in Python, file system paths have been represented as strings or bytes. This choice of representation has stemmed from C's own decision to represent file system paths

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 00:13, Brett Cannon wrote: I see this whole discussion breaking down into a few groups which changes what gets done upfront and what might be done farther down the line: 1. Maximum acceptance: do whatever we can to make all representation of paths just work, which means

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 18:04, Chris Barker wrote: On Tue, Apr 12, 2016 at 7:54 AM, Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: My conclusion is that these changes are not optional and tweaking os, io and shutil is just yet another workaround for a clean

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 16:59, Random832 wrote: Strings are strings. Paths are paths. That's were the difference is. Yes but why aren't these both "things that you may want to use to open a file"? Because "things that you may want to use to open a file" is a bit vague and thus conceal the fact that

Re: [Python-Dev] pathlib - current status of discussions

Sorry for disturbing this thread's harmony. On 12.04.2016 08:00, Ethan Furman wrote: On 04/11/2016 10:14 PM, Chris Barker - NOAA Federal wrote: Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Because

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 12:41, Paul Moore wrote: As your thoughts appear to have been triggered by my comments, I feel I should clarify. 1. I like pathlib even as it is right now, and I'm strongly -1 on removing it. 2. The "external dependency" aspect of 3rd party solutions makes them far less useful to

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

, Apr 11, 2016, at 17:43, Sven R. Kunze wrote: So, I might add: 3. add more high-level features to pathlib to prevent a downgrade to os or os.path 3. reimplement the entire ecosystem in every walled garden so no-one has to leave their walled gardens. What's the point of batteries being included

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:15, Ethan Furman wrote: We've pretty decided that we have two options: 1. remove pathlib 2. make the stdlib work with pathlib So we're trying to make option 2 work before falling back to option 1. If you have a way to make pathlib work with the stdlib that doesn't involve

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:05, Random832 wrote: On Mon, Apr 11, 2016, at 16:48, Sven R. Kunze wrote: On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting something myself. I cannot agree completely. But starting

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:08, Random832 wrote: On Mon, Apr 11, 2016, at 17:04, Sven R. Kunze wrote: PS: The only way out that I can imagine is to fix pathlib. I am not in favor of fixing functions of "os" and "os.path" to except "path" objects; Why not? It occurred to

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 22:55, Alexander Walters wrote: Every conceivable way to fix pathlib have already been argued. Are any of them worth doing? Can we get consensus enough to implement one of them? If not, we should consider either dropping the matter or dropping the module. Right now, I don't

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting something myself. I cannot agree completely. But starting with a comment from Paul, I realized that pathlib is something different than a string.

Re: [Python-Dev] pathlib+os/shutil feedback

On 10.04.2016 16:51, Paul Moore wrote: On 10 April 2016 at 15:07, Sven R. Kunze <srku...@mail.de> wrote: If there's some agreement to change things with respect to those 5 points, I am willing to put some time into it. In broad terms I agree with these points. Thanks for doing the re

[Python-Dev] pathlib+os/shutil feedback

I talked to my colleague. He didn't remember the concrete use-case, though, he instantly mentioned three possible things (no order of preference): 1) pathlib + mtime 2) os.walk and pathlib 3) creation/removal of paths He wasn't too sure but I checked with the docs and his memories seemed to

Re: [Python-Dev] When should pathlib stop being provisional?

On 06.04.2016 23:03, Ethan Furman wrote: On 04/06/2016 01:47 PM, Sven R. Kunze wrote: I still cannot remember what the concrete issue was why we dropped pathlib the same day we gave it a try. It was something really stupid and although I hoped to reduce the size of the code, it was less readable

Re: [Python-Dev] Defining a path protocol

On 06.04.2016 22:55, Brett Cannon wrote: On Wed, 6 Apr 2016 at 13:54 Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: Furthermore, we MIGHT later want some URI support, so I don't know off the top of my head if there's a difference between __fspath__ and

Re: [Python-Dev] Defining a path protocol

On 06.04.2016 22:28, Brett Cannon wrote: On Wed, 6 Apr 2016 at 13:20 Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: What about __file_path__ Can be a directory as well (and you could argue semantics of file system inodes, beginners won't know

Re: [Python-Dev] When should pathlib stop being provisional?

On 06.04.2016 07:00, Guido van Rossum wrote: On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote: [...] we can't do: app_root = Path(...) config = app_root/'settings.cfg' with open(config) as blah: # whatever It feels like instead of addressing this

Re: [Python-Dev] Defining a path protocol

On 06.04.2016 21:02, Alexander Belopolsky wrote: On Wed, Apr 6, 2016 at 2:32 PM, Brett Cannon > wrote: +1 for __path__, +0 for __fspath__ (I don't know how widespread the notion that "fs" means "file system" is). Same here. In the good

Re: [Python-Dev] Opcode cache in ceval loop

On 05.02.2016 00:06, Matthias Bussonnier wrote: On Feb 4, 2016, at 08:22, Sven R. Kunze <srku...@mail.de> wrote: On 04.02.2016 16:57, Matthias Bussonnier wrote: On Feb 3, 2016, at 13:22, Yury Selivanov <yselivanov...@gmail.com> wrote: An ideal way would be to calculate a hit/mis

Re: [Python-Dev] Opcode cache in ceval loop

indows ? Otherwise if you just want a let's say 20% miss threshold, you increment by 1 on hit, and decrement by 4 on miss. Division is expensive. On Feb 3, 2016, at 13:37, Sven R. Kunze <srku...@mail.de> wrote: On 03.02.2016 22:22, Yury Selivanov wrote: One way of tackling this is to give ea

Re: [Python-Dev] More optimisation ideas

On 04.02.2016 14:09, Nick Coghlan wrote: On 2 February 2016 at 06:39, Andrew Barnert via Python-Dev wrote: On Feb 1, 2016, at 09:59, mike.romb...@comcast.net wrote: If the stdlib were to use implicit namespace packages ( https://www.python.org/dev/peps/pep-0420/ ) and

Re: [Python-Dev] Opcode cache in ceval loop

On 03.02.2016 22:22, Yury Selivanov wrote: One way of tackling this is to give each optimized opcode a counter for hit/misses. When we have a "hit" we increment that counter, when it's a miss, we decrement it. Within a given range, I suppose. Like: c = min(c+1, 100) I kind of have

Re: [Python-Dev] Opcode cache in ceval loop

On 02.02.2016 20:41, Yury Selivanov wrote: Hi Victor, On 2016-02-02 4:33 AM, Victor Stinner wrote: Hi, Maybe it's worth to write a PEP to summarize all your changes to optimize CPython? It would avoid to have to follow different threads on the mailing lists, different issues on the bug

Re: [Python-Dev] Speeding up CPython 5-10%

On 02.02.2016 00:27, Greg Ewing wrote: Sven R. Kunze wrote: Are there some resources on why register machines are considered faster than stack machines? If a register VM is faster, it's probably because each register instruction does the work of about 2-3 stack instructions, meaning less

Re: [Python-Dev] Opcode cache in ceval loop

On 01.02.2016 20:51, Yury Selivanov wrote: If LOAD_ATTR gets too many cache misses (20 in my current patch) it gets deoptimized, and the default implementation is used. So if the code is very dynamic - there's no improvement, but no performance penalty either. Will you re-try optimizing it?

Re: [Python-Dev] Opcode cache in ceval loop

On 01.02.2016 21:35, Yury Selivanov wrote: It's important to understand that if we have a lot of cache misses after the code object was executed 1000 times, it doesn't make sense to keep trying to update that cache. It just means that the code, in that particular point, works with different

Re: [Python-Dev] Speeding up CPython 5-10%

On 01.02.2016 19:28, Brett Cannon wrote: A search for [stack vs register based virtual machine] will get you some information. Alright. :) Will go for that. You aren't really supposed to yet. :) In Pyjion's case we are still working on compatibility, let alone trying to show a speed

Re: [Python-Dev] Speeding up CPython 5-10%

On 01.02.2016 18:18, Brett Cannon wrote: On Mon, 1 Feb 2016 at 09:08 Yury Selivanov > wrote: On 2016-01-29 11:28 PM, Steven D'Aprano wrote: > On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote: >> Hi,

Re: [Python-Dev] More optimisation ideas

Thanks, Brett. Wasn't aware of lazy imports as well. I think that one is even better reducing startup time as freezing stdlib. On 31.01.2016 18:57, Brett Cannon wrote: I have opened http://bugs.python.org/issue26252 to track writing the example (and before ppl go playing with the lazy loader,

Re: [Python-Dev] Opcode cache in ceval loop

On 01.02.2016 22:27, Yury Selivanov wrote: Right now they are private constants in ceval.c. I will (maybe) expose a private API via the _testcapi module to re-define them (set them to 1 or 0), only to write better unittests. I have no plans to make those constants public or have a public API

Re: [Python-Dev] Speeding up CPython 5-10%

On 01.02.2016 17:54, Yury Selivanov wrote: If I were to do some big refactoring of the ceval loop, I'd probably consider implementing a register VM. While register VMs are a bit faster than stack VMs (up to 20-30%), they would also allow us to apply more optimizations, and even bolt on a

Re: [Python-Dev] More optimisation ideas

On 30.01.2016 19:20, Serhiy Storchaka wrote: AFAIK the most time is spent in system calls like stat or open. Archiving the stdlib into the ZIP file and using zipimport can decrease Python startup time (perhaps there is an open issue about this). Oh, please don't. One thing I love about Python

Re: [Python-Dev] More optimisation ideas

On 30.01.2016 21:32, Brett Cannon wrote: On Sat, Jan 30, 2016, 12:30 Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: On 30.01.2016 19:20, Serhiy Storchaka wrote: > AFAIK the most time is spent in system calls like stat or open. > Archiving the s

Re: [Python-Dev] FAT Python (lack of) performance

On 27.01.2016 11:59, Terry Reedy wrote: On 1/26/2016 12:35 PM, Sven R. Kunze wrote: I completely agree with INADA. I an not sure you do. I am sure I am. He wants to solve a problem the way that is natural to him as a unique human being. It's like saying, because a specific crossroad

Re: [Python-Dev] FAT Python (lack of) performance

On 27.01.2016 12:16, Nick Coghlan wrote: On 27 January 2016 at 03:35, Sven R. Kunze <srku...@mail.de> wrote: I completely agree with INADA. It's like saying, because a specific crossroad features a higher accident rate, people need to change their driving behavior. No! People won't

Re: [Python-Dev] FAT Python (lack of) performance

On 27.01.2016 19:33, Brett Cannon wrote: And this is why this entire email thread has devolved into a conversation that isn't really going anywhere. This whole thread has completely lost track of the point of Victor's earlier email saying "I'm still working on my FAT work and don't take any

Re: [Python-Dev] FAT Python (lack of) performance

Hi, will look into it soon. :) Best, Sven On 26.01.2016 16:32, Victor Stinner wrote: Hi, 2016-01-26 3:21 GMT+01:00 INADA Naoki : How can I help your work? I don't know exactly yet, but I started to write a documentation to explain how to contribute:

Re: [Python-Dev] FAT Python (lack of) performance

I completely agree with INADA. It's like saying, because a specific crossroad features a higher accident rate, *people need to change their driving behavior*. *No!* People won't change and it's not necessary either. The crossroad needs to be changed to be safer. Same goes for Python. If

Re: [Python-Dev] FAT Python (lack of) performance

Hi Victor, I encourage you to proceed here. I would love to see your PEPs (509-511) incorporated into CPython. It's not that I consider Python slow (although some folks claim so), but performance improvements are always welcome; especially when I glance over diagrams like those:

Re: [Python-Dev] Code formatter bot

Not a core dev, but I would definitely recommend using them. Best, Sven On 19.01.2016 21:59, francismb wrote: Dear Core-Devs, what's your opinion about a code-formatter bot for cpython. Pros, Cons, where could be applicable (new commits, new workflow, it doesn't make sense), ... - At least

Re: [Python-Dev] Asynchronous context manager in a typical network server

On 18.12.2015 22:09, Guido van Rossum wrote: I guess we could make the default arg to sleep() 1e9. Or make it None and special-case it. I don't feel strongly about this -- I'm not sure how baffling it would be to accidentally leave out the delay and find your code sleeps forever rather than

Re: [Python-Dev] Second milestone of FAT Python

typo: "chance" instead of "change" On 04.11.2015 21:14, Sven R. Kunze wrote: Hi Victor, great to hear. I think everybody here appreciates your efforts. Do you think there will be any change of merging this back into CPython? Best, Sven On 04.11.2015 09:50, Victor Stin

Re: [Python-Dev] Second milestone of FAT Python

Hi Victor, great to hear. I think everybody here appreciates your efforts. Do you think there will be any change of merging this back into CPython? Best, Sven On 04.11.2015 09:50, Victor Stinner wrote: Hi, I'm writing a new "FAT Python" project to try to implement optimizations in CPython

  1   2   >