Re: Finding skilled pythonistas for micro-jobs?
Paul Rubin wrote this on Sat, Nov 18, 2006 at 04:39:47PM -0800. My reply is below. > "darran" <[EMAIL PROTECTED]> writes: > > Any suggestions then for locating skilled Python/C++ programmers > > for these small (micro) jobs? > I've taken a number of these and always regretted it. They've been > far more hassle than they're worth. But maybe that's just me. I've never seen the point of trying to compete for the kind of work-at-home programming jobs you see posted on Internet clearing houses. A number of reservations have always stopped me: o The problem descriptions are nebulous or incoherent or both. o No background scope is provided. o No performance criteria are set forth. o No pay rate is specified. o No due date is mentioned. Obviously, it would take longer to draw these things together than it would to do the job itself, at least in the posters' opinions. I can't help wondering, though, if they're serious, because, if they need the job completed successfully, however trivial it may be, sooner or later somebody is going to have to do their homework, and, yes, it's going to take at least twice as long as they're willing to spend when they get around to it. I think there's a case to be made for hiring a another full-time programmer if these small jobs keep cropping up. Part of his job description can be to prepare needs assessments and impact analyses and to prioritize requests before he even thinks about beginning a task. It's difficult to outsource these things, and they are time consuming. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 38° — Wind NNW 9 mph — Sky overcast. -- http://mail.python.org/mailman/listinfo/python-list
PythonTidy
I couldn't find a routine to clean up, regularize, and reformat Python code, so I wrote one: http://www.lacusveris.com/PythonTidy/PythonTidy.python Now, I'm looking for beta-testers. Compensation is a bit on the low side. In fact it's limited to the satisfaction of helping out. Thanks. -- .. Chuck Rhode, Sheboygan, WI, USA -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonTidy
Roberto Bonvallet wrote this on Thu, Nov 30, 2006 at 01:21:55PM +. My reply is below. > About changing the shebang line: I'll take it as a bug. > About changing the encoding declaration from vim-style to > emacs-style: I'll take it as an insult :) Ooh! > Both are comments, and should be left that way. Besides, there is no > officially preferred way for each of them. BTW, in a recent thread on > this newsgroup, most people said they preferred #!/usr/bin/env python over > #!/usb/bin/python for the shebang line. See http://tinyurl.com/yngmfr . Thanks for the link. I was unaware of the /usr/bin/env technique and the controversy surrounding it. Thanks, too, for trying *PythonTidy*. As you have no doubt perceived, *PythonTidy* is *not* "table driven." It is a script after all. I decided before writing it that I didn't really need to externalize all the options; nevertheless, most are declared near the beginning where they sit just begging for end-user involvement. See: CODING_SPEC and SHEBANG. *PythonTidy* is all about consistency, consistency, and consistency. You can use it to standardize shebangs and coding across a whole library of Python scripts. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 25° — Wind NW 13 mph -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonTidy
Thomas Heller wrote this on Thu, Nov 30, 2006 at 09:50:25PM +0100. My reply is below. > The two things that bother me at the moment are how the comments are > formatted (dunno if that can be customized or changed easily), and > it would be good if the script took command line args instead of > working as a filter only. Thank you for trying PythonTidy. o Command-line args: Please give an example of a standard command that I might emulate w.r.t. standard argument use. o Comments: Input is parsed twice: I use *tokenize.generate_tokens* to extract the comments and *compiler.parse* to generate the Abstract Syntax Tree (AST). Other applications usually use the AST to generate bytecode, so it contains no information about comments. The tokens list identifies keywords (and comments and some whitespace) but doesn't group them into statements. I need both: comments *and* functional grouping. Fortunately both the AST and the tokens list carry line numbers to reference the source. Unfortunately the AST line numbers are relative to functional groups and do not necessarily apply to the particular keywords that introduce each group. This makes fixing the position of comments relative to reconstructed code a bit of a challenge. For example, when a comment has a line number in the beginning/ending range of what would normally be considered one command, I have to assume it is an inline comment regardless of how it may have appeared in the original code. Out-of-line comments should appear pretty much as they did in the original code, however. Can you provide an example where they do not? Would you prefer that they be left justified or wrapped? >-~ Doc strings (for modules, class declarations, and functions) are another matter. PythonTidy should not mess with them (unless LEFTJUST_DOC_STRINGS is True). They should appear exactly as originally written. I was taught that code ought to be self documenting and that comments more often than not diminish readability by padding the code beyond what can be comprehended on one page (screen). I use them only minimally and am not greatly inconvenienced when they are moved around a little. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 21° — Wind N 8 mph -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonTidy
Thomas Heller wrote this on Fri, Dec 01, 2006 at 10:12:38PM +0100. My reply is below. > Here is part of a diff before and after running PythonTidy on it: > > > -def comptr_setitem(self, index, value): > -# We override the __setitem__ method of the > -# POINTER(POINTER(interface)) type, so that the COM > -# reference count is managed correctly. > +def comptr_setitem(self, index, value): # We override the > __setitem__ method of the > + # > POINTER(POINTER(interface)) type, so that the COM > + # reference count is > managed correctly. > > Can this be customized? I am able to rationalize why this happens, but you are correct: This behavior is not appropriate. I am testing several changes, one of which should prevent it in all cases, obviating the need for a custom switch. -- .. Chuck Rhode, Sheboygan, WI, USA .. 1979 Honda Goldwing GL1000 (Geraldine) .. Weather: http://LacusVeris.com/WX .. 10° — Wind S 5 mph -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonTidy
Thomas Heller wrote this on Fri, Dec 01, 2006 at 10:12:38PM +0100. My reply is below. > Chuck Rhode schrieb: > > o Command-line args: Please give an example of a standard command that > > I might emulate w.r.t. standard argument use. > Well, at least it would be nice if I could call > 'PythonTidy.py mymodule.py' to tidy up the mymodule.py file. I've uploaded a new version of PythonTidy: o http://www.lacusveris.com/PythonTidy/PythonTidy-1.4.python It fixes several problems. Also it allows file names as arguments. > Here is part of a diff before and after running PythonTidy on it: > > -def comptr_setitem(self, index, value): > -# We override the __setitem__ method of the > -# POINTER(POINTER(interface)) type, so that the COM > -# reference count is managed correctly. > +def comptr_setitem(self, index, value): # We override the > __setitem__ method of the > + # > POINTER(POINTER(interface)) type, so that the COM > + # reference count is > managed correctly. > Can this be customized? This problem has been fixed I think. No customization should be required to keep block comments from being rendered as in-line comments. Wolfgang Grafen reported that PythonTidy crashed in Python-2.4 because new Abstract Syntax Tree node types introduced in Python-2.5 weren't available. It was trivial to check availability, so PythonTidy should now run in Python-2.4. However, this has not been thoroughly tested and is not guaranteed. PythonTidy can now recode string literals if required, although this capability is turned off by default. See RECODE_STRINGS. Docstrings will henceforward be enclosed in double quotes when feasible. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 30° — Wind WSW 10 mph — Sky overcast. -- http://mail.python.org/mailman/listinfo/python-list
PythonTidy
That went well. PythonTidy has been looked at at least 10**2 times, and I have received a couple of complaints, which I hope I have addressed satisfactorily -- plenty good enough for a beta test. The basic concept stands. PythonTidy.py cleans up, regularizes, and reformats the text of Python scripts: http://www.LacusVeris.com/PythonTidy/PythonTidy.python What next? Is it appropriately submitted to the Cheese Shop? -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 3° — Wind W 8 mph -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonTidy
rzed wrote this on Tue, Dec 05, 2006 at 08:19:28PM -0500. My reply is below. > I ran PythonTidy on a wxPython sample, and found that wx.CONSTANTS > were being translated to wx.Constants, which won't do at all. Find the first line in the PythonTidy code where the following global variables are declared and change them as follows: PERSONAL = False # This eliminates case manipulation. > The idea of PythonTidy is not bad, but there should be a minimal > option that essentially reindents and nothing more. ... For example, > I don't necessarily need a shebang or coding line for my purposes, > but without going into the code and commenting out lines, I can't > readily suppress them. Yes, it's too bad that PythonTidy doesn't have an *.rc file or a *.cfg file or an *.ini file or an *.xml file or a Registry entry or a Gnome configuration or its own graphical front end or a gob of command-line options, but that's just the way it is. SHEBANG = '' # This removes the shebang line from the output. CODING_SPEC = '' # This removes the coding specification from the output. > As it stands now, I can't trust PythonTidy to do the right thing on > unfamiliar code, and I can't readily try out various options by > simply activating or deactivating them; if I could, it would be much > more useful to me. PythonTidy should be run only on code that is already familiar or that will rapidly become so in the near future. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 25° — Wind SSW 20 mph — Sky overcast. Precipitation. -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonTidy
Thomas Heller wrote this on Tue, Dec 05, 2006 at 07:06:30PM +0100. My reply is below. > I suggest you open the file with open(input-file, "rU"). This doesn't work so pretty good while reading from sys.stdin, so I'm still at the drawing board. -- .. Chuck Rhode, Sheboygan, WI, USA .. 1979 Honda Goldwing GL1000 (Geraldine) .. Weather: http://LacusVeris.com/WX .. 27° — Wind S 15 mph — Sky overcast. -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonTidy
Thomas Heller wrote this on Tue, Dec 05, 2006 at 07:06:30PM +0100. My reply is below. > There is still one major issue. pythonTidy uses open(input-file, > "rb") to open the Python module to tidy up. That does not work on > Windows, at least if the file has (as it should) "\r\n" newlines. Thank you for challenging my parochial world view. I have posted yet another version of PythonTidy: http://www.lacusveris.com/PythonTidy/PythonTidy-1.5.python This one is omnivorous wrt to newlines. > For output, PythonTidy generates "\n" line endings, this should also > be changed on Windows. When OVERRIDE_NEWLINE = None, the first newline encountered on input is the one used throughout the output; otherwise, you can set it to what you want, e.g, OVERRIDE_NEWLINE = '\n'. > PythonTidy outputs strings with single quotes, while my own style is > to use double quotes (I don't think that pep8 prefers one over the > other). Is it possible to customize this? Here is a new global: DOUBLE_QUOTED_STRINGS = True. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 30° — Wind WNW 15 mph — Sky overcast. -- http://mail.python.org/mailman/listinfo/python-list
Re: help: code formatter?
siggi wrote this on Mon, Jan 08, 2007 at 03:33:21PM +0100. My reply is below. > Is there a simple code formatter that first removes all indentations > and then refomats correctly? Why, yes, there is: http://lacusveris.com/PythonTidy/PythonTidy.python -- .. Chuck Rhode, Sheboygan, WI, USA .. 1979 Honda Goldwing GL1000 (Geraldine) .. Weather: http://LacusVeris.com/WX .. 26° — Wind W 17 mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000: Standard API for archives?
samwyse wrote this on Mon, 04 Jun 2007 12:02:03 +. My reply is below. > I think it would be a good thing if a standardized interface > existed, similar to PEP 247. This would make it easier for one > script to access multiple types of archives, such as RAR, 7-Zip, > ISO, etc. Gee, it would be great to be able to open an archive member for update I/O. This is kind of hard to do now. If it were possible, though, it would obscure the difference between file directories and archives, which would be kind of neat. Furthermore, you could navigate archives of archives (zips of tars and other abominations). -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 62° — Wind N 7 mph — Sky overcast. Mist. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000: Standard API for archives?
Tim Golden wrote this on Mon, 04 Jun 2007 15:55:30 +0100. My reply is below. > Chuck Rhode wrote: >> samwyse wrote this on Mon, 04 Jun 2007 12:02:03 +. My reply is >> below. >>> I think it would be a good thing if a standardized interface >>> existed, similar to PEP 247. This would make it easier for one >>> script to access multiple types of archives, such as RAR, 7-Zip, >>> ISO, etc. >> Gee, it would be great to be able to open an archive member for >> update I/O. This is kind of hard to do now. If it were possible, >> though, it would obscure the difference between file directories >> and archives, which would be kind of neat. Furthermore, you could >> navigate archives of archives (zips of tars and other >> abominations). > Just put something together a module called "archive" or whatever, > which exposes the kind of API you're thinking of, offering support > across zip, bz2 and whatever else you want. Put it up on the > Cheeseshop, announce it on c.l.py.ann and anywhere else which seems > apt. See if it gains traction. Take it from there. > NB This has the advantage that you can start small, say with zip and > bz2 support and maybe see if you get contributions for less common > formats, even via 3rd party libs. If you were to try to get it into > the stdlib it would need to be much more fully specified up front, I > suspect. Yeah, this is in the daydreaming stages. I'd like to maintain not-just-read-only libraries of geographic shapefiles, which are available free from governmental agencies and which are riddled with obvious errors. Typically these are published in compressed archives within which every subdirectory is likewise compressed (apparently for no other purpose than a rather vain attempt at flattening the directory structure, which must be reconstituted on the User's end anyway). Building a comprehensive index to what member name(s) the different map layers (roads, political boundaries, watercourses) have in various political districts of varying geographic resolutions is much more than merely frustrating. I've given it up. However, I believe that once I've located something usable, the thing to do is save a grand unified reference locator (GURL) for it. The GURL would specify a directory path to the highest level archive followed by a (potential cascade of) archive member name(s for enclosed archives) of the data file(s) to be operated on. Unpacking and repacking would be behind the scenes. Updates (via FTP) of non-local resources would be transparent, too. I think, though, that notes about the publication date, publisher, resolution, area covered, and format of the map or map layer ought to be kept out of the GURL. My whole appetite for this sort of thing would vanish if access to the shapefiles were more tractable to begin with. -- .. Chuck Rhode, Sheboygan, WI, USA .. 1979 Honda Goldwing GL1000 (Geraldine) .. Weather: http://LacusVeris.com/WX .. 52° — Wind N 9 mph — Sky overcast. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
Grant Edwards wrote this on Mon, 14 May 2007 19:22:16 +. My reply is below. >> Of course. If they're any longer than that then you can't fit an >> entire identifier into a 36-bit CDC 6600 machine register so you >> can do a compare with a single machine instruction. While skimming this discussion, I, too, was suffering flashbacks to CDC's 6-bit Hollerith code. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 69° — Wind NNE 6 mph — Sky partly cloudy. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 style enforcing program
montyphyton wrote this on Thu, 31 May 2007 05:16:30 -0700. My reply is below. > I understand that there are a lot of code beautifiers out there, but > i haven't seen one specially tailored for Python. Consider PythonTidy: o http://lacusveris.com/PythonTidy/PythonTidy.python -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 75° — Wind SSE 9 mph — Sky haze. -- http://mail.python.org/mailman/listinfo/python-list
Re: [JOB] Sr. Python Developer, Northern VA
John J. Lee wrote this on Thu, 22 Mar 2007 21:16:13 +. My reply is below. > I sympathise but conventional wisdom (which surely has a lot of > truth in it) is that employers are not faced with the problem of > minimising false negatives (failing to hire when they should have > hired). They are faced with the problem of minimising false > positives (hiring when they should not have hired). That's a gross > simplification of course, but I'm sure you appreciate the point -- > if you're hiring employees, being fairly risk-averse is probably > quite rational. ... so what's this we hear of employers' (in the US) being so starved for talent that they're willing to bring in young men from overseas with 3.5 kids and 1.5 wives? -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 44° — Wind SSE 7 mph — Sky overcast. Light rain; mist. -- http://mail.python.org/mailman/listinfo/python-list
Re: nonstandard XML character entities?
Martin v. Löwis wrote this on Sat, 14 Apr 2007 09:10:44 +0200. My reply is below. > Paul Rubin: >> I'm new to xml mongering so forgive me if there's an obvious >> well-known answer to this. It's not real obvious from the library >> documentation I've looked at so far. Basically I have to munch of >> a bunch of xml files which contain character entities like ú >> which are apparently nonstandard. -snip- > In ElementTree, the XMLTreeBuilder has an attribute entity which is > a dictionary used to map entity names in entity references to their > definitions. Whether you can make the parser download the DTD > itself, I don't know. What he said Try this on your piano: : import xml.etree.ElementTree # or elementtree.ElementTree prior to 2.5 : ElementTree = xml.etree.ElementTree : import htmlentitydefs : class XmlFile(ElementTree.ElementTree): : def __init__(self, file=None, tag='global', **extra): : ElementTree.ElementTree.__init__(self) : parser = ElementTree.XMLTreeBuilder( : target=ElementTree.TreeBuilder(Element)) : parser.entity = htmlentitydefs.entitydefs : self.parse(source=file, parser=parser) : return It looks goofy as can be, but it works for me. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 32° — Wind Calm -- http://mail.python.org/mailman/listinfo/python-list
Re: nonstandard XML character entities?
Chuck Rhode wrote this on Sat, 14 Apr 2007 09:04:45 -0500. My reply is below. Fixed text wrap: > import xml.etree.ElementTree # or elementtree.ElementTree prior to 2.5 > ElementTree = xml.etree.ElementTree > import htmlentitydefs > class XmlFile(ElementTree.ElementTree): > def __init__(self, file=None, tag='global', **extra): > ElementTree.ElementTree.__init__(self) > parser = ElementTree.XMLTreeBuilder( > target=ElementTree.TreeBuilder(Element)) > parser.entity = htmlentitydefs.entitydefs > self.parse(source=file, parser=parser) > return -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 32° — Wind Calm -- http://mail.python.org/mailman/listinfo/python-list
Re: Conflicting needs for __init__ method
Ben Finney wrote this on Wed, Jan 17, 2007 at 08:27:54PM +1100. My reply is below. > I recommend, instead, separate factory functions for separate input > types. Uh, how 'bout separate subclasses for separate input types? -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 7° — Wind SW 10 mph -- http://mail.python.org/mailman/listinfo/python-list
PythonTidy 1.10
PythonTidy cleans up, regularizes, and reformats the text of Python scripts. It is released under the GNU General Public License. Python scripts are usually so good looking that no beautification is required. However, from time to time, it may be necessary to alter the style to conform to changing standards. This script converts programs in a consistent way. It abstracts the pretty presentation of the symbolic code from the humdrum process of writing it and getting it to work. This is an upgrade. There was a big problem with earlier versions: Canonical values were substituted for strings and numbers. For example, decimal integers were substituted for hexadecimal, and escaped strings for raw strings. Authors of Python scripts usually use peculiar notations for peculiar purposes, and doing away with the peculiarity negatively impacts the readability of the code. This version preserves the original constants (parsed by *tokenize*) in a literal pool indexed by the value they evaluate to. The canonical values (output by *compiler*) are then translated back (when possible) to the original constants by looking them up in the literal pool. -- http://www.lacusveris.com/PythonTidy/PythonTidy-1.10.python";>PythonTidy 1.10 - Cleans up, regularizes, and reformats the text of Python scripts. (18-Jan-07) .. Chuck Rhode, Sheboygan, WI, USA .. mailto:[EMAIL PROTECTED] .. Weather: http://LacusVeris.com/WX .. 20° — Wind WNW 13 mph -- http://mail.python.org/mailman/listinfo/python-list
Re: beep or sound playing under linux
hg wrote this on Mon, Jan 22, 2007 at 04:12:50PM +0100. My reply is below. > Is there a way to do that? (Make noise.) In Gnome there is: gtk.gdk.beep() -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 28° — Wind WSW 10 mph — Sky overcast. -- http://mail.python.org/mailman/listinfo/python-list
Re: Automated resizing of JPEG image + making slices?
Michiel Sikma wrote this on Thu, 15 Feb 2007 22:21:34 +0100. My reply is below. -snip- > I initially hired someone to do it in PHP (don't bite, please :-) > but it seems that I forgot about one thing: the people updating the > site would have been able to upload a huge 30 MB JPEG image, which > PHP would then resize to various sizes and cut them into 200x200 > pieces, which would be fed to the Google Maps API. However, this > costs a lot of memory, and PHP by default only has 8 MB. -snip- > I know some Python (but not much since I've never actually written > that many things in it), and with some effort I could probably make > a simple image manipulator frontend in it, but only if I can find a > good library for doing the actual manipulation. Do any of you know > such libraries? I can't make head or tail of your project's constraints, so the following advice probably isn't worth much. IMHO, slicing and dicing is best done by stand-alone, special-purpose, image-manipulation routines that do their own I/O. Here is a library of such routines: o http://netpbm.sourceforge.net/doc/directory.html These can be chained together (piped) in shell script (or in *python* if you prefer) if they're installed on your server. There is an API (and maybe even a *python* interface), but I've never needed it. For security, the parameters passed to these routines from the wild (such as file names) need to be scrubbed clean of any delimiters that would look like executable shell script code, variable substitutions, or even spurious path names. -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 18° — Wind WNW 13 mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Source Code Beautifier
Franz Steinhaeusler wrote this on Tue, 27 Feb 2007 09:45:42 +0100. My reply is below. > Hello, I did not find any reasonable pyhton source code beautifier > program (preferable gui). -snip- > Is there such a tool around? Why, yes! Yes, there is: o http://lacusveris.com/PythonTidy/PythonTidy.python It doesn't have a graphical user interface, and it doesn't do everything you want, and it isn't reasonable (It's of an unreasonable size.), but it is a beginning. For future reference, look in: o http://cheeseshop.python.org/pypi ... under "reformat." -- .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 26° — Wind WNW 5 mph — Sky overcast. Mist. -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Crawler - Python or Perl?
On Mon, 09 Jun 2008 10:48:03 -0700, disappearedng wrote: > I know Python but not Perl, and I am interested in knowing which of > these two are a better choice. I'm partial to *Python*, but, the last time I looked, *urllib2* didn't provide a time-out mechanism that worked under all circumstances. My client-side scripts would usually hang when the server quit responding, which happened a lot. You can get around this by starting an *html* retrieval in its own thread, giving it a deadline, and killing it if it doesn't finish gracefully. A quicker and considerably grittier solution is to supply timeout parms to the *curl* command through the shell. Execute the command and retrieve its output through the *subprocess* module. -- .. Chuck Rhode, Sheboygan, WI, USA .. 1979 Honda Goldwing GL1000 (Geraldine) .. Weather: http://LacusVeris.com/WX .. 64° — Wind SE 5 mph — Sky partly cloudy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Web Crawler - Python or Perl?
On Sun, 22 Jun 2008 10:47:59 -0700, subeen wrote: > You can avoid the problem using the following code: > import socket > timeout = 300 # seconds > socket.setdefaulttimeout(timeout) Yes, I tried that, too, but I forget what went wrong with it. Perhaps, the socket kept up the handshake even though the download stalled. -- .. Chuck Rhode, Sheboygan, WI, USA .. 1979 Honda Goldwing GL1000 (Geraldine) .. Weather: http://LacusVeris.com/WX .. 73° — Wind Calm -- http://mail.python.org/mailman/listinfo/python-list
Re: Good python equivalent to C goto
On Sun, 17 Aug 2008 09:08:35 -0500, Grant Edwards wrote: > In Python one uses try/raise/except. At the risk of introducing an anachronism and in deference to Mr. "ElementTree" Lundh, I now invoke Godwin's Law (1990): Isn't *try/except* kinda sorta like the musty, old *come from* construct proposed for *fortran*? Here there be typos (abject apologies): o Clark, R. Lawrence. "A Linguistic Contribution to GOTO-less Programming." _Datamation_ Dec. 1973. 18 Aug. 2008 <http://www.fortranlib.com/gotoless.htm>. -- .. Be Seeing You, .. Chuck Rhode, Sheboygan, WI, USA .. Weather: http://LacusVeris.com/WX .. 71° — Wind W 9 mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Best practice for config files?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 May 2025 14:59:28 -0500 "Michael F. Stemper" wrote: > Is requiring the program to be executed in the directory containing > the configuration file considered acceptable practice? Freedesktop.org proposes a specification for where such things ought to be located: + https://specifications.freedesktop.org/basedir-spec/latest/ Here's how I do it: > def get_xdg_config_home(): > > """The configuration directory. > > Normally $HOME/.config. > > """ > > result = pathlib.Path.home() / ".config" > return result - -- .. Be Seeing You, .. Chuck Rhode, Sheboygan, WI, USA .. Weather: https://LacusVeris.com/Wx .. 47° — Wind NNW at 12 mph. Sky clear. -BEGIN PGP SIGNATURE- iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaDB5oAAKCRBg2/xipKOW Ukg/AJ9cWxtykecg31HvVrCz+GhWPOn+gQCePacKiSXFlRdkEeyrzksobcbTCFw= =OzzD -END PGP SIGNATURE- -- https://mail.python.org/mailman3//lists/python-list.python.org
