Re: PYTHONDOCS on OSX

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 "Robert Hicks" <[EMAIL PROTECTED]> wrote:

> How do I set this variable in my .bash_profile? I have the html docs in
> /usr/local/PythonDocs.

I have a line in my .profile like this:

export PYTHONDOCS='/Users/opstad/Documents/Developer 
Docs/Python-Docs-2.4.1'

So by analogy, you could try adding this to your profile:

export PYTHONDOCS='/usr/local/PythonDocs'

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

Awkwardness of C API for making tuples

[Dave Opstad]

One of the functions in a C extension I'm writing needs to return a 
tuple of integers, where the length of the tuple is only known at 
runtime. I'm currently doing a loop calling PyInt_FromLong to make the 
integers, then PyTuple_New, and finally a loop calling PyTuple_SET_ITEM 
to set the tuple's items. Whew.

Does anyone know of a simpler way? I can't use Py_BuildValue because I 
don't know at compile-time how many values there are going to be. And 
there doesn't seem to be a PyTuple_FromArray() function.

If I'm overlooking something obvious, please clue me in!

Thanks,
Dave Opstad
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awkwardness of C API for making tuples

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 "John Machin" <[EMAIL PROTECTED]> wrote:

> What is the purpose of this first loop?

Error handling. If I can't successfully create all the PyInts then I can 
dispose the ones I've made and not bother making the tuple at all.
> 
> In what variable-length storage are you storing these (Python) integers
> during this first loop? Something you created with (a) PyMem_Malloc (b)
> malloc (c) alloca (d) your_own_malloc?

(b) malloc. The sequence here is: 1) malloc; 2) check for malloc 
success; 3) loop to create PyInts (if failure, Py_DECREF those made so 
far and free the malloc'ed buffer); 4) create new tuple (error checks 
again); and 5) PyTuple_SET_ITEM (no error checks needed)

> 1. Determine the length of the required tuple; this may need a loop,
> but only to _count_ the number of C longs that you have.
> 2. Use PyTuple_New.
> 3. Loop to fill the tuple, using PyInt_FromLong and PyTuple_SetItem.

This would certainly be simpler, although I'm not sure I'm as clear as 
to what happens if, say, in the middle of this loop a PyInt_FromLong 
fails. I know that PyTuple_SetItem steals the reference; does that mean 
I could just Py_DECREF the tuple and all the pieces will be 
automagically freed? If so, I'll take your recommendation and rework the 
logic this way.

Thanks!
Dave
-- 
http://mail.python.org/mailman/listinfo/python-list

Odd slicing behavior?

[Dave Opstad]

Take a look at this snippet:

>>> class L(list):
...   def __init__(self, v):
... super(L, self).__init__(v)
...   def __setitem__(self, key, value):
... print key.indices(len(self))
... 
>>> v = L(range(10))
>>> v
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> v[::] = [1]
(0, 10, 1)
>>> v[0:10:1] = [1]
(0, 10, 1)

So both assignments result in slices with exactly the same start, stop 
and step values: 0, 10 and 1. Also, the __setitem__ method is being 
called, not the older __setslice__ method; we can tell this because it 
hit the print statement.

However, actually trying to make a slice assignment on a regular list in 
these two ways behaves differently:

>>> v2 = range(10)
>>> v2[0:10:1] = [1]
Traceback (most recent call last):
  File "", line 1, in ?
ValueError: attempt to assign sequence of size 1 to extended slice of 
size 10
>>> v2[::] = [1]
>>> v2
[1]

So given the equality of their slice representations, why do the v2[::] 
and v2[0:10:1] assignments behave differently? My reading of section 
5.3.3 of the manual suggests that these should behave the same.

If I'm just not seeing something obvious, please let me know!

Thanks,
Dave
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Odd slicing behavior?

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:

> So - the rationale seems to be: "When using slice-assignment, a form 
> like l[a:b:c] imposes possibly a non-continous section in l, for which 
> the semantics are unclear - so we forbid it"

But it isn't forbidden:

>>> v = range(10)
>>> v
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> v[0:10:3] = ['a', 'b', 'c', 'd']
>>> v
['a', 1, 2, 'b', 4, 5, 'c', 7, 8, 'd']

The only time it's actively forbidden is when the length of the slice 
and the length of the list being assigned to it don't match.

I agree with you that it might be nice for [a:b:1] and [a:b] to be 
treated synonymously.

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

Using Python to make Cocoa apps on Mac OS X

[Dave Opstad]

FYI:

A new article has been posted at the Apple Developer website:

http://developer.apple.com/cocoa/pyobjc.html

Cheers!
Dave
-- 
http://mail.python.org/mailman/listinfo/python-list

__setslice__ and classes derived from list

