[issue46548] macOS installers cannot be signed on Monterey
Robert Xiao added the comment: I noticed that the official installer seems to be built using an entirely different process, as it produces a single-file .pkg in xar format with an embedded Distribution file, rather than an .mpkg directory. Is there documentation on how these packages are generated? It seems like the scripts for that aren't in the Python source tree? -- ___ Python tracker <https://bugs.python.org/issue46548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46548] macOS installers cannot be signed on Monterey
Change by Robert Xiao : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue46548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46548] macOS installers cannot be signed on Monterey
New submission from Robert Xiao : I am building unofficial macOS packages for personal use. My main build machine is running macOS Monterey 12.1 and Xcode 13.2.1. I recently attempted to build Python 3.8.12 as a package using build-installer.py. This worked fine after a bit of dependency wrangling (mostly, downloading the right Tcl/Tk source files manually) and produced an installer package and DMG as expected. However, it is apparently impossible to actually sign the package. I receive the following error: % productsign --sign 'Apple Development: ...' /private/tmp/_py/installer/Python.mpkg /private/tmp/_py/installer/Python-signed.mpkg productsign: preparing "Python.mpkg" for signing ... productsign: error: component package "PythonFramework-3.8.pkg" uses legacy installer features that make it impossible to sign. Unfortunately, searching for "legacy installer features" yields zero useful hits, which is a bit of a surprise. I assume that this error message was added to a recent macOS/Xcode build, but I am unable to downgrade easily. I believe this is probably being triggered because the way the packages are put together differs from the way pkgbuild/productbuild would do it. The longer term solution would probably be to switch to those tools instead of assembling the packages by hand. Issue reproduces with Python 3.11a4 sources as well, so I'm tagging it as applying for 3.8~3.11. -- components: Build messages: 411857 nosy: nneonneo priority: normal severity: normal status: open title: macOS installers cannot be signed on Monterey versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39318] NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws
Robert Xiao added the comment: Could this be solvable if `closefd` were a writable attribute? Then we could do file = None try: file = io.open(fd, ..., closefd=False) file.closefd = True except: if file and not file.closefd: os.close(fd) raise I believe this should be bulletproof - a KeyboardInterrupt can happen anywhere in the `try` and we will not leak or double-close. Either file.closefd is set, in which case `file` owns the fd and will close it eventually, or file.closefd is not set in which case the fd needs to be manually closed, or file doesn't exist (exception thrown in io.open or while assigning file), in which case the fd still needs to be manually closed. Of course, this can leak if a KeyboardInterrupt lands in the `except` - but that's not something we can meaningfully deal with. The important thing is that this shouldn't double-close if I analyzed it correctly. This is a somewhat annoying pattern, though. I wonder if there's a nicer way to implement it so we don't end up with this kind of boilerplate everywhere. -- ___ Python tracker <https://bugs.python.org/issue39318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39318] NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws
New submission from Robert Xiao : tempfile.NamedTemporaryFile creates its wrapper like so: try: file = _io.open(fd, mode, buffering=buffering, newline=newline, encoding=encoding, errors=errors) return _TemporaryFileWrapper(file, name, delete) except BaseException: _os.unlink(name) _os.close(fd) raise If _TemporaryFileWrapper throws any kind of exception (even KeyboardInterrupt), this closes `fd` but leaks a valid `file` pointing to that fd. The `file` will later attempt to close the `fd` when it is collected, which can lead to subtle bugs. (This particular issue contributed to this bug: https://nedbatchelder.com/blog/202001/bug_915_please_help.html) This should probably be rewritten as: try: file = _io.open(fd, mode, buffering=buffering, newline=newline, encoding=encoding, errors=errors) except: _os.unlink(name) _os.close(fd) raise try: return _TemporaryFileWrapper(file, name, delete) except BaseException: _os.unlink(name) file.close() raise or perhaps use nested try blocks to avoid the _os.unlink duplication. -- components: Library (Lib) messages: 359888 nosy: nneonneo priority: normal severity: normal status: open title: NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33074] dbm corrupts index on macOS (_dbm module)
Robert Xiao added the comment: I just started a new project, thoughtlessly decided to use `shelve` to store data, and lost it all again thanks to this bug. To reiterate: Although `gdbm` might fix this issue, it's not installed by default. But the issue is with `dbm`: Python is allowing me to insert elements into the database which exceed internal limits, causing the database to become silently corrupt upon retrieval. This is an unacceptable situation - a very normal, non-complex use of the standard library is causing data loss without any indication that the loss is occurring. At the very least there should be a warning or error that the data inserted exceeds dbm's limits, and in an ideal world dbm would not fall over from inserting a few KB of data in a single row (but I understand that's a third party problem at that point). Can't we just ship a dbm that is backed with a more robust engine, like a SQLite key-value table? -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue33074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33074] dbm corrupts index on macOS (_dbm module)
Robert Xiao <nneon...@gmail.com> added the comment: So we have some other problems then: (1) It should be documented in dbm, and ideally in shelve, that keys/values over a certain limit might not work. Presently there is no hint that such a limit exists, and until you mentioned it I was unaware that POSIX only required 1023-byte keys and values. (2) dbm.ndbm should refuse to perform operations that might corrupt the database, or it should be deprecated entirely if this is impossible. A built-in data storage system for Python should not have an easy corruption route, as it is very surprising for users. (3) It might be worth considering "dbm.sqlite" or somesuch, adapting a SQLite database as a key-value store. The key-value store approach is much simpler than sqlite and appropriate for certain applications, while SQLite itself would provide robustness and correctness. I can volunteer to build such a thing on top of the existing Python SQLite support. (4) The approach of shelve is incompatible with limited-length values, because shelve's pickles are of an unpredictable length. This suggests that shelve should internally prioritize dumbdbm over ndbm if ndbm cannot guarantee support for arbitrary-length keys/values. (5) dbm.gnu is not a default, and I can't even work out how to get it enabled with the stock Python installation (i.e. without building my own Python against e.g. Macports gdbm). Is it a problem to ship dbm.gnu as part of the default install, so that it is more feasible to assume its existence? Thoughts? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33090] race condition between send and recv in _ssl with non-zero timeout
New submission from Robert Xiao <nneon...@gmail.com>:
Environment: Several versions of Python (see below), macOS 10.12.6
The attached script creates an SSL echo server (fairly standard), connects to
the server, and spawns a read and write thread.
The write thread repeatedly shovels data into the connection, while the read
thread receives data and prints a dot for each successful read.
The socket has a timeout of 10 seconds set: if the timeout is 0, the script
blows up immediately due to blocking, and if the timeout is -1 nothing bad
happens.
On Linux and the default Mac Python 2.6, the script prints an endless series of
dots as expected.
On most other versions of Mac Python (2.7, 3.5, 3.6), the script dies quite
quickly (within 1-2 seconds) with an error like this:
$ /usr/bin/python2.7 test_ssl.py
Got connection from ('127.0.0.1', 49683)
..Exception in thread ReadThread:
Traceback (most recent call last):
File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py",
line 810, in __bootstrap_inner
self.run()
File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py",
line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "test_ssl.py", line 93, in read_thread
csocket.recv()
File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py",
line 734, in recv
return self.read(buflen)
File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py",
line 621, in read
v = self._sslobj.read(len or 1024)
error: [Errno 35] Resource temporarily unavailable
The error can be one of the following:
[Py2.7] error: [Errno 35] Resource temporarily unavailable
[Py2.7] SSLWantReadError: The operation did not complete (read) (_ssl.c:1752)
[Py3.x] BlockingIOError: [Errno 35] Resource temporarily unavailable
[Py3.x] ssl.SSLWantReadError: The operation did not complete (read)
(_ssl.c:1974)
[Py3.6] ssl.SSLError: Invalid error code (_ssl.c:2217)
The last error occurs under much rarer circumstances, but appears to be
associated with the same underlying bug. The "invalid error code" is 0 when
tested with a debugger, indicating a successful completion (but somehow the
error logic gets triggered anyway).
This was tested with the following configurations:
macOS: /usr/bin/python2.6: Python 2.6.9 from Apple [ok]
macOS: /usr/bin/python2.7: Python 2.7.10 from Apple [crashes]
macOS: /usr/local/bin/python2.7: Python 2.7.13 from Python.org [crashes]
macOS: /usr/local/bin/python3.5: Python 3.5.1 from Python.org [crashes]
macOS: /usr/local/bin/python3.6: Python 3.6.4 from Python.org [crashes]
macOS: /opt/local/bin/python2.7: Python 2.7.14 from MacPorts [crashes]
A number of these were tested on a second machine (to rule out any strange
environment issues), and the same results were obtained.
--
assignee: christian.heimes
components: SSL, macOS
files: test_ssl.py
messages: 313970
nosy: christian.heimes, ned.deily, nneonneo, ronaldoussoren
priority: normal
severity: normal
status: open
title: race condition between send and recv in _ssl with non-zero timeout
type: crash
versions: Python 2.7, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47489/test_ssl.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33090>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33074] dbm corrupts index on macOS (_dbm module)
Robert Xiao <nneon...@gmail.com> added the comment: (Note: the contextlib stuff is just for Python 2 compatibility, it's not necessary on Python 3). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33074] dbm corrupts index on macOS (_dbm module)
New submission from Robert Xiao <nneon...@gmail.com>:
Environment: Python 3.6.4, macOS 10.12.6
Python 3's dbm appears to corrupt the key index on macOS if objects >4KB are
inserted.
Code:
<<<<<<<<<<<
import dbm
import contextlib
with contextlib.closing(dbm.open('test', 'n')) as db:
for k in range(128):
db[('%04d' % k).encode()] = b'\0' * (k * 128)
with contextlib.closing(dbm.open('test', 'r')) as db:
print(len(db))
print(len(list(db.keys(
>>>>>>>>>>>
On my machine, I get the following:
<<<<<<<<<<<
94
Traceback (most recent call last):
File "test.py", line 10, in
print(len(list(db.keys(
SystemError: Negative size passed to PyBytes_FromStringAndSize
>>>>>>>>>>>
(The error says PyString_FromStringAndSize on Python 2.x but is otherwise the
same). The expected output, which I see on Linux (using gdbm), is
128
128
I get this error with the following Pythons on my system:
/usr/bin/python2.6 - Apple-supplied Python 2.6.9
/usr/bin/python - Apple-supplied Python 2.7.13
/opt/local/bin/python2.7 - MacPorts Python 2.7.14
/usr/local/bin/python - Python.org Python 2.7.13
/usr/local/bin/python3.5 - Python.org Python 3.5.1
/usr/local/bin/python3.6 - Python.org Python 3.6.4
This seems like a very big problem - silent data corruption with no warning. It
appears related to issue30388, but in that case they were seeing sporadic
failures. The deterministic script above causes failures in every case.
This was discovered after running some code which used shelve (which uses dbm
under the hood) in Python 3, but the bug clearly applies to Python 2 as well.
--
files: test.db
messages: 313809
nosy: nneonneo
priority: normal
severity: normal
status: open
title: dbm corrupts index on macOS (_dbm module)
versions: Python 2.7, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47484/test.db
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33074>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29427] Option to skip padding for base64 urlsafe encoding/decoding
Robert Xiao added the comment:
This sounds reasonable. I ran into a similar issue today trying to decode a
JSON Web Key. Although I don't have any real say, I'd say that if you put
together a patch it may have a higher chance to get reviewed.
I wonder about the following:
- What about adding a new kwarg to b64decode, passed through by
urlsafe_b64decode, called "checkpad=True" which validates padding? Then we can
just set that False when we need.
- At the same time it might be nice to pass "validate=False" through from
urlsafe_b64decode and friends, so we can have some nicer validation of data.
- I like adding the "padding=True" arg to encode, but it may not be necessary
given the ease of ".rstrip('=')" as an alternative. Anyway, if you will add it
to encode, please add it to b64encode and pass through from the variant
encoders to unify the API somewhat.
If you are still interested in putting together a patch, post a comment.
Otherwise I may work on a patch for this.
--
nosy: +nneonneo
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29427>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28927] bytes.fromhex should ignore all whitespace
Robert Xiao added the comment: New patch with proper line lengths in documentation. -- Added file: http://bugs.python.org/file45967/fromhex.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28927] bytes.fromhex should ignore all whitespace
Robert Xiao added the comment: OK, I've attached a new version of the patch with the requested documentation changes (versionchanged and whatsnew). -- Added file: http://bugs.python.org/file45966/fromhex.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28927] bytes.fromhex should ignore all whitespace
Robert Xiao added the comment:
I see your point, Nick. Can I offer a counterpoint?
Most of the string parsers operate only on relatively short inputs, like
numbers. Numbers in particular are rarely written with inner spaces, so it
makes sense not to ignore internal whitespaces.
On the other hand, hexadecimal data can be very long, and is often formatted
with spaces and newlines. For example, the default output of `xxd -p`, a format
quite suitable for copy-paste, looks like this:
cffaedfe0701038002001500d80885802100
190048005f5f504147455a45524f
0100
190018035f5f54455854
01909d01
It would be desirable to write something like
blob = bytes.fromhex('''
cffaedfe0701038002001500d80885802100
190048005f5f504147455a45524f
0100
190018035f5f54455854
01909d01
''')
and not have to worry about sticking in some whitespace remover, like this:
blob = bytes.fromhex(''.join('''
cffaedfe0701038002001500d80885802100
190048005f5f504147455a45524f
0100
190018035f5f54455854
01909d01
'''.split()))
or removing the newlines in the source code, which impacts readability.
Similar kinds of whitespaced output (sometimes with spaces between octets,
words or dwords, sometimes with tabs between 8-16 byte groups, sometimes with
newlines between groups, etc.) can be found in the wild and from the "hex"
clipboard output from various applications.
We can already have newlines and other whitespace with base64, which is in
principle quite similar:
blob = base64.b64decode('''
z/rt/gcAAAEDAACAAgAAABUAAADYCAAAhYAhAAAZSF9fUEFHRVpFUk8A
AAABAAAZGAMAAF9fVEVYVAAA
AQCQnQEAkJ0BAAcFCQBfX3Rl
eHQAX19URVhUAAALAAABRCF5AQAACwAACAAA
''')
so I think it makes sense to support other whitespaces in fromhex. I'm happy to
reconsider if there's a strong argument against adding this convenience.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28927>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28927] bytes.fromhex should ignore all whitespace
Robert Xiao added the comment: Sorry, I should have clarified that these methods consider *ASCII whitespace* equivalent - just like my proposed patch. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28927] bytes.fromhex should ignore all whitespace
Robert Xiao added the comment: Terry, can you elaborate what you mean by a tradeoff? I feel like such a patch makes .fromhex more consistent with other string methods like .split() and .strip() which implicitly consider all whitespace equivalent. Martin, I've updated the patch to include documentation updates and more testcases. -- Added file: http://bugs.python.org/file45933/fromhex.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28927] bytes.fromhex should ignore all whitespace
Robert Xiao added the comment: I used Py_ISSPACE, which uses the .strip() default charset - I think this is a reasonable choice. We don't have to go crazy and support all the Unicode spaces. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28927] bytes.fromhex should ignore all whitespace
New submission from Robert Xiao:
bytes.fromhex ignores space characters now (yay!) but still barfs if fed
newlines or tabs:
>>> bytes.fromhex('ab\ncd')
Traceback (most recent call last):
File "", line 1, in
ValueError: non-hexadecimal number found in fromhex() arg at position 2
>>> bytes.fromhex('ab\tcd')
Traceback (most recent call last):
File "", line 1, in
ValueError: non-hexadecimal number found in fromhex() arg at position 2
It's often quite useful to paste blobs of hex into source code (or the REPL)
and call ".fromhex" on them. These might include spaces, tabs and/or newlines,
and barfing on these other whitespace characters is inconvenient.
I propose that bytes.fromhex should ignore all whitespace. A patch + test is
attached.
--
files: fromhex.patch
keywords: patch
messages: 282811
nosy: nneonneo
priority: normal
severity: normal
status: open
title: bytes.fromhex should ignore all whitespace
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file45823/fromhex.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28927>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10109] itertools.product with infinite iterator cause MemoryError.
Robert Xiao added the comment: It wouldn't be that complicated to have the combinatorial functions be lazy too - I feel like there's some value to be had there. What's the major objection to making all of the itertools functions "maximally lazy"? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10109] itertools.product with infinite iterator cause MemoryError.
Robert Xiao added the comment: I think this _is_ a bug. Most of the itertools are quite thrifty with memory, and exceptions are explicitly documented. The itertools generally only require memory proportional to the number of iterations consumed. However, `itertools.product` requires an enormous up-front memory cost even if only a few iterations are performed. There are good reasons to extract only a few iterations from a `product` - for example, a search procedure where only the first item in the product is infinite: for year, day in product(count(2010), range(365)): if rare_event(year, day): break Or, in an application I recently tried, to count occurrences of something up to a limit: prod = product(count(), range(n)) filtered = ifilter(pred, prod) want = list(islice(filtered, 101)) if len(want) > 100: print "Too many matches" Having `product` greedily consume all of its input iterators is rather antithetical to the notion of itertools being lazy generators, and it breaks efficient composability with the other itertools. The fix should be fairly straightforward: like tee, maintain lists of items already generated as the input iterators are exhausted, and add a note that "product"'s memory usage may slowly grow over time (as opposed to growing to maximum size immediately). -- nosy: +nneonneo ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25145] urllib how-to should be updated to remove PyGoogle
New submission from Robert Xiao: PyGoogle has been dead for 6-7 years at this point (probably longer), yet the newest urllib documentation (https://docs.python.org/3/howto/urllib2.html#id1) still refers to it in a footnote: [1] Like Google for example. The proper way to use google from a program is to use PyGoogle of course. This should probably be amended to remove the outdated reference altogether (the footnote itself can probably just go). While we're at it: the user agent version strings are _really_ old - MSIE 5.5 and MSIE 6.0. I know they are just illustrative, but couldn't we at least update them to something from the last decade? :P -- assignee: docs@python components: Documentation messages: 250863 nosy: docs@python, nneonneo priority: normal severity: normal status: open title: urllib how-to should be updated to remove PyGoogle versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18458] interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update
Changes by Robert Xiao nneon...@gmail.com: Removed file: http://bugs.python.org/file32320/readline.so ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18458 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18458] interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update
Robert Xiao added the comment: Russell, that's not related to readline. Please file a new bug report. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18458 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18458] interactive interpreter crashes and test_readline fails with newer versions of libedit
Robert Xiao added the comment: I've attached a fixed readline.so built from today's 2.7 branch, for the convenience of anyone who upgraded to 10.9 and now has crashing Python. Drop the file in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload, replacing the original readline.so. This file is compatible with both 32-bit and 64-bit python.org builds of Python 2.7.5. -- nosy: +nneonneo Added file: http://bugs.python.org/file32320/readline.so ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18458 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17048] calendar should understand full- vs. half-width characters
New submission from Robert Xiao: Try this at your command-prompt (requires utf8 support in the terminal emulator): $ python3 -m calendar -L zh_CN -e utf8 The result is a mess like this: 2013 一月二月三月 一 二 三 四 五 六 日 一 二 三 四 五 六 日 一 二 三 四 五 六 日 1 2 3 4 5 6 1 2 3 1 2 3 7 8 9 10 11 12 13 4 5 6 7 8 9 10 4 5 6 7 8 9 10 14 15 16 17 18 19 20 11 12 13 14 15 16 17 11 12 13 14 15 16 17 21 22 23 24 25 26 27 18 19 20 21 22 23 24 18 19 20 21 22 23 24 28 29 30 31 25 26 27 28 25 26 27 28 29 30 31 Note the irregular spacing. The calendar module assumes that the characters are half-width, when in reality they are full-width characters. calendar should use unicodedata.east_asian_width to determine if a character is full- or half-width, and adjust the spacing accordingly. -- components: Library (Lib) messages: 180748 nosy: nneonneo priority: normal severity: normal status: open title: calendar should understand full- vs. half-width characters versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17049] calendar throws UnicodeEncodeError when locale is specified
New submission from Robert Xiao: Try this at a command-prompt: $ python -m calendar -L ja_JP --encoding utf8 The result is a crash: Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py, line 162, in _run_module_as_main __main__, fname, loader, pkg_name) File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py, line 72, in _run_code exec code in run_globals File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/calendar.py, line 708, in module main(sys.argv) File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/calendar.py, line 703, in main result = result.encode(options.encoding) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 49: ordinal not in range(128) The reason is because the TimeEncoding class doesn't properly return the encoding it should use, so 'encoding' ends up being None in with TimeEncoding(self.locale) as encoding: lines. Trivial patch: --- calendar.py 2013-01-27 03:48:08.0 -0500 +++ calendar.py 2013-01-27 03:48:08.0 -0500 @@ -488,6 +488,7 @@ def __enter__(self): self.oldlocale = _locale.getlocale(_locale.LC_TIME) _locale.setlocale(_locale.LC_TIME, self.locale) +return self.locale[1] def __exit__(self, *args): _locale.setlocale(_locale.LC_TIME, self.oldlocale) -- components: Library (Lib) messages: 180750 nosy: nneonneo priority: normal severity: normal status: open title: calendar throws UnicodeEncodeError when locale is specified versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17048] calendar should understand full- vs. half-width characters
Robert Xiao added the comment: This is also a problem in Python 2.7 after the patch in issue17049 is applied. -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17051] Memory leak in os.path.isdir under Windows
New submission from Robert Xiao: [From http://stackoverflow.com/questions/12648737/huge-memory-leak-in-repeated-os-path-isdir-calls] os.path.isdir() leaks memory under Windows in Python 2.7. The core cause is this snippet: Modules/posixmodule.c:4226: if (!PyArg_ParseTuple(args, et:_isdir, Py_FileSystemDefaultEncoding, path)) return NULL; attributes = GetFileAttributesA(path); if (attributes == INVALID_FILE_ATTRIBUTES) Py_RETURN_FALSE; check: if (attributes FILE_ATTRIBUTE_DIRECTORY) Py_RETURN_TRUE; else Py_RETURN_FALSE; The buffer returned by the et ParseTuple format must be freed after use. Since it isn't freed, we get a memory leak here. Patch: --- a/Modules/posixmodule.c Mon Apr 09 19:04:04 2012 -0400 +++ b/Modules/posixmodule.c Sun Jan 27 04:10:34 2013 -0500 @@ -4226,6 +4226,7 @@ return NULL; attributes = GetFileAttributesA(path); +PyMem_Free(path); if (attributes == INVALID_FILE_ATTRIBUTES) Py_RETURN_FALSE; -- components: Library (Lib) messages: 180754 nosy: nneonneo priority: normal severity: normal status: open title: Memory leak in os.path.isdir under Windows type: resource usage versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17051] Memory leak in os.path.isdir under Windows
Robert Xiao added the comment: The PSF form really needs a PDF version. Anyway, 'tis duly submitted. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16125] open accepts arbitrary mode strings as long as they contain U
New submission from Robert Xiao:
This issue affects Python 2.5 through 2.7, but not Python 3.
open accepts basically anything for the second argument, so long as it either
starts with r, w, or a, or contains U somewhere in the string. Therefore, the
following are all legal in Python 2.7.3:
open('/tmp/a', 'wail')
open file '/tmp/a', mode 'wail' at 0x100468ed0
open('/tmp/a', 'PAIL')
open file '/tmp/a', mode 'PAIL' at 0x100468270
open('/tmp/a', 'rabid')
open file '/tmp/a', mode 'rabid' at 0x100468ed0
open('/tmp/a', 'alpha[]')
open file '/tmp/a', mode 'alpha[]' at 0x100468270
open('/tmp/a', 'raw')
open file '/tmp/a', mode 'raw' at 0x100468270
Because the mode string is literally a copy of the passed-in mode, it is not
clear at all what the mode of the file actually is. For example, in the last
case, I cannot write to the file even though the mode contains 'w', because the
mode is actually 'r'.
I think there are two ways to fix this: either fix the whole mode parsing logic
in Objects/fileobject.c to resemble that in Modules/_io/fileio.c from Python 3
(which does proper validation), or just build and store the calculated mode
(e.g. rb) so it's at least possible to determine the file mode.
--
components: IO
messages: 171922
nosy: nneonneo
priority: normal
severity: normal
status: open
title: open accepts arbitrary mode strings as long as they contain U
versions: Python 2.6, Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16125
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16125] open accepts arbitrary mode strings as long as they contain U
Changes by Robert Xiao nneon...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16125 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13844] hg.python.org doesn't escape title attributes in annotate view
New submission from Robert Xiao nneon...@gmail.com: On hg.python.org, the annotate view doesn't properly escape the title attribute of the a elements, resulting in breakage on the left column: http://hg.python.org/cpython/annotate/728cfc671d15/Modules/Setup.config.in -- components: None messages: 151860 nosy: nneonneo priority: normal severity: normal status: open title: hg.python.org doesn't escape title attributes in annotate view type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13844] hg.python.org doesn't escape title attributes in annotate view
Robert Xiao nneon...@gmail.com added the comment: My testing suggests that this issue is already fixed in Mercurial itself, since using hg serve on a local copy gives the expected result. Thus, the problem is probably with hg.python.org's local installation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13458] _ssl memory leak in _get_peer_alt_names
New submission from Robert Xiao nneon...@gmail.com:
_ssl.c has a memory leak in _get_peer_alt_names.
The `names' object is initialized here:
Modules/_ssl.c:601:
if (method-it)
names = (GENERAL_NAMES*)
(ASN1_item_d2i(NULL,
p,
ext-value-length,
ASN1_ITEM_ptr(method-it)));
else
names = (GENERAL_NAMES*)
(method-d2i(NULL,
p,
ext-value-length));
However, `names' is not freed after use, so it simply leaks.
Trivial patch:
--- a/Modules/_ssl.c2011-09-03 12:16:46.0 -0400
+++ b/Modules/_ssl.c2011-11-22 19:41:12.0 -0400
@@ -679,6 +679,8 @@
}
Py_DECREF(t);
}
+
+sk_GENERAL_NAME_pop_free(names, GENERAL_NAME_free);
}
BIO_free(biobuf);
if (peer_alt_names != Py_None) {
I tested this with a private certificate containing a subjectAltName field, and
the following code:
import ssl, socket
sock = ssl.wrap_socket(socket.socket(), cert_reqs=ssl.CERT_REQUIRED)
sock.connect(('localhost', 443))
for i in range(10):
x=sock._sslobj.peer_certificate()
Before this change, Python's memory usage would continually increase to about
45MB at the end of the loop. After this change, the memory usage stays constant
at around 6MB.
--
components: Library (Lib)
messages: 148154
nosy: nneonneo
priority: normal
severity: normal
status: open
title: _ssl memory leak in _get_peer_alt_names
type: resource usage
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13458
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13458] _ssl memory leak in _get_peer_alt_names
Robert Xiao nneon...@gmail.com added the comment: Attaching patch. -- keywords: +patch Added file: http://bugs.python.org/file23760/ssl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13458] _ssl memory leak in _get_peer_alt_names
Robert Xiao nneon...@gmail.com added the comment: Also applies to Python 2.7. -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13384] Unnecessary __future__ import in random module
New submission from Robert Xiao nneon...@gmail.com: Lib/random.py in Python 3.2 contains the line from __future__ import division even though it is no longer necessary, as true float division is the default in Python 3. Trivial patch: --- lib/python3.2/random.py 2011-09-03 20:32:05.0 -0400 +++ lib/python3.2/random.py 2011-11-11 11:11:11.0 -0400 @@ -36,7 +36,6 @@ -from __future__ import division from warnings import warn as _warn from types import MethodType as _MethodType, BuiltinMethodType as _BuiltinMethodType from math import log as _log, exp as _exp, pi as _pi, e as _e, ceil as _ceil -- components: Library (Lib) messages: 147437 nosy: nneonneo priority: normal severity: normal status: open title: Unnecessary __future__ import in random module versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13384 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13339] Missing semicolon at Modules/posixsubprocess.c:4511
New submission from Robert Xiao nneon...@gmail.com:
Line 4511 of Modules/posixsubprocess.c is missing a semicolon, so it would not
compile successfully if the relevant build flags were enabled (PYOS_OS2).
Trivial patch:
@@ -4508,7 +4508,7 @@
static PyObject *
posix_spawnvpe(PyObject *self, PyObject *args)
{
-PyObject *opath
+PyObject *opath;
char *path;
PyObject *argv, *env;
char **argvlist;
No tests needed since it's a compile error.
--
components: Extension Modules
messages: 146995
nosy: nneonneo
priority: normal
severity: normal
status: open
title: Missing semicolon at Modules/posixsubprocess.c:4511
type: compile error
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13339
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12576] urlib.request fails to open some sites
Robert Xiao nneon...@gmail.com added the comment: S3 also doesn't send any kind of connection header at all. x-amz-id-2: WWuo30Fk2inKVcC5dH4GOjvHxnqMa5Q2+AduPm2bMhL1h3GqzOR0EPwUv0biqv2V x-amz-request-id: 3CCF6B6A000E6446 Date: Sat, 23 Jul 2011 06:42:45 GMT x-amz-meta-s3fox-filesize: 27692 x-amz-meta-s3fox-modifiedtime: 121329234 Last-Modified: Thu, 12 Jun 2008 17:45:12 GMT ETag: c4db184c97f1d6b0b6e7ee17a73e785b Accept-Ranges: bytes Content-Type: application/pdf Content-Length: 27692 Server: AmazonS3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12576] urlib.request fails to open some sites
Robert Xiao nneon...@gmail.com added the comment:
Seconded. #12133 inadvertently closes the response object if the server fails
to indicate Connection: close. In my case, Amazon S3 (s3.amazonaws.com)
causes this problem:
(Python 3.2)
conn =
urllib.request.urlopen('http://s3.amazonaws.com/SurveyMonkeyFiles/VPAT_SurveyMonkey.pdf')
len(conn.read())
27692
(Python 3.2.1)
conn =
urllib.request.urlopen('http://s3.amazonaws.com/SurveyMonkeyFiles/VPAT_SurveyMonkey.pdf')
len(conn.read())
0
The problem is that S3 doesn't send back a Connection: close header, so when
h.close() is called from request.py, the request object is also closed;
consequently, conn.fp is None and so conn.read() returns an empty bytes object.
This is a clear regression due to the patch in #12133.
--
nosy: +nneonneo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12576
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12587] tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a UTF8 BOM signature
New submission from Robert Xiao nneon...@gmail.com: From a fresh Python3.2.1 tarball: nneonneo@nneonneo-mbp:~/devel/Python-3.2.1/Lib/test$ for i in tokenize_tests-*; do echo $i; xxd $i | head -n 1; done tokenize_tests-latin1-coding-cookie-and-utf8-bom-sig.txt 000: efbb bf23 202d 2a2d 2063 6f64 696e 673a ...# -*- coding: tokenize_tests-no-coding-cookie-and-utf8-bom-sig-only.txt 000: efbb bf23 2049 4d50 4f52 5441 4e54 3a20 ...# IMPORTANT: tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt 000: efbb bf23 202d 2a2d 2063 6f64 696e 673a ...# -*- coding: tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt 000: efbb bf23 202d 2a2d 2063 6f64 696e 673a ...# -*- coding: From this, it appears that the file called tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt actually has a UTF-8 BOM signature, which means either the comment is lying or the BOM was accidentally added to the test file at some point. -- messages: 140694 nosy: nneonneo priority: normal severity: normal status: open title: tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a UTF8 BOM signature type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12587] tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a UTF8 BOM signature
Robert Xiao nneon...@gmail.com added the comment: Yes, it seems that way. Then the question is: why does the comment claim that it doesn't have a BOM? Also, test_tokenize.py is wrong around line 651: def test_utf8_coding_cookie_and_no_utf8_bom(self): f = 'tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt' self.assertTrue(self._testFile(f)) It reads the wrong file in this case, judging by the testcase name. (This makes it a duplicate of the test_utf8_coding_cookie_and_utf8_bom case) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12587] tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a UTF8 BOM signature
Robert Xiao nneon...@gmail.com added the comment: Attached is a patch which fixes this. Python 3.2.1 still passes the test after applying the patch, as expected. -- keywords: +patch Added file: http://bugs.python.org/file22701/issue12587.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12002] ftplib.FTP.abort fails with TypeError on Python 3.x
New submission from Robert Xiao nneon...@gmail.com:
On Python 3.2, calling abort() on an ftplib.FTP object will cause an exception:
ftp = ftplib.FTP('localhost')
ftp.abort()
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.2/ftplib.py, line 246, in abort
self.sock.sendall(line, MSG_OOB)
TypeError: 'str' does not support the buffer interface
The offending line, ftplib.py:246, should be replaced by
self.sock.sendall(line.encode(self.encoding), MSG_OOB)
--
components: Library (Lib)
messages: 135158
nosy: nneonneo
priority: normal
severity: normal
status: open
title: ftplib.FTP.abort fails with TypeError on Python 3.x
type: crash
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12002
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Robert Xiao nneon...@gmail.com added the comment: Do you have it in any kind of repository at all? Even a private SVN repo or something like that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5677] Serious interpreter crash and/or arbitrary memory leak using .read() on writable file
Robert Xiao nneon...@gmail.com added the comment:
It seems like this is actually a problem in Windows libc or something (tested
using MinGW on Windows XP):
#include stdio.h
main() {
FILE *f = fopen(test, wb);
fwrite(test, 1, 4, f);
char buf[2048];
size_t k = fread(buf, 1, 2048, f);
printf(%d\n, k);
int i=0;
for(; ik; i++) printf(%02x, buf[i]);
}
This causes a lot of garbage to be printed out. Removing the fwrite causes 0
to be printed with no further output.
The garbage is not from the uninitialized buffer, since I've verified that the
original contents of the buffer are not what is being printed out. Furthermore,
adjusting 2048 produces a maximum output of 4092 bytes (even with in place
of 2048).
Short of simply denying read() on writable files, I don't really see an easy
way around this libc bug.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5677
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7586] Typo in collections documentation
New submission from Robert Xiao nneon...@gmail.com: In the documentation for the namedtuple (http://docs.python.org/3.1/library/collections.html), the following phrase is incorrect: The subclass shown above sets __slots__ to an empty tuple. This keeps keep memory requirements low by preventing the creation of instance dictionaries. It should read The subclass shown above sets __slots__ to an empty tuple. This helps keep memory requirements low by preventing the creation of instance dictionaries. or The subclass shown above sets __slots__ to an empty tuple. This keeps memory requirements low by preventing the creation of instance dictionaries. (either change keeps to helps, or delete the next keep). -- assignee: georg.brandl components: Documentation messages: 96931 nosy: georg.brandl, nneonneo severity: normal status: open title: Typo in collections documentation type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7586 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5762] AttributeError: 'NoneType' object has no attribute 'replace'
Robert Xiao nneon...@gmail.com added the comment: Have you tried this with xml.dom.minidom? -- nosy: +nneonneo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5677] Serious interpreter crash and/or arbitrary memory leak using .read() on writable file
New submission from Robert Xiao nneon...@gmail.com: (tested and verified on Windows and Solaris SPARC) Running this code in Python 2.4, 2.5 or 2.6 (all minor versions) produces garbage. f=open(anyfile,w) f.write(garbage) f.readline() Mac OS X and Linux appear to simply throw an IOError: [Errno 9] Bad file descriptor exception, while using a read method without writing first produces the same exception on Windows and certain versions under Solaris. Under Solaris, it is further possible to segfault the interpreter with this code: f=open(anyfile,w) f.read() In the former case, it appears as if the data is simply read from the disk block containing the file. In the latter, I have no clue what is going on. In Python 3.0, file objects opened with w don't even support any .read methods, so this does not affect Py3k. -- components: Interpreter Core messages: 85286 nosy: nneonneo severity: normal status: open title: Serious interpreter crash and/or arbitrary memory leak using .read() on writable file type: crash versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5677 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5677] Serious interpreter crash and/or arbitrary memory leak using .read() on writable file
Robert Xiao nneon...@gmail.com added the comment: OK, it's not a memory leak, rather, it's something leaking from the files. However, this still winds up filling the affected file full of garbage, which is quite undesirable (and, I think, quite likely to be unwanted behaviour, considering that *some* read methods throw IOError 9 and some others don't). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5677 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Robert Xiao nneon...@gmail.com added the comment: Frankly, I don't really like that idea; I think it muddles up the RE syntax to have such a group-modifying operator, and seems rather unpythonic: the existing way to do this -- use .upper(), .lower() or .title() to format the groups in a match object as necessary -- seems to be much more readable and reasonable in this sense. I think the proposed changes look good, but I agree that the focus should be on breaking up the megapatch into more digestible feature additions, starting from the barebones engine. Until that's done, I doubt *anyone* will want to review it, let alone merge it into the main Python distribution. So, I think we should hold off on any new features until this raft of changes can be properly broken up, reviewed and (hopefully) merged in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Robert Xiao nneon...@gmail.com added the comment:
In fact, it works for Python 2.4, 2.5, 2.6 and 3.0 from my rather
limited testing.
In Python 2.4:
u\N{LATIN CAPITAL LETTER A}
u'A'
u\N{MUSICAL SYMBOL DOUBLE SHARP}
u'\U0001d12a'
In Python 3.0:
\N{LATIN CAPITAL LETTER A}
'A'
ord(\N{MUSICAL SYMBOL DOUBLE SHARP})
119082
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2636
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
