Martin v. Loewis <martin@v.loewis.de>: > > I told him that we don't have a formal process, but attracting the > > attention of someone on python-dev is usually where it starts. > > Actually, we do: Write a library PEP, see PEP 2. > > This procedure is rarely executed completely, but I would atleast > insist on the maintenance part being clarified in advance Thanks for the correction. > As you can see, I don't care that much about usefulness of the module > (although I'm sure others here will); to me, if users say it is > useful, and maintenance is clear, and it does not come with a huge C > library that you need to build, I'm fine with incorporating it - > provided there is somebody I can assign bug reports to. No C. That's one of the good things about this implementation; it's pure Python, relying only on the existing pty module. I don't think it's going to need a lot of maintainance, frankly. Simple API, well-understood problem, and an author who (correctly) describes himself as "anal-retentive" :-). What it *is* likely to do is tickle a lot of bugs and edge cases in the pty code. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4