Re: Pep 342 (val = yield MyGenerator(foo)), synchronous os.system() that doesn't block gui event loops
On Jul 23, 11:29 pm, Nick Craig-Wood n...@craig-wood.com wrote: The syntax would be something like: def work(): showstatus(building) r = yield runshell(make) showstatus(installing) r = yield runshell(make install) showstatus(Success) mygui.startwork(work) # returns immediately, runs work() gradually in the background. The catch is that showstatus() would need to be run in the mainloop, so running the whole thing in a thread is a no-go. I imagine runshell() would be implemented in terms of QProcess, or subprocess.Popen/os.system and a worker thread. Anyone done this already, or do I have to roll my own? You might want to look at twisted, in particular http://twistedmatrix.com/trac/wiki/DeferredGenerator Indeed, DeferredGenerator looks pretty much what I'm interested in, thanks for the pointer. Unfortunately, it has the big Twisted dependency. That's probably not a showstopper, but Twisted requires a degree of buy-in when something smaller would do. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 342 (val = yield MyGenerator(foo)), synchronous os.system() that doesn't block gui event loops
Apologies for the long subject line, here it is again: Pep 342 (val = yield MyGenerator(foo)), synchronous os.system() that doesn't block gui event loops On Jul 21, 7:48 pm, John Nagle na...@animats.com wrote: The idea: To run functions that execute a series of system commands without blocking the ui, *and* without adding state machine logic. At some level, there's going to be state machine logic. You need interlocking so that the user can't initiate simultaneous conflicting background operations from the GUI. This belongs to the I don't care category, as you'd expect to have only one operation like this on the flight at one time. The idea is to allow making simple scripts that you execute from the gui, that *may* need to access the gui objects at one point or another (so execution has to happen in the main thread most of the time - apart from blocking, long operations). The usual solution is to run the background operations in another thread, and have them put events on a queue read by the GUI task. Yeah, and the receiving end of the queue here would be the same block of statements that launched the request - that is, I want to avoid having to create handler functions, and keep the program from linear. You also have to work out how to cancel background operations, if they're going to be as big as a make. I think that is easy to accomplish with generators, provided that you can let the long-lasting operation run to completion - just close() the generator. If the long lasting computation was in a subprocess, rather than a thread, it could be interrupted in a cleaner fashion even. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 342 (val = yield MyGenerator(foo)), synchronous os.system() that doesn't block gui event loops
On Jul 20, 1:12 pm, Ville Vainio vivai...@gmail.com wrote: Has anyone implementing something like what the subject line ImplentED. I don't think this is that hard to do in the first place, but a generic solution that can be easily tuned for different gui mainloops would be nice. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 342 (val = yield MyGenerator(foo)), synchronous os.system() that doesn't block gui event loops
On Jul 20, 1:12 pm, Ville Vainio vivai...@gmail.com wrote:
I imagine runshell() would be implemented in terms of QProcess, or
subprocess.Popen/os.system and a worker thread.
Actually, the problem is that of general serialization of worker
thread operations. That is, it could be something akin to:
res = yield run_in_thread(lambda : os.system('make'))
run_in_thread would basically grab a worked thread, execute the
callable, and allow the generator to proceed after the thread is done.
Now, the only thing to do is the generator dispatcher in gui
mainloop that finds the correct generator and makes it proceed...
--
http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Leo 4.6 rc1 released
On Jul 10, 9:54 pm, Edward K Ream edream...@charter.net wrote: The highlights of Leo 4.6: -- - Leo now features a modern Qt interface by default. Leo's legacy Tk interface can also be used. And to drive home this point (Qt ui), some screenshots for the visually oriented: http://imgbin.org/images/625.png http://imgbin.org/images/626.png http://imgbin.org/images/627.png -- http://mail.python.org/mailman/listinfo/python-list
Re: Chandler, Python, speed
Ville M. Vainio wrote: Alan G Isaac wrote: 3. Chandler is not really an email client. So specifically, which of its functionalities is it slow, and what evidence if any is there that Python is causing this? I remember reading somewhere that the cause of slowness is/was architectural - perhaps it was that chandler was persisting too much stuff to disk, or something. In any case, this might help you google for more detail. Here's the somewhere: http://blog.chandlerproject.org/2008/05/21/rick-rawson-on-why-i-use-chandler-and-what-would-make-me-stop/ QQQ Alex, you’re right that VM usage is a big factor, although there are cases where the CPU is doing too much, too. So far as why this is, there are many contributions. The biggest one is that architectural decisions taken early on in the project meant that way too much data is being persisted. For example, the app persists all schema and GUI layout information, leading to on-disk and mapped memory bloat. (There is also redundancy in the data stored on disk that leads to more of this kind of bloat). QQQ -- http://mail.python.org/mailman/listinfo/python-list
Re: Email Program
J wrote: Is it possible to make a GUI email program in Python that stores emails, composes, ect? Here's one with less than 600 lines: http://code.google.com/p/pyqtimap/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Chandler, Python, speed
Alan G Isaac wrote: 3. Chandler is not really an email client. So specifically, which of its functionalities is it slow, and what evidence if any is there that Python is causing this? I remember reading somewhere that the cause of slowness is/was architectural - perhaps it was that chandler was persisting too much stuff to disk, or something. In any case, this might help you google for more detail. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python equivalent for C module
Vinay Sajip [EMAIL PROTECTED] writes: import logging logging.warning(Message with %s data, variable) # or debug, info, error and I'd like to know what simpler interface you think would be better/ easier to grok for quick hack jobs. It's not the logging itself that is a problem, it's setting up the loggers that was nontrivial (back in the day I last tried it). Some googling revealed what was my problem back in 2004: http://coding.derkeiler.com/Archive/Python/comp.lang.python/2004-10/3714.html I do realize the technical problems of coming up with one-size-fits-all solution for a problem domain like this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing for Python (2.x or 3)?
Paulo J. Matos [EMAIL PROTECTED] writes: I am in the process of choosing which Python version for a brand new application. Van Rossum in an interview recently advised all new applications to use Python3 but I am afraid, most libraries (PyGtk, I don't think he meant all new applications, bit rather when you are about to embark on a new thing that will take a while to build (new django? ;-). PyQt, Networking Libs, etc) won't follow suit to 3.0 and I will end up using a version of the language which can't connect to libraries because they haven't been ported yet. I'd expect the libs to catch up quite quickly, bit I'd still not do an end-user app in 3.0 yet. 2.6, using 3.0 comatibility features is your best bet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Commercial Products in Python
Paulo J. Matos [EMAIL PROTECTED] writes: Hi all, I was just wondering, if you wish to commercialize an application developed in Python, what's the way to go? I guess the only way is to sell the source, right? That should be a good way to go about it. It doesn't make it open source, you can still bundle the source with a cut-throat license that does not allow derived products. 1) You can't sell an executable because Python doesn't compile to native code (the usual approach, afaik); You can sell py2exe:d package for windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python equivalent for C module
Bruno Desthuilliers [EMAIL PROTECTED] writes: STDOUT is for *normal* program outputs. Debug informations, warnings, and all verbosity should go to STDERR. Actually, stderr is for errors, by convention. It's rather impolite to dump trivial debug info to stderr, which often alerts the user more than stdout. Also and FWIW, Python has a logging module in it's stdlib. Please use it instead of any half-backed squared-wheel homegrown solution. Unfortunately these square-wheeled homegrown solutions are easier to grok than the standard logging module. It seems to target more serious applications at the cost of feeling a bit too clunky for quick hack jobs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Porting VB apps to Python for Window / Linux use
Stef Mientki [EMAIL PROTECTED] writes: Sorry but for GUI design, Python is pre-historic ;-) Time to show the don't feed the troll sign, I guess. Even without the smiley, I'm convinced of my statement. cheers, I don't think I'm feeding the troll, but - ever took a look at PyQt? -- http://mail.python.org/mailman/listinfo/python-list
How to run PyOS_InputHook from python code (i.e. yield to event loops)
Background: PyOS_InputHook is something that gets run when python is
doing raw_input. TkInter and friends use it to run their event loops,
so that their events are handled while python is doing raw_input.
What I'd like to do is run the same function without having to do
raw_input. I.e. I'd like to run whatever event loop is available,
without incorporating any gui-specific code (PyOS_InputHook seems like
a nifty way to accomplish this).
My actual use case is to keep a tkinter application responsive while
launching a background process (and waiting for it to complete!).
My eventual code would be something like:
launch_process_in_thread('bzr pull')
while not is_done:
pyos_inputhook()
time.sleep(0.1)
print Done!
--
http://mail.python.org/mailman/listinfo/python-list
ANN: IPython 0.8.3 is out
Hi all, The IPython team is happy to release version 0.8.3, with lots of new enhancements as well as many bug fixes, and updated documentation that has been long in the coming. We hope you all enjoy it, and please report any problems as usual. WHAT is IPython? 1. An interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. An embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. A flexible framework which can be used as the base environment for other systems with Python as the underlying language. 4. A shell for interactive usage of threaded graphical toolkits. IPython has support for interactive, non-blocking control of GTK, Qt and WX applications via special threading flags. The normal Python shell can only do this for Tkinter applications. Where to get it --- IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist We've provided: - Source download (.tar.gz) - A Python Egg (http://peak.telecommunity.com/DevCenter/PythonEggs). - A native win32 installer. - rpm's Note that win32 users also need to get pyreadline, available at the same download site (http://ipython.scipy.org/dist). You should also read of additional considerations at http://ipython.scipy.org/moin/IpythonOnWindows We note that IPython is now officially part of most major Linux and BSD distributions, so packages for this version should be coming soon, as the respective maintainers have the time to follow their packaging procedures. Many thanks to Jack Moffit, Norbert Tretkowski, Andrea Riciputi, Dryice Liu and Will Maier for the packaging work, which helps users get IPython more conveniently. Many thanks to Enthought for their continued hosting support for IPython. Release notes - See http://ipython.scipy.org/moin/WhatsNew083 for notable new features in this release. Enjoy, and as usual please report any problems. The IPython team. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Fuzzyman [EMAIL PROTECTED] writes: Perhaps a lint-like validation tool would be optimal for this problem... So we can refuse to execute their code if they use private APIs? No, but it could complain and point out the exact offending lines, pointing their development effort to right direction. Proxying so that we can really hide our internal APIs is a better solution. How about pyprotocols and other interface packages? Proxying is pretty workable too, and it easily makes sense that the official API objects should be different from the logic executing objects. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Duncan Booth [EMAIL PROTECTED] writes: Or if you code in C++ and they *really* need to get at something you made private they will still get at it. I've been there and done that: 'private' in languages which have it is rarely an advantage and frequently a pain. Indeed. In C++, they recommend the pimpl idiom (private implementation), which actually has real advantages ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Storing objects in relational database
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: I don't know if you'd label it 'elegant', but as far as I'm concerned, storing serialized objects as blobs in a relational database is mostly non-sense. If I use a relational database, it's because it is a *relational* database. If you want an OODB, then we have the ZODB, Durus and a couple others. ... not to forget object-relational mappers like SQLAlchemy, SQLObject... -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Fuzzyman [EMAIL PROTECTED] writes: The 'we told you not to use that' approach, when applied to paying customers doesn't really work... all they see is that you broke their spreadsheet code by changing your API. And the customer point of view is quite reasonable - they have a job to do, and a limited timeframe; sometimes accessing privates directly is much better than waiting for updates from vendor. Bad designs (as far as choosing publics goes) happen. Even if their softare breaks on upgrade, you can quite clearly point out that they used an internal api - and they will keep on using the old version until they solve the problem. Everybody wins. Perhaps a lint-like validation tool would be optimal for this problem... -- http://mail.python.org/mailman/listinfo/python-list
Re: feature proposal, debug on exception
Simon Forman [EMAIL PROTECTED] writes: This is not exactly an answer to your proposal, I know, but FWIW Ipython has exactly this capability. Yes. When you %run a scripts and get exception, you can launch post-mortem pdb on it by typing %debug. -- http://mail.python.org/mailman/listinfo/python-list
Re: Shelve or pickle module
Gabriel Genellina [EMAIL PROTECTED] writes: A shelve is just a persistent dictionary that uses pickle to store the objects. If you want to store one or a few objects, using pickle directly may be easier. Any problem you may have with pickle (nonpickleable objects, security risks) will happen with shelve too. Shameless plug warning! If you want to store pickles directly in a directory with shelve-like dict API, you may also be interested in my pickleshare module: http://pypi.python.org/pypi/pickleshare/0.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: datamining .txt-files, library?
Chris [EMAIL PROTECTED] writes: On May 15, 2:27 pm, globalrev [EMAIL PROTECTED] wrote: i have a big collection of .txt files that i want to open and parse to extract information. is there a library for this or maybe even built in? os.open to open the files and iterate through it and built in string functions to parse it. Or more probably, regular expression library re. -- http://mail.python.org/mailman/listinfo/python-list
Re: portable way to tell what Popen will call
Brendan Miller [EMAIL PROTECTED] writes: For instance on unix systems, Popen will work for files flagged with the executable bit, whereas on windows Popen will work on files ending the in .exe extension (and I don't think anything else). Is there a portable way Actually, if you pass the use_shell = 1 argument to Popen, it will launch the process using a shell - that is, what you expect to work in a shell (and consequently os.system()) will work. to check what Popen will work on without actually execute it? Do I have to write a bunch of platform specific code here? Unfortunately, you'll probably need to write platform specific kludges for this. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs. grep
Ricardo Aráoz [EMAIL PROTECTED] writes: The easy/simple (too easy/simple?) way I see out of it is to read THE WHOLE file into memory and don't worry. But what if the file is too The easiest and simplest approach is often the best with Python. Reading in the whole file is rarely too heavy, and you omit the python object overhead entirely - all the code executes in the fast C extensions. If the file is too big, you might want to look up mmap: http://effbot.org/librarybook/mmap.htm -- http://mail.python.org/mailman/listinfo/python-list
Re: observer pattern (notification chain synchronization)
Alan Isaac [EMAIL PROTECTED] writes: Here is one way: - for each fund, create a ``reportreceived`` dict that maps stocks to booleans (initially False) - as each stock notifies its funds, the fund changes False to True and checks ``all(reportreceived.values())`` to determine whether it is ok to notify investors. - When it is ok, the fund notifies investors and resets all the ``reportreceived`` values. Is this sensible enough? What are standard and better ways? You could explore the performance of popping items from the dict/set, instead of toggling the value so to true. Once the dict is empty, you are done. Of course the dict/set would be called stocks_that_havent_reported, or a saner shorter variant of that. The idea here is that checking a dict/set for emptiness is close-to-zero time operation. -- http://mail.python.org/mailman/listinfo/python-list
Re: observer pattern (notification chain synchronization)
Alan Isaac [EMAIL PROTECTED] writes: OK, thanks. Another approach is to begin with a set of stocks and remove them as they report. You can then trigger a report with the empty set instead of repeatedly calling ``all``. After a report the set can be refilled. Ah, and I obviously didn't read the whole thread before posting ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: File Creation Not Working In A Thread Class?
bc90021 [EMAIL PROTECTED] writes: The error message was at the top of the thread (am I incapable of posting it, or are you incapable of following a thread?), but here it is again: IOError: [Errno 2] no such file u'tempfileName' Typically, when you report an error message, it helps to paste the whole traceback. For example, it may be that you are seeing an error from an old version of the file that has quotes around tempfileName, or the error is coming from somewhere else. But to answer your original question: no, there are no problems with threading and files, and this is just simple human mistake somewhere. -- http://mail.python.org/mailman/listinfo/python-list
Re: observer pattern question #1 (reference to subject)
Alan Isaac [EMAIL PROTECTED] writes: Is anything lost by not maintaining this reference (other than error checking ...)? If I feel the observer needs access to the subject, what is wrong with just having the subject pass itself as part of the notification? It reduces the number of places the observer can be called from, because now the event source is part of the function signature. If you omit the event source in the signature, you gain looser coupling - it's the observer business to create the dependency. Also, consider the situation where you want all investors to refresh their idea about stock prices (because of, short network failure). It's easy to run through a list of them and call update() for everybody, while it's not so easy to find out what stock the investor is observing (that's the investors business!) and pass that object to the investor in the call. Are these school questions btw? ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: observer pattern question #1 (reference to subject)
Alan Isaac [EMAIL PROTECTED] writes: the following: OK, here's the pattern, now your listener wants to know the event source, do not ask something new the subject to respond to that need. That is unnecessary coupling. Instead, just rewrite your listener to maintain a reference to the subject. Do I have that right? Not really. It has to be determined case-by-case. Note that I'm not arguing *for* not passing subject on notification, just trying to elaborate on situations that might want to choose that route. It seems to me that this response begs the question. That is, an appropriate reply seems to be: here is a related pattern, call it observer2. In the observer2 pattern, the subject has a getState method and always passes itself when it notifies the observer. Now: in what sense does this require closer coupling? It creates stronger connection between the subject and observer, thereby reducing the amount different of places that can call the observer (I don't mean different stock, but altogether different places - say, a central stock controller that can broadcast the change in several stocks at the time by stock id, once per second). This is not really a feature of the observer pattern, both approaches are somewhat valid observer patterns, depending on problem domain. If you think it makes sense in the first place to have ONE reference to the subject in observer, it's probably a workable approach - but in case of stocks, you are probably monitoring several stock objects, so the stock should probably pass itself to the observer (so that you don't need to check all stocks every time something changes!). Of course this stock thing is a bad example for this case, because you have several stocks per investor. It's analogous to a typical UI scenario where you have several widgets forwarding events to one big observer - and they *do* provide the event source and event type. Or to put it a different way, your suggestion that the investors should have to *pull* this information from the stocks seems out of step with the observer pattern, where the stocks should be pushing this information to the investor. It's not necessarily the observer that has the interesting information. It's quite typical to have general catch-all notifications than report observers that something has chanced somewhere, so you should refresh your data. All in all, though, the right solution should be obvious from the problem at hand. -- http://mail.python.org/mailman/listinfo/python-list
Re: License selection for free software
Paul Boddie [EMAIL PROTECTED] writes: original licence as well. Now, I did leave a fair amount of information about the heritage of the code, so that anyone who is scared of the LGPL could just go and get the original work, but that I doubt anyone is really afraid of LGPL. The only problem with LGPL is that of static vs. dynamic linking, and that is only a problem in platforms without dynamic linker (rarity these days). You can almost never just grab the code from somewhere without having to think about [the] license since even permissive licences typically have a list of conditions that must be observed. Certainly, they Yeah, but you don't have to worry about license - just have the license text in source code, or a text file in binary distribution. -- http://mail.python.org/mailman/listinfo/python-list
Re: License selection for free software
Excuse the long post. Ben Finney [EMAIL PROTECTED] writes: I guess it's safe to assume that you are not opposed to using code based on more liberal license, right? :-) I'm less inclined to base work on, or contribute to, a work under a non-copyleft license, because I have less assurance that the code will remain free for all recipients. In practice, the probability of hijacking of source code by an evil corporation is very low for most projects. And even when it did happen, the evil corporation would likely submit patches. The more users an open source project has, the better. Also, you can do what Paul Boddie did - fork the project, or maintain patches that are under LGPL. With a liberal license, you have that privilege. There's no single free-software license that won't displease some segment of the free-software community. I think the Vellum project I don't think BSD/MIT like license really annoys anyone. Think python here ;-) I'm also answering some points by Zed here (assuming they were meant for mailing list): Well, I'm also telling people that it's like the GNU toolchain in that using it doesn't mean your stuff is GPLed. Just if you import it as a library or write commands for it that you release. I realize this - there is a difference here between tools that you run and tools that you link to / import. However, Vellum could be in the middle ground, since the commands you create do link with Vellum. Ok, so for you it's a religious thing more than a technical capability or limitation thing? Does that mean you use a BSD alternative for everything GNU, like GCC as well? Not at all, it's a very practical thing related to all the intellectual property lawyerage in corporate setting. With Vellum, it doesn't matter a lot because most of the tools are only used in-house, but it would still be nice if you could just grab the code from somewhere without having to think about license at all, or considering whether any of this would ever be needed for something that involves selling stuff under proprietary license. To stay on topic of Vellum, let's consider the scenario where someone digged Vellum's syntax, and would like to use the parser in a proprietary app - or create commands that include proprietary stuff (it's not the developer's call, but the corporate policy). Vellum parser would be only a small component in the whole system. Would you rather make the developer: - Find some other, inferior parser with more liberal license or reimplement Vellum syntax from spec (typical nah, this is gpl, I can't use this, continue with the next google hit scenario) - Just grab the Vellum implementation and use it without concern or management discussions, yielding yet another developer that saved some time, had more coffee breaks and possibly hit the deadline early, recommending Vellum code to his colleagues as a good starting point to whatever they are doing, and perhaps contributing some code or ideas back? Note that this applies mostly to small tools / libs. Big projects like Linux kernel, Gnome or KDE have to be seriously concerned about malicious use of their intellectual property, but a small open source tool is more likely to be (initially) picked up by an individual developer who thinks something is cool; and it will never be the money-making part of the product. Also, for some reason, GPL is used for evil (dual-licensing schemes - make money but still gain the open source mindshare, and possibly rack up free contributions to something that is your *commercial product*) more often than it's used for good (gcc, Linux kernel - prevent IP exploitation and ensure that all improvements are freely accessible). I must say that if I implemented something I want to make money on at some point, I would license it under GPL. If I'm just scratching my own itch, having fun or racking up open source feelgood karma, I would use MIT (or BSD, as we are doing w/ IPython). So I'm not opposed to GPL - just saying that it's not often the choice that will net you the most users. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python application distribution
ron.longo wrote: unable to execute. Why is this? At this point I'm not really keen on handing out the source files to my application, it feels unprofessional. If you plan to deploy on windows, py2exe could be the more professional approach you are thinking of. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python application distribution
ron.longo wrote: unable to execute. Why is this? At this point I'm not really keen on handing out the source files to my application, it feels unprofessional. If you plan to deploy on windows, py2exe could be the more professional approach you are thinking of. -- http://mail.python.org/mailman/listinfo/python-list
Re: ]ANN[ Vellum 0.16: Lots Of Documentation and Watching
Zed A. Shaw [EMAIL PROTECTED] writes: GPLv3? How do people feel about Vellum's GPLv3 status? It actually doesn't impact anyone unless you embed Vellum into a project/product or you Yeah, but it effectively prevents people from embedding it into their apps that wish to remain BSD/MIT clean. It's not likely that some evil corporation is going to hijack Vellum source code as a basis of their next evil app (which is basically what GPL is used to prevent) any time soon, so I don't really see a particular reason for such a developer-oriented tool to be released under GPL. Basically, avoiding GPL maximizes the brainshare that a small-ish tool is going to attract, and many (including myself, FWIW) view GPL as a big turn-off when I consider spending some time to familiarize myself with a tool, or recommending it to someone else. -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Vellum 0.16: Lots Of Documentation and Watching
[EMAIL PROTECTED] writes: I didn't find your language offensive but you might consider toning down your review of the Awesome Window Manager :) Nah - keep up the bad attitude. Your (Zed) blog/articles are one of the few things on the programmosphere that actually make me laugh audibly. -- http://mail.python.org/mailman/listinfo/python-list
Re: ISBN Barecode reader in Python?
Max Erickson [EMAIL PROTECTED] writes: The killer application for ISBN lookup on Amazon is checking prices while in the bookstore. Being able to email a photo from your phone and then getting an email with the Amazon price in response would be way easier than typing the isbn into Google or whatever. Yeah, or just create a S60 python app to do it directly. Basically, just put up a web service somewhere that allows pushing an image of the barcode and returns the lowest price for that item, and the PyS60 app will be done in a day. -- http://mail.python.org/mailman/listinfo/python-list
Re: ]ANN[ Vellum 0.16: Lots Of Documentation and Watching
Paul Boddie [EMAIL PROTECTED] writes: Anyway, I'm just confirming that I'm clearly not one of the many described above. A lot of my own work is licensed under the GPL or I guess it's safe to assume that you are not opposed to using code based on more liberal license, right? :-) My point is: GPL is a reason to reject a tool for some, but MIT/BSD never is. Ultimately, of course, it's up to the preferences of the author but if the idea is to maximize the popularity, GPL is a worse bet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python make like tools (was Re: [ANN] DoIt 0.1.0 Released (build tool))
Eduardo Schettino wrote:
I find the doit syntax a bit cumbersome, especially as you can avoid
'args' by just returning a lamda in 'action'.
My idea was to: do *not* add any new syntax (to avoid being
cumbersome). It is just python, you dont have to import or subclass
Yeah, decorators get around this.
I though about using decorators in the beginning... but returning a
dictionary looked easier to implement and more flexible. one important
feature is how easy to define a group of task with the same action.
Take a look at the example below on running pychecker in all python
files from a folder. I couldnt figure out an easy way of doing it with
decorators.
import glob;
pyFiles = glob.glob('*.py')
def task_checker():
for f in pyFiles:
yield {'action': pychecker %s% f,
'name':f,
'dependencies':(f,)}
Perhaps you could do:
for f in pyFiles:
@task(checker)
@depend(f)
def check():
c(pychecker %s % f)
Never underestimate the magic that is nested scopes and name-agnostic
function object creation...
Another advantage of using just a dictionary to define a task is that
it will be easy to read tasks from a text file (if it is very simple
and you dont need to write any python script). but not implemented
yet.
It is easy with the above syntax as well.
I though about using decorator for simple python-tasks but in a different way:
@task
def create_folder(path):
Create folder given by path if it doesnt exist
if not os.path.exists(path):
os.mkdir(path)
return True
so if your python function is a task and you will use it only once you
dont need to define a function for the 'action' and another function
to create the task. but not implement yet also.
Yeah, this is what I consider much friendlier syntax (the aim is to not
be much more verbose than make).
apart from one .py file installation (easy_install is not enough?)
thats what i am trying to do.
easy_install is not really enough - it introduces a dependency that you
can't get around by just shipping a short .py file with your project.
This problem domain seems simple enough that it should be covered by a
very short and simple module (Paul, the Waf you suggested was ~ 300k, no
doubt caused by all the c compiler stuff that I don't need).
'Paver' seems to have the right idea:
http://www.blueskyonmars.com/projects/paver/index.html
But it's still *slightly* too big:
http://bazaar.launchpad.net/~dangoor/paver/main/files
--
http://mail.python.org/mailman/listinfo/python-list
Re: Unix Device File Emulation
blaine wrote: example usage: echo 'line 0 0 10 10' /dev/screen On the actual embedded device this is handled by a kernel module. We can spit commands into it as fast as we can and the kernel module can keep up. This is typical unix device file behavior. Any suggestions or advice would be splendid. Thanks! Assuming you are on unix, have you considered FIFO's, os.mkfifo()? -- http://mail.python.org/mailman/listinfo/python-list
Python make like tools (was Re: [ANN] DoIt 0.1.0 Released (build tool))
Eduardo Schettino wrote:
DoIt is a build tool that focus not only on making/building things but on
executing any kind of tasks in an efficient way. Designed to be easy to use
and get out of your way.
I took a look at dolt syntax, and saw this:
QQQ
def create_folder(path):
Create folder given by path if it doesnt exist
if not os.path.exists(path):
os.mkdir(path)
return True
def task_create_build_folder():
buildFolder = jsPath + build
return {'action':create_folder,
'args': (buildFolder,)
}
QQQ
Wouldn't it be more convenient to provide syntax like this:
@task(create_build_folder)
@depend(dep1 some_other_dep)
def buildf():
buildFolder = jsPath + build
create_folder(buildFolder)
I find the doit syntax a bit cumbersome, especially as you can avoid
'args' by just returning a lamda in 'action'.
I've looked around a bit for python make replacement, but there does
not seem to be a simple straightforward solution around (read -
straight-python syntax, one .py file installation, friendly license).
--
http://mail.python.org/mailman/listinfo/python-list