[Dave Opstad]

According to the documentation the __setslice__ method has been 
deprecated since Python 2.0. However, if I'm deriving classes from the 
builtin list class, I've discovered I can't really ignore __setslice__. 
Have a look at this snippet:


>>> class V(list):
...   def __setitem__(self, key, value):
... if isinstance(key, slice):
...   print "Slice:", key.start, key.stop, key.step
... else:
...   print "Regular:", key
... super(V, self).__setitem__(key, value)
...   def __setslice__(self, i, j, value):
... print "Old method:", i, j
... super(V, self).__setslice__(i, j, value)
... 
>>> v = V([1,2,4,8])
>>> v
[1, 2, 4, 8]
>>> v[0] = 100
Regular: 0
>>> v
[100, 2, 4, 8]
>>> v[1:3] = [99, 99]
Old method: 1 3
>>> v   
[100, 99, 99, 8]
>>> v[1:3:1] = [88, 88]
Slice: 1 3 1
>>> v
[100, 88, 88, 8]
>>> v[-1] = 12
Regular: -1
>>> v   
[100, 88, 88, 12]
>>> v[-3:-1] = [77, 66]
Old method: 1 3
>>> v
[100, 77, 66, 12]


If I assign to v[1:3] it dispatches via __setslice__, but if I assign to 
v[1:3:1] it dispatches via __setitem__. The documentation states that if 
a __setslice__ method is present it will be used, but if one isn't 
present then a slice will be synthesized and __setitem__ will be used 
exclusively. Since the builtin list class provides a __setslice__ 
method, what this means is that any class derived from list still has to 
make provisions for this ostensibly deprecated method.

There's a workaround for this, namely to include this method:

def __setslice__(self, i, j, seq):
self.__setitem__(slice(i, j), seq)

That way any custom code I need to include in __setitem__ doesn't have 
to be duplicated in __setslice__. But just out of curiosity I thought 
I'd ask the folks here if there's any other way of doing this? Maybe 
something like a "noslicelist" class which doesn't have __setslice__, 
where the standard list class would then be a subclass of noslicelist 
with the __setslice__ method present for compatibility. That way I could 
subclass noslicelist myself, and not have to worry about it.

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

Re: __setslice__ and classes derived from list

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 Michael Hoffman <[EMAIL PROTECTED]> wrote:

> Perhaps you should submit a feature request? It must be time to get rid 
> of __setslice__, if not now, then maybe by Python 3.0.

I'm happy to submit a feature request, once I figure out how to do it!

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

Initializing subclasses of tuple

[Dave Opstad]

I'm hoping someone can point out where I'm going wrong here. Here's a 
snippet of a Python interactive session (2.3, if it makes a difference):

--
>>> class X(list):
...   def __init__(self, n):
... v = range(n)
... list.__init__(self, v)
... 
>>> x = X(10)
>>> x
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> class Y(tuple):
...   def __init__(self, n):
... v = tuple(range(n))
... tuple.__init__(self, v)
... 
>>> y = Y(10)
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: iteration over non-sequence
--

How do I initialize instances of a class derived from tuple, if it's not 
in the __init__ method?

Thanks for any help!
Dave Opstad
-- 
http://mail.python.org/mailman/listinfo/python-list

Is there a short-circuiting dictionary "get" method?

[Dave Opstad]

In this snippet:

d = {'x': 1}
value = d.get('x', bigscaryfunction())

the bigscaryfunction is always called, even though 'x' is a valid key. 
Is there a "short-circuit" version of get that doesn't evaluate the 
second argument if the first is a valid key? For now I'll code around 
it, but this behavior surprised me a bit...

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

Attributes and built-in types

[Dave Opstad]

Is it just an implementation limitation that attributes cannot be 
assigned to instances of internal types?

---
>>> x = 4
>>> type(x)

>>> class Test(int):
...   pass
... 
>>> y = Test(4)
>>> type(y)

>>> y.someattr = 10
>>> x.someattr = 10
Traceback (most recent call last):
  File "", line 1, in ?
AttributeError: 'int' object has no attribute 'someattr'
---

When I did a dir(int) there was no __dict__ entry, but a dir(Test) 
showed a __dict__entry, which is why (presumably) the attribute 
assignment worked for Test but not for int.

Just curious...

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

Re: pack a three byte int

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] wrote:

> Can Python not express the idea of a three-byte int?
> 
> For instance, in the working example below, can we somehow collapse the
> three calls of struct.pack into one?
> 
> >>> import struct
> >>>
> >>> skip = 0x123456 ; count = 0x80
> >>>
> >>> cdb = ''
> >>> cdb += struct.pack('>B', 0x08)
> >>> cdb += struct.pack('>I', skip)[-3:]
> >>> cdb += struct.pack('>BB', count, 0)

