[Python-Dev] PEP proposal to limit various aspects of a Python program to one million.

Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the lines of code per module. Any thoughts or feedback? The PEP: https://github.com/markshannon/peps/blob/one-million/pep-100.rst Cheers, Mark

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On 04/12/2019 2:31 am, Gregory P. Smith wrote: On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On 05/12/2019 12:45 pm, Karthikeyan wrote: On Thu, Dec 5, 2019, 5:53 PM Mark Shannon <mailto:m...@hotpy.org>> wrote: On 04/12/2019 2:31 am, Gregory P. Smith wrote: > > > On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon mailto:m...@hotpy.org> >

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On 03/12/2019 5:22 pm, Steve Dower wrote: On 03Dec2019 0815, Mark Shannon wrote: Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the lines of code per module. I assume you're aimin

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

Hi Guido, On 04/12/2019 3:51 pm, Guido van Rossum wrote: I am overwhelmed by this thread (and a few other things in real life) but here are some thoughts. 1. It seems the PEP doesn't sufficiently show that there is a problem to be solved. There are claims of inefficiency but these aren't sub

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

Hi, On 05/12/2019 12:54 pm, Tal Einat wrote: On Tue, Dec 3, 2019 at 6:23 PM Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the

[Python-Dev] PEP 611: The one million limit.

Hi Everyone, Thanks for all your feedback on my proposed PEP. I've editing the PEP in light of all your comments and it is now hopefully more precise and with better justification. https://github.com/python/peps/pull/1249 Cheers, Mark. ___ P

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

Hi Oscar, Thanks for the feedback. On 07/12/2019 7:37 pm, Oscar Benjamin wrote: On Sat, 7 Dec 2019 at 06:29, Steven D'Aprano wrote: A million seems reasonable for lines of source code, if we're prepared to tell people using machine generated code to split their humongous .py files into mul

[Python-Dev] Please be more precise when commenting on PEP 611.

large limits, then I wouldn't have proposed the PEP in the first place. Bear in mind that the costs of higher limits are paid by everyone, but the benefits are gained by few. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.o

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 09/12/2019 2:15 pm, Chris Angelico wrote: On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon wrote: Bear in mind that the costs of higher limits are paid by everyone, but the benefits are gained by few. Can we get some stats on what the costs of higher limits (or having no limit at all) is

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

have a reference? -gps On Mon, Dec 9, 2019 at 6:10 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi everyone, Thanks again for all your comments on PEP 611. I would like to ask a favour; please be more specific in your comments. Ideally state which part of the P

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 10/12/2019 7:24 am, Kyle Stanley wrote: Chris Angelico wrote: > We have people who believe that a bit > mask will slow things down, others who claim that improved cache > locality will speed things up, and Mark asks us to please justify our > objections with numbers. But su

[Python-Dev] Dropping coroutines from PEP 611.

for limiting coroutines is probably the weakest. Consequently, I'm dropping the limit on the number of coroutines from the PEP. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-d

[Python-Dev] Re: Feedback on PEP 611 (so far) from the Steering Council

On 11/12/2019 12:04 am, Barry Warsaw wrote: The Python Steering Council discussed PEP 611 at today’s meeting. Here is our feedback so far: * The Steering Council reserves the right to be the BDFL-Delegate for this PEP * The PEP should clearly delineate two aspects: - A language generic

[Python-Dev] More feedback on PEP 611, please

d forever, whereas the inconvenience will be felt by a handful of developers, very rarely. Another thing I would like feedback on this: My justification for a single limit of one million across the board is to ease memorization and learning. Is that sufficient justification, or would differin

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

On 11/12/2019 3:56 pm, Guido van Rossum wrote: On Wed, Dec 11, 2019 at 2:14 AM Mark Shannon <mailto:m...@hotpy.org>> wrote: If the status quo were the result of considered decision, then it would of course need considerable justification. If, as is the case here, the s

[Python-Dev] Something wrong with the bug tracker?

