Python3 - encoding issues
Hello,
at first i must beg the pardon of those from you, whose mailboxes got
flooded by my last announcement of depikt. I myself get no emails from
this list, and when i had done my corrections and posted each of the
sligthly improved versions, i wasn't aware of the extra emails that
produces. Sorry !
I read here recently, that some reagard Python3 worse at encoding
issues than former versions. For me, a German, quite the contrary is
true. The automatic conversion without an Exception from before 3 has
caused pain over pain during the last years. Even some weeks before it
happened, that pygtk suddenly returned utf-8, not unicode, and my
software had delivered a lot of muddled automatically written emails,
before i saw the mess. Python 3 would have raised Exceptions - however
the translation of my software to 3 has just begun.
Now there is a concept of two separated worlds, and i have decided to
use bytes for my software. The string representation, that output
needs anyway, and with depikt and a changed apsw (file reads anyway)
or other database-APIs (internally they all understand utf-8) i can
get utf-8 for all input too.
This means, that i do not have the standard string methods, but
substitutes are easily made. Not for a subclass of bytes, that
wouldn't have the b"" initialization. Thus only in form of
functions. Here are some of my utools:
u0 = "".encode('utf-8')
def u(s):
if type(s) in (int, float, type): s = str(s)
if type(s) == str: return s.encode("utf-8")
if type(s) == bytes: # we keep the two worlds cleanly separated
raise TypeError(b"argument is bytes already")
raise TypeError(b"Bad argument for utf-encoding")
def u_startswith(s, test):
try:
if s.index(test) == 0: return True
except:# a bit frisky perhaps
return False
def u_endswith(s, test):
if s[-len(test):] == test: return True
return False
def u_split(s, splitter):
ret = []
while s and splitter in s:
if u_startswith(s, splitter):
s = s[len(splitter):]; continue
ret += s[:s.index[splitter]]
return ret + [s]
def u_join(joiner, l):
while True:
if len(l) in (0,1): return l
else: l = [l[0]+joiner+l[1]]+l[2:]
(not all with the standard signatures). Writing them is trivial. Note
u0 - unfortunately b"" doesn't at all work as expected, i had to learn
the hard way.
Looking more close to these functions one sees, that they only use the
sequence protocol. "index" is in the sequence protocol too now - there
the library reference has still to be updated. Thus all of these and
much more string methods could get to the sequence protocol too
without much work - then nobody would have to write all this. This
doesn't only affect string-like objects: split and join for lists
could open interesting possibilities for list representations of trees
for example.
Does anybody want to make a PEP from this (i won't do so) ?
Joost Behrends
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python3 - encoding issues
Ohhh - that's nice. But no words of that in the library reference here: http://docs.python.org/3.1/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range Still this fails: >>> a = (1,2,3,4) >>> print(a.startswith((1,2))) Traceback (most recent call last): File "", line 1, in AttributeError: 'tuple' object has no attribute 'startswith' Still methods of this kind would have a better place in the sequence protocol. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python3 - encoding issues
No, sorry, i must correct me. There is a paragraph below on the quoted site. ".index" is still under "Mutable sequence types" - but bytes are treated below. -- http://mail.python.org/mailman/listinfo/python-list
Documentation bugs in 3.1 - C-API - TypeObjects
Hello, this page http://docs.python.org/3.1/c-api/typeobj.html has a bad error: " PyTypeObject* PyObject.ob_type This is the type’s type, in other words its metatype. It is initialized by the argument to the PyObject_HEAD_INIT macro, and its value should normally be &PyType_Type. However, for dynamically loadable extension modules that must be usable on Windows (at least), the compiler complains that this is not a valid initializer. Therefore, the convention is to pass NULL to the PyObject_HEAD_INIT macro and to initialize this field explicitly at the start of the module’s initialization function, before doing anything else. This is typically done like this: Foo_Type.ob_type = &PyType_Type; " This cannot work, because Foo_Type is no PyObject but a PyVarObject (independent of the use of PyVarObject_HEAD_INIT or PyObject_HEAD_INIT). The code line would work so: ((PyObject *)&Foo_Type)->ob_type = &PyType_Type But in the Tutorial for Extensions and Embedding we are advised as follows: " This is so important that we’re going to pick the top of it apart still further: PyVarObject_HEAD_INIT(NULL, 0) This line is a bit of a wart; what we’d like to write is: PyVarObject_HEAD_INIT(&PyType_Type, 0) as the type of a type object is “type”, but this isn’t strictly conforming C and some compilers complain. Fortunately, this member will be filled in for us by PyType_Ready(). " What now ? Another problem, which might be a documentation bug, is the last sentence here: " destructor PyTypeObject.tp_dealloc A pointer to the instance destructor function. This function must be defined unless the type guarantees that its instances will never be deallocated (as is the case for the singletons None and Ellipsis). The destructor function is called by the Py_DECREF() and Py_XDECREF() macros when the new reference count is zero. At this point, the instance is still in existence, but there are no references to it. The destructor function should free all references which the instance owns, free all memory buffers owned by the instance (using the freeing function corresponding to the allocation function used to allocate the buffer), and finally (as its last action) call the type’s tp_free function. If the type is not subtypable (doesn’t have the Py_TPFLAGS_BASETYPE flag bit set), it is permissible to call the object deallocator directly instead of via tp_free. " What ? Where do we "call" these methods ? Primarily we write them down to get members of the Foo_Type struct and our question is where. Shall this sentence mean, that we write the function, we'd normally use for tp_dealloc und which behaves like it, to the place of tp_free ? I've run into terrible trouble with extension classes, which have neither members nor init. They work (and i am quite happy about that) but finding out, that tp_dictoffset had to be set (for what i wanted) took more than a day of searching - including öecture of typeobject.c and object.c - and i cannot derive from them. class(my_extension_class): ... doesn't crash, but results in objects, which have the type my_extension_class, what means, that they do not call their __init__. In certain circumstances a correct tp_free seems to be a premise for inheritance, thus i'd very like to understand the quoted passage. Joost -- http://mail.python.org/mailman/listinfo/python-list
Re: More Python versions on an XP machine
Hi, there are several ways to do that besides starting python scripts with a double-click on a desktop icon (that can only work with the one and only python version of the registry). One is to start the new python version directly from a "DosBox". You could copy python.exe or pythonw.exe from the new version directly into the directory, where your python script is - both are only some kB large - and then execute "python your_script" in the cmd.exe. After some "cd"s to the directory of your script. Besides - it is no bad idea to have some copies of the cmd.exe at several places of your file system - the correct run of cmd.exe is not depending on its place in C:\Windows\system32. It also runs from external disks. This is, how i do that, not optimal probably, but easy to understand. Joost -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation bugs in 3.1 - C-API - TypeObjects
Thanks ! Okay, i've already used the call of tp_free as the last statement in tp_dealloc and do understand now, that a call of tp_dealloc should be the last statement in the code for tp_free in specific cases. And yes, "Py_Type(&Foo_Type) = &PyType_Type" will be more stable against changes of the object implementation. Still there remains the difference to what is told with the Noddy_Type in the tutorial. Skimmimg through PyType_Ready in typeobject.c i find, that 3760 if (Py_TYPE(type) == NULL && base != NULL) 3761 Py_TYPE(type) = Py_TYPE(base); are the only lines referring to what is ob_type now. Thus the quoted lines from the tutorial ending with "Fortunately, this member will be filled in for us by PyType_Ready()." are possibly wrong (respective outdated) too. The two lines above are, what happens to my extension classes, if i want to derive application classes from them. class(my_extension_class): ... will of course call more from Python than PyTypeReady, but PyType(type) = Py_TYPE(base) is not getting corrected by this "more" here and the class statement doesn't create a new type. I will examine now, why this happens (without a crash of the calling application !), but still welcome every hint. Seen from a strict perspective this is a bug in Python's C-API. I'll save a freeze of the code for my extension for anyone, who might interested to reproduce this. Joost -- http://mail.python.org/mailman/listinfo/python-list
Re: Documentation bugs in 3.1 - C-API - TypeObjects
Thanks a second time - the picture has gotten clearer indeed. But for third-party readers the complexities of this matter require the correction, that "Py_Type(&Foo_Type) = &PyType_Type" must be: "Py_TYPE(&Foo_Type) = &PyType_Type " - or am i completely wrong ? Joost -- http://mail.python.org/mailman/listinfo/python-list
Announcement: depikt - the minimalistic python gate to gtk
Hi all, these days i make depikt, a python C-extension for building apps with gtk. It was a challenge for me and big fun. From its short description on sourceforge.net: "Python-3 wrappers for GTK. A minimalistic approach - just suited for GUI-building of apps, in no way for widget-building. Currently 1250 lines for 15 widgets with about 100 methods ... " depikt is advanced enough now to begin the transition of an 8MB python app of me to it - simultaneously with the transition to Python-3 and English. During this process depikt will grow to support for perhaps 25 widgets and 200 methods. From gobject it has connect(), connect_after(), handler_block(), handler_unblock() and handler_is_connected(). Still its status is marked as PreAlpha and depikt not entered to the Python wiki, because gtk_container_set_focus_chain() is defunct now - a vital method for fine usable applications. It's difficult to find out why - as it is the code was working for some time. depikt is very minimalistic: No python attributes of its classes, let alone properties No __repr__, no standard __init__ No support for set_property, get_property No real class hierarchy, there is one abstract base class Pikt, from which all concrete widgets are inheriting directly No exposing of Glib to python (but all i need from pango, cairo and gdk) Thus the code is very petty, well understandable and easy to extend to support for other widgets. That was the primary design goal, together with exact control of encoding issues, support for Python-3 and registry- and autoconf-free installation. Exception handling is about average now - there no mimimalism is intended, quite the contrary (for the long run). depikt will get to some mature state in 2010 - with perhaps about 3.000 lines then. One C-file will always be sufficient. atk might be added by means of a second file, also support for gtk.TreeView might get an own file - but both directly inserted by #include (no .h planned). Enjoy, Joost -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there something similar to list comprehension in dict?
NB: I wondered about about dict(one=1, two=2) - why not d = {one:1,
two:2} ? Since you do not write L=list((1, 2)) either. These composed
objects as basic building blocks make Python code so dense and
beautiful, thus using "{}" means embracing the language's concept.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question about scrapy tutorial
Sorry, i have no idea what scrapy is - but i see, that you try to use idle with pipes or anything like that. That cannot work. idle doesn't even handle __file__ correctly. Use a full-fledged python IDE (PyDev under Eclipse leaves very few wishes open) or test in a python interpreter shell. Good luck, DreiJane -- http://mail.python.org/mailman/listinfo/python-list
depikt (gtk-wrappers): Threads, code-inlining Pixbufs
Hello, these days i make depikt, my replacement of pygtk. There are several reasons to do this: - Support for Python3 - Exact control of encoding issues. I myself (a German) hope to abandon with any python unicode objects forever in future - that is, why Python3 is an important improvement for me. I'll also make a version of apsw leaving the utf-8-code sqlite works with alone. And in the long run one of the python-API of the monet database perhaps A preprocessor macro -DDEPIKT_USES_BYTES decides, whether depikt communicates with python via bytes or (unicode) strings - the actual setting in setup.py is, that DEPIKT_USES_BYTES is defined. - Readability and changability of code. pygtk's hundreds of files are too much for me - since i will make own widgets with C, not python, the work of understanding this source code would be wasted for me. All the more, as pygtk's sources are templates for an own templating system, not .c-files - can this really be called "open source" ? - "Ambulancy". All other tools i use can be installed by simple copying (or compiling via distutils without autoconf) without admin rights: eclipse with pydev, mingw, gcc4.4, apsw, cython, gtk are "ambulant". Only setting the environment variable PATH in a local environment is needed for gtk. Not so pygtk: It searches for python in the windows registry or has to be compiled with autoconf. There are not neglectable traces of trouble with installing pygtk on the web. A drawback: To install depikt you must compile it. But by pythons distutils, which make compiling absolutely easy. Still you have to edit the provided setup.py, i will not automatize the use of the output of pkg-config for gtk. But that really doesn't need much C- knowledge (a little bit knowledge of how C-compilers work is essential though). depikt comes with new features: depikt.gdk_threads_enter (and leave) is supported. Again controlled by a preprocessor macro -DDEPIKT_SUPPORTS_THREADS. #ifdef DEPIKT_SUPPORTS_THREADS (what is the default), each gtk.main() has to be prepended by depikt.gdk_threads_enter(). Admittedly this isn't really tested now. Since you must arrange setup.py anyway to use depikt, these macros are no obstacle. Nevertheless i will keep the number of such #defines small (certainly below 10). depikt also provides a way of inlining icons (and images at all) in python code now.. depikt.gdk_Pixbuf.serialize() renders gdk.pixbufs to a representation in bytes objects of Python3. These are not really well readable or usable but python's array.array.fromstring() and array.array.tostring() are used to provide a well readable and well code-usable representation of these bytes objects. There is PixbufLister.py in tools.tgz now, creating those array-representations (arrays of unsigned 8-bit-ints). Again Python3 is essential here. depikt also provides the standard dialogs in tools.tgz now - they use a serialized (and public domain) back-icon of WindowsXP. The script Dialogs.py is also a severe test of depikt's usability, since using moreover grandchildren of depikt.Window and python threads - unfortunately this script crashes sometimes due to the bad support for widget destruction in depikt. Again: I urgently need depikt for a large python project. Adapting depikt for it will make depikt better usable and really stable sometimes in 2010. depikt will prevail. There is no way for me without depikt. Thanks for reading, DreiJane -- http://mail.python.org/mailman/listinfo/python-list
depikt (gtk-wrappers): Threads, inlining Pixbufs to python code
Hello, these days i make depikt, my replacement of pygtk. There are several reasons to do this: - Support for Python3 - Exact control of encoding issues. I myself (a German) hope to abandon with any python unicode objects forever in future - that is, why Python3 is an important improvement for me. I'll also make a version of apsw leaving the utf-8-code sqlite works with alone. And in the long run one of the python-API of the monet database perhaps A preprocessor macro -DDEPIKT_USES_BYTES decides, whether depikt communicates with python via bytes or (unicode) strings - the actual setting in setup.py is, that DEPIKT_USES_BYTES is defined. - Readability and changability of code. pygtk's hundreds of files are too much for me - since i will make own widgets with C, not python, the work of understanding this source code would be wasted for me. All the more, as pygtk's sources are templates for an own templating system, not .c-files - can this really be called "open source" ? - "Ambulancy". All other tools i use can be installed by simple copying (or compiling via distutils without autoconf) without admin rights: eclipse with pydev, mingw, gcc4.4, apsw, cython, gtk are "ambulant". Only setting the environment variable PATH in a local environment is needed for gtk. Not so pygtk: It searches for python in the windows registry or has to be compiled with autoconf. There are not neglectable traces of trouble with installing pygtk on the web. A drawback: To install depikt you must compile it. But by python's distutils, which make compiling absolutely easy. Still you have to edit the provided setup.py, i will not automatize the use of the output of pkg-config for gtk. But that really doesn't need much C- knowledge (a little bit knowledge of how C-compilers work is essential though). depikt comes with new features: depikt.gdk_threads_enter (and leave) is supported. Again controlled by a preprocessor macro DEPIKT_SUPPORTS_THREADS. #ifdef DEPIKT_SUPPORTS_THREADS (what is the default), each gtk.main() has to be prepended by depikt.gdk_threads_enter(). Admittedly gtk-threads aren't really intensively now. Since you must arrange setup.py anyway to use depikt, these macros are no obstacle. Nevertheless i will keep the number of such preprocessor #defines small (certainly below 10). depikt also provides a way of inlining icons (and images at all) in python code now. depikt.gdk_Pixbuf.serialize() renders gdk.pixbufs to a representation in bytes objects of Python3. These are not really well readable or usable, but python's array.array.fromstring() and array.array.tostring() are used to provide well readable and well code-usable representations of these bytes objects. There is PixbufLister.py in tools.tgz now, creating those array-representations (arrays of unsigned 8-bit-ints). Again Python3 is essential here. depikt also provides the standard dialogs in tools.tgz now - they use a serialized (and public domain) back-icon of WindowsXP. The script Dialogs.py is also a severe test of depikt's usability, since using moreover grandchildren of depikt.Window and python threads - unfortunately this script crashes sometimes due to the bad support for widget destruction in depikt. Again: I urgently need depikt for a large python project. Adapting depikt for it will make depikt better usable and really stable sometimes in 2010. depikt will prevail. There is no way for me without depikt. Thanks for reading, DreiJane -- http://mail.python.org/mailman/listinfo/python-list
depikt (gtk-wrappers): Threads, inlining Pixbufs to python code
Hello, these days i make depikt, my replacement of pygtk. There are several reasons to do this: - Support for Python3 - Exact control of encoding issues. I myself (a German) hope to abandon with any python unicode objects forever in future - that is, why Python3 is an important improvement for me. I'll also make a version of apsw leaving alone the utf-8 sqlite works with. And in the long run perhaps one of the python-API of the monet database. A preprocessor macro DEPIKT_USES_BYTES decides, whether depikt communicates with python via bytes or (unicode) strings - the actual setting in setup.py is, that DEPIKT_USES_BYTES is defined. - Readability and changability of code. pygtk's hundreds of files are too much for me - since i will make own widgets with C, not python, the work of understanding this would be wasted for me. All the more, as pygtk's sources are templates for an own templating system, not .c-files - can this really be called "open source" ? - "Ambulancy". All other tools i use can be installed by simple copying (or compiling via distutils without autoconf) without admin rights: eclipse with pydev, mingw, gcc4.4, apsw, cython, gtk are "ambulant". Only setting the environment variable PATH in a local environment is needed for gtk. Not so pygtk: It searches for python in the windows registry or has to be compiled with autoconf. There are not neglectable traces of trouble with installing pygtk on the web. A drawback: To install depikt you must compile it. But by python's distutils, which make compiling absolutely easy. Still you have to edit the provided setup.py, i will not automatize the use of the output of pkg-config for gtk. But that really doesn't need much C- knowledge (a bit knowledge of how C-compilers work is essential though). depikt comes with new features: depikt.gdk_threads_enter (and leave) is supported. Again controlled by a preprocessor macro DEPIKT_SUPPORTS_THREADS. #ifdef DEPIKT_SUPPORTS_THREADS (what is the default), each gtk.main() has to be prepended by depikt.gdk_threads_enter() and - with more than one - must be followed by gdk_threads_leave(). Admittedly gtk-threads aren't really intensively tested now (but gdk_threads_enter is only protecting values in the thread's namespace and is safely ignored, when gtk is initialized without support for threads). Since you must arrange setup.py anyway to use depikt, these macros are no obstacle. Nevertheless i will keep the number of such preprocessor #defines small (certainly below 10). depikt also provides a way of inlining icons (and images at all) in python code now. depikt.gdk_Pixbuf.serialize() renders gdk.pixbufs to a representation in bytes objects of Python3. These are not really well readable or usable, but python's array.array.fromstring() and array.array.tostring() are used to provide well readable and well code-usable representations of those bytes objects. There is PixbufLister.py in tools.tgz now, creating those array-representations (arrays of unsigned 8-bit-ints). Again Python3 is essential here. depikt also provides the standard dialogs in tools.tgz now - they use a serialized (and public domain) "back"-icon of WindowsXP. The script Dialogs.py is also a severe test of depikt's usability, since using moreover grandchildren of depikt.Window and python threads - unfortunately this script crashes sometimes due to the bad support for widget destruction in depikt. Again: I urgently need depikt for a large python project. Adapting depikt for it will make depikt better usable and really stable sometimes in 2010. depikt will prevail. There is no way for me without depikt. Thanks for reading, DreiJane -- http://mail.python.org/mailman/listinfo/python-list
depikt (gtk-wrappers): Threads, inlining Pixbufs to python code
Hello, these days i make depikt, my replacement of pygtk. There are several reasons to do this: - Support for Python3 - Exact control of encoding issues. I myself (a German) hope to abandon with any python unicode objects forever in future - that is, why Python3 is an important improvement for me. I'll also make a version of apsw leaving alone the utf-8 sqlite works with. And in the long run perhaps one of the python-API of the monet database. A preprocessor macro DEPIKT_USES_BYTES decides, whether depikt communicates with python via bytes or (unicode) strings - the actual setting in setup.py is, that DEPIKT_USES_BYTES is defined. - Readability and changability of code. pygtk's hundreds of files are too much for me - since i will make own widgets with C, not python, the work of understanding this would be wasted for me. All the more, as pygtk's sources are templates for an own templating system, not .c-files - can this really be called "open source" ? - "Ambulancy". All other tools i use can be installed by simple copying (or compiling via distutils without autoconf) without admin rights: eclipse with pydev, mingw, gcc4.4, apsw, cython, gtk are "ambulant". Only setting the environment variable PATH in a local environment is needed for gtk. Not so pygtk: It searches for python in the windows registry or has to be compiled with autoconf. There are not neglectable traces of trouble with installing pygtk on the web. A drawback: To install depikt you must compile it. But by python's distutils, which make compiling absolutely easy. Still you have to edit the provided setup.py, i will not automatize the use of the output of pkg-config for gtk. But that really doesn't need much C- knowledge (a bit knowledge of how C-compilers work is essential though). depikt comes with new features: depikt.gdk_threads_enter (and leave) is supported. Again controlled by a preprocessor macro DEPIKT_SUPPORTS_THREADS. #ifdef DEPIKT_SUPPORTS_THREADS (what is the default), each gtk.main() has to be prepended by depikt.gdk_threads_enter() and - with more than one - must be followed by gdk_threads_leave(). Admittedly gtk threads aren't really intensively tested now (but gdk_threads_enter is only protecting values in the thread's namespace and is safely ignored, when gtk is initialized without support for threads). Since you must arrange setup.py anyway to use depikt, these macros are no obstacle. Nevertheless i will keep the number of such preprocessor #defines small (certainly below 10). depikt also provides a way of inlining icons (and images at all) in python code now. depikt.gdk_Pixbuf.serialize() renders gdk.pixbufs to a representation in bytes objects of Python3. These are not really well readable or usable, but python's array.array.fromstring() and array.array.tostring() are used to provide well readable and well code-usable representations of those bytes objects. There is PixbufLister.py in tools.tgz now, creating those array-representations (arrays of unsigned 8-bit-ints). Again Python3 is essential here. depikt also provides the standard dialogs in tools.tgz now - they use a serialized (and public domain) "back"-icon of WindowsXP. The script Dialogs.py is also a severe test of depikt's usability, since using moreover grandchildren of depikt.Window and python threads - unfortunately this script crashes sometimes due to the bad support for widget destruction in depikt. Again: I urgently need depikt for a large python project. Adapting depikt for it will make depikt better usable and really stable sometimes in 2010. depikt will prevail. There is no way for me without depikt. Thanks for reading, DreiJane -- http://mail.python.org/mailman/listinfo/python-list
depikt (gtk-wrappers): Threads, inlining Pixbufs to python code
Hello, these days i make depikt, my replacement of pygtk. There are several reasons to do this: - Support for Python3 - Exact control of encoding issues. I myself (a German) hope to abandon with any python unicode objects forever in future - that is, why Python3 is an important improvement for me. I'll also make a version of apsw leaving alone the utf-8 sqlite works with. And in the long run perhaps one of the python-API of the monet database. A preprocessor macro DEPIKT_USES_BYTES decides, whether depikt communicates with python via bytes or (unicode) strings - the actual setting in setup.py is, that DEPIKT_USES_BYTES is defined. - Readability and changability of code. pygtk's hundreds of files are too much for me - since i will make own widgets with C, not python, the work of understanding this would be wasted for me. All the more, as pygtk's sources are templates for an own templating system, not .c-files - can this really be called "open source" ? - "Ambulancy". All other tools i use can be installed by simple copying (or compiling via distutils without autoconf) without admin rights: eclipse with pydev, mingw, gcc4.4, apsw, cython, gtk are "ambulant". Only setting the environment variable PATH in a local environment is needed for gtk. Not so pygtk: It searches for python in the windows registry or has to be compiled with autoconf. There are not neglectable traces of trouble with installing pygtk on the web. A drawback: To install depikt you must compile it. But by python's distutils, which make compiling absolutely easy. Still you have to edit the provided setup.py, i will not automatize the use of the output of pkg-config for gtk. But that really doesn't need much C- knowledge (a bit knowledge of how C-compilers work is essential though). depikt comes with new features: depikt.gdk_threads_enter (and leave) is supported. Again controlled by a preprocessor macro DEPIKT_SUPPORTS_THREADS. #ifdef DEPIKT_SUPPORTS_THREADS (what is the default), each gtk.main() has to be prepended by depikt.gdk_threads_enter() and - with more than one - must be followed by gdk_threads_leave(). Admittedly gtk threads aren't really intensively tested now (but gdk_threads_enter is only protecting values in the thread's namespace and is safely ignored, when gtk is initialized without support for threads). Since you must arrange setup.py anyway to use depikt, these macros are no obstacle. Nevertheless i will keep the number of such preprocessor #defines small (certainly below 10). depikt also provides a way of inlining icons (and images at all) in python code now. depikt.gdk_Pixbuf.serialize() renders gdk.pixbufs to a representation in bytes objects of Python3. These are not really well readable or usable, but python's array.array.fromstring() and array.array.tostring() are used to provide well readable and well code-usable representations of those bytes objects. There is PixbufLister.py in tools.tgz now, creating those array-representations (arrays of unsigned 8-bit-ints). Again Python3 is essential here. depikt also provides the standard dialogs in tools.tgz now - they use a serialized (and public domain) "back"-icon of WindowsXP. The script Dialogs.py is also a severe test of depikt's usability, since using moreover grandchildren of depikt.Window and python threads - unfortunately this script crashes sometimes due to the bad support for widget destruction in depikt. Again: I urgently need depikt for a large python project. Adapting depikt for it will make depikt better usable and really stable sometimes in 2010. depikt will prevail. There is no way for me without depikt. Thanks for reading, DreiJane -- http://mail.python.org/mailman/listinfo/python-list
depikt (gtk-wrappers): Threads, inlining Pixbufs to python code
Hello, these days i make depikt, my replacement of pygtk. There are several reasons to do this: - Support for Python3 - Exact control of encoding issues. I myself (a German) hope to abandon with any python unicode objects forever in future - that is, why Python3 is an important improvement for me. I'll also make a version of apsw leaving alone the utf-8 sqlite works with. And in the long run perhaps one of the python-API of the monet database. A preprocessor macro DEPIKT_USES_BYTES decides, whether depikt communicates with python via bytes or (unicode) strings - the actual setting in setup.py is, that DEPIKT_USES_BYTES is defined. - Readability and changability of code. pygtk's hundreds of files are too much for me - since i will make own widgets with C, not python, the work of understanding this would be wasted for me. All the more, as pygtk's sources are templates for an own templating system, not .c-files - can this really be called "open source" ? - "Ambulancy". All other tools i use can be installed by simple copying (or compiling via distutils without autoconf) without admin rights: eclipse with pydev, mingw, gcc4.4, apsw, cython, gtk are "ambulant". Only setting the environment variable PATH in a local environment is needed for gtk. Not so pygtk: It searches for python in the windows registry or has to be compiled with autoconf. There are not neglectable traces of trouble with installing pygtk on the web. A drawback: To install depikt you must compile it. But by python's distutils, which make compiling absolutely easy. Still you have to edit the provided setup.py, i will not automatize the use of the output of pkg-config for gtk. But that really doesn't need much C- knowledge (a bit knowledge of how C-compilers work is essential though). depikt comes with new features: depikt.gdk_threads_enter (and leave) is supported. Again controlled by a preprocessor macro DEPIKT_SUPPORTS_THREADS. #ifdef DEPIKT_SUPPORTS_THREADS (what is the default), each gtk.main() has to be prepended by depikt.gdk_threads_enter() and - with more than one - must be followed by gdk_threads_leave(). Admittedly gtk threads aren't really intensively tested now (but gdk_threads_enter is only protecting values in the thread's namespace and is safely ignored, when gtk is initialized without support for threads). Since you must arrange setup.py anyway to use depikt, these macros are no obstacle. Nevertheless i will keep the number of such preprocessor #defines small (certainly below 10). depikt also provides a way of inlining icons (and images at all) in python code now. depikt.gdk_Pixbuf.serialize() renders gdk.pixbufs to a representation in bytes objects of Python3. These are not really well readable or usable, but python's array.array.fromstring() and array.array.tostring() are used to provide well readable and well code-usable representations of those bytes objects. There is PixbufLister.py in tools.tgz now, creating those array-representations (arrays of unsigned 8-bit-ints). Again Python3 is essential here. depikt also provides the standard dialogs in tools.tgz now - they use a serialized (and public domain) "back"-icon of WindowsXP. The script Dialogs.py is also a severe test of depikt's usability, since using moreover grandchildren of depikt.Window and python threads - unfortunately this script crashes sometimes due to the bad support for widget destruction in depikt. Again: I urgently need depikt for a large python project. Adapting depikt for it will make depikt better usable and really stable sometimes in 2010. depikt will prevail. There is no way for me without depikt. Thanks for reading, DreiJane -- http://mail.python.org/mailman/listinfo/python-list
Re: Python, Reportlabs, Pil and Windows 7 (64bit)
Hello, i've used reportlabs over two years now and was content with its quality. These days i have turned to cairo and can only recommend to do so: It is still easier to use (than the well-designed reportlabs tools) and an engine working in a lot of other software too, for example firefox. Reasons for this: reportlabs do not even answer question about the date to upgrade to Python3. Since Platypus isn't complete, i had to do a lot with the primitves in the canvas object after all - that part of my code got even shorter with cairo. For me - working with pygtk - that spares two installations also. To repear myself: I love cairo. Regards, Joost -- http://mail.python.org/mailman/listinfo/python-list
Re: sqlite3, memory db and multithreading
Hello, i cannot help you directly with sqlite2 in the Standardlib, since i am used to work with Roger Binns's apsw. After a short experiment with pysqlite leading to data loss - caused by one of the unclearer exception messages of sqlite3 and me having a bad day - i at once turned back to apsw. And so far i haven't done much with threads. Principally sqlite connections (sqlite3 objects in the C-API) can be used over multiple threads - and connections to :memory: make no difference. There are additional parameters to open() giving fine- tuned control. And apsw is promising a true reflection of sqlite's C- API. Regards, Joost -- http://mail.python.org/mailman/listinfo/python-list
Re: Python question
Hello,
Python and gtk are "ambulant" (portable plus intallable by mere
copying without admin rights). gtk only needs to have the path to its /
bin on the PATH . The latter could - and possibly should be - done by
the Python scripts using it, for example:
s = os.environ['PATH']
if s.find(gtkBinDir) == -1: os.putenv("PATH", os.getenv("PATH")+
os.pathsep + gtkBinDir)
for gtkBinDir from some GlobalConstants.py.
Pygtk breaks that "ambulance" - its parts use the registry, but only
for finding Python during installation. Afterwards such a Python is
ambulant again - that means with its pygtk (this little flaw is a
minor reason for me to work on my depikt). I am on Windows normally,
but never considered pywin.
Good luck, Joost
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python question
Rereading my sent answer i wondered, what the variable s was used for
besides that "find" and found nothing. Without it also the layout is
better:
if os.environ['PATH'].find(gtkBinDir) == -1:
os.putenv("PATH", os.getenv("PATH")+
os.pathsep + gtkBinDir)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Destructor being called twice?
Hello, i'd like to comment a bit off-topic. The way you call gtk.main_quit() is probably not the safest. Callling gtk.main_quit() from a lambda expression is in the tutorials, but never worked on my WindowsXP (SP3 too). The delete-event is the last event before the "destroy" and the place for callbacks like "Do you really want to ", "You have changed data - Save ?" and so on. It can even be used not to shutdown eventually. gtk.main_quit() is better connected to "destroy" of the toplevel window of your app. Connecting it to any event before could cause leaking for example (and there is a possibility, that this causes the strange behavior you noticed). Then "A().show()" - do you really want to create such an anonymous gtk.Window ? Why not the natural my_app_window = A() ... A.show(); ? Kind regards, Joost -- http://mail.python.org/mailman/listinfo/python-list
