Currently running the test suite, even without any resource flags,
renders my machine unusable for at least part of the test execution. The
main culprit appears to be the checks for expected memory errors in
Does anyone have any objections to making the offending test dependent
on a resource flag after beta 3 is out the door?
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On my quest to remove warnings raised in 2.6 when Python is run with
-3, the issue of dealing with mimetools has come up in terms of
backwards-compatibility. For instance, in BaseHTTPServer, the headers
attribute on BaseHTTPRequestHandler is an instance of
mimetools.Message. But in 3.0 it is an instance of
So my question is, should 2.6 be changed to match 3.0, or should
deprecation warnings for mimetools (and possibly other modules) just
be silenced so as to not risk breaking backwards-compatibility?
Le Saturday 19 July 2008 21:52:09 A.M. Kuchling, vous avez écrit :
> Excellent work! Another fruitful area for fuzzing might be the
> miniature virtual machine used by the re module. It's possible to
> import _sre and call the compile() function directly (see the end of
> Lib/sre_compile.py for how it's invoked); I wonder how the regex VM
> copes with random strings of bytecode.
Hum... how can I say it? It's trivial to crash _sre :-) So I blacklisted
_sre.compile() in my fuzzer.
For information, it's also very easy to crash CPython with fuzzed .pyc file.
It's hard to check bytecode without execute it. It's maybe better to add
checks directly in the VM.
Victor Stinner aka haypo
Are big merges from the trunk still being made to the py3k branch? I
checked in a change to csv.DictReader on the trunk yesterday evening. I
will port it to py3k if necessary, but I was under the impression that the
merge gnomes are constantly busy at work behind the scene. If this activity
has been curtailed because we are nearly late betas or something, let me
know and I'll do it myself.
I'm confused as to how you represent a bytes object in hexadecimal in Python
3. Of course in Python 2, you use str.encode('hex') to go to hex, and
hexstr.decode('hex') to go from hex.
In Python 3, they removed "hex" as a codec (which was a good move, I think).
Now there's the static method bytes.fromhex(hexbytes) to go from hex. But I
haven't figured out any (easy) way to convert a byte string to hex. Is there
some way I haven't noticed, or is this an oversight?
The easiest thing I can think of currently is this:
''.join(hex(b)[2:] for b in mybytes)
I think there should be a bytes.tohex() method. I'll add this as a bug
report if it indeed is an oversight, but I thought I'd check here first to
make sure I'm not just missing something.
I'm trying to understand the architecture of the core Python interpreter and
virtual machine, but I've been having trouble finding the documentation. It
looks like most of the docs are for either writing Python programs or
extending / writing modules. Is there any documentation (or papers) geared
towards understanding the core? The closest I could find was this,
but that is still geared towards extending it with C modules. I guess I'm
more interested in python's security architecture, but anything about the VM
or interpreter would be great!
We reached an important milestone in the IronPython project this week
with the release of IronPython 2.0 beta 4. But it's not our code that
makes this release so remarkable -- it's yours, the Python developers.
For the first time, Microsoft is including the standard Python
library as part of what you can download from CodePlex. Previously,
users of IronPython who wanted to make use of the urllib module (to
give just one example) would have to download the CPython distribution
separately and then fiddle with the bits on the disk to make them work
together. That is no longer the case.
Of course, this isn't any kind of great technical achievement -- but
it is legal and cultural progress here at Microsoft. All of us
working on the IronPython and IronRuby projects are committed to
pulling the company in a more open source direction, so it's very
gratifying to see this happening.
(IronPython 2.0 targets compatibility with Python 2.5.)
On Wed, Jul 30, 2008 at 12:49 PM, Bill Janssen <janssen(a)parc.com> wrote:
>> > unquote() -- takes string, produces bytes or string
>> > If optional "encoding" parameter is specified, decodes bytes with
>> > that encoding and returns string. Otherwise, returns bytes.
>> The default of returning bytes will break almost all uses. Most code
>> will uses the unquoted result as a text string, not as bytes -- e.g. a
>> server has to unquote the values it receives from a form (whether POST
>> or GET), but almost always the unquoted values are text, e.g.
>> someone's name or address, or a draft email message.
> I actually do know a lot about the uses of this function...
> But: OK, OK, I yield. Though I still think this is a bad idea, I'll
> shut up if we can also add "unquote_as_bytes" which returns a byte
> sequence instead of a string. I'll just change my code to use that.
>> (Aside: I dislike functions that have a different return type based on
>> the value of a parameter.)
> Fair enough.
I think this is as close as consensus as we can get on this issue. Can
whoever wrote the patch adjust the patch to this outcome? (I think the
only change is to remove the encoding arguments and make separate
functions for bytes.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
Hello heroes and heroins of the python universe, lend me your ears and
I will tell you a tale that will make your platters spin!
As noted by SQLite  and MySQL  developers, fsync on OS X does
not actually flush a file to disk... instead OS X provides "fullfsync"
which actually flushes the file descriptor to disk. This simple patch
modifies python's "fsync" to take advantage of fullfsync on platforms
that support it:
While some people might suggest that fullfsync should be exposed as a
method on the 'os' module for platforms that support it, I believe
this is not the best approach. Because the docstring for os.fsync
says that it forces the file to be written to disk, I think it's up to
python to ensure that functionality is really there on all platforms.
Currently on OS X, fullfsync is needed to provide this functionality,
so I think python's os.fsync should use fullfsync on OS X.
Looking at 'svn blame' output for Modules/posixmodule.c, I see that
guido wrote the original python fsync, ronald.oussoren added all the
OS X specific stuff to posixmodule.c, and recent commits have been
made to that file by martin.v.loewis. christian.heimes,
facundo.batista, and gregory.p.smith. Would any of you fine folks
like to take a look at this? I believe it's a *very* small patch.
Many thanks, -Ian Charnas
 SQLite uses fullfsync on all platforms that define it:
 MySQL uses fullfsync only on the darwin platform and only when
F_FULLFSYNC is defined as 51, which seems to be short-sighted in that
this symbol may change value in future versions of OS X. To see this
code, download a mysql 5.x source snapshot and open up