HCT added the comment:
maybe someone should start a PEP with all of the thoughts organized?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
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 stdin, line 1, in module
TypeError: 'str' does not support the buffer interface
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
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
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
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__
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 rep...@bugs.python.org
http://bugs.python.org/issue7994
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
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 rep...@bugs.python.org
http://bugs.python.org/issue19915
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
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
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
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
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
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
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 rep...@bugs.python.org
http://bugs.python.org/issue19915
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
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
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_
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
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 rep...@bugs.python.org
http://bugs.python.org
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
Changes by HCT hcta...@gmail.com:
--
type: - crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19729
___
___
Python-bugs-list mailing list
Changes by HCT hcta...@gmail.com:
--
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 rep...@bugs.python.org
http://bugs.python.org
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
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
HCT hcta...@gmail.com 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 rep...@bugs.python.org
http
27 matches
Mail list logo
