Thomas Jollans added the comment:
Hello Xiang Zhong,
You're almost correct, but not quite.
File descriptors/file numbers are just integers assigned by the operating
system, and Python has little to no control over them. The OS keeps a numbered
list of open files for each process
Thomas Jollans added the comment:
I cannot reproduce this on my OpenSUSE (glibc 2.33, Linux 5.12.4) or Ubuntu
20.04 (glibc 2.31, Linux 5.4.0) machines, but I can reproduce it on an old
Debian Stretch VM I happened to have lying around (glibc 2.24, Linux 4.9.0).
(FreeBSD 12.2 and Windows 10
Thomas Jollans added the comment:
I think I know what's going on here.
The way you're using tempfile.TemporaryFile() is, shall we say, unusual.
TemporaryFile() already gives you an open file, there's really no reason why
you'd call open() again. In practice you'd usually want to write
New submission from Thomas Jollans :
The file https://www.python.org/static/files/pubkeys.txt contains some bogus
GPG keys with 32-bit key IDs identical to actual release manager key IDs. (see
below) I imagine these slipped in by accident and may have been created by
someone trying to make
Thomas Jollans added the comment:
RFC 2396 explicitly excludes the use of [ and ] in URLs. RFC 2732
<https://www.ietf.org/rfc/rfc2732.txt> defines the syntax for IPv6 URLs, and
allows [ and ] ONLY in the host part.
So I'd say that the behaviour is arguably correct (if somewhat unfor
Thomas Jollans <t...@tjol.eu> added the comment:
Should the PEP be clarified?
--
title: string.Template: cods, docs and PEP all disagree on definition of
identifier -> string.Template: code, docs and PEP all disagree on definition of
i
New submission from Thomas Jollans <t...@tjol.eu>:
string.Template matches a $identifier with the regex [_a-z][_a-z0-9]* and
re.IGNORECASE. This matches S, ſ and s, but not ß.
https://github.com/python/cpython/blob/master/Lib/string.py#L78 (this code came
up on python-dev)
The docs s
Thomas Jollans tho...@jollans.com added the comment:
That sounds reasonable. I've updated the patch to keep the old
test_tofromstring testcase.
I'll also attach another patch in a moment that removes what I'm reasonably
sure is all the uses of array.tostring and .fromstring in the standard
Changes by Thomas Jollans tho...@jollans.com:
Added file: http://bugs.python.org/file18698/tostring_usage.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8990
Changes by Thomas Jollans tho...@jollans.com:
Removed file: http://bugs.python.org/file18607/tofrombytes.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8990
Changes by Thomas Jollans tho...@jollans.com:
Added file: http://bugs.python.org/file18606/tofrombytes.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8990
Changes by Thomas Jollans tho...@jollans.com:
Removed file: http://bugs.python.org/file18606/tofrombytes.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8990
Thomas Jollans tho...@jollans.com added the comment:
Hello again, sorry for the absense.
Victor, thanks for the input. I've attached a new patch that checks the
PyErr_WarnEx return value.
--
Added file: http://bugs.python.org/file18607/tofrombytes.diff
Thomas Jollans tho...@jollans.com added the comment:
Two more patches:
Firstly, this patch (array_3.2_fromstring.diff) is nearly identical to
array2.diff. y* would (again) have to be changed to s* to apply this to 3.1
--
Added file: http://bugs.python.org/file17826
Thomas Jollans tho...@jollans.com added the comment:
Secondly, this is my attempt to add the more sensibly named {to|from}bytes
methods, and to deprecate {to|from}string.
I doubt it's perfect, maybe there's some policy on deprecating methods that I
didn't find? This may be better discussed
Changes by Thomas Jollans tho...@jollans.com:
Added file: http://bugs.python.org/file17828/tofrombytes.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8990
Changes by Thomas Jollans tho...@jollans.com:
Removed file: http://bugs.python.org/file17827/tofrombytes.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8990
Thomas Jollans tho...@jollans.com added the comment:
OK, here's the new patch. I added tests for array(typecode,
bytearray(b'abab')), a.extend(b'123') and a.extend(bytearray(b'123')).
@Victor: int itemsize is the array's item size, buffer.itemsize is the strings'
(and must be 1)
PROBLEM
Thomas Jollans tho...@jollans.com added the comment:
Thanks for the input. I'm going to re-work the patch a bit (releasing buffers
and such) and add a test within the next few days.
The question remains whether or not to accept other buffers with itemsize == 1.
The way I understand
New submission from Thomas Jollans tho...@jollans.com:
Currently, the array constructor, if given a bytearray, detects this with
PyByteArray_Check, and hands it on to array_fromstring, which does not support
bytearray (by using s# with PyArg_ParseTuple) and raises TypeError.
array('h
Thomas Jollans tho...@jollans.com added the comment:
Attached is a patch against the current py3k trunk that fixes this. (as far as
I can tell)
--
keywords: +patch
Added file: http://bugs.python.org/file17580/sunau-bytes.diff
___
Python tracker rep
Thomas Jollans tho...@jollans.com added the comment:
test case for sunau, as requested. Loosely based on test_wave.
--
Added file: http://bugs.python.org/file17582/sunau-test.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Thomas Jollans tho...@jollans.com:
aifc getcomptype() and setcomptype() use bytes while the corresponding methods
in the sunau and wave modules use str (b'NONE', b'ULAW' vs 'NONE', 'ULAW').
This means that programmers wanting simple format-agnostic audio file output
Thomas Jollans tho...@jollans.com added the comment:
tentative documentation patch uploaded
--
Added file: http://bugs.python.org/file17584/aifc_str_doc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8934
New submission from Thomas Jollans tho...@jollans.com:
The sunau module, essentially, doesn't work. This looks like a problem with
the bytes/unicode transition of str in Python 3.x vs Python 2:
Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48)
[GCC 4.4.3] on linux2
Type help, copyright
25 matches
Mail list logo
