[issue7852] [PATCH] Drop Computer from Apple Computer in plistlib
Wang Chun yaohua2...@gmail.com added the comment: plutil is a command shipped with every Mac. See the example in my original post. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7852] [PATCH] Drop Computer from Apple Computer in plistlib
New submission from Wang Chun yaohua2...@gmail.com:
Apple's official utilities had been dropped the word Computer. We should
follow them.
imac:~$ cat test.py
__import__('plistlib').writePlist({}, 'test.plist')
imac:~$ python test.py
imac:~$ cat test.py
__import__('plistlib').writePlist({}, 'test.plist')
imac:~$ python test.py
imac:~$ cat test.plist
?xml version=1.0 encoding=UTF-8?
!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd;
plist version=1.0
dict
/dict
/plist
imac:~$ plutil -convert xml1 test.plist
imac:~$ cat test.plist
?xml version=1.0 encoding=UTF-8?
!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd;
plist version=1.0
dict/
/plist
imac:~$
--
components: Library (Lib)
files: plistlib.diff
keywords: patch
messages: 98815
nosy: wangchun
severity: normal
status: open
title: [PATCH] Drop Computer from Apple Computer in plistlib
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file16123/plistlib.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7852
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6105] json.dumps doesn't respect OrderedDict's iteration order
New submission from Wang Chun yaohua2...@gmail.com:
PEP-0372 and Issue 5381 both say json.dumps respect OrderedDict's
iteration order, but the example in them do not work on my latest trunk
build.
$ uname -a
Linux 12.38 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64
x86_64 x86_64 GNU/Linux
$ python2.7
Python 2.7a0 (trunk, May 21 2009, 08:00:00)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type help, copyright, credits or license for more information.
import json
from collections import OrderedDict
items = [('one', 1), ('two', 2), ('three', 3), ('four', 4), ('five',
5)]
json.dumps(OrderedDict(items))
'{four: 4, three: 3, five: 5, two: 2, one: 1}'
--
components: Library (Lib)
messages: 88311
nosy: wangchun
severity: normal
status: open
title: json.dumps doesn't respect OrderedDict's iteration order
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6105
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5885] uuid.uuid1() is too slow
New submission from Wang Chun yaohua2...@gmail.com: uuid.uuid1() currently uses two different ways to generate a uuid. If the system call uuid_generate_time is available, uuid1() uses the system call via the ctypes interface, otherwise, it uses pure Python code to generate a uuid. The problem is, the C interface uuid_generate_time is even slower than the Python code. The ctypes interface is too slow. According to my test, it took 55 microseconds to generate a uuid via ctypes interface but only 45 microseconds via the Python code. I also tried to test the performance of the uuid_generate_time C API itself. It takes C code 12 microseconds. Most of the time were wasted on ctypes. I believe we need to drop ctypes and write a Python extensions in C for this job. -- components: Library (Lib) messages: 86840 nosy: wangchun severity: normal status: open title: uuid.uuid1() is too slow type: performance versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5885 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5885] uuid.uuid1() is too slow
Wang Chun yaohua2...@gmail.com added the comment:
This is my test on another faster machine.
$ cat test.py
import sys, time, uuid
N = int(sys.argv[1])
t = time.time()
for x in xrange(N):
uuid.uuid1()
print('%.3f microseconds' % ((time.time() - t) * 100.0 / N))
$ cat test.c
#include stdio.h
#include sys/time.h
#include uuid/uuid.h
int main(int argc, char *argv[])
{
int i, n;
double t1, t2;
uuid_t uuid;
struct timeval t;
struct timezone tz;
sscanf(argv[1], %d, n);
gettimeofday(t, tz);
t1 = (double)t.tv_sec + (double)t.tv_usec / 100.0;
for (i = 0; i n; i++) {
uuid_generate_time(uuid);
}
gettimeofday(t, tz);
t2 = (double)t.tv_sec + (double)t.tv_usec / 100.0;
printf(%.3f microseconds\n, (t2 - t1) * 100.0 / n);
return 0;
}
$ gcc -l uuid -o test test.c
$ python test.py 5
25.944 microseconds
$ python test.py 20
25.810 microseconds
$ python test.py 100
25.865 microseconds
$ ./test 5
0.214 microseconds
$ ./test 20
0.214 microseconds
$ ./test 100
0.212 microseconds
$
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5885
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4650] getopt need re-factor...
New submission from Wang Chun yaohua2...@gmail.com: I created #4629 a couple of days ago. And besides that issue, for Python 3.x, I guess we can remove getopt.error since Python 3.x does not have to backward compatible with Python 2.x. And another issue is, GetoptError does not render right error message with unicode_literals enabled in Python 2.6. -- components: Library (Lib) messages: 77715 nosy: wangchun severity: normal status: open title: getopt need re-factor... versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4651] getopt need re-factor...
New submission from Wang Chun yaohua2...@gmail.com: I created #4629 a couple of days ago. And besides that issue, for Python 3.x, I guess we can remove getopt.error since Python 3.x does not have to backward compatible with Python 2.x. And another issue is, GetoptError does not render right error message with unicode_literals enabled in Python 2.6. -- components: Library (Lib) messages: 77716 nosy: wangchun severity: normal status: open title: getopt need re-factor... versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4629] getopt should not accept no_argument that ends with '='
New submission from Wang Chun [EMAIL PROTECTED]:
Consider the following program tmp.py:
import sys, getopt
print(getopt.getopt(sys.argv[1:], '', ['help']))
The program accept --help without a value:
python helloworld.py --help
But if someone invoke the program like:
python helloworld.py --help=
Python should raise an error.
--help= is not considered as no_argument in libc's getopt implementation
(tested on Mac OS X
Leopard):
#include getopt.h
static struct option longopts[] = {
{ help, no_argument, NULL, h },
};
#include getopt.h
static struct option longopts[] = {
{ help, no_argument, NULL, 'h' },
};
int main(int argc, char **argv)
{
while (getopt_long(argc, argv, h, longopts, NULL) != -1);
return 0;
}
macbook:~/tmp$ gcc -o tmp tmp.c
macbook:~/tmp$ ./tmp --help=
tmp: option `--help' doesn't allow an argument
macbook:~/tmp$
--
components: Library (Lib)
messages: 77597
nosy: wangchun
severity: normal
status: open
title: getopt should not accept no_argument that ends with '='
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2,
Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.5.3, Python 2.6,
Python 2.7, Python 3.0, Python 3.1
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4629
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4629] getopt should not accept no_argument that ends with '='
Changes by Wang Chun [EMAIL PROTECTED]: -- keywords: +patch Added file: http://bugs.python.org/file12325/getopt.py.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2173] Python fails silently on bad locale
Wang Chun [EMAIL PROTECTED] added the comment: This issue remains unsolved in the latest python 3.0rc2+ subversion repository as of 2008-11-13. -- nosy: +wangchun ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1982] Feature: extend strftime to accept milliseconds
Wang Chun [EMAIL PROTECTED] added the comment:
Ruby recently added support of millisecond and nanosecond to strftime.
This is their changeset:
http://redmine.ruby-lang.org/repositories/revision/ruby-19?rev=18731
To use the extended strftime, one can do:
Time.now.strftime('%Y-%m-%dT%H:%M:%S.%L%z')
.. 2008-10-29T17:46:03.895+0800
In the current implementation of Python, both datetime and time modules
have strftime. Like in Ruby, the strftime in datetime module is a
method. But the strftime in time module is a function, which takes time
value to be formatted from argument, and which must be a 9-tuple
returned by gmtime or localtime. No microsecond data in the tuple,
unfortunately.
I think as the first step we can make datetime.datetime.strftime do
microsecond. I prefer microsecond to milli- or micro- second because it
is something from the the system.
The current Ruby implementation use %L or %3N for millisecond, %6N for
microsecond, and %N or %9N for nanosecond. I am not sure where they came
from. Hope there can be some widely accepted standard.
--
nosy: +wangchun
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1982
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4227] unicode_literals and print_function do not work together.
New submission from Wang Chun [EMAIL PROTECTED]: If from __future__ import unicode_literals, print_function, unicode_literals works, but not print_function; If from __future__ import print_function, unicode_literals, print_function works, but not unicode_literals. -- components: Interpreter Core messages: 75314 nosy: wangchun severity: normal status: open title: unicode_literals and print_function do not work together. type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4227 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
