Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
True, this could be documented better - flagging as a docs bug. (It is
mentioned at the bottom of
http://docs.python.org/library/functools.html#partial-objects, but that could
be referenced better from the main documentation of the function higher up in
the
Nick Coghlan added the comment:
Part of the problem is that there was a specific reason we didn't go with lazy
initialisation of the internal generator: lazy initialisation means there can
be an arbitrary delay between creation of the context manager and the creation
of the under
Nick Coghlan added the comment:
Eugene: I suggest raising the question on python-dev. The answer potentially
affects the PEP 380 patch as well (which adds a new attribute to the "Yield"
node).
Anatoly: If you just want to get a feel for the kind of AST various pieces of
code pro
New submission from Nick Coghlan :
http://docs.python.org/py3k/urllib errors out rather than returning an index
page for the modules that are part of the urllib package.
This index page could also link to the HOWTO at
http://docs.python.org/py3k/howto/urllib2.html
The following packages have
Nick Coghlan added the comment:
Because I don't want to conflate the two APIs. ContextDecorator can be used
with *any* context manager, and some of those may already be using their copy
semantics for something else.
If anyone ever writes the __with__ PEP, then ContextDecorator._recreat
Nick Coghlan added the comment:
If support for a top level temporary directory is added, test.support should
acquire alternatives to the tempfile module tools to make it easy for tests
that create their own temporary files to respect that naming scheme. In
particular
Nick Coghlan added the comment:
To control where mkdtemp() puts files, you could just use the "dir" argument
(and you can use tempfile.gettempdir() beforehand if you want that location to
be inside the normal temp directory)
--
___
Pyth
Nick Coghlan added the comment:
Note that this appears to have been fixed already in the 3.x series (I haven't
investigated the differences to see what makes this a 2.x only problem)
--
versions: +Python 2.7
___
Python tracker
Nick Coghlan added the comment:
2.5: -1
2.6: -0
3.1: +0
As I see it, a large part of the "security fixes only" rule is for the benefit
of folks auditing those security fixes, as it means there's very little noise
in the branch to confuse the matter.
--
Nick Coghlan added the comment:
That link goes to a 404 error page for me.
--
___
Python tracker
<http://bugs.python.org/issue11710>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
Oh, I see the confusion - yeah, the missing "library" in the URL in my first
post was just a typo. It was actually present in my test URLs (otherwise the 4
packages with landing pages wouldn't have worked).
The problem in 2.7 is smaller, since
Nick Coghlan added the comment:
I'll throw in my 2 cents as to a possible way forward:
- fix test.support.unlink in all current maintenance branches (2.7, 3.1, 3.2,
default)
- expose the feature to users as "shutil.rmfile" for 3.3
--
___
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11707>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I may have found another use case for this functionality. Currently, the Python
code in heapq.py accepts arbitrary sequences (that are sufficiently compatible
with the Sequence ABC), but the C code in _heapq only permits use of a concrete
list.
The two
Nick Coghlan added the comment:
I added a few commments on Daniel's draft patch. However, I'm getting nervous
about the performance impact of all these extra pointer comparisons.
We should probably hold off on this until more of the macro benchmark suite
runs on Py3k so we can get
Nick Coghlan added the comment:
"should" is a wonderful word when it comes to external APIs.
We currently have a couple of problems:
1. The concrete APIs will fail noisily if given an instance of something that
isn't a list, but may fail *silently* if given a subclass that
Nick Coghlan added the comment:
1. It's an external API. We *don't control* most of the potentially broken
code, so saying "just fix the call sites" effectively solves nothing and leaves
classes like OrderedDict at risk of subtle silent corruption whenever they are
pas
Nick Coghlan added the comment:
Having convinced myself that Raymond's original suggestion can't be implemented
safely, I have an alternative (arguably even more radical) proposal:
Deprecate the public concrete API functions that modify object state.
Put an underscore in front o
Nick Coghlan added the comment:
Changing the affected components. Antoine and Benjamin are right, this needs to
be handled as a documentation and education problem.
Raymond's suggestion can too easily trigger infinite recursion and mine would
block legitimate use cases in 3rd party
Nick Coghlan added the comment:
I thought about a warning, but the problem is that a subclass using the
concrete API as part of its *implementation* of the associated slot or method
is actually perfectly correct usage.
I'm not sure this is enough to give up on the idea of OrderedDict be
New submission from Nick Coghlan :
Vinay did some great work on the logging documentation for 3.2
(http://docs.python.org/py3k/library/logging).
However, a lot of people will currently miss it, since they land on the
existing 2.7 documentation (http://docs.python.org/library/logging) instead
New submission from Nick Coghlan :
Based on a core-mentoring thread, a couple more points for:
http://docs.python.org/devguide/committing.html#handling-other-s-code
Attribution:
- add to Misc/ACKS if they aren't already there (and didn't add themselves in
their patch)
- mention &quo
Nick Coghlan added the comment:
As a first guess, I would suspect that this is just badly fragmenting the heap
and we aren't freeing up any arenas to pass back to the OS.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
+1 for clarifying the comments. Adding comments for the apparently unused
fields (as per my last tracker comment) would be good, too.
--
___
Python tracker
<http://bugs.python.org/issue9
Nick Coghlan added the comment:
I really like the idea of adding some lower level infrastructure to dis to make
it generator based, making the disassembly more amenable to programmatic
manipulation.
Consider if, for each line disassemble() currently prints, we had an underlying
iterator
Nick Coghlan added the comment:
Changed issue title to cover ideas like get_opinfo().
--
title: Add functions to return disassembly as string -> Refactor the dis module
to provide better building blocks for bytecode analysis
___
Python trac
Nick Coghlan added the comment:
Oops, I forgot to edit my comment to match the OpInfo definition I used in the
proof-of-concept:
OpInfo = collections.namedtuple("OpInfo",
"opindex opcode opname oparg details starts_line
Nick Coghlan added the comment:
If we decide our long term goal is the use of the opcode stream for
programmatic access, then yes.
--
___
Python tracker
<http://bugs.python.org/issue11
Nick Coghlan added the comment:
Good point about the extra parameter just pushing the problem one layer up the
stack rather than completely solving the problem.
However, on further reflection, I've realised that I really don't like having
runpy import the threading module aut
Nick Coghlan added the comment:
Yep, the leading underscore and the fact you added it to a block of code that
is skipped when Py_LIMITED_API is defined makes it OK to include the prototype
in object.h.
However, I would suggest _PyType_CalculateMetaclass as the name -
CalculateWinner is a
Nick Coghlan added the comment:
Removed 2.7 from the affected versions - with neither __build_class__ nor
__prepare__ in 2.x, there's no alternate metaclass calculation to go wrong.
This should definitely be fixed for the final 3.1 release and for 3.2 though.
An updated patch against cu
Nick Coghlan added the comment:
Sorry, my last review wasn't right and the patch is incorrect as it stands.
After digging a little deeper, there is still a case that isn't covered
correctly in __build_class__.
Specifically, the case where the most derived class has a declared meta
Nick Coghlan added the comment:
This last point sounds like an error in PEP 3115 rather than an error
in the implementation - as the exception says, the metaclass of a
derived class must be the same as or a subclass of the metaclasses of
all of its bases. Since that rule applies recursively
Nick Coghlan added the comment:
I think PEP 3115 is OK - the error about all metaclasses inheriting from type
was a mistake on my part (I thought the ability to create non-type metaclasses
went away along with old-style classes, but I was simply wrong on that point).
That got me curious as
Nick Coghlan added the comment:
As near as I can tell, the only visible behavioural change with Daniel's patch
(updated as per my last comment) will be that the two error cases noted above
(i.e. when an explicit metaclass or the first parent type's metaclass is not
the most derived
Nick Coghlan added the comment:
Commenting on the latest patch here, since the Rietveld integration isn't
coping with the "hg extdiff" output (I would guess that the revision numbers in
the pathnames are confusing the script that attempts to determine the base
revision).
Asid
Nick Coghlan added the comment:
That's not correct - we've merely pointed out that it isn't as easy as most
people seem to think.
For the POSIX world, there is a version management scheme based on symlinks in
/usr/bin (or /usr/local/bin) and it is easy to add and
Nick Coghlan added the comment:
Reopening this issue since #9228 was closed as a duplicate of this one. Given
the significant level of user demand for this behaviour, it should NOT be
closed again until a PEP has been written and either accepted or rejected. If
such a PEP is not written and
Nick Coghlan added the comment:
If it is being requested every few months, then we should reconsider rejecting
it. I have now reopened #3561 instead of this one.
--
___
Python tracker
<http://bugs.python.org/issue9
Nick Coghlan added the comment:
Now, another factor to consider is that Windows 7 makes manipulating the system
PATH even more difficult to do correctly (e.g. see
http://www.symantec.com/connect/forums/wise-7-win-7-problems-updating-environment-variable-current-user).
I believe ActiveState
Nick Coghlan added the comment:
Sounds good. I still have that embedded pickle module issue to deal with, and
this should let me actually add a test for it along with the fix.
--
___
Python tracker
<http://bugs.python.org/issue10
Nick Coghlan added the comment:
Reopening, as a 2.7 backport of this would be a nice thing to have.
--
assignee: rhettinger ->
status: closed -> open
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan added the comment:
It's because it isn't a true Mercurial clone-and-update - it's a patch queue,
which the review generation code doesn't know how to interpret.
--
___
Python tracker
<http://bug
Nick Coghlan added the comment:
It's not just hiding the real error, it's also saying something that isn't
true. If you remove the deliberate error from the generator definition, it is
clear that generators are perfectly acceptable as *arg inputs:
>>> def g(): yie
New submission from Nick Coghlan :
The question of the way Python handles NaN came up again on python-dev
recently. The current semantics have been assessed as a reasonable compromise,
but a poorly explained and inconsistently implemented one.
Based on a suggestion from Terry Reedy [1] I
Nick Coghlan added the comment:
Actually, based on the NumPy precedent [1], array.array should be fine as is.
Since it uses raw C floats and doubles internally, rather than Python objects,
there is no clear concept of "object identity" to use to enforce reflexivity.
Nick Coghlan added the comment:
The status quo works. Proposals to change it on theoretical grounds have a
significantly higher bar to meet than proposals to simply document it clearly.
--
___
Python tracker
<http://bugs.python.org/issue11
Nick Coghlan added the comment:
By "works" I merely meant that you can currently achieve both of the following:
1. Write fully conformant implementations of IEEE754 floating point types,
including the non-reflexive NaN comparisons (keeping in mind that, as a
value-based specificat
Nick Coghlan added the comment:
After further discussion on python-dev, it is clear that this identity checking
behaviour handles more than just NaNs - it also allows containers to cope more
gracefully with objects like NumPy arrays that make use of rich comparisons to
return something other
Nick Coghlan added the comment:
Scratch the first half of that last comment - Guido pointed out that false
positives rear their ugly head almost immediately if you try to store rich
comparison objects in other containers.
--
___
Python tracker
Nick Coghlan added the comment:
Rather than fiddling with the warnings filters, wouldn't it be easier to just
catch BytesWarning and return False in that case?
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/is
New submission from Nick Coghlan :
http://nedbatchelder.com/code/coverage/subprocess.html describes how to
instruct a test suite that spawns subprocesses to correctly report coverage
data for code covered only in those subprocesses.
regrtest currently doesn't do this, so modules tha
Nick Coghlan added the comment:
I'm OK with that - I'd actually suggest explicitly *emitting* a warning when
the error is suppressed under -bb, as Ezio is right that even tests should be
keeping their bytes/str separation straight. I don't like completely
suppressing warning
Nick Coghlan added the comment:
A quick eyeball of the test doesn't reveal anything obvious:
- if the subprocess is failing, it is doing so in such a way that it is still
returning a 0 error code and isn't writing anything to stdout (as those
assertions are before the check that th
Nick Coghlan added the comment:
Hmm, I probably should have revised the first half of my comment after I had
the thought about "simple regex" + "random directory name" being potentially
problematic. I don't think that theory really
Changes by Nick Coghlan :
--
nosy: -ncoghlan
___
Python tracker
<http://bugs.python.org/issue10775>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
assignee: docs@python -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue11690>
___
___
Python-bugs-list mailing list
Un
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue11647>
___
___
Python-
Nick Coghlan added the comment:
The core bug has been fixed for 3.2.1 and forward ported to 3.3.
I credited the patch to "Ysj Ray" in ACKS and NEWS, let me know if you'd prefer
a different attribution.
Leaving the issue open for now, since _recreate_cm() should be renamed and
Nick Coghlan added the comment:
Python should still work reliably even if the temp directory is on a
case-insensitive filesystem. Since that isn't an easy thing to determine, -1 on
restoring the uppercase characters to the filenames.
As for it not being fixed previously, it's a rar
Nick Coghlan added the comment:
The number of characters in the filename is hardcoded in the guts of tempfile
(in _RandomNameSequence.__next__ to be exact). Increasing that to 7 (or even 8)
would be a straightforward change at the library level, but it can't be done
from user
Nick Coghlan added the comment:
Basically, adding the uppercase letters back in would provide no gain in
entropy on a case-insensitive filesystem (as the upper and lower case letters
will collide). Increasing the length of the random sequence would provide a
consistent gain regardless of
Nick Coghlan added the comment:
Minor clarification: after my first comment, I realised that the original
change in the character set didn't actually fix anything, it just propagated
the effectively smaller sample space on case-insensitive filesystems to all
filesystems. Increasin
Nick Coghlan added the comment:
Oh, you mean the security risk if the temporary names can be guessed? My
recollection is that it is more of a problem for temporary directories than it
is for temporary files, since the module can't control how files inside a temp
directory get created.
Nick Coghlan added the comment:
The challenge with C functions is that this becomes *additional* metadata that
somehow needs to be provided to the method and function creation process. None
of our APIs are set up to accept that information (and obviously no code is set
up to provide it
Nick Coghlan added the comment:
It still works fine for me (as do test_imp, test_import and test_importlib).
Did you provide any arguments to ./configure, or provide any interesting
options to regrtest to get it to fail?
--
___
Python tracker
Nick Coghlan added the comment:
Oh, that's the other question - is there any chance you are passing -B or have
PYTHONDONTWRITEBYTECODE set? (I'm not sure that would affect make_legacy_pyc,
but all the errors you posted relate to unexpectedly absent pyc files and
d
Nick Coghlan added the comment:
Several of these could be handled just by having test.support.make_legacy_pyc()
fall back to compiling from source if sys.dont_write_bytecode is set.
The others may need to be skipped in that situation
Nick Coghlan added the comment:
If I was looking for opportunities for a compiler to do something weird, I'd
start with the TestEndianness macro (i.e. maybe it is incorrectly flagging the
Cell as little endian when it is actually big endian)
The endianness handling itself looks fine
Nick Coghlan added the comment:
Indeed, any time you shadow a standard library module you run the risk of
breaking things. runpy (and its dependencies) are just like any other module in
that respect.
--
resolution: -> invalid
stage: needs patch -> committed/rejected
status
Nick Coghlan added the comment:
Gah, I accidentally generated a diff that included some unrelated changes to
urrlib (and its tests) for a different issue I had been working on, and Ron's
subsequent patch picked them up. I then misinterpreted "left them alone" to
mean "di
Nick Coghlan added the comment:
No. Once you start shadowing standard library modules, all bets are off as to
what will and won't work. It's one of the reasons we need to be somewhat
careful with the naming of new standard library modules.
I'm mildly curious as to why 2.7 di
Changes by Nick Coghlan :
--
versions: +Python 3.2 -Python 2.5
___
Python tracker
<http://bugs.python.org/issue9732>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
The idea is bring the API up a level, and also take care of wrapping the
file-like object around the source string/byte sequence.
--
___
Python tracker
<http://bugs.python.org/issue9
Nick Coghlan added the comment:
I'll actually go with version 1 of the patch as far as the variable
initialisation goes. Yes, it is fractionally slower, but you get a maintenance
gain from the fact that the enum values are guaranteed to be orthogonal, and
this is clearly obvious t
Nick Coghlan added the comment:
Committed in r86633.
I added the missing docs changes, and tweaked the tests a little bit:
- added a helper method to retrieve the generator state in the test case
- this allowed test_running to be simplified a bit
- added an explicit test for the CREATED
Nick Coghlan added the comment:
Temporarily reopening to remind me to switch from using integer constants to
strings (which are much friendlier for debugging purposes).
--
status: closed -> open
___
Python tracker
<http://bugs.pyth
Nick Coghlan added the comment:
Regarding question 1 (_start_server docstring):
I have no problem with docstrings on private functions in general. It just
means they're for the benefit of developers of the module itself rather than
users of the module. However, in this case, I would mov
New submission from Nick Coghlan :
As per private email to Raymond, I would like to move the lru_cache access
attributes and methods into a CacheInfo class, exposed as a "cache" attribute
with several methods and read-only properties.
Read-only properties: hits, misses, maxsize
Meth
Nick Coghlan added the comment:
Raymond suggested a simple cache_info() method that returns a named tuple as a
possible alternative.
I like that idea, as it makes displaying debugging information (the intended
use case for these attributes) absolutely trivial:
>>> import
Nick Coghlan added the comment:
Committed in r86878.
I put a XXX note in the relevant part of the 3.2 What's New rather than
updating it directly.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Nick Coghlan :
--
stage: -> committed/rejected
status: open -> closed
type: -> feature request
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
Switched to strings in r86879.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10220>
___
___
Python-
Nick Coghlan added the comment:
New patch which addresses my last two comments (i.e. some basic explicit tests
of the encode/decode methods on result objects, and urldefrag returns a named
tuple like urlsplit and urlparse already did).
A natural consequence of this patch is that mixed
Nick Coghlan added the comment:
Committed in r86889
The docs changes should soon be live at:
http://docs.python.org/dev/library/urllib.parse.html
If anyone would like to suggest changes to the wording of the docs for post
beta1, or finds additional corner cases that the new bytes handling
Nick Coghlan added the comment:
Nice!
You may still need to use the lock even for the simple unbounded case though -
incrementing hits and misses isn't atomic, so the statistics may be miscounted
if you get a hit or miss in different threads at the same time.
Alternatively, we could
Nick Coghlan added the comment:
Fixed for 3.2 in r86928.
The fix has not been backported to 3.1, since it depends on the fix for issue
7242 (r78527) which was itself never backported to 3.1 after being forward
ported to the py3k branch as part of a bulk merge (r83318)
Backporting to 2.7
Nick Coghlan added the comment:
Committed in r86962.
Thanks to all involved in getting this from initial submission to final checkin
:)
Any further changes (including addressing Éric's last few comments) can be
undertaken as separate issues.
--
resolution: -> accepted
stag
Nick Coghlan added the comment:
Oh, I also fixed in issue in both the old and new server code that switched
warnings off globally rather than merely for the operation it was trying to
disable warnings for.
--
___
Python tracker
<h
Nick Coghlan added the comment:
I brought the patch up to date for the Py3k branch, but realised just before
checking it in that it may run afoul of the language moratorium (since it
alters the behaviour of builtin range objects).
However, the .count() and .index() methods (along with the
Nick Coghlan added the comment:
Added the missing CSS file in r86971. Hopefully that will make the buildbots a
little happier.
--
___
Python tracker
<http://bugs.python.org/issue2
Nick Coghlan added the comment:
r86975 should fix the problem with Windows paths.
I also found an issue where many of the emitted HTML pages contained two HTML
header sections. The tests were just written in a way that they only looked at
the second of these header sections, while my browser
Nick Coghlan added the comment:
Oh, that would be Éric's point 4 that I fixed. OK, no need to create a new
issue for that one then :)
--
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan added the comment:
On Sat, Dec 4, 2010 at 2:26 AM, Daniel Stutzbach wrote:
>
> Daniel Stutzbach added the comment:
>
>> (I also noticed that the new methods from issue #9213 are not mentioned
>> in the range() docs
>
> Wasn't that fixed in Issue9
Nick Coghlan added the comment:
Daniel Stutzbach pointed out that range() is also mentioned under:
http://docs.python.org/dev/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range
The descriptions of range's limitations there is no longer accurate (slicing is
supp
Nick Coghlan added the comment:
(Oops, didn't mean to reclose this yet)
I want to wait for Georg's verdict on including the functionality in 3.2 before
stressing too much about correct documentation of it :)
--
assignee: -> georg.brandl
status: c
Nick Coghlan added the comment:
To get back to my original objection, it shouldn't be that difficult to
differentiate between "__context__ never set" and "__context__ explicitly
suppressed".
(e.g. using a property that sets an internal flag when set from Python code
Nick Coghlan added the comment:
This is unrelated to issue 10517 (based on Dave Malcolm's initial
investigation, that looks like it may be a genuine problem in multiprocessing)
Instead, this relates to a problem in concurrent.futures where it installs a
logging *handler* as a side effe
Nick Coghlan added the comment:
For 3.2, writing such errors directly to stderr would be fine (we already do
that in other places via PyErr_WriteUnraisable)
The test could then be modified to use test.support.captured_output to
temporarily replace stderr and look at the output.
The problem
601 - 700 of 6301 matches
Mail list logo
