Hi,
I would like to know if 1)there is a Python way to tell under which
terminal process a Python command-line application is running 2)there
is a Python way to tell the OS to give focus to another window.
Solutions for Windows, Linux and OS X are welcome, even if OS-specific
(of course general s
On Dec 12, 2:58 pm, Neil Cerutti <[EMAIL PROTECTED]> wrote:
> On 2007-12-11, massimo s. <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I'm struggling to use the python in-built csv module, and I
> > must say I'm less than satisfied. Apart from being r
Thanks to everyone in this thread. As always on this newsgroup, I
learned very much.
I'm also quite embarrassed of my ignorance. Only excuse I have is that
I learned programming and Python by myself, with no formal (or
informal) education in programming. So, I am often clumsy.
On Dec 12, 1:29 am,
On 12 Dic, 00:08, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> Note that all the above (as any operation involving a whole *column*)
> requires reading the whole file in memory. Working by rows, on the other
> hand, only requires holding ONE row at a time. For big files this is
> significant.
>
On 11 Dic, 22:37, John Machin <[EMAIL PROTECTED]> wrote:
> On Dec 12, 6:14 am, "massimo s." <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I'm struggling to use the python in-built csv module, and I must say
> > I'm less than satisfied.
On 11 Dic, 20:24, "Guilherme Polo" <[EMAIL PROTECTED]> wrote:
>
> Post your actual problem so you can get more accurate help.
Hi Guilhermo,
I have not an actual problem. I'm just trying to use the CSV module
and I mostly can get it working. I just think its interface is much
less than perfect. I'
Hi,
I'm struggling to use the python in-built csv module, and I must say
I'm less than satisfied. Apart from being rather poorly documented, I
find it especially cumbersome to use, and also rather limited. What I
dislike more is that it seems working by *rows* instead than by
*columns*.
So I have
Uh, oh.
I think I found the bug, and it was a *really stupid bug*.
The list of GUI_PLUGINS was empty... so there was no plugin class that
was inherited.
I'm embarrassed to have wasted your time that way. However I learned a
lot about new-style classes and so on, so for me it was a learning
experi
On 28 Giu, 15:37, Peter Otten <[EMAIL PROTECTED]> wrote:
> Post a self-contained example.
Now I'm even more confused. The self-contained example is below... and
it works, using only old-style declarations.
#!/usr/bin/env python
import wx
import cmd
global CLI_PLUGINS
global GUI_PLUGINS
class
On 28 Giu, 15:37, Peter Otten <[EMAIL PROTECTED]> wrote:
> massimo s. wrote:
> > Again: using a new-style plugin class for multiple inheritance does
> > not work.
>
> This statement is certainly too broad.
>
> [earlier]
>
> > TypeError: unbou
On 28 Giu, 14:41, "massimo s." <[EMAIL PROTECTED]> wrote:
> The new-style behaviour only appears when wxFrame is plugged with the
> current hack.
> That is:
>
> - print type(self) in wxFrame alone returns
> - print type(self) in the plugged (multiply in
On 28 Giu, 13:45, Bruno Desthuilliers wrote:
> wxFrame is obviously a new-style class.
I don't know if it's true, however. I tried that:
>>> class A(object):
... def __init__(self):
... print type(self)
...
>>> a=A()
so in fact what I see has something to do with new style cla
On 28 Giu, 13:45, Bruno Desthuilliers wrote:
>
> wrt/ this snippet:
>
> for plugin_name in self.config['plugins']:
> try:
> plugin=__import__(plugin_name)
> try:
> print type(self)
> eval('plugin.'+plugin_name+'Commands._plu
On 28 Giu, 13:45, Bruno Desthuilliers wrote:
> massimo s. a écrit :
>
> >> At this point, it seems too much a deep object-oriented hell to be
> >> able to dig it myself. Would you help me getting some cue on the
> >> problem?
>
> > Update. Now I know
> At this point, it seems too much a deep object-oriented hell to be
> able to dig it myself. Would you help me getting some cue on the
> problem?
Update. Now I know that:
- every sane Python class should return after
type(self)
- when disabling the multiple-inheritance-hack, the situation comes
Before all, I'm not a professional programmer but just a biophysics
ph.d. student, so if something makes you scream of horror, please
forgive me...
Ok, this is not straightforward at all.
I am working on an application that uses plugins. Plugins are coded as
small classes that become inherited by
> No, it removes the association between the name 'item' and the object it is
> currently bound to. In CPython, removing the last such reference will
> cause the object to be gc'ed. In other implementations, actual deletion
> may occur later. You probably should close the files directly and arra
> Relying on the `__del__()` method isn't a good idea because there are no
> really hard guaranties by the language if and when it will be called.
Ok, I read the __del__() docs and I understand using it is not a good
idea.
I can easily add a close_files() method that forces all dangling files
to
> It will delete the *name* `item`. It does nothing to the object that was
> bound to that name. If the name was the only reference to that object, it
> may be garbage collected sooner or later. Read the documentation for the
> `__del__()` method for more details and why implementing such a meth
Hi,
Python 2.4, Kubuntu 6.06. I'm no professional programmer (I am a ph.d.
student in biophysics) but I have a fair knowledge of Python.
I have a for loop that looks like the following :
for item in long_list:
foo(item)
def foo(item):
item.create_blah() #<--this creates item.blah;
Isn't the very concept of major releases (1.x, 2.x, 3.x) that they
*can* be not backwards-compatible with previous releases?
m.
--
http://mail.python.org/mailman/listinfo/python-list
On 13 Feb, 12:46, Peter Otten <[EMAIL PROTECTED]> wrote:
> Well, what problems ocurring with
>
> class A: pass
> class B: pass
> class C(A, B): pass
>
> could be avoided by writing
>
> class A: pass
> class B(A): pass
> class C(B): pass
>
> instead? Classes have to be designed for subclassing, so e
22 matches
Mail list logo
