The function PyOS_GetLastModificationTime() is documented in sys.rst as taking
a "char*". However, in reality, it takes a "char*" and a "FILE*". Actually,
it should take a "char const*", as it doesn't and shouldn't modify the path.
Further, the normal version doesn't use the path at all, the RISCOS version
in 2.7 does however, and for a CE port it would be convenient to have that
There is another issue, and that is that the function isn't declared anywhere,
and I'm not sure where it should be declared either. Actually, I'm not sure
if is suitable/intended for public consumption, so I wonder if putting it
into 'Include' would be right.
Any suggestions how to deal with that issue?
Python 3.0 is released and supports unicode everywhere, great! But as pointed
by different people, bytes are required on non-Windows OS for backward
compatibility. This email is just a sum up all many issues/email threads.
Problems with Python 3.0:
(1) Invalid unicode string on the command line
=> some people wants to get the command line arguments as bytes
and so start even if non decodable unicode strings are present
on the command line
(2) Non decodable environment variables are skipped in os.environ
=> Create os.environb (or anything else) to get these variables
as bytes (and be able to setup new variables as bytes)
=> Read the email thread "Python-3.0, unicode, and os.environ"
(Decembre 2008) opened by Toshio Kuratomi
(3) Support bytes for os.exec*() and subprocess.Popen(): process arguments
and the environment variables
=> http://bugs.python.org/issue4035: my patch for os.exec*()
=> http://bugs.python.org/issue4036: my patch for subprocess.Popen()
I like the curent behaviour and I don't want to change it. Be free to propose
a solution to solve the issue ;-)
I already proposed "os.environb" which will have the similar API
than "os.environ" but with bytes. Relations between os.environb and
- for an undecodable variable value in os.environb, os.environ will raise
a KeyError. Example with utf8 charset and os.environb[b'PATH'] = '\xff':
path=os.environ['PATH'] will raise a KeyError to keep the current
- os.environ raises an UnicodeDecodeError if the key or value can not be
encoded in the current charset. Example with ASCII charset:
os.environ['PATH'] = '/home/hayp\xf4'
- except undecodable variable values in os.environb, os.environ and
os.environb will be consistent. Example: delete a variable in
os.environb will also delete the key in os.environ.
I think that most of these points (or all points) are ok for everyone
(especially ok for Toshio Kuratomi and me :-)).
Now I have to try to write an implementation of this, but it's complex,
especially to keep os.environ and os.environb consistents!
I proposed patches to fix non-Windows OS, but Antoine Pitrou wants also bytes
on Windows. Amaury wrote that it's possible using the ANSI version of the
Windows API. I don't know this API and so I can not contribute to this point.
Use a private Unicode block causes interoperability problems:
- the block may be already used by other programs/libraires
- 3rd party programs/libraries don't understand this block and may
have problems this display/process the data
(Is the idea really rejected? It has at least many problems)
I don't have new solutions, it's just an email to restart the discussion about
bytes ;-) Martin also asked for a PEP to change the posix module API to
Victor Stinner aka haypo
Alexander Belopolsky wrote:
> 4. Should exported symbols be always declared in headers or is it ok
> to just declare them as extern in .c files where they are used?
Is the concern that moving them to a header makes them part of the API?
In other words, does replacing
PyFile_FromString(char *name, char *mode)
extern int fclose(FILE *);
mean that the <stdio.h> needs to be included from then on, even if
PyFile_FromString stops relying upon it?
Just wondered if/when there'd be a Mac installer for Python 3?
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3" - ISBN 0137129297
The doc for os.path.commonprefix states:
Return the longest path prefix (taken character-by-character) that is a
prefix of all paths in list. If list is empty, return the empty string
(''). Note that this may return invalid paths because it works a
character at a time.
I remember encountering this in an earlier version of Python 2.x (maybe 2.2
or 2.3?) and "fixed" it to work by pathname components instead of by
characters. That had to be reverted because it was a behavior change and
broke code which used it for strings which didn't represent paths. After
the reversion I then forgot about it.
I just stumbled upon it again. It seems to me this would have been a good
thing to fix in 3.0. Is this something which could change in 3.1 (or be
deprecated in 3.1 with deletion in 3.2)?
I would like to mention that I've written a patch which enables "threaded
interpretation" on the ceval loop with gcc (*). On my computer (an Athlon X2
3600+), it is good for a 15-20% speedup of the interpreter on pystone and
pybench. I also had the opportunity to test it on a Core2-derived CPU, where it
doesn't make a difference (I conjecture it's because Core2 CPUs have
hardware-based indirect branch optimizations). It will make no difference if the
interpreter is compiled with something else than gcc (I tested on Windows).
The additional complexity is very small. There's a separate script which is run
to build the dispatch table (only if needed, that is if dis.py has been
modified). In ceval.c, there are a couple of macros and some #ifdef's. That's
all. It breaks no test in the regression suite.
Could other people test and report their results here? (the patch is for py3k,
btw). Also, what are you thoughts for/against integrating this patch in the
(*) please note: it has nothing to see with multithreading.
In python 2.6, there have been some effort to make float formatting
more consistent between platforms, which is nice. Unfortunately, there
is still one corner case, for example on windows:
print a -> print 'inf'
print '%f' % a -> print '1.#INF'
The difference being that in the second case, the formatting is done
in floatformat.c (in stringobject.c), whereas in the first case, it is
done in format_float (in floatobject.c). Shouldn't both functions be
calling the same underlying implementation, to avoid those
Does anyone have local access to a sparc machine to try to track down
the ongoing buildbot failures in test_subprocess?
(I think the problem is specific to 3.x builds on sparc machines, but I
haven't checked the buildbots all that closely - that assessment is just
based on what I recall of the buildbot failure emails).
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia