[Python-Dev] PEP 0404 and VS 2010
Hi, I've been following this thread and the specific issue of the strong negative reaction to the name "Stackless Python 2.8", and I'm a bit bothered by the whole experience. Was there any concern about the name "Stackless Python 0.x" when Christian released his original versions? More importantly, has it caused any real problems over the years? https://mail.python.org/pipermail/python-announce-list/1999-July/000117.html Was there any concern about the dozens of "Stackless Python 2.x" and "Stackless Python 3.x" versions that I have released over the years being a cause for confusion? Or more importantly, any actual problems experienced? Yet, suddenly, the chance that we may release a "Stackless Python 2.8", is a concern. https://mail.python.org/pipermail/python-dev/2013-November/130429.html https://mail.python.org/pipermail/python-dev/2013-November/130466.html https://mail.python.org/pipermail/python-dev/2013-November/130467.html https://mail.python.org/pipermail/python-dev/2013-November/130495.html We've been releasing a variant of Python with related version numbers for over 14 years, under the name "Stackless Python x.x". Now because of a different version number, not only is there strong opposition to us continuing to use this name, but people go so far as to talk about trademarks as a way to prevent us using "Python" in there. https://mail.python.org/pipermail/python-dev/2013-November/130435.html We're not talking about releasing a Python 2.8 against anyone's wishes here. Or in _this specific case_, doing anything other than naming something in a way we've been naming it for over a decade. Yet it's reached the point where people are alluding to ways to forcibly stop us. That there are people who would consider using the trademark to force us to change the name we've been using without harm for 14 years, worries me. It's one thing to perhaps use it to stop someone scamming Python users, and another to suggest using it as a weapon against us for this? Really? Cheers, Richard. ___ 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] Trial balloon: microthreads library in stdlib
On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > >> Of course Stackless isn't quite fully integrated with 2.5 (yet). > >> > >> When did someone last suggest that Stackless become part of the core > >> CPython implementation, and why didn't that ever happen? > >> > > > > Don't remember the "when". The "why" has always been that Christian's > > hacks into the core were complicated and he didn't even think > > integration was worth it. > > With emphasis on the latter. Christian never proposed (to my knowledge) > that Stackless should be integrated. Of course, he didn't propose it > because he assumed that proposal would be turned down, anyway. As I understand it, given that at that time continuations and actually trying to make Python stackless were a goal of Stackless Python, I would hope people do not assume that the changes it currently makes to the core are the same as the ones mentioned here as hacks. Both of these goals have been discarded and Christian also made it an aim to make very few changes to the core and to "keep it and Stackless' intersection a minimum". One improvement Stackless needs related to what is proposed for the generator coroutines, is wrapping calls out of the Python runtime to things like network and file IO, so that microthreads can naturally take advantage of them. The asyncore module does the job for socket IO and allows monkeypatching the socket module so that the current microthread blocks on the asynchronous IO so the scheduler can continue without the whole runtime being stalled. But there is no support for cross- platform (specifically on Windows) asyncronous file IO for instance. If these generator coroutine microthreads went ahead and part of it was improving the support for asynchronous calls in the runtime and standard library, this would also be something which also benefited Stackless Python. Even if they didn't go ahead I would be interested in hearing about whether these sort of changes would be of interest or not for whatever reason. Regarding the port of Stackless to 2.5, it passes both its own (albeit limited) set of tests and the core's set as well. And there are no known bugs which affect general usage. Hope this helps, Richard. ___ 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] Trial balloon: microthreads library in stdlib
On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Richard Tew schrieb: > > If these generator coroutine microthreads went ahead and part > > of it was improving the support for asynchronous calls in the > > runtime and standard library, this would also be something > > which also benefited Stackless Python. Even if they didn't go > > ahead I would be interested in hearing about whether these > > sort of changes would be of interest or not for whatever reason. > > For me to respond to such a question, I first need to understand > what changes precisely you propose. "wrapping calls out of the Python > runtime to things like network and file IO, so that microthreads > can naturally take advantage of them." is a bit vague: how precisely > would you wrap them? I was meaning wrapping on the Stackless side of things and it was not meant as a reference to how better support for asynchronous calls might be added. You can see how wrapping is done with Stackless channels in the examples I linked to at the end of this mail on the off chance you were curious about that instead and I am happy to give any further detail needed. > I assume you would like to see operating system mechanism be used > that currently aren't used (similar to the way asynchore uses > select/poll). Yes. > If so, what mechanism would you like to use, and on what systems? It depends what you mean by mechanism. I can't go into low level details because I do not have the necessary experience or knowledge to know which approach would be best. But I do have some general thoughts and would be willing to do any work involved, if there was a feasible solution and the changes required were thought worthwhile. Let me describe the situation I currently face in order to give context, please excuse the Windows specifics and the lack of consideration for other platforms. I currently use Windows. By using asyncore and monkeypatching in a replacement socket module based on it [1] I can give users of Stackless socket operations which invisibly block at the microthread level allowing the scheduler to continue to run. However there is no support for asynchronous file IO. Now I can monkeypatch in a replacement file object which uses IO completion ports [2], but at that stage I need to poll two different resources for events. In order to avoid this it makes sense to stop using asyncore for sockets and to write a new replacement socket object based on IO completion ports. Then there are other calls which come into the mix. Like in the subprocess module. As I understand it I would need to monkeypatch the Popen.wait, and os.waitpid calls so that they were polled internally to the monkeypatching and Stackless could handle the wake up of the caller there as well. And there might be other blocking calls in the runtime which it would be worth handling also, which might not have methods any way of operating asynchronously (like sockets, files and subprocesses). The ideal mechanism at the high level would be expanding asyncore into a "one-stop shop". Where all these things can be passed into it and it can do the work to notify of events on the objects in a standard way. However even if this were judged feasible, one immediate hurdle is that files passed to it would need to have been opened in overlapped mode for IO completion ports could be used with it. I presume generally opening all files in overlapped mode on Windows would address this thought. And I guess all the other "stuff" which does not relate to IO completion ports like subprocesses would be bundled into a WaitForMultipleObject call. Perhaps there is a better way. And I of course have no concept of how this might be done on other platforms. Thanks, Richard. [1] http://svn.python.org/view/stackless/sandbox/examples/stacklesssocket.py [2] http://svn.python.org/view/stackless/sandbox/libraries/slpmonkeypatch/resources/iocp.py ___ 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] Trial balloon: microthreads library in stdlib
On 2/12/07, Tristan Seligmann <[EMAIL PROTECTED]> wrote: > * Richard Tew <[EMAIL PROTECTED]> [2007-02-12 13:46:43 +]: > > Perhaps there is a better way. And I of course have no concept of > > how this might be done on other platforms. > > Building on an existing framework that does this seems better than > reinventing the wheel, for something of this magnitude. This to me seems to be the low level support you would build something like Twisted on top of. Pushing Twisted so that others can get it seems a little over the top. In any case I'm not building an application. I am transparently making standard library calls yield to a scheduler while whatever they would do happens asynchronously. Generic support for this allows me to make Stackless usage like normal Python usage but with microthreads. I would hope if Dustin went ahead with a generator based microthread solution he find it useful as well. Lumbering Stackless at least with a framework like Twisted pushes complexity up to the user, something Stackless cannot afford. Cheers, Richard. ___ 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] Trial balloon: microthreads library in stdlib
On 2/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Armin Rigo schrieb: > > The history as I remember it is that Christian tried hard to integrate > > the first versions of Stackless with CPython, but was turned town by > > python-dev. > > Are there public records of that? As I remember it, Christian never > actually submitted a patch for inclusion (at least not in public; > he may have approached Guido in private). The oldest discussion > I could find quickly is from August 2000 (Python 2.0 and Stackless); > there, it was Ben Wolfson who asked whether it could be integrated. > I also found a message where I said that it couldn't be integrated > as-is, for a number of reasons I listed; I didn't mean to imply > that it can never be integrated. I can't point you to the posts, but I can point you to something Christian has written on the subject which may indicate why it was never actually submitted for inclusion. See "A Bit Of History" http://svn.python.org/view/stackless/trunk/Stackless/readme.txt I have not talked to Christian about it but as the current maintainer of Stackless I was under the impression that there was a complete lack of interest in even considering it for integration. If addition of microthreading is being considered please consider Stackless. One reason why Stackless is not so popular is that as a fork people shy away from it because it is not the main version. It would benefit Stackless to be integrated and I would be willing to do any work involved to either integrate or maintain it afterwards. Cheers, Richard. ___ 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] Trial balloon: microthreads library in stdlib
On 2/13/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Steve Holden schrieb: > > The only things that concern me are a) whether it could make sense to > > add Stackless in bits and pieces and b) whether the BDFL (or even the > > developer community en masse) would object in principle, thereby > > rendering such efforts useless. > > I think I need to try again. The 'developer community en masse' does > not have a single voice, so it won't object. Not sure about the BDFL, > but I personally don't object 'to a change like that' 'in principle', > primarily because I don't know what the change is. > > I know I'm almost certainly object to the change 'incorporate > Stackless Python into Python as-is', because history shows that > any change of that size would need multiple iterations until it > was acceptable (despite the code being in-use for multiple years). > Very few people can get away with getting their code unedited > into Python (ctypes and elementtree being the most prominent > examples); in these cases, I could accept what I consider flaws > in the code because: > a) the authors promised to maintain the code, and react to > actual bug reports, and > b) these come as extension modules, so it's easy to ignore > them if you don't like them. This makes a lot of sense. You have given a lot of food for thought and a path forward. If I gave an impression in my mails that I expected a consensus of objection, it was because I believed objection to Stackless to be an established thing and that it didn't matter whether there was consensus or not because someone would step forward and reiterate that. I didn't want to push the issue or invest wasted effort if that proved to be the case as mistakenly expected. At no time have I expected that Stackless would be added as-is. > > My (limited) understanding is that with Stackless installed *all* > > existing programs that don't import stackless should continue to run > > unchanged. If that's true then it seems to me it would be a desirable > > addition as long as maintainability wasn't compromised. I suppose only > > the patches will allow a sensible judgment on that issue. > > My understanding is that incorporating Stackless will reduce the > portability: it cannot work on certain platforms, and even for > platforms it works on, it cannot work with certain compilers > or compiler switches (the Windows SEH being the primary example; > the SPARC register stack another one - although this might now > be supported through assembler code). On platforms where it isn't > supported, it still may compile, but might crash the interpreter > when used. If there is no Stackless 'hard switching' available (the stack switching done with assistance of assembler) for the platform it is being compiled on, then compilation proceeds without Stackless compiled into Python. The module is not available. The process of adding support for additional platforms is rather straightforward and with access to them I can do it if required. I don't know about SEH but I believe support for SPARC was added in 2002. http://svn.python.org/view/stackless/trunk/Stackless/platf/switch_sparc_sun_gcc.h > Please understand that this is from a shallow inspection a few > years ago (actually, a description of the working mechanics that > Christian gave me). It would make me feel uncomfortable if Python > had modules that may randomly crash the interpreter, and there > is no procedure to tell beforehand whether a certain applications > is supported or not. Right. I imagine that if there are still problems like these, they will be brought to light when and if patches are submitted. But for now I will address what you mention just so that people don't assume they are still the case, especially since Stackless has been rewritten since then. > Also, I would not like to see modules that monkey-patch other > modules in the standard library. If socket.connect is to > behave differently, the code that makes that so should be > *in* socket.connect, and the documentation of socket.connect > should state that it has that modified behavior. Of course, > people may object to massive library changes of the nature > "if running in stackless mode, this library routine behaves > differently". Perhaps my pursuit of better support for asynchronous calls has led to some confusion. Stackless is an implementation with minimal changes to the core. It does not include any modules which monkey patch. However I have a replacement socket module based on asyncore which is not part of the Stackless distribution. If monkey patched it allows people to use sockets suitably in their microthreads. I am experimenting with this in order to see if I can make using Stackless as close to being as straightforward as writing normal Python code as possible, while still gaining the benefits which use of microthreads should allow. It was considered and quickly dismissed to modify the socket and file support in the core at C
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
On 2/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Tristan is correct: this should be a patch against Twisted, or perhaps as a > separate library that could implement a reactor. I think there is some confusion here. I am not writing a competing event driven mechanism. What I was doing was feeling out whether there was any interest in better support for asynchronous calls. You are right. This should not have been on this list. It should have been on python-ideas, but I replied here because Dustin started the discussion here and I thought if a generator based microthreading solution were to be implemented, it could also benefit from better asynchronous support so brought it into the discussion. After all, if microthreading was in the Python distribution, then it makes sense to make other general improvements which make them more useful. What I meant to suggest that Twisted could be based on was the asynchronous file IO support using IOCP. Especially because Tristan implied that Twisted's own IOCP reactor was incomplete. I did not say this clearly. Yes I have looked at Twisted. It was the first place I looked, several months ago, and what drew me to it was the IOCP reactor. However as I also explained in my reply to Tristan it is not suitable for my needs. It is a large dependency and it is a secondary framework. And I did not feel the need to verify the implication that it wasn't ready because this matched my own recollections. But I hope you realise that asserting that things should be within Twisted without giving any reason, especially when the first person saying it just stated that the matching work in Twisted wasn't even ready, feels like Twisted is trying to push itself forward by bullying people to work within it whenever something can be asserted as laying within whatever domain it is which Twisted covers. Even if it doesn't suit their needs. I don't think Tristan intended that, but when followed up with your reply and JP's interesting response to Greg, it feels like it. ___ 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
[Python-Dev] Stackless Python sprint at PyCon 2006
Hi,During the sprint period after PyCon, we are planning on sprinting to bring Stackless up to date and to make it more current and approachable. A key part of this is porting it and the recently completed 64 bit changes that have been made to it to the latest version of Python. At the end of the sprint we hope to have up to date working 32 and 64 bit versions. If anyone on this list who is attending PyCon, has some time to spare during the sprint period and an interest in perhaps getting more familiar with Stackless, you would be more than welcome in joining us to help out. Familiarity with the Python source code and its workings would be a great help in the work we hope to get done. Especially participants with an interest in ensuring and testing that the porting done works on other platforms than those we will be developing on (Windows XP and Windows XP x64 edition). Obviously being the most familiar with the Stackless Python source code, Christian Tismer has kindly offered us guidance by acting as the coach for the sprint, taking time away from the PyPy sprint.In any case, if you have any questions, or are interested, please feel free to reply, whether here, to this email address or to [EMAIL PROTECTED].Thanks,Richard TewSenior ProgrammerCCP GamesYou can read more about the sprint and the scheduled talk about how Stackless is used in the massively multiplayer game EVE Online we make, at PyCon at the folloing URL: http://www.stackless.com/Members/rmtew/pycon2006And don't forget the Stackless website :)http://www.stackless.com/ ___ 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
