[issue4775] Incorrect documentation - UTC time
Martin v. Löwis mar...@v.loewis.de added the comment: The difference is that UTC includes leap seconds, whereas UT1 does not (see http://en.wikipedia.org/wiki/Coordinated_Universal_Time). The conversion routines ignore leap seconds, e.g., (time.mktime((2000,1,1,12,0,0,0,0,0))- time.mktime((1990,1,1,12,0,0,0,0,0))) returns an exact multiple of 24*60*60 and does not include all the leap seconds added between those dates. Read the documentation carefully. It doesn't claim that mktime uses UTC, and claiming that it uses UT1 would be equally incorrect. Instead, mktime uses local time (as documented). Whether that includes leap seconds or not depends on the definition of your time zone in your operating system. Also notice that the Unix time (time_t) is discontinuous with respect to leap seconds; each day time_t advances by 86400 seconds even if there was a leap second on that day; see http://en.wikipedia.org/wiki/Unix_time So even if your time zone includes leap seconds, then mktime still correctly computes the difference as multiple of 86400. Which specific other usage of UTC do you also consider incorrect? -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine
Martin v. Löwis mar...@v.loewis.de added the comment: I'm seeing the same symptoms that are described in issue 1543 with the 2.6b3 MSIs. Namely, when you run one of the MSIs (either 32-bit or 64-bit) then the other will refuse to install. This is on XP Pro x64 SP2. python-3.0b3.msi and python-3.0b3.amd64.msi exhibit the same problem. Having 32-bit and 64-bit version coexist makes it much easier to build extensions for and test on both versions at the same time. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3833] python-2.6b3.msi and python-2.6b3.amd64.msi can't both be installed on one machine
Martin v. Löwis mar...@v.loewis.de added the comment: It is possible to reattach messages to the issue. In this specific case, just append ?...@action=edit@a...@messages=73003 to the issue URL. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4096] Lib/lib2to3/*.pickle are shipped / modified in the build
Martin v. Löwis mar...@v.loewis.de added the comment: It's not sufficient that they get created when 2to3 needs them. It might be that the user running 2to3 has no permission to write them. I believe that it currently then just won't write them - but they won't be created, either (it used to be that it aborts when it can't write them) However, they should get installed with make install - so closing it as works for me. -- resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4096 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4750] tarfile keeps excessive dir structure in compressed files
Changes by Martin v. Löwis mar...@v.loewis.de: Removed file: http://bugs.python.org/file12452/tarfile.directory.fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4750] tarfile keeps excessive dir structure in compressed files
Martin v. Löwis mar...@v.loewis.de added the comment: No further bug fixes are accepted for 2.5 (unless they fix security problems), so I reject the 2.5 patch. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
Changes by Tarek Ziadé ziade.ta...@gmail.com: -- assignee: - tarek nosy: +tarek priority: - normal type: - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4778] Small typo in multiprocessing documentation
New submission from Dmitry Vasiliev d...@hlabs.spb.ru: Small typo about call Process.daemon flag. The patch attached. -- assignee: georg.brandl components: Documentation files: multiprocessing.patch keywords: patch messages: 78516 nosy: georg.brandl, hdima severity: normal status: open title: Small typo in multiprocessing documentation versions: Python 3.0 Added file: http://bugs.python.org/file12491/multiprocessing.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4778] Small typo in multiprocessing documentation
Georg Brandl ge...@python.org added the comment: Thanks, fixed in r68061. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
Tarek Ziadé ziade.ta...@gmail.com added the comment: Here's a status: The problem is located in the codec that decodes the data (called by the compile builtin). It throws an error : *** UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 853: character maps to undefined Which is caught by compile and translated into: SyntaxError: unknown encoding: cp1252 So I see two problems: 1/ why compile throws such an error when there's an UnicodeDecodeError 2/ why compile works well under Py2 since 0x9d is not part of the cp1252 mapping I have written a test that reproduces the problem, and I am still investigating. If I can't find the problem I will ask for help on python-dev because I have no knowledge in the compiler internals yet. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4779] Can't import Tkinter
New submission from pierre.lhoste pierre.lho...@voila.fr: I've just installed Python 3.0 (with Tkinter) on Windows Vista, but I can't import Tkinter : No module named Tkinter When installing Python 2.6, it works. Why ? Thank you. -- components: Tkinter messages: 78519 nosy: pierre.lhoste severity: normal status: open title: Can't import Tkinter versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4779] Can't import Tkinter
Quentin Gallet-Gilles qgal...@gmail.com added the comment: Tkinter has been renamed to tkinter (and been made a package) as part of the stdlib reorganisation : http://www.python.org/dev/peps/pep-3108/#tkinter-package -- nosy: +quentin.gallet-gilles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1011893] Problems importing packages in ZIP file
Martin v. Löwis mar...@v.loewis.de added the comment: It seems most people agree that this works for me. -- resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1011893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3997] zipfile and winzip
Changes by Martin v. Löwis mar...@v.loewis.de: -- priority: - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
Changes by Martin v. Löwis mar...@v.loewis.de: -- priority: - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
John Machin sjmac...@users.sourceforge.net added the comment:
TWO POINTS:
(1) I am not very concerned about chars like \x9d which are not valid in
the declared encoding; I am more concerned with chars like \x93 and \x94
which *ARE* valid in the declared encoding. Please ensure that these
cases are included in tests.
(2) Please check your test data and test results. I get different
results. I have created a file x9d.py by making the minimal changes to
x94.py. For me, this blows up on bytecompiling with *both* 3.0
(UnicodeDecodeError, as expected) and 2.x (Syntax Error unknown encoding
cp1252, wrong message) -- see below.
byte-compiling C:\python30\Lib\site-packages\x9d.py to x9d.pyc
Traceback (most recent call last):
File setup.py, line 5, in module
py_modules = [foo3, bar3, x93, x94, x9d, xa0b7]
File C:\python30\lib\distutils\core.py, line 149, in setup
dist.run_commands()
File C:\python30\lib\distutils\dist.py, line 942, in run_commands
self.run_command(cmd)
File C:\python30\lib\distutils\dist.py, line 962, in run_command
cmd_obj.run()
File C:\python30\lib\distutils\command\install.py, line 571, in run
self.run_command(cmd_name)
File C:\python30\lib\distutils\cmd.py, line 317, in run_command
self.distribution.run_command(command)
File C:\python30\lib\distutils\dist.py, line 962, in run_command
cmd_obj.run()
File C:\python30\lib\distutils\command\install_lib.py, line 91, in run
self.byte_compile(outfiles)
File C:\python30\lib\distutils\command\install_lib.py, line 125, in
byte_compile
dry_run=self.dry_run)
File C:\python30\lib\distutils\util.py, line 520, in byte_compile
compile(file, cfile, dfile)
File C:\python30\lib\py_compile.py, line 137, in compile
codestring = f.read()
File C:\python30\lib\io.py, line 1724, in read
decoder.decode(self.buffer.read(), final=True))
File C:\python30\lib\io.py, line 1295, in decode
output = self.decoder.decode(input, final=final)
File C:\python30\lib\encodings\cp1252.py, line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position
64: character maps to undefined
byte-compiling C:\python26\Lib\site-packages\x9d.py to x9d.pyc
SyntaxError: ('unknown encoding: cp1252',
('C:\\python26\\Lib\\site-packages\\x9d.py', 0, 0, None))
byte-compiling c:\python25\Lib\site-packages\x9d.py to x9d.pyc
File c:\python25\Lib\site-packages\x9d.py, line 0
SyntaxError: ('unknown encoding: cp1252',
('c:\\python25\\Lib\\site-packages\\x9d.py', 0, 0, None))
Added file: http://bugs.python.org/file12492/x9d.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4775] Incorrect documentation - UTC time
David Morley mor...@ai.sri.com added the comment: - My use of mktime was a bad choice for an example, since local time is not defined and does not necessarily bear any relationship to UTC. However the documentation does claim that time.gmtime converts a time expressed in seconds since the epoch to a struct_time in UTC. - You are no doubt correct that under Unix, Unix time is actually used, however the phrase a time expressed in seconds since the epoch implies the number of *elapsed* seconds since the epoch, which is not the same thing as Unix time. It was the fact that (at least under Mac OS X) the numeric representation assumes a 86400 second day that led me to believe that non-SI seconds and hence a non-UTC version of Universal Time, such as UT1 was being used. The documentation should make it clear either that (1) the numeric representation of times is based on Unix time and assumes a 86400 SI second day, and therefore (1a) the number of elapsed SI seconds between two numeric times is not necessarily equal to the difference of those two numbers and (1b) gmtime accurately converts a UTC time, or that (2) the numeric representation of times is based on a 86400 non-SI second day, and therefore (2a) the number of elapsed (non-SI) seconds between two numeric times is equal to the difference of the two numbers and (2b) gmtime accurately converts a non-UTC Universal Time, or that (3) the numeric representation of times is based on TAI and assumes a 86400 SI second day, and therefore (1a) the number of elapsed SI seconds between two numeric times is equal to the difference of those two numbers and (1b) gmtime accurately converts a TAI time, or that (4) the numeric representation of time is based on SI-seconds past the epoch and allows variable length days, and therefore (4a) the number of elapsed SI seconds between two numeric times is equal to the difference of the two numbers and (4b) gmtime only accurately converts a UTC time that is before the next future leap-second adjustment (whenever that may be), or that (5) the numeric representation of time is platform-dependent and any one of the above may hold. Note that the only significant difference in implementation between (1), (2), and (3) is what time.time() actually returns: Unix time, a non-UTC Universal Time, or TAI. Since the time.localtime is most-likely implemented as an integral- minute offset from time.gmtime, the same issues arise for time.localtime and time.mktime. The same documentation issue crops up in http://docs.python.org/library/datetime.html and indirectly (calendar.timegm) in http://docs.python.org/library/calendar.html ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
Marc-Andre Lemburg m...@egenix.com added the comment:
On 2008-12-30 13:20, John Machin wrote:
byte-compiling C:\python26\Lib\site-packages\x9d.py to x9d.pyc
SyntaxError: ('unknown encoding: cp1252',
('C:\\python26\\Lib\\site-packages\\x9d.py', 0, 0, None))
byte-compiling c:\python25\Lib\site-packages\x9d.py to x9d.pyc
File c:\python25\Lib\site-packages\x9d.py, line 0
SyntaxError: ('unknown encoding: cp1252',
('c:\\python25\\Lib\\site-packages\\x9d.py', 0, 0, None))
Added file: http://bugs.python.org/file12492/x9d.py
FWIW, I've tried that file with Python 2.5 and 2.6 on my machine:
lemburg/tmp python2.5 ~/bin/pycompile.py x9d.py
compiling x9d.py - x9d.pyc
XXX type 'exceptions.SyntaxError': unknown encoding: cp1252 (x9d.py, line
0)
lemburg/tmp python2.6 ~/bin/pycompile.py x9d.py
compiling x9d.py - x9d.pyc
XXX type 'exceptions.SyntaxError': unknown encoding: cp1252 (x9d.py, line
0)
Note that the line number is wrong in both messages.
It is interesting that simply running the files gives a more correct
error message:
lemburg/tmp python2.5 x9d.py
File x9d.py, line 2
SyntaxError: 'charmap' codec can't decode byte 0x9d in position 0: character
maps to undefined
lemburg/tmp python2.6 x9d.py
File x9d.py, line 2
SyntaxError: 'charmap' codec can't decode byte 0x9d in position 0: character
maps to undefined
The character position is wrong again in both messages.
Needless to say that the encoding cp1252 is *not* unknown. It looks
like compile() causes the decoding error to be overwritten with a
misleading error message.
--
nosy: +lemburg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
Tarek Ziadé ziade.ta...@gmail.com added the comment: yup, here's the test I have written to demonstrate the problem. In any case, compile doesn't behave right way in the first place. -- keywords: +patch Added file: http://bugs.python.org/file12493/encoding.issue.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
Changes by Tarek Ziadé ziade.ta...@gmail.com: Removed file: http://bugs.python.org/file12493/encoding.issue.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
Changes by Tarek Ziadé ziade.ta...@gmail.com: Added file: http://bugs.python.org/file12494/encoding.issue.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4702] [PATCH] msvc9compiler raises IOError when no compiler found instead of DistutilsError
Changes by Tarek Ziadé ziade.ta...@gmail.com: -- assignee: - tarek nosy: +tarek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4780] Makefile.pre.in patch to run regen on OSX (framework build)
New submission from Ronald Oussoren ronaldousso...@mac.com: I needed the attached patch to install a framework build of Python3 (py3k branch), otherwise the 'regen' script wouldn't start to build Lib/plat- mac. I haven't applied the patch to the repository because I don't know if there's a reason for not using RUNSHARED in the first place. -- components: Build files: Makefile.pre.in.patch keywords: needs review, patch, patch messages: 78526 nosy: ronaldoussoren priority: normal severity: normal status: open title: Makefile.pre.in patch to run regen on OSX (framework build) versions: Python 3.1 Added file: http://bugs.python.org/file12495/Makefile.pre.in.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4775] Incorrect documentation - UTC time
Martin v. Löwis mar...@v.loewis.de added the comment: It was the fact that (at least under Mac OS X) the numeric representation assumes a 86400 second day that led me to believe that non-SI seconds and hence a non-UTC version of Universal Time, such as UT1 was being used. AFAICT, Mac OSX also uses Unix time... Why do you think UT1 plays any role here? Computers *have* to use SI seconds, since they are not physically equipped to measure anything else (unless you want to get even more nit-picking and point out that the quartz in the computer is not capable of measuring SI seconds exactly). (5) the numeric representation of time is platform-dependent This is the case. and any one of the above may hold. This is not consequential. As it is platform dependent, it might do any of the above, plus an infinite number of additional alternatives (including bugs and whatnot). I propose to add this sentence to the explanation of the epoch: It is platform-dependent whether or not 'seconds since the epoch' includes leap seconds. Most systems likely implement `Unix time`_ _ http://en.wikipedia.org/wiki/Unix_time The same documentation issue crops up in http://docs.python.org/library/datetime.html and indirectly (calendar.timegm) in http://docs.python.org/library/calendar.html Please, one issue at a time. I believe that this doesn't crop up, or if it does, it's a different issue. If you want to pursue this, please create a separate report, and preferably include a proposed wording. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
John Machin sjmac...@users.sourceforge.net added the comment: (1) what am I supposed to infer from Yup?? That all of that \x9d stuff was a mistake? (2) +def tearDown(self): +pyc_file = os.path.join(os.path.dirname(__file__), 'cp1252.pyc') +if os.path.exists(pyc_file): +os.patth.remove(pyc_file) os.patth is novel :-) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4755] Common path prefix
Martin v. Löwis mar...@v.loewis.de added the comment: The documentation should explain what a common path prefix is. It can't be the path to a common parent directory, since the new function doesn't allow mixing absolute and relative directories. As Phillip Eby points out, it also doesn't account for case-insensitivity that some file systems or operating systems implement, nor does it take into account short file names on Windows. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4075] Use WCHAR variant of OutputDebugString
Changes by Martin v. Löwis mar...@v.loewis.de: -- resolution: - accepted ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4075] Use WCHAR variant of OutputDebugString
Changes by Martin v. Löwis mar...@v.loewis.de: -- stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4075] Use WCHAR variant of OutputDebugString
Changes by Martin v. Löwis mar...@v.loewis.de: -- assignee: - loewis priority: - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4755] Common path prefix
Skip Montanaro s...@pobox.com added the comment: I think we need to recognize the inherent limitations of what we can expect to do. It is perfectly reasonable for a user on Windows to import posixpath and call posixpath.commonpathprefix. The function won't have access to the actual filesystems being manipulated. Same for Unix folks importing ntpath and manipulating Windows paths. While we can make it handle case-insensitivity, I'm no sure we can do much, if anything, about shortened filenames. Also, as long as we are considering case sensitivity, what about HFS on Mac OS X? Skip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3872] Python 2.6rc2: Tix ComboBox error
Matthew Karas lucidgu...@gmail.com added the comment: I'm sorry, will this fix get into a new release? I tried using a tix widget on 2.6.1 and got the same error. -- nosy: +lucidguppy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4755] Common path prefix
Nick Coghlan ncogh...@gmail.com added the comment: 1. The discussion on python-dev shows that the current documentation of os.path.commonprefix is incorrect - it technically works element by element rather than character by character (since it will handle sequences other than strings, such as lists of path components) 2. Splitting on os.sep is not the correct way to break a string into path components. Instead, os.path.split needs to be applied repeatedly until head is a single character (a single occurrence of os.sep or os.altsep for an absolute path) or empty (for a relative path). (Alternatively, but with additional effects on the result, the separators can be normalised first with os.path.normpath or os.path.normcase) For Windows, os.path.splitunc and os.path.splitdrive should also be invoked first, and if either returns a non-empty string, that should become the first path component (with the remaining components filled in as above) 3. Calling any or all of abspath/expanduser/expandvars/normcase/normpath/realpath is the responsibility of the library user as far as os.path.commonprefix is concerned. Should that behaviour be retained for an os.path.commonpath function, or should some of them (such as os.path.abspath) be called automatically? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4755] Common path prefix
Nick Coghlan ncogh...@gmail.com added the comment: The regex based approach to the component splitting when os.altsep is defined obviously works as well. Duplicating the values of sep and altsep in the default regex that way grates a little though... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4626] compile() doesn't ignore the source encoding when a string is passed in
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Issue4742 is similar issue:
source = b# coding=cp1252\n\x94 = '\x94'.decode('cp1252')
compile(source, 'test', 'exec')
Traceback (most recent call last):
File stdin, line 1, in module
File test, line 0
SyntaxError: unknown encoding: cp1252
The real error here is masked; just before the exception is set, there
is a pending
SyntaxError: 'charmap' codec can't decode byte 0x9d in position 18:
character maps to undefined
It seems that the source internal representation is correct utf-8, but
this is decoded again with the coding= cookie.
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4626
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
This is a duplicate of issue4626.
Here, the content is correctly decoded with cp1252, then passed to
compile(); but compile() works on the internal utf-8 representation, and
tries to decode it again with cp1252!
Yes, the error message is overwritten. If I remove the code that sets
the unknown encoding exception, I get:
compile(open(c:/temp/t1252.py, encoding=cp1252).read(),
t1252.py, exec)
SyntaxError: 'charmap' codec can't decode byte 0x9d in position 35:
character maps to undefined
The 0x9d explains easily:
b\x94.decode('cp1252').encode('utf8')
b'\xe2\x80\x9d'
--
nosy: +amaury.forgeotdarc
superseder: - compile() doesn't ignore the source encoding when a string is
passed in
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4742
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4779] Can't import Tkinter
Changes by Georg Brandl ge...@python.org: -- resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk?
Ronald Oussoren ronaldousso...@mac.com added the comment: The issue is caused by lack of support for building .dylibs in configure.in and Makefile.pre.in. AFAIK this has never worked on OSX. Fixing that is not entirely trivial (did I mention configure.in is rather crufty?). The attached patch should fix that (the patch touched configure.in, you'll have to run autoconf after applying the patch). Could you please test if the patch fixes the issue for you? -- keywords: +patch nosy: +ronaldoussoren Added file: http://bugs.python.org/file12496/issue4472.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4554] Missing make altframeworkinstall for Mac OS X
Ronald Oussoren ronaldousso...@mac.com added the comment: make frameworkinstall should be deprecated anyway, AFAIK it should be possible to use make install or make altinstall for framework installs as well. That latter should make it possible to install multiple versions of python side-by-side without interference beyond the Current link inside the framework. A patch to fix that last issue would be welcome ;-) BTW. The above comment is for python 2.x, I haven't checked the makefiles for python 3.x yet beyond trying to get a framework build to work at all (commited a patch for that earlier today). -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4554 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738250] Universal MacPython 2.5.1 installation fails
Ronald Oussoren ronaldousso...@mac.com added the comment: Can you reproduce this problem with the installer for Python 2.6? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1738250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk?
Ronald Oussoren ronaldousso...@mac.com added the comment: Never mind, the patch won't work. Python's build procedure on unix-y platforms assumes that the suffix for shared libraries is the same as that for python extentions. That's not true on OSX :-( I'm working on an updated patch. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk?
Changes by Ronald Oussoren ronaldousso...@mac.com: Removed file: http://bugs.python.org/file12496/issue4472.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4781] The function, Threading.Timer.run(), may be Inappropriate
New submission from Deli.Zhang gestapo2...@163.com: def run(self): self.finished.wait(self.interval) if not self.finished.isSet(): self.function(*self.args, **self.kwargs) self.finished.set() I think the function run() should be modified to like this below: def run(self): while not self.finished.isSet(): self.finished.wait(self.interval) self.function(*self.args, **self.kwargs) In this case, it can still run on next 'interval', and next's next... -- components: Library (Lib) messages: 78540 nosy: gestapo21th severity: normal status: open title: The function, Threading.Timer.run(), may be Inappropriate type: feature request versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk?
Ronald Oussoren ronaldousso...@mac.com added the comment: I've uploaded a new version of issue4472.patch that seems to do the trick: this supports --enable-shared and also still works without that flag. Added file: http://bugs.python.org/file12497/issue4472.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4782] json documentation missing load(), loads()
New submission from David M. Beazley beaz...@users.sourceforge.net: Documentation for the json module in Python 2.6 and Python 3.0 doesn't have any description for load() or loads() even though both functions are used in the examples. -- assignee: georg.brandl components: Documentation messages: 78542 nosy: beazley, georg.brandl severity: normal status: open title: json documentation missing load(), loads() versions: Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk?
Roumen Petrov bugtr...@roumenpetrov.info added the comment: What is reason to change SO to .dylib in configure script and later Lib/distutils/sysconfig.py to restore it to .so ? Also other builds use $(LDSHARED) to create python shared library. Why proposed patch introduce inconsistency with other builds and ignore LDSHARED set by configure script ? -- nosy: +rpetrov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk?
Roumen Petrov bugtr...@roumenpetrov.info added the comment: Skip, Why the issue title is without platform? Shared build is fine on Linux and Cygwin too. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk for Mac OS X?
Changes by Skip Montanaro s...@pobox.com: -- title: Is shared lib building broken on trunk? - Is shared lib building broken on trunk for Mac OS X? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk for Mac OS X?
Ronald Oussoren ronaldousso...@mac.com added the comment: SO=.dylib is needed in the makefile to ensure that make install works and to ensure that the libpython shared library is build with the right suffix (OSX uses .dylib for shared libraries). The code in distutils.sysconfig is necessary to ensure that extentions are build with a .so suffix because the import machinery expected '.so' as the suffix. BTW. I intent to commit the attached patch later this week. -- resolution: - accepted versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4263] BufferedWriter non-blocking overage
Antoine Pitrou pit...@free.fr added the comment: The tests should be written so as not to rely on internal implementation details (the _write_buf attribute). -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4263 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4742] 3.0 distutils byte-compiling - Syntax error: unknown encoding: cp1252
Changes by Tarek Ziadé ziade.ta...@gmail.com: -- resolution: - duplicate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4783] json documentation needs a BAWM (Big A** Warning Message)
New submission from David M. Beazley beaz...@users.sourceforge.net: The json module is described as having an interface similar to pickle: json.dump() json.dumps() json.load() json.loads() I think it would be a WISE idea to add a huge warning message to the documentation that these functions should *NOT* be used to serialize or unserialize multiple objects on the same file stream like pickle. For example: f = open(stuff,w) json.dump(obj1, f) json.dump(obj2, f)# NO! FLAMING DEATH! f = open(stuff,r) obj1 = json.load(f) obj2 = json.load(f) # NO! EXTRA CRIPSY FLAMING DEATH! For one, it doesn't work. load() actually reads the whole file into a big string and tries to parse it as a single object. If there are multiple objects in the file, you get a nasty exeption. Second, I'm not even sure this is technically allowed by the JSON spec. As far as I call tell, concatenating JSON objects together in the same file falls into the same category as concatenating two HTML documents together in the same file (something you just don't do). Related: json.load() should probably not be used on any streaming input source such as a file wrapped around a socket. The first thing it does is consume the entire input by calling f.read()---which probably not what someone is expecting (and it might even cause the whole program to hang). -- assignee: georg.brandl components: Documentation messages: 78547 nosy: beazley, georg.brandl severity: normal status: open title: json documentation needs a BAWM (Big A** Warning Message) type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4263] BufferedWriter non-blocking overage
Antoine Pitrou pit...@free.fr added the comment: Here is a patch which replaces testWriteNonBlocking with a reasonable implementation-independent test (it works with e.g. the io-c sandbox). The new test also checks for the current problem, i.e. it passes with the fix to io.py and fails without. Added file: http://bugs.python.org/file12498/nonblocking.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4263 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4783] json documentation needs a BAWM (Big A** Warning Message)
Changes by Benjamin Peterson benja...@python.org: -- assignee: georg.brandl - bob.ippolito nosy: +bob.ippolito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4784] Mismatch in documentation for module webbrowser
New submission from Eric Naeseth enaes...@gmail.com: In Python 2.5, a new method named open_new_tab was added to webbrowser and webbrowser's browser controller objects. With this addition, there are now three methods on browser controllers, but the documentation still reads: Browser controllers provide two methods which parallel *two* of the module-level convenience functions. -- assignee: georg.brandl components: Documentation messages: 78549 nosy: georg.brandl, improper_smile severity: normal status: open title: Mismatch in documentation for module webbrowser versions: Python 2.5, Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4785] json.JSONDecoder() strict argument undocumented and potentially confusing
New submission from David M. Beazley beaz...@users.sourceforge.net:
The strict parameter to JSONDecoder() is undocumented and is confusing
because someone might assume it has something to do with the encoding
parameter or the general handling of parsing errors (which it doesn't).
As far as I can determine by reading the source, strict determines
whether or not JSON strings are allowed to contain literal newlines in
them or not. For example (note: loads() passes its parameters to
JSONDecoder):
s = '{test:Hello\nWorld}'
print(s)
{test:Hello
World}
json.loads(s)
Traceback (most recent call last):
...
File /tmp/lib/python3.0/json/decoder.py, line 159, in JSONString
return scanstring(match.string, match.end(), encoding, strict)
ValueError: Invalid control character at: line 1 column 14 (char 14)
json.loads(s,strict=False)
{'test': 'Hello\nWorld'}
Note in this last example how the result has the literal newline
embedded in it when strict is set False.
--
assignee: georg.brandl
components: Documentation
messages: 78550
nosy: beazley, georg.brandl
severity: normal
status: open
title: json.JSONDecoder() strict argument undocumented and potentially confusing
type: behavior
versions: Python 2.6, Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4785
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk for Mac OS X?
Roumen Petrov bugtr...@roumenpetrov.info added the comment:
Ronald,
In proposed patch we see (insert about line 740):
+ LDLIBRARY='libpython$(VERSION).dylib'
+ BLDLIBRARY='-L. -lpython$(VERSION)'
+ RUNSHARED='DYLD_LIBRARY_PATH=`pwd`:${DYLD_LIBRARY_PATH}'
Let see comment in configure script(about line 585):
# MacOSX framework builds need more magic. LDLIBRARY is the dynamic
# library that we build, but we do not want to link against it (we
# will find it with a -framework option). For this reason there is an
# extra variable BLDLIBRARY against which Python and the extension
# modules are linked, BLDLIBRARY. This is normally the same as
# LDLIBRARY, but empty for MacOSX framework builds.
Next on line about 675 we see:
# MacOSX framework builds need more magic. LDLIBRARY is the dynamic
# library that we build, but we do not want to link against it (we
# will find it with a -framework option). For this reason there is an
# extra variable BLDLIBRARY against which Python and the extension
# modules are linked, BLDLIBRARY. This is normally the same as
# LDLIBRARY, but empty for MacOSX framework builds.
if test $enable_framework
then
LDLIBRARY='$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)'
RUNSHARED=DYLD_FRAMEWORK_PATH=`pwd`:$DYLD_FRAMEWORK_PATH
BLDLIBRARY=''
else
BLDLIBRARY='$(LDLIBRARY)'
fi
So proposed patch is not consistent with comments. Is expected shared
build to ignore framework build ?
About SO - as I understand python build system it is reserved for
module suffix. So there is no reason to change it.
About .dylib - I'm sure that issue can be resolved with appropriate
update without SO to be changed by configure.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4472
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4780] Makefile.pre.in patch to run regen on OSX (framework build)
Benjamin Peterson benja...@python.org added the comment: I probably forgot to add it when I was missing with the Makefile a while back. I applied your patch in r68075. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4783] json documentation needs a BAWM (Big A** Warning Message)
Bob Ippolito b...@redivi.com added the comment: You're the first person to ever raise any of these issues in the slightly more than 3 years that the package has been around (by other names), so I'm not sure such a warning needs to be that big. JSON doesn't really have any framing, so serializing more than one document to or from the same place doesn't work so well. It's not even talked about in the spec, and I've never seen someone try it before. -- priority: - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4783] json documentation needs a BAWM (Big A** Warning Message)
David M. Beazley beaz...@users.sourceforge.net added the comment: Just consider me to be an impartial outside reviewer. Hypothetically, let's say I'm a Python programmer who knows a thing or two about standard library modules (like pickle), but I'm new to JSON so I come looking at the json module documentation. The documentation tells me it uses the same interface as pickle and marshal (even naming those two modules right off the bat). So, right away, I'm thinking the module probably does all of the usual things that pickle and marshal can do. For instance, serializing multiple objects to the same stream. However, it doesn't work this way and the only way to find out that it doesn't work is to either try it and get an error, or to read the source code and figure it out. I'm not reporting this as an end-user of the json module, but as a Python book author who is trying to get things right and to be precise. I think if you're going to keep the pickle and marshal reference I would add the warning message. Otherwise, I wouldn't mention pickle or marshal at all. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4783] json documentation needs a BAWM (Big A** Warning Message)
Bob Ippolito b...@redivi.com added the comment: Ok, I've added some notes to the trunk of simplejson's documentation. Not sure when/if that'll hit the Python trunks, I've been having a hard time getting my other patches to sync up with simplejson through: http://bugs.python.org/issue4136 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4782] json documentation missing load(), loads()
Bob Ippolito b...@redivi.com added the comment: There are some missing colons in the documentation apparently, which causes reStructuredText to ignore the documentation for those two functions. -- nosy: +bob.ippolito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4783] json documentation needs a BAWM (Big A** Warning Message)
David M. Beazley beaz...@users.sourceforge.net added the comment: Thanks! Hopefully I'm not giving you too much work to do :-). Cheers, Dave ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4626] compile() doesn't ignore the source encoding when a string is passed in
Changes by John Machin sjmac...@users.sourceforge.net: -- nosy: +sjmachin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4786] xml.etree.ElementTree module name in Python 3
New submission from David M. Beazley beaz...@users.sourceforge.net: Not a bug, but a question to developers: Is xml.etree.ElementTree going to be the only standard library module in Python 3.0 that doesn't follow the standard Python 3.0 module naming conventions? (e.g., socketserver, configparser, etc.). Are there any plans to rename it to xml.etree.elementtree? Just curious. -- components: Library (Lib) messages: 78560 nosy: beazley severity: normal status: open title: xml.etree.ElementTree module name in Python 3 versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4074] Building a list of tuples has non-linear performance
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4074 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4688] GC optimization: don't track simple tuples and dicts
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4472] Is shared lib building broken on trunk for Mac OS X?
Roumen Petrov bugtr...@roumenpetrov.info added the comment: A --enable-framework and --enable-shared are mutable exclusive. You either have a regular unix build or a Python.framework. May be configure has to block user if both are enabled. Is there any documentation on what the role of the SO variable means. Reading the code (distutils), comments configure script we may get some information. From configure (line about 1600) : AC_DEFINE_UNQUOTED(SHLIB_EXT, $SO, [Define this to be extension of shared libraries (including the dot!).]) Actually this is suffix for python module (as example for windows .pyd or _d.pyd) If SO is changed by to .dylib for OS X in configure above line will define SHLIB_EXT to .dylib in pyconfig.h. Ronald, you patch restore indirectly shared_lib_extension (distutils) to .so, but define SHLIB_EXT from pyconfig.h will be .dylib. This may impact other projects. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4749] Issue with RotatingFileHandler logging handler on Windows
Lowell Alleman lowel...@gmail.com added the comment: I've ran into the same problem before. I've found that due to differences between the way Unix and Windows handles files (inodes vs file handles), this problem is more apparent on Windows, but it isn't handled 100% correctly on Unix systems either. I think the root of the problem is that there is nothing in the code to handle multiple concurrent processes writing to a single log file; and I'm not sure there is a simple fix for this. I tried several easy solutions to this problem by retrying failed file renames and re-opening closed files, but I ultimately discovered all all such approaches are inadequate and can actually result in losing old log files too (in the worse-case scenario). I final got frustrated enough to just take the time to write my own. It is based on the built-in one and aims to be a drop-in replacement. I use file locking to safely write to a single log file from multiple python processes concurrently. If you would like to give it a try, it is located here: http://pypi.python.org/pypi/ConcurrentLogHandler I agree that it would be nice for the built in logging handlers to do this for you, but in the mean time this may be option for you. -- nosy: +lowell87 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4749 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
New submission from Damian atag...@gmail.com: Hi, in switching to Python 3.0 I've run into an issue with displaying Unicode characters via curses. In Python 2.x a simple hello-world looks like: #!/usr/bin/python # coding=UTF-8 import curses import locale locale.setlocale(locale.LC_ALL,) def doStuff(stdscr): message = uhello わたし! stdscr.addstr(0, 0, message.encode(utf-8), curses.A_BLINK) stdscr.getch() # pauses until a key's hit curses.wrapper(doStuff) This works. However, when I try to come up with an equivalent for Python 3.0: #!/usr/bin/python import curses import locale locale.setlocale(locale.LC_ALL,) def doStuff(stdscr): message = hello わたし! stdscr.addstr(0, 0, message, curses.A_BLINK) stdscr.getch() # pauses until a key's hit curses.wrapper(doStuff) It fails (printing gibberish to the console). It seems that the problem is that the curses module isn't respecting the system's preferred encoding (utf-8) which was set via the setlocale function (as per instructions at http://docs.python.org/dev/3.0/library/curses.html#module-curses). My apologies in advance if this is my mistake. Cheers! -Damian -- components: Unicode messages: 78563 nosy: atagar1 severity: normal status: open title: Curses Unicode Support type: behavior versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
STINNER Victor victor.stin...@haypocalc.com added the comment: I tested your example on Linux (Ubuntu Gutsy) and it works correctly. What is your: - OS (name, version) - locale (charset?) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4702] [PATCH] msvc9compiler raises IOError when no compiler found instead of DistutilsError
Tarek Ziadé ziade.ta...@gmail.com added the comment: Fixed, thanks for the patch Philip, -- status: open - closed versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian atag...@gmail.com added the comment: My OS is Ubuntu 8.04 (Hardy) and the locale is utf-8: locale.setlocale(locale.LC_ALL,) 'en_US.UTF-8' You do mean the Python 3.0 example didn't work, right? The Python3.0 header is: Python 3.0 (r30:67503, Dec 21 2008, 02:16:52) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 in case that makes a difference. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian atag...@gmail.com added the comment: Ack - sorry, typo. I meant You do mean the Python 3.0 example did work, right? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
STINNER Victor victor.stin...@haypocalc.com added the comment: You do mean the Python 3.0 example didn't work, right? I only tested yje Python3 example and it works correctly on my computer. I'm using Python3 trunk but I don't think that the curses module changed after the 3.0 release. $ ./python Python 3.1a0 (py3k:67973M, Dec 28 2008, 17:53:52) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 import locale; locale.setlocale(locale.LC_ALL, '') 'fr_FR.UTF-8' ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian atag...@gmail.com added the comment: Doing a checkout of the trunk - I'll let you know if it works. Thanks! ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4786] xml.etree.ElementTree module name in Python 3
Quentin Gallet-Gilles qgal...@gmail.com added the comment: ElementTree is maintained externally, that's why it wasn't renamed during the stdlib reorganization : http://www.python.org/dev/peps/pep-3108/#open-issues -- nosy: +quentin.gallet-gilles ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
STINNER Victor victor.stin...@haypocalc.com added the comment:
I think that I catched the problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379447
_curses.so should be linked to libncursesw.so.5 and not
libncurses.so.5. I tested on Hardy and I doesn't work because
_curses.so was linked to libncurses.so.5.
Few commands...
sudo apt-get install libncursesw5-dev
make clean
make
and it works ;-) Possible workaround: reject non-unicode ncurses
library in setup.py. The ugly patch:
Index: setup.py
===
--- setup.py(révision 67973)
+++ setup.py(copie de travail)
@@ -848,23 +848,6 @@
panel_library = 'panelw'
exts.append( Extension('_curses', ['_cursesmodule.c'],
libraries = curses_libs) )
-elif (self.compiler.find_library_file(lib_dirs, 'ncurses')):
-curses_libs = ['ncurses']
-exts.append( Extension('_curses', ['_cursesmodule.c'],
- libraries = curses_libs) )
-elif (self.compiler.find_library_file(lib_dirs, 'curses')
- and platform != 'darwin'):
-# OSX has an old Berkeley curses, not good enough for
-# the _curses module.
-if
(self.compiler.find_library_file(lib_dirs, 'terminfo')):
-curses_libs = ['curses', 'terminfo']
-elif
(self.compiler.find_library_file(lib_dirs, 'termcap')):
-curses_libs = ['curses', 'termcap']
-else:
-curses_libs = ['curses']
-
-exts.append( Extension('_curses', ['_cursesmodule.c'],
- libraries = curses_libs) )
else:
missing.append('_curses')
Ugly because it may break the curses module compilation on many OS
(BSD and Solaris?).
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4787
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
STINNER Victor victor.stin...@haypocalc.com added the comment: See also the old (and closed) issue #1428494: Prefer linking against ncursesw over ncurses library. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian atag...@gmail.com added the comment: Just finished recompiling and works perfectly. My hat's off to you - many thanks! -Damian ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2552 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
STINNER Victor victor.stin...@haypocalc.com added the comment: ncursesw looks to be available for: - Linux: eg. packaged in Ubunbut - NetBSD: ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/ncursesw/README.html - FreeBSD: ncurses package with USE=unicode - Mac OS X: http://ncursesw.darwinports.com/ - Windows: by Cygwin (libncurses5 package) I think that libncursesw is working well on Linux and BSD, but Windows port may be buggy. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4788] two bare except clauses are used in the ssl module
New submission from Giampaolo Rodola' billiej...@users.sourceforge.net: From PEP-8: When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause. [...] A bare 'except:' clause will catch SystemExit and KeyboardInterrupt exceptions, making it harder to interrupt a program with Control-C, and can disguise other problems. The patch in attachment removes two bare except clauses used in ssl module. -- components: Library (Lib) files: ssl.patch keywords: patch messages: 78575 nosy: giampaolo.rodola severity: normal status: open title: two bare except clauses are used in the ssl module versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12499/ssl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4788] two bare except clauses are used in the ssl module
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net: Added file: http://bugs.python.org/file12500/ssl-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4788] two bare except clauses are used in the ssl module
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net: -- nosy: +janssen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
STINNER Victor victor.stin...@haypocalc.com added the comment: For Solaris, see this bug report of nano editor: https://savannah.gnu.org/bugs/?24028 libcurses has been added to OpenSolaris in Septembre 2008. But it don't see the unicode version (libncusesw) :-/ ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4788] two bare except clauses are used in the ssl module
STINNER Victor victor.stin...@haypocalc.com added the comment: socket.getpeername() can only raises an error of type socket.error, so the patch is valid and needed! -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1664] nntplib is not IPv6-capable
STINNER Victor victor.stin...@haypocalc.com added the comment: I like nntplib_ipv6.patch: it's a generic solution (may support address families other than IPv6) and reuse code (socket.create_connection()) is always a good thing :-) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1664 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1664] nntplib is not IPv6-capable
STINNER Victor victor.stin...@haypocalc.com added the comment: About Python 2.5: this branch doesn't accept bugfix anymore, only security issues. So only Python 2.6+ and 3.0+ can be patched. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1664 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4777] nntplib - python 2.5
STINNER Victor victor.stin...@haypocalc.com added the comment: Python 2.5 branch doesn't accept bugfix anymore, only security issues. See #1664 for python 2.6+ and 3.0+. -- nosy: +haypo resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4770] binascii module, crazy error messages, unexpected behavior
STINNER Victor victor.stin...@haypocalc.com added the comment: See also issue #4769 (want base64.b64decode(str)). -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3023] Problem with invalidly-encoded command-line arguments (Unix)
STINNER Victor victor.stin...@haypocalc.com added the comment: Hmm, yes, I see that the open() builtin doesn't accept bytes filenames, though os.open() still does. What? open() builtin, io.open() and os.open() accept bytes filename. So what *is* os.listdir() supposed to do when it finds an unconvertible filename? Raise an exception? os.listdir(str)-str raises an exception on undecodable filename, whereas os.listdir(bytes)-bytes doesn't write unicode error because the filename is not decoded! What if someone puts unconvertible strings in the password database? Which database? It sounds like a different issue. It's always a good thing to reject undecodable string, even with python2 ;-) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3023 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4789] Documentation changes break existing URIs
New submission from Mark Sapiro m...@msapiro.net: The Mailman GUI contains a few links to the python.org documentation which are now broken. These links and the current equivalents are: http://www.python.org/doc/ works, but could map to http://docs.python.org/ http://www.python.org/doc/current/ works, but could map to http://docs.python.org/ http://www.python.org/doc/current/lib/ - http://docs.python.org/library/ http://www.python.org/doc/current/lib/module-re.htm - http://docs.python.org/library/re.html http://www.python.org/doc/current/lib/re-syntax - http://docs.python.org/library/re.html#regular-expression-syntax http://www.python.org/doc/current/lib/typesseq-strings.html - http://docs.python.org/library/stdtypes.html#string-formatting-operations It would be really cool if these old URIs could redirect to the new ones. -- assignee: georg.brandl components: Documentation messages: 78583 nosy: barry, georg.brandl, msapiro severity: normal status: open title: Documentation changes break existing URIs type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4789 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4790] Optimization to heapq module
New submission from Nilton nil...@google.com: The wrapper around heapq.nlargest and heapq.nsmallest is much slower than it's C version. $ python2.5 -mtimeit -s 'import random; random.seed(123); n=99; x=range(n); random.shuffle(x); import _heapq' '_heapq.nlargest(3, x)' 10 loops, best of 3: 142 msec per loop $ python2.5 -mtimeit -s 'import random; random.seed(123); n=99; x=range(n); random.shuffle(x); import heapq' 'heapq.nlargest(3, x)' 10 loops, best of 3: 685 msec per loop If the key argument is None, there is no need to use the wrapper. This patch adds an a check to avoid this. -- components: Library (Lib) files: heapq_optimization.diff keywords: patch messages: 78584 nosy: nilton severity: normal status: open title: Optimization to heapq module versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12501/heapq_optimization.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4790 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1664] nntplib is not IPv6-capable
Chris Morrow ch...@as701.net added the comment: Are we sure that the 2.6 fix (in the patch) will make it into 2.6? (and the right upstream patching will happen to the 3.0 code as well?) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1664 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3023] Problem with invalidly-encoded command-line arguments (Unix)
Dan Dever ded...@verizon.net added the comment: What if someone puts unconvertible strings in the password database? Which database? It sounds like a different issue. It's yet another special case of the more general issue, which is that Unix strings are strings of bytes that may or may not be encoded text. Bytes of any value (save nul) are permitted in any order. There may be the occasional additional constraint: '/' is not permitted in filenames since it's the path element delimiter, for example. But you can certainly have non-text strings for file names, environment variables, command-line arguments, etc. Since Python 3 strings must be text, they cannot generally be used to represent Unix strings. David's right, this is going to cause real problems. It has to be solved somehow, but the more obvious solutions are in some way ugly and introduce platform-to-platform inconsistencies. I occasionally skim the python-dev mailing list archive, and as far as I can tell there is yet no consensus on how to handle this. My use of Python is chiefly general-purpose scripting on Linux. Parameters to these scripts are more likely to be file names than anything else. So I can't personally consider moving to version 3 until this issue is resolved, which is why I added myself to the nosy list. I'm bothered by Martin's comment: That os.listdir still uses bytes should be changed as well. Both file names and command line arguments are strings, from the viewpoint of Python. Nothing else is supported. I hope that this is nothing more than his expression of dismay that such a situation should exist, and that he doesn't mean it literally. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3023 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4790] Optimization to heapq module
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Am rejecting the patch because it violates the sort equivalence guarantee (including sort's promise to maintain stability). If you need the speed and don't care about sort stability, then just use _heapq.nsmallest() or _heapq.nlargest() directly. We could complexify the code a bit to achieve some automatic speed-up in the case of key==None, but my timings don't show much of an improvement: if key is None: it = izip(iterable, count()) # decorate result = _nsmallest(n, it) return map(itemgetter(0), result)# undecorate else: in1, in2 = tee(iterable) it = izip(imap(key, in1), count(), in2) # decorate result = _nsmallest(n, it) return map(itemgetter(2), result)# undecorate -- assignee: - rhettinger nosy: +rhettinger resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4790 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4787] Curses Unicode Support
Damian atag...@gmail.com added the comment: Looks like this was my mistake, not a bug. According to: http://mail.python.org/pipermail/python-list/2007-July/450133.html Python 2.5 also requires the addition of libcursesw but it was working for the Ubuntu release because they specifically added it. There's no missing functionality - just my mistake. Cheers! -Damian ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4788] two bare except clauses are used in the ssl module
Benjamin Peterson benja...@python.org added the comment: Fixed in r68089 and r68091. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4790] Optimization to heapq module
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: After looking at the ugly handling of this logic in the 3.0 translation, I've reconsidered. It is better to have a separate path for the case where the key is None. See r68095 and r68096 . -- resolution: rejected - accepted ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4790 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4775] Incorrect documentation - UTC time
David Morley mor...@ai.sri.com added the comment: I propose to add this sentence to the explanation of the epoch: It is platform-dependent whether or not 'seconds since the epoch' includes leap seconds. Most systems likely implement `Unix time`_ That solution is fine. Anyone sufficiently concerned about the implications can then work out the consequences for themselves once alerted. Please, one issue at a time. I believe that this doesn't crop up, or if it does, it's a different issue. If you want to pursue this, please create a separate report, and preferably include a proposed wording. This was in response to your request for specific other usage of UTC. The datetime module uses the term UTC very frequently but assumes a fixed 86400 second day (which is incompatible with UTC but compatible with the other Universal Times). I see this as the same issue, that is, when leap-seconds are not used it seems odd to use the more specific term UTC rather than the less specific GMT or UT - UTC is a more precise but in this case less accurate term. ...but I am happy to drop this if you don't consider it a problem. Why do you think UT1 plays any role here? To me, but maybe not to anyone else :-), property (1a) eliminates the usefulness of the numerical representation of time for interpretation (1) of the time routines. Of the non-UTC versions of Universal Time why did I assume UT1 specifically? UT1 is the main Universal Time - the one that UTC attempts to approximate. Computers *have* to use SI seconds, since they are not physically equipped to measure anything else (unless you want to get even more nit-picking and point out that the quartz in the computer is not capable of measuring SI seconds exactly). Well, the different Universal Times *are* nit-picking over defining seconds :-) Without the nit-picking, we would have GMT. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
