[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

ish". We need to say "won't fix" anyway. Do we need to do anything here to move forward on this issue? I've chatted with Larry and Mark Shannon, who have some additional thoughts and I'm sure will chime in. My only comment concerned performance. I won't c

[Python-Dev] PEP 667: Consistent views of namespaces

558 but is simpler and more consistent internally, at the expense of some minor C API backwards incompatibility issues. PEP 558 also has backwards incompatibility issues, but claims to be more compatible at the C API level. Cheers, Mark. ___ Python

[Python-Dev] Re: PEP 667: Consistent views of namespaces

Hi Nick, On 22/08/2021 4:51 am, Nick Coghlan wrote: On Sun, 22 Aug 2021, 10:47 am Guido van Rossum, <mailto:gu...@python.org>> wrote: Hopefully anyone is still reading python-dev. I'm going to try to summarize the differences between the two proposals, even thoug

[Python-Dev] Re: PEP 667: Consistent views of namespaces

Hi Guido, On 23/08/2021 3:53 pm, Guido van Rossum wrote: On Mon, Aug 23, 2021 at 4:38 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi Nick, On 22/08/2021 4:51 am, Nick Coghlan wrote: > If Mark's claim that PyEval_GetLocals() could not be fixed was true th

[Python-Dev] How to decipher Windows errors on builds?

error RC1116: RC terminating after preprocessor errors [D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj] Can anyone translate that into English for me? It suggests that there are errors in the preprocessor. But how do I tell what the error is? Cheers,

[Python-Dev] Re: PEP 654 except* formatting

Another +1 for `except group` from me. On 04/10/2021 2:57 pm, Ammar Askar wrote: Throwing in another +1 for `except group`. It's explicit, doesn't introduce new punctuation and avoids confusion with unpacking. Regards, Ammar On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

is: what things should be comparable? and this is something that has not been settled. Nor do I believe it can be by the language. This is where I rather liked the old __cmp__ function, not only was it easier to implement, but I could define a comparison and it was clearer that I was doing

Re: [Python-Dev] Introducing Electronic Contributor Agreements

contribute, wouldn't this requirement make the situation worse? -- Cheers. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On 04/03/2013 22:08, Brett Cannon wrote: On Mon, Mar 4, 2013 at 4:33 PM, Mark Lawrence mailto:breamore...@yahoo.co.uk>> wrote: On 04/03/2013 20:46, Terry Reedy wrote: On 3/4/2013 11:36 AM, Brett Cannon wrote: On Mon, Mar 4, 2013 at 11:30 AM, Brian

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 7:57 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > On Mar 20, 2013, at 12:38 PM, Barry Warsaw wrote: > > Right. Ultimately, I think IDLE should be a separate project entirely, > but I > guess there's push back against that too. > > > The most important f

Re: [Python-Dev] IDLE in the stdlib

. The "editor-centric paradigm" has not created a community of re-usable code, despite all the promises. I'll argue that the *interpreter environment* will be the future and the editor will be relegated to a simple memory-saving device. Mark Tacoma, Washington __

Re: [Python-Dev] IDLE in the stdlib

On Thu, Mar 21, 2013 at 2:31 PM, Oleg Broytman wrote: > On Thu, Mar 21, 2013 at 02:19:33PM -0700, Mark Janssen < > dreamingforw...@gmail.com> wrote: > > The *only* thing I find "ugly" about it is that it doesn't have a > > white-on-black color scheme. L

Re: [Python-Dev] IDLE in the stdlib

x27;s bundled with the standard distribution. > > > > Just like a lot of the stdlib, it *gets* a lot of usefulness from > > being a battery. But just because there are better/more > > comprehensive/prettier replacements out ther

[Python-Dev] Semantics of __int__(), __index__()

o 1 and 2. I had previously assumed (and would expect) that the answers were: 1. Any subclass is OK 2. Ditto 3. Yes 4. Yes Which means that def is_int(x): return int in type(x).__mro__ is_index = is_int Cheers, Mark. ___ Python-Dev m

Re: [Python-Dev] Semantics of __int__(), __index__()

On Sun, Mar 31, 2013 at 2:29 PM, Mark Shannon wrote: > class Int1(int): > def __init__(self, val=0): > print("new %s" % self.__class__) > > class Int2(Int1): > def __int__(self): > return self > > and two instances > i1 = Int1(

Re: [Python-Dev] Semantics of __int__(), __index__()

pped back to just the base > class. > Can you point me to that code? All I could find was PyLong_Check calls (I was looking for PyLong_CheckExact). Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-

Re: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 8:07 AM, Mark Dickinson wrote: > On Tue, Apr 2, 2013 at 1:44 AM, Nick Coghlan wrote: > >> There's code in the slot wrappers so that if you return a non-int object >> from either __int__ or __index__, then the interpreter will complain about >

Re: [Python-Dev] Semantics of __int__(), __index__()

On 02/04/13 01:44, Nick Coghlan wrote: On Mon, Apr 1, 2013 at 12:28 AM, Mark Dickinson mailto:dicki...@gmail.com>> wrote: As written, int_check would do the wrong thing for bools, too: I definitely want int(True) to be 1, not True. For (2) and (4), it's not so clear.

Re: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon wrote: > > Hence my original question: what *should* the semantics be? > > I like Nick's answer to that: int *should* always return something of exact type int. Otherwise you're always left wondering whether you have to do &qu

Re: [Python-Dev] Semantics of __int__(), __index__()

d definitely be using __index__. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 10:02 AM, Mark Dickinson wrote: > On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski wrote: > >> >> My 2 cents here is that which one is called seems to be truly random. >> Try looking into what builtin functions call (for example list.pop &g

Re: [Python-Dev] Semantics of __int__(), __index__()

e > type, so deprecation of subtypes makes sense as a way forward. We should > check the other type coercion methods, too.) > Agreed on both points. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-d

Re: [Python-Dev] Semantics of __int__(), __index__()

__ > as a backup. > It uses __trunc__, which is supposed to be the unambiguous "Yes I really want to throw away the fractional part and risk losing information" replacement for __int__. int() will try __int__ first, and then __trunc_

Re: [Python-Dev] The end of 2.7

is planned to be a gradual thing for the next year, at least. From http://wiki.wxpython.org/ProjectPhoenix "WooHoo! Phoenix runs on Python 3!! " --Stephen -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython.

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/19/2013 10:48 AM, Guido van Rossum wrote: >> Anyway, if you're doing arithmetic on enums you're doing it wrong. > > Hmm, bitwise operations, even? I think it's rather pointless to do bi

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

rogram to determine the execution environment for the doctests. > picking-your-poison-ly y'rs - tim Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What if we didn't have repr?

> I have pondered it many times, although usually in the form "Why do we > need both str and repr?" Here's an idea: considering python objects are "stateful". Make a general, state-query operator: "?". Then the distinction is clear. >>> ?"This is a string" #Returns the contents of the string

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

t-code-test cycle for TDD and agile development. --Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 and function names

understood what you meant. :-) Yet another reference to Orwell's worst room in the world, what does this imply about Python? :) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence _

Re: [Python-Dev] cpython: Introduce importlib.util.ModuleManager which is a context manager to

meanings. Once you've answered that question you should have your name. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] doctest and pickle

> >>> from pickle import dumps, loads > >>> Fruit.tomato is loads(dumps(Fruit.tomato)) > True Why are you using is here instead of ==? You're making a circular loop using "is" -- MarkJ Tacoma, Washington ___ Python-Dev mailing list Python-D

Re: [Python-Dev] doctest and pickle

On Fri, Jun 7, 2013 at 10:50 AM, Mark Janssen wrote: >> >>> from pickle import dumps, loads >> >>> Fruit.tomato is loads(dumps(Fruit.tomato)) >> True > > Why are you using is here instead of ==? You're making a circular > loop usi

Re: [Python-Dev] doctest and pickle

>> Why are you using is here instead of ==? > > > I'm using `is` because I'm verifying that the instance returned by > `pickle.loads` is the exact same object as the instance fed into > `pickle.dumps`. Enum members should be singletons. I see now. That makes sense, but I don't think you'll be ab

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

> It's like this. Whenever you use special characters in a file name, > you're asking for trouble. The shell and the OS have negotiate how to > interpret it. It bigger than git, and not a bug. Sorry, I meant mercurial, not git. -- MarkJ Tacoma, Washington __

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

> One month ago, unit tests were added to IDLE (cool!) with a file > called @README.txt. The @ was used to see the name on top in a listing > of the directory. It's like this. Whenever you use special characters in a file name, you're asking for trouble. The shell and the OS have negotiate how t

Re: [Python-Dev] PEP 450 adding statistics module

that takes a string specifying computation using a particular method. I don't see a really good reason to deviate from standard patterns here, and fear that users would find the current API surprising. Mark On Thu, Aug 15, 2013 at 2:25 AM, Steven D'Aprano wrote: > Hi all, > >

Re: [Python-Dev] PEP 450 adding statistics module

ons 'median', 'median_low', 'median_high', etc., or have a single function 'median' with a "method" argument that takes a string specifying computation using a particular method. I don't see a really good reason to deviate from standard patterns here

Re: [Python-Dev] PEP 450 adding statistics module

I'd like the hear the opinion of other python-dev readers. Thanks for the detailed replies. Would it be possible to put some of this reasoning into the PEP? Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/li

Re: [Python-Dev] PEP 450 adding statistics module

cs import median; m = median(my_data)" should still work in the simple case. Mark > > Steven D'Aprano wrote: > >> On 15/08/13 21:42, Mark Dickinson wrote: >> >>> The PEP and code look generally good to me. >>> >>> I think the API

Re: [Python-Dev] PEP 450 adding statistics module

On 15/08/13 14:08, Steven D'Aprano wrote: On 15/08/13 21:42, Mark Dickinson wrote: The PEP and code look generally good to me. I think the API for median and its variants deserves some wider discussion: the reference implementation has a callable 'median', and variant callab

Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.

e dummy from regular set contents, anymore :-) It should be fixable, but I don't know how. By giving the dummy object a custom type, the dummy object can be recognised by testing that its type equals PySetDummy_Type (or whatever it is called) S

