Re: send an email with picture/rich text format in the body
Ten wrote: Sorry for the rant, good luck to the guy if he's solved his problem, but damn, that 90% so let's not bother doing things properly stuff makes my blood boil. You must really hate browsing the web then. :) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding a lost PYTHONPATH with find
John J. Lee wrote:
find / -maxdepth 3 -size -100k -type f -exec grep -sli pythonpath '{}' \;
The minus in '-100k' (meaning less than 100k) seems to be
undocumented, at least on my system.
It should be standard in linux man pages, can't speak for other unices:
TESTS
Numeric arguments can be specified as
+n for greater than n,
-n for less than n,
n for exactly n.
Maybe you were fooled because it's not directly under the description of
-size.
I suppose the -maxdepth is
redundant since I think find searches breadth-first by default.
??? maxdepth determines how deep the search will look, not the order the
search occurs. Your search only find things within 3 levels of the root,
unless your directory tree goes no deeper than that (very unlikely) the
maxdepth can't be redundant.
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
--
http://mail.python.org/mailman/listinfo/python-list
Re: HTMLParser chokes on bad end tag in comment
Fredrik Lundh wrote: Should it? The end tag it chokes on is in comment, isn't it? no. STYLE and SCRIPT elements contain character data, not parsed character data, so comments are treated as characters, and the first / ends the element. Rather than take your word for it, I checked the W3C HTML4 DTD and found this: http://www.w3.org/TR/html4/appendix/notes.html#notes-specifying-data Element content When script or style data is the content of an element (SCRIPT and STYLE), the data begins immediately after the element start tag and ends at the first ETAGO (/) delimiter followed by a name start character ([a-zA-Z]); note that this may not be the element's end tag. Authors should therefore escape / within the content. Escape mechanisms are specific to each scripting or style sheet language. ILLEGAL EXAMPLE: The following script data incorrectly contains a / sequence (as part of /EM) before the SCRIPT end tag: SCRIPT type=text/javascript document.write (EMThis won't work/EM) /SCRIPT In JavaScript, this code can be expressed legally by hiding the ETAGO delimiter before an SGML name start character: SCRIPT type=text/javascript document.write (EMThis will work\/EM) /SCRIPT Guess you learn something new every day. Too bad there's so much illegal code in the wild. :( -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Ricerca Programmatore Python
Scott David Daniels wrote: I understand there is an Italian-language Python group, but _here_ the language is English, even if you begin by an apology in English. ... In consideration for such people, please limit yourself to English. I doubt he'll ever see your reprimand, looks like a hit-and-run job. Too bad we can't force non-English posts through Babelfish first. At the very least, we'll get a good laugh out of it: Blank to all, I write in order to inform you of one proposed of collaboration. I am trying a programmatore for the realization of a minium-software useful in order to analyze and to represent multigrafi. An optimal competence is demanded in uses of Python with the relati to you packages of mathematical rappresentazione (es. matplotlib). For the notion of grafo it is referred to the following pages: http://it.wikipedia.org/wiki/Teoria_dei_grafi (Italian). http://en.wikipedia.org/wiki/Graph_theory (English). The residence in province of Milan, sight of a possible encounter is preferibile. Draft of one retribuita external collaboration. The interested ones can directly contact to the present deliveries in tail to the email, sending the relative resume to me. I hope of to have made what appreciate postando this announcement. In contrary case, I make excuses myself for the disturbance. Salutes, Giandomenico Sica -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Need C# Coding for MD5 Algorithm...
Dennis Lee Bieber wrote: As for the algorithm... http://www.faqs.org/rfcs/rfc1321.html Implement per that spec. It even includes a C-language implementation that you might be able to bastardize into C# Please don't. Crypto algorithms are hard enough to implement correctly as it is. Leave it to the experts and use a library. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
bruno at modulix wrote:
Edward Elliott wrote:
You mean like this:
s = foo + bar
s = 'foo' + 'bar'
s = 'foo' 'bar'
s = '%s%s' % ('foo', 'bar')
[snip]
The real mantra is actually :
There should be one-- and preferably only one --obvious way to do it
Please note the should, preferably, and obvious.
Touche. Please tell me which of the above should obviously be the
preferable way to concatenate strings. All those weasel words prove my
point: it's a vague and watered-down guideline that gives way in the face
of other considerations.
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python - Web Display Technology
SamFeltus wrote: 1. Loss of back button Isn't this really a myth? A page with a time dimension, be it Flash, HTML/JS or whatever, breaks the back button. A page without a time dimension doesn't break the back button. Should we now and forever more give up the time dimension to avoid breaking the back button. Perhaps for non-text sites, the back button is an anachronism? A time-based push model of content delivery, that would be television. One of the web's defining features is it lets you retrieve information in your own order at your own pace. Pages with an unalterable 'time dimension' are nothing more than interactive tv at best. Flash is a fine technology, just not a good one for the web. It's appropriate for games and video clips embedded in a page and that's about it. Other content has no business being in Flash. Usability problems aren't just an artifact of the implementation, they're part of Flash's design. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: dict!ident as equivalent of dict[ident]
Alexander Kozlovsky wrote: With this suggestion, mapping!identifier becomes fully equivalent to mapping[identifier] Penny-wise, pound-foolish. Saves 3 character strokes at the cost of a new special-purpose operator which only works in limited circumstances. To avoid parsing ambiguity, identifier can only contain (as the name implies) alphanumerics and _. So your ! is limited not only to dicts but to certain keys in certain dicts. More complicated than it's worth. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterators: Would rewind be a good idea?
Heiko Wundram wrote: But, think of the following: what if the iterator computes the values at runtime, and you're not iterating over a predefined list of some sort? Do you want the machinery to store the state of the iterator at every earlier point in time (sometimes this may not even be possible, think of socket communication handled by iterators, or of some state being kept in a C extension outside of the grasp of the Python interpreter), and to restore the iterator to this point? This is why the C++ STL has independent forward and backward iterator types. Iterating over containers in memory generally supports both. Iterating over stdin or a socket would only support forward iteration. I can't recall any examples of backwards-only iteration atm... maybe popping values off a stack. My STL's a bit rusty. Anyway, python iterators could provide a prev() method to go with next(). If the iterator doesn't support backwards iteration (sockets, generators), it could raise an exception. Then you could implement rewind as: def rewind (iter) try: while iter.prev(): pass except StopIteration: pass There's no faster way in general to rewind an iterator (think linked lists), just like there's no fast_forward() to automatically jump current iterators to the end of the sequence (which may not terminate anyway, a la itertools.count). Note that backwards iterators are different from iterating in reverse. Namely, the former let's you move back and forth at will in a sequence, while the latter is just a one-way street from back to front. My knowledge of Python's iterators is kind of sketchy, so I may have missed something. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming language productivity
Peter Maas wrote: I think that a LOC comparison between a language that enforces line breaks and another language that enables putting an lots of code in one line doesn't make much sense. I wonder why comparisons aren't made in terms of word count. Word count would include literals, constants, variables, keywords, operators, bracket- and block delimiter pairs. Python indent/unindent would of course also count as block delimiters. I think this would be a more precise measure for software size. I don't disagree, but word counts aren't so simple, either to define or to implement. What counts as a word? Parser tokens? That counts a.b (or a::b, or a-b, depending on language) as 3 words. Block delimiters? After a month, you don't even notice them in properly formatted code, which is why python doesn't have them in the first place. Operators? Then e.g. a = b + c + d + e counts more than a = add (b, c, d, e). The complexity of expressions seems determined by the numbers of operands; using operators as well arguably overcounts. Regardless of the above choices, you still need a parser (or at least a lexer) to count anything. Whitespace separation won't cut it - what happens with 'for (i=0;i5;i++)' or 's = foo bar baz'? If you toss out operators, you could almost get away with regular expressions for counting the identifiers, keywords, and literals. But there's still the problem of overcounting string literals. Line counts are simple to compute and it's easier to agree on which lines to count. Thus their popularity. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP-xxx: Unification of for statement and list-comp syntax
George Sakkis wrote:
Em Dom, 2006-05-21 às 17:11 +0200, Heiko Wundram escreveu:
for node in tree if node.haschildren():
do something with node
as syntactic sugar for:
for node in tree:
if not node.haschildren():
continue
do something with node
[snip]
2) There should be one and preferably only one way to do it.
You mean like this:
s = foo + bar
s = 'foo' + 'bar'
s = 'foo' 'bar'
s = '%s%s' % ('foo', 'bar')
This one and only one way stuff is overrated. I don't care how many ways
there are as long as:
1. at least one way is intuitive
2. every way is easily comprehendible (readable, no side effects, etc)
Now 'one way to do it' is a good mantra for keeping language complexity down
and achieving the second goal. But it needs to be flexible. The proposed
syntax is short, intuitive, and consistent with comprehension/generator
syntax. I'd say it's entirely in keeping with a number of rules which
trump 'one way':
Beautiful is better than ugly.
Flat is better than nested.
Readability counts.
Special cases aren't special enough to break the rules. (proposal eliminates
the current special case for comprehensions/generators)
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
--
http://mail.python.org/mailman/listinfo/python-list
Re: Iterators: Would rewind be a good idea?
Roy Smith wrote: Edward Elliott [EMAIL PROTECTED] wrote: This is why the C++ STL has independent forward and backward iterator types. Let me see if I can paraphrase the difference between the Python design philosophy and the C++ design philosophy about most things. Python says, Let's make things simple enough that it can be explained fully in a couple of paragraphs, even if it means there are some things you can't do. C++ says, Let's make it possible to do anything, even if it makes it complicated enough that it takes a shelf full of books to explain it all. STL has its problems, complexity among them, but just because it's in the STL doesn't automatically make it a bad idea. They faced a similar problem, and this is how some very smart people solved it. There's always value in exploring that. It doesn't get much simpler than adding one method (prev) with symmetry to an existing method (next). There may be value in restartable iterators, but comparing what we've got now to STL isn't the way to convince people it's a good idea :-) BTW I never said backwards iterators were a good idea. I haven't decided yet. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Python - Web Display Technology
[EMAIL PROTECTED] wrote: Flash also behaves consistently cross-browser, cross/platform -- and features cannot be disabled by the user. ^^ And that's a good thing? Maybe for Macromedia, not for us. This smells like astroturf. Flash can load and play external MP3 audio. Flash can render text... Flash can load/parse/serialize/send XML. Flash can access you webcam, allowing you to create your own video chat/IM app. Flash can programatically-build vector shapes, gradients, and fills. It dices! It splices! Flash can heat your coffee, walk your dog, and change your baby! It's the stupendous, miraculous, fantabulous app you can't live without! Flash can #animate# stuff!!! Flash is like a 2 MB download that works in almost *every* browser out there. ...it's pretty phenomenal that all those features could have been crammed into it.(like: a built-in interpreter for a late-version-EcmaScript-compliant scripting language -- that, in many ways, is far more capable than what is available w/ JavaScript in most browsers!) *** This feature can be used for a web-based CMS! It would blow-away anything (non-Java) now available for managing and uploading assets. - Show quoted text - Ugh, definitely astroturf. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Python - Web Display Technology
Roel Schroeven wrote: SamFeltus schreef: Here is a visual argument, I would love to see a list of AJAX and SVG sites that display excellent graphics. [snip] In my humble opinion, those sites are an argument _against_ the use of Flash on websites. They may look pretty (I don't think they do, but I can imagine there are people out there who like the looks of those sites), but they fail as websites: long load times and especially such horrible navigation is a big no-no. A quote regarding web usability comes to mind: If you're website starts winning design awards, be afraid. Be very afraid. Unfortunately I can't locate proper attribution. It may have been Jakob Nielsen. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: The ONE TRUE WAY to use tabs (if you must...)
Andy Sy wrote: [snipped 50 lines of previous message] Also... remember that the 'ONE TRUE WAY' essentially involves *mixing* tabs and spaces for indentation with all the objections that that entails... (although like mentioned above, it should work with Python, at least in the simple cases i've tried) Frankly, the case for tab usage is not that compelling... Quoting usenet posts is like hunting buffalo: only take what you need. http://www.xs4all.nl/~wijnands/nnq/nquote.html#Q2 -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
A little out-of-order execution seems useful here. ;) John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: I can readily believe that the community frequenting the newsgroups, mailing lists, and blogs don't encourage it anymore. But that's a tiny fraction of all perl programmers, and most of them have no exposure to this little clique. Pfft, you are just guessing around now. How many organizations have you worked at? How much exposure to coders whose daily job description doesn't include the word programming? I've been at Fortune 100 companies with thousands of programmers and support staff, and at startups with a half dozen employees. I've been employed at 3 universities from small to huge. I know full-time software developers, software testers, sys admins, network admins, managers, web developers, graphic artists, physics researchers, bioinformatics researchers, instructors, librarians, consultants, contractors, hardware engineers, forensic analysts, and even a law professor. They all code perl to some degree. Many of them don't even know what a newsgroup is, and you can have their cookbook when you pry it from their cold dead hands. Guessing? Hardly. Just not trapped in your insular world of who makes up the perl community. Don't forget that most of the book was written around 1998. Yes, 8 years ago. Doesn't matter. Yes it matters. 8 years is a lot of time in IT. In 1998 Perl5.005 was announced (22 July). [1] Which should tell you a lot if you indeed have 3 years of Perl skills. Tell that to everyone who relies on the cookbook. It gets their job done. They don't care if it was written in the dark ages. Until a replacement comes along, that's what they'll use. Of course Perl itself has moved on, that's not the point. If they are serious with their study they know that a 8 year old book is hardly up to date. I tend to take most IT related books I use that are older then 3-4 years with quite a grain of salt. I am not going to take an 8 year old Java CookBook very seriously for example. Many/most people aren't serious with their study of perl. They just want to get things done. Perl 5 works for them now, it will work for them 10 years from now. Unless something significantly better comes along to justify the cost of switching, they'll stick with what they know. And that includes perl 6. One would hope an updated cookbook is out before then. Or maybe it's not needed because the current one works just fine. Time isn't a great measure of language change. A C++ book from 8-10 years ago is just as good as one today in most respects (maybe exceptions and templates are a bit underused). A C book from 20 years ago is perfectly fine for most purposes (how well does KR stand the test of time?). C99 and C++0x aren't revolutionary changes (ISO committees frown on such things). God only knows how far back useful LISP resources go. You can even find examples on my site that use imported functions (which I will fix, because I frown upon it :-) ). But I doubt you can find a majority in the perl community that *encourages* the use of imported functionality. I'm not arguing what best practices the hardcore community recommends. Many/most perl programmers aren't part of that community, their only exposure is the perl books (especially the cookbook), and they'll do whatever it says in there. Call perl a victim of its own success (a nice position to be in). For many people, whatever the cookbook says goes. If it's wrong, update it. Well, contact the authors or O'Reilly. Sorry, I've got a bad case of not my problem. ;) Seriously, are you using 8 year old Python recipes without thinking? Sure, if they do the job and an updated reference isn't handy. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: [silly] Does the python mascot have a name ?
John D Salt jdsalt_AT_gotadsl.co.uk wrote: Most things don't have names? I'll believe you if you can give me a list of ten things that don't have names. Chairs, couches, tables, desks, beds, cars, pens, phones, trees, windows (can you tell how I came up with this list? ;). Those are all object types without names to identify individual instances. Ed's chair and John's blue car aren't names to me, just descriptions. It's like saying that temporary object on line 24 of function foo. Really, how many things *do* have names? People, pets, computers, ships, and a few guns? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: A little out-of-order execution seems useful here. ;) No, not interested in a pissing contest. Your statement that the Perl community encourages importing is *encouraged* (over using OO without importing) is false. The cookbook says otherwise. So it depends how you define community. You lecturing people on pissing contests, that's rich. Nice way to duck the issue and sound like a winner. Wake me when you decide to address the substance of my arguments. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
George Sakkis wrote: Not trying to be as ass, but can you take this offline or at least in a perl newsgroup ? Arguing on a particular fact or speculation about the perl community is rather unproductive and offtopic for a python newsgroup. No offense taken. It's definitely OT. I left it here because 1) comp.lang.python seems pretty lax about going OT when it's related to the thread, which in this case it was, and 2) the general discussion about what constitutes a community seemed kinda useful. That said, I definitely think the discussion has run its course. It's getting dangerously close to flaming at this point, which indicates it's time to go offline. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Larry Bates wrote: Sorry, I don't buy this. I can write REALLY short programs that don't handle exceptions, don't provide for logging for debugging purposes, don't allow for future growth, etc. I find that 60% of my code has nothing to do with the actual algorithm or function I'm trying to accomplish. It has more to do with handling user's bad input, exceptions, recovering from hardware or communications failures, etc. Wow, only 60%, I'm surprised it's that low :). When I say the algorithms are roughly equivalent, I'm including the amount of input verification and error checking that they do. To me, that's part of the algorithm. Inexperienced programmers can write some pretty short programs that get the job done, but can't handle the real world. Tell me about it. I've taught intro comp sci, things can get real ugly real quick. :) Also, many years ago I wrote a number of applications in APL. We often referred to programs written in APL as write only code because going back to read what you had written after-the-fact was very hard. You could write in one line of APL what takes 1000's of lines of C or even Python and it was pretty efficient also (for applications that needed to manipulate vectors or matrices). Of course. Comparing line counts between assembly and Prolog is pretty useless given the vast discrepancy in their expressive power. Perl and Python are roughly comparable in expressiveness, so it doesn't seem unreasonable to compare their line counts. It might not tell you much, there are undoubtedly better comparisons to make, but I don't think it's grossly unfair the way you suggest. I'm all ears if you have another metric I can test as easily. I understand what you are trying to say, but I can't support your conclusions as presented. What would those be? I tried hard not draw any conclusions. I just want to see how other people's data compares to mine. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: misleading prefix ++
Peter Otten wrote: class Int(object): [snip] ... def __pos__(self): ... if self.half: ... self.value += 1 ... self.half = not self.half ... return self [snip] i = Int() which leads us to: i 0 +i 0 +i 1 +i 1 +i 2 Now that is absolutely lovely. Looks like it's time to join the ranks of Perl and C with an Obfuscated Python Contest. ;) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: How to tell if function was passed a list or a string?
Roy Smith wrote: Ben Finney [EMAIL PROTECTED] wrote: Currently there's no good duck-typing way to differentiate strings from other sequences. I suppose you could do something like: try: foo.isalpha except AttributeError: print foo is not a string Another way: if getattr (foo, 'isalpha', False): print 'foo is a string' Of course now string duck types must have an 'isalpha' and list ones can't, but that shouldn't matter much. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature request: sorting a list slice
John Machin wrote: Use case? quicksort! :) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Terry Hancock wrote: Edward Elliott wrote: For inquiries into real-world code, it's enough to believe that I'm not lying So I don't make assumptions about people without some kind of evidence. There *are* plenty of bad guys out there, so one learns both to have a thick skin and to rely on that which is reasonably proven, rather than making casual assumptions of good will. That'd be like leaving your car in downtown LA overnight with the doors unlocked. So lookup my post history in comp.lang.python on google groups. Do I behave like a scammer or troll? Have I wasted time posting in other threads just to build credibility and dupe everyone here? You make judgements about people in the real world all the time on significantly less information. If you really think I'm making all this up, feel free to ignore to me. Or reserve judgement until you have more data for comparison. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
[EMAIL PROTECTED] wrote: But first things first... and this one I think is solvable - their has got to be an equitable way to count how much code was written - maybe it isn't lines maybe it is ANd that's it - not can we make a qualitative statement beyond that. But simply can we quanitfy the amount of code in some fashion that allows a reasonable comparison? Maybe a count of identifiers and keywords. Symbols like ()[];,. don't add much beyond where to parse the code. And even though operators like +-*/^| et al convey semantics, they need expressions to operate on, in which the identifiers are already counted. You could make a case either way but I'd leave them out for simplicity. The question is how to count explicit names like module.class.func; should that be 1 identifier or 3? Counting as 3 would reward things like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. I'm inclined to just count explicit names as 1. It's still a single object, and I'm not sure a.b.c is more work to process than just c anyway. If you don't care where c is, they're equivalent. If you do care, you've got to remember where the naked c lives, so it just shifts the work from the code to your brain. Then you've got problems with implicit variables/operations. Should perl's $_ be counted? What about python's copy-slice [:]? You can drive yourself crazy worrying about such things, so I'd just start with the simple case by ignoring them. This id-keyword count would appear to be related to how much information you must process to read through the code. Unfortunately you need a parser for each language to measure it. If anyone can provide such a beast, I'll gladly run it against my code. In the meantime, line/char counts are the best I've got. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: The question is how to count explicit names like module.class.func; should that be 1 identifier or 3? Counting as 3 would reward things like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. Not by me, and I doubt it is in general. Well it's all over the Perl Cookbook. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. Not by me, and I doubt it is in general. Well it's all over the Perl Cookbook. Yeah, sure, all over. 125 occurences in 78 recipes. Sure looks like all over to me. Maybe check the book again. It is used in some examples, sure. And it even explains how it works. Yep, 125 times. In 78 recipes. Out of 105 total recipes with 'use'. I'd say a 3:1 ratio is pretty strong encouragement. Don't forget that most of the book was written around 1998. Yes, 8 years ago. Doesn't matter. It's still the standard example reference. People use it heavily. They don't magically know what parts are now deprecated. You can even find examples on my site that use imported functions (which I will fix, because I frown upon it :-) ). But I doubt you can find a majority in the perl community that *encourages* the use of imported functionality. I can readily believe that the community frequenting the newsgroups, mailing lists, and blogs don't encourage it anymore. But that's a tiny fraction of all perl programmers, and most of them have no exposure to this little clique. For many people, whatever the cookbook says goes. If it's wrong, update it. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
Christophe wrote: No, it's really easy : a simple precoomit hook which will refuse any .py file with the \t char in it and it's done ;) $ echo \t t Why would you wan_ _o remove all _ee charac_ers? Isn'_ _ha_ a li__le awkward? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It seems to me the discussion could actually be beneficial. If several different coders gave similar responses, ie code line/character count comparisons, we might be able to see if there is a trend of any sort - the more anecdotes given and we start to have trends - or maybe we don't. What's the point? So you can say: Perl code has on average 1.727 more lines compared to Python? That's more than we know right now. You never know what data will reveal until you collect and analyze it. BTW I'm not limiting this discussion to lines of code. That was simply the most convenient metric available. If people have other metrics to consider, by all means post them. What's the point, both are tools. People who use both Perl and Python pick one to solve a problem because they want to pick what they believe is the right tool. I doubt that the number of lines is often on their mind. What's the point in learning trigonometry? People who survey land just want to mark off boundaries, not solve a bunch of equations. The Pythagoreans built a religious cult on the study of geometric figures. They didn't know or care that their discoveries would be useful in engineering and science. More knowledge = more choice = better tools. When all you have is a hammer, everything looks like a nail. It's as simple as that. If you're happy playing with your hammers, fine. Go away and post in some other thread. People who just know either Perl or Python don't care much about such figures, or so I hope. I don't know Ruby, but if you could show me it produced significantly shorter code with comparable readability to Python, I'd certainly look into it. Lastly, Ed - can you post the code? That may be putting your head in the lion's mouth so to speak and make the whole thread even worse - and your coding style will get shredded by perl advocates... ok nevermind don't post it.' And not by Python advocates? I don't care who rips my code to what. I haven't posted code because people will dissect it to death and lose sight of the big picture. Code can always be improved, it's a question of resources. The point is not what could be done better in my code, but what was done with my skill and my time committment, and what others have done with their skill and their time committment. At some point I may post small snippets of each so others can gauge my style and experience, but I'm afraid it will devolve into a code crtitiquing fest. Ok I'm going to end with a flamebait - but I would posit, ALL OTHER THINGS BEING EQUAL - that a smaller number of characters and lines in code is more maintainable than larger number of characters and lines in the code. And I think that's why a lot of people posted very negative, in the hope that people would not be tempted to make the above very dumb statement. That's not a dumb statement, it's a sensible and testable hypothesis. The more people post their own experiences, the more patterns emerge and testable hypotheses form, which can then be confirmed or debunked with further study. The journey of 1000 miles starts with a single step, etc, etc. Didn't your mother ever tell you how science works? It's not all bunsen burners and test tubes. To everyone who thinks this thread is pointless or a bad idea: please just go away. Your objections have been noted, at this point you're not contributing anything to the discussion. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ben Finney wrote: Until we get the code to examine independently, all we have is an anecdote. Thus the comparison to UFO sightings. Except UFO sightings comprise a large body of data containing a vast number of known false reports and others that appear to be in the same vein with no verified positives despite many concerted efforts to produce such evidence. Here we have a single data point with no positive or negative corroborations. It's like a guy saying he saw a cloud that looks like a python. The cloud's gone now, but other people can watch other clouds and report what they see. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ben Finney wrote: Until we get the code to examine independently, all we have is an anecdote. Thus the comparison to UFO sightings. Except UFO sightings comprise a large body of data containing a vast number of known false reports and others that appear to be in the same vein with no verified positives despite many concerted efforts to produce such evidence. Here we have a single data point with no positive or negative corroborations. It's like a guy saying he saw a cloud that looks like a python. The cloud's gone now, but other people can watch other clouds and report what they see. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Terry Hancock wrote: But the real point is that no one here can make any reasonably objective assessment of whether your data is meaningful unless you post examples. That's what creates the hostility, I think. Fair enough. But see my other posts on why I'm not interested in objective assessments of my code. For inquiries into real-world code, it's enough to believe that I'm not lying, e.g. that I have the programs and ran the tests described. The actual file contents are almost irrelevant. Nothing one can say about my code tells us anything about typical code in the wild. Producing more data points _will_ tell us that. If my data are an outlier, they may be worthless anyway. That's what I'm interested in. Others are interested in analyzing my code. Which is fine, it's just not what I'm after. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
achates wrote: Jorge Godoy wrote Emacs guess what's used in the file and allows me to use tabs all the time, doing the correct thing... That sounds like useful behaviour. vim can do it to. http://www.vim.org/scripts/script.php?script_id=1171 -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Sybren Stuvel wrote: Andy Sy enlightened us with: Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation' idea to work properly in the most basic utilities which have the 8-space tabs assumption hardcoded in them. Fair enough. How much code is viewed with less and cat, and how much is viewed using smart viewers/editors? I think the majority is viewed using the latter. Just for the sake of completeness: cat file |sed 's/\t//g' less -x4 file vim ~/bin.cat #!/bin/sh cat $@ |sed 's/\t//g' :wq alias less='less -x4' -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Mirco Wahab wrote: Maybe somebody would change his style and had a lot of such statements before: which can be expressed in one line: This has a 1:4 line count then. Or, somebody used identifier like: and later: and saved ~40% characters. You got my point? ;-) Hey I completely agree that line counts leave out a lot of information. Measures of the code like complexity, readability, work performed, etc hinge on many more important factors. I don't pretend that lines of code represents any indication of inherent superiority or fitness. But line counts do convey some information. Even if it's only how many lines a particular programmer used to convey his ideas. Real-world and average-case data are more compelling than theoretical limits on how compact code can be. Besides compactness isn't the point, communication is. Maybe line count is a good rough first-cut approximation of that. Maybe it's not. Probably it's both, depending on the case. Talking about the numbers can only shed light on how to interpret them, which as always is 'very carefully'. I'm not saying lines of code necessarily reflects anything else. All I'm saying is, I noticed some properties of my code. I'd like to know what objective properties others have noticed about their code. This is not meant to be a comparison of languages or programming technique, just a sampling of collective wisdom. That always has value, even when it's wrong. By the looks of it, this group is uninterested in the discussion. Which is fine. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: Evaluating my experiences yes, relating your own no. What would the point be? Most important to me would be: am I happy with the result? And that rarely has to do with the number of lines of actual code or the programming language. A language is just a tool. The point is knowing how to pick the right tool for the right job. Anecdotes aren't the answer but they can be the beginning of the question. Besides, whatever happened to pursuing knowledge for its own sake? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Dave Hansen wrote: On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott Just for the sake of completeness: cat file |sed 's/\t//g' That doesn't always work. If you don't see why, you don't understand my objection to TAB characters in text files. less -x4 file That will work. As long as the creator of file used four-space TABs, anyway... I fail to see why less 'will work' but cat 'doesn't always work'. The net effect of both is the same. Unless you're in some weird place that pipes aren't allowed, these should be equivalent: cat file |sed 's/\t//g' |less less -x4 file Now if you're talking about the conversion altering the data's semantics, that's a separate issue that has nothing to do with unix utilities and everything to do with the file formatting. In that case, I'll simply refer you to the rest of this thread for discussion. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
brian d foy wrote: You have to note that rewriting a program, even in the same language, tends to make it shorter, too. These things are measures of programmer skill, not the usefulness or merit of a particular language. I completely agree. But you have to start somewhere. Shorter doesn't really mean anything though, and line count means even less. The number of statements or the statement density might be slightly more meaningful. Furthermore, you can't judge a script by just the lines you see. Count the lines of all the libraries and support files that come into play. Even then, that's next to meaningless unless the two things do exactly the same thing and have exactly the same features and capabilities. For an objective measure of which language/environment is more optimal for a given task, your statement is completely accurate. OTOH for a quick-and-dirty real-world comparison of line counts, and possibly a rough approximation of complexity, the libraries don't matter if they offer more-or-less comparable functionality. Especially if those libraries are the standard ones most people rely on. I'm not attaching any special significance to line counts. They're just a data point that's easy to quantify. What if anything do they mean? How does one measure statement density? What's the divisor in the density ratio - lines, characters, units of work, etc? These are all interesting questions with no easy answers. I can write a one line (or very short) program (in any language) that does the same thing your scripts do just by hiding the good stuff in a library. One of my friends likes to talk about his program that implements Tetris in one statement (because he hardwired everything into a chip). That doesn't lead us to any greater understanding of anything though. Of course. Extreme cases are just that. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
achates wrote: It probably says something about your coding style, particularly in perl. I've found (anecdotally of course) that while perl is potentially the more economical language, writing *legible* perl takes a lot more space. I'm sure it does. My perl (from 5 years ago) may be considered verbose (or not, I don't know). I avoid shortcuts like $_, use strict mode, etc. Then again I frequently use short forms like statement if/unless (blah); when appropriate. So there's a big personal component in there. But again, the interesting thing to me isn't what could one do, it's what are people actually doing in the real world? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Adam Jones wrote: Without any more information I would say the biggest contributor to this dissimilarity is your experience. Having spent an additional five years writing code you probably are better now at programming than you were then. I am fairly confident that if you were to take another crack at these same programs in perl you would see similar results. I am in complete agreement with that statement. One of the bigger differences might have been language changes over time. If you had written this in python five years ago (assuming the python rewrites are relatively current, otherwise this list gets bigger) you would not have generators, iterators, the logging package, built in sets, decorators, and a host of other changes. Some of these features you may not have used, but for every one you did python would have had more weight. Absolutely. Other than that it all boils down to how the algorithm is implemented. Between those three factors you can probably account for most of the differences here. s/probably/maybe. The factors you list are certainly big contributors, but are they most of it? I don't know, there are good arguments both ways. If you removed those factors, would the resulting python be shorter, as long as, or longer than the corresponding perl? Would that mean anything about code complexity, readability, maintainability, etc? I'm not comfortable drawing any conclusions, but asking the questions is good. The real important question is: what has perl done in the last five years to make writing these scripts easier? That's another very good question. One I can't answer. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
William Studenmund wrote: The problem is that tabs take you to the next tab stop, they don't expand to a fixed number of spaces. Got it. You're talking about using tabs other than for initial line indentation on a source file. Yes, then tab expansion is not perfect. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Terry Hancock wrote: Now, of course, the data I provide is nasty, mean, poorly-formatted data, abhorable by space-zealots and tab-libertines alike (;-)), but the point is, unless you have set up your editor to syntax color spaces and tabs differently, you won't see the difference in the original editor. Sure, mixed tabs and spaces were not part of my use case. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
We've finally hit the meta-discussion point. Instead of talking about tabs and spaces, we're talking about talking about tabs and spaces. Which frankly is a much more interesting conversation anyway. achates wrote: Does it matter? Perhaps not if we can use tools which enable us to bridge the divide, like indent auto-detection in emacs and vim. I'm prepared to do that in cases where I have to work with an existing group of coders uasing spaces. If you ask me, which of course you didn't, indentation is just one small part of the larger issue of code formatting. Unfortunately it's the only one that allows some semblance of flexibility. Formatting like brace/paren placement and inter-operator spacing greatly affect readability but are hard-coded into the source. And none of this matters a wit to the semantics of the code. What really should happen is that every time an editor reads in source code, the code is reformatted for display according to the user's settings. The editor becomes a parser, breaking the code down into tokens and emitting it in a personally preferred format. Comments are left untouched apart from initial indentation. On output back to a file, the code can be either written as-is (the next guy's editor will reformat it anyway) or put in some standard form (for the poor shlubs who code with cat/notepad). All this becomes completely transparent to the user, who sees every file he edits in exactly the format he's accustomed to. It's similar to the various pushes for syntactic code storage formats like abstract syntax trees or shudder xml, but works with the existing infrastructure built around processing plain text files. Meanwhile LISP has been storing code in paren-based ASTs since the 50s. vim and emacs can already do this today. It might not be perfect, but if people spent half as much time perfecting this as arguing about tabs vs spaces, we'd all be a lot better off (yes I'm guilty too). It's a cruel irony that Python's creator didn't appreciate the benefits that tab indentation would bring to his own language - the only major language in which indentation levels actually have semantic significance. Fate is a cruel mistress. Or maybe just a heartless bitch. Either way, watch your back. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Michael Tobis wrote: Edward also asked if others had similar experiences. If others did, the assemblage of their opinions would in fact consttitute data. I have no idea why people are giving him such grief over this request. Thank you, Michael. It was starting to feel like I'd asked about the best way to club baby seals in here. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ben Finney wrote: Those samples can be independently verified by any skilled observer at another time. This is what distinguishes them from anecdotes, and breaks your analogy. Anyone who has my source files can run the same tests. The measures are repeatable and reliable, even if at the moment few can perform them on my code. They don't just let anybody walk into the Louvre and cut off a piece of the Mona Lisa for spectral analysis. :) Before the days of cheap video, lots of scientific data was gathered by lone observers recording unrepeatable events. You build statistics by accumulating a vast number of such observations over time. In any case, I never asked for scientific-quality data in the first place. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ben Finney wrote: I responded to a post that seemed to claim that anecdotes about events can be treated as data about events. They can't; that's what I'm arguing. And conveniently ignoring the key part of my post. Here it is again for those who missed it: Before the days of cheap video, lots of scientific data was gathered by lone observers recording unrepeatable events. You build statistics by accumulating a vast number of such observations over time. Sounds like anecdotes can become data to me. It's a stupid argument anyway. Anecdotes *are* data. Some data is repeatable, some is not. All data has an associated confidence level. Single anecdotes are relatively low, as you gather more the confidence level rises (for the aggregate). Eventually you reach the maximal level by definition: the sum of all anecdotes is the universe of available data. No one's saying anecdotes are 100% reliable. But they aren't 0% reliable either. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
achates wrote: A tab is not equivalent to a number of spaces. It is a character signifying an indent, just like the newline character signifies the end of a line. This link posted over in comp.lang.perl.misc expands on that: http://numeromancer.dyndns.org/~timothy/tab-width-independence/description.html To me, tabs are like gotos. In the wrong hands, they can be abused. Novices will do the most hideous things with them. So do we just ban gotos alogether? No - we structure their use to avoid the most obnoxious mistakes and live with the rest in a power/abuse tradeoff. Before you object that modern languages don't use gotos, think again. Break and continue are merely restricted forms of goto, as are exceptions. Don't throw the baby out with the bathwater. Make better tools that allow the good uses and prevent the bad. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
achates wrote: With spaces for indentation, this just isn't possible, because I have to conform to your viewing preferences, and that makes me unhappy. Why would you want to make me unhappy? +5 QOTW -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
python vs perl lines of code
This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. I'm in the process of converting some old perl programs to python. These programs use some network code and do a lot of list/dict data processing. The old ones work fine but are a pain to extend. After two conversions, the python versions are noticeably shorter. The first program does some http retrieval, sort of a poor-man's wget with some extra features. In fact it could be written as a bash script with wget, but the extra processing would make it very messy. Here are the numbers on the two versions: Raw -Blanks -Comments lines chars lines chars lines chars mirror.py 16746321324597 1184009 mirror.pl 30958362115647 1844790 I've listed line and character counts for three forms. Raw is the source file as-is. -Blanks is the source with blank lines removed, including lines with just a brace. -Comments removes both blanks and comment lines. I think -Blanks is the better measure because comments are a function of code complexity, but either works. By the numbers, the python code appears roughly 60% as long by line and 80% as long by characters. The chars percentage being (higher relative to line count) doesn't surprise me since things like list comprehensions and explicit module calling produce lengthy but readable lines. I should point out this wasn't a straight line-for-line conversion, but the basic code structure is extremely similar. I did make a number of improvements in the Python version with stricter arg checks and better error handling, plus added a couple minor new features. The second program is an smtp outbound filtering proxy. Same categories as before: Raw -Blanks -Comments lines chars lines chars lines chars smtp-proxy.py 2617788 222 7749 205 6964 smtp-proxy.pl 96624110 66023469 45214869 The numbers here look much more impressive but it's not a fair comparison. I wasn't happy with any of the cpan libraries for smtp sending at the time so I rolled my own. That accounts for 150 raw lines of difference. Another 70 raw lines are logging functions that the python version does with the standard library. The new version performs the same algorithms and data manipulations as the original. I did do some major refactoring along the way, but it wasn't the sort that greatly reduces line count by eliminating redundancy; there is very little redundancy in either version. In any case, these factors alone don't account for the entire difference, even if you take 220 raw lines directly off the latter columns. The two versions were written about 5 years apart, all by me. At the time of each, I had about 3 years experience in the given language and would classify my skill level in it as midway between intermediate and advanced. IOW I'm very comfortable with the language and library reference docs (minus a few odd corners), but generally draw the line at mucking with interpreter internals like symbol tables. I'd like to here from others what their experience converting between perl and python is (either direction). I don't have the sense that either language is particularly better suited for my problem domain than the other, as they both handle network io and list/dict processing very well. What are the differences like in other domains? Do you attribute those differences to the language, the library, the programmer, or other factors? What are the consistent differences across space and time, if any? I'm interested in properties of the code itself, not performance. And just what is the question to the ultimate answer to life, the universe, and everything anyway? ;) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. Without seeing the actual code this is quite meaningless. Evaluating my experiences yes, relating your own no. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: any plans to make pprint() a builtin?
Ant wrote: Longer, messy, and what's the actual point? Wouldn't: import pprint as pp pp.pprint(x) be better, standard *and* shorter? why not just: from pprint import pprint pprint (x) No need to modify the interpreter when you can pollute the global namespace yourself just as easily. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: do/while structure needed
Dennis Lee Bieber wrote: Would you put the condition at the top of the loop -- and confuse those people who believe the exit condition should appear at the point the exit activates? Confusion is not the issue. You can put the condition smack dab in the middle of the loop, as long as the location is consistent people will know where to look for it. Rejecting because some are confused the first time since other languages do it differently gets you nowhere: some group will always be confused by something. They learn, problem solved. I agree that do/while is unnecessary. But I'd argue against it on grounds of simplicity and readability instead of confusion. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: common practice for creating utility functions?
BartlebyScrivener wrote: QOTW Programming is not just creating strings of instructions for a computer to execute. It's also 'literary' in that you are trying to communicate a program structure to other humans reading the code. Paul Rubin I take it you've never heard of Donald Knuth or literate programming: The main idea is to regard a program as a communication to human beings rather than as a set of instructions to a computer. So you need somebody who's not afraid to write an essay, as well as not afraid to write a computer program. They work together perfectly, but you have to be able to communicate to the computer, and you have to be able to communicate to the human being, and if you don't do both, then you can't expect your program to be as successful. Literate programming is just the best way I know to do both at the same time. My schtick is to promote the idea that humans, not computers, read programs I ask programmers to think of themselves as writers, teachers, expositors. When you're programming, the very act of trying to explain it to another human being forces you to get more clarity. And then later on, you can maintain, modify, and port your programs to other platforms much more easily. Even if your only audience is yourself, everything gets better. http://www-cs-faculty.stanford.edu/~knuth/ http://www-cs-faculty.stanford.edu/~uno/lp.html -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: common practice for creating utility functions?
Bruno Desthuilliers wrote: Then it would be better to just alias it: # def convert_quote(quote): # return make_code(quote) convert_quote = make_code The former makes sense if you're planning to do more with the calling function later. About the fine to do part, remember that Python's function calls are rather expansive... Indeed, their expansiveness makes them great. Unfortunately they're somewhat expensive too. ;) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: using target words from arrays in regex, pythons version of perls 'map'
John Machin wrote: Would you believe steps 3 4? How about two pops and a pass? Quick! Lower the cone of silence! -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: [silly] Does the python mascot have a name ?
Carl J. Van Arsdall wrote: Well, we could call the perl camel Joe but I don't know if the perlcores (read: hardcore PERL users) would be down for that ;) Hmmm. Perl is like smoking, it feels great and gives you cancer. Yes, there's definitely potential here. ;) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Charles DeRykus wrote: This subject thread may be of great interest but I think an language advocacy mailing list would be a better forum. Fair enough, but advocacy isn't at all what I'm after. Anecdotes are fine, after all what is data but a collection of anecdotes? :) Seriously, anecdotes are valuable: they give you another perspective, reflect common wisdom, and can tell you what/where/how to look for hard data. Of course if anyone already has hard data that would be welcome too, but it's hard to even pin down what 'hard data' means in this situation. I'll grant you though, asking for non-value-judgement-laden anecdotes on newsgroups may be asking too much. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ala Qumsieh wrote: Btw, do you include space chars that go toward indentating Python code in your count? If not, you should since they are required. Not so for Perl. All chars are counted on lines which are counted. The perl and python versions use the same amount and type of indentation, which in this case is tab characters. In any case, I wouldn't strip the whitespace out of the perl code just because it's unnecessary for the interpreter. How people deal with code is far more interesting than how machines do, and for us whitespace is necessary (not strictly, but a really really good idea). -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Harry George wrote: This has been discussed repeatedly, and the answer is If you only work alone, never use anyone else's code and no one ever uses your codes, then do as you please. The answer is Do what works best for your project. Smart people can agree on and use whatever convention they want without trouble. The key is consistency. Otherwise use tab-is-4-spaces. Tab is not 4 spaces. Tab is 1 level of indentation. The confusion that tabs equals some fixed width, or can/should be set to some fixed width, is the entire problem hampering their use. It implies that conversion between tabs and spaces is straightforward when it is not. They are not comparable entities. When you do Agile Programming with people using emacs, vim, nedit, xedit, wordpad, eclipse, and who knows what else, the 4-spaces rule is necessary for survival. IOW reward programmers for being sloppy and using poor tools. Anyone who programs in wordpad/xedit has far bigger problems than worrying about tabs vs spaces (as do projects who let people program in wordpad/xedit). Editors which are designed for programming handle tabs and spaces cleanly. The reason is simple: People get confused, and accidentally get the wrong tab indents when they move among editors or among settings on the same editor. Sounds like PEBCAK to me. :) If everyone uses tabs for indent, then it doesn't matter if Joe's vim showed them as 3 spaces while Mary's emacs showed them at 6. You can't get the 'wrong tab indents' when everything is a tab indent. Mixing tabs and spaces is where you get problems. In most languages this is an irritation, requiring some cleanup. In Python it is a disaster requiring re-inventing the coded algorithms. Use the -tt flag to the Python interpreter and you'll catch inconsistencies immediately. Voila, no disaster. Again, you're not complaining about using tabs, you're complaining about mixing tabs and spaces. I completely agree with you that the latter is way too much hassle to even attempt. All I'm saying is that using tabs on their own is perfectly viable and a bit cleaner. I'm not trying to force that preference on anyone else, just get everyone to recognize that one is just as rational and salubrious as the other. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Brian Quinlan wrote: The problem with tabs is that people use tabs for alignment e.g. def foo(): -query = SELECT * - - - FROM sometable - - - WHERE condition Sure it's a problem. When programmers do bad things, what is your response? Slap his nose and say 'Bad, don't do that'? Or take away his toys so he can't do that? Therein lies your answer to tabs or spaces. Both are rational. Of course, a very disciplined group of people could be trained to never use tabs except to align with the current block level but, in practice, that doesn't work. Therefore tabs are bad. Consistency is always hard for people and easy for machines. If you make it a machine task instead of a people task, it can easily work in practice, just like Python easily enforces no mixing of tabs and spaces with the -tt flag. Get editors that use different (background) colors for tabs and spaces so you can easily pick them out even when the above alignment problem isn't noticeable. Use editors that automatically pick the right character when indenting: tabs to the level of indentation of the current block, then spaces afterward for line continuations. Run the code through parsers that detect and flag inconsistencies on check-in. If such tools are lacking, use substitutes in the meantime. Don't allow any code to be checked in where a line departs more than one tab indentation level from its neighbors. It's not perfect, but it eliminates the worst offenses. Good enough often is. Not saying you should do this, just pointing out how tabs are viable. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: send an email with picture/rich text format in the body
anya wrote: I want to send an email message with picture in it. I dont want to put it as attachment but make it in the body of the mail, so every one who open the email will see the picture.. Step 1: convert image to ascii art Step 2: send Step 3: hope recipient uses a fixed-width font -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
help using smptd
I'm having trouble using the smptd module. The docs are woefully inadequate and inspecting the source didn't help either. So far I've figured out how to subclass smtpd.SMTPServer and override the process_message method to handle smtp messages. I create an instance of my server and it listens on the given interface. I can connect to the port it's on and send SMTP commands but it doesn't respond. I've verified that it's actually bound and I'm connecting to the right port. The server object doesn't appear to have any methods like poll() or loop() to continually handle connections, which is all I want it to do. There is a listen method but it does something else. Does SMTPServer have an equivalent to the serve_forever method of BaseHTTPServer.BaseHTTPRequestHandler? If not how do I handle smtp sessions? SMTPServer derives from asyncore/asynchat, but I didn't find what I wanted there either. import smtpd class SMTPProxy (smtpd.SMTPServer): def process_message (self, peer, mailfrom, rcpttos, data): # my code here proxy = SMTPProxy (listen_addr, relay_addr) # now what? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Named regexp variables, an extension proposal.
Paddy wrote: I have another use case. If you want to match a comma separated list of words you end up writing what constitutes a word twice, i.e: r\w+[,\w+] That matches one or more alphanum characters followed by exactly one comma, plus, or alphanum. I think you meant r'\w+(,\w+)*' or if you don't care where or how many commas there are r'[\w,]*' or if previous but has to start with alphanum r'\w[\w,]*' As what constitues a word gets longer, you have to repeat a longer RE fragment so the fact that it is a match of a comma separated list is lost, e.g: r[a-zA-Z_]\w+[,[a-zA-Z_]\w+] That's why god invented % interpolation. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: help using smptd
Heiko Wundram wrote: If you don't define an __init__() yourself (as it seems to be the case here), MRO (and the rules associated with class methods) will take care that the base class' __init__() gets called automatically. Yes __init__ is being called. smtpd.PureProxy doesn't define its own init either and it shows the same behavior as my class: binds to the port but doesn't respond to connections. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Eli Gottlieb wrote: Actually, spaces are better for indenting code. The exact amount of space taken up by one space character will always (or at least tend to be) the same, while every combination of keyboard driver, operating system, text editor, content/file format, and character encoding all change precisely what the tab key does. What you see as tabs' weakness is their strength. They encode '1 level of indentation', not a fixed width. Of course tabs are rendered differently by different editors -- that's the point. If you like indentation to be 2 or 3 or 7 chars wide, you can view your preference without forcing it on the rest of the world. It's a logical rather than a fixed encoding. There's no use in typing tab for indentation when my text editor will simply convert it to three spaces, or worse, autoindent and mix tabs with spaces so that I have no idea how many actual whitespace characters of what kinds are really taking up all that whitespace. I admit it doesn't usually matter, but then you go back to try and make your code prettier and find yourself asking WTF? Sounds like the problem is your editor, not tabs. But I wouldn't rule out PEBCAK either. ;) Undoubtedly adding the second spark to the holy war, Undoubtedly. Let's keep it civil, shall we? And please limit the cross-posting to a minimum. (directed at the group, not you personally Eli). -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: help using smptd
Edward Elliott wrote: import smtpd class SMTPProxy (smtpd.SMTPServer): def process_message (self, peer, mailfrom, rcpttos, data): # my code here proxy = SMTPProxy (listen_addr, relay_addr) # now what? Update: I think I've solved it. SMTPServer registers with asyncore, so the 'now what' to handle connections is this: asyncore.loop() I tried that once before I posted without success, however I think I had accidentally closed the socket already. Now a follow-up question: does anyone know the purpose of the timeout parameter to loop()? The asyncore docs say this: The timeout argument sets the timeout parameter for the appropriate select() or poll() call, measured in seconds; the default is 30 seconds. According to the select man page, timeout determines how long it blocks before returning. But AFAICT, asyncore.loop() runs forever (as long as a channel is open) no matter how long select blocks. What's the point of passing a timeout for select when loop just calls it again every time it returns? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: compiling module from string and put into namespace
glomde wrote: I didnt mean that __import__ isnt a function, but that I want to make a function called ImoprtFile that actually does something very similar that what __import__. So to rephrsase the questin how does __import__ load a module into the callers namespace. Ok got it now. I'm sure it's doable but it sounds tricky. Wouldn't it be easier to just have your function return a list of modules to the caller and have the caller import them? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: distributing a app frozen by cx_freeze
Flavio wrote: ImportError: /home/flavio/freeze/qt.so: undefined symbol: _ZNK9QSGIStyle9classNameEv So my question is: is there a way to find out exactly which lib is missing ? yes - find the one with that symbol. wash, rinse, repeat. ;) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Question regarding checksuming of a file
Andrew Robert wrote: m=md5.new() contents = open(self.file_name,rb).read() check=md5.update(contents) However this does not appear to be actually returning the checksum. the docs are your friend, use them. hint: first you eat, then you... http://docs.python.org/lib/module-md5.html -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: copying files into one
Gary Wessle wrote: I am looping through a directory and appending all the files in one huge file, the codes below should give the same end results but are not, I don't understand why the first code is not doing it. combined = open(outputFile, 'wb') for name in flist: if os.path.isdir(file): continue infile = open(os.path.join(file), 'rb') this shouldn't work. 'file' is a type object, not a filename. did you rebind 'file' without showing us? or should those 'file's be 'name's instead? in either case, calling os.path.join with one argument is pointless. # CODE 1 this does not work tx = infile.read(1000) if tx == : break combined.write(tx) infile.close() hint: where will break take you? therein lies your answer. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: copying files into one
Gary Wessle wrote: I am looping through a directory and appending all the files in one huge file, the codes below should give the same end results but are not, I don't understand why the first code is not doing it. another bit of friendly advice (for others as well): learn to use pdb before posting your code for the group to debug. this type of error is easily catchable with a little effort. you'll learn more by investigating your problems yourself before feeding them to the great distributed debugger known as comp.lang.python. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax for -c cmd
Dennis Lee Bieber wrote: On Thu, 11 May 2006 20:12:55 GMT, Edward Elliott [EMAIL PROTECTED] declaimed the following in comp.lang.python: If putting the else in a separate arg unbinds it from the if, I would expect a syntax error. If OTOH naked elses are allowed on the command line for some odd reason, then this shouldn't happen: More likely, the -C never processed anything after the first quoted statement. Yep you are correct. Odd, I could've sworn I've done that before. Here's what the man page has to say: when called with -c command, it executes the Python statement(s) given as command. Here command may contain multiple statements separated by newlines. ... following options are passed as arguments to the command. So the following works: $ python -c 'if 0 == 1: print foo # arg is unterminated $$ else: print bar' # now we close it bar -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Threads
Dennis Lee Bieber wrote: On 11 May 2006 17:02:51 -0700, placid [EMAIL PROTECTED] declaimed the following in comp.lang.python: do is, when the queue is empty, i want the thread to pause (or more technical, i want the thread to block) until the queue gets populated again. Is this possible ? Did you read the documentation for Queue methods? x = q.get(true) #blocks until data is available Like a good lawyer, Dennis knows the answer before he asks the question. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax for -c cmd
Fredrik Lundh wrote: hint: $ python -c 'import sys; print sys.argv' 'else: print no' /F Yeah the man page knows all. About the only time I use python on the command line is with the timeit module, which evals all arguments given. Hence the confusion. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Reg Ex help
bruno at modulix wrote:
parts = s.replace(' ', '/').strip('/').split('/')
branch = parts[parts.index('CHECKEDOUT') - 1]
Edward Elliott wrote:
marker = s.index('/CHECKEDOUT')
branch = s [s.rindex('/', 0, marker) + 1 : marker]
Much cleaner than mine. I shouldn't try to code when it's time to bed !-)
Not terribly readable though, hard to tell what the magic slice indexes
mean. Yours is easier to follow. I think I'd just use a regex though.
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
--
http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Unix Tools (was: deleting texts between patterns)
Dan Sommers wrote: Or even awk '/abc/,/xyz/' file.txt Excluding the abc and xyz lines is left as an exercise to the interested reader. Once again, us completely disinterested readers get the short end of the stick. :) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Translation of C# DES Encryption
Andreas Pauley wrote: Hi all, I'm trying to implement a Python equivalent of a C# method that encrypts a string. My Python attempt is in the attached file, but does not return the same value as the C# method (see below). Any hints? I can't tell from the code you posted what a DESCryptoServiceProvider does, but I think you're using two different block cipher modes. The C/C# code uses an IV, which means it's probably not using ECB mode. Meanwhile your Python code uses ECB mode, which doesn't even use an IV (the one you provided is probably just ignored). You need to find the exact algorithm the DESCryptoServiceProvider uses. CBC and CTR are common modes with IVs. Besides mode of operation, there's the issue of how it pads the data (in the cipher, not base64). There could also be differences in things like the key scheduling routines, but that's less likely. Until you know exactly what the original code does, your only option is trial and error. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Possible constant assignment operators := and ::= for Python
Piet van Oostrum wrote: [EMAIL PROTECTED] (T) wrote: T As you can see, the constant A can be modified this easily. But if T there were an intuitive mechanism to declare a symbol to be immutable, T then there won't be this problem. Mutability is not a property of symbols but of values. So it doesn't make sense to declare an identifier to be immutable. And mutability is tied to the object's type, not to individual instances. I think he meant immutable binding, not immutable symbol. So rebinding/overshadowing a constant A would raise an error, but mutating the underlying object A refers to would not (unless it too were immutable). As far objects themselves, adding an ability to make any object immutable regardless of type is exactly what he suggests. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: How to get a part of string which follows a particular pattern usingshell script
Anthra Norell wrote: This is the third problem today which I propose to solve with my stream editor SE. If the group thinks it could be useful I would submit it the moment I'm done with the doc, which is in the final stage. You keep saying that and getting no response, so I'll take a stab at telling you why. I take it that when you say 'propose it to the group' and 'submit it for distribution', you mean include it in the standard library. My impression (and fervent hope) is that nobody's gonna throw a new, unfamiliar module straight into the standard library. Put it up somewhere like the cheese shop and let people kick the tires for a few months/years. Then if it solves a real need, works well, is sufficiently general, and isn't handled better by another module, it might be eligible for consideration for inclusion in the standard library. New modules aren't just thrown in there willy-nilly. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: compiling module from string and put into namespace
glomde wrote: Tanks but that isn't what I am looking for. I really want a function that you can call and imports the module into the calling functions namespace. I dont want the caller to call import but a function. come again? type (__builtins__.__import__) type 'builtin_function_or_method' -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: unzip zip files
Marcelo Ramos wrote: DataSmash escribió: file into the subdirectory, but unzips the contents into the root (current) directory. I want the contents of the zip file unloaded into the newly created subdirectory where the zip file is. See -d zip's parameter in man zip. or change the working dir before calling unzip. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax for -c cmd
James wrote: Wrong syntax is shown below. What should be the delimiter before else? python -c 'if 1==1: print yes; else print no' Now this is interesting. I broke the line up into separate arguments and it seemed to work fine: $ python -c 'if 1==1: print yes' 'else: print no' yes But then I tested the else branch and it produces no output: $ python -c 'if 1==0: print yes' 'else: print no' $ If putting the else in a separate arg unbinds it from the if, I would expect a syntax error. If OTOH naked elses are allowed on the command line for some odd reason, then this shouldn't happen: $ python -c 'else: print no' File string, line 1 else: print no ^ SyntaxError: invalid syntax What's with the silent failure in the two-arg version? If the else arg is syntactically acceptable, why doesn't it behave as expected? -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] tdir 1.69 Released And Available
Tim Daneliuk wrote: 'tdir' is a reimplementation and enhancement of the old 'xdir' CP/M utility from Ancient Times. 'tdir' is an advanced directory display utility written in Pure Python, and runs on both *nix and Win32 systems.\ With 'tdir' you can display directories sorted by file extension, ls -X display directory trees, ls -R and separate directories from files in the output listing. ls -u color me unimpressed ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Nested loops confusion
[EMAIL PROTECTED] wrote: Call me crazy, but be careful when programming python in different text editors and in general, ie cutting and pasting, tabing and spacing. Loops can look fine and not work (try moving around test print statements for iterators), in this case try re-tabing your indents so that everything is uniform in the editor you are using. the -tt flag is a good way to catch/avoid such problems: #!/usr/bin/python -tt -- http://mail.python.org/mailman/listinfo/python-list
Re: python equivalent of the following program
Steven Bethard wrote:
import subprocess
file1 = open('file1', 'w')
prog1 = subprocess.Popen(['prog1'], stdout=file1)
And if the script runs somewhere that stderr is likely to disappear:
prog1 = subprocess.Popen(['prog1'], stdout=file1, stderr=subprocess.STDOUT)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Reg Ex help
Bruno Desthuilliers wrote:
don a écrit :
Also if there is a better way than using regex, please let me know.
s =/main/parallel_branch_1/release_branch_1.0/dbg_for_python/CHECKEDOUT
from /main/parallel_branch_1/release_branch_1.0/4
parts = s.replace(' ', '/').strip('/').split('/')
branch = parts[parts.index('CHECKEDOUT') - 1]
I wouldn't call these better (or worse) than regexes, but a slight variation
on the above:
marker = s.index('/CHECKEDOUT')
branch = s [s.rindex('/', 0, marker) + 1 : marker]
This version will throw exceptions when the marker isn't found, which may or
may not be preferable under the circumstances.
--
http://mail.python.org/mailman/listinfo/python-list
Re: FTP filename escaping
Serge Orlov wrote: Almad wrote: OK, after some investigation...problem is in non-latin characters in filenames on ftp. Yes, users should be killed for this, It's futile, users will always find a way to crash you program :) And you can't kill them all, there are too many of them. Yes but you can take their toys away. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: python equivalent of the following program
AndyL wrote: Edward Elliott wrote: And if the script runs somewhere that stderr is likely to disappear: prog1 = subprocess.Popen(['prog1'], stdout=file1, stderr=subprocess.STDOUT) Forgot to mention before that the main motivation is to have the same code on bot Linux and M$ platforms. Does subprocess work well on both? yes Also how to find out that the 'prog1' e.g. has exited and it is done? prog1.wait() or prog1.poll(). look at the subprocess docs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's regular expression?
bruno at modulix wrote: From a readability/maintenance POV, Perl is a perfect nightmare. It's certainly true that perl lacks the the eminently readable quality of python. But then so do C, C++, Java, and a lot of other languages. And I'll grant you that perl is more susceptible to the 'executable line-noise' style than most other languages. This results from its heritage as a quick-and-dirty awk/sed type text processing language. But perl doesn't *have* to look that way, and not every perl program is a 'perfect nightmare'. If you follow good practices like turning on strict checking, using readable variable names, avoiding $_, etc, you can produce pretty readable and maintainable code. It takes some discipline, but it's very doable. I've worked with some perl programs for over 5 years without any trouble. About the only thing you can't avoid are the sigils everywhere. Would I recommend perl for readable, maintainable code? No, not when better options like Python are available. But it can be done with some effort. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can Python installation be as clean as PHP?
XBello wrote: It's possible to work with php just with these single file? Maybe I'm doing the wrong thing, because to start to program I needed to install a web server too (a large bunch of files). PHP can be run from the command line too. On ubuntu/debian it's available by installing the php4-cli package. Not sure about other systems, I didn't see any any obvious links on the php website. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question on code vetting
I'm replying to Ben because William's post is no longer on my news server. [EMAIL PROTECTED] wrote: I would like to offer a couple of links to the kind of stuff I am talking about w.r.t. the transparency issue. First, some from Eclipse: http://www.eclipse.org/legal/ See especially the committer resources Here are a couple more from the Apache software foundation. http://www.apache.org/foundation/how-it-works.html Interesting, those links have nothing to do with checking the source of code and everything to do with the projects covering their asses. Which is perfectly reasonable behavior on their part, but it gives you, the end user, almost no protection. Suppose company X proves that project Foo incorporated some of their unlicensed code. Copyright infringement is a strict liability action. X can obtain an injunction against distributing Foo and impoundment/destruction of all infringing copies. Waivers like those above may indemnify Foo against monetary damages and legal fees, but end users are in the same position as without the waivers: their software Foo can be seized and destroyed. How exactly are you better off trusting Foo? Now maybe you could claim that merely using the waivers forces everyone to think long and hard about IP, avoiding potential issues, but that strikes me as more than a little dubious. People often don't even read what they sign, much less think about the implications. I am not a lawyer (yet), but I have studied US copyright law. My thinking is that if that kind of documentation were more widely available, the process of doing appropriate diligence on the part of the consuming organizations would be easier and more repeatable. Looking for boilerplate waivers sounds more like CYA than diligence to me. Asking the higher-ups at work to reach technology management decisions based on my gut feel is an uphill climb. And foolish. If you can't make a convincing case based on everything said in this thread, you may as well give up because your higher-ups aren't listening. The overall goal is to remove a barrier to more widespread use of Open Source - growing the mindshare dedicated to it and potentially shrinking the mindshare dedicated to commercially-produced software. Ben already mentioned the false dichotomy here. Let me just say I think both your goal and his (spreading free software at the expense of non-free) are counterproductive. Organizations (and people) should look for the software that best fits their needs. Sometimes that means highest technical quality. Sometimes it means open standards or open source. Sometimes it means features X, Y, and Z. Sometimes it means vendor support. Often it's a combination. A successful project should focus on discovering and meeting its users' needs. Spreading open source for its own sake helps no one. but if the Open Source movement can cause Bill Gates to show his code to the Chinese government, who knows what else it can do? Really, open source did that? Here I thought it was the the Chinese govt strongarming Microsoft over the promise of 1.3 billion potential consumers. I think the Open Source movement is leading, not following, commercial code producers. If there is a better way to do business, I would like to see Open Source get there first. We must move forward, not backward, upward, not forward, and always twirling, twirling, twirling towards freedom! Seriously, I think you're kidding yourself. Community-based, volunteer-driven open source projects handle some things very well. Closed, commercial projects excel at others. In between there's a lot of overlap with mixed attributes of each (not to imply these are merely two ends along a single spectrum, there are more dimensions involved). I think the market success of communal software shows that some software is becoming commoditized. Because software is a nonrivalous good (making copies is essentially free), it's usually more economically efficient for users to pool development costs and only pay for support than to pay for profits on each copy produced. Where it makes sense, the market is moving towards software as a public good rather than software as a product. Instead of digging out a huge canyon and charging for access to it (Microsoft/Oracle model), it's hiring out a river guide just to those who want one (Linux/MySQL model). Each has its place and neither is going away. Also note the public good approach doesn't require open source -- it works just as well with freely available binaries, a la Sun's Java VM. -- http://mail.python.org/mailman/listinfo/python-list
Re: Counterproductive goals (was Re: code vetting)
Apologies to the group for getting so OT here. Thanks for your indulgence. Ben Finney wrote: I think both your goal and his (spreading free software at the expense of non-free) are counterproductive. Huh? A goal is counterproductive? By what do you measure counterproductive, if not the goal? I'm measuring against the implicit goal of producing useful software from a functional perspective. I assumed all projects followed that goal, but I suppose Hurd is a counterexample to that. Regardless, I should have said can be counterproductive. Both goals can coexist. But I would argue that focusing on the functional goal does more in the end to gain and help users than many of the more direct attempts to spread free software. In that sense, the tactics undertaken to explicitly further a goal can actually hurt achievement of the goal itself. Often it's a combination. A successful project should focus on discovering and meeting its users' needs. Again, success is measured by the goal. My goal is to increase the freedom of software users. That's fine. But if we're talking about the software world at large, or even the open source world at large, many do not share that goal. The closest we can get to a universal goal, and hence the most representative way to measure success, is with a functional approach. You are free to measure things differently, but it's not a conversation a lot people would care about. Spreading open source for its own sake helps no one. Increasing the freedom of software users helps all software users, except those who want that freedom restricted. I repeat: spreading open source for its own sake helps no one. Open source != freedom. You can access Sun's Java source and even Microsoft's Windows source under certain conditions. Access to the source gives you nothing. To borrow from Agent Smith: What good is a phone call if you're unable to speak? Now maybe you're thinking of open source as an OSI-approved license. That's a different statement which jives more with your contention that increasing freedom helps all software users. I'd say it depends how you define freedom and helps. Regardless, I'll relax my statement that it helps no one and agree that some people benefit in some situations. Maybe it's a lot, maybe it's a little; I don't want to quibble over quantifying it. I'm not disagreeing with your basic philosophy. Free software brings a number of benefits. Both the BSD and the GNU camps have laudable goals and do some fantastic work. Where I part company is in thinking those approaches are inherently superior or should/will become widespread. To each his own. In the current discussion about universal benefits of transparency, the fact that different groups have different goals is highly relevant. -- http://mail.python.org/mailman/listinfo/python-list
Re: stripping unwanted chars from string
John Machin wrote: [expletives deleted] and it was wrong anyway (according to your requirements); using \w would keep '_' which is *NOT* alphanumeric. Actually the perl is correct, the explanation was the faulty part. When in doubt, trust the code. Plus I explicitly allowed _ further down, so the mistake should have been fairly obvious. alphabet = 'qwertyuiopasdfghjklzxcvbnm' # Look, Ma, no thought required!! Monkey see, monkey type. I won't dignify that with a response. The code that is, I could give a toss about the comments. If you enjoy using such verbose, error-prone representations in your code, god help anyone maintaining it. Including you six months later. Quick, find the difference between these sets at a glance: 'qwertyuiopasdfghjklzxcvbnm' 'abcdefghijklmnopqrstuvwxyz' 'abcdefghijklmnopprstuvwxyz' 'abcdefghijk1mnopqrstuvwxyz' 'qwertyuopasdfghjklzxcvbnm' # no fair peeking And I won't even bring up locales. keepchars = set(alphabet + alphabet.upper() + '1234567890-.') fixer = lambda x: ''.join(c for c in x if c in keepchars) Those darn monkeys, always think they're so clever! ;) if you can == you should: do(it) else: do(not) Sadly I can find no such beast. Anyone have any insight? As of now, regexes look like the best solution. I'll leave it to somebody else to dredge up the standard riposte to your last sentence :-) If the monstrosity above is the best you've got, regexes are clearly the better solution. Readable trumps inscrutable any day. One point on your requirements: replacing unwanted characters instead of deleting them may be better -- theoretically possible problems with deleting are: (1) duplicates (foo and foo_ become the same) (2) '_' becomes '' which is not a valid filename. Which is why I perform checks for emptiness and uniqueness after the strip. I decided long ago that stripping is preferable to replacement here. And a legibility problem: if you hate '_' and ' ' so much, why not change them to '-'? _ is allowed. And I do prefer -, but not for legibility. It doesn't require me to hit Shift. Oh and just in case the fix was accidentally applied to a path: keepchars.update(os.sep) if os.altsep: keepchars.update(os.altsep) Nope, like I said this is strictly a filename. Stripping out path components is the first thing I do. But thanks for pointing out these common pitfalls for members of our studio audience. Tell him what he's won, Johnny! ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: stripping unwanted chars from string
Bryan wrote: keepchars = set(string.letters + string.digits + '-.') Now that looks a lot better. Just don't forget the underscore. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Possible constant assignment operators := and ::= for Python
Michele Simionato wrote:
A = [] # let's declare a constant here
b = A # and let's assign the constant here
b.append('1') # OOPS!
But it makes no sense to use a mutable object for a constant!
The user should use a tuple,
Sure. Now show me the builtin immutable equivalent of a dict.
or a custom list-like type where
all methods with side effects are removed, so it effectively acts
as a tuple.
Ugh, not worth the trouble imo.
--
http://mail.python.org/mailman/listinfo/python-list
Re: noob question: TypeError wrong number of args
bruno at modulix wrote: Edward Elliott wrote: Ah, well then, there's no need for a full-blown parser. It should suffice to recognize a class definition and modify the parameter list of every def indented one level further than that. won't do : class CounterExample(object): if compute_some_const_according_to_phase_of_moon(): def meth(...): do_something(self, 42) Uuunn, you got me pardner. (cough, cough) my hands, they're so cold. bruno? where'd you go, bruno? i can't see you anymore. are we back on the farm? tell ma i love her. (clunk) -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question on code vetting
[EMAIL PROTECTED] wrote: I agree with your point, which is why I asked the question. Risk cannot be eliminated, but it can be understood and managed so that useful work can still be done. If there is any way I can find out what the commiters do prior to reaching a decision to accept or reject a particular submission, I would like to know about it. If committers make no checks on submitted code, that doesn't have to be an automatic showstopper, even for a risk-averse company. How many of the alternatives perform more stringent checks on their code? How much misappropriated code is floating around in closed commercial products, where the privacy of the source may encourage more liberal borrowing? Anyone can say they check their IP, but how many organizations put their money where their mouth is and provide indemnity? How visible will your company and your Python projects be? You can always try to make the case that even without ip checks python makes your company 1) no more vulnerable than the other software they already rely on, and 2) unlikely to be targetted for their use anyway. And if you can show the financial gains from using it are highger than the potential liability, you're golden. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question on code vetting
I have no deep connections to any open source projects. I do however know quite a few engineers. Bear that in mind. [EMAIL PROTECTED] wrote: It seems to me that Open Source generally would be more pervasive if there was more transparency with respect to the practices observed within the projects. What possible harm could there be in letting the world know how decisions to incorporate code are reached? I don't think it's a question of transparency but effort. Documenting the processes takes time which many probably feel is better spent on functional aspects of the project. And for what benefit? Are open source projects more concerned about approval or quality? Besdies, most commercial products have zero transparency in their development processes and it doesn't hinder their market acceptance. The goal of collaborative development is to build a body of code with many minds that is better than the body of code that could be built by any subset of them. The same principle could be applied to identification of best practices for committers across projects. If those practices are identifiable and repeatable, then sure, maybe projects could be more productive following a best practices approach. OTOH if successful projects function more as little fiefdoms run by benevolent dictators, the reasons for success may be too idiosyncratic and happenstance to translate to other projects. Note I said more productive, as in allow the code to improve quicker. My impression is most engineers don't want to invest time on IP rules and hate when legal shenanigans impinge on their development. They're generally good at providing attribution and avoiding intentional misuses, but won't go out of their way to check sources. Nor should they, as 1) that's not their job and 2) it's a very difficult task (unless you know of some master database containing all the world's code). Hence IP verification best practices are likely to be summarily ignored as a foolish waste of time. Closed commercial projects fare no better, indeed they may be even worse since the risk of getting caught is lower. Google for the number of times unlicensed GPLed code turned up in some commercial product. To me, being unable to reach an understanding of the practices is analogous to being unable to see and run the JUnit suites on a bunch of classes - being in the position of assuming that there is coverage, but not being able to understand how much or how thorough. Transparency can be valuable to an outsider, but I don't see how most projects would have the time, resources, or inclination to provide it. I think it is obvious that if every consumer of the code who has an interest in controlling risk has to reinvent the wheel, there will be a lot of effort wasted on redundant work. Sure, but this task is better handled by vendors like Red Hat than by individual projects. IP verification is no easy matter to handle, and vendors have a financial incentive to perform the checks. Vendors can also offer indemnity, which individual projects can't. Why not have the project publish a document that says here are the practices by which we manage our code base - take it or leave it. Just as most licenses are variations on a few (GPL, LGPL, CPL, etc.), it seems to me that very quickly, a set of common management practices would evolve if most projects published, perhaps with a few variations. I suspect part of the reason you have trouble finding answers about IP issues is that there are none to give. I doubt most projects follow anything resembling a formal process for verifying sources. It's more likely left up to individual contributors, and probably runs along the lines of if it doesn't look obviously ripped-off, then it's ok. With regard to the issue of trust, how can I either trust or decide not to trust in an information vacuum? By looking at indirect sources of evidence. How much trust do others put in this project? (Google for one uses python heavily.) How do most open source projects function? How do most engineers handle IP issues? Can I hire an auditor to sample a representative portion of the code base for IP issues? Has anyone else already done so? How often are open source projects accused of IP violations? How serious are they and what are the outcomes? Do closed projects handle things any differently? What assurances do they really provide? Risk analysis means there's risk. Unknowns are inherent. Work around them the best you can. I may be splitting hairs, but my understanding is that belief despite absence of evidence is faith, not trust. Trust is the result of observation, and I want to be able to observe. Faith is a belief that something is true without evidence. Trust is relying on something/someone to perform a certain way. Blindly believing a project to be free of IP issues is faith. Expecting the committers to take the same reasonable precautions most
Re: Newbie question on code vetting
Dennis Lee Bieber wrote: I work for a risk-averse company, and I want to compile a solid case for obtaining and using Python at work. Given the nature of the US Patent Office... You might as well lock the doors now... The Patent Office could issue a patent next week that makes all bytecode interpreted languages subject to some royalty... Risk isn't just what could happen, it's how likely it is and what effects it would have. A patent affecting millions of installed interpreters is pretty unlikely and would have many challengers. Even if it were upheld, how many larger companies with deeper pockets would they go after before his? And everyone stuck in the same boat would quickly work towards a non-infringing solution. Cases like MS-EOLAS and RIM-NTP aren't exactly a daily occurence. They also demonstrate why there really is safety in numbers. Plus all the potential negatives have to weighed against the increased productivity his company gains from using a scripting language. The gains may more than offset any potential patent settlement. Risk-averse doesn't mean head-in-the-sand. -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: TypeError wrong number of args
Bruno Desthuilliers wrote: IOW, let's give Edward some time to come up with enough rope so we can hang him to the nearest (AS) Tree !-) That's all I ask. ;) -- http://mail.python.org/mailman/listinfo/python-list