Why not something like this:

skip += struct.pack(">L", skip)[1:]

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

Re: pack a three byte int

[Dave Opstad]

Sorry, that should have been:

cdb += struct.pack(">L", skip)[1:]

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

Re: Python is fun (useless social thread) ;-)

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 John Salerno <[EMAIL PROTECTED]> wrote:

I had retired from Apple in 2001 after 33 years in the business, feeling 
completely burned out. Didn't want to even look at another line of code. 
After resting and recuperating for a couple years, though, I picked up a 
book on Python (Alex Martelli's wonderful "Python in a Nutshell") and 
started tinkering with it. I was utterly amazed at how well Python's 
metaphors fit my way of thinking. It was actually fun to program again!

So now I'm back at work full-time, at a company that lets me do 95%+ of 
my work in Python, and I'm having the time of my life. My copy of the 
Martelli book is seriously dog-eared at this point; I'm glad a new 
edition is being released in a few months.

In short: Python rocks.

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

Re: py2app console

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 James Stroud <[EMAIL PROTECTED]> wrote:

> Does anyone know of the most straightforward way to get rid of the 
> intensely annoying "console" window that py2app feels so compelled to 
> create?

I include this code in my apps:

if (sys.platform != "win32") and hasattr(sys, 'frozen'):
root.tk.call('console', 'hide')

That hides the console in py2app applications.

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

Re: py2app semi-standalone semi-works

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 James Stroud <[EMAIL PROTECTED]> wrote:

> I am trying to create a semi-standalone with the vendor python on OS X 
> 10.4 (python 2.3.5). I tried to include some packages with both 
> --packages from the command and the 'packages' option in setup.py. While 
> the packages were nicely included in the application bundle in both 
> cases (at Contents/Resources/lib/python2.3/), they were not found by 
> python when the program was launched, giving the error:
> 
>  "ImportError: No module named [whatever module]"
> 
> Is this because semi-standalone is semi-broken or is it because I have 
> semi-omitted something?
> 
> Any advice on resolving this issue would be greatly appreciated and 
> would greatly reduce the size of the download.

You might want to have a setup.cfg file in addition to the setup.py 
file. I've found that helps ensure the relevant packages and includes 
make it into the bundled application.

For example, say you have a package named fred and also a separate 
module named george that are needed for your app. Your setup.cfg could 
look like this:

#
# setup.cfg
#

[py2app]
packages=fred
includes=george

You can also have a section for [py2exe] if needed; that way, if there 
are modules that your Windows build needs that the Mac build doesn't (or 
vice versa), you can just include them where needed.

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

Re: Tkinter / Aqua (OS X) question (canvas borders)

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> There appears to be an asymmetric "border"
> around the inside of the canvas.

There was a thread on this last May (you can search for the thread 
titled "Unusable outer edge of Tkinter canvases?")

Fredrik Lundh suggested resetting the coordinate system via:

w.xview_moveto(0)
w.yview_moveto(0)

This seemed to help, but in the end it still seems that there's a narrow 
border inside the edges of a Canvas which can't be drawn to. And it 
seems to be different for OS X and Windows.

In the end I just made sure everything I draw is no closer than 5 pixels 
from the edge of the Canvas, and that seems to work on all the platforms 
I'm deploying on.

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

Re: Outdated Python Info on www.unicode.org

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 Dennis Benzinger <[EMAIL PROTECTED]> wrote:

> Could someone who knows the current state of Unicode support in Python 
> update this information?

I've just passed this along to the folks at the Unicode Consortium.

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

Unusable outer edge of Tkinter canvases?

[Dave Opstad]

When drawing rectangles in Tkinter canvases I've noticed the outer edges 
(say 3-5 pixels) don't always draw. For instance, try typing this in an 
interactive session (Terminal in OS X or Command Prompt in Windows XP):

>>> import Tkinter as T
>>> root = T.Tk()
>>> f = T.Frame(root)
>>> f.grid()
>>> c = T.Canvas(f, width = 300, height = 300)
>>> c.grid()
>>> c.create_rectangle(1, 1, 299, 299)
>>> c.create_rectangle(3, 3, 297, 297)
>>> c.create_rectangle(5, 5, 295, 295)

On the Mac, the first two rectangles only partly show up (two sides for 
the first one and three for the second), while the third one draws 
completely. On Windows the first rectangle appears partially and the 
final two appear completely.

Is there some simple setting I'm missing? I've tried gridding the canvas 
with padx, pady and also ipadx, ipady values but nothing seems to help 
make the whole rectangle (1, 1, 299, 299) appear.

