[issue6493] Can not set value for structure members larger than 32 bits

[HCT]

HCT  added the comment:

Hirokazu's v3 patch is a clean solution for the issue and works on 3.2 

any update on when it will go into 3.2/3.3? I can help if needed

--
nosy: +hct

___
Python tracker 
<http://bugs.python.org/issue6493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16070] Structure and native Structure (LittleEndianStructure on Windows) supports __slots__, but BigEndianStructure doesn't

[HCT]

New submission from HCT:

using official CPython 3.2.3 with a simple demonstration script (attached) to 
demonstrate inconsistency between ctypes structures

from ctypes import *

class cbs( BigEndianStructure ):
__slots__ = tuple()
def __init__( self, *args, **kw ):
super().__init__( *args, **kw )
self.a = 11

class cls( LittleEndianStructure ):
__slots__ = tuple()
def __init__( self, *args, **kw ):
super().__init__( *args, **kw )
self.a = 11

class cs( Structure ):
__slots__ = tuple()
def __init__( self, *args, **kw ):
super().__init__( *args, **kw )
self.a = 11

try :
cbs1=cbs()
except AttributeError as e:
print(e)

try :
cls1=cls()
except AttributeError as e:
print(e)

try :
cs=cs()
except AttributeError as e:
print(e)



yields

'cls' object has no attribute 'a'
'cs' object has no attribute 'a'



I expect cbs to throw error too, but itwent through the initalization and 
silently ignored the __slots__ defined in the class

--
components: ctypes
files: slots_test.py
messages: 171402
nosy: hct
priority: normal
severity: normal
status: open
title: Structure and native Structure (LittleEndianStructure on Windows) 
supports __slots__, but BigEndianStructure doesn't
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file27323/slots_test.py

___
Python tracker 
<http://bugs.python.org/issue16070>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7994] object.__format__ should reject format strings

[HCT]

HCT added the comment:

just found out about this change in the latest official stable release and it's 
breaking my code all over the place. something like "{:s}".format( self.pc ) 
used to work in 3.3.4 and prior releases now raise exception rather then return 
a string 'None' when self.pc was never update to not None (was initialized to 
None during object init). this means I have to manually go and change every 
single line that expects smooth formatting to a check to see if the variable is 
still a 'NoneType'.

should we just create a format for None, alias string format to repr/str on 
classes without format implementation or put more thought into this

--
nosy: +hct

___
Python tracker 
<http://bugs.python.org/issue7994>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7994] object.__format__ should reject format strings

[HCT]

HCT added the comment:

I use lots of complicated format such as the following
"{:{:s}{:d}s}".format( self.pcs,self.format_align, self.max_length )

it looks like the way to do it from now on will be
"{!s:{:s}{:d}}".format( self.pcs,self.format_align, self.max_length )

--

___
Python tracker 
<http://bugs.python.org/issue7994>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7994] object.__format__ should reject format strings

[HCT]

HCT added the comment:

unlike NoneType, datetime doesn't throw exception. is returning the format 
specifier the intended behaviour of this fix?


>>> import datetime
>>> a=datetime.datetime(1999,7,7)
>>> str(a)
'1999-07-07 00:00:00'
>>> "{:s}".format(a)
's'
>>> "{:7s}".format(a)
'7s'
>>> "{!s}".format(a)
'1999-07-07 00:00:00'
>>>

--

___
Python tracker 
<http://bugs.python.org/issue7994>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7994] object.__format__ should reject format strings

[HCT]

HCT added the comment:

None does have __format__, but it raises exception

>>> dir(None)
['__bool__', '__class__', '__delattr__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', 
'__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', 
'__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__']

>>> None.__format__


--

___
Python tracker 
<http://bugs.python.org/issue7994>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7994] object.__format__ should reject format strings

[HCT]

HCT added the comment:

I think was confused as I forgot that I was doing str.format where {} being 
format of str. confusion cleared

--

___
Python tracker 
<http://bugs.python.org/issue7994>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19729] str.format sublevel format parsing broken in Python 3.3.3

[HCT]

New submission from HCT:

