Re: [Python-Dev] Sourceforge CVS down?
Tim Peters <[EMAIL PROTECTED]> writes: > [Neil Schemenauer[ >> I've been getting: >> >> ssh: connect to host cvs.sourceforge.net port 22: Connection refused >> >> for the past few hours. Their "Site News" doesn't say anything >> about downtime. > > A cvs update doesn't work for me either now. I did finish one > sometime before noon (EDT) today, though. They've been upgrading the CVS server hardware. See the 'site status' page http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352 Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Nicholas Bastin wrote: > It's a mature product. I would hope that that would count for > something. I've had enough corrupted subversion repositories that I'm > not crazy about the thought of using it in a production system. I > know I'm not the only person with this experience. compared to Perforce, SVN is extremely fragile. I've used both for years, and I've never had Perforce repository break down on me. our SVN repositories are relatively stable these days, but the clients are still buggy as hell (mostly along the "I don't feel like doing this today, despite the fact that it worked yesterday, and I don't feel like telling you what's wrong either" lines. having to nuke workspaces from time to time gets boring, quickly.) in contrast, Perforce just runs and runs and runs. the clients always do what you tell them. and server maintenance is trivial; just make sure that the server starts when the host computer boots, and if you have enough disk, just leave it running. if you're tight on disk space, trim away some log files now and then. that's it. but despite this, if all you need is a better CVS, I'd say SVN is good enough for today's python-dev. I'd still think that a more distributed, mail-driven system (built on top of Mercurial, Bazaar-NG, or some such (*)) would speed up both development and patch processing, and also make it a lot easier for "casual contributors" and "drive-by developers" to help develop Python, but that's another story. *) being able to ship a fully working Python-powered SCM with the Python source code would be an extra coolness bonus, of course. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On 8/10/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > in contrast, Perforce just runs and runs and runs. the clients always > do what you tell them. and server maintenance is trivial; just make sure > that the server starts when the host computer boots, and if you have > enough disk, just leave it running. if you're tight on disk space, trim > away some log files now and then. that's it. We've used P4 at Elemental for two years now; I mostly agree with this assessment, although occasionally the server becomes unbearably slow and a sysadmin does some painful magic to rescue it. Maybe that's just because the box is underpowered. More troublesome is that I've seen a few client repositories getting out of sync; one developer spent a lot of time tracking down mysterious compilation errors that went away after forced resync'ing. We never figured out the cause, but (since he swears he didn't touch the affected files) most likely hitting ^C during a previous sync could've broken some things. Another problem with P4 is that local operation is lousy -- if you can't reach the server, you can't do *anything* -- while svn always lets you edit and diff. Also, P4 has *no* command to tell you which files you've created without adding them to the repository yet -- so the most frequent build breakage is caused by missing new files. Finally, while I hear that P4's branching support is superior over SVN's, I find it has a steep learning curve -- almost every developer needs some serious hand-holding before they understand P4 branches correctly. I'm intrigued by Linus Torvald's preference for extremely distributed source control, but I have no experience and it seems a bit, um, experimental. Someone should contact Steve Alexander, who I believe is excited about Bazaar-NG. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I'm intrigued by Linus Torvald's preference for extremely distributed > source control, but I have no experience and it seems a bit, um, > experimental. "git", which is Linus' home-grown replacement for BitKeeper, quickly attracted a development community and has grown into a reasonably full-featured distributed RCS. It is apparently already stable enough for serious use. If I was trying to pick an RCS for a large, distributed project, I would at least investigate it as a possibility. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
[Guido van Rossum wrote] > Also, P4 has *no* command to tell you which > files you've created without adding them to the repository yet -- so > the most frequent build breakage is caused by missing new files. This one is a frequent complaint from CVS-heads here at ActiveState. I have a p4 wrapper called "px" that extends some p4 commands (and adds a couple). One of the commands that it extends is "diff" to add a "-sn" (new) option similar to the "-se" (edit), "-sd" (delete). $ px help diff ...the usual 'p4 help diff'... new px options: [-sn -c changelist#] Px adds another -s option: -sn Local files not in the p4 client. Px also adds the --skip option (which only makes sense together with -sn) to specify that regularly skipped file (CVS control files, *~) should be skipped. The '-c' option can be used to limit diff'ing to files in the given changelist. '-c' cannot be used with any of the '-s' options. 'px' should grow a "px status" a la "svn|cvs status" to give a quick summary of local differences. Other additions: $ px help px 'px' entensions to 'p4': px --help Add px-specific help output to the usual 'p4 -h' and 'p4 -?'. See 'px help usage'. px -V, --version Print px-specific version information in addition to the usage 'p4 -V' output. See 'px help usage'. px -g ... Format input/output as *un*marshalled Python objects. Compare to the usual 'p4 -G ...'. See 'px help usage'. px annotate ... Identify last change to each line in given file, like 'cvs annotate' or 'p4pr.pl'. See 'px help annotate'. px backout ... Provide all the general steps for rolling back a perforce change as described in Perforce technote 14. See 'px help backout'. px changes -d ... Print the full 'p4 describe -du' output for each listed change. See 'px help changes'. px diff -sn --skip ... List local files not in the p4 depot. Useful for importing new files into a depot via 'px diff -sn --skip ./... | px -x - add'. See 'px help diff'. px diff -c ... Limit diffing to files opened in the given pending change. See 'px help diff'. px genpatch [] Generate a patch (usable by the GNU 'patch' program) from a pending or submitted chagelist. See 'px help genpatch'. Available here: http://starship.python.net/~tmick/#px Pure python. Works on Python >=2.2. Windows, Linux, Mac OS X, Unix. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python + Ping
Hello Everybody, I´m a beginner in python dev.. Well, i need to implement a external ping command and get the results to view the output. How can I do that? Per example, i need to ping and IP address and need to know if the host is down or up. Tka a lot? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pdb: should next command be extended?
[Ilya Sandler wrote] > > > At OSCON, Anthony Baxter made the point that pdb is currently one of the > > more unPythonic modules. > > What is unpythonic about pdb? Is this part of Anthony's presentation > online? (Google found a summary and slides from presentation but they > don't say anything about pdb's deficiencies) Kevin Altis was policing him to 5 minutes for his lightning talk so he didn't have a lot of time to elaborate. :) His slides were more of the Lawrence Lessig, quick and pithy style rather than lots of explanatory text. I think overridability, i.e. being about to subclass the Pdb stuff to do useful things, or lack of it was the main beef. Mostly Anthony was echoing comments from others' experiences with trying to work with the Pdb code. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python + Ping
Joseh Martins wrote: > I´m a beginner in python dev.. > > Well, i need to implement a external ping command and get the results > to view the output. How can I do that? > > Per example, i need to ping and IP address and need to know if the > host is down or up. python-dev is for discussion of the development *of* python, not development *with* python. This question should be posted to the python-list@python.org discussion list (or comp.lang.python newsgroup - they're the same thing) or possibly even the tutor@python.org mailing list. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python + Ping
Your email is off-topic for python-dev, which is for the development OF Python. Repost your question on python-list. - Josiah Joseh Martins <[EMAIL PROTECTED]> wrote: > > Hello Everybody, > > I´m a beginner in python dev.. > > Well, i need to implement a external ping command and get the results > to view the output. How can I do that? > > Per example, i need to ping and IP address and need to know if the > host is down or up. > > Tka a lot? > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jcarlson%40uci.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
> > WindowsError > > > > > > This should be kept. Unlike module specific exceptions, this exception > > occurs in multiple places and diverse applications. It is appropriate > > to list as a builtin. > > > > "Too O/S specific" is not a reason for eliminating this. Looking at the > > codebase there does not appear to be a good substitute. Eliminating > > this one would break code, decrease clarity, and cause modules to grow > > competing variants. [Brett] > I unfortunately forgot to add that the exception would be moved under > os, so it would be more of a renaming than a removal. Isn't OSError already used for another purpose (non-platform dependent exceptions raised by the os module)? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > WindowsError > > > > > > > > > This should be kept. Unlike module specific exceptions, this > exception > > > occurs in multiple places and diverse applications. It is > appropriate > > > to list as a builtin. > > > > > > "Too O/S specific" is not a reason for eliminating this. Looking at > the > > > codebase there does not appear to be a good substitute. Eliminating > > > this one would break code, decrease clarity, and cause modules to > grow > > > competing variants. > > [Brett] > > I unfortunately forgot to add that the exception would be moved under > > os, so it would be more of a renaming than a removal. > > Isn't OSError already used for another purpose (non-platform dependent > exceptions raised by the os module)? > Don't quite follow what that has to do with making WindowsError become os.WindowsError. Yes, OSError is meant for platform-agnostic OS errors by the os module, but how does that affect the proposed move of WindowsError? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
> > Then I don't follow what you mean by "moved under os". > > In other words, to get the exception, do ``from os import > WindowsError``. Unfortunately we don't have a generic win module to > put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > Then I don't follow what you mean by "moved under os". > > > > In other words, to get the exception, do ``from os import > > WindowsError``. Unfortunately we don't have a generic win module to > > put it under. Maybe in the platform module instead? > > -1 on either. The WindowsError exception needs to in the main exception > tree. It occurs in too many different modules and applications. That > is a good reason for being in the main tree. > Where is it used so much? In the stdlib, grepping for WindowsError recursively in Lib in 2.4 turns up only one module raising it (subprocess) and only two modules with a total of three places of catching it (ntpath once, urllib twice). In Module, there are no hits. > If the name bugs you, I would support renaming it to PlatformError or > somesuch. That would make it free for use with Mac errors and Linux > errors. Also, it wouldn't tie a language feature to the name of an MS > product. > I can compromise to this if others prefer this alternative. Anybody else have an opinion? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
On Wed, Aug 10, 2005, Brett Cannon wrote: > On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> >> If the name bugs you, I would support renaming it to PlatformError or >> somesuch. That would make it free for use with Mac errors and Linux >> errors. Also, it wouldn't tie a language feature to the name of an MS >> product. > > I can compromise to this if others prefer this alternative. Anybody > else have an opinion? Googling for "windowserror python" produces 800 hits. So yes, it does seem to be widely used. I'm -0 on renaming; +1 on leaving things as-is. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
[Brett Cannon wrote] > Where is it used so much? In the stdlib, grepping for WindowsError > recursively in Lib in 2.4 turns up only one module raising it > (subprocess) and only two modules with a total of three places of > catching it (ntpath once, urllib twice). In Module, there are no > hits. Just a data point (not really following this thread): The PyWin32 sources raise WindowsError twice (one of them is win32\Demos\winprocess.py which is probably where subprocess got it from) an catches it in 11 places. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
On 8/10/05, Aahz <[EMAIL PROTECTED]> wrote: > On Wed, Aug 10, 2005, Brett Cannon wrote: > > On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >> > >> If the name bugs you, I would support renaming it to PlatformError or > >> somesuch. That would make it free for use with Mac errors and Linux > >> errors. Also, it wouldn't tie a language feature to the name of an MS > >> product. > > > > I can compromise to this if others prefer this alternative. Anybody > > else have an opinion? > > Googling for "windowserror python" produces 800 hits. So yes, it does > seem to be widely used. I'm -0 on renaming; +1 on leaving things as-is. But Googling for "attributeerror python" turns up 94,700, a factor of over 118. OSError turns up 20,300 hits; a factor of 25. Even EnvironmentError turns up more at 5,610 and I would expect most people don't use this class directly that often. While 800 might seem large, it's puny compared to other exceptions. Plus, if you look at the first 10 hits, 4 are from PEP 348, one of which is the top hit. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 352 open ( -2) / 2896 closed ( +8) / 3248 total ( +6) Bugs: 913 open ( +4) / 5162 closed (+10) / 6075 total (+14) RFE : 191 open ( +0) / 178 closed ( +0) / 369 total ( +0) New / Reopened Patches __ compiler package: "global a; a=5" (2005-08-04) http://python.org/sf/1251748 opened by Armin Rigo Simplying Tkinter's event loop (2005-08-05) http://python.org/sf/1252236 opened by Michiel de Hoon modulefinder misses modules (2005-08-05) http://python.org/sf/1252550 opened by Thomas Heller poplib list() docstring fix (2005-08-05) CLOSED http://python.org/sf/1252706 opened by Steve Greenland QuickTime API needs corrected object types (2005-08-09) http://python.org/sf/1254695 opened by Christopher K Davis GCC detection for runtime_library_dirs when ccache is used (2005-08-09) http://python.org/sf/1254718 opened by Seo Sanghyeon Patches Closed __ Faster commonprefix in macpath, ntpath, etc. (2005-01-20) http://python.org/sf/1105730 closed by birkenfeld poplib list() docstring fix (2005-08-05) http://python.org/sf/1252706 closed by birkenfeld absolute paths cause problems for MSVC (2003-10-21) http://python.org/sf/827386 closed by loewis Fix LINKCC (Bug #1189330) (2005-07-15) http://python.org/sf/1239112 closed by loewis file.encoding support for file.write and file.writelines (2005-06-04) http://python.org/sf/1214889 closed by birkenfeld st_gen and st_birthtime support for FreeBSD (2005-04-11) http://python.org/sf/1180695 closed by loewis Add unicode for sys.argv, os.environ, os.system (2005-07-02) http://python.org/sf/1231336 closed by loewis Refactoring Python/import.c (2004-12-30) http://python.org/sf/1093253 closed by theller New / Reopened Bugs ___ cgitb gives wrong lineno inside try:..finally: (2005-08-03) http://python.org/sf/1251026 opened by Rob W.W. Hooft Decoding with unicode_internal segfaults on UCS-4 builds (2005-08-03) http://python.org/sf/1251300 opened by nhaldimann smtplib and email.py (2005-08-03) http://python.org/sf/1251528 opened by Cosmin Nicolaescu Python 2.4.1 crashes when importing the attached script (2005-08-04) http://python.org/sf/1251631 opened by Viktor Ferenczi Fail codecs.lookup() on 'mbcs' and 'tactis' (2005-08-04) http://python.org/sf/1251921 reopened by lemburg Fail codecs.lookup() on 'mbcs' and 'tactis' (2005-08-04) http://python.org/sf/1251921 opened by liturgist Issue with telnetlib read_until not timing out (2005-08-04) http://python.org/sf/1252001 opened by padded IOError after normal write (2005-08-04) http://python.org/sf/1252149 opened by Patrick Gerken os.system on win32 can't handle pathnames with spaces (2005-08-05) CLOSED http://python.org/sf/1252733 opened by Ori Avtalion non-admin install may fail (win xp pro) (2005-07-05) CLOSED http://python.org/sf/1232947 reopened by loewis raw_input() displays wrong unicode prompt (2005-01-10) http://python.org/sf/1099364 reopened by prikryl Python interpreter unnecessarily linked against c++ runtime (2005-08-08) http://python.org/sf/1254125 opened by Zak Kipling parser fails on long non-ascii lines if coding declared (2005-08-08) CLOSED http://python.org/sf/1254248 opened by Oleg Noga Docs for list.extend() are incorrect (2005-08-08) CLOSED http://python.org/sf/1254362 opened by Kent Johnson "appropriately decorated" is undefined in MultiFile.push doc (2005-08-09) http://python.org/sf/1255218 opened by Alan float('-inf') (2005-08-10) http://python.org/sf/1255395 opened by Steven Bird bug in use of __getattribute__ ? (2005-08-10) CLOSED http://python.org/sf/1256010 opened by sylvain ferriol Bugs Closed ___ numarray in debian python 2.4.1 (2005-08-02) http://python.org/sf/1249903 closed by birkenfeld incorrect description of range function (2005-08-02) http://python.org/sf/1250306 closed by birkenfeld isinstance() fails depending on how modules imported (2005-08-01) http://python.org/sf/1249615 closed by hgibson50 set of pdb breakpoint fails (2005-07-30) http://python.org/sf/1248127 closed by birkenfeld Fail codecs.lookup() on 'mbcs' and 'tactis' (2005-08-04) http://python.org/sf/1251921 closed by loewis os.system on win32 can't handle pathnames with spaces (2005-08-05) http://python.org/sf/1252733 closed by salty-horse distutils: MetroWerks support can go (2005-07-17) http://python.org/sf/1239948 closed by jackjansen non-admin install may fail (win xp pro) (2005-07-05) http://python.org/sf/1232947 closed by loewis segfault in os module (2005-06-24) http://python.org/sf/1226969 closed by loewis LINKCC incorrect
Re: [Python-Dev] Exception Reorg PEP revised yet again
[Brett] > I can compromise to this if others prefer this alternative. Anybody > else have an opinion? We're not opinion shopping -- we're looking for analysis. Py3.0 is not supposed to just a Python variant -- it is supposed to be better. It is not about making compromises -- it is about only making changes that are clear improvements. First, do no harm. It is an abuse of the PEP process to toss up one random idea after another with whimsical justifications, zero research, zero analysis of the implications, no respect for existing code, no recognition that the current design is somewhat successful, and contravention of basic design principles (Zen of Python). The only thing worse is wasting everyone's time by sticking to the proposals like glue when others take the time to think it through and offer sound reasons why the proposal is not a good idea. [Aahz] > Googling for "windowserror python" produces 800 hits. So yes, it does > seem to be widely used. I'm -0 on renaming; +1 on leaving things as-is. Well said. Squirreling WindowsError away in another namespace harms existing code, reduces clarity, and offers no offsetting gains. It is simply crummy design to take a multi-module, multi-application exception and push it down into a module namespace. +0 on renaming; +1 on leaving as-is. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
> There > is a reason you listed writing a PEP on your own on the "School of > Hard Knocks" list; it isn't easy. I am trying my best here. Hang in there. Do what you can to make sure we get a result we can live with. -- R ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com