Prevent Tkinter Canvas from resizing

[Eric Wong]

Using Tkinter, I have a Canvas with vertical Scrollbar attached.  At
runtime, I dynamically create Checkboxes on the Canvas, each one on a
different row.  When I add a lot of Checkboxes, instead of the
scrollbar kicking in, the Canvas resizes and subsequently, my
Application window resizes such that it is larger than my monitor.

Can I prevent the Canvas from resizing when I am creating widgets on it
at runtime?  I want to use the scrollbars when there are more
Checkboxes than will fit on the visible Canvas.  Is this possible?
Thanks for any help.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why PyObject_VAR_HEAD?

[Eric Wong]

kio wrote:

> Hi,
> 
> I'm studying the CPython source code. I don’t quite understand why
> they’re using PyObject_VAR_HEAD to define struct like PyListObject. 
To
> define such kind of struct, could I use _PyObject_HEAD_EXTRA as a
> header and add "items" pointer and "allocated" count explicity? Is
> there any difference?
> 
> Thanks.
> 
> Eric

first, _PyObject_HEAD_EXTRA is only useful for debug and defined as:
#ifdef Py_TRACE_REFS
   #define _PyObject_HEAD_EXTRA \
  struct _object *_ob_next;   \
  struct _object *_ob_prev;
   #define _PyObject_EXTRA_INIT 0, 0,
#else 
   #define _PyObject_HEAD_EXTRA
   #define _PyObject_EXTRA_INIT
#endif

and PyObject_HEAD is defined as
#define PyObject_HEAD\
   _PyObject_HEAD_EXTRA  \
   int ob_refcnt;\
   struct _typeobject *ob_type;

PyObject_VAR_HEAD defined as
#define PyObject_VAR_HEAD   \
   PyObject_HEAD\
   int ob_size;

so you can see the differences between them here.
PyListObject is defined as
typedef struct{
PyObject_VAR_HEAD
PyObject **ob_item;
int allocated;
}PyListObject;

After unfolding these macros we can get
typedef struct{
_PyObject_HEAD_EXTRA
int ob_refcnt;
struct _typeobject *ob_type;
int ob_size;
PyObject **ob_item;
int allocated;
}PyListObject;

So, if we don't use macros, we have to specify not only the "item" and 
"allocated", but also the ref count and type information of the object 
and the size info for a variable object. These information is not only 
used by PyListObject, but also PyStringObject and PyDictObject, so 
macros make it convenient and consize. 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How Python Implements "long integer"?

[Eric Wong]

Pedram wrote:

> Hello Mr. Dickinson. Glad to see you again :)
> 
> On Jul 6, 5:46 pm, Mark Dickinson  wrote:
>> On Jul 6, 1:24 pm, Pedram  wrote:
>>
>> > OK, fine, I read longobject.c at last! :)
>> > I found that longobject is a structure like this:
>>
>> > struct _longobject {
>> > struct _object *_ob_next;
>> > struct _object *_ob_prev;
>>
>> For current CPython, these two fields are only present in debug
>> builds;  for a normal build they won't exist.
> 
> I couldn't understand the difference between them. What are debug
> build and normal build themselves? And You mean in debug build
> PyLongObject is a doubly-linked-list but in normal build it is just 
an
> array (Or if not how it'll store in this mode)?
> 
we use the macro Py_TRACE_REFS to differ the code for debug build and 
normal build, that's to say, in debug build and normal build the codes 
are actually *different*. In debug build, not only PyLongObject but 
all Objects are linked by a doubly-linked-list and it can make the 
debug process less painful. But in normal build, objects are 
seperated! After an object is created, it will never be moved, so we 
can and should refer to an object only by it's address(pointer). 
There's no one-big-container like a list or an array for objects.

-- 
http://mail.python.org/mailman/listinfo/python-list