>
> So when you exec 'a = "B"' in globals(), locals() you might think you
> were changing the local namespace. In fact you are changing a copy of
> the local namespace:
>
Well, that explains much, but not all that I want to be explained. Why?
Because now I understand, that by invoking
exec "a =
> Use the exec statement without the in-clause to get the desired effect:
>
> >>> def f():
> ... a = "a"
> ... exec "a = 'B'"
> ... print a
> ...
> >>> f()
> B
>
Well... I *do* realize that. But this is *not* my problem. I have a
function with another nested one. If I used "exec ..."
I have the following code:
---
def f():
def g():
a = 'a' # marked line 1
exec 'a = "b"' in globals(), locals()
print "g: a =", a
a = 'A' # marked line 2
exec 'a = "B"' in globals(), locals()
print "f: a =", a
g()
f(
Hello, I have another, probably stupid, question.
I'm working on some Python project, and I use some extensions written
in C. I do all the development on my GNU/Linux box, so my setup.py
script works just as it's supposed to work on a GNU/Linux system. But
in the nearest future I'll have to make a
he declaration of the Obj class will explain
everything:
class Obj( Object ):
...
So the Obj class is an *extension* of the Object class. Therefore I
wrote that "Obj is just an Object". I (mis?)used the vocabulary from
OO: something may *be* a kind of something else (inheritance),
Thank you VERY much!
These other errors are not so serious. I think I'll fix them soon. The
most important thing is that now I'm ready to work on that code again.
Life is beautiful again!
Damn, I knew it is some very stupid mistake. I must learn how to use
that pylint, instead of asking people on
System1()
File "test.py", line 81, in __init__
self.objA.demandNewLink( 'B' )
File "/home/tpj/opt/Praca/Programy/PyObject/workdir/PyObject.py",
line 503, in demandNewLink
s_object )
File "/home/tpj/opt/Praca/Programy/PyObject/workdir/PyObject.py"
I'm trying to get a wrapper for my C code in order to be able to use it
as a module in Python. I'm doing it as follows:
C code (file_c.c):
---
#include
void hello( int size )
{
printf("Hello! %d\n", size);
}
---
Pyrex code (file.pyx):
---
OT:
> BTW: I wonder if and when someone will use stackless python (...)
And what is this stackless python? I have visited it's homepage, but I
wasn't able to find any answer. (Well, I have found out, that stackles
python is python's implementation that doesn't use C stack, but it
tells me nothing
> Beside this, wxPython (and wxWidgets) is often told to be more complete,
> better documented and better supported than GTK/PyGTK.
Is wxPython often told to be more documented? By who?
Several months ago I wanted to choose a nice GUI for Python (Tkinter
was out of question). I choosed PyGTK for
Well, I think I must answer to my own post...
There is at least one reason to bother with executables. I have just
read a message. Someone wanted to run a program written in Python +
wxPython. But he has failed. Why? Because the version of wxPython on
his system was newer and it's API was differen
Recently I was considering the choice of PyGTK or wxPython. They are
both rich GUI libraries, and they both are cross-platform ones (well...
they work on GNU/Linux and on Windows).
I chose PyGTK, because it has *much* better documentation (I wasn't
very happy when I had to look for information in
It's just the same as with Java, GTK+, Qt or any other
library/platform. If you're doing development with Java, you can use
any version that you like (for example the version 1.5) - and your
application probably won't be able to run by an older version of Java.
The same is with, for example, GTK+ l
> I should have added that my platform is Linux.
In this case you shouldn't bother yourself with executables. Python is
available on any major distribution.
My Python apps are available as pyc files for Linux (and for those
Windows users, who have Python installed) and as executables for Win
(for
"The advantage of xrange() over range() is minimal (since xrange()
still has to create the values when asked for them) except when a very
large range is used on a memory-starved machine or when all of the
range's elements are never used (such as when the loop is usually
terminated with break)." - f
There are two things I don't like about messages you got.
> checking for g++ ... no
and
> C++ compiler cannot create executables
There are two possibilities I can think of now. The first is you have
no g++ installed. In this case you should install it (I think it would
be very easy, you could
I have encountered some problems with PyGTK only when I was trying to
install a PyGTK version that was different from the installed GTK+
version. When those both versions were the same, I had no problems at
all.
(Another problem with PyGTK is that it's installation is somewhat more
complicated tha
Why not start with Python's standard documentation? There are Python
Tutorial and Library Reference. IMHO it's the best place to start.
--
http://mail.python.org/mailman/listinfo/python-list
Thanks a lot!
Now I know I can choose PyGTK. I really like it because of its rich
documentation.
> You could also bundle the runtime DLLs with your py2exe'd application
That's great. I think my clients will appreciate a single one
executable.
--
http://mail.python.org/mailman/listinfo/python-l
> PyQt works equally well on both systems.
I believe you. The problem is I don't like GPL.
--
http://mail.python.org/mailman/listinfo/python-list
> I've used pygtk with success on windows. (...)
> > [will] I be able to make an executable (using Py2Exe) of an application
> > that uses PyGTK?
>
> Yes.
So PyGTK is now my favourite. Better documentation, runs on Linux and
Windows, the possibility to make an executable program with Py2Exe.
It's
GUI's etc: PyGtk on Windows
"(...) So if someone develops mainly for X and just wants to make sure
that it is not impossible to run on Windows, you can use PyGTK. (...)",
July 2nd, 1999
pyGTK on Windows
"(...)
> can i use pyGTK under
> Windows???
It's probably doable (...) but not worthy in my op
I've heard about this "EasyInstall" and I like this idea.
If EI becomes a part of Python's standard library, my script will use
it.
--
http://mail.python.org/mailman/listinfo/python-list
> So, to make sure I've understood (...) : you want to provide
> a specialized install script for Python (3rd party modules,
> non-standard locations, etc.)
yes
> You started in bash to deal with minority cases without an extant
> Python install.
My motivation was rather to avoid a bootstrap-l
> (...) I've seen the claim that every Linux
> distro comes with Python installed, but can't verify it.
So have I. And I think it might be truth. The only problem is that
different distros might be released with different versions of Python.
> Then again, the same comments apply to bash. Distri
First I have to admit that my English isn't good enough. I'm still
studying and sometimes I just can't express what I want to express.
A few weeks ago I've written 'Python Builder' - a bash script that
allows anyone to download, compile (with flags given by user) and
install Python and some exter
26 matches
Mail list logo
