I'd like to include the patch for bug 3890 in Python 2.6.3. There is
a patch by Amaury that has gotten the blessing of Bill Janssen,
however the patch has no test.
Is there anybody who can come up with a test in the next few hours so
we can get this into 2.6.3rc1?
If not, is the fix important enough to include without the test?
I'm currently working on a reimplementation of io.FileIO, which would
allow cross-platform file range locking and all kinds of other safety
features ; however I'm slightly stuck due to some specification
fuzziness in the IO docs.
The main points that annoy me at the moment :
- it is unclear what truncate() methods do with the file pointer, and
even if the current implementation simply moves it to the truncation
point, it's very contrary to the standard way of doing under unix, where
the file pointer is normally left unchanged. Shouldn't we specify that
the file pointer remains unmoved, and fix the _fileio module accordingly ?
- exceptions are not always specified, and even if most of them are
IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if
we try to wrap a wrong file descriptor when instanciating a new FileIO).
This might lead to bad program crashes if some people don't "refuse the
temptation to guess" and only get prepared to catch IOErrors
- the doc sometimes says that when we receive an empty string from a
read() operation, without exceptions, it means the file is empty.
However, with the current implementation, if we call file.read(0), we
simply receive "", even though it doesn't mean that we're at EOF.
Shouldn't we avoid this (rare, I admit) ambiguity on the return value,
by preventing read(0) ? Or at least, note in the doc that (we receive an
empty string) <-> (the file is at EOF OR we called read with 0 as
Are there some arguments that I don't know, which lead to this or that
particular implementation choice ?
I'd strongly advocate very detailled specifications, letting no room for
cross-platform subtilities (that's also a strong goal of my
reimplemntation), since that new IO system (which saved me a lot of
coding time, by the way) should become the base of many programs.
So wouldn't it be a godo idea to write some kind of mini-pep, just to
fix the corner cases of the current IO documentation ? I might handle
it, if no more-knowledgeable people feels like it.
Found in current io PEP :
Q: Do we want to mandate in the specification that switching between
reading and writing on a read-write object implies a .flush()? Or is
that an implementation convenience that users should not rely on?
-> it seems that the only important matter is : file pointer positions
and bytes/characters read should always be the ones that the user
expects, as if there
were no buffering. So flushing or not may stay a non-mandatory
behaviour, as long as the buffered streams ensures this data integrity.
Eg. If a user opens a file in r/w mode, writes two bytes in it (which
stay buffered), and then reads 2 bytes, the two bytes read should be
those on range [2:4] of course, even though the file pointer would, due
to python buffering, still be at index 0.
Q from me : What happens in read/write text files, when overwriting a
three-bytes character with a single-byte character ? Or at the contrary,
when a single chinese character overrides 3 ASCII characters in an UTF8
file ? Is there any system designed to avoid this data corruption ? Or
should TextIO classes forbid read+write streams ?
IO Exceptions :
Currently, the situation is kind of fuzzy around EnvironmentError
* OSError represents errors notified by the OS via errno.h error codes
(as mirrored in the python "errno" module).
errno.h errors (less than 125 error codes) seem to represent the whole
of *nix system errors. However, Windows has many more system errors
(15000+). So windows errors, when they can't be mapped to one of the
errno errors are raises as "WindowsError" instances (a subclass of
OSError), with the special attribute "winerror" indicating that win32
* IOError are "errors raised because of I/O problems", but they use
errno codes, like OSError.
Thus, at the moment IOErrors rather have the semantic of "particular
case of OSError", and it's kind of confusing to have them remain in
their own separate tree... Furthermore, OSErrors are often used where
IOErrors would perfectly fit, eg. in low level I/O functions of the OS
Since OSErrors and IOErrors are slightly mixed up when we deal with IO
operations, maybe the easiest way to make it clearer would be to push to
their limits already existing designs.
- the os module should only raise OSErrors, whatever the os operation
involved (maybe it's already the case in CPython, isn't it ?)
- the io module should only raise IOErrors and its subclasses, so that
davs can easily take measures depending on the cause of the io failure
(except 1 OSError exception, it's already the case in _fileio)
- other modules refering to i/o might maybe keep their current (fuzzy)
behaviour, since they're more platform specific, and should in the end
be replaced by a crossplatform solution (at least I'd love it to happen)
Until there, there would be no real benefits for the user, compared to
catching EnvironmentErrors as most probably do. But the sweet thing
would be to offer a concise but meaningfull IOError hierarchy, so that
we can easily handle most specific errors gracefully (having a disk full
is not the same level of gravity as simply having another process
locking your target file).
Here is a very rough beginning of IOError hierarchy. I'd liek to have
people's opinion on the relevance of these, as well as on what other
exceptions should be distinguished from basic IOErrors.
+-InvalidStreamError (eg. we try to write on a stream opened in
+-PermissionError (mostly *nix chmod stuffs)
+-MaxFileSizeError (maybe hard to implement, happens when we exceed
4Gb on fat32 and stuffs...)
+-InvalidFileNameError (filepath max lengths, or "? / : " characters
in a windows file name...)
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson <benjamin(a)python.org> wrote:
> 2009/9/27 Steven Bethard <steven.bethard(a)gmail.com>:
>> On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson <benjamin(a)python.org> wrote:
>>> 2009/9/27 Steven Bethard <steven.bethard(a)gmail.com>:
>>>> The first release where any real deprecation message would show up is
>>>> Python 3.4, more than 3 years away. If you think 3 years isn't long
>>>> enough for people to be over the Python 3 transition, let's stick in
>>>> another version in there and make it 4.5 years.
>>> So, why even bother deprecating it if nobody is going to see the warnings?
>> I feel like I'm repeating the PEP, but here it is again anyway. There
>> will be messages in the docs and pending deprecation warnings (which
>> don't show up by default but can be requested) starting in Python 2.7
>> and 3.2. Regular deprecation warnings wouldn't show up until Python
>> 3.4, 3 years away. This compromise was intended exactly to address the
>> issue you brought up about people getting over the Python 3
> But that doesn't tell me why we should deprecate optparse, when it may
> work perfectly well for some people.
Because it's basically unmaintained, and anything you can do in
optparse you can do in argparse with almost identical syntax. So
encouraging people to move from getopt and optparse to argparse is a
net gain for us as Python maintainers -- that's two fewer modules in
the standard library that someone has to take care of bug reports for.
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
I have a first draft of a PEP for including an IP address manipulation
library in the python stdlib. It seems like there are a lot of really
smart folks with some, ahem, strong ideas about what an IP address
module should and shouldn't be so I wanted to solicit your input on
the pep can be found here:
the code can be found here:
Please let me know if you have any comments (some already coming :)
I'm looking for advice on how to clean up an ugliness (one
that I'm at least partly responsible for) in the Python build setup.
Here's the problem: some of the exported functions (e.g. atanh,
log1p) in the Python/pymath.c file aren't needed by the Python core
at all; they're exported solely for use in the math and cmath modules.
Even worse, these exported functions have no '_Py' or 'Py' prefix.
Since I'm currently working on adding some oft-requested
functions to the math module (gamma, lgamma, erf, ...) it seemed
like a good time to clean this up.
So I've now got a file Modules/math_support.c that contains
some functions needed by both mathmodule.c and
cmathmodule.c, as well as a couple of functions only
currently needed by the math module. How should I incorporate
this file into the build?
One obvious solution seems to be to build an extra math_support.so
file that's then used by both mathmodule.so and cmathmodule.so.
Is this a sensible solution? Are there better ways?
A complication to bear in mind is that some users may want to
alter Modules/Setup.dist so that either the math module and/or
the cmath module is included in the core Python executable.
I floated a proposal on stdlib-sig to create a file named
Misc/maintainers.rst. The purpose of this file is to collect knowledge
about who knows which modules well enough to make decision about issues
in the tracker when the participants in the issue aren't sure, and to
write down the community knowledge about who has special interest and
expertise in specific topic areas.
This proposal was met with approval and, after a couple of small
modifications of the proposal, no dissent; so I've created the skeleton
of the file. I've filled in some of the blanks where I had personal
knowledge, was told info on IRC, from the two referenced PEPs, and
from PEP 11.
Feel free to respond with comments about the header text, but more
importantly let me know what you know about who (especially if it is you)
should be listed for each module, platform, and topic, and feel free to
suggest additional topics. My goal is to record the community knowledge.
Another topic of discussion that is orthogonal to filling in the table is
whether or not to publish it outside the repository. Jesse would like to
see it included in the Python Documentation, and Georg has suggested the
possibility of creating a separate, sphinx-based, automatically-uploaded
document collection in the repository to contain this and related
The module list was built from the py3k documentation module index, with
the addition of 'pybench' from PEP 291. If there are other modules/tools
that are missing, or submodules that should be broken out into
separate lines, please let me know.
After the initial flurry of updates and comments dies down I will check
This document cross references Python Modules (first table) and platforms
(second table) with the Tracker user names of people who are experts
and/or resources for that module or platform. This list is intended
to be used by issue submitters, issue triage people, and other issue
participants to find people to add to the nosy list or to contact
directly by email for help and decisions on feature requests and bug
fixes. People on this list may be asked to render final judgement on a
feature or bug. If no active maintainer is listed for a given module,
then questionable changes should go to python-dev, while any other issues
can and should be decided by any committer.
The last part of this document is a third table, listing broader topic
areas in which various people have expertise. These people can also
be contacted for help, opinions, and decisions when issues involve
If a listed maintainer does not respond to requests for comment for an
extended period (three weeks or more), they should be marked as inactive
in this list by placing the word 'inactive' in parenthesis behind their
tracker id. They are of course free to remove that inactive mark at
Committers should update this table as their areas of expertise widen.
New topics may be added to the third table at will.
The existence of this list is not meant to indicate that these people
*must* be contacted for decisions; it is, rather, a resource to be used
by non-committers to find responsible parties, and by committers who do
not feel qualified to make a decision in a particular context.
See also `PEP 291`_ and `PEP 360`_ for information about certain modules
with special rules.
.. _`PEP 291`: http://www.python.org/dev/peps/pep-0291/
.. _`PEP 360`: http://www.python.org/dev/peps/pep-0360/
io pitrou, benjamin.peterson
modulefinder theller, jvr
subprocess astrand (inactive)
xml.etree effbot (inactive)
Interest Area Maintainers
import machinery brett.cannon
io pitrou, benjamin.peterson
mathematics marketdickinson, eric.smith
time and dates
Just four more days to propose a presentation!
Call for proposals -- PyCon 2010 -- <http://us.pycon.org/2010/>
Due date: October 1st, 2009
Want to showcase your skills as a Python Hacker? Want to have
hundreds of people see your talk on the subject of your choice? Have some
hot button issue you think the community needs to address, or have some
package, code or project you simply love talking about? Want to launch
your master plan to take over the world with python?
PyCon is your platform for getting the word out and teaching something
new to hundreds of people, face to face.
Previous PyCon conferences have had a broad range of presentations,
from reports on academic and commercial projects, tutorials on a broad
range of subjects and case studies. All conference speakers are volunteers
and come from a myriad of backgrounds. Some are new speakers, some
are old speakers. Everyone is welcome so bring your passion and your
code! We're looking to you to help us top the previous years of success
PyCon has had.
PyCon 2010 is looking for proposals to fill the formal presentation tracks.
The PyCon conference days will be February 19-22, 2010 in Atlanta,
Georgia, preceded by the tutorial days (February 17-18), and followed
by four days of development sprints (February 22-25).
Online proposal submission is open now! Proposals will be accepted
through October 1st, with acceptance notifications coming out on
November 15th. For the detailed call for proposals, please see:
For videos of talks from previous years - check out:
We look forward to seeing you in Atlanta!
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/
"Look, it's your affair if you want to play with five people, but don't
go calling it doubles." --John Cleese anticipates Usenet
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few weeks to avoid 2.x having features which 3.x
doesn't. If no one has problems with this, I will draft a schedule.
Are we still planning to make 3.3 the main development focus and start
the 5 years of 2.x maintenance after this release?
Additionally, I'm very apprehensive about doing any kind of release
without the buildbots running. Does anyone know when they might be up?
I dont know it is the right place to post this question. I need help to change one search code line . can you help me please.
here is my search method code:
search=re.compile("^#acl InternationalGroup.*\n", re.M).search(pagetext)
here i am searching for "#acl InternationalGroup" in the pageText and when it true is then give me search group.
I want to change this for following requirement:
I want to search for "#acl InternationalGroup" and "CatInternational" in the pageText.
when "#acl InternationalGroup" is not there but "CatInternational" is there. then return me search group.
I shall be thankful to you for any help.
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!