m logged in or out of Google, or using a private tab, it makes no difference. Anyone else having problems? Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.

[Python-Dev] Re: Python-dev mailing lis archives earlier than late April 1999?

39502442 Jan 18 2010 python-dev-2008.mbox > -rw-rw-r-- 1 mailman mailman 58868434 Jan 18 2010 python-dev-2009.mbox > -rw-rw-r-- 1 mailman mailman 435171834 Jun 4 2019 python-dev.mbox I'll see about adding the missing messages if they are in the pipermail archive. -- Mark S

[Python-Dev] Re: Python-dev mailing lis archives earlier than late April 1999?

y spurious message from some other list dated March 16, 1995 from Linus Torvalds. Aside from this one message and as far as I can tell, all the other messages from April 21 forward are in the current Hyperkitty archive. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Ca

[Python-Dev] Re: Python-dev mailing lis archives earlier than late April 1999?

thon.org/pipermail/python-list/) is updated, the link to 'old_stuff' can't be added to that page in a way that will persist as new messages are archived, but at least they are there until someone comes up with a better place. -- Mark Sapiro The highway is for gamblers, San Franc

[Python-Dev] Re: Python-dev mailing lis archives earlier than late April 1999?

On 1/6/20 8:03 PM, Mark Sapiro wrote: > > Actually there's quite a bit more than that. see > <ftp://ftp.ntua.gr/mirror/python/search/hypermail/>. I have grabbed that > entire directory and it is now visible at > <https://mail.python.org/pipermail/python-list/old_stuff

[Python-Dev] Re: Should we pass tstate in the VECTORCALL calling convention before making it public?

On 08/01/2020 3:46 pm, Victor Stinner wrote: Hi, I started to modify Python internals to pass explicitly the Python thread state ("tstate") to internal C a functions: https://vstinner.github.io/cpython-pass-tstate.html Passing the thread state explicitly creates a new class of errors that w

[Python-Dev] Re: About "python-porting" mail list

The list has been removed. The archives are still available at <https://mail.python.org/pipermail/python-porting/>. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan signa

[Python-Dev] Comments on PEP 558 (Defined semantics for locals() )

