I wanted to take a few minutes to let you all know that the recent call for help with translating Python Insider was met with a wave of enthusiastic contributors. We now have teams prepared to translate all posts to Simplified and Traditional Chinese, German, Japanese, Portuguese, Romanian, and Spanish. Setting up each blog takes a bit of effort, so we are launching them in batches as they are ready. When all of the existing teams are launched, I will be looking for translators for additional languages.
The next time you have Python related information that you would like to share with the community, I hope you will consider working with us and publishing it through Python Insider, so it can reach the widest possible audience. Either Brian Curtin or I can help you get set up, so contact one of us directly when you are ready.
Michael Foord wrote:
> On 06/05/2011 18:26, Mark Shannon wrote:
>> Michael Foord wrote:
>>> On 06/05/2011 17:51, Stefan Behnel wrote:
>>>> Mark Shannon, 06.05.2011 18:33:
>>>>> skip(a)pobox.com wrote:
>>>>>> Antoine> Since we're sharing links, here's Matt Mackall's take:
>>>>>>> From that note:
>>>>>> 1: You can't have meaningful destructors, because when destruction
>>>>>> happens is undefined. And going-out-of-scope destructors are
>>>>>> useful. Python is already a rather broken in this regard, so feel
>>>>>> to ignore this point.
>>>>>> Given the presence of cyclic data I don't see how reference
>>>>>> counting or
>>>>>> garbage collection win. Ignoring the fact that in a pure reference
>>>>>> system you won't even consider cycles for reclmation, would both
>>>>>> RC and GC
>>>>>> have to punt because they can't tell which object's destructor to
>>>>> It doesn't matter which is called first.
>>>> May I quote you on that one the next time my software crashes?
>>> Arbitrarily breaking cycles *could* cause a problem if a destructor
>>> attempts to access an already collected object. Not breaking cycles
>>> *definitely* leaks memory and definitely doesn't call finalizers.
>> You don't need to break the cycles to call the finalizers. Just call
>> them, then collect the whole cycle (assuming it is still unreachable).
>> The GC will *never* reclaim a reachable object. Objects awaiting
>> finalization are reachable, by definition.
> Well it was sloppily worded, so replace it with:
> if a finalizer attempts to access an already finalized object.
A finalized object will still be a valid object.
Python code cannot make an object unsafe.
Obviously C code can make it unsafe, but that's true of C code anywhere.
For example, a file object will close itself during finalization,
but its still a valid object, just a closed file rather than an open one.
>>>> It may not make a difference for the runtime, but the difference for
>>>> user software may be "dead" or "alive".
>>>> Python-Dev mailing list
On Thu, 05 May 2011 20:38:27 +0200
raymond.hettinger <python-checkins(a)python.org> wrote:
> changeset: 69858:2bc784057226
> parent: 69856:b06ad8458b32
> parent: 69857:1a56775c6e54
> user: Raymond Hettinger <python(a)rcn.com>
> date: Thu May 05 11:38:06 2011 -0700
> Avoid codec spelling issues by just using the utf-8 default.
> Lib/random.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> diff --git a/Lib/random.py b/Lib/random.py
> --- a/Lib/random.py
> +++ b/Lib/random.py
> @@ -114,7 +114,7 @@
> if version == 2:
> if isinstance(a, (str, bytes, bytearray)):
> if isinstance(a, str):
> - a = a.encode("utf-8")
> + a = a.encode()
Isn't explicit better than implicit? By reading the new code it is not
obvious that any thought was given to the choice of a codec, while
stating "utf-8" explicitly hints that a decision was made.
(also, I don't understand the spelling issue: "utf-8" just works)
On Tue, May 3, 2011 at 3:19 PM, victor.stinner
> +# Issue #10276 - check that inputs of 2 GB are handled correctly.
> +# Be aware of issues #1202, #8650, #8651 and #10276
> +class ChecksumBigBufferTestCase(unittest.TestCase):
> + int_max = 0x7FFFFFFF
> + @unittest.skipUnless(mmap, "mmap() is not available.")
> + def test_big_buffer(self):
> + if sys.platform[:3] == 'win' or sys.platform == 'darwin':
> + requires('largefile',
> + 'test requires %s bytes and a long time to run' %
> + str(self.int_max))
> + try:
> + with open(TESTFN, "wb+") as f:
> + f.seek(self.int_max-4)
> + f.write("asdf")
> + f.flush()
> + try:
> + m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
> + self.assertEqual(zlib.crc32(m), 0x709418e7)
> + self.assertEqual(zlib.adler32(m), -2072837729)
> + finally:
> + m.close()
> + except (IOError, OverflowError):
> + raise unittest.SkipTest("filesystem doesn't have largefile support")
> + finally:
> + unlink(TESTFN)
0x7FFFFFFF is (2G-1) bytes. For a 2GB buffer, int_max should be
0x80000000. However, if you make this change, crc32() and adler32()
raise OverflowErrors (see changeset a0681e7a6ded). This makes the test
to erroneously report that the filesystem doesn't support large files.
The assertEqual() tests should probably be changed to
Also, the assignment to m needs to be moved outside of the inner
try...finally block. If mmap() fails, the call to m.close() raises a
new exception because m has not yet been bound. This seems to be
causing failures on some of the 32-bit buildbots.
As an aside, in this sort of situation is it better to just go and
commit a fix myself, or is raising it on the mailing list first the
right way to do things?