Re: [Python-Dev] PEP 447: add type.__locallookup__

I'll look into it this evening. On 09/09/13 17:03, Guido van Rossum wrote: OK, how much time do you need? --Guido van Rossum (sent from Android phone) On Sep 9, 2013 8:44 AM, "Mark Shannon" mailto:m...@hotpy.org>> wrote: I would like time to investigate this further

Re: [Python-Dev] PEP 447: add type.__locallookup__

, Mark. On 09/09/13 16:27, Guido van Rossum wrote: Let's just accept this PEP. It looks like a nice addition to the metaclass machinery and I don't think we'll get much more useful feedback by waiting. On Mon, Sep 9, 2013 at 7:30 AM, Ethan Furman mailto:et...@stoneleaf.us>>

Re: [Python-Dev] PEP 447: add type.__locallookup__

hat do the Jython/IronPython/PyPy developers think? Cheers, Mark. p.s. Apologies for top-posting earlier ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailm

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 09/09/13 22:25, Benjamin Peterson wrote: 2013/9/9 Mark Shannon : On 09/09/13 15:30, Ethan Furman wrote: On 07/30/2013 11:17 PM, Ronald Oussoren wrote: And something I forgot to ask: is anyone willing to be the BDFL-Delegate for PEP 447? *Bump*. It would be nice if this could make

