[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.

ysj.ray added the comment: > I would not read [str] as implying a list of strings, FWIW. help() on distutils.extension.Extension gives the parameters description like this: .. sources: [string] .. include_dirs: [string] .. So I guess this style can be used

[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.

ysj.ray added the comment: > FYI, in one packaging doc I added one note instead of changing each cell: > http://docs.python.org/dev/library/packaging.compiler#id6 I like this solution, it seems more concise and to the point. With this the doc need only one change: --- a/Doc/dis

[issue11934] build with --prefix=/dev/null and zlib enabled in Modules/Setup failed

ysj.ray added the comment: Isn’t zlib built by setup.py anyway? If can be build by Modules/Setup first as a builtin module, then the setup.py woun't build it. -- ___ Python tracker <http://bugs.python.org/is

[issue11206] test_readline unconditionally calls clear_history()

ysj.ray added the comment: This seems has already been fixed in issue11496, should be closed. -- nosy: +ysj.ray ___ Python tracker <http://bugs.python.org/issue11

[issue11874] argparse assertion failure with brackets in metavars

Changes by ysj.ray : -- components: +Library (Lib) -None ___ Python tracker <http://bugs.python.org/issue11874> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11874] argparse assertion failure with brackets in metavars

ysj.ray added the comment: Seem as a problem in optparse.HelpFormatter._format_usage(): when the generated usage string is too long(longer than 78, e.g.), python tries to break the usage string into parts at some proper positions and group them to multiple lines, then join the parts with

[issue11934] build with --prefix=/dev/null and zlib enabled in Modules/Setup failed

New submission from ysj.ray : The development guide(http://docs.python.org/devguide/setup.html) suggested that one can build with "--prefix=/dev/null" in order to avoid accidentally install it. But in the Modules/Setup.dist the zlib module is defined as: zlib zlibmodule.c -I$(prefi

[issue11882] test_imaplib failed on x86 ubuntu

ysj.ray added the comment: Guess the problem is with time.mktime() and time.localtime(). Could you debug into the Internaldate2Tuple() function and see at which step the time value(a time_struct or a float which represents seconds) is wrong? -- nosy: +ysj.ray

[issue11908] Weird `slice.stop or sys.maxint`

ysj.ray added the comment: `step` argument for xrange() could not be 0. But `s.stop or sys.maxint` is really a problem, in the case of `s.stop == 0`. So the given `Equivalent to` python code in the doc is not precisely equivalent to the c implementation. The doc needs a fix. -- nosy

[issue9523] Improve dbm modules

ysj.ray added the comment: Sorry, previous patch(issue_9523_4.diff) missed a file(Lib/test/dbm_tests.py) Here is an intact one. -- Added file: http://bugs.python.org/file21769/issue_9523_5.diff ___ Python tracker <http://bugs.python.org/issue9

[issue9523] Improve dbm modules

ysj.ray added the comment: Updated patch following C code review comments from http://bugs.python.org/review/9523/show Two big changes: 1. Add check for each time assign a Py_ssize_t variable to datum.dsize(int), if value not fit, raise a ValueError(following PEP 353) 2. Simplify

[issue11785] email subpackages documentation problems

ysj.ray added the comment: Oh, sorry, I didn't differ :mod:, :module:, :currentmodule: clearly. But shouldn't the modules link titles in http://docs.python.org/dev/library/email.html display correct module names instead just the "email" package name? """

[issue11777] Executor.map does not submit futures until iter.next() is called

ysj.ray added the comment: Got it. Seems the behavior is not consist with the Executor.map() function: "The returned iterator raises a TimeoutError if __next__() is called and the result isn't available after timeout seconds from ***the original ca

[issue11785] email subpackages documentation problems

ysj.ray added the comment: And this causes the toctree in email doc(http://docs.python.org/dev/library/email.html) in correct. All of the tree elements' names are displayed as "email". -- ___ Python tracker <http://bugs.pyt

[issue11785] email subpackages documentation problems

New submission from ysj.ray : All the module name in the first line of email subpackages' documentation files(Doc/library/email.xxx.rst) are incorrect: all of them are "email" but not "email.xxx" Besides, the Doc/library/email-examples.rst is not a module and it

[issue11777] Executor.map does not submit futures until iter.next() is called

ysj.ray added the comment: Isn't this the supposed behavior? -- nosy: +ysj.ray ___ Python tracker <http://bugs.python.org/issue11777> ___ ___ Python-bugs-l

[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative

Changes by ysj.ray : -- nosy: +ysj.ray ___ Python tracker <http://bugs.python.org/issue11605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue11764] inspect.getattr_static code execution w/ class body as non dict

Changes by ysj.ray : -- nosy: +ysj.ray ___ Python tracker <http://bugs.python.org/issue11764> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue11747] unified_diff function product incorrect range information

ysj.ray added the comment: Since if one of the two comparing files is empty, gnu diff regards the beginning line of differences as line 0 (there is not any lines), but difflib regards it as line 1(there is a line, but empty). Not sure weather is correct since the practice usage of diff

[issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if PyRun_InteractiveOneFlags() raises an error

ysj.ray added the comment: > On most cases, setting sys.stdin to some other invalid value does means the > program could not continue running. Sorry, it should be: On most cases, setting sys.stdin to some other invalid value does not mean the program could not continue r

[issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if PyRun_InteractiveOneFlags() raises an error

ysj.ray added the comment: I'd prefer not exit program but try to use Py_FileSystemDefaultEncoding as enc when sys.stdin is invalid. On most cases, setting sys.stdin to some other invalid value does means the program could not continue ru

[issue11740] difflib html diff takes extremely long

ysj.ray added the comment: Reproduced in 3.3 -- components: +Library (Lib) -None nosy: +ysj.ray versions: +Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue11

[issue11739] Python doesn't have a 2011 april fools joke

ysj.ray added the comment: > Perhaps 2012 will be extra special. I'm afraid 2012 April Fool may be the last April Fool of the world. -- ___ Python tracker <http://bugs.python.org

[issue11739] Python doesn't have a 2011 april fools joke

ysj.ray added the comment: +1. I was updating my hg clone all the time yesterday to see if there was anything interesting happened. But I was disappointed. -- nosy: +ysj.ray ___ Python tracker <http://bugs.python.org/issue11

[issue11730] Setting sys.stdin to an invalid input stream causes interpreter run loop forever.

New submission from ysj.ray : Setting sys.stdin to an invalid input stream under interactive mode causes interpreter run loop forever: Python 3.3a0 (default:22ae2b002865+, Mar 30 2011, 21:17:03) [GCC 4.4.4] on linux2 Type "help", "copyright", "credits" or

[issue1257] atexit errors should result in nonzero exit code

ysj.ray added the comment: I think there is no need to implement this in python2.x since it's a behavior change which could introduce some compatibility issues to someone's code, besides in 2.x both sys.exitfunc and atexit module should be considered, that makes the code looks co

[issue11654] errors in atexit hooks don't change process exit code

ysj.ray added the comment: see #1257 -- ___ Python tracker <http://bugs.python.org/issue11654> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11647] function decorated with a context manager can only be invoked once

ysj.ray added the comment: Got it. Here is my updated patch. Not sure if the doc is proper. -- Added file: http://bugs.python.org/file21475/issue_11647_2.diff ___ Python tracker <http://bugs.python.org/issue11

[issue11647] function decorated with a context manager can only be invoked once

ysj.ray added the comment: > For 3.3, the fix could be generalised with ContextDecorator supporting a > documented "self._recreate" internal interface that, by default, just returns > self, but would be overridden in _GeneratorContextManager to actually create > a ne

[issue11647] function decorated with a context manager can only be invoked once

ysj.ray added the comment: Here I worked out a patch to make the function decorated by context manager returned by @contextmanager reusable, by storing original function object and argments(args, kwds objects) in _GeneratorContextManager and construct a generator when needed(in self

[issue11647] function decorated with a context manager can only be invoked once

ysj.ray added the comment: Now I found that I am wrong and I feel OK with make the context manager reusable when used as a decorator. I missed one thing: the reusable behavior is regarded as in the decorated function but not in the decorator context manager