sending gmail with smtplib from behind a proxy
Hi, I tried the script below to send mail by gmail from python using
smptlib. I got the script here (http://kutuma.blogspot.com/2007/08/
sending-emails-via-gmail-with-python.html)
It works fine from home, but at work not. I think it is because I am
behind a http or a socks proxy server at work. Can I adapt this script
to work from behind the http or socks proxy? I couldnt understand from
the smtplib if I can specify this somehow?
Sincerely,
bjorn johansson
Script-
#!/usr/bin/python
import smtplib
from email.MIMEMultipart import MIMEMultipart
from email.MIMEBase import MIMEBase
from email.MIMEText import MIMEText
from email import Encoders
import os
gmail_user = "your_em...@gmail.com"
gmail_pwd = "your_password"
def mail(to, subject, text, attach):
msg = MIMEMultipart()
msg['From'] = gmail_user
msg['To'] = to
msg['Subject'] = subject
msg.attach(MIMEText(text))
part = MIMEBase('application', 'octet-stream')
part.set_payload(open(attach, 'rb').read())
Encoders.encode_base64(part)
part.add_header('Content-Disposition',
'attachment; filename="%s"' % os.path.basename(attach))
msg.attach(part)
mailServer = smtplib.SMTP("smtp.gmail.com", 587)
mailServer.ehlo()
mailServer.starttls()
mailServer.ehlo()
mailServer.login(gmail_user, gmail_pwd)
mailServer.sendmail(gmail_user, to, msg.as_string())
# Should be mailServer.quit(), but that crashes...
mailServer.close()
mail("some.per...@some.address.com",
"Hello from python!",
"This is a email sent with python",
"my_picture.jpg")
--
http://mail.python.org/mailman/listinfo/python-list
start external program from python
Hi, I woul like to start a program from within python (under linux): This works fine: import os path = 'tclsh AppMain.tcl hej.gb' os.system(path) The file AppMain.tcl is the executable and the file hej.gb is a textfile in the same directory. The text file gets opened in the app in the correct way. I wonder if I could pass information from the clipboard to the AppMain.tcl instead of the file hej.gb ? I use wxPython. any comment is appreciated! /bjorn -- http://mail.python.org/mailman/listinfo/python-list
unicode in doctests
I'm trying to combine documentation and testing, by using DocFileSuite from Python 2.4. But the problem is that I need to write non-ascii characters in the test, and I can't get it to work. I haven't found a way to specify which encoding the file is in, so it gets decoded to unicode. Anyone know if it's possible at all to use non-ascii character in a DocFileSuite? For example, this fails: >>> foo = u'föö' u'föö' BTW, I know that I can use \-notation, but since the test will serve as documentation as well, I don't want to use it. Regards, Bjorn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Xah Lee <[EMAIL PROTECTED]>] | | | SIMPLE CHANGES if I were to suggest improvements to Emacs, the things you mention are probably among the last things I'd even consider. the problem with Emacs is not really the nomenclature or the keybindings. the problem is that it needs to do what it already does better. My frustration with Emacs has mostly been that Emacs-Lisp is a bit too limiting. It is too slow and the codebase is a bit messy. or at least it was the last time I tried to do something in Emacs-Lisp a couple of years ago. it would also be beneficial if there was a more proper and well-organized standard library for Emacs to make developing Emacs applications easier. for programmers, Emacs is a pretty good editor already, but there is a bit of a threshold for extending Emacs. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Xah Lee <[EMAIL PROTECTED]>] to be quite honest, your proposal seems to largely be based on ignorance. | A: The terminology “buffer” or “keybinding”, are technical terms | having to do with software programing. The term “keybinding” refers to | the association of a keystroke with a command in a technical, software | application programing context. That is to say, a programer “bind” a | keystroke to a command in a software application. The term “buffer” | refers to a abstract, temporary area for storing data, in the context | of programing or computer science. the term "buffer" is used extensively outside the computer science domain, so it is not a CS only term. in an editor it is actually a quite sensible name since it abstracts things a bit. for instance a buffer need not be associated with a file. nor does it make any assumptions about the way it is displayed (as opposed to "window" or "tab"). | These terms are irrelevant to the users of a software application. they are very relevant to me, and I am very much a user of Emacs. and again, they provide good abstractions. | As a user of a text editor, he works with files. learn Emacs before you criticize it. your assumption is wrong. in emacs you work on _buffers_. buffers often do not have files associated with them. | The terms “opened file” or “untitled file” are more appropriate than | “buffer”. Since emacs is also used for many things beside reading | files or writing to files, for example, file management, ftp/sftp, | shell, email, irc etc., the proper term can be “panel”, “window”, or | “work area”. "panel" and "window" refer to UI-elements. the buffer concept does not map 1:1 to any of these. substituting "work area" for "buffer" doesn't seem like a better abstraction. especially not if you see it in the context of how Emacs relates to buffer contents. | And, the term “keyboard shortcut” refers to typing of a key- | combination to activate a command. It is also more appropriate than | “binding” or “keybinding”. why? if anything the term "shortcut" seems to imply that there is a primary route to executing the function in question -- which more often than not isn't the case. "keybinding" is a more precise term. | Although concepts like “buffer” and “keybinding” are seemingly | interchangeable with “panel” or “keyboard shortcut”, but their | contexts set them apart. they are interchangeable only if you have no idea what you are talking about. you obviously have not bothered to have a proper look at Emacs and think these things through properly. | This is why in all modern software application's user | documentations, terms like “buffer” or “keybinding” are not to be | seen but “windows, panes, and keyboard shortcuts”. most "modern" editors are built on different premises than Emacs and many have a far simpler view of the world. extremely few of them even come close to Emacs in defining what is in practice an operating environment for applications. it makes sense to refer to "windows" when in fact you are referring to windows. it doesn't make sense to call buffers "windows" in Emacs; because they are not. | The reason emacs uses the technical terminologies throughout is | because when emacs started in the 1970s, there really isn't any other | text editors or even software applications. the abstractions you mention are sensible ones independently of when they were concieved. just because other people came along later and used different abstractions, doesn't mean that the ones used in Emacs are wrong, inferior or inappropriate. if you had bothered to understand Emacs properly, you would have found that some of the abstractions used make a lot of sense in an editor. | Changes in society are always resisted by old timers, but it is also a | main element behind progress. I've been in the computer industry long enough to have seen quite a few cycles of re-invention. each cycle you learn something about which inventions were good and which were bad. a common thread if you look at the survival rate of products and ideas is that it isn't always the best product or idea that wins. often something new comes along to replace something old. sometimes it is better than what you had before, but often it is not really better, just different. a good example is the web and the applications we implement in terms of the web. take forums for instance. in a strict technical sense, web-based forums are inferior to NNTP-based forums. (I am sure you can make the comparison yourself). yet NNTP-based discussion is not growing at the same rate as web forums. the net has chosen its preferred technology, and it wasn't because the web-based discussion forums were so much more technically refined that the majority chose them. for my uses, web forums are a huge step back from NNTP. | This terminology issue may seem trivial, but its importance lies in | making emacs palpable to the vast number of people who ever need to | use a compute
Re: The Modernization of Emacs: terminology buffer and keybinding
[Giorgos Keramidas <[EMAIL PROTECTED]>] | | Educating the user to avoid confusion in this and other cases of made | up, 'user-friendly' descriptions is not a good enough answer. there are two types of "user friendly". there's "user friendly" and then there is "beginner friendly" which is often mislabeled. the latter is more important for applications which are to be used casually. like utilities you only use once or twice per year -- those need to be "beginner friendly". for applications you are likely to use for prolonged periods of time (like programming, video editing, music production etc), it does not make sense to optimize for "beginner friendly". at least not at the cost of making the application less "user friendly". applications you spend a lot of time using are worth an investment in learning how to use them. what creates friction in an application you know reasonably well is when common tasks are fiddly. for instance, while menus are often good for casual use and lower the initial threshold for absolute beginners, depending heavily on menu navigation becomes too fiddly if you are performing a certain task 2-3 times per minute. it is not _user_ friendly. Emacs is rather "user friendly", but not very "beginner friendly". when I was first confronted with it, the sort of text editors I was used to were Wordstar and derivatives of it. I was rather annoyed that it didn't do what I expected, so I just used a different editor. a few years later I bemoaned the fact that Emacs was so hard to use during a conversation with a friend. he asked me if I had actually made an effort to learn Emacs, which of course I hadn't. so I figured I might as well give it a shot. following the tutorial that comes with Emacs (and which is referred to in the startup message) I spent a couple of hours one afternoon learning the basics. already the next day I started using Emacs for programming. the week after I had progressed to using it as my newsreader (which I still do to this day) and eventually I started reading my email in Emacs. perhaps two months after I had sat down to learn Emacs I wrote my first Emacs extensions in Emacs Lisp. mostly simple stuff to make common programming tasks easier. I found Emacs to be user friendly, but in a different sense than the, IMHO faulty definition, "beginner friendly". Emacs let me, as a user, do more with less effort and provides a lot less friction than many other developer tools I've used. at work I use it extensively, and we have lots of neat extensions that really save a lot of time. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Kaldrenon <[EMAIL PROTECTED]>] | Just so everyone's clear: | | Nothing he has said makes much sense, if any. (it'd be good if you explicitly specify who "he" is since pronouns by nature are extremely context sensitive, and in this context an unattentive reader might think you are referring to me. thanks :-). | Emacs' uniqueness may hurt its adoption rate, but it still has plenty | of users, who are all perfectly happy with how things are done. I don't see popularity as a goal in itself. I am selfish. I only care what the software can do for me and I think that this is the only way to write good software: make something you'd want to use yourself. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Twisted <[EMAIL PROTECTED]>] | | 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. indeed, not adhering to the half a dozen keybinding and menu conventions that most newer applications use on OSX and Windows today is not ideal UI design, but it doesn't really present that much of a problem either; so it ends up being a non-issue to any regular user. (actually, it isn't merely a case of changing some keybindings and names -- the problem is that Emacs has a bunch of concepts that are not easily mapped to trivial editor semantics, so it would be hard to change without causing further confusion). Emacs isn't really meant for the casual user and there are editors far better suited for those who think spending an afternoon learning it is too much. (compare to VI or VIM, which probably takes even a bit longer to grasp, but which is beautifully practical once you understand how it works. there's this good tech-talk given by Bram Moolenaar available¹ on about text editing and VIM). ¹) http://video.google.com/videoplay?docid=2538831956647446078 -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Martin Gregorie <[EMAIL PROTECTED]>] | | As for documentation, lets look at vi. Not a great editor, but every | *nix variation has it installed and any fool can learn to use it in | about 2 hours flat and it does at least have good pattern matching. there's also the "info" system in Emacs, which not only covers Emacs itself, but usually also a lot of documentation available for Emacs extensions and other programs. again, this predates a lot of things that people are used to today, so just because it seems (and sometimes is) a bit more fiddly, it must necessarily be inferior. the most common theme when people have to choose between products is that they are not really comparing what it is like to use the products like they were intended -- they are merely underlining that X is not Y. for instance, Linux has come a long way in addressing the needs of desktop users, yet some people refuse to use Linux because it doesn't behave *exactly* like Windows (as if that was a worthwhile goal) and they are too lazy or don't think they can manage, to learn a new system. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[BartlebyScrivener <[EMAIL PROTECTED]>] | | http://www.debian-administration.org/polls/89 this is hardly surprising. I use both editors. for most sysadmin tasks I use vi(m). for programming i use Emacs. in part out of old habit (most UNIX systems had vi installed) and partly because vi(m) is faster (which makes it more suitable when you just need to change a couple of lines in a file). for programming I use Emacs since I have a gazillion extensions I use while programming that I don't even think about anymore. from various forms of automated text completion to syntax checking/highlighting, to enforcing style guides, look up symbol relationships, compile, debug etc. so if the context was system administration, I'd vote for vi as well. if the context was programming I'd vote Emacs. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | | Being beginner-friendly doesn't have to be at the expense of power or | expert-user usability. depends on your definition of "expert". :-) | On the other hand, being actively beginner-hostile leads to nobody | adopting the tool. Then again, if you don't mind being the last | generation that'll ever use it, then I guess you're okay with that. obviously I lie awake dreading the day this happens. on my tombstone will say "here lies the last Emacs user on earth. M-x rip". -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | | Emacs does have documentation. The problem is you have to already know | a load of emacs navigation oddities^Wkeyboard commands to get to and | use it. that, or just start Emacs and follow the instructions that appear on the screen. indeed, I *am* aware that something demanding an attention span in excess of 3 seconds is a bit of a tall order for most users today. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | | I think it is quite relevant. Clunky computer interfaces may not be so | dramatically dangerous, but they certainly can hamper productivity. | Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix | clunkiness, billions of dollars of potential productivity is lost | worldwide every *month*. bah, UNIX is not user hostile; it is just selective about its friends. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Robert Uhl <[EMAIL PROTECTED]>] | | Why should the ignorant decide? Do you leave the decision of what great | art is to 3 year olds and their doting parents? Do you leave the | decision of what great food is to the ignorant, unwashed, | McDonald's-devouring masses? Why then do you leave the decision of | what's a useful interface to those with insufficient experience? Robert does have a point; however, one needs to take into account that it is very difficult to judge the quality of an interface if it is one that is very familiar to you or if the inner workings are obvious to you. this is why programmers often make bad UI designers: we are intimately familiar with the inner workings, and to us it is okay if the UI is just a thin layer on top of a system we've made. (I'd say the web is a better showcase for this. there seems to be no end to the number of websites that have awkward interaction modes. nor do people seem particularly shy about adding "just one more" thing to an already crowded interface -- because they're blind to the wall of complexity it presents to the occasional user). editors like Emacs is not something which is designed for the casual user, so what the casual user thinks is irrelevant. (also note that the definition of "casual user" has changed). -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Falcolas <[EMAIL PROTECTED]>] | | I took a moment to look at the gui editor which has been made | available to me, and short of the "remove leading spaces" commands, I | do not need to remove my hands from the keyboard if I do not want | to. well, that depends on the editing features you use. I use a lot of features I am not consciously aware of, so if I were to list what I require from an editor, I would have trouble enumerating them. I can't even tell you what keys they are bound to because I just use them instinctively. the same goes for VI. (VI having the added benefit of a really systematic way to organize editing actions into a sort of a matrix (a useful metaphor I was made aware of by an "expert VI user" who showed me how to make some editing operations more efficiently)) having people who are good at efficient editing show you some tricks really pays off btw. I can't bear to watch other people edit text because they are doing so much manual labor that could have been avoided if they had just bothered to learn more effective editing habits. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Martin Gregorie <[EMAIL PROTECTED]>] | | Yep, and the same people think a command line is to be avoided at all | costs. "I mean, its so /last century/ and you can't do anything useful | with it anyway". I have a friend who is a carpenter. he switched to Linux a few years ago because he was tired of how slow windows was and how easily it was infested with malware. he really, really doesn't give a toss what it says on the tin, he's a _user_ and that's it. to my surprise, finds Linux as easy, if not easier to use, than windows. (he still has to use windows for his invoicing system. everything else he does in Linux). I have observed similar opinions in other non-computer-freaks. people who see the computer only as a tool and are only interested in getting the job done. they have a surprising preference for Linux. (not many of them have ever been exposed to OSX though, and I'd suspect they'd prefer that since it is far more streamlined). | Obligatory OT comment: right now I have two xterm sessions open with | which I've been writing a Swing/JDBC app using nowt but a bash shell, | cvs, microEmacs and (of course) J2SE. I don't need no steenking IDE. I used J2SE, Ant, Emacs, Xterm, bash and Firefox as my main tools when I wrote most of my production Java code. and it is not exactly what you'd call "hobbyist projects" either. :-) -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Kaldrenon <[EMAIL PROTECTED]>] | | I don't think anyone can make the argument that any (past or current) | graphics-based editor is as efficient when being used to its fullest | as a text-based editor. It's basic math - it takes measurably more | time to move a hand to the mouse, move/click the mouse, and more the | hand back to the touch-typing position than it does to execute even a | moderately complex series of keystrokes. Maybe not large amounts of | time -per action-, but it doesn't take too long for it to add up if | you spend a lot of time editing. a lot of IDE's are getting quite good and you don't have to mouse around all that much. I think the main reason I stick to Emacs is because I use it for a wider range of tasks -- not just programming. also, the IDE's I've used in the past were sluggish and for some reason the font-rendering was really hard to get right (if at all). when you spend the majority of your waking hours editing text, interactive response time and "editing ergonomics" matter a lot. this reminds me that it is probably time to give IDEs another chance. it has been a couple of years since the last time I tried a couple for Java. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[David Kastrup <[EMAIL PROTECTED]>] | | The idea is to start Emacs once and use it for everything. ...which is fine as long as you are only fiddling around on one machine or you have emacs windows running on all your machines. for my main use, I do start Emacs just once though. for instance at work my Emacs has been running for as long as the machine has been up. | > so if the context was system administration, I'd vote for vi as | > well. if the context was programming I'd vote Emacs. | | You know you can use something like | C-x C-f /su::/etc/fstab RET | (or /sudo::/etc/fstab) in order to edit files as root in a normal | Emacs session? sure, but often it is just simpler, while you are fiddling around in a shell, to just fire up vi to do some quick editing than to bounce back and forth between windows. it is usually quicker too if you have to navigate deep directory trees -- if you're already in the directory where the file is, it'd be fewer keystrokes to specify the file than opening it in emacs. even with tab-completion. also, I make extensive use of the readline and history features when fiddling about in the shell. shells have a lot of context if you use them effectively. context that isn't easy to transport between the shell and emacs -- and it isn't really easy to explain either. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Falcolas <[EMAIL PROTECTED]>] | | I guess ultimately I'm trying to argue the point that just because a | tool was written with a GUI or on Windows does not automatically make | it any less a productive tool than a text based terminal tool. Even in | windows, you can use the keyboard to do all of your work, if you learn | how (thanks to the magic of the alt key). as I see it, the debate isn't whether GUI tools are inferior per se, but whether Emacs is inferior since it has its own interaction concepts that do not map 1:1 to GUI conventions of Windows and OSX. the point I am trying to get across is that Emacs (and vi) is its own niche, and that if you want to improve them, there are more important things than fiddling around with superficial details (like keybindings -- which you can customize to your own liking anyway). for Emacs it would be far more helpful if the Lisp-implementation was replaced with one that is more efficient and Common Lisp-like. (indeed several friends of mine would like to see Emacs done in Common Lisp, and I seem to have some memory of such a project existing somewhere). -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs
[Twisted <[EMAIL PROTECTED]>] | | > I have observed similar opinions in other non-computer-freaks. people | > who see the computer only as a tool and are only interested in getting | > the job done. they have a surprising preference for Linux. | | But not emacs, I'll bet. I think emacs appeals to people who like | dealing with the mechanics of emacs or fiddling with and extending the | darn thing. But most people just want to get the job done, and the | editor or other tools they use have to get out of the way and simply | let them work. no, Emacs is not among the applications they use. nor are any IDEs or compilers. I don't think Emacs is that relevant to these users since what they do is mostly word-processing, spreadsheets, mail and web browsing. Emacs is not really targeted at Word processing as such. (although that doesn't stop some people from thinking that it would be a good idea to turn Emacs into a wordprocessing application with support for graphics, mixed fonts etc.) I use Emacs for creating documents, but this is very different since I use LaTeX and I'm a programmer, so it is very conventient for me to use a system that allows me to treat documents like code (with respect to revision control systems etc). outside academia or the technical community, not that many use LaTeX, but I have seen it in the past. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | | That sort of negative-sum thinking is alien to me. Software being easy | for beginners to get started using does not in and of itself detract | from its value to expert users. the fact that you imply that this is my argument tells me that either you have not paid attention, or you have a raging inferiority complex. given the sum of your postings so far I'd say that you neither are, nor consider yourself, a cerebral sort of person, so this narrows it down somewhat (although not to the exclusion of you not having paid attention). -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | You end up having to memorize the help, because *you can't | have arbitrary parts of the help and your document open side by side | and be working on the document*. All because you can't simply tab or | click to the document. yes you can. you even have a lot of choice as to how you want to do it and it even works on the simplest of text terminals (which is useful when you are on the road and only have a computer with a browser availabe and you've had the foresight to set up the Mindterm SSH applet on a machine so you can log in and edit code from anywhere in the world). I use multiple frames on-screen most of the time. either to edit and view multiple files at once or to edit different locations of the same file. if you're a programmer it is often useful to be able to do this. you can look at more than one file at the same time, have documentation up on screen etc. | At minimum, you have to *memorize* some arcane key controls for | switching panes ... er, "windows", that are totally unintuitive and | unlike what is normally used. following the built-in tutorial in Emacs I understood how to manipulate buffers and split windows in various ways. there are basically three commands you need to know. one of them is used to switch between active buffers in a given window, so it is not specific to splitting. it took me minutes to learn and within days I didn't even think about what I was doing -- I was just using the features. I think you fail to understand the approach. if you know an editor like VI or Emacs properly you have a much bigger bag of tricks, that are applicable to a wide range of scenarios, than what is encouraged by GUI intensive editors. and you don't think of them as "tricks". it is just the way you edit text. | Oops. The interface design is a nightmare. The most basic requirement, | that it be easy to have the help open side by side with your document | and switch back and forth and navigate inside the help easily, is | broken. If you have to consult the help just to navigate the help or | to switch focus between document and help, then you're trapped, and | that is what happens with emacs. why don't you learn Emacs before you say what it can and can't do? it is so frustrating to debate editors with people who haven't even bothered to make a minimal effort to at least spend a day or two learning it. let's look at Word and word processing. how long does it take you to learn Word properly? to understand how to efficiently edit large documents, automate common tasks, use the built-in features for helping you organize documents? -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Robert Uhl <[EMAIL PROTECTED]>] | | Once again I am forced to wonder if you have _ever_ actually used | emacs. find-file has tab completion: hit tab without anything typed, and | it displays _everything_ in the directory; type a few characters to | narrow it down; hit tab to complete the filename and be done with | it. ...and of course, in addition you have access to history so you can easily find previous parameters and edit them. this makes it very efficient when you need to fiddle about in deep directory trees in a way no GUI can yet offer. ...and then there's bookmarking, which is very good for keeping a set of files (and locations) handy for quick access. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | | Really? None of this happens if you just do the straightforward file- | open command, which should obviously at least provide a navigable | directory tree, but definitely does not. well, if you insist on using Emacs in the most clumsy way possible, then of course, not it won't be easy. it is very obvious to any Emacs user that you haven't bothered learning Emacs at all. go away, troll. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Robert Uhl <[EMAIL PROTECTED]>] | | Agreed. Stallman got sidetracked by Scheme, which IMHO was a | dead-end. too many people buying SICP and believing what they heard about it being an important book. I too spent some time exploring Scheme, or should I say, wasted some time, years ago, and nothing came of it other than a profound irritation. these people seemed to be completely disconnected from reality. Scheme, and thus Guile, might have been a viable path if these people had only been practical instead of stubbornly insisting on being odd. | A Common Lisp emacs would be pretty sweet. There's a Climacs project, | but they're just focused on providing an editor, not on providing a | full-fledged emacs. if nothing else, a proper Emacs in Common Lisp might give me a reason to learn Lisp properly. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | On Jun 23, 2:04 am, Robert Uhl <[EMAIL PROTECTED]> wrote: | > Of course, emacs doesn't take years of mastery. It takes 30, 40 | > minutes. | | I gave it twice that, and it failed to grow on me in that amount of | time. then it just wasn't meant to be. stick to Notepad. | If I haven't, it must be the case that finding this tutorial (or even | discovering that it exists) was nontrivial, or it wasn't built into | emacs, one or the other. when Emacs on my machine starts it says the following: Welcome to GNU Emacs, one component of a Linux-based GNU system. Get help C-h (Hold down CTRL and press h) Undo changes C-x u Exit Emacs C-x C-c Get a tutorial C-h t Use Info to read docsC-h i Ordering manuals C-h RET Activate menubar F10 or ESC ` or M-` (`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key. If you have no Meta key, you may instead type ESC followed by the character.) if you haven't found the tutorial, you haven't really tried very hard. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | | and you said that depended on the definition of "expert". Apparently | you believe there is a type of "expert" for whom beginner-friendly | software is intrinsically less usable than beginner-hostile | software. no, I was alluding to you thinking that posession of knowledge which is considered rudimentary basics for Emacs somehow elevates the person in question to an "expert". just because you have not, by your own admission, been able to even locate the built-in tutorial, I don't think your definition of "expert" is very relevant. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
["Kjetil S. Matheussen" <[EMAIL PROTECTED]>] | | Did you expect something specific before starting to read that book? | Thats a failure. SICP is a book you should read just for pure | pleasure. I was told by a lot of people I consider to be intelligent that this book would change how I think about writing software. it didn't. I didn't really know what to expect, but after reading it I did feel that its importance was greatly exaggerated. | > these people seemed to be | > completely disconnected from reality. | | Please don't write things like that without backing it up with some | reason. well, for one, Scheme lacked proper libraries for doing everyday things, so when I tried to use it I found myself writing a lot of library code that I shouldn't have had to deal with. but it is quite long ago, so things might have changed since then. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | | Some people might say the same thing about emacs. A lot of unix tools | even. "Stubbornly insisting on being odd" appears to be a particularly | prevalent character flaw among the geeknoscenti. I think you are missing the point. you may find Emacs (and UNIX) to be odd, and you consistently parade this around as a reason not to even make an honest attempt at understanding how to use it (them). if the oddness still eclipses usefulness once you've made a proper attempt at understanding a tool, then the oddness is a problem. Emacs (and UNIX) don't exhibit these characteristics for a great number of people. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
["Kjetil S. Matheussen" <[EMAIL PROTECTED]>] | | Things have probably changed a little, but the stuff in SISC isn't | specific for scheme, although a schemish language is used in the book. well, those are really two separate discussions: Scheme and whether SICP is an important book or not. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: terminology buffer and keybinding
[Twisted <[EMAIL PROTECTED]>] | | Translation: since perfection is unattainable, we shouldn't even try, | and just foist upon our poor users whatever awkward and hard-to-learn | interface pops into our heads first? uh, I think the point here is that some think it might be an idea to force *their* idea of the ideal interface upon others, refusing to understand that people might have their own preferences. -Bjørn -- http://mail.python.org/mailman/listinfo/python-list
script won't run using cron.d or crontab
I appologize if this been discussed previously. If so, just point me to that information. I have done a fair bit of digging, but I haven't found a description of what to actually do. I have a fairly lengthy script that I am able to run without any problems from a shell. My problem is, now I am wanting to get it running using crontab or cron.d. It seems that running it this way there is a problem with some of the commands that I am using. For instance "commands.getoutput" or " os.access". I am assuming that there is something missing within the environment that cron runs that fails to allow these commands to run. If anyone has any information that would help, it would be greatly appreciated. -- Have a GREAT day!!! Bjorn -- http://mail.python.org/mailman/listinfo/python-list
Re: script won't run using cron.d or crontab
Thank you for your reply. This is pretty much what I found from my digging around. I asume this can still be done. Is there an easy way to determine what needs to be added to the environment? Bjorn On Fri, Mar 21, 2008 at 2:01 AM, Robert Bossy <[EMAIL PROTECTED]> wrote: > Bjorn Meyer wrote: > > I appologize if this been discussed previously. If so, just point me > > to that information. > > > > I have done a fair bit of digging, but I haven't found a description > > of what to actually do. > > > > I have a fairly lengthy script that I am able to run without any > > problems from a shell. My problem is, now I am wanting to get it > > running using crontab or cron.d. It seems that running it this way > > there is a problem with some of the commands that I am using. For > > instance "commands.getoutput" or "os.access". I am assuming that there > > is something missing within the environment that cron runs that fails > > to allow these commands to run. > > If anyone has any information that would help, it would be greatly > > appreciated. > Hi, > > From a shell, type: >man 5 crontab > and read carefully. You'll realize that a croned script does not inherit > from the user shell's environment. > > Cheers, > RB > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
multiprocessing and dictionaries
I am trying to convert a piece of code that I am using the thread module with to the multiprocessing module. The way that I have it set up is a chunk of code reads a text file and assigns a dictionary key multiple values from the text file. I am using locks to write the values to the dictionary. The way that the values are written is as follows: mydict.setdefault(key, []).append(value) The problem that I have run into is that using multiprocessing, the key gets set, but the values don't get appended. I've even tried the Manager().dict() option, but it doesn't seem to work. Is this not supported at this time or am I missing something? Thanks in advance. Bjorn -- http://mail.python.org/mailman/listinfo/python-list
Re: multiprocessing and dictionaries
On Monday 13 July 2009 01:56:08 Piet van Oostrum wrote:
> >>>>> Bjorn Meyer (BM) wrote:
> >
> >BM> I am trying to convert a piece of code that I am using the thread
> > module with BM> to the multiprocessing module.
> >
> >BM> The way that I have it set up is a chunk of code reads a text file and
> > assigns BM> a dictionary key multiple values from the text file. I am
> > using locks to write BM> the values to the dictionary.
> >BM> The way that the values are written is as follows:
> >BM> mydict.setdefault(key, []).append(value)
> >
> >BM> The problem that I have run into is that using multiprocessing, the
> > key gets BM> set, but the values don't get appended.
> >BM> I've even tried the Manager().dict() option, but it doesn't seem to
> > work.
> >
> >BM> Is this not supported at this time or am I missing something?
>
> I think you should give more information. Try to make a *minimal* program
> that shows the problem and include it in your posting or supply a
> download link.
> --
> Piet van Oostrum
> URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
> Private email: p...@vanoostrum.org
Here is what I have been using as a test.
This pretty much mimics what I am trying to do.
I put both threading and multiprocessing in the example which shows the output
that I am looking for.
#!/usr/bin/env python
import threading
from multiprocessing import Manager, Process
name = ('test1','test2','test3')
data1 = ('dat1','dat2','dat3')
data2 = ('datA','datB','datC')
def thread_test(name,data1,data2, d):
for nam in name:
for num in range(0,3):
d.setdefault(nam, []).append(data1[num])
d.setdefault(nam, []).append(data2[num])
print 'Thread test dict:',d
def multiprocess_test(name,data1,data2, mydict):
for nam in name:
for num in range(0,3):
mydict.setdefault(nam, []).append(data1[num])
mydict.setdefault(nam, []).append(data2[num])
print 'Multiprocess test dic:',mydict
if __name__ == '__main__':
mgr = Manager()
md = mgr.dict()
d = {}
m = Process(target=multiprocess_test, args=(name,data1,data2,md))
m.start()
t = threading.Thread(target=thread_test, args=(name,data1,data2,d))
t.start()
m.join()
t.join()
print 'Thread test:',d
print 'Multiprocess test:',md
Thanks
Bjorn
--
http://mail.python.org/mailman/listinfo/python-list
Re: multiprocessing and dictionaries
On Monday 13 July 2009 13:12:18 Piet van Oostrum wrote:
> >>>>> Bjorn Meyer (BM) wrote:
> >
> >BM> Here is what I have been using as a test.
> >BM> This pretty much mimics what I am trying to do.
> >BM> I put both threading and multiprocessing in the example which shows
> >BM> the output that I am looking for.
> >
> >BM> #!/usr/bin/env python
> >
> >BM> import threading
> >BM> from multiprocessing import Manager, Process
> >
> >BM> name = ('test1','test2','test3')
> >BM> data1 = ('dat1','dat2','dat3')
> >BM> data2 = ('datA','datB','datC')
>
> [snip]
>
> >BM> def multiprocess_test(name,data1,data2, mydict):
> >BM> for nam in name:
> >BM> for num in range(0,3):
> >BM> mydict.setdefault(nam, []).append(data1[num])
> >BM> mydict.setdefault(nam, []).append(data2[num])
> >BM> print 'Multiprocess test dic:',mydict
>
> I guess what's happening is this:
>
> d.setdefault(nam, []) returns a list, initially an empty list ([]). This
> list gets appended to. However, this list is a local list in the
> multi-process_test Process, therefore the result is not reflected in the
> original list inside the manager. Therefore all your updates get lost.
> You will have to do operations directly on the dictionary itself, not on
> any intermediary objects. Of course with the threading the situation is
> different as all operations are local.
>
> This works:
>
> def multiprocess_test(name,data1,data2, mydict):
> print name, data1, data2
> for nam in name:
> for num in range(0,3):
> mydict.setdefault(nam, [])
> mydict[nam] += [data1[num]]
> mydict[nam] += [data2[num]]
> print 'Multiprocess test dic:',mydict
>
> If you have more than one process operating on the dictionary
> simultaneously you have to beware of race conditions!!
> --
> Piet van Oostrum
> URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
> Private email: p...@vanoostrum.org
Excellent. That works perfectly.
Thank you for your response Piet.
Bjorn
--
http://mail.python.org/mailman/listinfo/python-list
