Guido has granted me committer privileges to svn.python.org and
bugs.python.org about a week ago. So I'm new and new people tend to make
mistakes until they've learned the specific rules of a project.
Today I've learned that the resolution keyword "accepted" doesn't mean
the bug report is accepted. It only means a patch for the bug is
accepted. In the past I've used "accepted" in the meaning of "bug is
confirmed" in my own projects. In my ignorance I've used it in the same
way to mark bugs as confirmed when I was able to reproduce the bug myself.
The tracker doc at http://wiki.python.org/moin/TrackerDocs/ doesn't have
a formal definition of the various keywords. I like to add a definition
to the wiki to prevent others from making the same mistake. But first I
like to discuss my view of the keywords
accepted - patch accepted
confirmed (*) - the problem is confirmed
duplicate - the bug is a duplicated of another bug
fixed - the bug is fixed / patch is applied
invalid - catch all for invalid reports
later - the problem is going to be addressed later in the release cycle
out of date - the bug was already fixed in svn
postponed - the problem is going to be fixed in the next minor version
rejected - the patch or feature request is rejected
remind - remind me to finish the task (docs, unit tests)
wont fix - it's not a bug, it's a feature
works for me - unable to reproduce the problem
(*) It's missing from the list of resolutions but I like to have it
immediate - the bug must be fixed *NOW* (only used for important
security related problems)
urgent - the problem must be fixed ASAP because it's crucial for future
high - the problem should be fixed soonish and must be fixed for the
normal - the problem should be fixed for the next release
low - nice to have features and fixes
I've come up with a relatively unobtrusive pattern for defining
setters. Given the following definition:
assert isinstance(prop, property)
return property(prop.__get__, func, func, prop.__doc__)
we can declare getters and setters as follows:
_encoding = None
def encoding(self, value=None):
if value is not None:
unicode("0", value) # Test it
self._encoding = value
c = C()
c.encoding = "ascii"
c.encoding = "invalid" # Fails
I'd like to make this a standard built-in, in the hope the debate on
how to declare settable properties.
I'd also like to change property so that the doc string defaults to
the doc string of the getter.
--Guido van Rossum (home page: http://www.python.org/~guido/)
I thought the hell of stripping trailing Ls off of stringed numbers was gone
but it appears that the hex() and oct() builtins still leave the trailing
'L' on longs:
Python 2.6a0 (trunk:58846M, Nov 4 2007, 15:44:12)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 0xffffffffc10025be
>>> '0x%x' % (x)
This appears to be fixed in py3k (as there is no longer an int/long to
distinguish). Can we at least get rid of the annoying L in 2.6?
Issue http://bugs.python.org/issue1663329 details an annoyance in the
subprocess module that has affected several users, including me.
Essentially, closing hundreds of thousands of file descriptors by
round-tripping through the python exception machinery is very slow,
taking hundreds of milliseconds and at times many seconds. The
proposed fix is to write this loop in c. The c function is but a
handful of lines long. I purposefully kept the implementation
trivial so that it will work on all unix variants (there is another
issue that contains a super-duper optimization for AIX, and other
possibilities exist for Solaris, but the simple fix yields a ten-fold
speedup everywhere but windows, so I didn't think that it was worth
Though technically relating only to performance, I consider this a
bug-fix candidate as mysterious multi-second delays when launching a
subprocess end up making the functionality of close_fds unusable on
some platform configurations (namely, those with high MAX_FD set).
It would be great to see this is 2.5.2. Understanding that issue
evaluation takes significant effort, I've done some evaluation/triage
on other open tickets:
See issues for detailed comments.
http://bugs.python.org/issue1516330: No clear problem, invalid
patch. Recommend rejection.
http://bugs.python.org/issue1516327: No clear problem, no patch.
http://bugs.python.org/issue1705170: reproduced. Conjecture as to
why it is occurring, but I don't know the guts well enough to propose
a decent fix.
http://bugs.python.org/issue1773632: tested patch. Recommend
accepting unless there are things I don't know about this mysterious
_xmlrpclib extension (which there doubtlessly are)
http://bugs.python.org/issue738948: Rather old PEP that has gathered
no comments. Calling it a "PEP" is generous--it is really just a
link to an academic paper with a note about how this might be
integrated into Stackless.
I'm following the issue 1311: http://bugs.python.org/issue1311
There (and always talking in windows), the OP says the in Py2.4
os.path.exists("nul") returned True and now in 2.5 returns False. Note
that "nul" is an special file, something like /dev/null.
We made some tests, and we have inconsisten behaviour in previous
Python versions. For example, in Py2.3.5 in my machine I get a False,
as in Py2.5. But other person in the bug, gets True in 2.3.3 and
False in 2.5.
Even the OP has differents result for the same Python 2.4 in different machines.
Right now (but don't know exactly since when), Python relies in
kernel32.dll functions to make the stat on the file (if stat raises an
error, os.path.exists says that the file does not exist). Of course,
if I call to this function separately, I have the same behaviour.
So, the question is what we should do?:
1. Rely on the kernel32 function and behaves like it says?
2. Return a fixed response for this special file "nul"?
Personally, I prefer the first one, but it changed the semantic of
os.path.exists("nul") (but this semantic is not clear, as we get
different behaviour in different Python versions and windows
Thank you very much!