Re: [Python-Dev] Why is nb_inplace_power ternary?
Greg Ewing schrieb: >> What could the syntax for that be? > > It wouldn't be a syntax, just a function, e.g. > >ipow(x, n, 10) In what way would that be inplace? A function cannot rebind the variables it gets as parameters. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nb_inplace_power ternary?
Jim Jewett schrieb: > Either > > x**= n % 10 # The **= changes the parse context, so that % > is no longer > # immediately evaluated Are you seriously proposing such a change? I was asking for spellings that currently don't have a meaning (rather, I was suggesting that no such spelling exists, and the entire idea of supporting such notation in the language is ridiculous). > x**= (n, 10) # exponentiation to a tuple isn't currently > defined, and it Likewise: it currenly is well-defined: it invoked nb_inplace_power with the tuple (and __ipow__ if x's class is written in Python). Whether this gives a TypeError or not depends on the class of x. Regards, Martin ___ Python-Dev mailing list [email protected] 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 timeout option to httplib...connect()
[EMAIL PROTECTED] schrieb: > Guido> I'm not going to change ftplib.py and all the others. > > Also understood. This has, as far as I know, been the response of everybody > who has encountered this problem before. You should read your SF bug list more frequently, then. You are currently assigned bug #723312 (and have been since 2003-04-17), which has a patch to change ftplib. Regards, Martin ___ Python-Dev mailing list [email protected] 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 timeout option to httplib...connect()
Guido> I'm not going to change ftplib.py and all the others. >> Also understood. This has, as far as I know, been the response of >> everybody who has encountered this problem before. Martin> You should read your SF bug list more frequently, then. You are Martin> currently assigned bug #723312 (and have been since 2003-04-17), Martin> which has a patch to change ftplib. Assigned by the author, because I apparently offered him some advice I no longer recall giving? After much chiding here I'll take a look. I don't know if feature requests for Roundup are still being accepted, but I hope one of its features is that it can remind people periodically of the tickets they own. My primary goal in life is not to close Python bugs and patches, so I hope people will understand if I don't think on a Thursday evening, "Gee, I think I'll drop by SourceForge and see what work I have to do tonight". Skip ___ Python-Dev mailing list [email protected] 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 timeout option to httplib...connect()
[EMAIL PROTECTED] schrieb: > I don't know if feature requests for Roundup are still being accepted, but I > hope one of its features is that it can remind people periodically of the > tickets they own. My primary goal in life is not to close Python bugs and > patches, so I hope people will understand if I don't think on a Thursday > evening, "Gee, I think I'll drop by SourceForge and see what work I have to > do tonight". Maybe it would be better to remove you from the list of possible assignees, then? You have four more patches and four bugs assigned to you, please consider unassigning them if you don't plan to work on them. Regards, Martin ___ Python-Dev mailing list [email protected] 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 timeout option to httplib...connect()
>> I don't know if feature requests for Roundup are still being >> accepted, but I hope one of its features is that it can remind people >> periodically of the tickets they own. My primary goal in life is not >> to close Python bugs and patches, so I hope people will understand if >> I don't think on a Thursday evening, "Gee, I think I'll drop by >> SourceForge and see what work I have to do tonight". Martin> Maybe it would be better to remove you from the list of possible Martin> assignees, then? I'll take a look. Skip ___ Python-Dev mailing list [email protected] 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 timeout option to httplib...connect()
Guido> I'm not going to change ftplib.py and all the others. >> Also understood. This has, as far as I know, been the response of >> everybody who has encountered this problem before. Martin> You should read your SF bug list more frequently, then. You are Martin> currently assigned bug #723312 (and have been since 2003-04-17), Martin> which has a patch to change ftplib. I updated the patch to be compatible with current svn: http://python.org/sf/723312 All tests pass. Well, the only tests which fail for me seem to have nothing to do with networking. I looked at gopherlib for about five seconds then decided it wasn't worth it. (Shouldn't it be deprecated and moved out to PyPI for external maintenance?) There are still no documentation updates. I don't have the few minutes necessary at the present time to cobble something together (headed out the door). Maybe tomorrow. Guido, I looked at urllib2 and quickly gave up. I have no idea how that code works (where is a lower level library's connection object instantiated, for example?). I presume with timeouts in the lower level libraries someone who knows how urllib2 works will be able to graft timeouts onto it without too much work. Skip ___ Python-Dev mailing list [email protected] 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 timeout option to httplib...connect()
On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Guido, I looked at urllib2 and quickly gave up. I have no idea how that > code works (where is a lower level library's connection object instantiated, > for example?). I presume with timeouts in the lower level libraries someone > who knows how urllib2 works will be able to graft timeouts onto it without > too much work. Thanks for looking anyway! I had a quick look myself; I think it relies on the implicit call to connect() in the HTTPConnection class's request() method. This answers my question: the timeout should be passed to the HTTPConnection constructor which stores it in an instance variable just like host and port, and then connect() will get it from there. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Trial balloon: microthreads library in stdlib
Mostly for my own curiosity, I'm working on a PEP-342-based microthreading library with a similar api to threads and threading (coalesced into a single module). It uses coroutines and a trampoline scheduler, and provides basic async wrappers for common IO operations. It's not a framework/environment like Twisted or Kamaelia -- it's just a microthreading library with some solid primitives. My thinking is that this would be the "next level" for apps which currently use asyncore. I won't go into a lot of detail on the module, because (a) it's not even nearly done and (b) my question is higher-level than that. Is there any interest in including a simple microthreading module in Python's standard library? If this sounds like a terrible idea, let fly the n00b-seeking missiles. If it sounds better than terrible, I'll keep working and post a reasonable prototype soon (a PEP would also be in order at some point, correct?). Dustin ___ Python-Dev mailing list [email protected] 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 timeout option to httplib...connect()
On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Guido> I'm not going to change ftplib.py and all the others. > > >> Also understood. This has, as far as I know, been the response of > >> everybody who has encountered this problem before. > > Martin> You should read your SF bug list more frequently, then. You are > Martin> currently assigned bug #723312 (and have been since 2003-04-17), > Martin> which has a patch to change ftplib. > > I updated the patch to be compatible with current svn: > > http://python.org/sf/723312 > > All tests pass. Well, the only tests which fail for me seem to have nothing > to do with networking. I looked at gopherlib for about five seconds then > decided it wasn't worth it. (Shouldn't it be deprecated and moved out to > PyPI for external maintenance? PEP 3108 has gopherlib slated for removal. -Brett ___ Python-Dev mailing list [email protected] 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 timeout option to httplib...connect()
On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Guido> I'm not going to change ftplib.py and all the others. > > >> Also understood. This has, as far as I know, been the response of > >> everybody who has encountered this problem before. > > Martin> You should read your SF bug list more frequently, then. You are > Martin> currently assigned bug #723312 (and have been since 2003-04-17), > Martin> which has a patch to change ftplib. > > Assigned by the author, because I apparently offered him some advice I no > longer recall giving? After much chiding here I'll take a look. > > I don't know if feature requests for Roundup are still being accepted, but I > hope one of its features is that it can remind people periodically of the > tickets they own. Good idea. Kind of like a weekly "here is your Python todo list in terms of issues" email. I think it should be doable. As for taking new ideas, the goal right now is to get the transition done. The biggest thing holding it up now is documentation, especially howto docs. Once we are transitioned we are expecting people to want to change things or add features. But if you want to get the ball rolling on this for possible inclusion afterwards, email tracker-discuss about your idea. > My primary goal in life is not to close Python bugs and > patches, so I hope people will understand if I don't think on a Thursday > evening, "Gee, I think I'll drop by SourceForge and see what work I have to > do tonight". I understand. =) ___ Python-Dev mailing list [email protected] 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/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Mostly for my own curiosity, I'm working on a PEP-342-based > microthreading library with a similar api to threads and threading > (coalesced into a single module). It uses coroutines and a trampoline > scheduler, and provides basic async wrappers for common IO operations. > > It's not a framework/environment like Twisted or Kamaelia -- it's just a > microthreading library with some solid primitives. My thinking is that > this would be the "next level" for apps which currently use asyncore. > > I won't go into a lot of detail on the module, because (a) it's not even > nearly done and (b) my question is higher-level than that. > > Is there any interest in including a simple microthreading module in > Python's standard library? > I am sure there is. > If this sounds like a terrible idea, let fly the n00b-seeking missiles. > If it sounds better than terrible, I'll keep working and post a > reasonable prototype soon (a PEP would also be in order at some point, > correct?). I really need to get the informatiion PEP written for guidelines on what it usually takes to get something added to the stdlib. =) Basically, the list of things you need to do (typically, these are just guidelines) are: 1. Write it 2. Get the community to use it and like it 3. Make it follow PEP 7/8 style guidelines 4. Write docs 5. Write tests 6. Promise to help maintain the code. -Brett ___ Python-Dev mailing list [email protected] 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 Sat, Feb 10, 2007 at 03:00:28PM -0800, Brett Cannon wrote: > 1. Write it > 2. Get the community to use it and like it > 3. Make it follow PEP 7/8 style guidelines > 4. Write docs > 5. Write tests > 6. Promise to help maintain the code. Thanks -- I hadn't really planned that far ahead yet. I expect #2 will be the hardest! Dustin ___ Python-Dev mailing list [email protected] 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
> If this sounds like a terrible idea, let fly the n00b-seeking missiles. Sounds like a good idea. We did this with ILU, and it helped manage the overhead of threads quite a bit. Brett's comments on "the next step" are right on target. Bill ___ Python-Dev mailing list [email protected] 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 Sat, Feb 10, 2007, Brett Cannon wrote: > On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> Is there any interest in including a simple microthreading module in >> Python's standard library? > > Basically, the list of things you need to do (typically, these are > just guidelines) are: > > 1. Write it > 2. Get the community to use it and like it > 3. Make it follow PEP 7/8 style guidelines > 4. Write docs > 5. Write tests > 6. Promise to help maintain the code. Let me amplify step 2 a bit: once you get your code to the stage where it's usable by other people, upload it to PyPI, announce it on c.l.py.a and other appropriate places, and go through several rounds of improvements and updates based on feedback and bug reports. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM ___ Python-Dev mailing list [email protected] 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 Sun, Feb 11, 2007 at 03:35:29AM +0200, Yotam Rubin wrote: > Why don't you use Stackless? It's very simple, stable, and solves > quite completely the problems in writing concurrect code. That's a great point -- I'm not necessarily producing this to solve a problem I'm having. Rather, I think that the new language features in PEP 342 cry out for a batteries-included library that makes asynchronous programming both natural and easy. Dustin ___ Python-Dev mailing list [email protected] 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
[EMAIL PROTECTED] wrote: > On Sun, Feb 11, 2007 at 03:35:29AM +0200, Yotam Rubin wrote: >> Why don't you use Stackless? It's very simple, stable, and solves >> quite completely the problems in writing concurrect code. > > That's a great point -- I'm not necessarily producing this to solve a > problem I'm having. Rather, I think that the new language features in > PEP 342 cry out for a batteries-included library that makes asynchronous > programming both natural and easy. > 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? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