Re: [Python-Dev] PEP 455: TransformDict

On 14/09/13 23:31, Eli Bendersky wrote: On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka mailto:storch...@gmail.com>> wrote: 14.09.13 20:41, Antoine Pitrou написав(ла): No good reason. What's the name? transform_func? transform_func looks... truncated. Why not transform_fu

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

27;ve tried this, got the (rather cyptic) "error: Unable to find vcvarsall.bat" message and then gone off to find a suitable binary download. -- Cheers. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mail

Re: [Python-Dev] toolbar

its still absent. Thank you. Further to other replies you might be better off on the tutor mailing list see https://mail.python.org/mailman/listinfo/tutor -- Cheers. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https

Re: [Python-Dev] PEP 455: TransformDict

Sorry I missed the original discussion, but isn't this a simple case of putting a decorator around the getitem method (to transform the input key) and a single line in the body of the setitem method, making this very easy adaptation of the existing dict class?

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

n't define it. We already do this for non-parameter locals and it could be extended to parameters. 'range' would be defined thus: def range([start,] stop, [step], /): try: start except UnboundLocalError: start = 0 try: step except UnboundLocalEr

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

ttle or no chance :( -- Roses are red, Violets are blue, Most poems rhyme, But this one doesn't. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.pyt

[Python-Dev] Thanks everybody (was Summary of Python tracker Issues)

ou to everybody involved for the work that has been put in. I for one certainly appreciate your efforts. -- Roses are red, Violets are blue, Most poems rhyme, But this one doesn't. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python

Re: [Python-Dev] Support keyword in PEP URL?

PEP index? -- Roses are red, Violets are blue, Most poems rhyme, But this one doesn't. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailma

Re: [Python-Dev] frame evaluation API PEP

ido%40python.org -- --Guido van Rossum (python.org/~guido <http://python.org/~guido>) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mark%40hotpy.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Idea: more compact, interned string key only dict for namespace.

really two objects, the object and its dict, so that is 48 extra bytes every time you create a new object. Cheers, Mark. On 22/06/16 10:23, INADA Naoki wrote: As my last email, compact ordered dict can't preserve insertion order of key sharing dict (PEP 412). I'm thinking about depreca

[Python-Dev] Please reject or postpone PEP 526

ment statements and were primarily intended for use in stub files. Please don't turn Python into some sort of inferior Java. There is potential in this PEP, but in its current form I think it should be rejected. Cheers, Mark. ___ Python-D

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

le syntax? No. I think that defining the type of variables, rather than expressions is a bad idea. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.py

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

sure whether I agree with Mark on this particular point, but the difference I see here is that the first describes what types x may ever contain, while the latter describes what type of being assigned to x right here. So one is a variable annotation while the other is an expression annotation. Ul

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

er I agree with Mark on this particular point, but the difference I see here is that the first describes what types x may ever contain, while the latter describes what type of being assigned to x right here. So one is a variable annotation while the other is an expression annotation. But that&

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

On 04/09/16 11:57, Chris Angelico wrote: On Sun, Sep 4, 2016 at 8:52 PM, Mark Shannon wrote: The key difference is in placement. PEP 484 style variable = value # annotation Which reads to me as if the annotation refers to the value. PEP 526 variable: annotation = value Which reads very

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

as type checkers are not affected by the feature freeze. Indeed, we shouldn't panic. We should take our time, review this carefully and make sure that the version of typehints that lands in 3.7 is one that we most of us are happy with and all of us can at least tolerate. Cheers,

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

ot;type of a variable" actually mean, and why aren't the other uses of `x` int as well? Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/

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

On 05/09/16 23:16, Greg Ewing wrote: Mark Shannon wrote: Unless of course, others may have a different idea of what the "type of a variable" means. To me, it means it means that for all assignments `var = expr` the type of `expr` must be a subtype of the variable, and for all u

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

On 05/09/16 18:40, Guido van Rossum wrote: On Mon, Sep 5, 2016 at 8:26 AM, Mark Shannon wrote: PEP 526 states that "This PEP aims at adding syntax to Python for annotating the types of variables" and Guido seems quite insistent that the declarations are for the types of variables

Re: [Python-Dev] Drastically improving list.sort() for lists of strings/ints

> I am interested in making a non-trivial improvement to list.sort() [...] Would your proposed new sorting algorithm be stable? The language currently guarantees stability for `list.sort` and `sorted`. -- Mark ___ Python-Dev mailing list Python-

Re: [Python-Dev] Drastically improving list.sort() for lists of strings/ints

n already sorted list with a few extra unsorted elements appended). This is a case that does arise in practice, and that Timsort performs particularly well on. -- Mark ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailma

[Python-Dev] Clarification for concurrent.futures.Future

statement makes us hesitate to use it. We don't need the executor functionality. We can write our own future class easily enough, we're just wondering what the justification was for the limitations mentioned in the docs. Thanks, Mark Spruiell ZeroC, Inc. __

Re: [Python-Dev] bugs.python.org access problems

Hi All, The new cert has been installed. Let me know if you have any issues. https://bugs.python.org/ Best regards, Mark On Sat, Feb 11, 2017 at 11:09 AM, Brett Cannon wrote: > I emailed the infrastructure team and Mark Mangoba replied back saying > it's because the SSL c

Re: [Python-Dev] Micro-optimizations by adding special-case bytecodes?

suggesting is an ad-hoc form of what is known as "static superinstructions". Take a look at http://www.complang.tuwien.ac.at/projects/interpreters.html Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailma

Re: [Python-Dev] PEP 544: Protocols - second round

isinstance' and 'issubclass' should be removed. Type-hints should not have runtime semantics, beyond those that they have as classes. In fact, there is no need for protocol types to be classes at all. Cheers, Mark. ___ Python-De

Re: [Python-Dev] Micro-optimizations by adding special-case bytecodes?

On 25/05/17 03:47, Victor Stinner wrote: Hi Ben, I am not convinced that combining operations will have a significant impact in term of performance. Mark Shanon implemented that in his HotPy project. I don't think that I did ;) HotPy implemented a trace-based optimising interpreter,

Re: [Python-Dev] 64 bit units in PyLong

so there would be more opportunities to take fast paths, but there would need to be benchmarks demonstrating that. Oh, and you'd have to rewrite the power algorithm, which currently depends on the size of a limb in bytes being a multiple of 5. :-) -- Mark ___

[Python-Dev] bugs.python.org - outage 08/09/17 until 8:00pm PST

n the next 3 months. Best regards, Mark Mark Mangoba | PSF IT Manager | Python Software Foundation | mmang...@python.org | python.org | Infrastructure Staff: infrastructure-st...@python.org | GPG: 2DE4 D92B 739C 649B EBB8 CCF6 DC05 E024 5F4C A0D1 __

[Python-Dev] Re: What is __int__ still useful for?

python.org/issue44977 Mark On Thu, Oct 14, 2021 at 11:50 AM Serhiy Storchaka wrote: > 14.10.21 12:24, Eryk Sun пише: > > Maybe an alternate constructor could be added -- such as > > int.from_number() -- which would be restricted to calling __int__(), > > __index__(), and __

[Python-Dev] Re: What is __int__ still useful for?

Meta: apologies for failing to trim the context in the previous post. -- Mark ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org

[Python-Dev] Re: Optimizing literal comparisons and contains

On 28/11/2021 6:28 am, raymond.hettin...@gmail.com wrote: For the benefit of the audience on python-dev, you should also mention that this proposal and associated PR has been twice discussed and rejected on the tracker: https://bugs.python.org/issue45907 https://bugs.python.org/issu

[Python-Dev] Re: Optimizing literal comparisons and contains

are falsey) Excluding 1 < 2 seems inconsistent. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archi