can't find a way around it... maybe a new regression test on this.

Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> "0x{:0{:d}X}".format(0x0,16)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: unmatched '{' in format
>>> "0x{:0{{:d}}X}".format(0x0,16)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid format specifier
>>> "0x{:0{:d}X}".format(0x0,16)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: unmatched '{' in format
>>> "0x{:{:d}X}".format(0x0,16)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: unmatched '{' in format
>>> "0x{:0{:d}X}".format(0x0,16)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: unmatched '{' in format
>>> "0x{:0{:d}x}".format(0x0,16)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: unmatched '{' in format
>>>
>>> "{:0{}x}".format(0,16)
''

"0x{:0{:d}X}".format(0x0,16) and "{:0{}x}".format(0,16)
work with Python 3.1, 3.2 and up to 3.3.2

--
components: Interpreter Core
messages: 203954
nosy: hct
priority: normal
severity: normal
status: open
title: str.format sublevel format parsing broken in Python 3.3.3
versions: Python 3.3

___
Python tracker 
<http://bugs.python.org/issue19729>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19729] [regression] str.format sublevel format parsing broken in Python 3.3.3

[HCT]

Changes by HCT :


--
type:  -> crash

___
Python tracker 
<http://bugs.python.org/issue19729>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19729] [regression] str.format sublevel format parsing broken in Python 3.3.3

[HCT]

Changes by HCT :


--
title: str.format sublevel format parsing broken in Python 3.3.3 -> 
[regression] str.format sublevel format parsing broken in Python 3.3.3

___
Python tracker 
<http://bugs.python.org/issue19729>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19729] [regression] str.format sublevel format parsing broken in Python 3.3.3

[HCT]

HCT added the comment:

my projects are total broken by this, so my temporary solution is to down grade 
to 3.3.2

somehow we don't have any test to check this before releasing 3.3.3

--

___
Python tracker 
<http://bugs.python.org/issue19729>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19803] memoryview complain ctypes byte array are not native single character

[HCT]

New submission from HCT:

I'm trying to create ctypes buffer to be used back and forth with C libraries, 
but I keep getting errors. I need to slice the buffer to cut out different 
pieces to work on, so I try to get a memoryview of the buffer. does the error 
message imply that c_ubyte, c_uint8, c_byte and c_char are not native single 
character types?

>>> memoryview(c_ubyte()).cast('B')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: memoryview: source format must be a native single character format 
prefixed with an optional '@'
>>> memoryview((c_ubyte*1024)()).cast('B')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: memoryview: source format must be a native single character format 
prefixed with an optional '@'
>>> memoryview(c_uint8()).cast('B')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: memoryview: source format must be a native single character format 
prefixed with an optional '@'
>>> memoryview((c_uint8*1024)()).cast('B')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: memoryview: source format must be a native single character format 
prefixed with an optional '@'
>>> memoryview((c_byte*1024)()).cast('B')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: memoryview: source format must be a native single character format 
prefixed with an optional '@'
>>> memoryview((c_char*1024)()).cast('B')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: memoryview: source format must be a native single character format 
prefixed with an optional '@'
>>> memoryview((c_char*1024)())[0]
Traceback (most recent call last):
  File "", line 1, in 
NotImplementedError: memoryview: unsupported format (1024)>> memoryview((c_byte*1024)())[0]
Traceback (most recent call last):
  File "", line 1, in 
NotImplementedError: memoryview: unsupported format (1024)>> memoryview((c_ubyte*1024)())[0]
Traceback (most recent call last):
  File "", line 1, in 
NotImplementedError: memoryview: unsupported format (1024)>> memoryview((c_uint8*1024)())[0]
Traceback (most recent call last):
  File "", line 1, in 
NotImplementedError: memoryview: unsupported format (1024)>>

--
components: Library (Lib), ctypes
messages: 204536
nosy: hct
priority: normal
severity: normal
status: open
title: memoryview complain ctypes byte array are not native single character
versions: Python 3.3

___
Python tracker 
<http://bugs.python.org/issue19803>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19803] memoryview complain ctypes byte array are not native single character

[HCT]

HCT added the comment:

this seems to disagree with the statement of "Memoryview currently only knows 
the types from the struct module."

why is memoryview aware of _pack_, a implementation detail of ctypes 
structures. is memoryview a collection of implementation for different types or 
a unique type on its own?


>>> import ctypes
>>> class B1(ctypes.Structure):
... _fields_ = [( "data", c_uint8 * 256 ), ]
... _pack_ = 1
...
>>> class B2(ctypes.Structure):
... _fields_ = [( "data", c_uint8 * 256 ), ]
...
>>>
>>> a = B1()
>>> b = B2()
>>> memoryview( a ).cast( 'B' )

