[Python-Dev] Re: Deprecating the "u" string literal prefix

On 12/3/19 6:31 PM, Guido van Rossum wrote: > I think it’s too soon to worry about this. I don’t see a reason to harass > people who maintain code based that were just recently migrated. +1 ... or code that will be migrated in the (near) future ;-) ... Regards, fra

[Python-Dev] OT?: Re: Possible performance regression

Hi, just curious on this, On 2/25/19 5:54 AM, Raymond Hettinger wrote: > I'll been running benchmarks that have been stable for a while. But between > today and yesterday, there has been an almost across the board performance > regression. > > It's possible that this is a measurement error or

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Hi David, On 10/22/2017 07:30 PM, David Mertz wrote: > The 'time' module is about > wall clock out calendar time, not about *simulation time*. means that the other scale direction makes more sense for the module? aka 'get_time('us'), get_time('ms'), 'get_time('s') Thanks, --francis

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

If it sounds as there is no need or is unnecessary to you then it its ok :-), thank you for the feedback ! I'm just curious on: On 10/21/2017 05:45 PM, Guido van Rossum wrote: > That sounds like unnecessary generality, Meaning that the selection of precision on running time 'costs'? I

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Hi Victor, On 10/18/2017 01:14 AM, Victor Stinner wrote: > I updated my PEP 564 to add time.process_time_ns(): > https://github.com/python/peps/blob/master/pep-0564.rst > > The HTML version should be updated shortly: > https://www.python.org/dev/peps/pep-0564/ ** In practive, the resolution of

[Python-Dev] PEP 554 v3 (new interpreters module) - channel type

Hi Eric, >> To make this work, the mutable shared state will be managed by the >> Python runtime, not by any of the interpreters. Initially we will >> support only one type of objects for shared state: the channels >> provided by create_channel(). Channels, in turn, will carefully >> manage

Re: [Python-Dev] Evil reference cycles caused Exception.__traceback__

Hi, just curious on this, On 09/18/2017 10:54 PM, Antoine Pitrou wrote: >> I'm not an expert on GC at all, but intuitively it sure seems like >> allocation size might be a useful piece of information to feed into a >> heuristic. Our current heuristic is just, run a small collection after >> every

Re: [Python-Dev] PEP 550 v4

Hi, > Multithreaded Code > -- > > In multithreaded code, context variables behave like thread locals:: > > var = new_context_var() > > def sub(): > assert var.lookup() is None # The execution context is empty > # for each

Re: [Python-Dev] PEP 550 v4

Hi, > > For the purpose of this section, we define *execution context* as an > opaque container of non-local state that allows consistent access to > its contents in the concurrent execution environment. > May be nonsense/non-practical :-), but : - How extrapolates this concept to the whole

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

>> I propose RaymondLuxuryYach_t, but we’ll have to pronounce it >> ThroatwobblerMangrove. > > Sorry, but I think we should prononce it ThroatwobblerMangrove. > too hard to pronounce but at least is unique, I would prefer thredarena but I see naming is hard ... :-) Thanks! --francis

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