I'm using Python 2.4.1 and TclTkAqua 8.4.9 on Mac OS X 10.3.7, and 
Python 2.3.4 on Windows XP (which comes with a Tcl/Tk whose version I 
don't know).

Thanks for any insights,
Dave
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unusable outer edge of Tkinter canvases?

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:

> to fix this, you can either set the border width to zero, add scrollbars
> to the widget (this fixes the coordinate system), or explicitly reset the
> coordinate system:
> 
> w.xview_moveto(0)
> w.yview_moveto(0)

The canvas's border width was already zero, but when I moved the origin 
to (0,0) via xview_moveto and yview_moveto I was able to successfully 
draw all three rectangles.

Just out of curiosity, why aren't these zeroed to start with when the 
widget is created, given the default border width is zero? And is there 
a way of determining what they're set at, something like a xview_get() 
method? I looked at all the canvas's attributes (calling configure()) 
but nothing in there referred to xview or yview.

Thanks for the help!
Dave
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: struct.pack oddity

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 Larry Bates <[EMAIL PROTECTED]> wrote:

> 1) You can't put 10 into a half-word.  The limit is 2**16
> or 65535. On Python 2.5 I get:

Yes, I know. I used that example to illustrate the problem. If a value 
does not fit a format then Python should report that consistently, 
independent of whether a byte-order indication is explicit or implicit.

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

Re: struct.pack oddity

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 "Erik Johnson" <[EMAIL PROTECTED]> wrote:

> Barring anyone else disagreeing with classifying it as a bug, I would
> suggest reporting it. Proper procedure for reporting a bug appears to be
> covered in section B of the Python Library Reference:
> http://docs.python.org/lib/reporting-bugs.html

Thanks for that link. I searched for an existing bug covering this case 
and found 1229380, which specifically lists the case I raised. The bug 
appears to have been closed last June, which confuses me since the bad 
behavior remains in 2.5.

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

Re: Tkinter menu question--how to pass arguments

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 Kevin Walzer <[EMAIL PROTECTED]> wrote:

> I'm having difficulty structuring a Tkinter menu entry. Here is the 
> command in question:
> 
> self.finkmenu.add_command(label='Update List of Packages', 
> command=self.authorizeCommand(self.scanPackages))
> 
> When I start my program, it crashes because it's trying to run the 
> command self.authorizeCommand. The reason I'm structuring it in this 
> fashion is that this command takes another command as an argument--in 
> this case, self.ScanPackages.
> 
> The basic structure of the program is that the self.authorizeCommand 
> function pops up a dialog box for a password; it then feeds the password 
> to the function that it takes as an argument, i.e. self.scanPackages.
> 
> I tried setting up the menu entry without the additional parameter, i.e. 
> command=self.authorizeCommand, but then when I try to run the command 
> from the menu, it complains there are not enough arguments. 
> Unsurprising, since self.authorizeCommand takes another function name as 
> an argument.
> 
> How can I structure the menu item to reflect the correct number of 
> arguments without it trying to execute the command?

If self.scanPackages exists as an attribute of self, why do you need to 
pass it in? If your command is just self.authorizeCommand, and that 
method makes use of self.scanPackages when it runs, then it all should 
work without your having to specify it here.

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

Re: builtin set literal

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 Paul Rubin  wrote:

> [...]  However, Python seems to use the -ed suffix for the 
> non-mutating versions of these functions, e.g. sorted(list) instead 
> of the mutating list.sort().  

I've found this to be useful in my own Python libraries. For instance, a 
graphic object has move(), scale() etc. methods which mutate, and 
moved(), scaled() etc. methods which return new instances. It's 
English-specific, but still mnemonically useful.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: List of all Python's ____ ?

[Dave Opstad]

In article <[EMAIL PROTECTED]>,
 John Machin <[EMAIL PROTECTED]> wrote:

> Hrvoje Niksic wrote:
> > [EMAIL PROTECTED] writes:
> > 
> >> Is there an official list of all Python's ?
> > 
> > http://docs.python.org/ref/specialnames.html
> 
> __missing__ is missing :-)
> 
> see note (10) at the bottom of http://docs.python.org/lib/typesmapping.html

Yes, and __copy__ and __deepcopy__ are missing too:

http://docs.python.org/lib/module-copy.html

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

Manipulating sets from the 2.4 C API?

[Dave Opstad]

I just looked through the Python/C API reference for 2.4.3 and didn't 
see anything about using sets. I'd been expecting things like PySet_New, 
PySet_Check etc.

If I want to handle sets should I just use a dictionary's keys and 
ignore the values, or is there some more explicit set support somewhere 
I'm not seeing?

Thanks,
Dave Opstad
-- 
http://mail.python.org/mailman/listinfo/python-list