[issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib

2010-02-04 Thread Wang Chun 

New submission from Wang Chun :

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

http://www.apple.com/DTDs/PropertyList-1.0.dtd";>




imac:~$ plutil -convert xml1 test.plist
imac:~$ cat test.plist

http://www.apple.com/DTDs/PropertyList-1.0.dtd";>



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 
<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

2010-02-05 Thread Wang Chun 

Wang Chun  added the comment:

plutil is a command shipped with every Mac. See the example in my original post.

--

___
Python tracker 
<http://bugs.python.org/issue7852>
___
___
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

2008-10-29 Thread Wang Chun 

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.

2008-10-29 Thread Wang Chun 

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

[issue2173] Python fails silently on bad locale

2008-11-12 Thread Wang Chun 

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

[issue4629] getopt should not accept no_argument that ends with '='

2008-12-10 Thread Wang Chun 

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 

static struct option longopts[] = { 
{ "help", no_argument, NULL, "h" },
};

#include 

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 '='

2008-12-10 Thread Wang Chun 

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

[issue4650] getopt need re-factor...

2008-12-12 Thread Wang Chun 

New submission from Wang Chun :

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 
<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...

2008-12-12 Thread Wang Chun 

New submission from Wang Chun :

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 
<http://bugs.python.org/issue4651>
___
___
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

2009-04-30 Thread Wang Chun 

New submission from Wang Chun :

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 
<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

2009-04-30 Thread Wang Chun 

Wang Chun  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 
#include 
#include 

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 
<http://bugs.python.org/issue5885>
___
___
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

2009-05-25 Thread Wang Chun 

New submission from Wang Chun :

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 
<http://bugs.python.org/issue6105>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com