[Python-Dev] Small lament...

Just wanted to throw this out there... I lament the loss of waking up on April 1st to see a creative April Fool's Day joke on one or both of these lists, often from our FLUFL... Maybe such frivolity still happens, just not in the Python ecosystem? I know you can still import "this" or

[Python-Dev] Re: Switching to Discourse

> > I have a question about how you handle multiple communities. I'm > subscribed to ~30 python-dev style mailing lists across different > projects. There is no way I can open up 30 Discourse sites each day. > Mail brings everything into one place for me, and I have things setup > so that new mail

[Python-Dev] Re: Switching to Discourse

> No, Discord is a different thing; it does text and voice communication > channels in real-time. If you're familiar with Slack, it's broadly > similar in purpose. Thanks (and to the others who replied). It seems like they've tried to make it a game, giving me the "opportunity" to buy boosts (or

[Python-Dev] Re: Switching to Discourse

I have a perhaps stupid question. Is Discord the same as discuss.python.org, just by another name? I find the similarity in names a bit confusing. Skip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to

[Python-Dev] Re: Switching to Discourse

> > I don't think I *can* do much more than accept it and move on: > *if python-dev was used by everyone*, rather than almost exclusively by > people who prefer e-mail (and presumably use threading mail clients), > we'd get mangled threading anyway from all the non-threaded clients. > Don't

[Python-Dev] Re: Switching to Discourse

> > The discuss.python.org experiment has been going on for quite a while, > and while the platform is not without its issues, we consider it a > success. The Core Development category is busier than python-dev. > According to staff, discuss.python.org is much easier to moderate.. If > you're

[Python-Dev] Can I ask a real dumb procedural question about GitHub email?

I subscribe to the python/cpython stuff on GitHub. I find it basically impossible to follow because of the volume. I realize there are probably plenty of extra changes going in based on the recent language summit (and maybe some sprints at PyCon?) as well as the proximity to the beta 1 freeze.

[Python-Dev] Re: About PEPs being discussed on Discourse

> > Discourse it just flat-out easier to admin: individuals can flag posts, > automatic spam detection, site-wide admins instead of per-list, ability to > split topics, ability to lock topics, ability to "slow down" topics, > time-limited suspensions, etc. I quit being an admin for any ML beyond

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Wed, Mar 30, 2022, 12:02 PM Toshio Kuratomi wrote: > > As just one example, i found two interesting items in the discussion > started by Skip about determining what modules don't have maintainers just > downstream if this. > Age in snake years doesn't necessarily correlate well with one's

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

> > There's the CODEOWNERS file: > https://github.com/python/cpython/blob/main/.github/CODEOWNERS Thanks. Never would have thought there was such a thing. I was looking for files with "maintain" in them. Skimming it, it would seem that most of the stuff in Lib or Modules isn't really associated

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

I was trying to think through how a "remote" stdlib might work. In the process, I got to wondering if there are known "specialists" for various current modules. Every now and then I still get assigned (or at least made nosy) about something to do with the csv module. Is there an official

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

