[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: I've opened issue 8300 for adding the __index__ handling. -- superseder: -> Allow struct.pack to handle objects with an __index__ method. ___ Python tracker ___

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Closing this; a separate feature request should be opened for the idea of adding __index__ awareness to struct.pack in py3k. -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue1530559] struct.pack raises TypeError where it used to convert

Florent Xicluna added the comment: I would suggest to raise a py3k warning instead of a plain warning. AFAIU the implicit conversion is OK in 2.7, and it is removed in 3.x. -- nosy: +flox ___ Python tracker

[issue1530559] struct.pack raises TypeError where it used to convert

Meador Inge added the comment: > (2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer > on top of the C layer. Partly I'm worried about accidentally breaking > something (it's not 100% clear to me whether there might be hidden > side-effects to such a change), I unde

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Comments and thoughts on the __index__ patch: (1) Thank you for a remarkably complete patch! (2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer on top of the C layer. Partly I'm worried about accidentally breaking something (it's n

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Recent checkins messed up Meador Inge's __index__ patch; here's a regenerated version. -- Added file: http://bugs.python.org/file16485/issue-1530559__index__.patch ___ Python tracker

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Restored use of __int__ for all integer conversion codes in r78762. -- ___ Python tracker ___ ___

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Updated patch, with slightly saner warnings checks. -- Added file: http://bugs.python.org/file16484/issue1530559__int__2.patch ___ Python tracker ___

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Here's a patch to restore the old usage of __int__ to convert non-integer arguments; it also produces a DeprecationWarning whenever __int__ is used in this way. For consistency and simplicity, __int__ will be tried for *any* non-integer argument when packin

[issue1530559] struct.pack raises TypeError where it used to convert

Meador Inge added the comment: > If anyone's interested in submitting a patch, it would be welcome. Sure. I saw where this was partly addressed in r78690. The attached patch adds support for the '__index__' conversion that Mark suggested. At first glance, the patch may seem more than what

[issue1530559] struct.pack raises TypeError where it used to convert

Andreas Kloeckner added the comment: Thanks for the clarification of 'beforehand'--I had understood from your description that this would be some sort of preprocessing step. I agree that the TypeError is a bit much, though I'm biased of course. If you'd like my input on things you come up wit

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Also, it may be that some of r73858 needs to be reverted; going from accepting non-ints and longs in 2.6 to a TypeError in 2.7 is a bit much; there should have at least been a DeprecationWarning. I need to find some time to look at this properly, and work o

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: More or less, yes: when trying to pack a non-integer `x` (i.e. something that's not an instance of int or long) with an integer format code (one of 'bBhHiIlLqQ', or 'P'), `x.__index__()` would be called to convert `x` to an integer, and that integer would be

[issue1530559] struct.pack raises TypeError where it used to convert

Andreas Kloeckner added the comment: AFAICS, __index__ would be fine. To make sure I understand your proposed solution correctly: You'd go through the argument list beforehand and cast everything that's not a number type or str to int by means of __index__? -- __

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: I'd be open to re-allowing use of __int__ (and __long__) consistently for all integer packing codes in 2.7, as a temporary measure; I'd really prefer not to allow this for 3.x. What would make more sense, IMO, would be to allow use of the __index__ method (

[issue1530559] struct.pack raises TypeError where it used to convert

Andreas Kloeckner added the comment: The fix breaks my package PyCUDA, which relies on handing struct something that can be cast to long. (i.e. not a float, but something representing a memory address on a GPU) Am I out of luck? -- nosy: +inducer

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: This is now fixed in the trunk in r73858. The failing test has been reenabled. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker

[issue1530559] struct.pack raises TypeError where it used to convert

Changes by Daniel Diniz : -- dependencies: +struct.pack("I", "foo"); struct.pack("L", "foo") should fail keywords: +patch type: -> behavior ___ Python tracker ___

[issue1530559] struct.pack raises TypeError where it used to convert

Bob Ippolito added the comment: I believe that struct.error is just how it worked before 2.5 -- ___ Python tracker ___ ___ Python-b

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: The deprecated struct features (float coercion, overflow wrapping) have been removed for py3k in r70497, r70688, r71754. I don't plan to backport this to 2.7; I'll just try to fix the behaviour in a minimal way there. One thing that's not clear to me: what'

[issue1530559] struct.pack raises TypeError where it used to convert

Changes by Mark Dickinson : -- assignee: bob.ippolito -> marketdickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Stealing this from Bob. Bob, please steal it back it you want it! -- ___ Python tracker ___ ___

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Some more strange results: Python 2.6.1+ (release26-maint:68613, Jan 15 2009, 15:19:54) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from struct import pack >>> from decimal import Dec

[issue1530559] struct.pack raises TypeError where it used to convert

Mark Dickinson added the comment: Retargeting, now that 2.5 is in security-fix-only mode. Bob, can you clarify what *should* be happening in 2.6, 2.7, 3.0 and 3.1 for things like: struct.pack('L', 2009.1) struct.pack('L', Decimal('3.14')) ? It also seems that 'L' and 'Q behave differently.

[issue1530559] struct.pack raises TypeError where it used to convert

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bu

[issue1530559] struct.pack raises TypeError where it used to convert

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I ran into this issue converting test_struct to unittest. I would fix it, but I'm not sure exactly what is intended. I'm raising priority. -- nosy: +benjamin.peterson priority: normal -> critical __

[issue1530559] struct.pack raises TypeError where it used to convert

Changes by Sean Reifschneider: -- priority: urgent -> normal _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsub

[issue1530559] struct.pack raises TypeError where it used to convert

Sean Reifschneider added the comment: etrepum: Can you fix the test which caused this to be re-opened? I'm tempted to push this down in priority from urgent to high, since the code is (apparently) fixed, just the test is failing, but ideally this could just get fixed. -- nosy: +jafo __