[Tutor] odd behavior within __init__
(Oops, forgot to change this to go to the list...) On 4/14/05, Orri Ganel [EMAIL PROTECTED] wrote: On 4/14/05, Rich Krauter [EMAIL PROTECTED] wrote: On 4/14/05, Max Noel [EMAIL PROTECTED] wrote: Well, if you want b and a to refer to the same object, just use b = a. If you'll look at my code, you'll see that I *did* try that approach, and it did not persist past __init__ for some reason: That's because you re-bound the local name 'self', but that doesn't affect anything outside the local namespace. Remember, __init__() returns None; the object has already been allocated before __init__() is called, and while __init__() can mutate the object it can't affect the reference that the interpreter has created. (Unless you resort to hacking the contents of the parent frame, but we won't get into that. You *don't* want to do this.) In this case, I agree that a factory is your best bet. Jeff Shannon class Node: ... def __init__(self, cargo=None, prev=None, next=None, nod=False): x.__init__(...) initializes x; see x.__class__.__doc__ for signature if not isinstance(cargo, Node) or nod: self.cargo = cargo self.prev = prev self.next = next else: # self = cargo ## see? # print id(self), id(cargo) print self.cargo a = Node(1) b = Node(a) 12932600 12932600 1 id(b) 12960632 -- Email: singingxduck AT gmail DOT com AIM: singingxduck Programming Python for the fun of it. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Launching a file browser
On Mar 31, 2005 2:14 PM, Mike Hall [EMAIL PROTECTED] wrote: It's been too long since I used Python on MacOSX, but IIRC you can't just run a Python GUI program from the shell. Or something like that...you should ask this one on the python-mac SIG mailing list: http://www.python.org/sigs/pythonmac-sig/ Kent I'm unclear on why a command like webbrowser.open() will comfortably launch your default web browser (in my case Safari), but something as ubiquitous to an OS as a file browser has special needs to launch. At the OS level, these two actions are *completely* different. The webbrowser module launches an entirely separate program in its own independent process, where the file browser is opening a standard dialog inside of the current process and dependent upon the current process' message loop. (AFAIK, every GUI environment uses some sort of message/event loop...) I don't know Macs, but on Windows, the closest file browser parallel to what the webbrowser module is doing would be os.system(explorer.exe), which launches a separate program in an independent process. However, if you're trying to get the results of the file selection back into your own app, you need to do the file browsing within your own process (or explicitly use some form of inter-process communication). In order to use a GUI file-browsing dialog, you need to follow all the rules for a GUI program. Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] random import errors?
On Apr 1, 2005 3:20 PM, Jay Loden [EMAIL PROTECTED] wrote: I have a python script that runs on my webserver every fifteen minutes. It has run for several months with absolutely no problems. Suddenly, yesterday morning I got an email from cron with an import error for sre_constants (see below) Since you're able to import these files manually, it's unlikely to be a problem with your Python installation. I'd suggest trying to figure out what changed between the day before yesterday and yesterday. I'm just guessing here, but I'd expect that this is probably related to either permissions or environment variables. Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Launching a file browser
On Mon, 28 Mar 2005 18:53:39 -0800, Mike Hall [EMAIL PROTECTED] wrote: I my case the gui will be comprised of html and javascript, talking to python through system calls. I basically want to know if there's an equivalent of the webbrowser() module (which launches my browser) for file dialogs. This is what EasyDialogs should do, but does not. If you're using html and browser scripting for your GUI, then you'll probably need to use html and browser scripting for your file dialog too. A file dialog is just another GUI segment, so it should work the same as the rest of your GUI. Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Float precision untrustworthy~~~
On Mon, 28 Mar 2005 22:13:10 -0500, Jacob S. [EMAIL PROTECTED] wrote: I've already deleted the recent thread-- But sometimes I agree with he who said that you can't trust floats at all. The scientific theory suggests that if an output is not what it should be, then the hypothesis is untrue. In this case, the hypothesis is the fact that float division should always produce the same output as our decimal division used in common schools today. Since that is not always true, then floats are not trustworthy~~~ frankly, the mere fact that floats are difficult to check with equality has bitten me more than anything I've met yet in python. The scientific method is also quite well aware of the limits of precision. *EVERY* tool that you use to make measurements has precision limits. In most of those cases, the imprecision due to measuring tools will overwhelmingly swamp the tiny bit of imprecision involved with floating-point arithmetic. It's also worth pointing out that most of the float imprecision isn't anything inherent in the floats themselves -- it's due to converting between binary and decimal representation. Just as a phrase that's translated from English into Russian and then back to English again can have its meaning shifted, translating between different numerical bases can create error -- but it's usually *much* less error than the natural language translations cause. Really, all this talk about floating-point imprecision is *way* overblown. It's important to be aware of it, yes, because in some cases it can be relevant... but it's a *long* way from making floats unusable or unreliable. 64**(1/3) == 4 False 64**-3 == 4 False a = 1/3 a 0.1 Note that you'll have the same problems if you use a Decimal number type, because there's also an imprecision with Decimals. The problem is that you're expecting a digital variable with a limited discrete set of possible values to be equivalent to a rational number -- but no binary or decimal floating-point number can exactly represent 1/3. A Decimal approximation would have a 3 as the final digit rather than a 1, but there *would* be a final digit, and *that* is why this can't work. Why not just implement decimal or some equivalent and get rid of hidden, hard to debug headaches? Well, a Decimal type *has* been implemented... but it's just trading one set of headaches for another. What your code is apparently expecting is a Rational type, which has been discussed ad infinitum (and probably implemented several times, though not (yet) accepted into the standard library); Rationals have the problem, though, that any given operation may take an unpredictable amount of time to execute. Would you consider it an improvement if, instead of wondering why you're not getting an equality, you were wondering whether your machine had frozen? There's always a trade-off. It's important to be aware of the weaknesses of the tools that you use, but *every* tool has weaknesses, and it doesn't make sense to discard a tool just because you've learned what those weaknesses are. Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] If elif not working in comparison
On Mon, 28 Mar 2005 09:27:11 -0500, orbitz [EMAIL PROTECTED] wrote: Floats are inherintly inprecise. So if thigns arn't working like you expect don't be surprised if 0.15, 0.12, and 0.1 are closer to the same number than you think. However, the imprecision of floats is in the 10-12 precision digit range. That is, it's precise up to about 0.01 (or slightly fewer decimal places if the integer part is large). Given the precision with which those constants are specified, I doubt that float imprecision will be an issue here, unless there's a *lot* of repeated operations, e.g. a loop with many (i.e. hundreds to thousands of) iterations. Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Linked List
On Sat, 5 Mar 2005 06:20:40 -0800 (PST), Shitiz Bansal [EMAIL PROTECTED] wrote: In order to explain wat my problem is, here is an example code. Its not exactly what I am doing, I am using multiple threads and a rather complicated code so try and understand the sense rather than the code itself. myls=range(50) for i in myls: print i if i==20: myls.insert(5,5) The point is, the list(both size and elements) is changing even as it is being operated upon. My first thought was to say, Use a queue.Queue. But it appears that you need to be able to do more than just add items at the end of the queue. I suspect that what you need is along the lines of a priority queue. That is, something that works approximately like a queue, but when you add items to it, you also specify a priority for them. Then, when you retrieve an item from the queue, what you get is not necessarily the first-inserted item, but rather the item with highest priority. You might want to check the Cookbook to see if there's a priority queue recipe there. If not, I suspect that Google can be convinced to yield something... Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Criticism / Suggestions
On Wed, 02 Mar 2005 01:17:28 -0500, Bill Kranec [EMAIL PROTECTED] wrote: [...] I wanted to be able to define multiple tournament objects off of the same roundlist, to avoid generating the list every time a new object is created. I think what I really want to do is have a separate Round class, from which Tournament inherits the list of rounds. I have started to implement something like this in my most recent version, but haven't finished it yet. ( I need to understand class inheritance better. ) This sounds like a good idea, but inheritance is probably not the right way to solve it. Every Tournament contains a list of Rounds, but it's probably not accurate to say that a Tournament is a type of Round. (Inheritance works best when it describes an is-a relationship, not a has-a relationship.) It's probably better to have Tournament and Round be independent classes, but have Tournament instances hold a list of Rounds (which may be passed in during initialization, or may be added later). This is called composition, and is just as important (or perhaps more important) of an idea as inheritance, even though inheritance gets all the press. ;) Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] SubClassing
On Fri, 25 Feb 2005 05:54:39 -0200, Ismael Garrido [EMAIL PROTECTED] wrote: def __init__(self, this, that, new): Parent.__init__(self, this, that) #note self self.new = new If the paren's init t has a lot of possible arguments, it may be easier to do things this way: class Child(Parent): def __init__(self, new, *args, **kwargs): Parent.__init__(self, *args, **kwargs) self.new = new This way, the Child class doesn't need to know or care about what parameters get passed on to Parent; it uses the ones it needs, and passes all the rest on. Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] sys.argv[1: ] help
On Sun, 27 Feb 2005 17:55:54 +, Richard gelling [EMAIL PROTECTED] wrote: No What I get if I was to type in ./arg1.py a b c All I get is [] It sounds as though the command shell is not passing along the additional parameters. Try opening Windows Explorer, and go to the Folder Options (in the Tools menu, IIRC). Go to the File Types tab, find PY (Python File), and click the Advanced button. In the resulting dialog, select the open action and click edit, then look at the command line that it's using. You want something that looks like: C:\Python23\python.exe %1 %* The '%*' bit at the end is what I suspect may be missing in your settings. (There's some chance that cmd.exe uses a different set of settings than Windows Explorer does, in which case you'll have to research that independently. I know that you can use the assoc command to associate the .py extension with the Python.File filetype, but I'm not sure how to create filetypes or change actions that are taken upon filetypes if it's different from the Explorer settings) Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Active Python
On Thu, 17 Feb 2005 15:54:43 -0800 (PST), Terry Carroll [EMAIL PROTECTED] wrote: On Wed, 16 Feb 2005, Robert Campbell wrote: I am not a programmer, but have decided to learn Python. I am wondering if anyone has used the Activestate ActivePython and what are the advantages/disadvantages of using it rather than the standard Python tools. If you're on Windows, I recommend it. It is the full Python, plus some Windows extensions. I fully agree. ActivePython contains everything that you'd get from the standard distribution, plus extra tools that are especially useful under Windows. (I like PythonWin a lot more than IDLE...) The only downside I've encountered is that, as of 2.4, it no longer includes the Help files in their original HTML format. Instead, there's just one big help file in Windows Help format. I prefer the HTML, because I can then run searches against it from outside the help system. Interesting -- I prefer the CHM (Windows helpfile), because it's internally indexed. I feel that the internal search is more convenient than external searches would be. But I suppose that there's room for reasonable people to disagree, here. :) Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Queued threads
On Wed, 16 Feb 2005 16:50:07 +1300, Liam Clarke [EMAIL PROTECTED] wrote: Oops, you probably want to do this then- for i in range( 0, 3 ): oThread = Thread( target=mainFunction ).start() while oThread: print 'sleeping 3 seconds' time.sleep( 3 ) Probably not. Note that, since oThread's value is not changed in the body of this while loop, you will either never execute the body (if oThread is false) or execute it infintely many times (if oThread is true). I doubt that's the desired behavior. ;) In this case, since Thread.start() apparently always returns None, the while loop is effectively a no-op. However, if it *did* get triggered, it would do so immediately after the first thread [which returned a true value from start()] was started -- preventing later threads from being started because the main program is stuck in this endless loop. You could perhaps rewrite the whole thing like this: .for i in range(3): .mythread = Thread(target=mainFunction) .mythread.start() .while mythread.isAlive(): .print sleeping 3 seconds [main thread] .time.sleep(3) Though as others have said, if you're not starting the second thread until the first is finished, then you might as well just make it explicitly sequental and not bother with threads: .for i in range(3): .mainFunction() If you actually want the threads to process concurrently, and simply wait until all of them are done, you could do this: .threadlist = [] .for i in range (3): .mythread = Thread(target=mainFunction) .mythread.start() .threadlist.append(mythread) .for thread in threadlist: .thread.join() The join() method will wait until that thread is finished, and then return. If the thread is already finished when it's called, it returns immediately. Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] dictionary dispatch for object instance attributes question
On Tue, 15 Feb 2005 23:48:31 -0500, Brian van den Broek [EMAIL PROTECTED] wrote: Jeff Shannon said unto the world upon 2005-02-15 21:20: On Tue, 15 Feb 2005 17:19:37 -0500, Brian van den Broek [EMAIL PROTECTED] wrote: For starters, I've made metadata a class attribute rather than an unconnected dictionary. This seems conceptually nicer to me. The problem is that my Node instance live in a TP_file class instance, and the way my code is now, the TP_file instance also needs to see the metadata dict. There are a few tags, which if present in any Node of the file make me want to treat the entire file a bit differently. (Of course, here is the place where my novice-designer status is most likely to be bitting me.) So, that's why I have it as a module level object, rather than within a class. (I do, however, see your point about it being neater.) Okay, that makes sense. You have two different classes (the TP_file class and the Node class) that need access to the same information, so yes, having it at the module level lets them share it more effectively. (Alternately, since it sounds like the TP_file class is where all of the Node instances are created, you *could* decide that the metadata belongs as part of the TP_file, which would then actively share it with Node... but what you've got sounds like a very reasonable plan, so at this point I wouldn't worry about it.) In addition, update() can now modify several attributes at once, at the cost of a bit of extra parsing up front. The metadata all occurs one element to a line in my original file. [...] Maybe I'm still missing a better way, but as I am processing line by line, each line with one element, I don't see how to use this cool looking multiple elements at once approach. Yes, if you know that you will only have one header per line, then it's reasonable to process them one line at a time. You could alternatively have the TP_file gather all the header lines for a given node into a list, and then process that list to create the Node instance, but given the specifics of your case you probably wouldn't gain anything over your current approach by doing so. This is what makes programming so interesting -- there's so many different choices possible, and which one is best depends on a large number of factors. When writing a program for some task, the best design for a particular set of circumstances may be completely different than the best design for a somewhat different particular set of circumstances -- and the best design for general usage is probably an altogether different thing still. Good luck! Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Help needed with script to batch-create shapefiles
On Wed, 16 Feb 2005 21:37:10 +, Chris Bromley [EMAIL PROTECTED] wrote: Any help would be greatly appreciated! Others have already pointed out that we will have a hard time helping without a bit more information. But I've noticed something odd in your code -- it probably doesn't have anything to do with your problem, but it seems like an awkward idiom to me. fc = fcs.next() while fc: # [...] fc = fcs.next() This, it seems to me, is equivalent to (but less readable than) the following: .for fc in fcs: .# [...] If you're going to do something with every member of a list, then it's much more straightforward to use a for loop (which automatically tracks the iteration) than to use a while loop and manually adjusting the loop-controlling expression. Actually, it occurs to me that this *might* cause a confusing result in your code. Presuming that fcs is a standard iterator (as your usage of next() suggests), then calling next() on an exhausted iterator will raise a StopIteration exception. The for loop will automatically handle that, but with your while loop it would be caught by the following bare except statement. That means that you'll run (what I presume to be) your error-handling code even when you successfully convert every member of fcs... Jeff Shannon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Smith, Jeff wrote:
Jeff,
It looks like that finally is the simplest expression of the original
switch statement:
import sys
def p():
pass
ftable = { 'a' : lambda: sys.stdout.write('a\n'),
'b' : lambda: sys.stdout.write('b or c\n'),
'c' : lambda: sys.stdout.write('b or c\n'),
'd' : p }
ftable.get(var, lambda: sys.stdout.write('default case\n'))()
I do note that it took this group of experienced programmers several
tries to impliment this simple switch statement without actually using
switch. I dare say with standard switch syntax we would've had it right
the first time :-)
I wasn't following this thread all the way through, but to be honest,
I'd have solved this differently -- that may be the best direct
translation of some switch statement, but that doesn't mean it's the
best-fit solution here. ISTM that, given the desire to print some
text (or nothing) based on the contents of a variable, I would *not*
handle the output inside the switch -- that is, I'd (conditionally)
print a value from a string-containing dictionary, rather than use a
table of functions that print strings.
table = { 'a': 'a', 'b': 'b or c', 'c': 'b or c', 'd': None }
result = table.get(var, 'default case')
if result:
print result
This, to my mind, is much cleaner -- you're factoring out the repeated
code, whether print statement or call to sys.stdout.write(), reducing
the complexity of the dict. You're making flow control much more
straightforward. You're making the whole thing easier to read.
The key, here, is that instead of saying I want a switch, how can I
implement that in Python?, I've taken the approach of The end result
I want is ***; what tools does Python offer to achieve that? This
conceptual shift is, IMHO, *the* most important mental hurdle in
learning a [second/third/n-th] language.
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote:
As an aside, I did try to create a lambda based solution but was
unable. Let me know what's wrong:
ftable = { 'a' : lambda: print 'a',
SyntaxError: invalid syntax
I did say if Python had *proper* lambdas...
Unfortunately Python insists on only having *expressions* as
lambdas and since print is a command not a function you can't
use it in Python lambdas! Dumb or what??!
So you are stuck with predefining a bunch of one liner
functions and then creating a dictionary or going back
to if/elif chains, which is where we came in... :-)
Well, in this particular case, if one really wants to use lambdas then
one could (after importing sys, of course) replace the print statement
with a call to sys.stdout.write() --
ftable = { 'a': lambda: sys.stdout.write('a\n'), ... }
Note that sys.stdout.write() will *not* automatically add the newline
that print does (which is why I've specified it in the above sample).
Indeed, print can do all sorts of odd things with whitespace,
leaving sys.stdout.write() as the best way to have real control over
your output anyhow...
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Smith, Jeff wrote: IMHO, if/elif/else statements are far more abused than either switch or ternary but I certainly wouldn't argue they should be removed from the language. IMHO, if it's true that if/elif/else statements are more abused than ternaries, then it's only because they're *used* far more often than ternaries. I'd say that the percentage of uses which could count as abuse is *far* higher for ternary than for if/elif/else. And I avoid (and recommend against) Python's a and b or c trick for similar reasons -- it *is* a trick. A 'real' ternary operator is confusing enough; this trick is more readable (words instead of opaque symbols) but more difficult to write correctly given the constraints on 'a'... Maybe I'm just weird, but I just don't find so much benefit to putting *everything* in-line. Occassionally it improves readability, but more often it obscures and obfuscates. Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Max Noel wrote: On Feb 3, 2005, at 09:48, Alan Gauld wrote: Pythons lambda feature is a bare minimum (and Guido wants to remove it!). Does he? Damn, just when I was learning functional programming! (in Haskell, if you're curious ^^) However, Python doesn't need lambdas to be able to write in a functional style. Functions are first-class objects and can be passed around quite easily, and IIRC Python's list comprehensions were borrowed (though probably with notable modification) from Haskell. Keep in mind that both lambdas and named functions are created at runtime, so the creation of both is fully dynamic. Indeed, there are only a few differences between lambdas and named functions in Python: - Anonymous vs named - Single expression vs suite of statements - Inline vs. pre-created Note that the second of these is a consequence of the third -- given Python's block-indentation-based structure, there's no good way to inline a multi-statement suite (how many of those statements belong to that 'if' suite?). Statements need to have a clear indentation level, and while one can sometimes fudge that for a single statement, it gets exponentially messier as the number of statements goes up. I'd also argue that the inline nature is the *true* differentiating feature of lambdas -- the fact that they're anonymous is relatively minor. Consider, also, that if they weren't inline then you'd need a name to refer to them by... and at that point, you *have* a 'normal' function. So, while there are some advantages to having single-use callables be defined inline (i.e. lambdas), their removal from Python (which wouldn't happen before the mythical Python 3k anyhow) isn't likely to be as devastating as some might lead you to believe. ;) It certainly won't prevent you from using Python for functional programming... (And personally, I suspect that if lambdas *are* removed, they will be replaced with a different construct that will fill the same needs in a more Pythonic way...) Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote: There is no perfect language, and very few truly bad languages - they never get out of the lab - they all have something that they are good at and from which we can learn! Heh, I'd look at that a bit differently -- I think that there's a *lot* of bad languages, it's just that we're spared ever hearing about the majority of them because they don't ever get very far. ;) (But then, at my job I'm stuck using a horrible Frankenstein's monster of a proprietary language on a daily basis, so I can't help but believe that there's plenty more awful languages around that didn't happen to be rescued from oblivion by an accident of history...) Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Alan Gauld wrote: However, Python doesn't need lambdas to be able to write in a functional style. I disagree Jeff. It does need lambdas to do FP properly, and better lambdas than we have currently. What it doesn't need is the lambda keyword and syntax - although pesonally I like lambda since it is descriptive! Well, we'll have to continue to disagree on that. ;) Personally, I can't help but think that 'lambda' is descriptive only to people who've experienced it elsewhere, and that that does *not* include the majority of the programming community, but I could be mistaken. :) Functions are first-class objects and can be passed around quite easily, Yes, but lambdas are more than first class functions, they are anonymous functions! In fact really just callable code blocks, not necessarily functions in the strictest sense (except that every callable in FP is a function...! ;-) Well, given that in Python a function is just a callable code block that's bound to a name... ;) Personally, I fail to see why having an anonymous function is such a huge conceptual advantage, no matter how many times this is proclaimed as truth by lambda-users, but again this is just my own impression. Having to define every function before using it would be a big hassle and make code less readable IMHO. Here, ISTM that you're emphasizing the in-line nature of lambdas as being their key usage point... And personally, I prefer to have a glossary of terms rather than having to decipher jargon by context. ;) only a few differences between lambdas and named functions in Python: - Anonymous vs named the key feature Again, I fail to see why this is such an advantage -- I've seen assertions that it is, over and over again, but never any convincing evidence - Single expression vs suite of statements A python restriction. Well, I *did* specify that I was talking about 'in Python'... ;) I'd also argue that the inline nature is the *true* differentiating feature of lambdas -- the fact that they're anonymous is relatively minor. I agree, if I had an inline mechanism that forced me to provide a name I could just use 'f' over and over and not feel too cheated, but its nicer not to have an artificial name when theres no need. Personally, I prefer to have the opportunity to provide a meaningful name, and don't see where a generic name is any more restrictive than having no name, but again, maybe that's just me. So, while there are some advantages to having single-use callables be defined inline The other advantage is the huge conceptial advantage that real lambdas confer. The breakthrough idea of def f(x): return x+x being the same as f = lambda x: x+x is only possible to demonstrate if you have lambda to start with. And yet that concept of a function name being just another variable and the callable code being an object in its own right becomes much more obvious in my opinion. lambda is a learning tool which shows what is really happening whereas def is just syntactic sugar. Hm, I understood the idea of functions being just code objects that were bound to a name, and could be passed around, stored in collections, and effectively renamed, well before I really got a hold on lambdas as anything more than some confusing bit of magic. Of course, I started in C, where I was fairly comfortable with the idea of function pointers; function objects are a pretty simple step up, abstraction-wise, from that. I suppose that one might argue that I *still* just don't really get lambdas (and I wouldn't argue with that). I can see some advantages to small inline functions, though I suspect that a more-explicit currying mechanism (such as the proposed partial() higher-order function) could easily replace such uses. I'm sorry to say, though, that the supposed advantages of anonymity come across as little more than handwaving assertions to me, no matter how sincerely they're intended. (I've just started to read through SICP, to pick up some lisp/scheme, in hopes of understanding the appeal a bit better, so maybe there's hope for me yet. ;) ) Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
Max Noel wrote: On Feb 3, 2005, at 23:41, Jeff Shannon wrote: (But then, at my job I'm stuck using a horrible Frankenstein's monster of a proprietary language on a daily basis, so I can't help but believe that there's plenty more awful languages around that didn't happen to be rescued from oblivion by an accident of history...) Yeah. Sometimes I read a little bit of Wikipedia's Esoteric Programming Languages page, and some of them just leave me in awe. Brainfuck (and its variant Ook!) and INTERCAL (GOTO is considered harmful, so we removed it -- INTERCAL uses COME FROM instead) are already quite impressive, but the very idea of Befunge makes my brain want to explode. Especially that extension to the language that allows one to write N-dimensional programs. :D The difference here is that those are languages that were *intended* to be brain-melting. The language I'm talking about (Pick Proc, aka UHL) was intended to do real work with -- though at times I think it was designed by a brain-damaged lemur that was huffing paint fumes. For example, every line (except flow-control statements i.e. 'if' and 'go' (there's a few other exceptions as well, but anyhow...)) must begin with a single character that denotes what the line does - 'c' for comment, 'o' for output (print to terminal), 'h' to build a command, 'p' to execute that command... empty lines are forbidden. Note also that the position *after* the final newline character is considered a line, and therefore a file cannot end with a newline. Especially when combined with several of the utilities that it's commonly used to script for, it begins to approach Perl in indecipherability, without even having the excuse of being largely non-alpha characters. I'd consider writing a Python extension that would interact with the system such that I wouldn't need to use this awful little scripting language, but that would require more effort and thought than I'm willing to invest in learning the details of this system. Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Better structure?
Jacob S. wrote: So, how would one go about this in a non broken code way? Don't they have something like what I'm requesting. No, but it's pretty easy to do: def exact_lstrip(astring, stripstring): if astring.startswith(stripstring): astring = astring[len(stripstring):] return astring [...] Also why shouldn't string methods include stuff like lstrip which do precisely what I request? Maybe it's because other people would have different expectations? The current implementation of strip() (including lstrip() and rstrip()) seems to work well for the most common case, and I'm not sure that your expectation is necessarily more generally useful than the current behavior. Especially given that your behavior is the one that's easier to hand-code if it's desired. Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Regular expression re.search() object . Please help
Liam Clarke wrote:
openFile=file(probe_pairs.txt,r)
probe_pairs=openFile.readlines()
openFile.close()
indexesToRemove=[]
for lineIndex in range(len(probe_pairs)):
if probe_pairs[lineIndex].startswith(Name=):
probe_pairs[lineIndex]=''
If the intent is simply to remove all lines that begin with Name=,
and setting those lines to an empty string is just shorthand for that,
it'd make more sense to do this with a filtering list comprehension:
openfile = open(probe_pairs.txt,r)
probe_pairs = openfile.readlines()
openfile.close()
probe_pairs = [line for line in probe_pairs \
if not line.startswith('Name=')]
(The '\' line continuation isn't strictly necessary, because the open
list-comp will do the same thing, but I'm including it for
readability's sake.)
If one wants to avoid list comprehensions, you could instead do:
openfile = open(probe_pairs.txt,r)
probe_pairs = []
for line in openfile.readlines():
if not line.startswith('Name='):
probe_pairs.append(line)
openfile.close()
Either way, lines that start with 'Name=' get thrown away, and all
other lines get kept.
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Re: communication between java and python?
Lee Harr wrote: I'm trying to communicate between Python and Java and using os.popen(). But thing dont work...The Java program reads strings from stdin and the python program just writes to stdout. [...] popen(command[, mode[, bufsize]]) Open a pipe to or from command. The return value is an open file object connected to the pipe, which can be read or written depending on whether mode is 'r' (default) or 'w'. So, I do not believe that you can both write to and read from a file handle opened with popen. Not only that, but access to the file-like pipe objects is probably buffered. You'll want to call pipe.flush() after writing to it, or the child process won't actually see what you've written. Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] My best GUI app so far.
, there's nothing particularly special about lambdas -- you can create and pass around regular named functions, too. Each time that make_adddigit_callback() is called, it creates and returns a new function object which captures the current value of 'digit', in exactly the same way that lambda does. A function object (whether named with def, or lambda) like this, which captures a variable's current state, is called a closure. Closures are indispensible for GUI callbacks like this, and many people automatically turn to lambda when they want a closure. For me, though, having a proper def statement somewhere feels clearer. (The merits of lambda vs. def'd functions are a frequent subject of heated debate on comp.lang.python, so if you prefer to stick with the lambdas in this case, I'm sure you'd be able to find plenty of people to support you... ;) ) Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] About Perl's Integer module
('site.company.com')
'b2/37/site.company.com'
. complex2('site2.company.com')
'75/5c/site2.company.com'
. complex2('www.python.org')
'16/95/www.python.org'
.
This uses the md5 module to generate a 'fingerprint' for each domain
name. It gets that fingerprint as a long hexadecimal number, and then
slices off the first few characters to make the directory names. Now,
this method is going to be heavily weighted towards numbers instead of
letters, and it can create a maximum of 16^4 (65,536) different
directories instead of 64^4 (16,777,216), so you're somewhat more
likely to have collisions (multiple sites in a single directory), but
it's still not very likely. (That chance can be reduced by using
longer names, too. Using three-character directory names gives 16^6
possibilities -- which is equal to 64^4, the same as your perl script.)
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] check_range
Jeff Shannon wrote: if myrange in range(10,90): # in is the key word here return True else return False This is, however, the correct solution. :) Or I *should* say, rather, that this is *a* correct solution, in that it will yield the expected answer. Kent Johnson's '10 x 90' is a better solution, however -- 'if x in range(...)' creates a list of numbers, and then steps through that list comparing x to each one in turn, while Kent's version makes only two comparisons and no object creations. While one should never prematurely optimize, it's also good to be aware of how much work is done by different options, and in this case 'if x in range()' isn't any clearer than the direct comparisons. I'd think nothing of the extra cost of using range() if it *did* make the code easier to read, but there's no sense in going to extra work for no benefit. :) Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Please help matching elements from two lists and printing them
kumar s wrote:
On top of this this process is VERY SLOW on high end
server too.
That's because, for each line in spot_cor, you're examining every item
in spot_int, and if there's a match, you examine every element in
spot_int again! If I'm remembering my big-O notation correctly, that
makes this O(n*m + m) -- even if it simplifies to O(n*m) (which I
think it may), that's still quadratic time -- as the length of your
lists grows, your performance will degrade *very* rapidly.
Here's a simplified version of your code. I've changed the for loops
so that they iterate over the lists directly, instead of iterating
over a range and then using that number to index into the list -- the
result is the same, but this way is less extra work and easier to read.
out = open('sa_int_2.txt','w')
for cor_ele in spot_cor:
for int_ele in spot_int:
cols = split(int_ele, '\t')
y = cols[0] + '\t' + cols[1]
if x == y:
for int_ele2 in spot_int:
if y in int_ele2:
out.write(int_ele2 + '\n')
Remember, every time you use 'in', it means traversing the entire
list. Multiple levels of nesting statements that use 'in' causes a
polynomial expansion of work.
Now, here's how I'd rewrite your code.
out = open('sa_int_2.txt','w')
element_dict = {}
for line in spot_int:
cols = split(line,'\t')
key = '\t'.join(cols[:2])
element_dict[key] = line
for cor in spot_cor:
try:
value = element_dict[cor]
out.write(value + '\n')
except KeyError:
pass
out.close()
Note that I iterate through each list only once, so my timing should
be O(n + m). First, I preprocess spot_int by putting it into a
dictionary. I create keys for the dictionary that are identical to
what will be in spot_cor. Then I iterate through spot_cor, and match
each element with what's in the dictionary I've made. If I find
something that matches, I write it out; if I don't, then I simply move
on to the next item in spot_cor.
This does make several assumptions. First, it assumes that every line
in spot_int will be unique in the first two columns -- that is, I'm
assuming that nowhere in the file would you find lines like the following:
5 0 123
5 0 456
If these cases *do* happen, then all but the last such line would be
lost, and only the last one would be left in the dictionary (and thus
found and written out). In your version, all lines whose first two
columns match will be written out. (This may be the source of your
extra results.)
If you *do* need to handle lines like this, then it wouldn't be hard
to modify my code for it. Each value in the dictionary would become a
list, and matching lines are appended to that list. The line
'element_dict[key] = line' becomes 'element_dict.setdefault(key,
[]).append(line)', and writing to the file becomes a for-loop instead
of a single write.
The other assumption that I make is that these files are all of
reasonable size to fit into memory. Your code makes this same
assumption, too, of course. This assumption should be valid for up to
a few tens of thousands (maybe even hundreds of thousands, depending
on your hardware) of items. If you have more than this, then your
best bet would be to start using a real database. (I've heard good
things about mysql and sqlite support in Python...)
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] MemoryError
Liam Clarke wrote: So, I'm going to throw caution to the wind, and try an re approach. It can't be any more unwieldy and ugly than what I've got going at the moment. If you're going to try a new approach, I'd strongly suggest using a proper html/xml parser instead of re's. You'll almost certainly have an easier time using a tool that's designed for your specific problem domain than you will trying to force a more general tool to work. Since you're specifically trying to find (and replace) certain html tags and attributes, and that's exactly what html parsers *do*, well, the conclusions seems obvious (to me at least). ;) There are lots of html parsing tools available in Python (though I've never needed one myself). I've heard lots of good things about BeautifulSoup... Jeff Shannon Technician/Programmer Credit International ___ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Difference between for i in range(len(object)) and for i in object
kumar s wrote:
Here is my code:
spot_cor=[]
Create an empty list...
for m in cor:
Now, for each element in some other list from somewhere else,
... cols = split(cor,'\t')
Ignore the element we've just isolated and try to split the entire
list on '\t' ...
Traceback (most recent call last):
File stdin, line 2, in ?
File /usr/local/lib/python2.3/string.py, line 121,
in split
return s.split(sep, maxsplit)
AttributeError: 'list' object has no attribute 'split'
Yup, the list 'cor' doesn't have a split() method. The string that
presumably should be in 'm' would have such a method, though.
Here is 2nd way:
test_cor=[]
for m in cor:
... cols = split(cor,'\t')
Once again, you're operating on the list, not the element of the list.
Here is my 3rd way of doing this thing:
for m in range(len(cor)):
... cols = split(cor[m],'\t')
Here, you *are* operating on an element of the list. But if I were to
write this segment to be parallel to your previous two attempts, it
would be:
cols = split(cor[cor],'\t')
which probably wouldn't surprise you when it doesn't work...
My question:
Many people suggested me to avoid iteration over a
object using (range(len)) its index and use instead
'Python's power' by using for i in object, instead.
However, when I tried that using some data, as
demonstrated above, I get error because append method
does not work on list.
No -- look carefully at the tracebacks, and you'll see that nowhere
does it complain about append(), nor does it give the line numbers in
which the append() takes place. It complains about split(), and tells
you exactly which line the problem is on ('File stdin, line 2, in
?' -- since you're doing this in an interpreter, there's no filename
or function name).
Jeff Shannon
Technician/Programmer
Credit International
___
Tutor maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/tutor
