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
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 a
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
Thomas Jollans 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
identifier
___
Pyt
New submission from Thomas Jollans :
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 specify "any
Changes by Thomas Jollans :
Removed file: http://bugs.python.org/file18607/tofrombytes.diff
___
Python tracker
<http://bugs.python.org/issue8990>
___
___
Python-bug
Changes by Thomas Jollans :
Added file: http://bugs.python.org/file18698/tostring_usage.diff
___
Python tracker
<http://bugs.python.org/issue8990>
___
___
Python-bug
Thomas Jollans 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 l
Thomas Jollans 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
___
P
Changes by Thomas Jollans :
Removed file: http://bugs.python.org/file18606/tofrombytes.diff
___
Python tracker
<http://bugs.python.org/issue8990>
___
___
Python-bug
Changes by Thomas Jollans :
Added file: http://bugs.python.org/file18606/tofrombytes.diff
___
Python tracker
<http://bugs.python.org/issue8990>
___
___
Python-bugs-list m
Changes by Thomas Jollans :
Removed file: http://bugs.python.org/file17827/tofrombytes.diff
___
Python tracker
<http://bugs.python.org/issue8990>
___
___
Python-bug
Changes by Thomas Jollans :
Added file: http://bugs.python.org/file17828/tofrombytes.diff
___
Python tracker
<http://bugs.python.org/issue8990>
___
___
Python-bugs-list m
Thomas Jollans 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 in a
Thomas Jollans 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/array
Thomas Jollans 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'
Thomas Jollans 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 it, fromstring al
New submission from Thomas Jollans :
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.
>>> a
Thomas Jollans added the comment:
tentative documentation patch uploaded
--
Added file: http://bugs.python.org/file17584/aifc_str_doc.diff
___
Python tracker
<http://bugs.python.org/issue8
New submission from Thomas Jollans :
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
Thomas Jollans 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
<http://bugs.python.org/issue8
Thomas Jollans 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
<h
New submission from Thomas Jollans :
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 "he
25 matches
Mail list logo
