ysj.ray ysj@gmail.com 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
ysj.ray ysj@gmail.com 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
ysj.ray ysj@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org
ysj.ray ysj@gmail.com 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
Changes by ysj.ray ysj@gmail.com:
--
components: +Library (Lib) -None
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11874
___
___
Python-bugs
ysj.ray ysj@gmail.com added the comment:
This seems has already been fixed in issue11496, should be closed.
--
nosy: +ysj.ray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11206
New submission from ysj.ray ysj@gmail.com:
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
ysj.ray ysj@gmail.com 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 rep
ysj.ray ysj@gmail.com 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
ysj.ray ysj@gmail.com 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
ysj.ray ysj@gmail.com 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?
email: Representing
ysj.ray ysj@gmail.com 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 call to
map
New submission from ysj.ray ysj@gmail.com:
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 uses
:mod:`email
ysj.ray ysj@gmail.com 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 rep...@bugs.python.org
ysj.ray ysj@gmail.com 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
Changes by ysj.ray ysj@gmail.com:
--
nosy: +ysj.ray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11764
___
___
Python-bugs-list mailing list
Changes by ysj.ray ysj@gmail.com:
--
nosy: +ysj.ray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11605
___
___
Python-bugs-list mailing list
ysj.ray ysj@gmail.com added the comment:
Isn't this the supposed behavior?
--
nosy: +ysj.ray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11777
ysj.ray ysj@gmail.com 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 running
ysj.ray ysj@gmail.com 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
ysj.ray ysj@gmail.com 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 rep...@bugs.python.org
http
ysj.ray ysj@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue11739
ysj.ray ysj@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue11740
New submission from ysj.ray ysj@gmail.com:
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 license for more
ysj.ray ysj@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org
ysj.ray ysj@gmail.com added the comment:
see #1257
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11654
___
___
Python-bugs-list mailing
ysj.ray ysj@gmail.com 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
ysj.ray ysj@gmail.com 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
ysj.ray ysj@gmail.com 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 new instance
ysj.ray ysj@gmail.com 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
30 matches
Mail list logo