>>> memoryview( b ).cast( 'B' )
Traceback (most recent call last):
  File "", line 1, in 
ValueError: memoryview: source format must be a native single character format 
prefixed with an optional '@'
>>>

--

___
Python tracker 
<http://bugs.python.org/issue19803>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19803] memoryview complain ctypes byte array are not native single character

[HCT]

HCT added the comment:

more examples (using 64-bit integer vs 8-bit integer in the above example) to 
show that ctypes aren't being translated for memoryview properly. _pack_ is the 
only way to make memoryview handle ctypes properly


>>> import ctypes
>>> class B1(ctypes.Structure):
... _fields_ = [( "data", ctypes.c_uint64 * 256 ), ]
... _pack_ = 1
...
>>> class B2(ctypes.Structure):
... _fields_ = [( "data", ctypes.c_uint64 * 256 ), ]
...
>>>
>>> a = B1()
>>> b = B2()
>>> memoryview( a ).cast( 'B' )

>>> memoryview( b ).cast( 'B' )
Traceback (most recent call last):
  File "", line 1, in 
ValueError: memoryview: source format must be a native single character format 
prefixed with an optional '@'
>>>

--

___
Python tracker 
<http://bugs.python.org/issue19803>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19803] memoryview complain ctypes byte array are not native single character

[HCT]

HCT added the comment:

I wonder why "_pack_ = 1" has significant impact on the behaviour of memoryview 
if memoryview is not a sub class of ctypes structure. unless memoryview was 
specifically coded to understand ctypes structure, I don't see why "_pack_ = 1" 
should make any difference.

--

___
Python tracker 
<http://bugs.python.org/issue19803>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19914] help([object]) returns "Not enough memory." on standard Python types, object and object functions

[HCT]

New submission from HCT:

not sure if this ever worked. first time using help([object]), but these should 
work according to the documentation. OS is Win7 SP1 32-bit.

Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> help(list)
Not enough memory.

>>> help(list())
Not enough memory.

>>> help([])
Not enough memory.

>>> help(tuple())
Not enough memory.

>>> help(())
Not enough memory.

>>> help(str.format)
Not enough memory.

>>> help(str)
Not enough memory.

>>> help(b'1234')
Not enough memory.

>>> help(str.strip)
Not enough memory.

>>> help(str.count)
Not enough memory.

>>>

--
components: Interpreter Core
messages: 205413
nosy: hct
priority: normal
severity: normal
status: open
title: help([object]) returns "Not enough memory." on standard Python types, 
object and object functions
type: behavior
versions: Python 3.3

___
Python tracker 
<http://bugs.python.org/issue19914>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[HCT]

HCT added the comment:

or just allow slicing of int. otherwise function call overhead may defeat the 
speed up of such function.

--
nosy: +hct

___
Python tracker 
<http://bugs.python.org/issue19915>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9951] introduce bytes.hex method

[HCT]

HCT added the comment:

@Victor

binascii.hexlify('abc') doesn't work in 3.4. I assume this is a new thing for 
3.5

>>> import binascii
>>> binascii.hexlify('abc')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'str' does not support the buffer interface
>>>
>>> binascii.hexlify(b'abc')
b'616263'


@Terry
I think that space shouldn't be done by the hex function. if you allow space 
between each hex, then what do you do if the bytes are actually from array of 
64-bit ints? getting into support separating space for every X bytes is 
probably not the scope of this.


I propose the hex functions for bytes/memoryview/bytearray should be as follow. 
I prefer to not have the '0x' prefix at all, but I understand all other hex 
functions adds it. would be good to have the option to not have the prefix.

bytes.hex( byte_order = sys.byteorder ) returns a hex string in small letter. 
ex. c0ffee

bytes.HEX( byte_order = sys.byteorder ) returns a hex string in capital 
letters. ex. DEADBEEF

bytes.from_hex( hex_str, byte_order = sys.byteorder ) returns a bytes object. 
ex. b'\xFE\xFF'


another more flexible way is to have hex function accept a format similar to 
how sscanf works, but this will probably bring lots of trouble for all kinds of 
variants to support and the required error checks.

--

___
Python tracker 
<http://bugs.python.org/issue9951>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9951] introduce bytes.hex method

[HCT]

