[Python-Dev] Increase the code coverage of "OS" module
Hi python-dev, I'm interested in increasing the code coverage of the Python stdlib library "OS"Can some one who is already working on this or on a similar issue enlighten me on this? Thanks in advance. RegardsRakesh.G.K ___ 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 in the stdlib
Le Thu, 21 Mar 2013 21:38:41 +0100, Georg Brandl a écrit : > Am 21.03.2013 19:13, schrieb Antoine Pitrou: > > On Wed, 20 Mar 2013 19:57:54 -0700 > > Raymond Hettinger wrote: > >> > >> On Mar 20, 2013, at 12:38 PM, Barry Warsaw > >> wrote: > >> > >> > Right. Ultimately, I think IDLE should be a separate project > >> > entirely, but I guess there's push back against that too. > >> > >> The most important feature of IDLE is that it ships with the > >> standard library. Everyone who clicks on the Windows MSI on the > >> python.org webpage automatically has IDLE. That is why I > >> frequently teach Python with IDLE. > >> > >> If this thread results in IDLE being ripped out of the standard > >> distribution, then I would likely never use it again. > > > > Which says a lot about its usefulness, if the only reason you use > > it is that it's bundled with the standard distribution. > > Just like a lot of the stdlib, it *gets* a lot of usefulness from > being a battery. But just because there are better/more > comprehensive/prettier replacements out there is not reason enough to > remove standard libraries. That's a good point. I guess it's difficult for me to think of IDLE as an actual library. Regards Antoine. ___ 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 in the stdlib
Am 22.03.2013 10:48, schrieb Antoine Pitrou: > Le Thu, 21 Mar 2013 21:38:41 +0100, > Georg Brandl a écrit : > >> Am 21.03.2013 19:13, schrieb Antoine Pitrou: >> > On Wed, 20 Mar 2013 19:57:54 -0700 >> > Raymond Hettinger wrote: >> >> >> >> On Mar 20, 2013, at 12:38 PM, Barry Warsaw >> >> wrote: >> >> >> >> > Right. Ultimately, I think IDLE should be a separate project >> >> > entirely, but I guess there's push back against that too. >> >> >> >> The most important feature of IDLE is that it ships with the >> >> standard library. Everyone who clicks on the Windows MSI on the >> >> python.org webpage automatically has IDLE. That is why I >> >> frequently teach Python with IDLE. >> >> >> >> If this thread results in IDLE being ripped out of the standard >> >> distribution, then I would likely never use it again. >> > >> > Which says a lot about its usefulness, if the only reason you use >> > it is that it's bundled with the standard distribution. >> >> Just like a lot of the stdlib, it *gets* a lot of usefulness from >> being a battery. But just because there are better/more >> comprehensive/prettier replacements out there is not reason enough to >> remove standard libraries. > > That's a good point. I guess it's difficult for me to think of IDLE as > an actual library. You're right, "library" is not a good term, but "battery" certainly is. Georg ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-03-15 - 2013-03-22) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3908 (+20) closed 25389 (+73) total 29297 (+93) Open issues with patches: 1735 Issues opened (56) == #12098: Child process running as debug on Windows http://bugs.python.org/issue12098 reopened by kristjan.jonsson #17430: missed peephole optimization http://bugs.python.org/issue17430 opened by Neal.Norwitz #17432: PyUnicode_ functions not accessible in Limited API on Windows http://bugs.python.org/issue17432 opened by bdirks #17433: stdlib generator-like iterators don't forward send/throw http://bugs.python.org/issue17433 opened by twouters #17435: threading.Timer.__init__() should use immutable argument defau http://bugs.python.org/issue17435 opened by denversc #17436: hashlib: add a method to hash the content of a file http://bugs.python.org/issue17436 opened by techtonik #17437: Difference between open and codecs.open http://bugs.python.org/issue17437 opened by giampaolo.rodola #17438: json.load docs should mention that it always return unicode http://bugs.python.org/issue17438 opened by techtonik #17441: Do not cache re.compile http://bugs.python.org/issue17441 opened by serhiy.storchaka #17442: code.InteractiveInterpreter doesn't display the exception caus http://bugs.python.org/issue17442 opened by pjenvey #17444: multiprocessing.cpu_count() should use hw.availcpu on Mac OS X http://bugs.python.org/issue17444 opened by jszakmeister #17445: Handle bytes comparisons in difflib.Differ http://bugs.python.org/issue17445 opened by barry #17446: doctest test finder doesnt find line numbers of properties http://bugs.python.org/issue17446 opened by Ronny.Pfannschmidt #17447: str.identifier shouldn't accept Python keywords http://bugs.python.org/issue17447 opened by rhettinger #17449: dev guide appears not to cover the benchmarking suite http://bugs.python.org/issue17449 opened by dmalcolm #17453: logging.config.fileConfig error http://bugs.python.org/issue17453 opened by Alzakath #17454: ld_so_aix not used when linking c++ (scipy) http://bugs.python.org/issue17454 opened by alef #17457: Unittest discover fails with namespace packages and builtin mo http://bugs.python.org/issue17457 opened by Claudiu.Popa #17462: argparse FAQ: how it is different from optparse http://bugs.python.org/issue17462 opened by techtonik #17468: Generator memory leak http://bugs.python.org/issue17468 opened by Anssi.Kääriäinen #17469: Fix sys.getallocatedblocks() when running on valgrind http://bugs.python.org/issue17469 opened by piotr #17473: -m is not universally applicable http://bugs.python.org/issue17473 opened by Devin Jeanpierre #17475: Better doc on using python-gdb.py http://bugs.python.org/issue17475 opened by cben #17477: update the bsddb module do build with db 5.x versions http://bugs.python.org/issue17477 opened by doko #17478: Tkinter's split() inconsistent for bytes and unicode strings http://bugs.python.org/issue17478 opened by serhiy.storchaka #17479: Fix test discovery for test_io.py http://bugs.python.org/issue17479 opened by zach.ware #17480: pyvenv should be installed someplace more obvious on Windows http://bugs.python.org/issue17480 opened by jason.coombs #17481: inspect.getfullargspec could use __signature__ http://bugs.python.org/issue17481 opened by michael.foord #17482: functools.update_wrapper mishandles __wrapped__ http://bugs.python.org/issue17482 opened by ncoghlan #17483: Can not tell urlopen not to check the hostname for https conne http://bugs.python.org/issue17483 opened by dwoz #17484: add tests for getpass http://bugs.python.org/issue17484 opened by Thomas Fenzl #17486: datetime.timezone returns the wrong tzname() http://bugs.python.org/issue17486 opened by lregebro #17487: wave.Wave_read.getparams should be more user friendly http://bugs.python.org/issue17487 opened by Claudiu.Popa #17488: subprocess.Popen bufsize=0 parameter behaves differently in Py http://bugs.python.org/issue17488 opened by gregory.p.smith #17489: random.Random implements __getstate__() and __reduce__() http://bugs.python.org/issue17489 opened by vterron #17490: Improve ast.literal_eval test suite coverage http://bugs.python.org/issue17490 opened by ncoghlan #17491: Consolidate traceback.format_tb and traceback.print_tb http://bugs.python.org/issue17491 opened by raduv #17492: Increase test coverage for random (up to 99%) http://bugs.python.org/issue17492 opened by vterron #17496: OS X test for Tk availability in runtktests.py doesn't work http://bugs.python.org/issue17496 opened by alex #17498: error responses from server are masked in smtplib when server http://bugs.python.org/issue17498 opened by r.david.murray #17500: move PC/icons/source.xar to http://www.python.org/community/lo http://
Re: [Python-Dev] cpython (2.7): Issue #17508: Handled out-of-order handler configuration correctly.
Hello, On Fri, 22 Mar 2013 16:28:19 +0100 (CET) vinay.sajip wrote: > http://hg.python.org/cpython/rev/8ae1c28445f8 > changeset: 82881:8ae1c28445f8 > branch: 2.7 > user:Vinay Sajip > date:Fri Mar 22 15:19:24 2013 + > summary: > Issue #17508: Handled out-of-order handler configuration correctly. Could you explain what "out-of-order handler configuration" means? Also, could you add a Misc/NEWS entry for the change / bugfix? Thank you Antoine. ___ 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 in the stdlib
You can use idle from the command line almost as easily as the CP interpreter: 'python -m idlelib' instead of just 'python' (I just tried it to verify). Unlike bare 'python', IDLE includes a grep. Right click on any 'hit' and it opens the file at the specified line. Unlike bare 'python', you can run tests and collect the all the output, from as many tests as you want, in a dynamically right-sized buffer. I'm just getting: ~$ python2.7 -m idlelib /usr/bin/python2.7: No module named idlelib.__main__; 'idlelib' is a package and cannot be directly executed Same with python3... ...but thank you for talking about IDLE (the possibility of reediting and using history it so easy that I'm going to give it a try at least when I'm on windows...) ___ 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 in the stdlib
On Fri, Mar 22, 2013 at 2:48 AM, Antoine Pitrou wrote: > Le Thu, 21 Mar 2013 21:38:41 +0100, > Georg Brandl a écrit : > > > Am 21.03.2013 19:13, schrieb Antoine Pitrou: > > > On Wed, 20 Mar 2013 19:57:54 -0700 > > > Raymond Hettinger wrote: > > >> > > >> On Mar 20, 2013, at 12:38 PM, Barry Warsaw > > >> wrote: > > >> > > >> > Right. Ultimately, I think IDLE should be a separate project > > >> > entirely, but I guess there's push back against that too. > > >> > > >> The most important feature of IDLE is that it ships with the > > >> standard library. Everyone who clicks on the Windows MSI on the > > >> python.org webpage automatically has IDLE. That is why I > > >> frequently teach Python with IDLE. > > >> > > >> If this thread results in IDLE being ripped out of the standard > > >> distribution, then I would likely never use it again. > > > > > > Which says a lot about its usefulness, if the only reason you use > > > it is that it's bundled with the standard distribution. > > > > Just like a lot of the stdlib, it *gets* a lot of usefulness from > > being a battery. But just because there are better/more > > comprehensive/prettier replacements out there is not reason enough to > > remove standard libraries. > > That's a good point. I guess it's difficult for me to think of IDLE as > an actual library. > > It's not a library. It's an application that is bundled in the standard distribution. Mark Tacoma, Washington. ___ 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] Interested in GSoC for biopython
Hi, I'm Zheng from the University of Georgia. I heard about the GSoC several weeks before and found biopython also involved in the peoject. I plan to apply for the GSoC 2013, hoping to make some contributions this summer. I browsed the proposals in biopython wiki sites and find two of them are all interesting topics, especially the codon alignment functionality. I know this has been implemented by pal2nal, and pal2nal is a good program as it accounts for the mismatches between protein and DNA sequences. However, it may raise an error when the protein sequence contains * indicating a stop codon, which is typical when the sequence is translated from genomic DNA. Maybe I could write a python implementation that relax this requirement. Many interesting statistical tests based on codon alignment can also be implemented. As I am new to this group, can anyone give me some suggestions about what I could do while preparing my proposal? Do I need to read the souce code of some major classes in BioPython to better understand how it works as well as the programming style? Thanks. Best, Zheng Ruan Institute of Bioinformatics The University of Georgia___ 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] Interested in GSoC for biopython
On 22 March 2013 21:34, 阮铮 wrote: > Hi, > > I'm Zheng from the University of Georgia. I heard about the GSoC several > weeks before and found biopython also involved in the peoject. I plan to > apply for the GSoC 2013, hoping to make some contributions this summer. [SNIP] This mailing list is for development of Python, not biopython. Try asking on one of the biopython mailing lists: http://biopython.org/wiki/Mailing_lists Oscar ___ 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 in the stdlib
On Thu, Mar 21, 2013, at 05:37 AM, Antoine Pitrou wrote: > Le Wed, 20 Mar 2013 18:48:15 -0400, "Kurt B. Kaiser" > a écrit : > > > > IDLE has a single keystroke round trip - it's an IDE, not just an > > editor like Sublime Text or Notepad. In the 21st century, people > > expect some sort of IDE. Or, they should! > > I don't think I've used an IDE in years (not seriously anyway). If you haven't used IDLE lately, you might want to try it. > I also don't think beginners "expect some sort of IDE", since they > don't know what it is. They probably don't even expect a text editor > at first. Well, they will feel the need in less than a day, IMHO. These days, beginning users are accustomed to a GUI that "does something", not a command line, it seems. Right, they don't know what they need, at first. We should provide an interface that, in our experience, meets a beginner's needs. > > > I'd also like to make a plea to keep IDLE's interface clean and > > basic. There are lots of complex IDEs available for those who want > > them. It's natural for developers to add features, that's what they > > do :-), but you don't hand a novice a Ferrari (or emacs) and expect > > good results. > > What is the point of an IDE without features? None. But IDLE has plenty of features - and minimum clutter. It also works very well on small screens. > Also, this is touching another issue: IDLE needs active maintainers, > who will obviously be experienced Python developers. But if they are > experienced Python developers, they will certainly want the additional > features, otherwise's they'll stop using and maintaining IDLE. > > In other words, if IDLE were actually usable *and* pleasant for > experienced developers, I'm sure more developers would be motivated to > improve and maintain it. That's not the target audience for IDLE. There are many great IDEs for "experienced" developers. It's not my objective to turn IDLE into PyCharm, just to keep some developers motivated. Good design satisfies the target audience - IMHO, we should be working towards the best possible beginner Python interface on Windows, Mac, and Raspberry Pi. To get this done, we need IDLE developers who are interested in supporting beginners. Not so much developers who are interested in adding complex features for their more advanced usage. The complex IDE space is packed - it doesn't need another entry. OTOH, there are few simple IDEs like IDLE. It's a good niche to be in. And, yes, getting the IDLE developers to use IDLE is important - I do so most of the time (emacs for the rest :). That helps to discover IDLE and tkinter bugs, and occasionally exposes the need for a missing feature. > > > It's sometimes said that IDLE is "ugly" or "broken". These terms > > are subjective! > > Subjective statements are not baseless and idiotic. Please don't put words in my mouth. I only said those terms are subjective, which they are. > They come from the experience of people actually wanting to like a > piece of software, you shouldn't discard them at face value. Please don't allege actions I haven't taken! I agree entirely with you - one has to dig deeper to extract some constructive criticism, if it is available. Often, you can't address one person's idea of ugly or broken without raising those issues with another person. -- KBK ___ 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 405 (venv) - why does it copy the DLLs on Windows
Paul Moore gmail.com> writes: > I don't understand what this is saying - can someone clarify the > reason behind this statement? What is different about a > "non-system-wide installation" that causes this issue (I assume > "non-system-wide" means "not All Users")? The reason I ask is that > virtualenv doesn't do this, and I'm not clear if this is because of a > potential bug lurking in virtualenv (in which case, I'd like to find > out how to reproduce it) or because virtualenv takes a different > approach which avoids this issue somehow. One example of a non-system-wide installation is a source build of Python. PEP 405 venvs created from a source build should work in the same way as venvs created using an installed Python. Regards, Vinay Sajip ___ 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] Increase the code coverage of "OS" module
On Fri, Mar 22, 2013 at 2:28 AM, rakesh karanth wrote: > Hi python-dev, > > I'm interested in increasing the code coverage of the Python stdlib library > "OS" > Can some one who is already working on this or on a similar issue enlighten > me on this? > > Thanks in advance. Hey You can check out pypy os tests, we cover a bit more than CPython. (it's py.test based-though you might need to adapt it) ___ 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