[Python-Dev] PEP 669: Low Impact Monitoring for CPython

ad the PEP here: https://python.github.io/peps/pep-0669/ Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message a

[Python-Dev] Re: [RELEASE] Python 3.11.0a3 is available

rmance benchmarks](speed.python.org <http://speed.python.org>), compared to 3.10.0. Actually, it is quite a lot better than that at 19% on the standard benchmark suite :) https://gist.github.com/markshannon/0ddfb0b705d23b863477d7f7f9f00ef1

[Python-Dev] Re: RFC on Callable Syntax PEP

s you are playing code golf, that shouldn't matter. Cheers, Mark. On 16/12/2021 5:57 pm, Steven Troxler wrote: Hello all, Thanks everyone for comments on our earlier thread [1] about callable type syntax. We now have a draft PEP [2] proposing an arrow-based syntax for callable type

[Python-Dev] Re: RFC on Callable Syntax PEP

OOI, of those 1577 Callable type hints, how many distinct Callable types? On 20/12/2021 7:52 am, Andrew Svetlov wrote: At my job, we have 1577 Callable type hints scattered in 1063 Python files. For comparison, this codebase also has 2754 dict annotations and 1835 list ones. On Mon, Dec 20, 20

[Python-Dev] Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

it` type, `a + b` can't currently safely (i.e., without undefined behaviour from overflow) be computed with the C type `sdigit`. With 30-bit digits and a 32-bit `digit` and `sdigit` type, `a + b` is safe. Mark *References* Related b.p.o. issue: https://bugs.python.org/issue45569 MinGW compatibili

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

0-bit digits, then there's a case for at least making 30-bit digits the default, which would be a first step towards eventually dropping that support. GPS: I'm not immediately seeing the ABI issue. If you're able to dig up more information on that, I'd be interested to see it. Mark

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

bots": there's a 32-bit Gentoo buildbot that's (implicitly) using 15-bit digits, and the GitHub Actions Windows/x86 build also uses 15-bit digits. I don't think we have anything that's explicitly using the `--enable-big-digits` option, though. -- Mark __

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

://en.wikipedia.org/wiki/ARM_architecture#Arithmetic_instructions: "ARM supports 32-bit × 32-bit multiplies with either a 32-bit result or 64-bit result, though Cortex-M0 / M0+ / M1 cores don't support 64-bit results.") Division may still be problematic. -- Mark

[Python-Dev] Re: Python 3.11.0a4 is blocked

Hi Pablo, Issue 43683 should not have been marked as a release blocker, as it is a performance issue, not a bug. The related bug (which was a release blocker) is https://bugs.python.org/issue46009, and was fixed a while ago. Cheers, Mark. On 04/01/2022 11:12 pm, Pablo Galindo Salgado wrote

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 2, 2022 at 10:35 AM Mark Dickinson wrote: > Division may still be problematic. > On that note: Python divisions are somewhat crippled even on x64. Assuming 30-bit digits, the basic building block that's needed for multi-precision division is a 64-bit-by-32-bit unsig

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sat, Jan 15, 2022 at 8:12 PM Tim Peters wrote: > Something is missing here, but can't guess what without seeing the > generated machine code.But I trust Mark will do that. > Welp, there goes my weekend. :-) $ python -m timeit -n 150 -s "x = 10**1000" "x//

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

tions where you have a divisor not known at compile time but you know you're going to be using it often enough to compensate for the cost of computing the magic multiplier dynamically at run time. [1] https://libdivide.com -- Mark ___ Python-Dev

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 16, 2022 at 12:08 PM Mark Dickinson wrote: > So gcc is anticipating divisions by 10 and introducing special-case > divide-by-reciprocal-multiply code for that case, and presumably the > profile generated for the PGO backs up this being a common enough case, so > we end

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

rsion by comparing with an obviously-correct repeated-division-by-10 algorithm. Then again I'm not sure what's *lost* even if this optimization is > pointless -- surely it doesn't slow other divisions down enough to be > measurable. > Agreed. That at least is testable. I

[Python-Dev] Re: [Steering-council] Re: PEP 651, Robust Stack Overflow Handling, Rejection notice

Ditto ... On Fri, Mar 5, 2021 at 7:04 AM Mark Shannon mailto:m...@hotpy.org>> wrote: [...] In some cases, the PEP would have improved the situation. For example: sys.setrecursionlimit(5000) def f():      f()

[Python-Dev] Should we require IEEE 754 floating-point for CPython?

x27;s a Py_NO_NAN macro that builders can define to indicate that NaNs aren't supported, but the Python build is currently broken if Py_NO_NAN is defined (see https://bugs.python.org/issue46656). If the answer to the first question is "N

[Python-Dev] Re: Compiling of ast.Module in Python 3.10 and co_firstlineno behavior

Hi Fabio, This happened as part of implementing PEP 626. The previous behavior isn't very robust w.r.t doc strings and compiler optimizations. OOI, why would you want to revert to the old behavior? Cheers, Mark. On 17/02/2022 5:52 pm, Fabio Zadrozny wrote: Hi all, I'm stumbli

[Python-Dev] Re: Compiling of ast.Module in Python 3.10 and co_firstlineno behavior

Hi Fabio, On 17/02/2022 7:30 pm, Fabio Zadrozny wrote: Em qui., 17 de fev. de 2022 às 16:05, Mark Shannon mailto:m...@hotpy.org>> escreveu: Hi Fabio, This happened as part of implementing PEP 626. The previous behavior isn't very robust w.r.t doc strings and

[Python-Dev] Re: PEP 682: Format Specifier for Signed Zero

PEP 682 (Format Specifier for Signed Zero) has been accepted! Please see https://discuss.python.org/t/accepting-pep-682-format-specifier-for-signed-zero/14088 Thanks to all involved, Mark ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

t PEP 523 isn't used. Cheers, Mark. API: * _PyFrameEvalFunction type * _PyInterpreterState_GetEvalFrameFunc() * _PyInterpreterState_SetEvalFrameFunc() * (undocumented) _PyEval_EvalFrameDefault() The private API to get/set the eval function *is* documented at: https://docs.python.org/d

[Python-Dev] Re: code.replace() and Python 3.11 exception table

nothing new. The bytecode library already recomputes the consts, names, etc. TBH, calling `types.CodeType` didn't work for earlier versions either. It just sort of worked, some of the time. Cheers, Mark. https://github.com/MatthieuDartiailh/bytecode

[Python-Dev] Latest version of PEP 669 -- Low Impact Monitoring for CPython

e steering council in a month or so. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived

[Python-Dev] Re: Stalemate on bringing back PEP 523 support into Python 3.8

ts (both local and global variables) * Callbacks for events (call/return/exception/entry/exit/line). Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org

<    1   2   3   4   5   6   7   8   9   10   >