HCT added the comment:

@Terry

natural bytes do not have space between them. I would think adding space is for 
typesetting situation which should be done by user's post-processing.

I agree to not have any prefix to make .hex and from_hex uniform. the \x is the 
str representation of bytes when you print a bytes object directly in Python. 
the actual bytes object doesn't have that \x prefix.

--

___
Python tracker 
<http://bugs.python.org/issue9951>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[HCT]

HCT added the comment:

maybe someone should start a PEP with all of the thoughts organized?

--

___
Python tracker 
<http://bugs.python.org/issue19915>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[HCT]

HCT added the comment:

> I think slicing semantically "seems wrong" but it might be more elegant. It 
> might also make catching errors harder (in the case where an int is sent to a 
> function that does slicing and now won't fail with a TypeError).

not sure what's semantically "seems wrong" with it. not sure why TypeError or 
any other error catching should come into play for this.

calling a function is way more expensive than doing bit shift and/or AND 
operation. as a function, you've only hide your code into Python binaries at 
the expense of performance

--

___
Python tracker 
<http://bugs.python.org/issue19915>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9951] introduce bytes.hex method

[HCT]

HCT added the comment:

would be good if we can specify a optional flag to get all cap hex. currently, 
I have to do hexlify( some_bytes ).decode( 'UTF-8' ).upper(). would be good to 
be able to do some_bytes.hex( upper=1 )

--
nosy: +hct

___
Python tracker 
<http://bugs.python.org/issue9951>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19914] help([object]) returns "Not enough memory." on standard Python types, object and object functions

[HCT]

HCT added the comment:

verified issue is due to code page was set to 65001, but I set PYTHONIOENCODING 
to utf-8 (tried UTF-8, utf8, utf-8...etc), so I'm not sure why there is problem 
with code page 65001

setting code page back to ascii (non-Unicode) fixed the issue.

--

___
Python tracker 
<http://bugs.python.org/issue19914>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19914] help([object]) returns "Not enough memory." on standard Python types, object and object functions

[HCT]

HCT added the comment:

the other issue I'm also seeing is that help() doesn't seem to take exactly an 
object as an optional argument. perhaps Python manual for help() should be 
updated according to the actual implementation?

>>> help('hello')
no Python documentation found for 'hello'

>>> type('hello')

>>> a='hello'
>>> help(a)
no Python documentation found for 'hello'

>>>

--

___
Python tracker 
<http://bugs.python.org/issue19914>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19729] [regression] str.format sublevel format parsing broken in Python 3.3.3

[HCT]

HCT added the comment:

just want to know if there is any tentative schedule to release 3.3.4. the PEP 
for 3.3 schedule doesn't talk about 3.3.4, so I'm not sure if the decision was 
to leave latest 3.3 with this broken regression or fix it and release 3.3.4.

--

___
Python tracker 
<http://bugs.python.org/issue19729>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[HCT]

HCT added the comment:

then I guess it's either a new function to int or a new type of int for this 
type of operations. similar to bytearray/ctypes and memoryview

--

___
Python tracker 
<http://bugs.python.org/issue19915>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17885] multiprocessing.Process child process imports package instead of parent file

[HCT]

New submission from HCT:

created a project with the following content
CODEC/
CODEC/video.py
CODEC/audio.py
CODEC/__init__.py
CRC/
CRC/crc24.py
CRC/crc32.py
CRC/__init__.py
TEST/test_crc.py
TEST/test_codec.py
TEST/__init__.py
__init__.py
test.py
main.py


test.py contain tests that launches multiple multiprocessing.Process to test 
diffferent module in parallel, but always fail to launch child processes for 
test with AttributeError. I spent lots of time trying to figure out why my code 
don't work. I also tried to use the examples from 
http://docs.python.org/dev/library/multiprocessing.html#the-process-class and 
they also gives AttributeError when launching child process. in the end, I 
figured out it's because Pythong file test.py has same name as package TEST. 
change test.py to test_all.py and everything worked.

It looks multiprocessing import defaults to import package, not the parent file 
when file name without suffix is same as package.

--
components: Library (Lib)
messages: 188197
nosy: hct
priority: normal
severity: normal
status: open
title: multiprocessing.Process child process imports package instead of parent 
file
type: compile error
versions: Python 3.3

___
Python tracker 
<http://bugs.python.org/issue17885>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com