Re: [Python-Dev] Thoughts fresh after EuroPython
Am 25.07.2010 08:54, schrieb Stefan Behnel: > Nick Coghlan, 25.07.2010 08:29: >> We knew PEP 380 would be hurt by the moratorium when the moratorium >> PEP went through. >> >> The goals of the moratorium itself, in making it possible to have a >> 3.2 release that is fully supported by all of the major Python >> implementations, still apply, and I believe making an exception for >> PEP 380 *would* make those goals much harder to achieve. > > IMO, it would be worth asking the other implementations if that is the > case. It may well be that they are interested in implementing it anyway, so > getting it into CPython and the other implementations at the same time may > actually be possible. It wouldn't meet the moratorium as such, but it would > absolutely comply with its goals. +1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Python profiler and other tools
On Sat, Jul 24, 2010 at 8:29 PM, Nick Coghlan wrote: > On Sun, Jul 25, 2010 at 3:30 AM, Guido van Rossum wrote: >> On Fri, Jul 23, 2010 at 4:20 PM, Alexander Belopolsky >> wrote: >>> There must be a good reason why traditional software development tools >>> such as debugger, profiler and coverage are mostly neglected in >>> python. >> >> Most such tools are probably better developed outside the standard >> library. There are many reasons for that, but I would guess that it >> mostly has to do with very different development cycles for tools. >> Tool development usually goes in quick bursts (driven by urgent needs >> and perhaps improving tool developer skills) unrelated to the stdlib >> release cycle (and releasing the stdlib separately won't make much of >> a difference). Also tools often have rough edges, and the stdlib >> (except for the stuff added before 1995 or so :-) has a high >> perfectionism standard. > > Part of me agrees with you regarding the generally different tool > lifecycle, but another part says we need these tools in the standard > library or we risk inadvertently breaking the hooks they would still > rely on, even as third party projects. The hooks need to be exercised by unittests, for sure. Hooks are APIs with a contract and a promise of stability (though sometimes it's complicated). > I suspect a major factor here relates to the degree of unit test > coverage for these components - for areas that aren't of direct > interest to me, I'll still deal with it if something I do breaks that > code's unit tests, but if the tests don't start failing I'll never > even think to check for an incompatibility. (e.g. I seem to recall > line tracing for with statements and/or generator expressions being > broken for a while before we fixed it) Sure, but I don't see how the presence of a tracing tool in the stdlib would have helped -- in fact, there's pdb which does use the tracing hooks, but that was a new use case and nobody thought of checking it. > PEP 306 (the one about changing the grammar) and PEP 339 (which > includes a short section on changing the bytecode definition) may also > be missing some steps to make sure that any syntax and opcode changes > are correctly covered by the disassembly, debugging, profiling and > tracing tests. That's a good idea regardless. -- --Guido van Rossum (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
Re: [Python-Dev] Does trace modules have a unit test?
On Sat, Jul 24, 2010 at 11:18 PM, Nick Coghlan wrote: > On Sun, Jul 25, 2010 at 2:20 AM, Alexander Belopolsky > wrote: .. >> Step 1: Rename test_trace to test_sys_settrace and test_profilehooks >> to test_sys_setprofile. .. > A tracetester helper module + the two test module renames sounds like > a fine idea to me (your proposed new names should be clearer than the > existing *hooks naming, given the existence of "profile" and "trace" > modules). I have implemented the step 1 above in 3.2 and 2.7 branches, but svnmerge failed in 3.1 and I suspect that this was because r79102 did not make it to release31-maint. It is my understanding that test improvements are normally backported to maintenance branches and r79102 is a test-only revision. Unfortunately, I was not able to figure out how to convince svnmerge to merge r79102 in 3.1. Can someone help? ___ 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] Thoughts fresh after EuroPython
At 04:29 PM 7/25/2010 +1000, Nick Coghlan wrote: So, while I can understand Guido's temptation (PEP 380 *is* pretty cool), I'm among those that hope he resists that temptation. Letting these various ideas bake a little longer without syntactic support likely won't hurt either. Well, if somebody wants to clean up my syntax-sugar-free version a little (maybe adding a "From.return_(value)" staticmethod that raises StopIteration(value)) and throw it in the stdlib, then people can certainly experiment with the feature in 3.2, and get an opportunity to iron out any implementation issues before going to the C-and-sugared version later. ___ 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] [isssue 2001] Pydoc enhancement patch questions
On 07/24/2010 10:38 PM, Nick Coghlan wrote: On Sun, Jul 25, 2010 at 5:34 AM, Ron Adam wrote: On 07/24/2010 05:37 AM, Nick Coghlan wrote: On Sat, Jul 24, 2010 at 10:05 AM, Ron Adamwrote: I am not sure I like the fact that the browser is started automatically. Please bring this up on python-dev. This may be an opportunity to rethink pydoc command line switches. For example, -p and -g are currently exclusive, but it would make sense for -g to start server on the port specified by -p. So are any thoughts on starting the web browser automatically, and on how the -g and -p command line switches work? My suggestion: - leave the "-g" option alone (including the tk gui), but make sure other options still work when tk is unavailable I was hoping it would be ok to drop the tk gui in pydoc. Keeping it requires rewriting the tk gui interface to use the new server because the server code and the gui code are not cleanly separate. I can do this if it's really wanted. (Nothing against tKinter, I use it for my own gui apps.) I'd be completely fine with dropping the "Search For" box from the GUI interface, but the persistent window listing the served port and providing "Open Browser" and "Quit Serving" buttons still seems quite useful even without the search box (When running "python -m pydoc -p 8080&", it took me a moment to figure out how to kill the server I had started). You could even tidy it up a bit and include things like the Python version in the GUI window. Good ideas. Specifying both -b and -g should open both the (limited) GUI and the web browser. I see what you mean. The point is to always enable a way to communicate to the server directly. I've fairly often have had to kill the server with the task manager. or on ubuntu, use the system monitor to stop the server. That's definitely not novice friendly. Currently the port is printed on the console when started from the console, but there isn't a clean way to stop the server and no message to say how. The gui is needed for when pydoc is started without a console ie.. by an icon in windows. Another way to communicate to the server would be to add a link in the browser to open a server status page. For example my router has a configure page where I can check it's status and do other things. That might be something worth exploring at some later date. Here are some thoughts... The gui window can have a panal to display the server output. Currently it goes to the console window which may not be visible. This would replace the search results panel. If the gui window is not opened, ie... tk isn't installed or the user prefers the console, have the console window accept commands that correspond to the tk window. Both can have a way to turn on and off verbosity which will display the server activity. Cheers, Ron I'll be away from my computer most of today, I will start making some of the changes we have been discussing later tonight. ___ 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] [isssue 2001] Pydoc enhancement patch questions
On Sun, Jul 25, 2010 at 12:32 PM, Ron Adam wrote: .. >> I'd be completely fine with dropping the "Search For" box from the GUI >> interface, but the persistent window listing the served port and >> providing "Open Browser" and "Quit Serving" buttons still seems quite >> useful even without the search box (When running "python -m pydoc -p >> 8080&", it took me a moment to figure out how to kill the server I >> had started). Why not simply have "Quit Serving" next to the search button in the served pages? The server can even serve a friendly page explaining how it can be restarted before quitting. .. > Another way to communicate to the server would be to add a link in the > browser to open a server status page. For example my router has a configure > page where I can check it's status and do other things. That might be > something worth exploring at some later date. This would work as well, but for starters, I think "Search" and "Quit" buttons next to each other will be most familiar to the users of the current Tk-based control window. ___ 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] Python Language Summit EuroPython 2010
On 7/23/10 2:44 AM, Guido van Rossum wrote:
Indeed, we meant b'...{}...{}...'.format(x, y). The problem is that it
can't invoke x.__format__() or y.__format__() since those will return
text strings instead of bytes. A proposed solution was to try
x.__bformat__() etc. Another proposed solution was to limit x and y to
a small set of common types and hard-code their meanings (e.g.
numbers, bytes, and dates).
If there were an __bformat__ method, what would object.__bformat__() return?
--
Eric.
___
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] Python profiler and other tools
> Part of me agrees with you regarding the generally different tool > lifecycle, but another part says we need these tools in the standard > library or we risk inadvertently breaking the hooks they would still > rely on, even as third party projects. > > I suspect a major factor here relates to the degree of unit test > coverage for these components - for areas that aren't of direct > interest to me, I'll still deal with it if something I do breaks that > code's unit tests, but if the tests don't start failing I'll never > even think to check for an incompatibility. (e.g. I seem to recall > line tracing for with statements and/or generator expressions being > broken for a while before we fixed it) It is at best entertaining to ponder about reasons here; I doubt anything productive can come out of such a discussion. It may be fun posting a message to a ten-year-old issue saying "ACT NOW (you sluggards)", but I question that this will, on average, improve things. Likewise, speculating that tool support is deliberately ignored probably won't improve things (specifically *not* responding to Nick here). On the other hand, posting actual patches that fix actual bugs can make a lot of a difference. Also, having a maintainer who is willing to look into these patches and accept the good ones will make a lot of a difference. 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] http://bugs.python.org/issue231540
> Oh, and with business philosophy I mean: mails like the one you start > this thread with are interpreted by me as being very pushy, overly > sarcastic and if my project manager at the office sends me an email > like that I know I have to do it right now. I would dislike to be > spoken to like this in an voluntary environment. Do note that I do > understand where your feelings come from. +1. 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] Python Language Summit EuroPython 2010
On Fri, Jul 23, 2010 at 2:44 AM, Guido van Rossum wrote:
..
> Indeed, we meant b'...{}...{}...'.format(x, y). The problem is that it
> can't invoke x.__format__() or y.__format__() since those will return
> text strings instead of bytes. A proposed solution was to try
> x.__bformat__() etc. Another proposed solution was to limit x and y to
> a small set of common types and hard-code their meanings (e.g.
> numbers, bytes, and dates).
Reaching an agreement on what to hard-code for dates may be harder
than for the other common types. [1] Implementation of
date.__bformat__ will also have it's unique challenges because at the
moment date.__format__ is date.strftime and there is no locale
independent strftime variant.
A simple solution would be to have date.__bformat__ or hard-coded
meaning to be just b'-MM-DD', but when it gets to datetime, I am
sure users will start complaining about inability to specify RFC 3339
or other internet-standard formats.
[1] http://bugs.python.org/issue8913
___
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] Python Language Summit EuroPython 2010
On Sun, Jul 25, 2010 at 1:13 PM, Eric Smith wrote:
> On 7/23/10 2:44 AM, Guido van Rossum wrote:
>>
>> Indeed, we meant b'...{}...{}...'.format(x, y). The problem is that it
>> can't invoke x.__format__() or y.__format__() since those will return
>> text strings instead of bytes. A proposed solution was to try
>> x.__bformat__() etc. Another proposed solution was to limit x and y to
>> a small set of common types and hard-code their meanings (e.g.
>> numbers, bytes, and dates).
>
> If there were an __bformat__ method, what would object.__bformat__() return?
Maybe self.__format__(..).encode('ascii')? ...encode('utf-8') is a
tempting alternative as well.
___
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] Set the namespace free!
So OK, thank you for response.
No, I wasn't joking. I'm sorry, I didn't know that you Python guys get offended
from being compared to PHP or Perl. Perhaps that shouldn't surprise me, though.
I have posted all of this here, because I was hoping this feature would be
implemented secretly, without anyone knowing. Life isn't that simple it seems,
I would have to go through all this PEP publication and stuff. Blame yourselves.
Reconsidering various ideas you have posted, I think the following solution
would be best:
All alphanumeric sequences preceded by a dot (".") should not be treated as
reserved words.
This would allow now reserved names as attributes without any change. Highest
level identifiers would need to be simply preceded by a dot.
> boo.if = 3
> boo.with = hoo.as
> .while = 1
> .for = .def
> fun(.class="a")
This doesn't require any major change, does not break anything and as a side
effect makes some very old code _valid_, at least syntactically.
I am going to repost this now on a valid list. Wish me luck, you opportunists.
--
Regards, haael
___
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] Thoughts fresh after EuroPython
On Sat, Jul 24, 2010 at 10:08 AM, Guido van Rossum wrote: > While the EuroPython sprints are still going on, I am back home, and > after a somewhat restful night of sleep, I have some thoughts I'd like > to share before I get distracted. Note, I am jumping wildly between > topics. > > - Commit privileges: Maybe we've been too careful with only giving > commit privileges to to experienced and trusted new developers. I > spoke to Ezio Melotti and from his experience with getting commit > privileges, it seems to be a case of "the lion is much more afraid of > you than you are afraid of the lion". I.e. having got privileges he > was very concerned about doing something wrong, worried about the > complexity of SVN, and so on. Since we've got lots of people watching > the commit stream, I think that there really shouldn't need to be a > worry at all about a new committer doing something malicious, and > there shouldn't be much worry about honest beginners' mistakes either > -- the main worry remains that new committers don't use their > privileges enough. So, my recommendation (which surely is a > turn-around of my *own* attitude in the past) is to give out more > commit privileges sooner. I'd agree with this as well; speaking as someone who was terrified when I first got privileges, I can really back this up. However, I wonder if voluntary code reviews for bigger ticket items would be a good thing to encourage more. I know some people use rietveld - but maybe we should be using it more, plus emails to python-committers asking for reviews. As time has gone on, I've become more and more a firm believer in doing peer reviews. > - Concurrency and parallelism: Russel Winder and Sarah Mount pushed > the idea of CSP > (http://en.wikipedia.org/wiki/Communicating_sequential_processes) in > several talks at the conference. They (at least Russell) emphasized > the difference between concurrency (interleaved event streams) and > parallelism (using many processors to speed things up). Their > prediction is that as machines with many processing cores become more > prevalent, the relevant architecture will change from cores sharing a > single coherent memory (the model on which threads are based) to one > where each core has a limited amount of private memory, and > communication is done via message passing between the cores. This > gives them (and me :-) hope that the GIL won't be a problem as long as > we adopt a parallel processing model. Two competing models are the > Actor model, which is based on asynchronous communication, and CSP, > which is synchronous (when a writer writes to a channel, it blocks > until a reader reads that value -- a rendezvous). At least Sarah > suggested that both models are important. She also mentioned that a > merger is under consideration between the two major CSP-for-Python > packages, Py-CSP and Python-CSP. I also believe that the merger will > be based on the stdlib multiprocessing package, but I'm not sure. I do > expect that we may get some suggestions from that corner to make some > minor changes to details of multiprocessing (and perhaps threading), > and I think we should be open to those (I expect these will be good > suggestions for small tweaks, not major overhauls). I'm open to changes; but remain skeptical the CSP will suddenly take over the world :) There's other, competing philosophies and toolkits out there as well. Additionally; the patches would have to be relicensed - python-csp is under GPLv2 AFAICT. > - After seeing Raymond's talk about monocle (search for it on PyPI) I > am getting excited again about PEP 380 (yield from, return values from > generators). Having read the PEP on the plane back home I didn't see > anything wrong with it, so it could just be accepted in its current > form. Implementation will still have to wait for Python 3.3 because of > the moratorium. (Although I wouldn't mind making an exception to get > it into 3.2.) I, like others, want PEP 380 to be in and done (it's exciting!). However, we knew going into the moratorium that it would negatively affect PEP 380 - as a co-author, it was one of the few things which made me second-guess the implementation of the moratorium. So; in this case I'd have to vote no, we knew going in it would do this. > - This made me think of how the PEP process should evolve so as to not > require my personal approval for every PEP. I think the model for > future PEPs should be the one we used for PEP 3148 (futures, which was > just approved by Jesse): the discussion is led and moderated by one > designated "PEP handler" (a different one for each PEP) and the PEP > handler, after reviewing the discussion, decides when the PEP is > approved. A PEP handler should be selected for each PEP as soon as > possible; without a PEP handler, discussing a PEP is not all that > useful. The PEP handler should be someone respected by the community > with an interest in the subject of the PEP but at an arms' length (at > least) fro
Re: [Python-Dev] Python profiler and other tools
On Sun, Jul 25, 2010 at 1:22 PM, "Martin v. Löwis" wrote: .. > It is at best entertaining to ponder about reasons here; I doubt > anything productive can come out of such a discussion. > I disagree. Depending on the reasons for the relative lack of attention to these components, several alternative actions can be taken to improve the situation. Let's focus on the trace module because it is the simplest and in my opinion the most neglected of the three. Guido suggested that a tool like this is best developed outside of stdlib and python-dev should focus on providing stable interfaces such as sys.settrace to third party projects. On one hand, I would agree that it is better not to distribute the trace module at all than to distribute a broken implementation. (Quality of coverage tools is particularly important now when many developers try to improve up their test coverage before or during transition to 3.x.) On the other hand, using sys.settrace interface requires knowledge of the frame object structure which AFAICT is an implementation detail and may change from version to version. I think stdlib should expose a more abstract tracing API such as one implemented by the trace module which would hide frame object details from the user and give direct access to the data extracted from the frames such as file names and line numbers. A higher level module within stdlib can take advantage of implementation details and not be burdened by having to support multiple releases as long as its own user facing API is stable. > It may be fun posting a message to a ten-year-old issue saying > "ACT NOW (you sluggards)", but I question that this will, on average, > improve things. Likewise, speculating that tool support is deliberately > ignored probably won't improve things (specifically *not* responding > to Nick here). > I assume this is directed at Mark Lawrence even though I made the top post under this subject. While I expressed my own share of criticism of Mark's ways, I do believe that what he is doing is extremely valuable. I did not expect such an outcome, but Mark had a lot of success closing the issues that simply slipped under the radar, but were resolved or close to resolution in every other respect. He is apparently putting a lot of his volunteer hours into this work and this is reason enough to overlook occasional rants or poor choice of words. Mark's breadth-first approach to the tracker is unique and does not work for a lot of issues, but at the same time it does work maybe 10-20% of the time and as long as Mark himself does not get discouraged by the low success rate and learns how to communicate more effectively, I think his work will continue benefiting python. > On the other hand, posting actual patches that fix actual bugs can > make a lot of a difference. Also, having a maintainer who is willing > to look into these patches and accept the good ones will make a lot > of a difference. With respect to the trace module, I started both of these things already, but I would really like to hear feedback from people interested in the future of pdb and profile modules as well. ___ 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] Python profiler and other tools
On 25/07/2010 19:34, Alexander Belopolsky wrote: [snip...] On the other hand, posting actual patches that fix actual bugs can make a lot of a difference. Also, having a maintainer who is willing to look into these patches and accept the good ones will make a lot of a difference. With respect to the trace module, I started both of these things already, but I would really like to hear feedback from people interested in the future of pdb and profile modules as well. Antonio Cuni demoed some *great* improvements to the pdb module at EuroPython. A project called pdb++ http://codespeak.net/svn/user/antocuni/hack/pdb.py Among its improvements it includes the ability to debug through generator frames, which pdb can't. It would be great to see some of these fixes folded back into the standard library version. All the best, Michael Foord ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Python profiler and other tools
On Jul 25, 2010, at 11:38 AM, Michael Foord wrote: > On 25/07/2010 19:34, Alexander Belopolsky wrote: >> [snip...] >>> On the other hand, posting actual patches that fix actual bugs can >>> make a lot of a difference. Also, having a maintainer who is willing >>> to look into these patches and accept the good ones will make a lot >>> of a difference. >>> >> With respect to the trace module, I started both of these things >> already, but I would really like to hear feedback from people >> interested in the future of pdb and profile modules as well. >> > > Antonio Cuni demoed some *great* improvements to the pdb module at > EuroPython. A project called pdb++ > > http://codespeak.net/svn/user/antocuni/hack/pdb.py > > Among its improvements it includes the ability to debug through generator > frames, which pdb can't. It would be great to see some of these fixes folded > back into the standard library version. > +1 Raymond ___ 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] Patch submitted for 7447
Hi I have made a documentation patch for issue 7447. I cannot change the stage to patch-review - is this intentional? Would be great if someone could comment on the patch. Leonhard ___ 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] Thoughts fresh after EuroPython
On Sat, Jul 24, 2010 at 7:08 AM, Guido van Rossum wrote: > > > - Commit privileges: Maybe we've been too careful with only giving > commit privileges to to experienced and trusted new developers. I > spoke to Ezio Melotti and from his experience with getting commit > privileges, it seems to be a case of "the lion is much more afraid of > you than you are afraid of the lion". I.e. having got privileges he > was very concerned about doing something wrong, worried about the > complexity of SVN, and so on. Since we've got lots of people watching > the commit stream, I think that there really shouldn't need to be a > worry at all about a new committer doing something malicious, and > there shouldn't be much worry about honest beginners' mistakes either > -- the main worry remains that new committers don't use their > privileges enough. So, my recommendation (which surely is a > turn-around of my *own* attitude in the past) is to give out more > commit privileges sooner. > +1 agreed! > > - Concurrency and parallelism: Russel Winder and Sarah Mount pushed > the idea of CSP > (http://en.wikipedia.org/wiki/Communicating_sequential_processes) in > several talks at the conference. They (at least Russell) emphasized > the difference between concurrency (interleaved event streams) and > parallelism (using many processors to speed things up). Their > prediction is that as machines with many processing cores become more > prevalent, the relevant architecture will change from cores sharing a > single coherent memory (the model on which threads are based) to one > where each core has a limited amount of private memory, and > communication is done via message passing between the cores. This > I do not believe this prediction. The dominant systems being deployed today have 4,6,8,12 cores on a single memory bus with coherent memory. Sure, NUMA is clearly the dominant architecture but any subdivisions will still have multiple cores with access to the same coherent memory. We'll just end up with multiples of that in one system. The future architecture is _not_ the Cell processor. gives them (and me :-) hope that the GIL won't be a problem as long as > we adopt a parallel processing model. Two competing models are the Actor model, which is based on asynchronous communication, and CSP, > which is synchronous (when a writer writes to a channel, it blocks > until a reader reads that value -- a rendezvous). At least Sarah > suggested that both models are important. She also mentioned that a > merger is under consideration between the two major CSP-for-Python > packages, Py-CSP and Python-CSP. I also believe that the merger will > be based on the stdlib multiprocessing package, but I'm not sure. I do > expect that we may get some suggestions from that corner to make some > minor changes to details of multiprocessing (and perhaps threading), > and I think we should be open to those (I expect these will be good > suggestions for small tweaks, not major overhauls). > The async communication model is good regardless of individual architecture because it more readily grows out beyond a single computer to a network of computers when you want to scale an application up. So yes, anything we can do to help that is good. Hoping that the GIL won't be a problem has been a strategy for over a decade. It has failed. It is limiting what people can and will do with Python today. It isn't going to magically un-become a problem. -gps ___ 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] [Idle-dev] IDLE contributors and committers
>> There's no reason why Tal should be obstructed in his goal of making >> IDLE at least acceptable again. It's fairly obvious thaat there aren't >> any committers who have both the inclination /and/ the time to do this, >> so adding Tal (and other interested parties) as a developer makes a lot >> of sense. > > I would certainly accept this as a first step. Although I now use IDLE > much less than I have in previous years, I would be willing to put in > some time towards fixing the major current issues and integrating the > few polished enhancements. If you want commit access, please send me your ssh key. 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] IDLE contributors and committers
> Interested, yes. But until either a) I can commit patches, or b) there > is someone who will respond to commit review recommendations with "No, > here is why not" or "Yes, committed", I will work on other issues, such > as doc issues, for which I can get responses. If you are then still interested in getting commit access, please send me your SSH key. 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] Does trace modules have a unit test?
On Mon, Jul 26, 2010 at 1:50 AM, Alexander Belopolsky wrote: > On Sat, Jul 24, 2010 at 11:18 PM, Nick Coghlan wrote: >> On Sun, Jul 25, 2010 at 2:20 AM, Alexander Belopolsky >> wrote: > .. >>> Step 1: Rename test_trace to test_sys_settrace and test_profilehooks >>> to test_sys_setprofile. > .. >> A tracetester helper module + the two test module renames sounds like >> a fine idea to me (your proposed new names should be clearer than the >> existing *hooks naming, given the existence of "profile" and "trace" >> modules). > > I have implemented the step 1 above in 3.2 and 2.7 branches, but > svnmerge failed in 3.1 and I suspect that this was because r79102 did > not make it to release31-maint. It is my understanding that test > improvements are normally backported to maintenance branches and > r79102 is a test-only revision. Unfortunately, I was not able to > figure out how to convince svnmerge to merge r79102 in 3.1. Can > someone help? Looking at r79102, it updates a number of tests to use the new assert* unittest methods that aren't available in Python 3.1. So while the patch itself is test-only, it can't be backported because it depends on new features. While the general preference is to backport tests, it is also acknowledged that that can become overly difficult as the test cases diverge. Up to you if you want to manually fix your patch for 3.1, drop the test_profilehooks changes, or else just not backport at all. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Does trace modules have a unit test?
On Sun, Jul 25, 2010 at 5:57 PM, Nick Coghlan wrote: .. > While the general preference is to backport tests, it is also > acknowledged that that can become overly difficult as the test cases > diverge. Up to you if you want to manually fix your patch for 3.1, > drop the test_profilehooks changes, or else just not backport at all. Thanks for explanation, Nick. Since my change is for the benefit of tests that are planned to go in 2.7, it makes little sense to skip 3.1. The change introduced by r79102 in the relevant files is trivial (s/== None/is None/). I just added it manually. See rev 83148. ___ 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] Patch submitted for 7447
On 7/25/2010 2:58 PM, Leonhard Vogt wrote: I have made a documentation patch for issue 7447. I cannot change the stage to patch-review - is this intentional? Would be great if someone could comment on the patch. Done x 3 -- Terry Jan Reedy ___ 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] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
On 7/24/2010 11:21 PM, Guido van Rossum wrote: On Sat, Jul 24, 2010 at 6:51 PM, P.J. Eby wrote: By the way, the PEP's "optimized" implementation could probably be done just by making generator functions containing yield-from statements return an object of a different type than the standard geniter. + 1 Not a bad idea. I have not read the PEP thoroughly enough to understand the new behavior and suggest another name, but I would really like to not have to change current references to 'generator instances' in texts to "generators instances created by generator functions that only contain 'yield' and not 'yield from'". -- Terry Jan Reedy ___ 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] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
P.J. Eby wrote: I would like to reiterate (no pun intended) the suggestion of a special syntactic form for the return Allowing a return value, but then having that value silently disappear, seems like it would delay ... learning If I remember correctly, all these arguments were made at the time, even by Guido himself, and he eventually came around to the view that treating generator returns specially wasn't worth the trouble. -- Greg ___ 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] Thoughts fresh after EuroPython
On Sun, Jul 25, 2010 at 2:26 PM, Jesse Noller wrote: > On Sat, Jul 24, 2010 at 10:08 AM, Guido van Rossum wrote: >> - After seeing Raymond's talk about monocle (search for it on PyPI) I >> am getting excited again about PEP 380 (yield from, return values from >> generators). Having read the PEP on the plane back home I didn't see >> anything wrong with it, so it could just be accepted in its current >> form. Implementation will still have to wait for Python 3.3 because of >> the moratorium. (Although I wouldn't mind making an exception to get >> it into 3.2.) > > I, like others, want PEP 380 to be in and done (it's exciting!). > However, we knew going into the moratorium that it would negatively > affect PEP 380 - as a co-author, it was one of the few things which > made me second-guess the implementation of the moratorium. So; in this > case I'd have to vote no, we knew going in it would do this. I was/am pro PEP 380 and pro Moratorium. We knew going in to the moratorium that PEP 380 wouldn't be included and talked about it extensively. We should honor that now for the same reasons we talked about then: declaring "no syntax changes" allows for a focus on the stdlib. -Jack ___ 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] View tracker patches with ViewVC?
To review a patch on the tracker, I have to read and try to make sense of the raw diff file. Sometimes that is easy, sometimes not. *After* a patch is applied, I can click the rev link and then the 'text changed' link and see a nice, colored, side-by-side web-pace view created by ViewVC. Is there any way a 'view' button could be added, along with the current edit and remove buttons, to produce the same web page and make it easier to review patches *before* commitment? -- Terry Jan Reedy ___ 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] View tracker patches with ViewVC?
Am 26.07.2010 02:24, schrieb Terry Reedy: > To review a patch on the tracker, I have to read and try to make sense > of the raw diff file. Sometimes that is easy, sometimes not. > > *After* a patch is applied, I can click the rev link and then the > 'text changed' link and see a nice, colored, side-by-side web-pace view > created by ViewVC. Is there any way a 'view' button could be added, > along with the current edit and remove buttons, to produce the same web > page and make it easier to review patches *before* commitment? You should be using Rietveld for that. 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] Python Language Summit EuroPython 2010
On Sun, Jul 25, 2010 at 10:41 AM, Alexander Belopolsky
wrote:
> On Sun, Jul 25, 2010 at 1:13 PM, Eric Smith wrote:
>> On 7/23/10 2:44 AM, Guido van Rossum wrote:
>>>
>>> Indeed, we meant b'...{}...{}...'.format(x, y). The problem is that it
>>> can't invoke x.__format__() or y.__format__() since those will return
>>> text strings instead of bytes. A proposed solution was to try
>>> x.__bformat__() etc. Another proposed solution was to limit x and y to
>>> a small set of common types and hard-code their meanings (e.g.
>>> numbers, bytes, and dates).
>>
>> If there were an __bformat__ method, what would object.__bformat__() return?
>
> Maybe self.__format__(..).encode('ascii')? ...encode('utf-8') is a
> tempting alternative as well.
-1
That would bring back the "it fails for some users but passes for the
developer" problem. (True, if the developer calls .encode('ascii') it
may also break, but then at least it is something the developer chose
to do.)
How hard would it be to recode the sprintf language but with the
locale fixed to "C"? That would always be ASCII. Otherwise,
str(x).encode('ascii') might work, that's like the ISO format with the
'T' replaced by a space. (One issue: it's not fixed-width, since it
shows the microseconds iff they are nonzero. If I had to choose I'd
never show the microseconds.)
--
--Guido van Rossum (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
Re: [Python-Dev] Python profiler and other tools
On Sun, Jul 25, 2010 at 11:53 AM, Raymond Hettinger wrote: > On Jul 25, 2010, at 11:38 AM, Michael Foord wrote: >> Antonio Cuni demoed some *great* improvements to the pdb module at >> EuroPython. A project called pdb++ >> >> http://codespeak.net/svn/user/antocuni/hack/pdb.py >> >> Among its improvements it includes the ability to debug through generator >> frames, which pdb can't. It would be great to see some of these fixes folded >> back into the standard library version. >> > > +1 +1 on adding tracing through generators. Not so much about the other pdb++ features that were demoed. While I liked the demo at EuroPython (and applauded), in general I am wary of adding this kind of UI cleverness to the stdlib -- things like the (seemingly curses-based) updating of the listing in-line are usually pretty fragile. Also the development cycle of a tool like this is likely 1-2 orders of magnitude over that of the stdlib. (For this reason I also think it's right that ipython is still a 3rd party tool). -- --Guido van Rossum (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
Re: [Python-Dev] Python Language Summit EuroPython 2010
On Sun, Jul 25, 2010 at 9:46 PM, Guido van Rossum wrote: .. > If I had to choose I'd never show the microseconds. Or the timezone offset, right? ___ 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] Python Language Summit EuroPython 2010
On Sun, Jul 25, 2010 at 9:46 PM, Guido van Rossum wrote:
..
>> Maybe self.__format__(..).encode('ascii')? ...encode('utf-8') is a
>> tempting alternative as well.
>
> -1
>
> That would bring back the "it fails for some users but passes for the
> developer" problem. (True, if the developer calls .encode('ascii') it
> may also break, but then at least it is something the developer chose
> to do.)
>
> How hard would it be to recode the sprintf language but with the
> locale fixed to "C"? That would always be ASCII.
This is exactly what I proposed at
http://bugs.python.org/issue7584#msg110240 not so long ago. Given
that stftime language uses every English letter as one of its codes
(both caps and lower case), it would be an effort, but coding it in
python should not be too hard. A C implementation would be harder,
but there must be implementations around available under a suitable
license that can be reused.
In short, definitely +1.
> Otherwise,
> str(x).encode('ascii') might work, that's like the ISO format with the
> 'T' replaced by a space.
Before proposing format(x, ..).encode('ascii') above, I considered
str(x).encode('ascii') , but then realized that for user-defined
classes, str(x) is as likely to contain non-ASCII characters as
format(x, ..).
What about .encode('utf-8')? I thought it was not supposed to break
for any unicode.
___
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] Python Language Summit EuroPython 2010
On Sun, Jul 25, 2010 at 7:20 PM, Alexander Belopolsky
wrote:
> On Sun, Jul 25, 2010 at 9:46 PM, Guido van Rossum wrote:
> ..
>>> Maybe self.__format__(..).encode('ascii')? ...encode('utf-8') is a
>>> tempting alternative as well.
>>
>> -1
>>
>> That would bring back the "it fails for some users but passes for the
>> developer" problem. (True, if the developer calls .encode('ascii') it
>> may also break, but then at least it is something the developer chose
>> to do.)
>>
>> How hard would it be to recode the sprintf language but with the
>> locale fixed to "C"? That would always be ASCII.
>
> This is exactly what I proposed at
> http://bugs.python.org/issue7584#msg110240 not so long ago. Given
> that stftime language uses every English letter as one of its codes
> (both caps and lower case), it would be an effort, but coding it in
> python should not be too hard. A C implementation would be harder,
> but there must be implementations around available under a suitable
> license that can be reused.
>
> In short, definitely +1.
For b"...".format() we could also support a subset (still better than
hardcoding something str()-based).
>> Otherwise,
>> str(x).encode('ascii') might work, that's like the ISO format with the
>> 'T' replaced by a space.
>
> Before proposing format(x, ..).encode('ascii') above, I considered
> str(x).encode('ascii') , but then realized that for user-defined
> classes, str(x) is as likely to contain non-ASCII characters as
> format(x, ..).
>
> What about .encode('utf-8')? I thought it was not supposed to break
> for any unicode.
But it still makes an assumption about the output encoding. (So does
ASCII, technically, but way more encodings are ASCII supersets, and
some bytes methods already assume ASCII, e.g. .lower() and friends.)
--
--Guido van Rossum (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
Re: [Python-Dev] Thoughts fresh after EuroPython
On 7/25/10 3:19 PM, "Gregory P. Smith" wrote: > > On Sat, Jul 24, 2010 at 7:08 AM, Guido van Rossum wrote: >> >> - Commit privileges: Maybe we've been too careful with only giving >> commit privileges to to experienced and trusted new developers. I >> spoke to Ezio Melotti and from his experience with getting commit >> privileges, it seems to be a case of "the lion is much more afraid of >> you than you are afraid of the lion". I.e. having got privileges he >> was very concerned about doing something wrong, worried about the >> complexity of SVN, and so on. Since we've got lots of people watching >> the commit stream, I think that there really shouldn't need to be a >> worry at all about a new committer doing something malicious, and >> there shouldn't be much worry about honest beginners' mistakes either >> -- the main worry remains that new committers don't use their >> privileges enough. So, my recommendation (which surely is a >> turn-around of my *own* attitude in the past) is to give out more >> commit privileges sooner. > > +1 agreed! > >> >> - Concurrency and parallelism: Russel Winder and Sarah Mount pushed >> the idea of CSP >> (http://en.wikipedia.org/wiki/Communicating_sequential_processes) in >> several talks at the conference. They (at least Russell) emphasized >> the difference between concurrency (interleaved event streams) and >> parallelism (using many processors to speed things up). Their >> prediction is that as machines with many processing cores become more >> prevalent, the relevant architecture will change from cores sharing a >> single coherent memory (the model on which threads are based) to one >> where each core has a limited amount of private memory, and >> communication is done via message passing between the cores. This > > I do not believe this prediction. The dominant systems being deployed today > have 4,6,8,12 cores on a single memory bus with coherent memory. Sure, NUMA > is clearly the dominant architecture but any subdivisions will still have > multiple cores with access to the same coherent memory. We'll just end up > with multiples of that in one system. The future architecture is _not_ the > Cell processor. +1 And there is so much legacy software out there that depends on single coherency systems that it is unlikely such a memory architecture would become pervasive, given the hurdle of rewriting those programs, python programs included. >> gives them (and me :-) hope that the GIL won't be a problem as long as >> we adopt a parallel processing model. Two competing models are the >> Actor model, which is based on asynchronous communication, and CSP, >> which is synchronous (when a writer writes to a channel, it blocks >> until a reader reads that value -- a rendezvous). At least Sarah >> suggested that both models are important. She also mentioned that a >> merger is under consideration between the two major CSP-for-Python >> packages, Py-CSP and Python-CSP. I also believe that the merger will >> be based on the stdlib multiprocessing package, but I'm not sure. I do >> expect that we may get some suggestions from that corner to make some >> minor changes to details of multiprocessing (and perhaps threading), >> and I think we should be open to those (I expect these will be good >> suggestions for small tweaks, not major overhauls). > > The async communication model is good regardless of individual architecture > because it more readily grows out beyond a single computer to a network of > computers when you want to scale an application up. So yes, anything we can > do to help that is good. +1 > Hoping that the GIL won't be a problem has been a strategy for over a decade. > It has failed. It is limiting what people can and will do with Python today. > It isn't going to magically un-become a problem. +1 FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They work. And they work well. But we make light use of threads (mostly background I/O handling), and heavy use of multiple processes because we can't take advantage of our multi-core systems otherwise. -peter > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/peter.a.portante%40gmail.com ___ 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] Thoughts fresh after EuroPython
On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante wrote: > FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They > work. And they work well. But we make light use of threads (mostly > background I/O handling), and heavy use of multiple processes because we > can't take advantage of our multi-core systems otherwise. Isn't this an indication that the GIL is, in fact, not (much of) a problem? I wish those trying to get rid of the GIL well. But it may not be the panacea some folks are hoping for. Multi-threaded programming remains hard (and removing the GIL might actually make it harder). Jython and IronPython don't have a GIL, and I think PyPy may not either. Does anyone have experience with GIL-free programming in one of those? -- --Guido van Rossum (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
Re: [Python-Dev] Thoughts fresh after EuroPython
On 7/25/10 11:42 PM, "Guido van Rossum" wrote: > On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante > wrote: >> FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They >> work. And they work well. But we make light use of threads (mostly >> background I/O handling), and heavy use of multiple processes because we >> can't take advantage of our multi-core systems otherwise. > > Isn't this an indication that the GIL is, in fact, not (much of) a problem? Meaning, we have a working system, so the GIL is not (much of) a problem? Or that we have successfully spent a lot of time and effort rewriting embarrassingly parallel multithreaded algorithms into a bit more complex message passing multi-process algorithms because we can't get the language implementation to make efficient use of multiple CPUs, thus avoiding the GIL from being (much of) a problem? Perhaps we have to ask what does it mean to say the GIL is a problem? If what we mean is that the existence of the GIL does not cause a CPython based program to fail, then yes, it is not a problem at all. In fact, it is a testament to the level of excellence the code has achieved through the hard work folks have put in over the years. If what we mean is that the existence of the GIL prevents a multithreaded CPython application from taking advantage of multiple CPUs, then yes, it is a "problem". So the above statement says that the GIL is not a problem, and that it is THE problem, depending on your definition. :) > I wish those trying to get rid of the GIL well. But it may not be the > panacea some folks are hoping for. You are right, getting rid of the GIL is not a panacea for anything. Removing the GIL means that there will be other changes to the behavioral landscape of the language implementation which folks will have to learn and understand well to write multi-threaded programs that perform well. Anybody wishing to make a whole system run well must engage in that process of learning and discovery. Yet, shouldn't we be able to write a simple embarrassingly parallel multithreaded algorithm in python (no C-extensions) and have its execution use all the cores on a system using CPython? Python is a beautiful language in which to express algorithms. Having to resort to other languages, C extensions, or other implementations of Python, in order to express those algorithms that rely on execution entities sharing a coherent memory space is a limitation imposed by the existence of the GIL in CPython. Is that limitation worth the effort to remove? Perhaps. Perhaps not. Perhaps Jython, or IronPython, or other implementations of Python that don't have a GIL provide a path forward for folks that need that. Those implementations don't currently provide a path forward for what we are doing, so we avoid the use of threads with CPython. > Multi-threaded programming remains > hard (and removing the GIL might actually make it harder). Could we make a statement that the perceived difficulty of multithreaded programming would only increase if a CPython implementation had undocumented behaviors, or undefined behaviors that should be defined? In other words, the difficulty of multithreaded programming is independent of the existence of a/the GIL, but is dependent on the thorough documentation of all language implementation behaviors. > Jython and IronPython don't have a GIL, and I think PyPy may not > either. FWIW: We have considered switching to Jython because it does not have a GIL. Unfortunately, we'd have to find replacements for some of the C-extension modules we use. Sincerely, -peter > Does anyone have experience with GIL-free programming in one > of those? ___ 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] marking os.system() as deprecated in the docs
Hello, I'd like to propose formally marking os.system() as deprecated in the docs for next release of Python (v3.2 ?). The docs for os.system() /already/ include the following paragraph, which is basically tantamount to calling system() deprecated and very much resembles the deprecation notes for the os.popen*() family. """ The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function. Use the subprocess module. Check especially the Replacing Older Functions with the subprocess Module section. """ I'm merely suggesting slapping a formal ".. deprecated::" tag & box around this paragraph to make system()'s status more obvious. I am ***not*** suggesting the function be scheduled for removal or anything like that. I figure since this would be a substantive change (the docs currently don't outright say "deprecated"), it would need dev approval, hence this message. I've already written the absolutely /trivial/ docs patch. So, any objections? Cheers, Chris ___ 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
