Re: Homework help
On Apr 1, 11:29 am, [EMAIL PROTECTED] wrote: On Apr 1, 12:17 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: I don't necessarily want the answers, but need help on how to approach it/the steps i need to solve the problems What parts are you having difficulty with? Are there some course materials and have you read them yet? I just don't know how to start the problems off Well, for the first problem, the first line is def howMany(item,lst): If you can't figure out where to go from there, start here: http://docs.python.org/tut/tut.html Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Order in which modules are imported
On Feb 22, 5:21 pm, [EMAIL PROTECTED] wrote: I imported two modules (random and matplotlib), and found that the functions available to me from the random module depended on the order in which the imports occured. In particular, if I import random first, [...] import random from pylab import * Change this --^ lint to import pylab and see what happens. Of course, that may force other changes in your script... And remember that from module import * is never your friend. Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Finding overlapping times...
On Dec 13, 5:45 pm, Breal [EMAIL PROTECTED] wrote:
I have a list that looks like the following
[(10, 100010), (15, 17), (19, 100015)]
I would like to be able to determine which of these overlap each
other. So, in this case, tuple 1 overlaps with tuples 2 and 3. Tuple
2 overlaps with 1. Tuple 3 overlaps with tuple 1.
In my scenario I would have hundreds, if not thousands of these
ranges. Any nice pythonic way to do this?
What are you going to do with the result? Do you need to know if
there are any overlaps? The number of overlaps? Given any particular
range, what ranges overlap?
There's really no way, other than to compare each range. Note that
the relationship is symmetric, so you can save half you work. A
simple-minded approach might be
---
def overlaps(t1, t2):
return (t2[1] = t1[0]) and (t2[0] = t1[1])
in_data = [(10, 100010), (15, 17), (19, 100015)]
while (len(in_data) 1):
target = in_data.pop(0)
for test in in_data:
if overlaps(target,test):
print %s overlaps with %s % (repr(target),repr(test))
---
If you want to save the information for later retrieval, you could
build a dictionary with the ranges as keys:
---
ovr_map = {}
while len(in_data) 1:
target = in_data.pop(0)
for test in in_data:
if overlaps(target,test):
if ovr_map.has_key(target): ovr_map[target].append(test)
else: ovr_map[target] = [test]
if ovr_map.has_key(test): ovr_map[test].append(target)
else: ovr_map[test] = [target]
for target in ovr_map.keys():
for test in ovr_map[target]:
print %s overlaps with %s % (repr(target),repr(test))
---
I don't know that there isn't a more Pythonic way, I'm not much of an
expert. HTH,
-=Dave
--
http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
On Sep 12, 5:21 am, Charles Fox [EMAIL PROTECTED] wrote: I've just started playing around with Python, as a possible replacement for a mix of C++, Matlab and Lisp. The language looks lovely and clean with one huge exception: I do a lot of numerical modeling, so I deal with objects (like neurons) described mathematically in papers, by equations like a_dot = -k(a-u) In other languages, this translates nicely into code, but as far as I can tell, Python needs the ugly: self.a_dot = -self.k(self.a-self.u) For large equations this is going to make my code seriously unreadable to the point of needing to switch back to Matlab -- and it seems to go against everything else about python's simplicity and elegance. Am I It goes back to the Zen of Python (import this): Explicit is better than implicit. And it's a boon to future maintainers of your code missing something? Is there something like a 'with' command that lets me set the scope, like with self: .a_dot = -.k(.a-.u) The name self is just a convention. You can give it any name you wish. Using s is common. As others have mentioned, you can also provide local synonyms if the dot syntax is too onerous. But make sure you use the member access syntax if the result of an expression is an immutable type. For example, I assume a_dot is a mutable type, such as a list. If so, then you could simply use a_dot, k, a, u = self.a_dot, self.k, self.a, self.u a_dot = -k(a-u) However, if it's an immutable type, such as a scalar, strung, or tuple, you need self.a_dot = -k(a-u) And it gets trickier if you have members taking intermediate values... It's premature to make language suggestions as I am new to the That's for sure ;-) Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Car-ac-systems
On Sep 11, 12:42 pm, Zentrader [EMAIL PROTECTED] wrote: snip What is it about please do not top-post that you have difficulty understanding? Or do MVPs feel that their time is so much more valuable than anyone else's that they are free to ignore the norms? Who made this the norm? http://www.ietf.org/rfc/rfc1855.txt If you don't know what the IETF is, or what an RFC is, you should educate yourself. http://www.ietf.org/glossary.html#IETF is a good place to start. In my travels through web-land, it appears to Usenet is not web-land. And it is not Google Groups, either. Look up http://www.faqs.org/faqs/usenet/welcome/part1/ for more info be the opposite. Don't waste space repeating everything in every post, and it wastes everyone's time by have to go over the same thing again and again. Perhaps this thread has a purpose after all, anyway it has been reported as spam. You have much to learn. Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbee Question
On Aug 21, 2:57 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote: [...] pay = min(num, 22) * 0.4 + max(num-22, 0) * 1.4 pay = num*0.4 + (num22)*(num-22) ;-) -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: regexp problem in Python
On Aug 3, 4:41 pm, Ehsan [EMAIL PROTECTED] wrote: I want to find http://www.2shared.com/download/1716611/e2000f22/ [...] I use this pattern : http.*?\.(wmv|3gp).* but it returns only 'wmv' and '3gp' instead of http://www.2shared.com/ download/1716611/e2000f22/Jadeed_Mlak14.wmv? tsid=20070803-164051-9d637d11 what can I do? what's wrong whit this pattern? thanx for your comments Just a guess, based on too little information: Try (http.*?\.(wmv| 3gp).*) Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 21, 9:49 am, Robert Uhl [EMAIL PROTECTED] wrote: Twisted [EMAIL PROTECTED] writes: Given that in its out-of-the-box configuration it's well-nigh unusable without a printed-out cheat sheet of some kind, of the sort that were supposed to have died out in the 80s, getting it customized poses something of a catch-22 for anyone trying to get started using it. I don't see that. C-h t is your friend if you're starting out. The only keystrokes a user really needs to remember are C-x C-s and C-x C-c; everything else simple text editing needs works as expected (arrow keys, backspace and so forth). Granted, text-mode is friendlier than I'm not so sure C-h t is anybody's friend anymore. Every version of Emacs that I've used since 1984 has supported the arrow and page up/ down keys. And every version of the tutorial that I've read (the latest just a couple years back) insists on starting the user out with C-f, C-b, C-p, C-n, C-V, and ESC-V, with some lame explanation like touch-typists shun the arrow and page keys, and besides, they might not be supported on the next terminal you use. Like ESC, I suppose. Furrfu. Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
On Jun 20, 8:28 am, David Kastrup [EMAIL PROTECTED] wrote: Actually, the E in Emacs stands for extensible. Part of the appeal of Emacs is that you can change it to accommodate you. Actually, though Emacs is the epitome of extensibility, the E stands for Editor. EMACS is simply short for Editor MACroS, and was originally implemented as a set of TECO macros. There's also the joke that EMACS stands for Esc Meta Alt Ctrl Shift, due to it's (often overwhelmingly) large and sometimes complex set of keystroke combinations used to invoke various editing functions. This view is usually put forth by the vi camp during editor wars. Speaking of which, vi is a piece of wombat do. ;-) Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Is PEP-8 a Code or More of a Guideline?
Apologies for jumping into the thread late.
On May 27, 3:25 pm, Roy Smith [EMAIL PROTECTED] wrote:
Ben Finney [EMAIL PROTECTED] wrote:
Is C no longer a major language? The long-standing convention there
is for lower_case_with_underscores.
Which dates back to the days of ASR-33's which only had one case (upper
The date is about right (actually, a little early: ASR-33, 1965; C,
about 1970), but you can't program C on an ASR-33. Keywords are all
lower case, and always have been. IF is a syntax error...
case, as a matter of fact). Does nobody else remember C compilers which
accepted \( and \) for { and }?
I don't, but modern conforming compilers are supposed to accept ?? or
% for { and ?? or % for }. Makes it awful hard to read, though,
IMHO.
Regards,
-=Dave
P.S. CamelCase sucks. ;-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Suggestions for how to approach this problem?
On May 8, 3:00 pm, John Salerno [EMAIL PROTECTED] wrote: Marc 'BlackJack' Rintsch wrote: I think I have vague idea how the input looks like, but it would be helpful if you show some example input and wanted output. Good idea. Here's what it looks like now: 1. Levy, S.B. (1964) Isologous interference with ultraviolet and X-ray irradiated bacteriophage T2. J. Bacteriol. 87:1330-1338. 2. Levy, S.B. and T. Watanabe (1966) Mepacrine and transfer of R factor. Lancet 2:1138. 3. Takano, I., S. Sato, S.B. Levy and T. Watanabe (1966) Episomic resistance factors in Enterobacteriaceae. 34. The specific effects of the inhibitors of DNA synthesis on the transfer of R factor and F factor. Med. Biol. (Tokyo) 73:79-83. Questions: 1) Do the citation numbers always begin in column 1? 2) Are the citation numbers always followed by a period and then at least one whitespace character? If so, I'd probably use a regular expression like ^[0-9]+\.[ \t] to find the beginning of each cite. then I would output each cite through a state machine that would reduce consecutive whitespace characters (space, tab, newline) into a single character, separating each cite with a newline. Final formatting can be done with paragraph styles in Word. HTH, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python
On Mar 16, 8:39 am, Paul McGuire [EMAIL PROTECTED] wrote: [...] Stop thinking about *how* to start and *just start*. Python is pretty Indeed. Of all the fortune cookies I've eaten over the years, I've saved (and taped to my monitor) only one fortune. It reads: Begin...the rest is easy. Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Isn't there a better way?
On 21 Jul 2006 07:51:15 -0700 in comp.lang.python, T [EMAIL PROTECTED] wrote: I am using an optparse to get command line options, and then pass them to an instance of another class: # Class that uses optparse.OptionParser foo = Parse_Option() # Class that does the real work bar = Processor() bar.index = foo.options.index bar.output = foo.options.output bar.run() How about class Processor(whatever): ... def __init__(self,whatever_else): ... self.op = Parse_Option() ... bar = Processor() bar.run() This would even let you do some preliminary option processing during object initialization. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Coding style
On Mon, 17 Jul 2006 17:09:32 +0100 in comp.lang.python, Simon Brunning [EMAIL PROTECTED] wrote: [...] lst = [1,2,3,4,5] while lst: lst.pop() Or even just: lst = [] del lst[:] is probably closer to what the OP wants... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: stderr, stdout, and errno 24
On 12 Jul 2006 18:09:42 -0700 in comp.lang.python, Wesley Henwood [EMAIL PROTECTED] wrote: To capture output from python scripts run from a C++ app I've added the following code at the beggening of the C++ app: PyRun_SimpleString(import grabber); PyRun_SimpleString(import sys); PyRun_SimpleString(class a:\n\tdef write(self,s):\n\t\tograbber.grab(s)\n); PyRun_SimpleString(import sys\nsys.stderr=a()\nsys.stdout=a()); Its hard to read that way, here's what it expands to: import grabber import sys class a: def write(self, s) grabber.grab(s) Actually, that last line will more like ograbber.grab(s) At least, if what you posted above is accurate... It's not the question you asked, but if you want to make that easier to read, you can do something like PyRun_SimpleString(import grabber); PyRun_SimpleString(import sys); PyRun_SimpleString(class a:\n def write(self,s):\n grabber.grab(s)\n); PyRun_SimpleString(import sys\n sys.stderr=a()\n sys.stdout=a()\n); C++, like Python, will concatenate strings seperated only by whitespace. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Restricted Access
On 11 Jul 2006 10:19:22 -0700 in comp.lang.python, Paul Rubin http://[EMAIL PROTECTED] wrote: K.S.Sreeram [EMAIL PROTECTED] writes: Java is not the only restricted execution environment around. Javascript, as implemented by most browsers, is an excellent lightweight restricted execution environment, and there are many browsers which have good implementations. And we hear about browser security bugs all the time, for which the workaround is shut off javascript. And Java... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: a good programming text editor (not IDE)
On Thu, 15 Jun 2006 17:12:26 GMT in comp.lang.python, John Salerno [EMAIL PROTECTED] wrote: I know there's a request for a good IDE at least once a week on the ng, but hopefully this question is a little different. I'm looking for suggestions for a good cross-platform text editor (which the features for coding, such as syntax highlighting, etc.) but not a full IDE with all the fancy jazz (GUI developer, UML diagrams, etc.). Ideally, it would be something I could even put on a flash drive and move from computer to computer, but this isn't necessary. Just something I can immediately use in either Windows or Linux (or Mac, if necessary). Very small, very fast, very powerful, and very portable (though I'm not sure about Mac...): Take a look at Jed from www.jedsoft.org. You might not find it pretty, however... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)
On 19 May 2006 07:18:03 GMT in comp.lang.python, Duncan Booth [EMAIL PROTECTED] wrote: [...] My experience of programming with either spaces or tabs has taught me that tabs are evil not for themselves, but simply because no matter how hard you try they always end up being mixed with spaces. That's been my experience as well. At least on projects with more than one programmer. And more than once with single-programmer projects where the programmer changed or updated his editor in the middle... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Sorting of list containing tuples
On Thu, 18 May 2006 21:29:59 +0200 in comp.lang.python, Ronny Mandal [EMAIL PROTECTED] wrote: Hi! Assume we have a list l, containing tuples t1,t2... i.e. l = [(2,3),(3,2),(6,5)] And now I want to sort l reverse by the second element in the tuple, i.e the result should ideally be: l = [(6,5),(2,3),(3,2)] Any ideas of how to accomplish this? Thanks, Ronny Mandal def my_cmp(t1,t2): c1 = t1[1] c2 = t2[1] if c1 c2: return 1 if c2 c1: return -1 return 0 l [(2, 3), (3, 2), (6, 5)] l.sort(cmp=my_cmp, reverse = True) l [(6, 5), (2, 3), (3, 2)] HTH, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott [EMAIL PROTECTED] wrote: 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' 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... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
On Wed, 17 May 2006 12:02:46 -0700 in comp.lang.python, Carl J. Van
Arsdall [EMAIL PROTECTED] wrote:
Andy Sy wrote:
Carl J. Van Arsdall wrote:
Next major objection then, how can one practically use 'tabs as
semantic indentation' without screwing up formatting of code like
the below??
def sqlcall():
cursor.execute('select id, item, amount, field4, field5, field6'+
'from table1 where amount100')
Why couldn't you tab your third line over as close as possible to the
start of the quote then use a couple spaces? Then the tabs would work
just fine and you could still have your pretty line.
This will break if someone tries to view my code using different
tab settings from the one I'm using
Uh, no it won't. It should be read in as one tab and two spaces
regardless of the tabstop setting.
Think about it a little harder. What does that one tab mean?
Assume the code was written by someone using 4-space tabs. To them,
the code is:
def sqlcall():
---cursor.execute('select id, item, amount, field4, etc
...'from table1 where amount100')
(where --- represents an 4-space tab and . represents a space)
Which looks fine. But if I then load the code into my editor with
3-space tabs, it looks like:
def sqlcall():
--cursor.execute('select id, item, amount, field4, etc
...'from table1 where amount100')
Then my colleage loads it into his editor with 8-space tabs, and it
looks like (assuming I didn't change it to make it look reasonable):
def sqlcall():
---cursor.execute('select id, item, amount, field4, etc
...'from table1 where amount100')
In each case the second line has four TABs and three spaces. But only
with the original TAB settings does it line up properly.
The only solution (as posted elsewhere) is to somehow enforce tabs for
indentation and spaces for spacing:
def sqlcall():
---cursor.execute('select id, item, amount, field4, etc
---...'from table1 where amount100')
However, to twist an observation I've read about C++, while it's
clearly possible to use TABs in a sensible manner like this, it seems
that no one does. Or at least, it doesn't last much beyond the
original author of the code...
Regards,
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
On 17 May 2006 16:13:54 -0700 in comp.lang.python, achates [EMAIL PROTECTED] wrote: Carl J. Van Arsdall wrote: The converse can also be said, it's difficult to make sure everyone uses spaces and not tabs. I think we've just about beat this discussion to death... nice work everyone! Yeah - we've got to the repeating ourselves stage. But that's the problem with this issue: it's really hard to get the space-indenters to actually think about it and to address what is being said. Every time it comes up, there's always a few people trying to Look in the mirror. There is non so blind... explain why tabs give are a good idea, facing a whole raft of others The problem is that TABs are a _bad_ idea. spouting stuff like: 'mixing spaces and tabs is bad so use spaces only' Mixing TABs and spaces is bad because it means using TABs. ;-) 'tabs are x spaces and I like to use y spaces' I've not seen that argument. One of us needs to read closer. Although I have seen the converse used to defend TABs: x spaces is x spaces, and I like y spaces, 'tabs are bad end of story' Works for me! ;-) and these non-arguments are repeated over and over within the same thread. At times it's like talking to a child - and not a bright one at that. These non-arguments are your own straw men. Either that, or you need to work on reading comprehension. 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. It matters because not every programmer is willing to put in the time effort required to learn how to use a sophisticated editor like emacs or vim well. Or at all. It matters because in industry you get programmers with a wide range of skills, and you can't fire everyone who can't tell when there are spaces in front of a tab character. Often these people have unique and hard-to-find domain knowledge. But unfortunately the situation is worse than that: tab indentation needs to be actively defended. Most of the coding 'style guides' you'll No, it needs to be stamped out. ;-) find (including Python's) advocate spaces only. There are plenty of Hallelujah! people who would like tabs removed from the language as an acceptable indentation method - look at the responses to Guido's April Fools blog entry last year. I would love to see the TAB character treated as a syntax error. I have no illusions that's going to happen, though. FWIW, I would be equally (well, almost, anyway) happy if Python said that the _only_ place a TAB character could appear was at the beginning of a line, and that the number of TAB characters _always_ indicated the indentation level (e.g., spaces do _not_ change indentation level, and all the lines in a multi-line statement had to be at the same indentation level). This would eliminate most of my objections to TABs. I have no illusions this will happen either. Unlikely perhaps. I hope so. 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. The problem with TAB characters is that they look just like the equivalent number of space characters. This is, of course, their major feature as well. The problem, especially with Python, is that mistakes in the placement of TAB characters within a source file can silently change the _meaning_ of the code. TAB proponents seem to list one overriding advantage of using TAB characters for indentation: I can use my preferred indent level, and everyone else can use theirs. I find this argument _very_ weak. I've seen misuse of TABs break code. I've never seen an enforced indentation level break a programmer. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's regular expression?
On Wed, 10 May 2006 06:44:27 GMT in comp.lang.python, Edward Elliott [EMAIL PROTECTED] wrote: 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. I'm reminded of a comment made a few years ago by John Levine, moderator of comp.compilers. He said something like It's clearly possible to write good code in C++. It's just that no one does. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline strings and proper indentation/alignment
On Wed, 10 May 2006 13:56:52 GMT in comp.lang.python, John Salerno
[EMAIL PROTECTED] wrote:
bruno at modulix wrote:
Why not trying by yourself ?-)
Doh! I always forget I can do this! :)
Mmm. Not good. Let's try again:
print textwrap.dedent(s).strip()
this is a multiline
triple-quted string with
indentation for nicer code formatting
Well, seems like we're done. About 2'30'' to solve the problem.
Actually, I'm still wondering if it's possible to remove the newlines at
the end of the first and second lines (after 'multiline' and 'with'), so
Well, it's too long for my news reader to display the result on a
single line, but:
print textwrap.dedent(s).strip().replace('\n',' ')
this is a multiline triple-quted string with indentation for nicer
code formatting
that the string is one line. But it's already been shown that textwrap
alone doesn't do this, so I'd rather not mess with all the extra stuff
to do it, when I can just put the string in parentheses.
If that's the way you want the sting in the first place, that'd be my
recommendation. Regards,
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: multiline strings and proper indentation/alignment
On Wed, 10 May 2006 15:50:38 GMT in comp.lang.python, John Salerno
[EMAIL PROTECTED] wrote:
Dave Hansen wrote:
print textwrap.dedent(s).strip().replace('\n',' ')
this is a multiline triple-quted string with indentation for nicer
code formatting
But I have some newlines that are already embedded in the string, and I
wouldn't want those replaced.
s =
I want the following line-
concatenated, but leave this
line break alone.
print textwrap.dedent(s).strip().replace('-\n',' ')
I want the following line concatenated, but leave this
line break alone.
But I'd still recommend using parens and string concatentation.
s2 = (
I want the following line
concatentated, but leave this\n
line break alone.
)
print s2
I want the following line concatentated, but leave this
line break alone.
Regards,
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tuple assignment and generators?
On 5 May 2006 05:23:24 -0700 in comp.lang.python, vdrab [EMAIL PROTECTED] wrote: Are you telling us that you *had* read that doc, and tripped because it says depending on the implementation, when it should say at the choice of the implementation ? no. let's see, where to start ... ? let's say there's a certain property P, for the sake of this lng discussion, something more or less like a class or type's property of having immutable values, such that any instance with value X has a single, unique representation in memory and any two instantiations of objects with that value X are in fact references to the same object. IOW, property P is (x == y) = (x is y) (read = as implies). Note that only immutable objects can have property P. Then, for example, python strings have property P whereas python lists do not: x = test y = test x is y True x = [] y = [] x is y False Note this last relationship is _guaranteed_. Lists are not immutable, and therefore can not have property P. Now, as it turns out, whether or not python integers have property P _depends_on_their_value_. From the zen, I believe this falls out from practicality beats purity. For small values, they do. For large values they don't. Yes, I Even that's not necessarily true. The implementation is free to always create a new immutable object, even for small values. understand about the interpreter optimization. I didn't know this, and I find it neither evident nor consistent. I don't think the above post explains this, regardless of how you read implementation. Think about implementation for a moment. Consider the statement x = some_arbitrary_integer() Do you really want the interpreter to go through all the existing integer objects in the program to see if that particular value exists, just to guarantee some some later statement x is y returns True if x == y? OK, maybe we can change the is operator on immutable objects such that x is y returns True if x == y. But then you can encounter a situation where x is y but id(x) != id(y) Now what? Perhaps the solution would be to disable the is operator and id function for immutable objects. But then _they_ lose generality. There doesn't seem to be a way to win. So it all comes down to who cares? Immutable objects are immutable. You can't change them. Object identity is a non-issue. This is not the case for mutable objects. Consider a = [1,2,3] b = [1,2,3] c = a a==b a==c b==c a is not b b is not c c is a c.append(4) In fact, the whole string of replies after my initial question reminded me of something I read not too long ago, but didn't quite understand at the time. source : http://www.oreillynet.com/ruby/blog/2006/01/a_little_antiantihype.html [...whinge elided...] taking this rant with the proverbial grain of salt, I did think it was funny. Your original post in its entirety (ignoring the example) was what the...? does anybody else get mighty uncomfortable about this? The first response (paraphrased) was No. Why should I? With immutable objects, I care about ==, not is. Your response seemed to want to cast doubt on the integrity of the entire language: Given this though, what other such beauties are lurking in the interpreter, under the name of 'implementation accidents'? Anyway, thanks for all the attempts to show me. I will get it in the end. I will ignore the double entendre, and simply hope I was of help, and wish you luck. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: simultaneous assignment
On Tue, 02 May 2006 18:52:48 GMT in comp.lang.python, John Salerno [EMAIL PROTECTED] wrote: [...] Yeah, after trying some crazy things, I just wrote it this way: def truth_test(seq): truth = 0 for item in seq: if item: truth += 1 if truth == 1: return True else: return False You could replace those last four lines with return truth == 1 Not sure I like having to keep a counter though, but the other stuff I Well, if you want something minimalist, you could try def truth_test(seq): return sum(1 for item in seq if item) == 1 Though I'm not sure it's really any clearer... did was really convoluted, like checking to see if the first item was True, and if it was, popping it from the list and iterating over the rest of the items (needless to say, the in-place change wasn't helpful). Perhaps something like def truth_test(seq): found = False for item in seq: if item: if found: return False found = True return found Gets you an early exit, anyway... All code untested. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: A defense for bracket-less code
On Wed, 26 Apr 2006 10:20:57 -0400 in comp.lang.python, Don Taylor
[EMAIL PROTECTED] wrote:
Found in a style guide (http://www.artlogic.com/careers/styleguide.html)
---
Another case where unnecessary braces should be used is when writing
an empty while loop:
while (*p++ = *q++)
{
// this loop intentionally left empty...
}
FWIW, I usually code this like
while (*p++ = *q++)
continue;
instead of the form that is more commonly found:
while (*p++ = *q++);
PC-lint picks this up (as well as the erroneous code in the elided
example), but will allow the continue form shown above.
[...]
loop exactly once. Python programmers can stop chuckling now.
---
On 26 Apr 2006 07:54:38 -0700 in comp.lang.python,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
wrong group
Not really. It was mostly a lead-in to that last sentence. Problems
like this couldn't happen in Python. So it's an opportunity to get a
giggle at the expense of programmers using a language that gives you
enough rope to shoot yourself in the foot...
Regards,
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: do while loop
On Wed, 26 Apr 2006 22:41:04 +0200 in comp.lang.python, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], ? wrote: suggest add do while loop in later version Please also suggest a clean syntax for this. :-) while 1: do_loop_stuff() if time_to_leave(): break Well, maybe not too clean, but it works today... For the future, maybe: do: #or repeat: do_loop_stuff() until time_to_leave() Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to append to a list twice?
On 21 Apr 2006 12:50:38 -0700 in comp.lang.python, [EMAIL PROTECTED] wrote: I don't get it (the Elliot solution)... How is it that the first value is repeated once times, and the remaining values are repeated twice times? Integer division truncates. 200/2 - 100, 199/2 - 99, 198/2 - 99, etc. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do you guys print out a binary tree?
On Tue, 18 Apr 2006 08:17:22 -0700 (PDT) in comp.lang.python, Anthony Liu [EMAIL PROTECTED] wrote: --- bayerj [EMAIL PROTECTED] wrote: Hi, 1 2 3 4 5 0 7 8 9 10 0 0 13 14 15 0 0 0 19 20 0 0 0 0 25 Look at the triangle represented by the non-zero integers. This triangle is a binary tree if we take 5 as the root and walk down on both sides. Are you sure? Is 9 a child of 4 or 10? A binary tree can have up to 2^n - 1 nodes. A matrix can have up to n^2 values, in your case of a half-empty matrix about (n-1)^2. Thanks. I am not concerned about the shape of binary tree. So, let's forget about binary tree. Given a triangle like that, it does not matter which is whose children. How do we nicely present it as tree in an ascii console? Something like the following might work. Quick 2-minute script. Probably needs tweaking to be generally useful import sys def print_tri(t): n = len(t) cell = 0 for line in t: tw = max(map(lambda x:len(str(x)), line)) if tw cell: cell = tw for p in range(n,0,-1): sys.stdout.write(%*s%(((cell+1)/2)*(2*p),)) x = 0 y = p-1 while yn: s = str(t[x][y]) b = (cell-len(s))/2 sys.stdout.write(%*s%*s%(b,s,cell-b,)) x += 1 y += 1 sys.stdout.write(\n) Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, Identity functions and execution...
On Wed, 12 Apr 2006 17:19:25 +1200 in comp.lang.python, Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Terry Reedy [EMAIL PROTECTED] wrote: Sybren Stuvel [EMAIL PROTECTED] wrote in I don't care about how people see my tabs. I use one tab for every indent level, so no matter how you set your tab width, my code will look consistent. Unless they view with tab_width = 0, as with some news readers. I have my newsreader set to use a proportional font, so the point is moot. Even in a proportional font, spaces all have the same width. Though not as wide as a fixed font... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: converting lists to strings to lists
On 12 Apr 2006 06:53:23 -0700 in comp.lang.python, robin [EMAIL PROTECTED] wrote: hi, i'm doing some udp stuff and receive strings of the form '0.87 0.25 0.79;\n' what i'd need though is a list of the form [0.87 0.25 0.79] i got to the [0:-3] part to obtain a string '0.87 0.25 0.79' but i can't find a way to convert this into a list. i tried eval() but this gives me the following error: Traceback (most recent call last): File stdin, line 1, in ? File string, line 1 .87 0.25 0.79000 and i have the same problem the other way round. e.g. i have a list which i need to convert to a string in order to send it via udp. btw: i cannot use pickle, since i'm sending stuff to a LISP programme. Here's a little playing around I did the the interactive interpreter. Not guaranteed to be the most efficient or Pythonic, but it seems to work... instr = '0.87 0.25 0.79;\n' instr '0.87 0.25 0.79;\n' ell = [float(x) for x in instr[:-2].split()] print ell [0.87, 0.25, 0.79004] outstr = .join([%8.6f%x for x in ell]) + ;\n outstr '0.87 0.25 0.79;\n' instr == outstr True Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Filters like old skool Jive, Fudd, Valspeak... Text transformation in Python
On 5 Apr 2006 13:44:48 -0700 in comp.lang.python, [EMAIL PROTECTED] wrote: bruno at modulix wrote: There's a Kant generator example in Dive Into Python: http://diveintopython.org/xml_processing/index.html Thanks Bruno! Perhaps I could modify it to throw in some Hume and Wittgenstein, mix it all up in a syntactic / semantic blender and REALLY confuse people. Word Games indeed. :-) Or throw in stuff by whichever philosopher who wrote a book called The Meaning of Meaning, to add some metaphoric recursion. And that what be one heck of a Frankenstenian (but only 1 part Wittgensteinian) Robo-philosopher. Don't forget the famous American philosopher who contemplated the meaning of is. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference between 'is' and '=='
On 3 Apr 2006 10:37:11 -0400 in comp.lang.python, [EMAIL PROTECTED] (Roy Smith) wrote: Adam DePrince [EMAIL PROTECTED] wrote: It just happens that the logical operation (a is b ) - (a == b ) is always True. Only for small values of always. You can always do pathological things with operators: class Foo: def __eq__ (self, other): return False f = Foo() print f is f print f == f frame:play$ ./is.py True False This may even be useful. What if you were trying to emulate SQL's NULL? NULL compares false to anything, even itself. To test for NULLness, you have to use the special is NULL operator. Another instance where this may be useful is IEEE-754 NaN. I don't have fpconst to verify if that's the case, but I would expect NaN is NaN to be true, but NaN == NaN to be false. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: [CODE] - Python Newcomer Starting with Coding
On Tue, 21 Mar 2006 20:05:48 +0200 in comp.lang.python, Ilias Lazaridis [EMAIL PROTECTED] wrote: bruno at modulix wrote: [...] Look for the Python cookbook (google is your friend). ... http://www.oreilly.com/catalog/pythoncook/ sorry, I've not clarified that I mean an free internet resource. Try the first hit from google rather than the third. http://aspn.activestate.com/ASPN/Python/Cookbook/ Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Function params with **? what do these mean?
On 20 Mar 2006 12:46:43 -0800 in comp.lang.python, J Rice [EMAIL PROTECTED] wrote: I'm sorry for such a basic question, but I haven't been able to phrase a search that gets me an answer and my books are totally silent on this. I have seen a number of python function defs that take parameters of the form (**param1). Looks like a pointer... but my books on python (basic as they are) don't make a mention. What is this? It's a way of accepting a varying number of named arguments. In the function, the parameter becomes a dictionary with parameter names as the keys corresponding to the passed parameter values. It's harder to explain than understand. Try playing with the following function in the python interpreter: def test(a,b='b', *c, **d): print a,b,c,d A couple suggestions for tests: test(1,2,3,4) test(a=1,b=2,c=3,d=4) test(2,4,6,8,10,12,ralph=23,tony=45) See what happens. Should be mostly self-explanatory. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Function params with **? what do these mean?
On 20 Mar 2006 15:45:36 -0800 in comp.lang.python, [EMAIL PROTECTED] (Aahz) wrote: In article [EMAIL PROTECTED], Dave Hansen [EMAIL PROTECTED] wrote: [...] It's harder to explain than understand. Try playing with the following function in the python interpreter: def test(a,b='b', *c, **d): print a,b,c,d Personally, I think it's a Good Idea to stick with the semi-standard names of *args and **kwargs to make searching easier... Agreed (though kwargs kinda makes my skin crawl). I don't use these features often in my code, but when I do, I follow the convention. The example was just for illustrative purposes, and the names chosen for easy typing. It is important to note that using args and kwargs is a convention rather than a requirement, analogous to self. You can use different identifiers, but future maintainers of your code will be annoyed. But it won't affect the operation of the code. I found the test case test(a=1,b=2,c=3,d=4) to be most edifying. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: A C-like if statement
On Thu, 23 Feb 2006 12:04:38 -0700 in comp.lang.python, Bob Greschke
[EMAIL PROTECTED] wrote:
Roy Smith [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[...]
try:
i = a.find(3)
print It's here: , i
except NotFound:
print No 3's here
Nuts. I guess you're right. It wouldn't be proper. Things are added or
proposed every day for Python that I can't even pronounce, but a simple 'if
(I = a.find(3)) != -1' isn't allowed. Huh. It might be time to go back
to BASIC. :)
I think you'll find that BASIC doesn't allow it either...
Of the missing features of Python, this one is waay down on my
list. In fact, it's not there at all. What I _really_ miss is
do{...}while. The best workaround I've found is unaesthetic, IMHO:
while 1:
# stuff
if exit_condition: break
Regards,
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How would you open this file?
On Thu, 23 Feb 2006 18:01:32 -0500 in comp.lang.python, Kent Johnson
[EMAIL PROTECTED] wrote:
[...]
filename = open_file()
By the way 'filename' is a pretty bad name, since it contains a file
object, not a string. Maybe call it f instead. ('file' is also a bad
name because it is the name of a Python built-in function.)
I write a lot of simple scripts. Those that have input and/or output
files tend to call them infile and outfile. Given the name of the
OP's file, perhaps optfile would work for him...
Regards,
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Mutable numbers
On Tue, 21 Feb 2006 12:44:52 +0530 in comp.lang.python, Suresh Jeevanandam [EMAIL PROTECTED] wrote: # I am new to python. In python all numbers are immutable. This means there is one object ( a region in the memory ) created every time we do an numeric operation. I hope there should have been some good reasons why it was designed this way. But why not have mutable numbers also in the language. A type which would behave as follows: a = MutableInt(12) a = [12] b = a Now both a and b should refer to the same memory location. Any change in the object should get reflected in all the references. a.assign(13) # Same memory location should be updated with value 13, b a[0] = 13 is also 13 now. Now we can further optimize: a.incrementOne() # equivalent to a++ in C++ a.decrementOne() a[0] += 1 a[0] -= 1 and the augmented assignment operation also could be made optimized. In any application most of the operation is numerical. So, i think, we should get a good speed advantage with the availability of mutable numbers. What do you think ? I don't see how. HTH, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
On Tue, 21 Feb 2006 08:36:50 -0600 in comp.lang.python, Chris Mellon [EMAIL PROTECTED] wrote: [...] When asked to name some interpreted (or scripting) languages, they'll name some off - perl, python, ruby, javascript, basic... They won't say Java. Ask them why Python is interpreted and Java isn't and you'll have a hard time getting a decent technical answer, because Python isn't all that different from Java in that regard, especially pre-JIT versions of Java. IMHO, it's marketing. Soon after (as soon as?) Sun introduced Java, they announced microprocessors that would implement the JVM natively. Thus on those machines, Java would not be interpreted. AIUI, the reason native Java chips never took off is 1) limited utility (who wants a chip that can only run Java programs?), and 2) performance on native chips wasn't even better than JVMs running on commodity microprocessors, so what's the point? Probably the most accurate definition of interpreted as it is used in the wild is one of these languages: perl, python, perl, ruby, etc. That is, you're essentially claiming that Python is interpreted because everyone thinks of it that way, technical correctness be damned. I think another reason perl, Python etc. are known to be interpreted and Java is not is the interactivity afforded by former group. This is also why, e.g., lisp and Forth are thought of as interpreted (at least by those with only a passing familiarity with the languages), though native compilers for both languages are readily available. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 deat !? Is true division ever coming ?
Caution: bunny trail ahead. Feel free to skip this message, as it contains no useful content whatever... On Sat, 18 Feb 2006 12:09:02 +1100 in comp.lang.python, Steven D'Aprano [EMAIL PROTECTED] wrote: [...] I've never even used Matlab. But I have a calculator. (Actually I have about half a dozen calculators.) In every single one of them, 1/2 gives 0.5 instead of 0. I'm even capable of doing that calculation in my head. So I don't think true division is only in Matlab. I have three calculators: an HP-48S, and HP-16C, and NeoCal on my Palm. On the HP-48S: 1 Enter 2 / - 500.0E-3 On the HP-16C: 1 Enter 2 / - 0 h (c) On NeoCal: 1 Enter 2 / - 500.e-3 Note: the (c) on the 16C indicates the carry bit was set, which the 16C does whenever the remainder of a division is nonzero. Caveats: The result for each calculator depends on its mode. In programmer mode, each calculator performs a truncating integer division. The 16C is in programmer mode by default. The 48S is almost never in programmer mode since I bought the 16C. NeoCal goes into programmer mode about 25% of the time I use it. It was in Statistics mode when I powered it up just now. As you pointed out: the true division part of Python3000 might be one of the scariest and should therefore be pointed out already in the tutorial !! (It would look quite ugly to newcomers, though) If you want ugly, consider Pascal. The / operator could not perform an integer divide, and a compile-time error was generated if you attempted to use it with integer operands. The integer divide operator was 'div', e.g. i = j div k The tutorial shouldn't talk about Python3000 at all. What would be the point of that? The tutorial is there to teach about the way Python works now, not to make guesses and prediction about how it will work some time in the indefinite future. Having said that: I would vote against EVER introducing true division as default - because it will just PISS too many (long time python) people OFF. ;-) Do you realise that the reason true division was introduced into Python was because many long-time Python programmers requested it? So far from annoying them, it is a feature that most Python programmers are waiting for. I am a relatively long-time user (since about 1999) of Python, but I mainly program in C. True division probably wouldn't p*ss me off too bad, and I certainly wouldn't have a problem with new scripts I wrote. But if it broke old scripts, I wouldn't be extremely happy. FWIW, ISTM that true division would be better implemented by the new // operator, leaving the behavior of / unchanged. But that's probably just me. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Merging two lists of data (Pythonic way)
On Thu, 16 Feb 2006 12:51:24 -0800 in comp.lang.python, SMB [EMAIL PROTECTED] wrote: Jonathan Gardner [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] codes = map(lambda x: x[0], list1) for d in list2: if d['code'] in codes: d['VERIFIED'] = 1 Is this what you were looking for? That is exactly what I was looking for. I will have to take a look at map. You might also look at list comprehensions. Replacing the first line in the above with codes = [x[0] for x in list1] should yield the same result. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: processing limitation in Python
On 14 Feb 2006 08:42:38 -0800 in comp.lang.python, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If I un-comment any line in this program below the line where I commented all OK up to this point This program locks up my computer. Hmm. Ctrl-C gets me out just fine. In Idle, at least. Windows task manager will show Not Responding for Python in the Applications tab and in the Performance tabe the CPU usage will be locked at %100. Well sure. It's pretty busy code. I've experienced the same problem on 2 different computers, one running 2000 pro. the other running XP home eddition. both computers run Python 2.4.2 I'm just wondering if any one else has noticed any problems with working with large numbers in Python ind if there is anything that can work around this issue. Try running with the changes I've made below, and see if that tells you anything. def factor(n): d = 2 pctr = 0 factors = [ ] while n 1: if n % d == 0: factors.append(d) n = n/d else: d = d + 1 pctr += 1 if pctr = 100: print So Far: + str(factors) pctr = 0 print factors factor (12) factor (123) factor (1234) factor (12345) factor (123456) factor (1234567) factor (12345678) factor (123456789) factor (1234567898) factor (12345678987) factor (123456789876) factor (1234567898765) # all OK up to this point factor (12345678987654)# locks up computer if I run this line #factor (123456789876543) #factor (1234567898765432) #factor (12345678987654321) Hint: 2057613164609L is a Really Big Number (tm). If it's prime (I don't know if it is or not), it will take more than 46 days on my computer to figure that out. Did you wait that long? Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: simple math question
On Sat, 11 Feb 2006 16:43:33 -0500 in comp.lang.python, John Salerno [EMAIL PROTECTED] wrote: John Salerno wrote: Hi all. I'm just starting out with Python, so I'm a little slow right now. :) Can someone explain to me why the expression 5 / -2 evaluates to -3, especially considering that -2 * -3 evaluates to 6? I'm sure it has something to do with the negative number and the current way that the / operator is implemented, but why doesn't it evaluate to -2 instead? Thanks for the help guys! It's clearer to me now, and I think I was just conceptualizing it the wrong way in the first place. Probably not the wrong way, just a different way, especially if you write C code. The C standard defines integer division as (something like) the integer part of the result, throwing away the fraction, which would get you the value you expect. This also means the sign of the result of the C % operator matches the sign of the numerator. In Python, the sign matches the sign of the denominator. You could also describe the C scheme as truncating towards zero. Python (and my HP calculator) truncates toward negative infinity. I suppose a third way to do it would be to truncate towards positive infinity, but I don't know of any concrete examples of this. 'Twould seem counter-intuitive in any case... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do you pronounce 'tuple'?
On Sun, 12 Feb 2006 23:30:25 -0500 in comp.lang.python, Steve Holden [EMAIL PROTECTED] wrote: John Salerno wrote: [...] I know it comes from the suffix -tuple, which makes me think it's pronounced as 'toople', but I've seen (at m-w.com) that the first pronunciation option is 'tuhple', so I wasn't sure. Maybe it's both, but which is most prevalent? [...] Tyoople, toople or tupple depending on who you are, where you grew up and who you are speaking to. As with so many Usenet questions, there's no right answer, only 314 wrong ones :-) FWIW, I've often heard the latter two, but never the first one. Tuple by itself tends to be toople, but as a suffix tends to be tupple. I teach on both sides of the Atlantic, and have learned to draw a mental breath before trying to pronounce the word router. Americans find the British pronunciation (rooter) hilarious, despite the fact they tell Probably a cultural reference to Roto-Rooter, a nationwide plumbing company specializing in cleaning (ostensibly tree and other plant roots, though often more, uh, prozaic materials), from sewer drains. Call Roto-Rooter, that's the name, and away go troubles down the drain. me I drive on Root 66 to get to DC. The Brits are politer, and only snigger behind my back when I pronounce it as Americans do, to rhyme with outer. I've seen route pronounced rout or root depending on the background and mood of the speaker, though in this part of the country (midwest, though middle might be more accurate) the former pronunciation is far more common. Through the sugestive power of television, however, I suspect nearly every American would speak of root 66 even though the next sentence might reference rout 12. On NPR ([American] National Public Radio), there's a weekly music program called American Routes pronounced such to conjure the alternate American Roots. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do you pronounce 'tuple'?
On Mon, 13 Feb 2006 22:30:43 +0100 in comp.lang.python, Peter Maas [EMAIL PROTECTED] wrote: John Salerno schrieb: Terry Hancock wrote: So what's a 1-element tuple, anyway? A mople? monople? It does seem like this lopsided pythonic creature (1,) ought to have a name to reflect its ugly, newbie-unfriendly nature. Are we having fun yet? ;-) I kind of like 'moople'. :) tuples are of latin origin, so one can derive the tuple words systematically: Latin n-tuple --- ... ... triplex triple duplexduple simplex simple When I was in 4th grade, I was taught to count to ten in latin: unos, duos, trace, quatro, quinque, sex, septem, octem, novem, decem (assuming the intervening 35 years haven't dimmed my memory too much...). This would suggest untuple (or one of several contractions such as unuple or uple). Though I suspect single is correct. Consider coronary bypass operations -- single, double, triple, quadruple... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do you pronounce 'tuple'?
On Mon, 13 Feb 2006 16:46:26 -0500 in comp.lang.python, Steve Holden [EMAIL PROTECTED] wrote: Dave Hansen wrote: On Sun, 12 Feb 2006 23:30:25 -0500 in comp.lang.python, Steve Holden [EMAIL PROTECTED] wrote: [...] Tyoople, toople or tupple depending on who you are, where you grew up and who you are speaking to. As with so many Usenet questions, there's no right answer, only 314 wrong ones :-) FWIW, I've often heard the latter two, but never the first one. Tuple by itself tends to be toople, but as a suffix tends to be tupple. No, but then you probably listen to the noos, not the nyoos, on the TV or radio. That's a particularly British pronunciation. I have heard that pronunciation of news, and not just from the British. Back in the mid-1980's I listened to a radio station with a DJ who, in an attempt at humor, would prefix his news segments with a nasal And now, the nYoos! with the first part of the Y heavily stressed and about an octave higher in pitch than either end of the word. He wasn't trying to sound British, just mock-enthusiastic. [...] On NPR ([American] National Public Radio), there's a weekly music program called American Routes pronounced such to conjure the alternate American Roots. Never caught that. Must go get some batteries for my radio. If you're interested, see http://www.americanroutes.org/ Their station list includes some who broadcast over the web. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: invert the order of a string
On Mon, 13 Feb 2006 18:51:11 + in comp.lang.python, rtilley
[EMAIL PROTECTED] wrote:
s = list('some_random_string')
print s
s.reverse()
print s
s = ''.join(s)
print s
Surely there's a better way to do this, right?
How about
s = some random string
print s
s = s[::-1]
print s
HTH,
-=Dave
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: invert the order of a string
On Mon, 13 Feb 2006 19:03:32 + in comp.lang.python, rtilley [EMAIL PROTECTED] wrote: Dave Hansen wrote: How about s = some random string print s s = s[::-1] print s That looks like Perl, but it works. Makes me wonder with the string module doesn't have a reverse or invert function? It's just simple slicing. Well, maybe not so simple, or at least not so common, but with a syntax similar to the range function. Consider the following (string chosen to make it obvious what's going on): s = 0123456789 s[::] s[3::] s[:3:] s[::3] s[::-2] s[-2::-2] Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there a better way?
On Sat, 11 Feb 2006 01:37:59 +0100 in comp.lang.python, Schüle Daniel [EMAIL PROTECTED] wrote: Lonnie Princehouse wrote: everybody is making this way more complicated than it needs to be. storage = list[:list.index(O)] the question is whether the old list is needed in the future or not if not then it would be easer/mor efficient to use del lst[lst.index(0):] And you're both forgetting the list can end with X. the index method raises a ValueError exception if the desired value is not found in the list. Assuming you want to keep the original list and create a new list called storage, you could try if lst[-1] == X: storage = lst[:] else: storage = lst[:lst.index(O)] or even try: storage = lst[:lst.index(O)] except ValueError: storage = lst[:] (WARNING: untested!) Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
On Fri, 27 Jan 2006 20:27:40 -0500 in comp.lang.python, Dan Sommers [EMAIL PROTECTED] wrote: On Fri, 27 Jan 2006 22:29:20 GMT, Neil Hodgson [EMAIL PROTECTED] wrote: ... I'm so used to / for division that ÷ now looks strange. Indeed, I don't think I've used ÷ for division since about 7th grade, when I first started taking Algebra (over 30 years ago). Strange, indeed, and too close to + for me (at least within my newsreader). FWIW, it looks closer to - than + in mine. And as you say, _too_ close. IMHO. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Intro to Pyparsing Article at ONLamp
On Mon, 30 Jan 2006 16:39:51 -0500 in comp.lang.python, Peter Hansen [EMAIL PROTECTED] wrote: Christopher Subich wrote: Using English, because that's the only language I'm fluent in, consider the sentence: The horse raced past the barn fell. It's just one of many garden path sentences, where something that occurs late in the sentence needs to trigger a reparse of the entire sentence. I can't parse that at all. Are you sure it's correct? Aren't raced and fell both trying to be verbs on the same subject? English surely doesn't allow that forbids that sort of thing. (wink) I had a heck of a time myself. Try The horse that was raced... and see if it doesn't make more sense. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: beta.python.org content
On Thu, 26 Jan 2006 15:28:50 -0800 in comp.lang.python, James Stroud [EMAIL PROTECTED] wrote: Rocco Moretti wrote: (Not that I like the logo, mind you...) Does anyone? There has to be a better logo! I thought the previous requirement as established by the BDFL was no snakes. These are snakes, and they have no personality to boot. I like it, FWIW. Better than a dead parrot or a killer rabbit IMHO. Though maybe not as funny... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
Just a couple half-serious responses to your comment... On Fri, 27 Jan 2006 11:05:15 +0100 in comp.lang.python, Magnus Lycka [EMAIL PROTECTED] wrote: Terry Hancock wrote: That's interesting. I think many people in the West tend to imagine han/kanji characters as archaisms that will disappear (because to most Westerners they seem impossibly complex to learn and use, not suited for the modern world). I don't know about the West. Isn't it more typical for the US that people believe that everybody really wants to be like us. Here in Sweden, *we* obviously want to be like you, even if we don't admit it openly, but we don't suffer from the misconception that this applies to all of the world. ;) 1) Actually, we don't think everyone wants to be like us. More like anyone who doesn't want to be like us is weird. 2) This extends to our own fellow citizens. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
On Fri, 27 Jan 2006 08:11:24 GMT in comp.lang.python, [EMAIL PROTECTED] (Bengt Richter) wrote: [...] Maybe you would like the unambiguousness of (+ 8 (* 6 2)) or 6 2 * 8 + ? Well, I do like lisp and Forth, but would prefer Python to remain Python. Though it's hard to fit Python into 1k on an 8-bit mocrocontroller... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: beta.python.org content
On Fri, 27 Jan 2006 13:33:06 + in comp.lang.python, Steve Holden [EMAIL PROTECTED] wrote: Shalabh Chaturvedi wrote: [...] 2. also available as the python-list mailing list Add or a google group (link). It's not a Google Group, it's a Usenet newsgroup. Google merely provides a lousy but accessible interface to Usenet. Gimme the link! http://groups.google.com/group/comp.lang.python Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pulling numbers from ASCII filename not working
On Thu, 26 Jan 2006 06:39:20 GMT in comp.lang.python, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On 25 Jan 2006 12:42:20 -0800, IamIan [EMAIL PROTECTED] declaimed the following in comp.lang.python: [...] I tried print repr(filename) and it returned the actual filename: 'n16w099.asc' , 'n17w062.asc' , etc. You may have problems with the longitude... those leading zeroes may be taken as Octal notation... Shouldn't be a problem unless you make it one. Int defaults to decimal, unless you specify a base or tell it to infer the base from the number format by specifying a base of zero. a = int(062) a 62 a = int(062,0) a 50 Hard to interpret 099 as an octal number in any case: a = int(099,0) Traceback (most recent call last): File pyshell#59, line 1, in -toplevel- a = int(099,0) ValueError: invalid literal for int(): 099 Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Match First Sequence in Regular Expression?
On Thu, 26 Jan 2006 16:26:57 GMT in comp.lang.python, Roger L.
Cauvin [EMAIL PROTECTED] wrote:
Christos Georgiou [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[...]
Is this what you mean?
^[^a]*(a{3})(?:[^a].*)?$
Close, but the pattern should allow arbitrary sequence of characters that
precede the alternating a's and b's to contain the letter 'a'. In other
words, the pattern should accept:
xayz123aaabbab
since the 'a' between the 'x' and 'y' is not directly followed by a 'b'.
I don't know an RE is the best solution to this problem. If I
understand the problem correctly, building a state machine to solve
this is trivial. The following took about 5 minutes of coding:
---begin included file
# Define our states.
# state[0] is next state if character is 'a'
# state[1] is next state if character is 'b'
# state[2] is next state for any other character
# Accept state means we've found a match
Accept = []
for i in range(3):
Accept.append(Accept)
# Reject state means the string cannot match
Reject = []
for i in range(3):
Reject.append(Reject)
# Remaining states: Start, 'a' found, 'aa', 'aaa', and ''
Start = [0,1,2]
a1 = [0,1,2]
a2 = [0,1,2]
a3 = [0,1,2]
a4 = [0,1,2]
# Start: looking for first 'a'
Start[0] = a1
Start[1] = Start
Start[2] = Start
# a1: 1 'a' found so far
a1[0] = a2
a1[1] = Reject
a1[2] = Start
# a2: 'aa' found
a2[0] = a3
a2[1] = Reject
a2[2] = Start
# a3: 'aaa' found
a3[0] = a4
a3[1] = Accept
a3[2] = Start
# a4: four or more 'a' in a row
a4[0] = a4
a4[1] = Reject
a4[2] = Start
def detect(s):
Return 1 if first substring aa*b has exactly 3 a's
Return 0 otherwise
state = Start
for c in s:
if c == 'a':
state = state[0]
elif c == 'b':
state = state[1]
else:
state = state[2]
if state is Accept:
return 1
return 0
print detect(xyza123abc)
print detect(xyzaaa123aabc)
print detect(xyzaa123aaabc)
print detect(xyza123bc)
--- end included file ---
And I'm pretty sure it does what you need, though it's pretty naive.
Note that if '3' isn't a magic number, states a1, a2, a3, and a4 could
be re-implemented as a single state with a counter, but the logic
inside detect gets a little hairier.
I haven't timed it, but it's not doing anything other than simple
comparisons and assignments. It's a little (OK, a lot) more code than
a simple RE, but I know it works.
HTH,
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Creating a more random int?
On Wed, 25 Jan 2006 15:21:43 - in comp.lang.python, Grant Edwards [EMAIL PROTECTED] wrote: On 2006-01-25, Magnus Lycka [EMAIL PROTECTED] wrote: P.S. Since I was a kid, I've heard people say: So you're born on new years day--how unusual. Well, it happens to slightly less than 1/365th of the population[1], so it is rather unusual. Of course it's no more unusal that being born on June 19th or November 3rd or any other date you choose... [1] Assuming birth dates are uniformly distributed. Which the probably aren't in countries where a significant portion of the population schedules births to fit the hospital/doctors schedule. Google birthday paradox for a little OT fun. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: float formatting
On 25 Jan 2006 11:32:27 -0800 in comp.lang.python, Brian [EMAIL PROTECTED] wrote: Hello all, I am a bit stuck with a float formatting issue. What I want to do is print a float to the screen with each line showing one more decimal place. Here is a code snip that may explain it better: #!/usr/bin/env python num1 = 32 num2 = 42.98765 for i in range(2,7): print | + %10.3f % num2 + | In the for loop, is the line with my difficulty. In a perfect world it would read something like this: for i in range(2,7): print | + %10.if % num2 + | #where i would be the iteration and the num of decimal places Try something like this num2 = 42.98765 for i in range(2,7): print | + %10.*f%(i,num2) + | | 42.99| |42.988| | 42.9877| | 42.98765| | 42.987650| HTH, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
On Tue, 24 Jan 2006 16:33:16 +0200 in comp.lang.python, Juho Schultz [EMAIL PROTECTED] wrote: [...] Fortran 90 allowed , = instead of .GT., .GE. of Fortran 77. But F90 uses ! as comment symbol and therefore need /= instead of != for inequality. I guess just because they wanted. However, it is one more needless detail to remember. Same with the suggested operators. C uses ! as a unary logical not operator, so != for not equal just seems to follow, um, logically. Pascal used , which intuitively (to me, anyway ;-) read less than or greater than, i.e., not equal. Perl programmers might see a spaceship. Modula-2 used # for not equal. I guess that wouldn't work well in Python... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
On Tue, 24 Jan 2006 04:09:00 +0100 in comp.lang.python, Christoph Zwerschke [EMAIL PROTECTED] wrote: [...] Once you open your mind for using non-ascii symbols, I'm sure one can find a bunch of useful applications. Variable names could be allowed to be non-ascii, as in XML. Think class names in Arabian... Or you could use Greek letters if you run out of one-letter variable names, just as Mathematicians do. Would this be desirable or rather a horror scenario? The latter, IMHO. Especially variable names. Consider i vs. ì vs. í vs. î vs. ï vs. ... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: a 32 bit number to integer
On Tue, 24 Jan 2006 13:23:05 -0300 in comp.lang.python, Ricardo Quesada [EMAIL PROTECTED] wrote: Hi, In python 2.0, this number was an integer: 0x88776655 but in python 2.4 it is a long (every number 0x7fff it is a long) in python 2.4, is there a way to convert that number to a integer (notice that it only occupies 32 bits) ? Well, the sign bit's gonna be set no matter what. But the following might work for you... def short(x): return int(0x8000 - x) x = short(0x88776655) x -142042709 %x%x '-8776655' Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
On Tue, 24 Jan 2006 19:44:28 +0100 in comp.lang.python, Christoph Zwerschke [EMAIL PROTECTED] wrote: Dave Hansen wrote: C uses ! as a unary logical not operator, so != for not equal just seems to follow, um, logically. Consequently, C should have used ! for = and ! for = ... Well, actually, no. Less (than) or equal is =. Greater (than) or equal is =. Not equal is !=. If you want to write code for the IOCCC, you could use !(ab) instead of a=b... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using non-ascii symbols
On Wed, 25 Jan 2006 08:26:16 +1100 in comp.lang.python, Steven D'Aprano [EMAIL PROTECTED] wrote: On Tue, 24 Jan 2006 10:38:56 -0600, Dave Hansen wrote: The latter, IMHO. Especially variable names. Consider i vs. ì vs. í vs. î vs. ï vs. ... Agreed, but that's the programmer's fault for choosing stupid variable names. (One character names are almost always a bad idea. Names which can be easily misread are always a bad idea.) Consider how easy it is to I wasn't necessarily expecting single-character names. Indeed, the different between i and ì is easier to see than the difference between, say, long_variable_name and long_varìable_name. For me, anyway. shoot yourself in the foot with plain ASCII: l1 = 0 l2 = 4 ... pages of code ... assert 11 + l2 = 4 You've shot yourself twice, there. Python would tell you about the second error, though. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: excellent book on information theory
On Thu, 19 Jan 2006 15:04:51 +0100 in comp.lang.python, Mikael Olofsson [EMAIL PROTECTED] wrote: Terry Hancock wrote: Tim Peters [EMAIL PROTECTED] wrote: UK:Harry smiled vaguely back US:Harry smiled back vaguely Terry Hancock wrote: I know you are pointing out the triviality of this, since both US and UK English allow either placement -- but is it really preferred style in the UK to put the adverb right before the verb? In US English, the end of the clause (or the beginning) is probably more common. Indeed, the UK version (stripped of context) means something completely different than the US (vaguely modifies back rather than smiled.). At least, to this American. I appreciate your desire to put the thread on (Python) topic, but as I see this discussion, it really has to do with respect for the author, but also respect for the reader. The UK version is most likely the way the author intended it to be. Then that is the way the text should be, regardless if it is preferred style or not, under the assumption that English is English is English. I've not read any of the books, but from the critiques I've read, Rowling's skills as a writer in no way match (and indeed, often interfere with) her gifts as a storyteller. Sometimes a writer needs an editor. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can a simple a==b 'hang' in and endless loop?
On Thu, 19 Jan 2006 08:06:50 +0100 in comp.lang.python, Fredrik
Lundh [EMAIL PROTECTED] wrote:
Dave Hansen wrote:
[EMAIL PROTECTED] wrote]
Fuzzyman wrote:
[...]
In this case :
a = ['some string']
b = ['somestring']
a == b
False (probably)
That depends, the C syntax is like this :
char *a=hello;
char *b=hello;
assert(a==b);
// true, the compiler knows the two hello are the same and assign the
same address(sort of id() in python) to a and b
No. The C standard says the compiler is _allowed_ to re-use character
literal constants, but is not _required_ to do so.
I could have sworn that fuzzyman's example contained a literal string in
an array, and an array comparision, so why are you talking about com-
paring string literals ? a compiler for which
I was responding to bonono's example, not fuzzyman's. Perhaps a more
appropriate response would have been that his example (besides being
incorrect) didn't match the situation under consideration.
char* a[] = { some string };
char* b[] = { some string };
...
if (a == b)
printf(True\n);
prints True is definitely broken.
Definitely. However,
if (a[0] == b[0])
puts(True);
May or may not print True. Either answer is allowed. In C.
Regards,
-=Dave
--
Change is inevitable, progress is not.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python.org website?
On Thu, 19 Jan 2006 11:58:27 -0600 in comp.lang.python, Terry Hancock [EMAIL PROTECTED] wrote: [...] At worst, the cross might be a reference to The Spanish Inquisition, which anyone who knows anything about Python should know is topical. Perhaps, but they wouldn't expect it... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python code written in 1998, how to improve/change it?
On Fri, 20 Jan 2006 10:27:58 +1300 in comp.lang.python, Carl Cerecke [EMAIL PROTECTED] wrote: [...] Python has no goto. +1 [...] We want a goto. -1 Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can a simple a==b 'hang' in and endless loop?
On Wed, 18 Jan 2006 17:03:23 +0100 in comp.lang.python, Claudio Grondi [EMAIL PROTECTED] wrote: [...] a = 1L b = 1L a is b False Python fails to reuse the long integer object. It would be interesting to know why, because it seems to be strange, that in case of integers it does (but not always and I don't know actually when it happens and what it depends upon). Reusing long integers would make much more sense than reusing plain integers when considering memory spent on storage. Hmmm... I suspect it's a matter of practicality beating purity. Consider a = 1L b = 10L ... much code ... c = b/5 ... more code ... d = c * 3 ... still more code ... e = a * 6 ... and now the question ... print d is e Do you really want the interpreter, on each long integer assignment operation (5 in the above example), to find all the long integer objects, perform a comparison, and re-use objects that compare equal? Or would you rather the is operator alias == for longs? Are either of these options really useful? Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can a simple a==b 'hang' in and endless loop?
On 18 Jan 2006 08:41:00 -0800 in comp.lang.python, [EMAIL PROTECTED] wrote: Fuzzyman wrote: I'm not familiar with the C basic datatypes - I assume it has an array or list like object. Would it contain a sequence of poitners to the members ? In which case they would only be equal if the pointers are the same. In this case : a = ['some string'] b = ['somestring'] a == b False (probably) Incorrectly using Python syntax for a C example of course :-) That depends, the C syntax is like this : char *a=hello; char *b=hello; assert(a==b); // true, the compiler knows the two hello are the same and assign the same address(sort of id() in python) to a and b No. The C standard says the compiler is _allowed_ to re-use character literal constants, but is not _required_ to do so. So it may be true, or maybe not, depedning ont he compiler (and, probably, the options used in its invocation). But the following is not char *a=hello; char *b=_hello; char *c=b+1; assert(a==c); //false, even the content they point to are the same Ditto. The compiler is allowed to re-use the end of _hello to implement hello, in which case a == b+1, so a==c. Just to confuse matter slightly, if you change the declarations to something like char a[] = hello; char b[] = _hello; char c[] = hello; then a, b, and c are three different strings in three different locations. Always. In this case, the user is allowed to write code like a[0] = 'j'; to change the first string to jello without affecting the other strings. The essential difference is that in the first two cases, you're declaring _pointers_ to char, and initializing them to point to string constants, while in the second case, you're declaring _arrays_ of char, and setting their initial value using a special initialization syntax. However, string in the above are not basic types of C and if you want to compare the value(like comparing integer), you need to use function like strcmp() which again compare byte by byte in the above example and give true. Yes, indeed. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentation/whitespace
On 16 Jan 2006 20:41:24 -0800 in comp.lang.python, thakadu [EMAIL PROTECTED] wrote: Yes, thats what you have to do. And that was my original point, you cannot just paste and go, you have to first reformat. My heart bleeds. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentation/whitespace
On Thu, 12 Jan 2006 11:56:05 +0800 in comp.lang.python, Jon Perez [EMAIL PROTECTED] wrote: [...] Although the below does work, I believe: Verified example: def check_indent(n): if n==4: print You like four spaces elif n==3: print I like three elif n==2: print Others like two else: print But don't mix TABs and spaces! for n in range(4,0,-1): check_indent(n) You like four spaces I like three Others like two But don't mix TABs and spaces! Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: - E04 - Leadership! Google, Guido van Rossum, PSF
On 11 Jan 2006 21:30:11 -0800 in comp.lang.python, [EMAIL PROTECTED] (Aahz) wrote: [..] Side note: I don't have a degree, and I interviewed at Google several years ago. I'm about 97% certain that my lack of degree played little role (if any) in my failure to get a job offer. Side note: I have a couple degrees, and I sent in solutions to those tests Google published in Dr. Dobbs a year or so back, but I never heard back from them. Not that I expected to. I just did it for fun. I'm not sure what Google would do with someone whose entire work experience has been developing C code for small embedded controllers anyway. I use Python mostly to write small utility scripts for myself. And, FWIW, I don't think I could convince my wife (or myself) to move to CullyFORNya for any amount of money, whether there was a massage therapist on duty or not... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do real python programmers work?
On 12 Jan 2006 12:20:50 -0800 in comp.lang.python, bblais [EMAIL PROTECTED] wrote: Hello, Let me start by saying that I am coming from a background using Matlab (or Octave), and C++. I am going to outline the basic nuts-and-bolts I generally write C code for embedded controllers. of how I work in these languages, and ask for some help to find out how the same thing is done in Python. I am not sure what the standard is. [...] I have an editor I use for writing C code with a button I've configured to run lint. When the code lints clean I drop to a shell and run make when I can, fire up the vile IDE for the target platform when I can't, and build the code. Testing means firing up a simulator or downloading the code to the target. How do experienced python programmers usually do it? Is there a usually about it, or is it up to personal taste? Are there any convenient ways of doing these things? I've been writing Python for about 6 years, but mostly small utilities for personal use, so I don't think I'm typical. I think most of my code would run fine in 1.5.2, because that's what I started learning on... I use Idle. I try things out in the interactive shell, open an editor window to write code. When a script is ready to test, I hit F5 to run it. I build my systems bit-by-bit, so it's rarely worth my while to fire up my C editor (though it does support Python syntax coloring and auto-indenting. It may not be the shiniest toy in the box, but Idle does what I need it to do, and it's actually a very powerful and effective tool for writing simple scripts. Huge multi-module projects are probably another animal entirely. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: - E04 - Leadership! Google, Guido van Rossum, PSF
On 12 Jan 2006 16:16:58 -0800 in comp.lang.python, [EMAIL PROTECTED] (Aahz) wrote: In article [EMAIL PROTECTED], Dave Hansen [EMAIL PROTECTED] wrote: And, FWIW, I don't think I could convince my wife (or myself) to move to CullyFORNya for any amount of money, whether there was a massage therapist on duty or not... Google also has technical offices in the New York area. City? shudder. I moved out of the 'burbs of Minneapolis about 6 years ago, not because of the weather, but because it was getting too crowded for me. How 'bout Des Moines, or Madison? Or even Lubbock? Traverse City would be ideal, though there's no large university nearby (you can probably guess my biases...). Or even the Twin Cities? I still have friends there, and might be coaxed back. (Yeah, like Google wants to coax _me_ ;-) Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is the slickest way to transpose a square list of lists (tuple of tuples)?
On Sun, 08 Jan 2006 14:27:55 -0500 in comp.lang.python, Gerard Brunick [EMAIL PROTECTED] wrote: My way is ugly. These has to be a better way. This may not be the slickest way, but I needed some practice with list comprehensions (I've never really gotten used to them...) This works with lists. Making it work with tuples should be a simple change. Also, it works for the general case of rectangular matrices rather than being limited to squares. def transpose(m): Transpose the rectangular two-dimentional matrix m. return [[m[y][x] for y in range(len(m))]for x in range(len(m[0]))] def pm(m): Print the matrix m. Just to see the results. for row in m: print row td = [range(10) for x in range(10)] pm(td) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] pm(transpose(td)) [0, 0, 0, 0, 0, 0, 0, 0, 0, 0] [1, 1, 1, 1, 1, 1, 1, 1, 1, 1] [2, 2, 2, 2, 2, 2, 2, 2, 2, 2] [3, 3, 3, 3, 3, 3, 3, 3, 3, 3] [4, 4, 4, 4, 4, 4, 4, 4, 4, 4] [5, 5, 5, 5, 5, 5, 5, 5, 5, 5] [6, 6, 6, 6, 6, 6, 6, 6, 6, 6] [7, 7, 7, 7, 7, 7, 7, 7, 7, 7] [8, 8, 8, 8, 8, 8, 8, 8, 8, 8] [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] td2 = [range(10) for x in range(5)] pm(td2) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] pm(transpose(td2)) [0, 0, 0, 0, 0] [1, 1, 1, 1, 1] [2, 2, 2, 2, 2] [3, 3, 3, 3, 3] [4, 4, 4, 4, 4] [5, 5, 5, 5, 5] [6, 6, 6, 6, 6] [7, 7, 7, 7, 7] [8, 8, 8, 8, 8] [9, 9, 9, 9, 9] Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to create a script that list itself ?
On 9 Jan 2006 10:09:19 -0800 in comp.lang.python, Patrick Allaire [EMAIL PROTECTED] wrote: How to create a script that list itself ? Stealing from the old C chestnut: s=s=%c%s%c;print s%%(34,s,34);print s%(34,s,34) I would like to know, where is the script's code is stored once we start it. I know I can achieve that, using files : Well, in the above, the script (or rather, the information necessary to print the script) is actually stored in a string that is part of the script... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's wrong with this code snippet?
On Thu, 5 Jan 2006 01:14:43 + (UTC) in comp.lang.python, Karlo Lozovina [EMAIL PROTECTED] wrote: Dave Hansen [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: I'm not sure what rn is, but it looks like a standard library random.Random object. If so, I don't think you want to seed your PRNG each time you use it -- your numbers might be much less random that way. If it is the standard library object, the PRNG is seeded when the module is first imported, so you may not need to seed it at all. Yes, it is random module. So, what is the preferred way of seeding random number generator? Just once in a file? Or something else? I just needed some random choices to be made, so I didn't dig much into random module. Anyway, thanks for pointing this out, appreciated. From my reading of the library docs, when you import random the PRNG is seeded (using the current time) for you automatically. If you call seed without a parameter, it will again use the current time to seed the generator. But the generator only needs one seed to generate a random sequence. Re-seeding the generator starts it proding a new, different sequence. The resulting sequence of numbers is really the first number in several distinct sequences. It may be that the sequence of first numbers is random enough for your use. But the call to seed is useless at best, and damaging at worst. Unless you want to reproduce the same string of random numbers, there's really no reason to seed the generator yourself. Consider: rep = random.Random() rep.seed(1234) first = [rep.random() for x in range(10)] second = [rep.random() for x in range(10)] rep.seed(1234) third = [rep.random() for x in range(10)] print first == second False print first == third True fourth = [rep.random() for x in range(10)] print second == fourth True In your code, I would simply remove the rn.seed() call. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's wrong with this code snippet?
You've received good answers to your original question. Just a side issue... On Wed, 4 Jan 2006 22:19:27 + (UTC) in comp.lang.python, Karlo Lozovina [EMAIL PROTECTED] wrote: [...] def GenerateRandomColour(): rn.seed() colour = rn.choice(['C', 'P', 'Z']) return colour I'm not sure what rn is, but it looks like a standard library random.Random object. If so, I don't think you want to seed your PRNG each time you use it -- your numbers might be much less random that way. If it is the standard library object, the PRNG is seeded when the module is first imported, so you may not need to seed it at all. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: problem adding list values
On Thu, 22 Dec 2005 19:43:15 GMT in comp.lang.python, David M. Synck [EMAIL PROTECTED] wrote: [...] temp = float(raw_input(Please enter the first credit \n)) while temp != 0: credlist.append(temp) temp = float(raw_input(Please enter the next credit \n)) Here you're building credlist as a list of floats. i = 0 This is wasted effort for i in credlist: You've asked to loop through credlist, so each value of i is going to be float. Maybe you should rename i to something that looks less like an index and more like a credit. credits += credlist[i] Here, you're trying to indexa list with a float. No can do... [...] TypeError: list indices must be integers ...ss it's telling you here If anyone can point me in the right direction, I would greatly appreciate it. I think what you want is for cr in credlist: credits += cr Which could also be implemented as credits = reduce(lambda x,y: x+y, credlist) HTH, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: parsing engineering symbols
On Wed, 21 Dec 2005 19:10:21 +0530 in comp.lang.python, Suresh Jeevanandam [EMAIL PROTECTED] wrote: [re: SI prefixes] Exactly what I wanted. It would be nice if the standard float function takes care of these. No, it wouldn't. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: type error on porting outfile.write
On Tue, 20 Dec 2005 22:11:01 -0500 in comp.lang.python, Eric McCoy [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I ported my code from the development to application platform, I found a type error on a fileout statement: outfile.write(object.id +,) What is the type of object.id? I'm guessing an integer. The exception should tell you, e.g.: TypeError: unsupported operand type(s) for +: 'int' and 'str' If I'm right, you can do this: outfile.write(%d, % (object.id)) Or, more generally, outfile.write(%s, % object.id) or even (closer to the original code) outfile.write(str(object.id)+, ) Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to check if a string is an int?
On Thu, 22 Dec 2005 01:41:34 +1100 in comp.lang.python, Steven D'Aprano [EMAIL PROTECTED] wrote: [...] Well, let's find out, shall we? [...] A small but consistent speed advantage to the try...except block. Having said all that, the speed difference are absolutely trivial, less than 0.1 microseconds per digit. Choosing one form or the other purely on the basis of speed is premature optimization. Or maybe on which actually works. LBYL will fail to recognize negative numbers, e.g. def LBYL(s): if s.isdigit(): return int(s) else: return 0 def JDI(s): try: return int(s) except: return 0 test = '15' print LBYL(test), JDI(test) #- 15 15 test = '-15' print LBYL(test), JDI(test) #- 0 -15 But the real advantage of the try...except form is that it generalises to more complex kinds of data where there is no fast C code to check whether re: Generalization, apropos a different thread regarding the % operator on strings. In Python, I avoid using the specific type format conversions (such as %d) in favor of the generic string conversion (%s) unless I need specific field width and/or padding or other formatting, e.g. for p in range(32): v = 1p print %2u %#010x : %-d % (p,v,v) Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to check if a string is an int?
On 21 Dec 2005 14:36:32 -0800 in comp.lang.python, Paul Rubin http://[EMAIL PROTECTED] wrote: There is a third choice which is the natural and obvious one: have the function do what its name indicates. Return true if the arg is a digit and false otherwise. If iterating over the whole string is useful (which it may be), then the function should have been named differently, like .isdigits instead of .isdigit. Following your logic to its conclusion, had the name isdigits been chosen, '1'.isdigits() should return False. It's only one digit, not more than one, as the plural would imply. I, for one, don't see any utility in the dichotomy. We only need (should only have) one function. I do agree that isdigits might have been a better name, but we're stuck with isdigit for hysterical raisins. And it's logical that string functions work over a string rather than its first character. FWIW, I've usually tested for digit strings with re.match. It never occurred to me that isdigit tested a whole string. Someone's been trotting out that old jwz chestnut about regular expressions and problems... Not that I agree with it, but ISTM that regular expressions are vast overkill for this problem. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido at Google
On Wed, 21 Dec 2005 16:14:16 -0600 in comp.lang.python, Rocco Moretti [EMAIL PROTECTED] wrote: [...] 15 meters (150 decimeter, 1500 cm, etc ...) 590 inches 49 feet 16 yards 0.0093 miles 0.008 nautical miles 3 rods 0.075 furlongs 1800 barleycorns 147.63 hands 66 spans 33 cubits 13 ells 8.2 fathoms 75 links 0.75 chains 0.0027 leauges 0.03 li 0.081 stadia 4.8e-16 parsecs 1e-10 astronomical units 5e-8 lightseconds 2.8e11 Bohr radiuses 9.2e35 Plank lenghts and probably most appropriately (being dutch): 1.5 roede In other words a stone's throw away. You forgot 8.81419673 smoots Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to create linked list automatically
On Mon, 19 Dec 2005 20:51:39 + in comp.lang.python, Simon Brunning [EMAIL PROTECTED] wrote: I haven't the time (or inclination) to sort out all your problems here, but one thing jumps out at me: On 12/19/05, Shahriar Shamil Uulu [EMAIL PROTECTED] wrote: class Node: def __init__(self,name=None,next=None): self.name=name self.next=next def __str__(self): return str(self.name) Your Node classes str() prints the instances self.name attribute, which is set by an optional named argument on the initialiser... w=[] for i in range(10): node=Node(i) ... but you aren't providing this argument when you build your Node objects... Actually, he is. Look closer. As /F pointed out, his problem is in the linking. By making a small modification to his code, I was able to get it to print 1 2 3 4 5 6 7 8 9 None As (I assume) was expected. I'd post the code, but the margin is too small to contain it... Besides, I'd like the OP to figure it out himself. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: ?: in Python
On Wed, 14 Dec 2005 21:16:23 +0100 in comp.lang.python, Lawrence Oluyede [EMAIL PROTECTED] wrote: Il 2005-12-14, Andy Leszczynski [EMAIL PROTECTED] ha scritto: How can do elegantly in Python: if condition: a=1 else: a=2 like in C: a=condition?1:2 There are tons of threads on this newsgroup and in the python-dev mailing list about a ternary operator. There's also a PEP AFAIK. I like this: In [1]:switch = True In [2]:a = (1, 2)[switch] In [3]:print a 2 Note, however, you have the logic backwards. To duplicate the functionality of the OP's example, you need a = (2,1)[condition] or a = (1,2)[not condition] Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why and how there is only one way to do something?
On Thu, 15 Dec 2005 14:57:18 + in comp.lang.python, Steve Holden [EMAIL PROTECTED] wrote: [...] Would you say do: suite while condition or what? Basically do ... while and do ... until most naturally put the Works for me, though I wouldn't cry if the while was changed to until to make the difference between this form and the while loop more obvious. I don't think there's a good argument for _both_ do-while and do-until, but one or the other would be useful. The biggest objection I see is the addition of one or two more keywords, but I don't recall using do or until as a name in any of my programs... test after the loop body (suite), and it's difficult to think of a consistent and natural syntax for expressing the construct. Not that this stopped lots of people from coming forward with their personal favourites ... some suggestions even offered n and a half looping possibilities. Syntax is the problem? Specifically the position of the condition after the loop body? How do you explain the syntax of the new Python ternary operation, with the test in the middle, even though it logically has to be done first? Right now, I tend to write these loops something like while 1: do_stuff() if exit_condition: break which offends my sense of aesthetics, but it works. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tuples
On 15 Dec 2005 09:19:37 -0800 in comp.lang.python, Tuvas [EMAIL PROTECTED] wrote: Let's say I make a program something like follows: x=[] x.append([1,2,3]) x.append([4,5,6]) print x print x[0] print x[0][1] x[0][1]=5 Okay, everything works here as expected except the last line. Why won't this work? Thanks for the help! Perhaps because you're not expecting the right thing? Here's what I get: x = [] x.append([1,2,3]) x.append([4,5,6]) print x, x[0], x[0][1] [[1, 2, 3], [4, 5, 6]] [1, 2, 3] 2 x[0][1]=5 print x [[1, 5, 3], [4, 5, 6]] Which is what i would expect. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about tuple lengths
On Wed, 14 Dec 2005 12:58:16 -0500 in comp.lang.python, Jean-Paul Calderone [EMAIL PROTECTED] wrote: [...] It's the comma that makes it a tuple. The parenthesis are only required in cases where the expression might mean something else without them. That's almost true. Consider: t2 = (1,2) # 2 element tuple t1 = (1,) # 1 element tuple t0 = (,)# 0 element tuple? File stdin, line 1 t0 = (,) ^ SyntaxError: invalid syntax t0 = () # Guess not, try parens with no comma print t0, t1, t2 () (1,) (1, 2) print type(t0), type(t1), type(t2) type 'tuple' type 'tuple' type 'tuple' print len(t0), len(t1), len(t2) 0 1 2 Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: PHP = Perl Improved
On Sat, 10 Dec 2005 08:25:08 GMT in comp.lang.python, Tim Roberts [EMAIL PROTECTED] wrote: [...] The design of the PHP language is not too bad, and the standard library is extensive. It is quite possible to write well-structured, class-based web programs with PHP. However, it seems that almost no one actually does so. Virtually all of the vast PHP code samples on the web are crap. Maybe the simplicity of the language encourages inexperienced programmers who write spaghetti code without a thought to the structure; I don't know the exact cause, but I have seen it more often than not. This reminds me of a comment that John Levine (moderator of comp.compilers) wrote in a post back in 1997: It is my impression that it's possible to write good programs in C++, but nobody does. However, in the case of C++, I wouldn't blame ... the simplicity of the language ... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 8 Dec 2005 08:17:14 GMT in comp.lang.python, Antoon Pardon [EMAIL PROTECTED] wrote: [...] I just think braces are the worst solution for it, as python is concerned. Agreed. A model like Modula-2's would be much preferable, and in fact is supported (but not enforced) today (as long as you also obey indentation rules). Just mark the end of your blocks with #endif, #endfor, #endwhile, #enddef, #endclass, #endwhatever as appropriate. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
On Wed, 07 Dec 2005 12:33:07 -0600 in comp.lang.python, Rocco Moretti [EMAIL PROTECTED] wrote: [...] fred where guido had had had had had had had had had had had a better effect on the reader I've seen this before as bill had had had but will had had had had had had or had had been correct had had had Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why my modification of source file doesn't take effect when debugging?
On Fri, 02 Dec 2005 18:04:15 +0100 in comp.lang.python, Christophe [EMAIL PROTECTED] wrote: infidel a écrit : I'm using the Windows version of Python and IDLE. When I debug my .py file, my modification to the .py file does not seem to take effect unless I restart IDLE. Saving the file and re-importing it doesn't help either. Where's the problem? import only reads the file the first time it's called. Every import call after that looks up the module in memory. This is to prevent circular dependencies between modules from creating infinite loops. You need to use the reload() function: As a matter of fact, it would help a lot if that stupid behaviour of Idle was dropped. I'm sure I'm not the only one who lost lots of time because of that bug. Yes I call it a bug. But, if you are editing a Python Module in Idle, and press F5 to run the module, the interpreter is restarted for you. So what's the problem? I would consider it a far greater problem if Idle _didn't_ do that -- it could mean you module worked when you were debuggining it because of some initialization that doesn't get performed in a clean start. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dao Language v.0.9.6-beta is release!
On 2 Dec 2005 10:08:21 -0800 in comp.lang.python, [EMAIL PROTECTED] wrote: Here it is again... Python bypassed/discounted because, of all things, scoping by indentation!?!? This used to surprise me. Until I hear more and more otherwise reasonable programmers list this as their number one reason for shunning Python. I gauge design defects by how much after market discussion/documentation a feature generates/requires. Scoping by indentation is a whopper of a defect. FWIW, indentation scoping one one of the features that _attracted_ me to Python. It's far more interesting to me _why_ people think indentation scoping is a bad thing. The answer I get back fall into two general categories: 1) I've heard/read/been told it's a bad thing, and 2) It causes portability problems. Of these, only (2) is valid. And the only reason it's valid is that Python recognizes the TAB character as valid indentation. TAB characters are evil. They should be banned from Python source code. The interpreter should stop translation of code and throw an exception when one is encountered. Seriously. At least, I'm serious when I say that. I've never seen TAB characters solve more problems than they cause in any application. But I suspect I'm a lone voice crying in the wilderness. Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as Guido Intended
On 30 Nov 2005 10:57:04 GMT in comp.lang.python, Antoon Pardon [EMAIL PROTECTED] wrote: On 2005-11-29, Mike Meyer [EMAIL PROTECTED] wrote: Antoon Pardon [EMAIL PROTECTED] writes: You see, you can make languages more powerful by *removing* things from it. You cast this in way to general terms. The logic conclusion from this statements is that the most powerfull language is the empty language. The only way you reach that conclusion is if you read the statement as saying that removing things *always* makes a langauge more powerful. That's not what I said, I would say it is the common interpretation for such a sentence. I hope no one ever tells you that you'd be healthier if you ate less and exercised more. (Perhaps it's not true in your case, but it certainly is in mine.) Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Quene
On 30 Nov 2005 09:38:44 -0800 in comp.lang.python, Tuvas [EMAIL PROTECTED] wrote: I am trying to write a function that holds a variable-length quene. The quene has 2 bits of information. At some point, I would like to remove bits of this quene, when they are completed. Is there a way to do this with something as follows? the following might work... quene=[] quene.append((4,2)) quene.append((3,6)) if(4 in quene):#Shows false, what's the correct syntax to show true? found = [t for t in queue if t[0] == 4] if found: remove 4 from quene #(Not python code, not sure how to do this...) queue.remove(found[0]) HTH, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
