[issue34208] Change in 3.7 expression evaluation?
New submission from Dave Opstad : In 3.6 I get this: >>> x = (100 * 20) >>> x is 2000 False >>> (100 * 20) is 2000 False But in 3.7, I get this: >>> x = (100 * 20) >>> x is 2000 False >>> (100 * 20) is 2000 True This isn't necessarily a problem, but I'm curious why this behavior changed from 3.6 to 3.7. -- components: Interpreter Core messages: 322304 nosy: opstad priority: normal severity: normal status: open title: Change in 3.7 expression evaluation? type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32488] Fatal error using pydoc
Dave Opstad <dave.ops...@monotypeimaging.com> added the comment: I think this was my mistake; when I used pydoc3 instead of pydoc it ran to completion. Please feel free to close this; sorry for the noise. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32488> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32488] Fatal error using pydoc
New submission from Dave Opstad <dave.ops...@monotypeimaging.com>: I'm running 3.6.4 on Mac OS X 10.13.2, bash shell. Doing: $ pydoc modules causes: Please wait a moment while I gather a list of all available modules... Fatal Python error: PyThreadState_Get: no current thread Abort trap: 6 Reproduced this several times with the same result. -- components: Demos and Tools messages: 309422 nosy: opstad priority: normal severity: normal status: open title: Fatal error using pydoc type: crash versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32488> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11900] 2.7.1 unicode subclasses not calling __str__() for print statement
New submission from Dave Opstad dave.ops...@monotypeimaging.com:
Python 2.7.1 doesn't appear to do the usual implicit call to str() for
subclasses of unicode. In the following snippet, I would have expected print
myTest and print str(myTest) to behave the same:
class Test(unicode):
... def __str__(self):
... print In __str__
... return (u*** + self + u ***).encode('utf-8')
... def __unicode__(self):
... print In __unicode__
... return u*** + self + u ***
...
myTest = Test(uabc)
print myTest
abc
print str(myTest)
In __str__
*** abc ***
print unicode(myTest)
In __unicode__
*** abc ***
--
components: Unicode
messages: 134231
nosy: opstad
priority: normal
severity: normal
status: open
title: 2.7.1 unicode subclasses not calling __str__() for print statement
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11900
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11900] 2.7.1 unicode subclasses not calling __str__() for print statement
Dave Opstad dave.ops...@monotypeimaging.com added the comment: I guess I was confused by the inconsistency with Python 3, which *does* call the __str__ method, even though, again, no coercion is needed: Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. class X(str): ... def __str__(self): ... print(In __str__) ... return *** + self + *** ... x = X(abcde) print(x) In __str__ *** abcde *** print(str(x)) In __str__ *** abcde *** -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8941] utf-32be codec failing on 16-bit python build for 32-bit value
New submission from Dave Opstad dave.ops...@monotypeimaging.com: The utf-32 little-endian codec works fine, but the big-endian codec is producing incorrect results: Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. str(b'\x00\x00\x01\x00', 'utf-32le') # works '\U0001' str(b'\x00\x01\x00\x00', 'utf-32be') # doesn't work '\ud800\x02' -- components: Unicode messages: 107326 nosy: opstad priority: normal severity: normal status: open title: utf-32be codec failing on 16-bit python build for 32-bit value type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8946] PyBuffer_Release signature in 3.1 documentation is incorrect
New submission from Dave Opstad dave.ops...@monotypeimaging.com: According to the 3.1 documentation, the prototype for PyBuffer_Release is: void PyBuffer_Release(PyObject *obj, Py_buffer *view); However, abstract.h has this prototype: PyAPI_FUNC(void) PyBuffer_Release(Py_buffer *view); The documentation's reference to obj should be removed. -- assignee: d...@python components: Documentation messages: 107342 nosy: d...@python, opstad priority: normal severity: normal status: open title: PyBuffer_Release signature in 3.1 documentation is incorrect type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: List of all Python's __special-methods__ ?
In article [EMAIL PROTECTED], John Machin [EMAIL PROTECTED] wrote: Hrvoje Niksic wrote: [EMAIL PROTECTED] writes: Is there an official list of all Python's __special-methods__? 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
Re: Tkinter menu question--how to pass arguments
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: struct.pack oddity
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
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: builtin set literal
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] 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: pack a three byte int
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
Sorry, that should have been: cdb += struct.pack(L, skip)[1:] Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: py2app semi-standalone semi-works
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: py2app console
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: Python is fun (useless social thread) ;-)
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
Manipulating sets from the 2.4 C API?
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
Re: Outdated Python Info on www.unicode.org
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
Re: Tkinter / Aqua (OS X) question (canvas borders)
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: PYTHONDOCS on OSX
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
__setslice__ and classes derived from list
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
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
Odd slicing behavior?
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 stdin, 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?
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
Unusable outer edge of Tkinter canvases?
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?
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
Attributes and built-in types
Is it just an implementation limitation that attributes cannot be assigned to instances of internal types? --- x = 4 type(x) type 'int' class Test(int): ... pass ... y = Test(4) type(y) class '__main__.Test' y.someattr = 10 x.someattr = 10 Traceback (most recent call last): File stdin, 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
Is there a short-circuiting dictionary get method?
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
Initializing subclasses of tuple
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 stdin, 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
Awkwardness of C API for making tuples
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
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
