Pep 342 (val = yield MyGenerator(foo)), synchronous os.system() that doesn't block gui event loops
Has anyone implementing something like what the subject line
indicates?
The idea:
To run functions that execute a series of system commands without
blocking the ui, *and* without adding state machine logic.
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?
--
http://mail.python.org/mailman/listinfo/python-list
Re: LGPL license for Qt 4.5
On Jan 14, 2:57 pm, sturlamolden wrote: > According to a Norwegian publication, Nokia will release Qt under LGPL > as of version 4.5. > > If I had stocks in Riverbank Computing ltd., I would sell them now... Isn't that a tad thankless and premature? It may be that the "support" aspect needs to be emphasized (currently, the paying customers get a priority over non-paying customers, but there are no formal support contracts), but if we assume that the usage of Qt & PyQt in commercial setting is going to skyrocket (I'd wager that it's a pretty safe assumption), selling plain support could prove very profitable as well - esp. since most PyQt users probably won't be too eager to start messing with SIP & fiddling around with Qt C++ plumbing. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs. grep
On May 8, 8:11 pm, Ricardo Aráoz <[EMAIL PROTECTED]> wrote: > All these examples assume your regular expression will not span multiple > lines, but this can easily be the case. How would you process the file > with regular expressions that span multiple lines? re.findall/ finditer, as I said earlier. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs. grep
On May 6, 10:42 pm, Anton Slesarev <[EMAIL PROTECTED]> wrote: > flines = (line for line in f if pat.search(line)) What about re.findall() / re.finditer() for the whole file contents? -- http://mail.python.org/mailman/listinfo/python-list
Re: ]ANN[ Vellum 0.16: Lots Of Documentation and Watching
On May 6, 11:27 pm, hdante <[EMAIL PROTECTED]> wrote: > GPL can mix with other free software licenses, so people who write > BSD code and do not wish to remain BSD clean are free to use GPL'd > code. That's the important point. No, it can't. It can only mix through aggregation, i.e. you can ship a GPL'd "plugin" with BSD code as long as you don't import the plugin directly. Here's a real life example from ipython: - Core IPython is BSD clean, and we intend to leave it that way - If we imported a gpl'd module in some core ipython component, the core component would be gpl (or something equally restrictive) as well, through viral nature of the license - Now, if you want a BSD-clean version of ipython (say, to embed it in a commercial program - with which I have absolutely *no* problem, and can only see good things coming from it), you would have to gleam out all the uses of that module from the source code. Not very fun, esp. if it's something important - There is a GPL'd module in "extensions" folder of IPython, ipy_bzr (that is because of bzrlib). It's never imported anywhere in ipython source code, but the user can import it in ipy_user_conf.py. This "contaminates" the config file and subsequently ipython (because it's imported into python interpreter ipython is running on), but luckily the user can opt out from importing it if he wishes to remain BSD clean. Or he can delete the file altogether if he wishes. Without GPL, none of this hair-splitting is necessary. I guess I could have gone the Carl Banks route and just say "It scares away some people". Consider my replies here an elaborate way of saying the very same thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: is Pylons alive?
On Apr 9, 2:25 pm, Mage <[EMAIL PROTECTED]> wrote: > Before spending much time for investigating, I would like to ask you: is > Pylons the framework I look for if I want to come back to Python and > develop MVC web apps? Why not play with Django and the Google App Engine that everyone is raving about: http://code.google.com/appengine/ Zope is also becoming a realistic choice now that it's getting easier through Grok... -- http://mail.python.org/mailman/listinfo/python-list
pywin32 vista installer fix & general distutils installer name bug
I just noticed that pywin32 does not work with vista directly (tried import win32clipboard, => ImportError). The problem is the installer name; it's the usual pywin32-210-win32-py2.5.exe It needs to be renamed to: pywin32-210.win32-setup-py2.5.exe In order for vista to catch it as "installer". We renamed the IPython exe installer to have "setup" to get around the same issue. Just posting this for benefit of googlers. I'll complain about this on distutils-sig as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Leo 4.4.8 final
On Apr 6, 8:10 pm, "Edward K Ream" <[EMAIL PROTECTED]> wrote: > - Completed ILeo: a bridge between IPython and Leo. > See http://webpages.charter.net/edreamleo/IPythonBridge.html Additional note: to use ILeo, you need a new IPython. Download the not- yet-blessed release candidate (I don't foresee much changes before the final release) from: https://launchpad.net/ipython/stable/0.8.3pre It's a source distribution, so run "eggsetup.py develop" in it (if you have setuptools) or just "setup.py install" -- http://mail.python.org/mailman/listinfo/python-list
Re: ILeo (IPython-Leo bridge); a marriage made in heaven?
On Feb 23, 10:54 pm, Ricardo Aráoz <[EMAIL PROTECTED]> wrote: > Are you part of Leo? This smells like a marketing scheme to me. Yes, Edward is part of Leo and I am part of IPython. In fact, most of my income comes from selling IPython T-shirts at the local flea market and I therefore have to resort to shady operations like this to pump up my fading income. Hey, it pays the bills! Seriously, though; this *is* cool stuff. I have an updated version of the document here: http://vvtools.googlecode.com/files/ILeo_doc.txt -- http://mail.python.org/mailman/listinfo/python-list
ILeo (IPython-Leo bridge); a marriage made in heaven?
Here is something cool that will rock your world (ok, excuse the
slight hyperbole):
Introduction
The purpose of ILeo, or leo-ipython bridge, is being a two-way
communication
channel between Leo and IPython. The level of integration is much
deeper than
conventional integration in IDEs; most notably, you are able to store
*data* in
Leo nodes, in addition to mere program code. The possibilities of this
are
endless, and this degree of integration has not been seen previously
in the python
world.
IPython users are accustomed to using things like %edit to produce non-
trivial
functions/classes (i.e. something that they don't want to enter
directly on the
interactive prompt, but creating a proper script/module involves too
much
overhead). In ILeo, this task consists just going to the Leo window,
creating a node
and writing the code there, and pressing alt+I (push-to-ipython).
Obviously, you can save the Leo document as usual - this is a great
advantage
of ILeo over using %edit, you can save your experimental scripts all
at one
time, without having to organize them into script/module files (before
you
really want to, of course!)
Installation
You need at least Leo 4.4.7, and the development version of IPython
(ILeo
will be incorporated to IPython 0.8.3).
You can get IPython from Launchpad by installing bzr and doing
bzr branch lp:ipython
and running "setup.py install".
You need to enable the 'ipython.py' plugin in Leo:
- Help -> Open LeoSettings.leo
- Edit @settings-->Plugins-->@enabled-plugins, add/uncomment
'ipython.py'
- Restart Leo. Be sure that you have the console window open (start
leo.py from console, or double-click leo.py on windows)
- Press alt+5 OR alt-x start-ipython to launch IPython in the console
that
started leo. You can start entering IPython commands normally, and Leo
will keep
running at the same time.
Accessing IPython from Leo
==
IPython code
Just enter IPython commands on a Leo node and press alt-I to execute
push-to-ipython to execute the script in IPython. 'commands' is
interpreted
loosely here - you can enter function and class definitions, in
addition to the
things you would usually enter at IPython prompt - calculations,
system commands etc.
Everything that would be legal to enter on IPython prompt is legal to
execute
from ILeo.
Results will be shows in Leo log window for convenience, in addition
to the console.
Suppose that a node had the following contents:
{{{
1+2
print "hello"
3+4
def f(x):
return x.upper()
f('hello world')
}}}
If you press alt+I on that done, you will see the following in Leo log
window (IPython tab):
{{{
In: 1+2
<2> 3
In: 3+4
<4> 7
In: f('hello world')
<6> 'HELLO WORLD'
}}}
(numbers like <6> mean IPython output history indices).
Plain Python code
-
If the headline of the node ends with capital P, alt-I will not run
the code
through IPython translation mechanism but use the direct python 'exec'
statement
(in IPython user namespace) to execute the code. It wont be shown in
IPython
history, and sometimes it is safer (and more efficient) to execute
things as
plain Python statements. Large class definitions are good candidates
for P
nodes.
Accessing Leo nodes from IPython
The real fun starts when you start entering text to leo nodes, and are
using
that as data (input/output) for your IPython work.
Accessing Leo nodes happens through the variable 'wb' (short for
"WorkBook")
that exist in the IPython user namespace. Nodes that are directly
accessible are
the ones that have simple names which could also be Python variable
names;
'foo_1' will be accessible directly from IPython, whereas 'my scripts'
will not.
If you want to access a node with arbitrary headline, add a child node
'@a foo'
(@a stands for 'anchor'). Then, the parent of '@a foo' is accessible
through
'wb.foo'.
You can see what nodes are accessible be entering (in IPython)
wb.. Example:
[C:leo/src]|12> wb.
wb.b wb.tempfilewb.rfile wb.NewHeadline
wb.bar wb.Docswb.strlist wb.csvr
Suppose that we had a node with headline 'spam' and body:
['12',+32]
we can access it from IPython (or from scripts entered into other Leo
nodes!) by doing:
C:leo/src]|19> wb.spam.v
<19> ['12', 2254]
'v' attribute stands for 'value', which means the node contents will
be run
through 'eval' and everything you would be able to enter into IPython
prompt
will be converted to objects. This mechanism can be extended far
beyond direct
evaluation (see '@cl definitions').
'v' attribute also has a setter, i.e. you can do:
wb.spam.v = "mystring"
Which will result in the node 'spam' having the following text:
'mystring'
What assignment to 'v' does can be configured through generic
functions
(simplegeneric module, will be explained later).
Besides v, you can set the body text directly through wb.spam.b =
"some\nstring", headline by wb.spam.
ANN: IPython 0.8.2 released!
Hi all, The IPython team is happy to release version 0.8.2, with lots of new enhancements (especially for system shell use - it has never been a better time for switching to "pysh" or "ipython -p sh" as your system shell of choice), as well as many bug fixes. 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. 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/WhatsNew082 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
ANN: IPyKit, the standalone IPython prompt
Some of you might want to play with IPyKit, especially you need a swiss-army-knife Python prompt on a (win32) machine where you don't really want to install anything (python, pyreadline, ipython, PATH settings...). It's basically a py2exe'd "preconfigured" IPython. http://ipython.scipy.org/moin/IpyKit -- http://mail.python.org/mailman/listinfo/python-list
IPython 0.7.3 upgrade notes
Something I forgot to emphasize in the announcement, knowing that not everyone reads the release notes - if you are upgrading from a previous version of IPython, you must either: - Delete your ~/ipython (or ~/_ipython) directory OR - Run %upgrade once IPython starts. -- http://mail.python.org/mailman/listinfo/python-list
IPython 0.7.3 is out
Hi all, The IPython team is happy to release version 0.7.3, with a lot of new enhancements, as well as many bug fixes (including full Python 2.5 support). 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. 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://projects.scipy.org/ipython/ipython/wiki/Release/0.7.3/Features 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: IPython 0.7.3 upgrade notes
Ville Vainio wrote: > Something I forgot to emphasize in the announcement, knowing that not > everyone reads the release notes - if you are upgrading from a previous > version of IPython, you must either: > > - Delete your ~/ipython (or ~/_ipython) directory OR > - Run %upgrade once IPython starts. And if you are wondering what all of this is about, due to c.l.p.announce moderator approval wait period, see http://projects.scipy.org/ipython/ipython/wiki/Release/0.7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython 0.7.3 upgrade notes
Ville Vainio wrote: > Something I forgot to emphasize in the announcement, knowing that not > everyone reads the release notes - if you are upgrading from a previous > version of IPython, you must either: > > - Delete your ~/ipython (or ~/_ipython) directory OR > - Run %upgrade once IPython starts. (And if you are wondering what all of this is about, due to c.l.p.announce moderator approval waitn period, see http://projects.scipy.org/ipython/ipython/wiki/Release/0.7.3 -- http://mail.python.org/mailman/listinfo/python-list
IPython 0.7.3 upgrade notes
Something I forgot to emphasize in the announcement, knowing that not everyone reads the release notes - if you are upgrading from a previous version of IPython, you must either: - Delete your ~/ipython (or ~/_ipython) directory OR - Run %upgrade once IPython starts. -- http://mail.python.org/mailman/listinfo/python-list
IPython 0.7.3 beta 2 is out!
Yes, next version of IPython is closing in on final release around the years end, with lots of new exiting features (full list TBD, but it *does* include proper python 2.5 support if that's what you've been waiting for). Get the 0.7.3 beta 2 it at http://projects.scipy.org/ipython/ipython/wiki/Release/0.7.3 And remember to run %upgrade if you are already using an older version. -- http://mail.python.org/mailman/listinfo/python-list
IPython team needs a student for a google "Summer of Code" project.
This comes in a bit of a hurry (you only have time until next monday to sign up), but here's the deal: The next version of ipython (0.7.2, "out soon", pretty much done already) will include an extension for browsing and manipulating tabular data (e.g. file name, file size, permissions etc.) called "ipipe", contributed by Walter Doerwald. See http://projects.scipy.org/ipython/ipython/wiki/UsingIPipe to get an idea. The bad news is that, being built on curses, the browser only works on Linux/posix. That's where you'll step in. We need a similar tabular browser built on wxPython toolkit (possibly with the Wax wrapper library). Walter and me have already been accepted as mentors, but we need someone to do the work. As you probably know, there's money involved, see http://code.google.com/soc/studentfaq.html. No knowledge of IPython codebase is necessary (nor will you need to learn it), and the ipipe module itself is pretty manageable and small. So it's mostly about implementing new stuff from scratch. Please contact ipython-dev, me or (preferably) Walter Doerwald ([EMAIL PROTECTED]) if you are interested, ASAP. -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
Duncan Booth wrote: > Looking in the 'obvious' place in the Tutorial, section 5.1 'More on > Lists' I found in the immediately following section 5.2 'The del > statement': I read the tutorial 6 years ago, and don't read it regularly. What's in the tutorial is not really important, what can be easily looked up in library reference or interctive prompt is. There is a bit of "elitism" regarding the defense of del lst[:]. Many python programmers are "casual" programmers (was it Tim Berners-Lee that explained how great python is for casual users?) who know the language but don't remember the way everything is done. Of course someone that uses python 8 hours a day instantly recall lst[:], but a casual one will more probably launch an ipython prompt and do: [ipython]|1> l = [] [ipython]|2> l. l.__add__ l.__getslice__ l.__ne__ l.append l.__class__l.__gt__ l.__new__ l.count l.__contains__ l.__hash__ l.__reduce__ l.extend l.__delattr__ l.__iadd__ l.__reduce_ex__l.index l.__delitem__ l.__imul__ l.__repr__ l.insert l.__delslice__ l.__init__ l.__reversed__ l.pop l.__doc__ l.__iter__ l.__rmul__ l.remove l.__eq__ l.__le__ l.__setattr__ l.reverse l.__ge__ l.__len__ l.__setitem__ l.sort l.__getattribute__ l.__lt__ l.__setslice__ l.__getitem__ l.__mul__ l.__str__ [ipython]|2> # wtf? -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
Ville Vainio wrote: > Assigning to slices is much less important, and is something I always > never do (and hence forget). ALMOST never, of course. -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
Raymond Hettinger wrote: > * easier to figure-out, look-up, and remember than either s[:]=[] or > del s[:] Easier is an understatement - it's something you figure out automatically. When I want to do something w/ an object, looking at its methods (via code completion) is the very first thing. > * the OP is shocked, SHOCKED that python got by for 16 years without > list.clear() I'm sure you realize I was being sarcastic... > * learning slices is basic to the language (this lesson shouldn't be > skipped) Assigning to slices is much less important, and is something I always never do (and hence forget). > * the request is inane, the underlying problem is trivial, and the > relevant idiom is fundamental (api expansions should be saved for rich > new functionality and not become cluttered with infrequently used > redundant entries) I understand that these are the main arguments. However, as it stands there is no one *obvious* way to clear a list in-place. I agree that it's rare to even need it, but when you do a it's a little bit of a surprise. -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
John Salerno wrote: > Thanks guys, your explanations are really helpful. I think what had me > confused at first was my understanding of what L[:] does on either side > of the assignment operator. On the left, it just chooses those elements > and edits them in place; on the right, it makes a copy of that list, > right? (Which I guess is still more or less *doing* the same thing, just > for different purposes) Interestingly, if it was just a "clear" method nobody would be confused. -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
Steven Bethard wrote:
> If you feel really strongly about this though, you might consider
> writing up a PEP. It's been contentious enough that there's not much
> chance of getting a change without one.
No strong feelings here, and I'm sure greater minds than me have
already hashed this over sufficiently.
It's just that, when I have an object, and am wondering how I can clear
it, I tend to look what methods it has first and go to google looking
for "idioms" second.
Perhaps "clear" method could be added that raises
PedagogicException("Use del lst[:], stupid!")?
*ducks*
--
http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
Fredrik Lundh wrote: > > I tried to clear a list today (which I do rather rarely, considering > > that just doing l = [] works most of the time) and was shocked, SHOCKED > > to notice that there is no clear() method. Dicts have it, sets have it, > > why do lists have to be second class citizens? > > because Python already has a perfectly valid way to clear a list, > perhaps ? > > del l[:] Ok. That's pretty non-obvious but now that I've seen it I'll probably remember it. I did a stupid "while l: l.pop()" loop myself. > (lists are not mappings, so the duck typing argument don't really > apply here.) I was thinking of list as a "mutable collection", and clear() is certainly a very natural operation for them. -- http://mail.python.org/mailman/listinfo/python-list
list.clear() missing?!?
I tried to clear a list today (which I do rather rarely, considering that just doing l = [] works most of the time) and was shocked, SHOCKED to notice that there is no clear() method. Dicts have it, sets have it, why do lists have to be second class citizens? -- http://mail.python.org/mailman/listinfo/python-list
Re: How many web framework for python ?
Sybren Stuvel wrote: > Why forget it? I've written my own web framework > (http://www.unrealtower.org/) and it works great! It was a good Some reasons: - Waste. When you write your own framework, you are helping yourself. If you use an existing framework and possibly contribute patches to it, you help other people too. - Other people have already solved your problems, also problems that you can't think of yet. - Not reusing code is just plain evil. -- http://mail.python.org/mailman/listinfo/python-list
Re: How many web framework for python ?
Bo Yang wrote: > There are very good web framework for java and ruby , > Is there one for python ? There are many good ones. > I want to write a web framework for python based on > mod_python as my course homework , could you give some > advise ? Implement yet another web framework? It needs to be made harder so people can stop doing it all the time. ;-) You might want to watch the 20 min turbogears video for a laid back approach of familiarizing yourself with a python web framework: http://www.turbogears.org/docs/wiki20/20MinuteWiki.mov -- http://mail.python.org/mailman/listinfo/python-list
Re: Evil, evil wxPython (and a glimmer of hope)
Torsten Bronger wrote: > Has Wax exceeded the critical mass so that one can be quite certain > that it will still be maintained, say, next year? (Sincere question > since I don't know.) I was a bit worried about this myself, but after browsing the source I have to say I'm not terribly so anymore. It's a relatively thin wrapper over wxPython so you are *almost* using wxPython, but w/o a lot of the pain & horror, and if Hans Nowak stopped paying attention to it the maintenance tab could be picked up by someone else rather easily. Also, wxPython 2.6 is a relatively recent arrival and it's supported, so the next "breakage point" is relatively far away. Frankly, I think the time saved by coding for Wax could even exceed the hypothetical time wasted (in case Wax were discontinued) porting a finished Wax-using product over to use straight wxPython. Using Wax (and occasionally peeking at the source) also seems to be a nice way to learn straight wxPython without being immersed in all the grossness at once. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
>>>>> "Fabio" == Fabio Zadrozny <[EMAIL PROTECTED]> writes: >> I agree about the project management part. Though I would still love >> to use Eclipse instead, if it only was supported for my line of work >> :-/. Fabio> What line of work is not supported in eclipse? C++ programming for Symbian OS. Editing the C++ code works, debugging doesn't, at least yet. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on Guido's ITC audio interview
>>>>> "Timothy" == Delaney, Timothy (Tim) <[EMAIL PROTECTED]> writes: Timothy> Absolutely. I've really tried to use Eclipse - it's the Timothy> standard editor for my current project (Java - blegh!). I Timothy> *hate* it. It's huge, bulky, slow ... I've gone back to Timothy> my text editor. I'm a hell of a lot more Have you tried the recently released 3.1 version? It seems to be a tad snappier than the old version. Timothy> The only IDE I've ever actually liked using was Timothy> Metrowerks CodeWarrior (on MacOS classic). Simple, Timothy> unobtrusive. Good project management, without trying to Timothy> control every aspect of the development process. And The debugger in CodeWarrior is quite crappy IMHO. Unlike visual studio, it doesn't show the return values of function calls. The editor is also quite lacking, without the ability to create macros etc. I agree about the project management part. Though I would still love to use Eclipse instead, if it only was supported for my line of work :-/. Timothy> it allowed me to use the entire screen for editing if I Timothy> wished whilst still having everything readily available. Eclipse allows this as well. ctrl+m is maximize/unmaximize. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: *Python* Power Tools
>>>>> "John" == John Machin <[EMAIL PROTECTED]> writes: John> For windows users, apart from cygwin, there are a couple of John> sources of binaries for *x command-line utilities (unxutils, John> gnuwin32). unxutils is my personal favourite - cygwin is way too much an "environment", and gets broken too easily. I for one would like to see various shell tools implemented in pure python, if only to be able to import them as a module and use cross platform tools that have more power than e.g. 'shutil' or 'os' functions. The API exposed through the module (as opposed to normal execution from shell) could also be much richer, providing hooks for calling own stuff for just-in-time error handling, progress notification etc. So no, it doesn't seem like bad idea at all. It's also something that could evolve gradually, and reach a useful stage (i.e. have several handy tools) quickly. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Loop until condition is true
>>>>> "Stelios" == Stelios Xanthakis <[EMAIL PROTECTED]> writes: Stelios> Anyway, if you can't wait for 2.5 either use 'while 1:', Stelios> or pyc[1] ... and I can't see why people don't want to use 'while 1:' in the first place, given that everyone can identify the idiom immediately. It's 4 keystrokes less. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Dr. Dobb's Python-URL! - weekly Python news and links (Jun 7)
>>>>> "Fred" == Fred Pacquier <[EMAIL PROTECTED]> writes: Fred> Same here : thanks for letting us get away with being Fred> lazy(er) ! :-) Ditto. As someone who's done a couple of p-url's, I can say it's quite a bit of work to find the interesting tidbits from the depths of 500-post threads where people can't be bothered to change the subject line... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python analog of Ruby on Rails?
>>>>> "Shane" == Shane Hathaway <[EMAIL PROTECTED]> writes: Shane> BTW, here's the proper response to that religious thread Shane> that keeps invading this list: Shane> python -c 'print sum([ord(c) for c in "HOLYBIBLE"])' Shane> I'm Christian and I think it's funny. ;-) Some background: Shane> http://scriptures.lds.org/rev/13/16-18#16 Shane> http://www.greaterthings.com/Word-Number/666HolyBible.htm Ah, it was *obvious* from the start that the placement of ASCII letters was a conspiracy of american freemasons... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Just remember that Python is sexy
>>>>> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: >> The name index implies it returns something you can use as an index >> to get at the substring. Greg> But that's no fun -- it doesn't involve sex! Greg> How about this: "index" and "sex" both end with "ex", which Greg> is short for "exception". Or something about the use of index finger being an exception from the conventional strategy... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Just remember that Python is sexy
>>>>> "Peter" == Peter Hansen <[EMAIL PROTECTED]> writes:
Peter> Sion Arrowsmith wrote:
>> But can you come up with a method for remembering which way
>> round str.find() and str.index() are?
Peter> Don't use "str" and you won't have anything to remember:
Peter> 'foo bar baz'.find('spam')
Peter> 'spanish inquisition'.index('parrot')
But which one raises an exception, and which one returns -1?
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: first release of PyPy
>>>>> "Christian" == Christian Tismer <[EMAIL PROTECTED]> writes: >> PyPy is written in python, if it can be compiled then the programs >> can >> be as well. Christian> Well, this is not really true. PyPy is written in Christian> RPython, a sub-language of Python that is implicitly Christian> defined by "simple and static enough to be compilable". Could it be possible to tag some modules in application code as RPython-compatible, making it possible to implement the speed critical parts in RPython? -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: moving from c++ to python
>>>>> "Michael" == Michael <[EMAIL PROTECTED]> writes: Michael> me?? My biggest confusion so far is the lack of pointers Michael> in Python .. Achtually, python uses pointers for everything. On the contrary there are no "value types" in python. MyClass* c = new MyClass(12,13); is equal to c = MyClass(12,13) There is no equivalent to MyClass c(12,13); because it's not needed. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: first release of PyPy
>>>>> "Ville" == Ville Vainio <[EMAIL PROTECTED]> writes: Ville> This is not about PyPy but it might help: Ville> http://www.python.org/pycon/dc2004/papers/1/paper.pdf (It's about starkiller, sorry about the opaque url) -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: first release of PyPy
>>>>> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> writes: Torsten> What's supposed to be compiled? Only PyPy itself or also Torsten> the programs it's "interpreting"? PyPy is written in python, if it can be compiled then the programs can be as well. Torsten> I've been told by so many books and on-line material that Torsten> Python cannot be compiled (unless you cheat). So how is Torsten> this possible? These guys are exploring a new territory. OTOH, Lisp is a dynamic language like python and it can be compiled to native code. Pyrex demonstrates the "trivial" way to compile python to native code, the real problem is making the resulting code fast. Typically this requires type inference (i.e. figuring out the type of an object from the context because there are no type declarations) to avoid dict lookups in method dispatch. This is not about PyPy but it might help: http://www.python.org/pycon/dc2004/papers/1/paper.pdf -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python suitable for a huge, enterprise size app?
>>>>> "brian" == brian <[EMAIL PROTECTED]> writes: brian> to build expertise and confidence, etc. People are more brian> important than programming language. Or so you would think before writing sizeable software in C++. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Like Christ PBBUH Prayed
>>>>> "George" == George Sakkis <[EMAIL PROTECTED]> writes: George> "flamesrock" wrote: >> I don't understand.. why is everyone talking about christ on >> comp.lang.python? Isn't this not the place? >> George> Maybe they know something we don't. The information is generally reserved for 34DEG pythonistas. All will be cleared for lower degree aspirants in due time. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: python-dev Summary for 2005-04-16 through 2005-04-30
>>>>> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes: Steven> If you're interested in why Guido doesn't want blocks with Steven> arbitrary control flow, you should check out: Steven> http://mail.python.org/pipermail/python-dev/2005-May/053702.html It's convincing, but I would still prefer to leave the decision of pulling the trigger on the foot for the implementor of the block function, with the recommendation that all exceptions are propagated. What happened to "we are all adults here"? I don't mind much, though, the new proposal looks good as well. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: python-dev Summary for 2005-04-16 through 2005-04-30
>>>>> "Kay" == Kay Schluehr <[EMAIL PROTECTED]> writes: Kay> but PEP 340 is already withdrawn by the BDFL. [1] Kay> There won't be any Ruby-like blocks because they hide control Kay> flow. Bummer. I would have greatly enjoyed seeing the only real reason for choosing Ruby over Python blown away... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Ruby blocks finally coming to python? (was Re: python-dev Summary for 2005-04-16 through 2005-04-30
Just wanted to draw the attention by changing the subject line - see parent and especially: Tony> Tony> PEP 340 Proposed Tony> Tony> In the end, Guido decided that what he really wanted as a solution to Tony> `The Control Flow Management Problem`_ was the simplicity of something Tony> like generators that would let him write locking() as something like:: Tony> def locking(lock): Tony> lock.acquire() Tony> try: Tony> yield Tony> finally: Tony> lock.release() Tony> and invoke it as something like:: Tony> block locking(lock): Tony> CODE -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Interactive shell for demonstration purposes
>>>>> "Brian" == Brian Quinlan <[EMAIL PROTECTED]> writes: Brian> Can anyone recommend a Python interactive shell for use in Brian> presentations? Brian> I've tried ipython but, since it runs inside a console Brian> window, and the console window has a limited number of Brian> selectable fonts, it doesn't work terribly well. Hmm, do you consider the fonts in a console window unreadable? I've given a few presentations using ipython on win32 and it worked alright - but I suppose the projector quality is a factor here... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Solipsis: Python-powered Metaverse
>>>>> "Paul" == Paul McNett <[EMAIL PROTECTED]> writes: Paul> Only, I couldn't hear what they said back to me because I Paul> don't have UDP port 6000 open on my firewall and forwarding Paul> to my laptop (and don't want to do that either). Paul> It is a shame: peer to peer has the potential to enable Paul> really cool, imaginative multiuser worlds, but how many Paul> people are connecting directly to the internet these days? FWIW, In Finland all home *DSL and Cable internet connections (that I know of) are connected "directly" to the internet (in the sense that all ports are open). Blocking is reserved for the modem, just the way it should be... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference between Python CGI applications and Php applications
>>>>> "Praba" == praba kar <[EMAIL PROTECTED]> writes: Praba> Dear all, Praba> I have a project that is conversion of Php Web applications Praba> into Python cgi applications. In my mind compare You might want to look into mod_python and psp (python server pages) for a more straightforward conversion: http://www.onlamp.com/pub/a/python/2004/02/26/python_server_pages.html -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: BitKeeper for Python?
>>>>> "Bruce" == Bruce Stephens <[EMAIL PROTECTED]> writes: Bruce> Nick Craig-Wood <[EMAIL PROTECTED]> writes: Bruce> [...] >> You could try Mercurial >> >> http://www.selenic.com/mercurial/ Bruce> Or Codeville, also written in Python. Or bazaar-ng, also written in python. Bruce> Codeville's said to be pretty usable. Ditto, through the repo format has not been stabilized yet. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "John" == John J Lee <[EMAIL PROTECTED]> writes: John> Dave Cook <[EMAIL PROTECTED]> writes: John> What are those compelling features of Pydev, for an emacs John> user? http://pydev.sourceforge.net/features.html Code completion and debugger are the most obvious ones. Eclipse itself is also quite a "feature". -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: large dictionary creation takes a LOT of time.
>>>>> "Kent" == Kent Johnson <[EMAIL PROTECTED]> writes: Kent> if frequency.has_key(word): Kent> frequency[word] += 1 Kent> else: Kent> frequency[word] = 1 This is a good place to use 'get' method of dict: frequency[word] = frequency.get(word,0) + 1 -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "Brian" == Brian Beck <[EMAIL PROTECTED]> writes: Brian> Ville Vainio wrote: >> Perhaps you are just being impatient? >> >> Also, make sure that Preferences/pydev/code completion has >> "Autocomplete on '.'" box checked. Brian> Yeah, that option is enabled. I actually just discovered Brian> that it does work in the example you give and for other Brian> modules in the standard library. But calls to standard Brian> library modules only occur maybe twice in any of my big Brian> scripts... the problem is I've been trying code completion Brian> with third-party modules and local classes, which still Brian> doesn't work. >From the faq at http://pydev.sourceforge.net/faq.html: How do I set the PYTHONPATH for code completion to work in my project? To set the PYTHONPATH for code completion purposes, you have to right click your project root, choose properties->PyDev PYTHONPATH and set it. The Restore PYTHONPATH button should get your enviroment PYTHONPATH and automatically set it. If it does not work, check python interpreter is correctly set (see questions above). Does this help? -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "Brian" == Brian Beck <[EMAIL PROTECTED]> writes: Brian> Okay, sorry for spamming the newsgroup so much, but I Brian> installed 0.9.3 properly and the same issues I mentioned Brian> before persist. Code completion for imports or locals don't Brian> work at all -- the space thing was PyDev just listing all Brian> the built-ins, with none of my modules or locals included Brian> in the list. This is another thing that works fine for me. Have you tried starting with an empty file to see whether there is something in your source file that trips up pydev? Whining at the pydev mailing list might work as well. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "Brian" == Brian Beck <[EMAIL PROTECTED]> writes: Brian> Oh yeah, and what's with not being able to configure the Brian> code completion key sequence. How about *no* key sequence? Brian> That's the way every other IDE I've used does it. This is Brian> more like semi-automatic code completion. It works like that for me. I type: import os os. And I get the list of completions. Perhaps you are just being impatient? Also, make sure that Preferences/pydev/code completion has "Autocomplete on '.'" box checked. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Which IDE is recommended?
>>>>> "pydev" == Brian Beck <[EMAIL PROTECTED]> writes: pydev> * PyDev isn't yet mature enough to make it practical for me What version? PyDev has increased in maturity quite a bit lately. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: names of methods, exported functions
>>>>> "Mayer" == Mayer <[EMAIL PROTECTED]> writes: Mayer> Hello: Mayer> Is there a way to see at the python prompt the names of all Mayer> the public methods of a class or the names exported by a Mayer> module? I know that If you use ipython, you can press after the period, e.g. [~]|128> import re [~]|129> re. re.DOTALL re.MULTILINE re.__all__re.error re.search re.I re.S re.__doc__re.escape re.split re.IGNORECASE re.U re.__file__ re.findallre.sub re.L re.UNICODEre.__name__ re.finditer re.subn re.LOCALE re.VERBOSEre.compilere.match re.template re.M re.X re.engine re.purge re.__class__ [~]|129> re. ISTR the completion can be added to plain old python prompt as well, through rlcompleter. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python internal design
>>>>> "Emre" == Emre Turkay <[EMAIL PROTECTED]> writes: Emre> Hi Folks, Emre> I am designing a tool, in which there are dynamic types and Emre> variables with these types. In this respect, it is more like Emre> an interpreted language design. Emre> I wonder how these issues are implemented in Python are Emre> there any documents or articles about it, which I can read Emre> and get an idea. It's built around string lookup. obj.stuff() -> look up what object is associated with string 'stuff', get the object, see how it can be called, call it. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: What's do list comprehensions do that generator expressions don't?
>>>>> "Jeremy" == Jeremy Bowers <[EMAIL PROTECTED]> writes: Jeremy> On Sun, 24 Apr 2005 22:59:12 -0700, Robert Kern wrote: >> Never. If you really need a list >> >> list(x*x for x in xrange(10)) >> >> Sadly, we can't remove list comprehensions until 3.0. Jeremy> Why "remove" them? Instead, we have these things called Jeremy> "comprehensions" (which, now that I say that, seems a Jeremy> rather odd name), and you can control whether they result Jeremy> in a list or a generator with () or []. Still, list comprehensions should be implemented in terms of genexps to get rid of the LC variable that is visible outside the scope of the LC. Jeremy> should be relatively simple), it's not worth breaking that Jeremy> code. Well, the code that relies on the dangling variable deserves to break. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python or PHP?
>>>>> "John" == John Bokma <[EMAIL PROTECTED]> writes:
John> Who told you Perl can't do exceptions?
Back when I learned (heh, I never 'really' learned, but knew enough to
write programs in it) perl, almost every function call was followed by
or die("blah");
i.e. the user had to check the error code. If the function would have
raised an exception instead, such check would be redundant because it
would never be executed.
In Python, all error conditions raise exceptions. If python
'supported' exceptions but standard library functions didn't raise
them, the feature would not be worth much.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python or PHP?
>>>>> "John" == John Bokma <[EMAIL PROTECTED]> writes: >> Nah, they aren't slow. They just have to worry about more things than >> the Python developers. John> Do you have references to this? I would love to see if John> indeed 100 Python programmers do implement, say 5 CS tasks John> faster compared to 100 Perl programmers, on average. I am quite sure that given random sample of python and perl programmers, the python programmers would be faster. Less thinking is necessarily, no $ chars and generally less punctuation to worry about, no error handling needed (exceptions take care of it automatically). I would also venture to guess that random (adult) Python programmers would be of higher skill level as far as programming in general goes (know more languages, have a "good taste"...). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Object oriented storage with validation (was: Re: Caching compiled regexps across sessions (was Re: Regular Expressions - Python vs Perl))
>>>>> "Ilpo" == Ilpo NyyssÃnen writes: Ilpo> Pickle doesn't have validation. I am not comfortable for Ilpo> using it as storage format that should be reliable over Ilpo> years when the program evolves. It also doesn't tell me if That's why you should implement xml import/export mechanism and use the xml file as the "canonical" data, while the pickle is only a cache for the data. Ilpo> How can it work automatically in separate module? Replacing Ilpo> the re.compile with something sounds possible way of getting Ilpo> the regexps, but how and where to store the compiled data? Ilpo> Is there a way to put it to the byte code file? Do what you already did - dump the regexp cache to a separate file. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python or PHP?
>>>>> "Leif" == Leif K-Brooks <[EMAIL PROTECTED]> writes:
Leif> Lad wrote:
>> Is anyone capable of providing Python advantages over PHP if there are
>> any?
Leif> Python is a programming language in more ways than simple Turing
Leif> completeness. PHP isn't.
+1 QOTW.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Caching compiled regexps across sessions (was Re: Regular Expressions - Python vs Perl)
>>>>> "Ilpo" == Ilpo NyyssÃnen writes: >> so you picked the wrong file format for the task, and the slowest Ilpo> What would you recommend instead? Ilpo> I have searched alternatives, but somehow I still find XML Ilpo> the best there is. It is a standard format with standard Ilpo> programming API. Ilpo> I don't want to lose my calendar data. XML as a standard Ilpo> format makes it easier to convert later to some other Ilpo> format. As a textual format it is also readable as raw also Ilpo> and this eases debugging. Use pickle, perhaps, for optimal speed and code non-ugliness. You can always use xml as import/export format, perhaps even dumping the db to xml at the end of each day. Ilpo> And my point is that the regular expression compilation can Ilpo> be a problem in python. The current regular expression Ilpo> engine is just unusable slow in short lived programs with a Ilpo> bit bigger amount of regexps. And fixing it should not be Ilpo> that hard: an easy improvement would be to add some kind of Ilpo> storing mechanism for the compiled regexps. Are there any Ilpo> reasons not to do this? It should start life as a third-party module (perhaps written by you, who knows :-). If it is deemed useful and clean enough, it could be integrated w/ python proper. This is clearly something that should not be in the python core, because the regexps themselves aren't there either. >> python has shipped with a fast XML parser since 2.1, or so. Ilpo> With what features? validation? I really want a validating Ilpo> parser with a DOM interface. (Or something better than DOM, Ilpo> must be object oriented.) Check out (coincidentally) Fredrik's elementtree: http://effbot.org/zone/element-index.htm Ilpo> I don't want to make my programs ugly (read: use some more Ilpo> low level interface) and error prone (read: no validation) Ilpo> to make them fast. Why don't you use external validation on the created xml? Validating it every time sounds like way too much like Javaic B&D to be fun anymore. Pickle should serve you well, and would probably remove about half of your code. "Do the simplest thing that could possibly work" and all that. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Regular Expressions - Python vs Perl
>>>>> "Ilpo" == Ilpo NyyssÃnen writes: Ilpo> Of course it caches those when running. The point is that it Ilpo> needs to recompile every time you have restarted the Ilpo> program. With short lived command line programs this really Ilpo> can be a problem. I didn't imagine it could be longer than 1 second overhead - and if you have so many regexps, it must do something so nontrivial that 1 second doesn't matter. Perhaps I have a different mindset about this :-). Ilpo> And yes, I have read the source of sre.py and I have made an Ilpo> ugly module that digs the compiled data and pickles it to a Ilpo> file and then in next startup it reads that file and puts Ilpo> the stuff back to the cache. What's so ugly about it? The fact that you need to rewrite the cache when you change some of the regexps? I can't imagine you change more than, say, 10 of the regexps a day (compiling of which is an insignificant performance hit) and when you "ship" the script, you will freeze the regexps anyway. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Regular Expressions - Python vs Perl
>>>>> "Ilpo" == Ilpo NyyssÃnen writes: Ilpo> James Stroud <[EMAIL PROTECTED]> writes: >> Is it relevant that Python can produce compiled expressions? I >> don't think that there is such a thing with Perl. Ilpo> The problem in python here is that it needs to always Ilpo> recompile the regexp. I would like to have a way to write a Ilpo> regexp as a constant and then python should compile that Ilpo> regexp to the byte-code file. Ilpo> This is a problem when one has a big amount of regexps. One Ilpo> example is the xmlproc parser in PyXML, Read the source for sre.py, esp. _compile. The compiled regexps are cached, so when you invoke e.g. re.match(), it doesn't recompile the regexp. So this point is moot, and perl's approach is excessive special casing. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Nokia to speak at Python-UK next week
>>>>> "Nick" == Nick Craig-Wood <[EMAIL PROTECTED]> writes: Nick> Not entirely on topic, but does anyone know if there is a Nick> series 80 python? Or if the series 60 python runs on a Nick> series 80 phone (eg communicator 9300/9500)? Nope & nope. It would be easy-ish to get Python working on a console level on 9300/9500 if there was access to the source code... There's also an open source implementation of Python for UIQ (UI toolkit used by SonyEricsson) See http://www.mobilewhack.com/programming/python/ -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: templating system
>>>>> "Erik" == Erik Max Francis <[EMAIL PROTECTED]> writes: Erik> All I meant by that note was that EmPy was not primarily Erik> designed for blazing speed; that is, it could easily be made Erik> much more efficient in a lot of ways. I've never had a need It would be interesting to see benchmarks comparing different templating system. I suppose a web templating system like PSP (of mod_python) would be optimized for speed. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming Language for Systems Administrator
>>>>> "zsolt" == pythonUser 07 <[EMAIL PROTECTED]> writes: zsolt> Python is great, but having much "admin" type experience, zsolt> I've found python to be less than Ideal when dealing with zsolt> system calls and standard Input Ouput. Have you tried the 'subprocess' module to see whether it solves your problems, new in 2.4? That said, I've never had the problems you describe with normal popen* calls either. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming Language for Systems Administrator
>>>>> "beliavsky" == beliavsky <[EMAIL PROTECTED]> writes: beliavsky> The key difference between the Unix approach and the beliavsky> MSH one is that rather than creating a "pipeline" based beliavsky> on textual input and output, MSH passes data between beliavsky> the various commandlets as arbitrary objects. They clearly read my rant from last summer http://groups.google.com/groups?threadm=du7brj2mpg9.fsf%40mozart.cc.tut.fi ;-) -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
win32 readline maintenance (was Re: IPython - problem with...
>>>>> "Fernando" == Fernando Perez <[EMAIL PROTECTED]> writes: Fernando> Bummer. I wonder, if the changes are minor and easy, Fernando> perhaps you (or someone else) could offer Gary to take Fernando> over maintenance of readline/win32? It sounds Someone on the ipython mailing list already had patches for it - I think it was for Belgian keyboards. She didn't submit the patches, just asked whether she should submit them. Fernando> like he is perhaps too busy to keep up with the patches Fernando> and improvements, so perhaps it's time for someone else Fernando> to take over? That kind of library, while Optimally, something like this should be in the pywin32 package. I suppose it could be hosted at scipy if someone was to take over the maintenance? It's open source, so the maintenance doesn't need to be "transferred" - just put up version control somewhere and we'll see what happens :-). In the meantime I would suggest win32 users to do as I do and use a different keyboard layout. US layout is better for programming anyway and you learn it in a day or two. Settings->Control Panel->Regional Options->Input Locales. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython - problem with using US international keyboard input scheme on W2K
>>>>> "Claudio" == Claudio Grondi <[EMAIL PROTECTED]> writes: Claudio> Considering what I found in the ipython mailing archives Claudio> and the fact, that after the fix with displaying colors Claudio> on bright backgrounds Gary had no time yet to get in Claudio> touch with me about the code I have sent him, I suppose, Claudio> that there will be no new releases addressing this Claudio> problem soon, right? No idea. There have been multiple complaints about the issue (and functional patches to fix the problem), so I wouldn't be surprised if this issue was solved quickly enough. Claudio> lazy at the moment, because instead of trying to fix it Claudio> just switched back to Idle ... Don't get too lazy, you're not alone with this problem. I get a beep every time I try to type a scandinavian character (ÃÃ) on ipython console, luckily I never have to do that :-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming Language for Systems Administrator
>>>>> "Sizer" == Sizer <[EMAIL PROTECTED]> writes: Sizer> Looking at my followup, I really didn't make it clear that Sizer> you'll have to learn some bash scripting to be an effective Sizer> *nix administrator, just because so many parts of the Sizer> system use bash scripting. But python is much nicer to Sizer> write anything non-trivial in. If you don't need to edit already existing system scripts, you don't really need to know bash scripting. For debugging purposes, it's easy to see what commands the script executes to perform a task. You just need to know about `backticks` and $ENV_VARS, but that's more general Unix knowledge than actual shell scripting. So IMHO learning bash scripting might be a waste of time, and it should be learnt 'as you go' - i.e. if/when you eventually bump into a problem where you need to be able to do bash scripting. There's the 'Unix romantic' movement that still thinks shell scripts are a good idea, but this is my .02EUR to point out that not everyone agrees with them. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython - problem with using US international keyboard input scheme on W2K
>>>>> "Claudio" == Claudio Grondi <[EMAIL PROTECTED]> writes: Claudio> Is it already known, that after switching the keyboard Claudio> input scheme on German Windows 2000 to english USA Claudio> International IPython generates \x00" instead of " when Claudio> trying to input quotation marks? This has been reported previously - apparently it's a problem with Gary's readline module (or however it was called ;-), and hacking it solved the problem for someone. I suggest you search the ipython mailing list archives, or post this question there. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
>>>>> "jjl" == John J Lee <[EMAIL PROTECTED]> writes: >> Other editors also do stuff Emacs won't do. Code completion is a >> killer feature and emacs sucks at it (yes, w/ Cedet too). jjl> I thought that too, but then I bound dabbrev-expand to F4, jjl> and it seems even better than 'proper' completion (for jjl> reducing keystrokes, anyway). But does not work when you don't know/can't recall what methods are available for the object you are looking at. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
>>>>> "caneff" == ChinStrap <[EMAIL PROTECTED]> writes: caneff> Anyone want to send me a configuration setup with Python caneff> in mind, and decent colors? http://www.emacswiki.org/cgi-bin/wiki/ColorTheme -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
>>>>> "Sunnan" == Sunnan <[EMAIL PROTECTED]> writes: Sunnan> Ville Vainio wrote: Sunnan> Also, Guido recently urged people to explicitly write Sunnan> recursions rather than to use reduce - which I thought was Sunnan> completely in line with what I've seen as python's goals: Sunnan> readability/understandability as more important than Sunnan> terseness/non-boringness. The problem w/ reduce is that it's not intuitive. You'll have to stop to think what the code w/ reduce does - effectively converting it to a normal loop (not recursion!) in your head. It's a net loss when you compare it to just reading an explicit loop as written in code. Sunnan> Yesterday, I read some marketing prop describing a Sunnan> proprietary IDE (don't remember what language) as Sunnan> "exciting", and I went "Ugh, no thanks! Give me calm Sunnan> computing." And then I thought - wait: I just ranted about Sunnan> boringness on comp.lang.python. Can't boring and calm Sunnan> sometimes mean the same thing? Not for me at least. 'Boring' implies a certain sense of frustration, not getting anywhere and generally feeling like you are wasting your time. Human attention is a limited resource, and being bored leads to loss of attention. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Best editor?
>>>>> "Miki" == Miki Tebeka <[EMAIL PROTECTED]> writes: Miki> Emacs (or VIm in my case) takes time to learn. However when Miki> you start to understand it and know you way around it'll do Miki> things no other editor will do for you. Other editors also do stuff Emacs won't do. Code completion is a killer feature and emacs sucks at it (yes, w/ Cedet too). Emacs is pretty good for Python if you can't wait for something like Eclipse+pydev to start (which is a good choice, and worth learning). Emacs is not necessarily worth learning unless you are an emacs user already. Emacs also looks so horrible in Linux that I tend to go for Kate when I'm at home. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate DesignFlaw
>>>>> "Sunnan" == Sunnan <[EMAIL PROTECTED]> writes: Sunnan> languages". I'm not sure whether I'd consider python Sunnan> particularly terse, though, but I don't know enough about Sunnan> it yet. (I've read a Read up on list comprehensions and generator expressions. You'll see the terse side of Python (and genexps look kinda poetic too ;-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: boring the reader to death (wasRe: Lambda: the Ultimate Design Flaw
>>>>> "Sunnan" == Sunnan <[EMAIL PROTECTED]> writes:
Sunnan> It's just that I'm having a hard time matching that quote
Sunnan> to what I though python was about. I thought boring code
Sunnan> was considered a virtue in python. ("Explicit is better
Sunnan> than implicit", "sparse is better than dense".)
Boring code is code that numbs your senses with constant flow of
boilerplate crap, memory management and redundant type declarations
and general blah blah that you skip when you are trying to figure out
what a piece of code does. It's a code that you wish you could train a
monkey to write for you while you go for lunch. Think C++ or Java.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive dict, non-destructive, fast, anyone?
>>>>> "Bengt" == Bengt Richter <[EMAIL PROTECTED]> writes: Bengt> I wonder if a dict with a general override hook for hashing Bengt> all keys would be useful. E.g., a dict.__keyhash__ that Bengt> would take key as arg and default as now returning Bengt> key.__hash__() but that you could override. Seems like this There would need to be an override hook for key comparison as well (I suppose it always uses == operation now?). But yes, I think it would be *much* more useful than any 'keytransform' feature - is there any use for 'keytransform' feature apart from the uses that would be better covered by hash/comparison hooks? It would be lovely to have something like this in the stdlib (or anywhere, for that matter). Think about the use cases for hashing via by os.path.normcase, str.lower... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Case-insensitive dict, non-destructive, fast, anyone?
>>>>> "Daniel" == Daniel Dittmar <[EMAIL PROTECTED]> writes: Daniel> Ville Vainio wrote: >> I need a dict (well, it would be optimal anyway) class that >> stores the keys as strings without coercing the case to upper >> or lower, but still provides fast lookup (i.e. uses hash >> table). Daniel> Store the original key together with the value and use a Daniel> lowercase key for lookup. That's what I thought initially, but the strings take most of the space in dict and I didn't feel like doubling the size. It would be the "simplest thing that could possibly work", though. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Case-insensitive dict, non-destructive, fast, anyone?
I need a dict (well, it would be optimal anyway) class that stores the
keys as strings without coercing the case to upper or lower, but still
provides fast lookup (i.e. uses hash table).
>> d = CiDict([('Hi', 12),('hoho',13)])
>> d['hi']
12
>> d.keys()
['Hi','hoho']
Note that 'Hi' preserved the case. I imagine that 'Hi' and 'hi' would
need to share the same hash value in order for the lookup to be fast.
Anyone have a an implementation that I could use? Quick googling only
produced implementations that coerce all keys to lowercase.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: itertools to iter transition (WAS: Pre-PEP: Dictionary accumulator methods)
>>>>> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes: Steven> Certainly a valid point. How would you feel about adding Steven> just a select few itertools functions, perhaps just Steven> islice, chain and tee? A minimal set would not be that offensive, yes. But then we would have two places to look for itertools functionality, which may not be desirable. One thing that might be worth keeping in mind is that some of itertools functionality is going to become obsolete come py3k (izip->zip), and some is already (imap). At least such operations should not be dumped into the builtin iter. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: itertools to iter transition (WAS: Pre-PEP: Dictionary accumulator methods)
>>>>> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes: Steven> to be documented as a builtin type. I don't find the Steven> argument "builtin type methods are hard to find" Steven> convincing -- the solution here is to fix the Steven> documentation, not refuse to add builtin types. Yep - that's why we should perhaps fix the documentation first :-). Steven> I guess the real questions are[1]: Steven> * How much does iter feel like a type? Guess this depends on the person. I've never thought of it as a type. It's too fundamental a concept to coerce into a type, even thought protocol == type in a sense. Steven> [1] There's also the question of how much you believe in Steven> OO tenets like "functions closely associated with a type Steven> should be members of that type"... The issue that really bothers me here is bloating the builtin space. We already have an uncomfortable amount of builtin functions. Of course the additions that have been suggested would not pollute the builtin namespace, but they would still be there, taking space. I'd rather see a more modular and 'slimmer' Python, what with the advent of Python for S60 and other embedded uses. Perhaps what you need is 'from usefulstuff import *', with usefulstuff having os, sys, 'itertools as it', &c. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
>>>>> "Ville" == Ville Vainio <[EMAIL PROTECTED]> writes: Ville> To me, nothing is more natural than "ab" + "cd" == Ville> "abcd". Also [1,2] + [3,4] == [1,2,3,4]. "Dot product" is Ville> not really too useful in real world (non-mathematical) Ville> apps. ... and of course by "dot product", I don't mean dot product at all. I was thinking of summing vectors, which is not that much more common either. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
>>>>> "Antoon" == Antoon Pardon <[EMAIL PROTECTED]> writes:
Antoon> Op 2005-03-27, Joal Heagney schreef <[EMAIL PROTECTED]>:
>> Antoon Pardon wrote:
>>
>>> So python choose a non-deterministic direction. To me (2,3) + (4,5)
>>> equals (6,8). I don't dispute that having an operator to combine
>>> (2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
>>> used the "+" for that.
>>
>> ("alph", "bravo") + ("delta", "max") --> ("alphdelta", "bravomax")
Antoon> No, that wouldn't be the result. You are still using "+"
Antoon> for concatenation, even if only on strings. I say python
Antoon> should have used something else for concatenation (string
Antoon> concatenation included)
To me, nothing is more natural than "ab" + "cd" == "abcd". Also [1,2]
+ [3,4] == [1,2,3,4]. "Dot product" is not really too useful in real
world (non-mathematical) apps.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: itertools to iter transition (WAS: Pre-PEP: Dictionary accumulator methods)
>>>>> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes: Raymond> If the experience works out, then all you're left with is Raymond> the trivial matter of convincing Guido that function Raymond> attributes are a sure cure for the burden of typing Raymond> import statements. For one thing, it would make it harder to find the functions from the docs. It's easy to find the doc for 'itertools', but iter object methods would require browsing that infamous Chapter 2 of the documentation... Apart from that, I don't really see the advantage in moving away from itertools. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for a 10-14 years old?
>>>>> "Bengt" == Bengt Richter <[EMAIL PROTECTED]> writes: Bengt> Or they may identify with their gift and become Bengt> insufferable narcissistic egotists as a refuge from human Bengt> isolation and emotional starvation. Bengt> Or they may become wonderful human beings after all, happy Bengt> stewards of what becomes a gift to humanity, not just an Bengt> advantage to exploit meanly. Or they may determine to be exactly what they feel like being at the moment, independent of what their parents or the surrounding world feel they should be. (urgh, way too serious to be pythonic, but it's 5:14am here) -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for a 10-14 years old?
>>>>> "Christos" == TZOTZIOY writes: Christos> (first hw upgrade I ever did!), and one year and a half Christos> later, I managed to get the Sinclair QL, with better Christos> BASIC, multitasking capabilities, and something more Christos> like an OS than any other home computer till then. And Christos> man, wasn't 68k assembly a joy :) Linus Torvalds also bought Sinclair Ql back in the day - I was quite surprised to find out that it had a 32bit CPU (according to his autobiography). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggestions for a Java programmer
>>>>> "bruno" == bruno modulix <[EMAIL PROTECTED]> writes: bruno> These two books should help you to get a grasp of Pythonic idioms: ... Regarding a Java programmer moving to Python, a lot of the mindset change is about the abundant use of built in data types of Python. So a Java programmer, when confronted with a problem, should think "how can I solve this using lists, dicts and tuples?" (and perhaps also my new favourite, sets). Class-based solution should be chosen only after seeing that the problem can't be trivially solved with built-in types. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 0.7 released!
>>>>> "Robin" == Robin Becker <[EMAIL PROTECTED]> writes: Robin> well that's nice, but I don't do blogs and certainly don't You don't need to "do" much - just go to planetpython.org -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 0.7 released!
>>>>> "fphsml" == James <[EMAIL PROTECTED]> writes: fphsml> http://www.gotdotnet.com/workspaces/workspace.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742 Apparently they are also going to put out a release every 2 weeks until 1.0 is out. Great news for those who were afraid the project is dead due to silence... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Interface support?
>>>>> "Michael" == Michael Spencer <[EMAIL PROTECTED]> writes: Michael> Steve wrote: >> Is it possible to design interfaces that classes must implement >> in Python? Michael> PyProtocols: http://peak.telecommunity.com/PyProtocols.html, This (PyProtocols) seems to be the one with biggest momentum at the time being, so if you can't be bothered to perform an independent and balanced evaluation, go for PyProtocols :-). -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
REPOST: Re: Python becoming less Lisp-like
>>>>> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> writes: >>> There would be keywords for static and class methods, no >>> distinction between Unicode and non-Unicode >> You couldn't do that 15 years ago because there were no Unicode >> that time. Torsten> I've never said that Guido was just too stupid at that Torsten> time. I only said "but you can definitely see that it's Torsten> the oldest one". In other words, a Ruby six years older Torsten> than the real one would have the same problem. And who Torsten> knows how C# looks like in 10 years. http://c2.com/cgi/wiki?PythonVsRuby seems to suggest that Python has better Unicode support than Ruby. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
REPOST: Re: Python becoming less Lisp-like
>>>>> "Tim" == Tim Daneliuk <[EMAIL PROTECTED]> writes: Tim> Except that in this case, removal will also complicate code Tim> in some cases. Consider this fragment of Tkinter logic: Tim> UI.CmdBtn.menu.add_command(label="MyLabel", Tim> command=lambda cmd=cmdkey: CommandMenuSelection(cmd)) Tim> Would it not be the case that, without lambda, we will need Tim> to pollute the name space with a bunch of specialized little Tim> functions for each and every construct like this? You can reuse the same name for all those little functions to avoid polluting the namespace. Choose 'L' if it gives you that cozy lambda-ish feel. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: I can do it in sed...
>>>>> "John" == John Machin <[EMAIL PROTECTED]> writes: John> You can get gnu Windows versions of awk sed and most other John> suchlike goodies off the net ... Yeah, google for 'unxutils'. Cygwin versions of these tools can be a headache sometimes. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: I can do it in sed...
>>>>> "Damjan" == Damjan <[EMAIL PROTECTED]> writes:
Damjan> Or, much nicer
>> if line[:5]=='start': printing=1
Damjan> if line.startswith('start'): printing=1
>> if line[:3]=='end': printing=0
Damjan> if line.endswith('end'): printing=0
No, it's still line.startswith('end'), not endswith.
--
Ville Vainio http://tinyurl.com/2prnb
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
>>>>> "Mike" == Mike Meyer <[EMAIL PROTECTED]> writes: Mike> The real problem is that newbies won't know which features Mike> are "meta" features best left to experts, and which features Mike> are ok for everyday programmers to use. I suppose that a typical lazy newbie will just skip metaclasses and descriptors on the grounds of not understanding them immediately. It's the 'quest of guruhood' phase when novices start browsing wikis and obscure python-dev discussions to find out how these things work. All the documentation I've seen regarding these features mentions that the user probably doesn't need to know about them; this is especially true for metaclasses. -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python like VB?
>>>>> "Cappy" == Cappy2112 <[EMAIL PROTECTED]> writes: Cappy> VB has a much better IDE than the IDE's for Python, Cappy> although Eric3 is one of the best, and is absolutely free. Eric3 is not easily available for win32, due to current state of Qt licensing (will change with Qt4 I think). Cappy> There are many gui toolkits/frameworks for Python, but the Cappy> foreunners are pyQT, wxPython, pyGTK, and TK/Tkinter. On windows it might make sense to choose wxPython, though I've heard some good stuff about new versions of pyGTK as well. People coming from VB background probably also appreciate the ability to draw the UI in point&click style: http://gazpacho.sicem.biz/ http://wxglade.sourceforge.net/ Unfortunately these seem to still be a tad rough around the edges... -- Ville Vainio http://tinyurl.com/2prnb -- http://mail.python.org/mailman/listinfo/python-list
