HCT added the comment:
maybe someone should start a PEP with all of the thoughts organized?
--
___
Python tracker
<http://bugs.python.org/issue19915>
___
___
Pytho
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
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
T
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/issue7
HCT added the comment:
None does have __format__, but it raises exception
>>> dir(None)
['__bool__', '__class__', '__delattr__', '__dir__', '__doc__', '__eq__',
'__format__', '__ge__', '__getattribu
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'
>>> "
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_al
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 'No
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/is
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 rel
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 d
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
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
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
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/issue19
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",
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"
s
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
>>> cl
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 t
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_
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/is
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/issu
Changes by HCT :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue19729>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.p
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
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 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/i
27 matches
Mail list logo