> What happens when the new maintainer puts malware in the next release of > a package in sumo.txt? > Will core devs be blamed for listing it? > As a user, how do I determine if I can trust the packages there? (This > is easily the hardest part of finding and installing a package from > PyPI,

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

Barry writes (in part): > We could still distribute “sumo” releases which include all the > batteries, but develop and maintain them outside the cpython repo, > and even release them separately on PyPI. It’s *possible* but I > don’t know if it’s *practical*. to which Stephen responds (in part):

[Python-Dev] Re: New PEP website is horrible to read on mobile device

Dang auto-correct... I meant "anti-tracking," in case it wasn't obvious. Skip On Wed, Mar 16, 2022, 10:19 AM Skip Montanaro wrote: > One thing I would mention though is people who can reproduce it check if >> you have any extensions enabled or other tools that can block

[Python-Dev] Re: New PEP website is horrible to read on mobile device

> > One thing I would mention though is people who can reproduce it check if > you have any extensions enabled or other tools that can block network > traffic. Sometimes privacy based extensions and tools can have false > positives and block resources required to render sites correctly. > (I have

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

> > It would not be nice if the traceback module API started providing > text with embedded escape sequences without a way to turn then off in the > API. > I think fobj.isatty() would give the traceback module a good idea whether it's writing to a display device or not. There are a number of

[Python-Dev] Re: Suggestion: a little language for type definitions

> Here is the type hint for `len`, taken from the stub file in typeshed: > > def len(__obj: Sized) -> int: ... > > Putting the mysterious double underscore naming convention aside, I do > not find it credible that anyone capable of programming Python beyond a > beginner level can find that

[Python-Dev] Re: Suggestion: a little language for type definitions

> > So if you hate type annotations because they are unreadable, then you > hate Python because Python is unreadable. > That seems rather harsh. I suspect if those of us who are uncomfortable with the typing subsystem actually hated Python we would have found our way to the exits long ago. Typing

[Python-Dev] Re: Suggestion: a little language for type definitions

> ... make sense of what they’re reading. Some of us have that problem with type-embellished code now. I'm not sure a little language would be such a bad idea. 樂 Fortunately, my relationship to the working world allows me to simply ignore explicit typing.  Way, way BITD I recall leaning on a

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

Perhaps I missed it, but maybe an action item would be to add a buildbot which configures for 15-bit PyLong digits. Skip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] Re: issues-test-2 spam?

> Is anyone else also getting multiple subscription notices? > Yup. In an earlier thread (here? discuss.python.org?) I thought it was established that someone was working on something related to Python bug tracking in GitHub. Or something like that. I've just been deleting them. Skip

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

It might be worth (re)reviewing Sam Gross's nogil effort to see how he approached this: https://github.com/colesbury/nogil#readme He goes into plenty of detail in his design document about how he deals with immortal objects. From that document: Some objects, such as interned strings, small

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

> That is not entirely true: > https://github.com/python/cpython/pull/29639#issuecomment-974146979 The only places I've seen "if 0:" or "if False:" in live code was for debugging. Optimizing that hardly seems necessary. In any case, the original comment was about comparisons of two constants. I

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

> Many operations involving two literals are optimized (to a certain level). So > it sort of surprises me that literal comparisons are not optimized and > literal contains only convert the right operand to a constant if possible. > I'd like to implement optimizations for these especially for

[Python-Dev] Re: Python multithreading without the GIL

Sam> I think the performance difference is because of different versions of NumPy. Thanks all for the help/input/advice. It never occurred to me that two relatively recent versions of numpy would differ so much for the simple tasks in my script (array creation & transform). I confirmed this by

[Python-Dev] Re: Python multithreading without the GIL

> Remember that py stone is a terrible benchmark. I understand that. I was only using it as a spot check. I was surprised at how much slower my (threaded or unthreaded) matrix multiply was on nogil vs 3.9+. I went into it thinking I would see an improvement. The Performance section of Sam's

[Python-Dev] Re: Python multithreading without the GIL

Skip> 1. I use numpy arrays filled with random values, and the output array is also a numpy array. The vector multiplication is done in a simple for loop in my vecmul() function. CHB> probably doesn't make a difference for this exercise, but numpy arrays make lousy replacements for a regular

[Python-Dev] Re: Python multithreading without the GIL

> > Did you try running the same code with stock Python? > > One reason I ask is the IIUC, you are using numpy for the individual > vector operations, and numpy already releases the GIL in some > circumstances. > I had not run the same code with stock Python (but see below). Also, I only used

[Python-Dev] Re: Python multithreading without the GIL

Guido> To be clear, Sam’s basic approach is a bit slower for single-threaded code, and he admits that. But to sweeten the pot he has also applied a bunch of unrelated speedups that make it faster in general, so that overall it’s always a win. But presumably we could upstream the latter easily,

[Python-Dev] Re: Python multithreading without the GIL

Mohamed> I love everything about this - but I expect some hesitancy due to this "Multithreaded programs are prone to concurrency bugs.". Paul> The way I see it, the concurrency model to be used is selected by developers. They can choose between ... I think the real intent of the statement

[Python-Dev] Re: My apologies to the list

> > For the record, my personal arrangement for years has been to read most > open source mailing-lists using GMane, on a NNTP reader separate from my > main mail client. This works fine when I don't want to read open > source-related e-mails :-) > And if you're not an NNTP person (anymore),

[Python-Dev] Re: Notes on PEP 8

> > However, it has become a de facto standard for all Python code, and in the > document itself, there is frequent wording akin to "Identifiers used in the > standard library must be ASCII compatible ...", and even advice for third > party libraries. > > Which I think is acknowledging that PEP 8

[Python-Dev] Re: GDB not breaking at the right place

> > I'm having a hard time debugging some virtual machine code because GDB > won't break where it's supposed to. > A quick follow-up. The GDB folks were able to reproduce this in an XUbuntu 20.04 VM. I don't know if they tried straight Ubuntu, but as the main difference between the two is the

[Python-Dev] Re: GDB not breaking at the right place

me> I'm having a hard time debugging some virtual machine code because GDB won't break where it's supposed to. Here's a quick follow-up. I tried a number of different values of OPT during configuration and compilation, but nothing changed the result. I could never (and still can't) get GDB to

[Python-Dev] Re: GDB not breaking at the right place

> Just turn off optimisation when you want to single-step. But I don't just want to single-step. I want to break at the target label associated with a specific opcode. (I am - in fits and starts - working on register-based virtual machine instructions). If I'm working on, for example, the

[Python-Dev] Re: GDB not breaking at the right place

> I strongly suggest to only build Python with -O0 when using gdb. -Og > enables too many optimizations which makes gdb less usable. Thanks, Victor. It never made sense to me that you would want any optimizations enabled when truly debugging code (as opposed to wanting debug symbols and a sane

[Python-Dev] Re: GDB not breaking at the right place

On Fri, May 21, 2021 at 2:48 PM Guido van Rossum wrote: > I suspect that you're running into the issue where compiler optimizations > are *forced* on for ceval.c. > > There's a comment near the top about this. Just comment out this line: > > #define PY_LOCAL_AGGRESSIVE > > We tried to define

[Python-Dev] GDB not breaking at the right place

I'm having a hard time debugging some virtual machine code because GDB won't break where it's supposed to. Here's my breakpoint #2: 2 breakpoint keep y 0x556914fd ceval_reg.h:_PyEval_EvalFrameDefault:TARGET_JUMP_IF_FALSE_REG breakpoint already hit 1 time p/x oparg

[Python-Dev] Re: Can't sync cpython main to my fork

> Maybe others have different workflows, but I don't see much of a need for > keeping your fork's main branch up to date. My workflow is something like > this: > > % git remote -v > origin g...@github.com:JelleZijlstra/cpython.git (fetch) > origin g...@github.com:JelleZijlstra/cpython.git (push)

[Python-Dev] Re: Can't sync cpython main to my fork

> Your main branch in GitHub has some commits they are not in python/cpython. > https://github.com/smontanaro/cpython/commits/main Regarding this. How else am I to keep my fork in sync with python/cpython other than by the occasional pull upstream/push origin process? That's what all those merges

[Python-Dev] Re: Can't sync cpython main to my fork

Thanks for the recipe to fix my problem. Your main branch in GitHub has some commits they are not in python/cpython. > https://github.com/smontanaro/cpython/commits/main Is there a way to easily tell how they differ? My (obvious to me, but wrong) guess was git diff upstream/main origin/main

[Python-Dev] Can't sync cpython main to my fork

(Sorry, this is probably not really python-dev material, but I'm stuck trying to bring my fork into sync with python/cpython.) I don't know if I did something to my fork or if the master->main change did something to me, but I am unable to sync my smontanaro/cpython main with the python/cpython

[Python-Dev] Re: Keeping Python a Duck Typed Language.

> Practically speaking, one issue I have is how easy it is to write > isinstance or issubclass checks. It has historically been much more > difficult to write and maintain a check that something looks like a duck. > > `if hasattr(foo, 'close') and hasattr(foo, 'seek') and hasattr(foo, > 'read'):`

[Python-Dev] Re: How about using modern C++ in development of CPython ?

> > Perhaps there's some history in the python-dev archives that would inform > you of previous discussions and help you repeating already-considered > arguments. > This topic has come up a few times over the years. Maybe it would be worthwhile to have an informational PEP which documents the

[Python-Dev] Re: On the migration from master to main

Can I distract people for a moment to ask a couple procedural questions about this change? I maintain my own fork of https://github.com/python/cpython, but don't yet see a main branch on python/cpython. - When is the new main branch supposed to appear - Once it does, what will I need to do

[Python-Dev] Re: Non-monotonically increasing line numbers in dis.findlinestarts() output

> co_lnotab has had negative deltas since 3.6. Thanks. I'm probably misreading Objects/lnotab_notes.txt. Skip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] Non-monotonically increasing line numbers in dis.findlinestarts() output

Consider this little session from the tip of the spear: >>> sys.version '3.10.0a6+ (heads/master:0ab152c6b5, Mar 15 2021, 17:24:38) [GCC 10.2.0]' >>> def while2(a): ... while a >= 0: ... a -= 1 ... return a ... >>> dis.dis(while2) 2 0 LOAD_FAST0 (a)

[Python-Dev] Re: Python 0.9.1

> In conversation with Dan, I have fixed my conda package (but overwritten the same version). I needed to add this to the build: > > # sudo apt-get install gcc-multilib > CC='gcc -m32' make python Thanks. That fixes it for me as well. I never even looked at intobject.c, since it compiled out of

[Python-Dev] Re: Python 0.9.1

> If we can get a clean copy of the original sources I think we should put them > up under the Python org on GitHub for posterity. Did that earlier today: https://github.com/python/pythondotorg/issues/1734 Skip ___ Python-Dev mailing list --

[Python-Dev] Re: Python 0.9.1

This is getting a bit more off-topic for python-dev than I'd like. I will make a couple comments though, then hopefully be done with this thread. > The original ones are here: > http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/ > Look at

[Python-Dev] Re: Python 0.9.1

> Also mind > http://www.dalkescientific.com/writings/diary/archive/2009/03/27/python_0_9_1p1.html > for result comparison. Thanks, Paul. I had lost track of Andrew. Good to know he's still out there. I wonder why his tar file was never sucked up into the historical releases page. Whew! My

[Python-Dev] Re: Python 0.9.1

> If someone knows how to get the original Usenet messages from what Google > published, let me know. Seems the original shar is there buried in a Javascript string toward the end of the file. I think I've got a handle on it, though it will take a Python script to massage back into correct

[Python-Dev] Re: Python 0.9.1

> > Wow. Was white-space not significant in this release of Python? I see the >> lack of indentation in the first Python programs. >> > > Indentation most certainly was significant from day 0. I suspect what > happened is that these files got busted somehow by the extraction process > used by Skip

[Python-Dev] Python 0.9.1

A note to webmas...@python.org from an astute user named Hiromi in Japan* referred us to Guido's shell archives for the 0.9.1 release from 1991. As that wasn't listed in the historical releases README file: https://legacy.python.org/download/releases/src/README I pulled the shar files (and a

[Python-Dev] Re: Constructing expected_opinfo_* lists in test_dis.py

> The problem is not that dis.get_instructions can't be trusted, but that > the test isn't testing the dis module at all. It is testing whether the > output from the compiler has changed. > A lot of the tests in test_dis do that. Thanks. Perhaps such tests belong in a different test_* module? (I

[Python-Dev] Re: Constructing expected_opinfo_* lists in test_dis.py

Guido> Maybe these lines in test_dis.py? ... Skip> Thanks, I'll take a look. I was expecting there'd be a standalone Skip> script somewhere. Hadn't considered that comments would be hiding Skip> code. Indeed, that did the trick, however... I'm a bit uncomfortable with the methodology. It seems

[Python-Dev] Re: Constructing expected_opinfo_* lists in test_dis.py

> Maybe these lines in test_dis.py? > ``` > #print('expected_opinfo_jumpy = [\n ', > #',\n '.join(map(str, _instructions)), ',\n]', sep='') > ``` Thanks, I'll take a look. I was expecting there'd be a standalone script somewhere. Hadn't considered that comments would be hiding code. Skip

[Python-Dev] Constructing expected_opinfo_* lists in test_dis.py

I'm still messing around with my register VM stuff (off-and-on). I'm trying to adjust to some changes made a while ago, particularly (but probably not exclusively) after RERAISE acquired an argument. As a result, at least the expected_opinfo_jumpy list changed in a substantial way. I can manually

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

On Thu, Oct 29, 2020, 6:32 PM Gregory P. Smith wrote: > I agree, remove Solaris support. Nobody willing to contribute seems > interested. > *sniff* I spent a lot of professional time in front of SunOS and Solaris screens. But yes, I agree. It seems time to give Solaris the boot. Skip

[Python-Dev] f_localsplus[0] == NULL in super_init_without_args()

(I'm far from certain this is the correct place for this message. Maybe I should have opened a case on bpo instead?) I got far behind on my register instruction set stuff and in the interim the ground shifted underneath me. I'm still working to try and get the test suite to pass (modulo test_ssl,

[Python-Dev] Re: Virtual machine bleeds into generator implementation?

> > Thanks for the replies. I will cook up some private API in my cpython > fork. Whether or not my new vm ever sees the light of day, I think it > would be worthwhile to consider a proper API (even a _PyEval macro or > two) for the little dance the two subsystems do. > I committed a change to my

[Python-Dev] Re: Virtual machine bleeds into generator implementation?

> > I think it's worse that this though, as it seems that in gen_send_ex() > > it actually pushes a value onto the stack. That can't be solved by > > simply adding a state attribute to the generator object struct. > > At the higher level, "it doesn't push value on stack", it "sets value > of the

[Python-Dev] Virtual machine bleeds into generator implementation?

This is more an observation and question than anything else, but perhaps it will stimulate some ideas from the experts. Consider this trivial generator function: def gen(a): yield a When the YIELD_VALUE instruction is executed, it executes (in the non-async case): retval =

[Python-Dev] Re: Do we need port some extension modules to the modules directory?

> I notice some modules not in modules directory(for example: > _warnings、marshal in python directory). Do we need port those modules to > modules directory? I strongly suspect the answer is "no." Modules which aren't in the Modules directory are built directly into the Python executable.

[Python-Dev] Re: How to enable tracemalloc for the test suite?

> It seems like your Python changes use Py_False "somewhere" without > Py_INCREF(Py_False). > Maybe it's COMPARE_OP_REG() which calls SETLOCAL(dst, False). Yes, this was the problem. Thanks for the fix. Too much blind adherence on my part to the existing COMPARE_OP logic. I've even written

[Python-Dev] Re: How to enable tracemalloc for the test suite?

Victor> I wrote the feature (both tracemalloc and query tracemalloc when a Victor> buffer overflow is detected), so I should be able to help you ;-) Yes, I thought you might. :-) I've attached the output of a more complete run. The command is % PYTHONTRACEMALLOC=5 ./python

[Python-Dev] How to enable tracemalloc for the test suite?

I've got a memory issue in my modified Python interpreter I'm trying to debug. Output at the end of the problematic unit test looks like this: ... == Tests result: FAILURE then SUCCESS == 1 test OK. 1 re-run test: test_rattlesnake Total duration: 2.9 sec Tests result: FAILURE then SUCCESS

[Python-Dev] Re: Changing layout of f_localsplus in frame objects

> So far, my second go-round is proceeding better (fingers crossed). I > have added a new slot to the _frame struct (f_cellvars), initialized > once at creation, then referenced elsewhere. I'm also rerunning the > test suite more frequently. Once I've tweaked everything, all that > will remain (in

[Python-Dev] Re: Changing layout of f_localsplus in frame objects

> ... I would expect the FastToLocals and LocalsToFast functions to require > some non-trivial adjustments ... Thanks, Nick. I'm making precisely that change in a few places in frameobject.c. One loop for locals, another for cells & frees, a third for the stack (where the active stack is

[Python-Dev] Changing layout of f_localsplus in frame objects

(Apologies if you're seeing this twice. I first posted to the discourse instance.) I first worked on a register-based virtual machine in the 1.5.2 timeframe. That was before PEP 227 (closures) landed. Prior to that, local variables and the stack were contiguous in the f_localsplus array. Based on

[Python-Dev] Re: How to respond to repeated bad ideas

> Atm we don't have an index of ideas, apart from pep 3099, and I'm not sure we > can make one (can we?), so I do not see a way to prevent this from happening. Maybe an informational PEP which briefly lists rejected ideas? Presumably, they'd normally come up in python-ideas, python-list or

[Python-Dev] extern "C" { ... } in Include/cpython/*.h

(Apologies. Not sure where to ask this, and I'm not much of a C++ programmer. Maybe I should have just added a comment to the still-open issue.) I just noticed that Nick migrated the guts of Include/frameobject.h to include/cpython/frameobject.h. It's not clear to me that the latter should be

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

> Also note that comp.lang.python and hence python-list from late March > 1994 onward is archived at > > Thanks. During my first attempts at applying date range filters on Google Groups, everything came up empty, even for later dates

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

archives, ending in April 1995. Not exactly what > you were looking for but probably also worth saving before that archive > dies. > > On Mon, Jan 6, 2020 at 11:56 AM Skip Montanaro > wrote: > >> Thanks all. I just pinged Ken and am going to rummage around >> mail.python

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

ave survived the > various hosting migrations since then, but maybe they are laying around on > mail.python.org some place? > > -Barry > > > On Jan 6, 2020, at 06:48, Skip Montanaro > wrote: > > > > On Wed, Jan 1, 2020 at 7:25 PM Mark Sapiro wrote: > >

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

On Wed, Jan 1, 2020 at 7:25 PM Mark Sapiro wrote: > On 1/1/20 11:22 AM, Barry Warsaw wrote: > > I am looking at the MM2 mailing list creation confirmation messages in > my personal archives. Both d...@python.org (at 09:49 server local time?) > and python-dev@python.org (at 14:17) were created

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

I could swear python-dev was older than late April 1999, yet that's as far back as the MM3 archives go. As evidence, here's an email from Jack Jansen on 28 April 1999 which was a reply to an earlier message not present in the current archive:

[Python-Dev] Re: Macros instead of inline functions?

This is my last post on this, at least as far as specific usage instances are concerned. See my question about PEP 7 below. If that is a discussion people think worthwhile, please start a new thread. > if (!VISIT(...)) { > return 0; > } > if (!VISIT(...)) { >

[Python-Dev] Re: Macros instead of inline functions?

> > I don't think stable code which uses macros should be changed (though > > I see the INCREF/DECREF macros just call private inline functions, so > > some conversion has clearly been done). Still, in new code, shouldn't > > the use of macros for more than trivial use cases (constant defs, > >

[Python-Dev] Macros instead of inline functions?

As I wander around the code base, I keep seeing macro definitions in the C code. For example, there are four CALL* macros defined in Python/ast_opt.c which contain not entirely trivial bits of syntax. That code is from 2017 (as compared to, say, Modules/audioop.c, which first saw the light of day

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

Guido> I think it’s too soon to worry about this. Simon> +100 Ditto. Besides, isn't support for u"..." just a variable and a couple tests in the earliest phase of compilation? If things are going to get deprecated/removed, I'd prefer the focus be placed on those bits which present a significant

[Python-Dev] Re: Mixed Python/C debugging

Thanks for the responses. I know there are multiple tools out there (to wit, Wes's response), but I'm really after what people actually use and find works. I apologize that wasn't clear. I did neglect to mention that my environment is Linux (specifically Ubuntu 18.04), so Windows-based solutions

[Python-Dev] Mixed Python/C debugging

Having tried comp.lang.python with no response, I turn here... After at least ten years away from Python's run-time interpreter & byte code compiler, I'm getting set to familiarize myself with that again. This will, I think, entail debugging a mixed Python/C environment. I'm an Emacs user and am

[Python-Dev] Re: How to extricate large set of diffs from hg.python.org/sandbox?

> I think this might work: > > $ hg diff -r fb80df16c4ff -r tip > > Not sure fb80df16c4ff is the correct base revision. It seems to be > the base of Victor's work. I put the resulting patch file here: > > http://python.ca/nas/python/registervm-victor.txt Thanks, Neil. I barely

[Python-Dev] How to extricate large set of diffs from hg.python.org/sandbox?

Victor's experiments into a register-based virtual machine live here: https://hg.python.org/sandbox/registervm I'd like to revive them, if for no other reason to understand what he did. I see no obvious way to collect them all as a massive diff. For the moment, I downloaded each commit and am

[Python-Dev] Re:  New keyword in bpo: `newcomer friendly`

> There is now a “newcomer friendly” keyword in bpo. > > My hope is that going forward, we can tag issues that are suitable for first > time contributors with this keyword. Hmmm... I haven't looked lately, but didn't there used to be an "easy" tag which purported to serve roughly the same

[Python-Dev] Re: Replacing 4 underscores with a $ sign, idea for a PEP

My only comment is that this belongs first on python-ideas . Skip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

> You have missed at least one: the minimum technology requirement for > using Github is a lot more stringent than for Roundup. Github's minimum > system requirements are higher, and it doesn't degrade as well, so > moving to Github will make it much harder for those who are using older >

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

> If this were my PEP, I'd call it "Removing unloved batteries from the > standard library". Or maybe, "Removing obsolete and (potentially) dangerous batteries from the standard library." I can certainly understand why either class of module would be removed. When bsddb185 was tossed out, I put

Re: [Python-Dev] Easier debugging with f-strings

> My only complaint is that you steadfastly refuse use Guido’s time machine > keys to make this available in 3.7. Wait a minute, Barry. You mean you don't already have an Emacs function to do the rewriting as a pre-save-hook? Skip ___ Python-Dev

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

> I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for > CPython > > Full text: https://www.python.org/dev/peps/pep-0581/ Thanks for doing this. I think there is a pretty strong argument to be made that mature, widely adopted systems like GitHub (or GitLab or Bitbucket)

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

> I uploaded a tarfile I had on my PC to my web site: > > http://python.ca/nas/python/rattlesnake20010813/ > > It seems his name doesn't appear in the readme or source but I think > Rattlesnake was Skip Montanaro's project. I suppose my idea of > unifying the local variables and the registers

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

> The interwebs has been collecting ton of resources about porting py2 > to 3 during these years. Any not-yet-answered question surely can be > done in a list with more participants. > > Can we kill this list? Would it perhaps make sense to replace the list with an auto-reply about the list's

Re: [Python-Dev] Python3 compiled listcomp can't see local var - bug or feature?

> Skip, I think you have misunderstood the point I was making. It was > not whether the loop variable should leak out of a list comprehension. > Rather, it was whether a local variable should, so to speak, "leak into" > a list comprehension. And the answer is: it depends on whether the code >

Re: [Python-Dev] Python3 compiled listcomp can't see local var - bug or feature?

> Is this a bug or a feature? The bug was me being so excited about the new construct (I pushed in someone else's work, can't recall who now, maybe Fredrik Lundh?) that I didn't consider that leaking the loop variable out of the list comprehension was a bad idea. Think of the Py3 behavior as one

Re: [Python-Dev] "make test" routinely fails to terminate

> me> On the 3.7 branch, "make test" routinely fails to terminate. > Antoine> Can you try to rebuild Python? Use "make distclean" if that helps. > Thanks, Antoine. That solved the termination problem. I still have problems > with test_asyncio failing, but I can live with that for now. Final

Re: [Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?

> You don't really need copies of official branches on your Github fork if you're not a maintainer for these branches. I explicitly wanted to run with 3.7 in the run-up to release. On that branch, the built ./python reports 3.7.0b4+ at startup. Master tells me 3.8.0a0 on startup. Since my local

Re: [Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?

> Create it from upstream? Yep! Try this: > git checkout -b 3.7 upstream/3.7 > git push -u origin 3.7 Thanks, Chris! Didn't have to chug for too long either, just a few seconds. S ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] "make test" routinely fails to terminate

me> On the 3.7 branch, "make test" routinely fails to terminate. Antoine> Can you try to rebuild Python? Use "make distclean" if that helps. Thanks, Antoine. That solved the termination problem. I still have problems with test_asyncio failing, but I can live with that for now. If "make

[Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?

My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch was created. I have no remotes/origin/3.7. Is there some way to create it from remotes/upstream/3.7? I asked on GitHub's help forums. The only recommendation was to to delete my fork and recreate it. That seemed kind of

  1   2   3   4   >