Hi, On 08/24/2017 03:52 PM, Barry Warsaw wrote: > Guido van Rossum wrote: >> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote: >> >> I worry that that's going to lead more people astray thinking this has >> something to do with contextlib, which it really doesn't (it's much

Re: [Python-Dev] PEP 550 v3

Hi Yury, On 08/18/2017 10:33 PM, Yury Selivanov wrote: > * ``.get()`` method: return the current EC value for the context key. > Context keys return ``None`` when the key is missing, so the method > never fails. Is the difference between `Key not found` and `value is None` important here?

Re: [Python-Dev] Articles on my contributions to CPython during 2017 Q1 and Q2

Hi Victor, On 07/13/2017 05:33 PM, Victor Stinner wrote: > Hi, > > I wrote a serie of new articles on my contributions to CPython during > 2017 Q1 and Q2. > > "My contributions to CPython during 2017 Q1" > https://haypo.github.io/contrib-cpython-2017q1.html > > "New Python test.bisect tool" >

Re: [Python-Dev] PEP 8 updated on whether to break before or after a binary update

Hi, On 04/15/2016 07:43 PM, Guido van Rossum wrote: > The update is already serving its real purpose: showing that style is > debatable and cannot always easily be reduced to fixed rules. > As you said, there will be always some kind personal preferences or style taste and one can see on the

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

Hi, On 02/08/2016 06:44 PM, Victor Stinner wrote: > Hi, > > I changed the Python compiler to ignore any kind "constant > expressions", whereas it only ignored strings and integers before: > http://bugs.python.org/issue26204 > > The compiler now also emits a SyntaxWarning on such case. IMHO the

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

Hi, On 02/01/2016 10:43 PM, Yury Selivanov wrote: > > We also need to deoptimize the code to avoid having too many cache > misses/pointless cache updates. I found that, for instance, LOAD_ATTR > is either super stable (hits 100% of times), or really unstable, so 20 > misses is, again, seems to

Re: [Python-Dev] More optimisation ideas

Hi, > > Storing these in static data is a tradeoff between > disk space and startup performance, and one I think it likely to be > worthwhile. it's really an important trade off? As far a I understand from your email those modules are always being loaded and the final data created. won't the

Re: [Python-Dev] Code formatter bot

Hi, On 01/25/2016 01:28 AM, Raymond Hettinger wrote: > >> - At least it should follow PEP 7 ;-) > > Please don't do this. It misses the spirit of how the style-guides are > intended to be used. > > "I personally hate with a vengeance that there are tools named after style > guide PEPs that

Re: [Python-Dev] Code formatter bot

Hi, from your valuable feedback, here is what I thing could be a previous requirements list (lets call it for e.g. autopep7 script by now): - It should follow PEP 7 :-) - It should check PEP 7 compliance on a per file basis (for simplicity) - It should be embeddable on the test suite, returning

Re: [Python-Dev] do people use sys._mercurial?

Hi, On 01/24/2016 01:17 PM, Nick Coghlan wrote: > > Linux distros tend to build Python from a tarball rather than a source > checkout, for example, which means the build directory doesn't include > any VCS details: > Does that helps traceability (reproducibility)? If distros use (?) the tarball

Re: [Python-Dev] do people use sys._mercurial?

Hi, On 01/23/2016 12:44 AM, Brett Cannon wrote: > Since we are going to be switching over to Git, sys._mercurial is going to > be made to return a dummy value of `('CPython', '', '')` once we switch to > Git. for me sys._mercurial it's already returning that (?) : what should return now? (it's a

Re: [Python-Dev] Code formatter bot

Thanks again to all persons that commented so far. > 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 it should follow PEP 7 ;-) > - ... There seems to be too much

[Python-Dev] Code formatter bot

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 it should follow PEP 7 ;-) - ... Thanks in advance, francis ___

Re: [Python-Dev] Update PEP 7 to require curly braces in C

Hi Brett, On 01/19/2016 12:20 AM, Brett Cannon wrote: > On Sun, 17 Jan 2016 at 11:10 Brett Cannon wrote: > >> While doing a review of http://bugs.python.org/review/26129/ I asked to >> have curly braces put around all `if` statement bodies. Serhiy pointed out >> that PEP 7

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

>> Sometimes order matters, and sometimes it does not. If the order does >> not have an impact on the final code, it does not matter, and making >> us have to remember an order that does not matter is a waste. > > Order that matters? You must be kidding. That would turn different types > of

Re: [Python-Dev] PEP 495 accepted

On 09/24/2015 04:47 AM, Nick Coghlan wrote: > On 24 Sep 2015 01:21, "Tim Peters" wrote: > >> >> Guido's reply gave a clearer invariant: >> >> dt.timestamp() == >> dt.astimezone(utc).timestamp() == >> dt.astimezone().timestamp() >> > Might it be worth