Seem to be having trouble with Python/Bethon.

[Zoo Keeper]

class foo(BWindow.BWindow):
... pass
...
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: base is not a class object

Not entirely sure what the message means (beyond the obvious that it
does not believe the class is a class, so to speak). (Btw, I did
previously import BWindow).

Anyone here have BeOS experience with Python? The "rest" of python
works fine. I've built and added packages to it and am in the process
of coding an application which I will, eventually, want a front end for.

Thanks!

Mike

 

[Zoo Keeper]

No takers, eh? :/

I can't be the only python user on BeOS...

The only thing I can think of is that I am running "bone".

Mike

 

[Donn Cave]

Quoth Zoo Keeper <[email protected]>:
| No takers, eh? :/
|
| I can't be the only python user on BeOS...
|
| The only thing I can think of is that I am running "bone".

Well, at least now we know one thing about your setup.

In later versions, a Python class can definitely inherit
from BWindow. If you have the 0.5.1 distribution, the
programs in "test" do it that way, and they work. Earlier
versions, before 0.5.0, can't do this (and neither can
older versions of Python.) It is certainly possible to
mess up the BeOS libraries while trying to improve them,
though, as demonstrated by the 3rd party "Developer Edition".
That certainly could be your problem.

You're not the only Python user on BeOS, but they are few.
Given the level of general interest, I think you'd have
better odds posting to comp.sys.be.programmer.

As for what I read as your implicit question, will you be
sorry you chose to develop your application in Python with
a Bethon UI - it depends on the details. The functions
available here are numerous but not nearly the whole Be API,
and there are whole areas of functionality that it will
probably never get into. It's pretty useful for casual
stuff, but probably not for real hard core polished
applications. Distribution will be a harder, too, than
a straight C++ program.

Donn Cave, (e-mail address removed)

 

[Zoo Keeper]

Don! You've done great work. I suppose I can try rebuilding after switching
back to net_server. I have 2.2.2 w/0.5.0 and that failed as well, btw. I
apologize for not providing more information, I did not seek to irritate you.
:/ (as you sound in your response) and I appreciate all the work you've done.

Neither did I mean to imply that I was not sure if I wanted to use
Python/Bethon. I love Python, and I love BeOS. Bethon seems to be the way to
go, altho' I need to learn Bethon.

So, anyway, I will try switching back to net_server, building 0.5.1 for 2.2.2
and give it another go.

Mike

 

[Michael S. Jessop]

Rebuilt with Net_Server. Works fine now.

Mike

 

[Donn Cave]

Quoth Michael S. Jessop <[email protected]>:
| Rebuilt with Net_Server. Works fine now.

Thanks, that's interesting. I would not have guessed that the
host network implementation could be a factor in the Python
type/class internals that seemed to be failing for you, so I'm
guessing that when you choose between the two, there are some
other things that come along that have nothing to do with the
network. I'm actually running a BONE system right now, as I
type this, and the Python inheritance works fine - Zeta RC1.
Python+Bethon comes on the CD, but looks like it's the standard
issue software built on 5.03 (and has a problem with the Zeta
internationalization software, crashes on exit after I suppose
it freed something it wasn't supposed to.)

Donn Cave, (e-mail address removed)

 

[Donn Cave]

Quoth Zoo Keeper <[email protected]>:
....
| Neither did I mean to imply that I was not sure if I wanted to use
| Python/Bethon. I love Python, and I love BeOS. Bethon seems to be the way to
| go, altho' I need to learn Bethon.

As far as I know, there's no alternative. Just wanted to point out
that some limitations and impediments come with this path, compared
to C++.

On the other hand, Python may actually solve one problem that some
people claim is serious defect of BeOS. When Be was alive, the
pervasively multithreaded architecture was supposed to be a big
advantage, but after they crashed, even Be engineers came out of
the woodwork to claim that the concurrency issues posed too difficult
of a problem for most developers and were thus responsible for a lot
of unreliable software.

I loved the thread-per-window architecture myself and never noticed
any problem, and at first I figured that might have been because
I fastidiously follow a queuing, event I/O model for thread interop
in my own application. But Python itself takes some of the teeth
out of concurrency problems, because the interpreter doesn't run
in parallel. So while your program executes in parallel, your code
doesn't - only the library functions are parallel.

Donn Cave, (e-mail address removed)

 

[Michael S. Jessop]

That IS interesting. :/ Granted my machine was customized to some extent, but
it was basically 5.03 Pro, with BONE and OpenTracker and Mail Daemon
replacement.

I did also install the LibPak.

Mike