Walter Dörwald wrote:
> We should have one uniform way of representing time in Python. IMHO
> datetime objects are the natural choice.
Alas datetime objects do not unambiguously identify a point in time.
datetime objects are not timestamps: They represent the related but
different concept of _local time_, which can be good for presentation,
but shouldn't be allowed anywhere near a persistent store.
Gary Robinson wrote:
> It's been around 7 years since I've used C, I've forgotten virtually
> everything I may have known about gdb, I've never worked with the
> C-python API before... meanwhile there is intense time pressure to get
> the next release of our product (http://www.goombah.com) ready. So
> just not practical for me to take that on myself now. I'm hoping to
> some help from other pythonistas where someone will say -- "yes, it's
> getting a bus error for so-and-so reason, and if you do it this other
> way, you'll be fine..."
Well, it appears you have a workaround (METH_VARARGS) so I'd suggest
using that for now, and raise a bug report at SourceForge
Stuart Bishop writes:
> When I invoke subprocess.call(), I often want to ensure that the subprocess'
> stdin is closed. This ensures it will die if the subprocess attempts to read
> from stdin rather than block.
> This could be done if the subprocess.call() helper closes the input if
> stdin=subprocess.PIPE, which may be the only sane way to handle this
> argument (I can't think of any use cases for spawning a subprocess with an
> input stream that nothing can write too).
+0.5. I agree that if you pass "stdin=subprocess.PIPE" to subprocess.call()
that the current behavior of having the child process block forever is
totally useless. I have little reason to prefer "assume an empty input"
over "let subprocess.call() raise an exception if stdin==subprocess.PIPE"
-- but if I take your word for it that this is a common need, then that's
one good reason.
> It could also be done by adding a subprocess.CLOSED constant, which if
> passed to Popen causes a new closed file descriptor to be given to the
It is easy enough to create a closed FD to read from... why complicate the
-- Michael Chermside
>>>> One more issue is open: the one of naming. As "path" is already
>>>> the name of a module, what would the new object be called to
>>>> avoid confusion? pathobj? objpath? Path?
>>> I would argue for Path.
>> Granted "path" is actually os.path, but I don't think it's
>> wise to have stdlib modules whose names are differentiated only
>> by case, especially on Windows (and other case-insensitive
[Phillip J. Eby]
> This is the name of a *class*, not a module.
Sorry - it sounded like the idea was to put this class in a module by itself
(i.e. the class would be os.Path.Path).
> I.e., we are discussing
> adding a Path class to the 'os' module, that implements the
> interface of the "path" module.
In that case, I would argue against Path as the name of the class because
it's confusing to have "os.path" be the path module, and "os.Path" be an
class that provides an interface to that module.
I think differentiating things solely on the case of the name is a bad idea.
At 12:08 PM 6/27/2005 +1200, Tony Meyer wrote:
> >> One more issue is open: the one of naming. As "path" is already the
> >> name of a module, what would the new object be called to avoid
> >> confusion? pathobj? objpath? Path?
> > I would argue for Path.
>Granted "path" is actually os.path, but I don't think it's wise to have
>stdlib modules whose names are differentiated only by case, especially on
>Windows (and other case-insensitive filesystems).
This is the name of a *class*, not a module. I.e., we are discussing
adding a Path class to the 'os' module, that implements the interface of
the "path" module.
We can't call it "path" (as a top-level module) because the interface will
not be backward-compatible with current uses and installations of the
>> One more issue is open: the one of naming. As "path" is already the
>> name of a module, what would the new object be called to avoid
>> confusion? pathobj? objpath? Path?
> I would argue for Path.
Granted "path" is actually os.path, but I don't think it's wise to have
stdlib modules whose names are differentiated only by case, especially on
Windows (and other case-insensitive filesystems).
On 24-jun-2005, at 21:46, tim_one(a)users.sourceforge.net wrote:
> Update of /cvsroot/python/python/dist/src/Tools/bgen/bgen
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18095/Tools/
> Modified Files:
> bgenGenerator.py bgenObjectDefinition.py bgenType.py
> bgenVariable.py scantools.py
> Log Message:
> Normalize whitespace to avoid offending Bug Day volunteers.
Argh, sorry... I thought I had all my machines educated to do tab
expansion for Python, but apparently not...
Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
I'm trying to develop an extension module in C, but am having some
difficulties. I thought about posting to the general python mailling
list, but since it has to do with the C API I figured this was the correct
My difficulty lies with subclassing a class provided by another external
module. I have access to the structure definition, so I can determine the
size fo the tp_basicsize member of the PyTypeObject structure. What I
can't seem to determine is value for the tp_base element.
This is my current "best guess".
superclass = PyObject_GetAttrString( module, "SuperClass" );
if ( !superclass ) return;
type.tp_base = superclass->ob_type;
Py_DECREF( superclass );
type.tp_new = PyType_GenericNew;
if ( PyType_Ready( &type ) < 0 ) return;
Unfortunately, I seem to be inheriting from the type object for
SuperClass, and not from SuperClass itself.
I would greatly appreciate some direction on this issue.
Simon Fraser University
You've just read two summaries, but here is another one, as we come back up
to speed. If at all possible, it would be great if we could send this out
in time to catch people for the bug day (very tight, we know), so if anyone
has a chance to check this straight away, that would be great.
Please send any amendments to Steve (steven.bethard(a)gmail.com) as that
probably gives us the best chance of getting it out on time.
As always, many thanks for the proofreading!
Bug Day: Saturday, June 25th 2005
AMK is organizing another Python Bug Day this Saturday, June 25th. If you're
looking to help out with Python, this is a great way to get started!
- `Bug day on the 25th?
FishEye for Python CVS
Peter Moore has kindly set up `Fish Eye for the Python CVS repository`_.
FishEye is a repository browsing, searching, analysis and monitoring tool,
with great features like RSS feeds, Synthetic changesets, Pretty ediffs and
SQL like searches. Check it out!
.. _Fish Eye for the Python CVS repository:
- `FishEye on Python CVS Repository
PyPy Sprint: July 1st - 7th 2005
The next `PyPy`_ sprint is scheduled right after EuroPython 2005 in
Gothenborg, Sweden. It will focus mainly on translating PyPy to lower level
backends, so as to move away from running PyPy on top of the CPython
interpreter. There will be newcomer-friendly introductions, and other
topics are possible, so if you have any interest in PyPy, now is the time
to help out!
.. _PyPy: http://codespeak.net/pypy
- `Post-EuroPython 2005 PyPy Sprint 1st - 7th July 2005
Reminder: Google's Summer of Code
Just a reminder that the friendly folks at Python have set up a `wiki`_ and
a `mailing list`_ for questions about `Google's Summer of Code`_. For
specific details on particular projects (e.g. what needs done to complete
Python SSL support) participants may also ask questions to the Python-Dev
.. _wiki: http://wiki.python.org/moin/CodingProjectIdeas
.. _mailing list: http://mail.python.org/mailman/listinfo/summerofcode
.. _Google's Summer of Code: http://code.google.com/summerofcode.html
hashlib Review Request
Gregory P. Smith noted that he has finished up the hashlib work he started
on a few months ago for patches `935454`_ and `1121611`_ (where the final
patch is). He feels that the patch is ready, and would like anyone
interested to review it; the patch incorporates both OpenSSL hash support
and SHA256+SHA512 support in a single module. `The documentation`_ can be
accessed separately, for convenience.
.. _935454: http://python.org/sf/935454
.. _1121611: http://python.org/sf/1121611
.. _The documentation:
- `hashlib - faster md5/sha, adds sha256/512 support
PEP 343 Progress
The PEP 343 discussions were mostly concluded. Guido posted the newest
version of the PEP to both Python-Dev and Python-List and the discussions
that followed were brief and mostly in agreement with the proposal.
The PEP 343 syntax was modified slightly to require parentheses if VAR is a
comma-separated list of variables. This made the proposal
forward-compatible to extending the with-block for multiple resources. In
the favored extension, the with-block would take multiple expressions in a
manner analogous to import statements::
with EXPR1 [as VAR1], EXPR2 [as VAR2], ...:
There were also some brief discussions about how with-blocks should behave
in the presence of async exceptions like the KeyboardInterrupt generated
from a ^C. While it seemed like it would be a nice property for with-blocks
to guarantee that the __exit__ methods would still be called in the
presence of async exceptions, making such a guarantee proved to be too
complicated. Thus the final conclusion, as summarized by Nick Coghlan, was
that "with statements won't make any more guarantees about this than
try/finally statements do".
- `PEP 343 rewrite complete
- `For review: PEP 343: Anonymous Block Redux and Generator Enhancements
- `PEP 343 - next steps
- `PEP 343 question
Raymond Hettinger asked for a "dowhile" loop of the form::
which would run <body> once before testing the <cond>, and then proceed as a
normal while-loop. He was subsequently referred to `PEP 315`_, which
proposes a slightly different syntax for a similar purpose.
The discussion expanded to not only do-while loops, but also loops with
break conditions at locations other than the beginning and the end of a
loop. A variety of syntax proposals were suggested, but none seemed
compellingly better than the current syntax::
which supports putting the condition(s) at any location in the loop.
.. _PEP 315: http://www.python.org/peps/pep-0315.html
- `Wishlist: dowhile
Reference Counting in Module Globals
Both Michael Hudson and Skip Montanaro noticed that Py_INCREFs appeared to
be unnecessary when adding an object to a module's globals. Armin Rigo
explained that after a module is initialized, the import mechanism makes a
"hidden" copy of the module's dict so that the module can be reloaded. This
means that objects added as module globals will always have an extra
reference count in this hidden dict.
However, Armin Rigo agreed with Michael Hudson that this explanation was no
longer applicable after an interpreter shutdown. The best conclusion he
could draw in this a situation: "it's all quite obscure".
- `refcounting vs PyModule_AddObject
- `[Python-checkins] python/dist/src/Modules _csv.c, 1.37, 1.38
Reorganising the standard library (again)
The ever-popular topic of reorganising the standard library came up again
this fortnight, courtesy of Reinhold Birkenfeld. The questions posed
included hierarchy (flat/nested), third party modules, size (batteries
included or not), and the standard GUI toolkit.
As usual, there was a great deal of discussion, but not a great deal of
consensus about any of these (other than that including ElementTree in the
standard library would be good), and given the amount of breakage this would
involve (and that Guido didn't weigh in at all), it seems unlikely that much
will change before Python 3000; although Josiah Carlson indicated that he
had a patch that would avoid a lot of breakage.
- `Thoughts on stdlib evolvement
First Mac-tel, now Py-tel?
Guido mentioned that Intel has a free (as in beer) C `compiler for Linux`_,
and that a friend of his (who is involved in its production and marketing)
would like to see how it performs with Python. The compiler wasn't news to
some of the -dev crowd, though, with Martin v. Löwis pointing out a `bug
report on the compiler`_, as well as a `patch`_, and a `message indicating
that some people had problems`_ with the resulting interpreter.
Martin pointed out that there were some old (2002 and 2004) results
indicating that the Intel compiler was slightly faster, but couldn't find
any results for the latest version. Michael Hoffman gave summaries of more
testing, which gave a 16% speed increase. He felt that, while this was
significant, he wasted a lot of time dealing with resulting problems with
extension modules, and so doesn't use as much any more.
.. _compiler for Linux:
.. _bug report on the compiler: http://python.org/sf/1162001
.. _patch: http://python.org/sf/1162023
.. _message indicating that some people had problems:
- `Compiling Python with Intel compiler?
Reinhold Birkenfeld noticed that sys.path's first element is '' in
interactive sessions, but the directory containing the script otherwise,
and wondered if this was intentional. Guido clarified that he's always
liked it this way, so that if you use os.path.join to join it with a script
name you don't get a spurious ".\" preprended.
The "absolutizing" of sys.path entries, however, is reasonably new; Bob
Ippolito pointed out that is also `problematic with regards to path
hooks`_. He has a `patch to fix it`_, but hasn't had a chance to commit it;
Phillip J. Eby noted that the patch doesn't fix completely fix it, however,
and indicated that fixing site.py with respect to `PEP 302`_ will be quite
.. _problematic with regards to path hooks:
.. _patch to fix it: http://python.org/sf/1174614
.. _PEP 302: http://python.org/peps/pep-0302.html
- `sys.path in interactive session
More on old bugs
The discussion about what to do with old bugs continued this fortnight.
Against the concern about prematurely closing old bugs, there was the
suggestion that given that there are such a huge number of open bug reports,
and since closed bugs can be reopened, this wasn't such a problem. It was
suggested that the act of closing a bug might trigger activity to get it
fixed, if necessary. The thread died off before a consensus was reached,
- `Closing old bugs
Improved pseudo-switch statements
Skip Montanaro has been playing around with getting the Python compiler to
recognize switch-like statements and generate O(1) code out of them. The
rules are that the object being compared ('x') can be any expression, but
must be precisely the same in each elif clause, the comparison operator
must be "==", and the right-hand-side of the test must evaluate to a simple
hashable constant. However, if evaluating 'x' has side-effects, then this
would break code.
Various people felt that it was unwise to allow 'x' to be any expression;
Anthony Baxter suggested that one could allow any local object that didn't
define a comparison operator.
- `Multiple expression eval in compound if statement?
- `Adventures with Decimal
- `Weekly Python Patch/Bug Summary
- `AST manipulation and source code generation
- `Vestigial code in threadmodule?
- `[Python-checkins] python/dist/src/Lib sre_compile.py, 1.57, 1.58
- `Split MIME headers into multiple lines near a space
- `python running in several threads
- `problem installing current cvs
- `b32encode and NUL bytes
- `Example workaround classes for using Unicode with csv module...
- `Weekly Python Patch/Bug Summary
- `[Python-checkins] python/dist/src/Doc/lib libtokenize.tex, 1.5, 1.6
- `Five patch reviews & patch request
- `AIX 4.3, Python 2.4.1 fails in test_exceptions with a core dump
- `PEP 342 - Enhanced Iterators
- `A bug in pyconfig.h under Linux?
- `Dynamic class inheritance && something else
- `Weekly Python Patch/Bug Summary