ys that do not match variable names, an exception would be raised. This means that all proxies for a single frame will have value equivalence; object equivalence is not needed. I.e. for a frame `f`, `f.f_locals == f.f_locals` would be True, even though `f.f_lo

[Python-Dev] Re: Clarification of unpacking semantics.

): In the following lines, expressions will be evaluated in the arithmetic order of their suffixes: ... expr1(expr2, expr3, *expr4, **expr5) Note that the stars are not part of expressions 1-5, but are a part of the top-level call expression that operates on them all. Mark Shannon disagree

[Python-Dev] Re: Clarification of unpacking semantics.

n that operates on them all. There are many layers of grammar that make up a call. It is entirely arbitrary what you call an expression or some other grammatical entity. `*expr4` is parsed as an argument, the same as `expr2`. Cheers, Mark. Mark Shannon disagrees with me (I'll let him

[Python-Dev] Re: Clarification of unpacking semantics.

hon.org/3/reference/expressions.html#evaluation-order): In the following lines, expressions will be evaluated in the arithmetic order of their suffixes: ... expr1(expr2, expr3, *expr4, **expr5) Note that the stars are not part of expressions 1-5, but are a part of the top-level call expressio

[Python-Dev] Re: Comments on PEP 558 (Defined semantics for locals() )

e784 That was my misreading. The behaviour of `f_locals` in the PEP is not very clear, as it is buried in the discussion of CPython changes. Could you add it to the proposal section? Cheers, Mark. Cheers, Nick. On Wed, 22 Jan 2020 at 21:59, Mark Shannon wrote: Hi, First of all I wa

[Python-Dev] Re: Comments on PEP 558 (Defined semantics for locals() )

On 16/02/2020 1:35 pm, Nick Coghlan wrote: On Mon., 10 Feb. 2020, 8:31 pm Mark Shannon, <mailto:m...@hotpy.org>> wrote: On 08/02/2020 11:49 am, Nick Coghlan wrote: > Unfortunately, the simplifications you propose would be backwards > incompatible - it's exi

[Python-Dev] Proliferation of tstate arguments.

being added piecemeal without proper review. 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 at

[Python-Dev] Re: Proliferation of tstate arguments.

evance. The long-term goal is to be able to run multiple isolated interpreters in parallel. An admirable goal, IMO. But how is it to be done? That is the question. Le lun. 16 mars 2020 à 15:16, Mark Shannon a écrit : There seems to be a proliferation of `PyThreadState *tstate` arguments being ad

[Python-Dev] Re: Proliferation of tstate arguments.

singletons (None, True, False, ...): https://bugs.python.org/issue39511 The long-term goal is to be able to run multiple isolated interpreters in parallel. Le lun. 16 mars 2020 à 15:16, Mark Shannon a écrit : There seems to be a proliferation of `PyThreadState *tstate` arguments being added to

[Python-Dev] Re: Proliferation of tstate arguments.

On 17/03/2020 3:38 pm, Steve Dower wrote: On 17Mar2020 1447, Mark Shannon wrote: On 16/03/2020 3:04 pm, Victor Stinner wrote: In short, the answer is yes. I said "no" then and gave reasons. AFAICT no one has faulted my reasoning. I said "yes" then and was also no

[Python-Dev] Re: Proliferation of tstate arguments.

On 17/03/2020 7:00 pm, Steve Dower wrote: On 17Mar2020 1803, Chris Angelico wrote: On Wed, Mar 18, 2020 at 3:50 AM Mark Shannon wrote: The accessibility of a thread-local variable is a strict superset of that of a function-local variable. Therefore storing the thread state in a thread

[Python-Dev] Moving threadstate to thread-local storage.

iable than adding lots of extra parameters all over the place. 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/ M

[Python-Dev] Re: Moving threadstate to thread-local storage.

think the answer is yes. Do you have a specific example or testcase? Victor Le mar. 24 mars 2020 à 16:36, Mark Shannon a écrit : Hi, As an experiment, I thought I would try moving the thread state (what you get from _PyThreadState_GET() ) to TLS. https://github.com/python/cpython/compare

[Python-Dev] Re: Any thoughts about a control flow optimizer for CPython?

won't need to regenerate the CFG after bytecode layout. I'd be happy to offer advice and review any PRs. Cheers, Mark. -- //Best, Joannah Nanjekye /"You think you know when you learn, are more sure when you can write, even more when you can teach, but c

[Python-Dev] Re: Any thoughts about a control flow optimizer for CPython?

constant and without side effect. E.g. the following statements are "trivial": try: while False: pass 1 + 1 On the other hand, other more powerful optimization should always preserve the observable behavior of the program. Since the observable behavior is unchanged, there would be n

[Python-Dev] Comments on PEP 554 (Multiple Interpreters in the Stdlib)

ring in channels a recipe for deadlocks? What is the mechanism for reliably copying exceptions from one sub-interpreter to another in the `run()` method? If `run()` can raise an exception, why not let it return values? Cheers, Mark. ___ Python-Dev mailing

[Python-Dev] Re: Comments on PEP 554 (Multiple Interpreters in the Stdlib)

Hi, On 29/04/2020 4:02 am, Eric Snow wrote: On Tue, Apr 21, 2020 at 10:42 AM Mark Shannon wrote: I'm generally in favour of PEP 554, but I don't think it is ready to be accepted in its current form. Yay(ish)! :) My main objection is that without per-subinterpeter GILs (SILs

[Python-Dev] Can we stop adding to the C API, please?

done casually, without a PEP or, in many cases, even a review. We need to address what to do about the C API in the long term, but for now can we just stop making it larger? Please. Also, can we remove all the new API functions added in 3.9 before the release and it is

[Python-Dev] Re: Can we stop adding to the C API, please?

existing C API functions. Sadly, fixing flaws requires adding new functions and deprecating old ones in a slow migration. IMO, at least one function should be deprecated for each new function added. That way the API won't get any bigger. Cheers, Mark. I'm open to ideas how to

[Python-Dev] Re: Can we stop adding to the C API, please?

ion from Python in the GC module and this call just allows you to do the same from the C-API. Cheers, Pablo On Wed, 3 Jun 2020 at 18:26, Mark Shannon <mailto:m...@hotpy.org>> wrote: Hi Victor, On 03/06/2020 2:42 pm, Victor Stinner wrote: > Hi, > > In Pytho

[Python-Dev] Should we be making so many changes in pursuit of PEP 554?

s than 0.4ms per process. Processes are slower, but plenty fast enough. 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.

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

Hi Petr, On 09/06/2020 2:24 pm, Petr Viktorin wrote: On 2020-06-05 16:32, Mark Shannon wrote: Hi, There have been a lot of changes both to the C API and to internal implementations to allow multiple interpreters in a single O/S process. These changes cause backwards compatibility changes

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

;s the objection to spinning up a new processes? Cheers, Mark. P.S. Do try passing the underlying data, not the whole object, and dropping the GIL when calling back into C++. It can be effective. CPython already drops the GIL for some computational workloa

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 11/06/2020 2:50 pm, Riccardo Ghetta wrote: Hello Mark, and thanks for your suggestions. However, I'm afraid I haven't explained our use of python well enough. On 11/06/2020 12:59, Mark Shannon wrote: If you need to share objects across threads, then there will be contention,

[Python-Dev] Re: When can we remove wchar_t* cache from string?

Hi, A big +1 to exposing fewer internals of the PyUnicodeObject to C code. Ultimately, making PyUnicodeObject immutable to C code would be a real bonus. It would make the code cleaner, safer and faster. A triple win! I don't think removing Py_UNICODE API be sufficient for that, have you thou

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

Hi Edwin, Thanks for providing some concrete numbers. Is it expected that creating 100 processes takes 6.3ms per process, but that creating 1000 process takes 40ms per process? That's over 6 times as long in the latter case. Cheers, Mark. On 12/06/2020 11:29 am, Edwin Zimmerman wrote:

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

Hi Steve, On 12/06/2020 12:43 pm, Steve Dower wrote: On 12Jun2020 1008, Paul Moore wrote: On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote: Starting a new process is cheap. On my machine, starting a new Python process takes under 1ms and uses a few Mbytes. Is that on Windows or Unix

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

Hi Eric, On 12/06/2020 4:17 pm, Eric Snow wrote: On Fri, Jun 12, 2020 at 2:49 AM Mark Shannon wrote: The overhead largely comes from what you do with the process. The additional cost of starting a new interpreter is the same regardless of whether it is in the same process or not. FWIW

[Python-Dev] Re: When can we remove wchar_t* cache from string?

Hi Serhiy, On 15/06/2020 8:22 am, Serhiy Storchaka wrote: 12.06.20 11:32, Inada Naoki пише: Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine)

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

the point where JS web workers sit). Cheers, Nick. On Sat., 6 Jun. 2020, 12:39 am Mark Shannon, <mailto:m...@hotpy.org>> wrote: Hi, There have been a lot of changes both to the C API and to internal implementations to allow multiple interpreters in a single O/S process.

[Python-Dev] The Anti-PEP

list, and I can promise the PEP author won't be upset by an Anti-PEP :) Anyone care to volunteer? Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python

[Python-Dev] Re: PEP 622: Structural Pattern Matching

a useful and expressive tool in various modern languages. In particular, many aspects of this PEP were inspired by how pattern matching works in Rust [3] and Scala [4]. Both those languages are statically typed, which allows the compiler to perform the much of the pattern matching at com

[Python-Dev] Re: Recent PEP-8 change

ld be regarded as neutral in any world wide debate on English. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an

[Python-Dev] Request for code review

Hi, Would someone be kind enough to review https://github.com/python/cpython/pull/20803, please? It cleans up tracking and introspection of frame state. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email

[Python-Dev] Re: PEP 622: Structural Pattern Matching (version 2)

#x27;''''''''''''''''' This clearly demonstrates the value of symbolic constants for readability and the serious flaw in the PEP that I cannot use them. I really don't see you how you can claim that `case 406:` is

[Python-Dev] Re: PEP 622: Structural Pattern Matching (version 2)

Hi Tobias, In future, could you avoid editing emails when replying to them? A lot of context can get lost. On 14/07/2020 5:25 pm, Tobias Kohn wrote: Hi Mark, Thank you for your message.  I might be able to answer some of the questions and also address some issues with the underlying

[Python-Dev] PEP 626: Precise line numbers for debugging and other tools.

Hi all, I'd like to announce a new PEP. It is mainly codifying that Python should do what you probably already thought it did :) Should be uncontroversial, but all comments are welcome. Cheers, Mark. ___ Python-Dev mailing list -- pytho

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

idea. Performing any worthwhile performance optimization requires that we can reason about the behavior of programs. Consistent behavior makes that much easier. Inconsistent "micro optimizations" make real optimizations harder. Cheers, Mark. Regards, On Fri, Jul 17, 2020 at 11:49

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 22/07/2020 10:07 am, Antoine Pitrou wrote: On Wed, 22 Jul 2020 12:46:40 +0900 Inada Naoki wrote: On Wed, Jul 22, 2020 at 3:43 AM Mark Shannon wrote: On 18/07/2020 9:20 am, Inada Naoki wrote: It seems great improvement, but I am worrying about performance. Adding more attributes to

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

hwhile IMO. Especially if that 1 or 2% costs us 10% later because it makes more sophisticated optimizations impractical. Cheers, Mark. Regards, ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le..

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 21/07/2020 9:46 pm, Gregory P. Smith wrote: On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder <mailto:n...@nedbatchelder.com>> wrote: https://www.python.org/dev/peps/pep-0626/ :) --Ned. On 7/17/20 10:48 AM, Mark Shannon wrote: > Hi all, > > I&

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 22/07/2020 12:23 pm, Ned Batchelder wrote: On 7/17/20 10:48 AM, Mark Shannon wrote: Hi all, I'd like to announce a new PEP. It is mainly codifying that Python should do what you probably already thought it did :) Should be uncontroversial, but all comments are welcome. Thank

[Python-Dev] Re: Memory address vs serial number in reprs

. The hash doesn't need to be secure, just have a good spread. Cheers, Mark. On 19/07/2020 4:38 pm, Serhiy Storchaka wrote: I have problem with the location of hexadecimal memory address in custom reprs.     vs     The long hexadecimal number makes the repr longer and distracts atte

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Hi Barry, How long do we have to present objections to PEP 622? I don't feel that the PEP gives adequate prominence to the objections so far raised, and there are more issues I would like to bring up. Cheers, Mark. On 05/08/2020 5:58 pm, Barry Warsaw wrote: PEP 622 is already on the

[Python-Dev] PEP 622 (Structural Pattern Matching) questions

or tuple). 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 at https://mail.python.org/archives

[Python-Dev] Re: PEP 622 (Structural Pattern Matching) questions

Hi Daniel, On 06/08/2020 1:11 pm, Daniel Moisset wrote: Hi Mark, As the specific author of that example (and the author of the big it had on a previous version) let me clarify: The change in semantics is intentional. I could be more explicit, and preserve semantics, but I actually find

[Python-Dev] Critique of PEP 622 (Structural Pattern Matching)

for any reason, just send me an email. 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 at https://

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

ely focused on the examples in the PEP (it's as if Mark read nothing *but* the examples). I've read all the PEP. *All* of it. Several times. I would encourage others to read it all carefully as well. Anyone who just reads the abstract and introduction might well think that PEP 622 is

[Python-Dev] Re: PEP 622 questions

On 16/08/2020 8:23 pm, Jean Abou Samra wrote: Hi there, As a poor user, I am extremely excited about the possibilities PEP 622 (structural pattern matching) opens. I'd like to ask a few questions. OOI, what possibilities? I'm genuinely interested know what problems PEP 622 would solve for

[Python-Dev] Re: PEP 622 questions

On 16/08/2020 9:41 pm, Guido van Rossum wrote: On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra > wrote: Hi there, As a poor user, I am extremely excited about the possibilities PEP 622 (structural pattern matching) opens. I'd like to ask a few quest

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

Hi Chris, On 14/08/2020 3:36 pm, Chris Angelico wrote: On Sat, Aug 15, 2020 at 12:32 AM Mark Shannon wrote: Hi all, I've written up a critique of PEP 622. Rather than dump a 2000 line email on you all, I've made a git repo. https://github.com/markshannon/pep622-critique

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

On 17/08/2020 1:13 pm, Henk-Jaap Wagenaar wrote: On Mon, 17 Aug 2020 at 11:30, Mark Shannon <mailto:m...@hotpy.org>> wrote: I would also bring you attention to my rigorous analysis of the possible application to PEP 622 the entirety of CPython. If I have made any

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

wer for the reference implementation due to the repeated `isinstance(value, int)` checks. I think the repeated `int()` cases do not help readability. Which form do you think is more readable? On Mon, 17 Aug 2020 at 14:16, Mark Shannon <mailto:m...@hotpy.org>> wrote: On 17/08

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

On 17/08/2020 7:39 pm, Jean Abou Samra wrote: (the example with changing HTTP_OK value is downright horrifying). As was just mentioned by Guido in another thread, there is a SyntaxWarning to alert you. That doesn't help if the symbolic constant is the last match. Also, it's only in the r

[Python-Dev] Doc tests failing for many PRs on GitHub

___ 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 at https://mail.python.org/archives/list/python-dev@python.

[Python-Dev] Doc tests failing for many PRs on GitHub

Hi, There seems to be something wrong with the doc tests for PRs on Github. https://github.com/python/cpython/pull/22026/checks?check_run_id=1050881634 https://github.com/python/cpython/pull/22025/checks?check_run_id=1050403463 Anyone know what the issue is? Cheers, Mark. (apologies for the

[Python-Dev] Hygenic macros PEP.

t making Python ever larger and more complex. However, there is no reason why they cannot be made more widely available. Should a macro become widely used and popular, then it can be considered for adoption into the language. The PEP: https://github.com/markshannon/peps/bl

[Python-Dev] Re: Hygenic macros PEP.

o flag is not enabled it raises a syntax error. Thoughts? I don't like command line options that change behaviour. It seems to me that it would makes macro uses harder to understand. Cheers, Mark. ___ Python-Dev mailing list -- python-dev@py

[Python-Dev] Re: Hygenic macros PEP.

ol constructs adds a lot of cognitive burden.  Not least because there are likely to be a hundred different implementations that make "case" or "do until" do very subtly different things in each one. On Tue, Sep 15, 2020 at 9:27 AM Mark Shannon <mailto:m...@hotpy.org&

[Python-Dev] Re: Hygenic macros PEP.

Hi Pablo, On 15/09/2020 10:34 pm, Pablo Galindo Salgado wrote: Thanks for the proposal Mark! I wanted to make some comments regarding converting AST nodes to PyObjects internally. I see some challenges here: * Not using an arena allocator for the nodes can introduce more challenges than

[Python-Dev] Re: Hygenic macros PEP.

Hi Victor, On 15/09/2020 10:55 pm, Victor Stinner wrote: Hi Mark, In 2016, I wrote PEP 511 "API for code transformers" which proposed a different implementation but also used "preprocessor" use case in the rationale: """ A preprocessor can be easily imp

[Python-Dev] Re: Hygenic macros PEP.

Hi Matthias, On 15/09/2020 11:25 pm, Matthias Bussonnier wrote: Mark, Thanks you this is an interesting proposal. I can see how many of the "magics" provided by IPython/Jupyter could also be replaced by some of those macros. A couple of questions – which I understand could be de

[Python-Dev] Re: Hygenic macros PEP.

on doesn't have to be recursive. 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 at https://mai

[Python-Dev] Re: Hygenic macros PEP.

impact of exposing the AST at the Python level. Passing tokens around would mean that both the AST nodes and lexer tokens would need to be Python objects, making the performance impact much greater. Cheers, Mark. On 16/09/2020 2:33 pm, Benjamin Peterson wrote: On Tue, Sep 15, 2020, at 23:54,

[Python-Dev] Re: Hygenic macros PEP.

would translate to: $tmp = a; None if $tmp is None else ($tmp.b) Cheers, Mark. [1] https://doc.rust-lang.org/book/ch19-06-macros.html -- --Guido van Rossum (python.org/~guido <http://python.org/~guido>) /Pronouns: he/him //(why is my pronoun here?)/ <http://feministing.com/20

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

Add new INCREF/DECREF inline functions that take tagged values. Never return a borrowed reference (you should should know that ;) Why are you tagging None, True and False? They don't take up any space. Abstract out the tagging scheme. You will want to chan

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

luajit wouldn't exist. Even HotSpot was originally based on a VM for SmallTalk. 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/pyth

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

On 23/09/2020 12:46 pm, Ivan Levkivskyi wrote: On Wed, 23 Sep 2020 at 11:42, Mark Shannon <mailto:m...@hotpy.org>> wrote: On 23/09/2020 9:47 am, Ivan Levkivskyi wrote: > > > On Wed, 23 Sep 2020 at 01:19, Guido van Rossum mailto:gu...@python.org&

[Python-Dev] PEP 638: Syntactic macros

Hi everyone, I've submitted my PEP on syntactic macros as PEP 638. https://www.python.org/dev/peps/pep-0638/ All comments and suggestions are welcome. Cheers, Mark ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an ema

[Python-Dev] Re: PEP 638: Syntactic macros

lighting. Macros will stand out just as much as the users of those editors think they should. Personally, I think they should be fairly prominent. But don't let me stop configuring your editor as you choose :) Cheers, Mark. ___ Python-Dev mailing l

Re: [Python-Dev] negative PyLong integer -> unsigned integer, TypeError or OverflowError?

if (!is_signed) { > PyErr_SetString(PyExc_TypeError, > "can't convert negative long to unsigned"); > return -1; > } I agree that TypeError seems wrong here. Please could you f

Re: [Python-Dev] negative PyLong integer -> unsigned integer, TypeError or OverflowError?

On Fri, Feb 6, 2009 at 11:38 PM, Lisandro Dalcin wrote: > Done, http://bugs.python.org/issue5175 Thank you! Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.

[Python-Dev] str() on memoryview of bytearray failing on py3k

ror: __str__ returned non-string (type bytes) 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] str() on memoryview of bytearray failing on py3k

On 8/02/2009 10:21 AM, Antoine Pitrou wrote: Mark Hammond gmail.com> writes: I'm not sure if the following is a bug I should report or simply an artifact of the implementation and/or simply the way things work on py3k: [...] It's a bug. http://bugs.python.org/issue5182

Re: [Python-Dev] Tracker archeology

ects) to me. Thanks for this! 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] Adding T_SIZET to structmember.h

at bugs.python.org, and we'll find out! A working patch would probably be helpful. (It sounds like a sensible addition to me.) Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

[Python-Dev] 30-bit PyLong digits in 3.1?

rmance improvements planned (see the issue discussion for details); I left them out of the current patch for simplicity, and because they still need proper testing and benchmarking. Mark [1] http://mail.python.org/pipermail/python-dev/2008-November/083315.html ___

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