Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file21220/2f5db44c98f2.diff
___
Python tracker
<http://bugs.python.org/issue11477>
___
___
Python-bug
Nick Coghlan added the comment:
I think the roundup/Hg integration may be getting confused by the merges of the
cpython main line of development with my sandbox.
--
___
Python tracker
<http://bugs.python.org/issue11
Nick Coghlan added the comment:
MvL says the review creation script should be able to cope with the rdiff
output within the next day or so.
--
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue8754>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue1559549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11559>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I'd suggest calling Py_FatalError rather than calling abort() directly in
_PyObject_AssertFailed, but otherwise this looks like a nice improvement over
standard C asserts for state invariants that may be broken by buggy C
extensions.
For the tests, t
Changes by Nick Coghlan :
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
nosy: +brett.cannon, ncoghlan
___
Python tracker
<http://bugs.python.org/issue11561>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
We know, I left it there to help MvL debug the issues in the diff generator.
The version I created with the rdiff extension is correct though, and Martin
fixed the Reitveld integration to handle the extra lines at the start of the
diff.
I wouldn't act
Nick Coghlan added the comment:
The review links didn't come up automatically because 336137a359ae isn't a
hg.python.org/cpython revision ID.
--
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
No need, since you manually created a review on appspot. The local Reitveld
links are just a convenience that can avoid the need to manually create a
review instance.
--
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
As Daniel noted, this behaviour is in accordance with the language definition.
It's obscure and surprising behaviour, but it isn't wrong.
--
nosy: +ncoghlan
resolution: -> invalid
stage: test needed -> committed/rejected
status
Nick Coghlan added the comment:
Note that this will be fixed for 3.3, as siteconfig will be updated to use
static data (generated during the build process) rather than relying on build
artifacts being available at runtime.
However, virtualenv (et al) will still need to provide the relevant
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11560>
___
___
Python-bugs-list mai
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11572>
___
___
Python-bugs-list mai
Nick Coghlan added the comment:
Alexander: the coverage problem in this case has to do with it incorrectly
handling an "else:" clause on a loop (it doesn't adjust the expected target for
an empty sequence to be the body of the else clause)
Benjamin: the pragma question is
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11548>
___
___
Python-bugs-list mai
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11577>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
unittest provides a utility to help with testing that correct exceptions are
raised:
http://docs.python.org/dev/library/unittest#unittest.TestCase.assertRaises
--
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
I've been focusing on softer targets during the sprints - I'll dig into this
once I'm back home and using my desktop machine again.
--
___
Python tracker
<http://bugs.pyt
Nick Coghlan added the comment:
The draft code is now only on the "respect_LHS_precedence" branch of my sandbox
repository.
--
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
Well, there and in the named diff file on here, of course.
--
___
Python tracker
<http://bugs.python.org/issue11477>
___
___
Pytho
Nick Coghlan added the comment:
Reopening to double check with Jerome's patch.
--
resolution: fixed ->
stage: committed/rejected -> commit review
status: closed -> open
___
Python tracker
<http://bugs.pyth
Nick Coghlan added the comment:
This is fixed on default as well, I just stuffed the merge so the history looks
odd and the integration script didn't pick it up.
You can see the additional changes I made in the linked changeset:
- try/except with a flag to clean up implicitly created
Nick Coghlan added the comment:
Regarding "__reduce__", other readers will have the same question Éric did, so
that point should definitely go in a comment after the "__reduce_ex__" check.
--
___
Python tracker
<http://bug
Nick Coghlan added the comment:
It's largely a backwards compatibility hack, but the concrete methods also have
an optimised fast path that the generic methods lack.
So (for example), PyList_SetItem would now mean "this is *probably* a list, so
check for that and use the fast p
Nick Coghlan added the comment:
Note that this test code:
def raise_():
raise MyException
self.assertRaises(TypeError, raise_)
can be simplified to:
with self.assertRaises(TypeError):
raise MyException
in all currently maintained branches
Nick Coghlan added the comment:
On Wed, Mar 23, 2011 at 12:04 PM, Antoine Pitrou wrote:
> Clearly there is a problem in the API or its implementation, as in a function
> decorated with a context manager can only be invoked once! This isn't good...
The problem stems from a fundam
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue9523>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
> The former sounds like fixing the bug, the latter like removing
> functionality. So yes, I prefer the former...
The reason I'm reluctant is that it makes for a fundamental change in
behaviour between the use of an @contextmanager definition a
Nick Coghlan added the comment:
Thomas, I know you've been working on this post-Pycon. Could you please take a
look at Daniel's patch and/or publish your own.
--
assignee: -> twouters
nosy: +ncoghlan, twouters
___
Python t
Changes by Nick Coghlan :
Added file: http://bugs.python.org/file21383/8bd713a823b5.diff
___
Python tracker
<http://bugs.python.org/issue11477>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
Martin and I are still experimenting with this issue as a test case for the
remote repository diff calculator, so apologies for the noise as we add and
remove patch files.
--
___
Python tracker
<h
New submission from Nick Coghlan :
Creating an issue to track efforts to forward port the PEP 380 reference
implementation to Python 3.3.
--
hgrepos: 11
messages: 132213
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: PEP 380 reference implementation for 3.3
Nick Coghlan added the comment:
On Sat, Mar 26, 2011 at 9:14 PM, anatoly techtonik wrote:
> A pity that before argparse replaced optparse, there was no research
> made to gather the output from various console tools to see how
> argparse really saves people from reinventing their
New submission from Nick Coghlan :
It would be good to supplement the "here's the list of mailing lists" (etc)
section in the devguide [1] with a more task oriented communications FAQ of the
form "If you are asking about topic A, then ask in forums X, Y or Z".
(wher
Nick Coghlan added the comment:
Even "from __future__ import unicode_literals" doesn't make it do anything.
Perhaps Christian merged it by mistake in [5341b30b1812]?
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.pyt
Nick Coghlan added the comment:
Finally got around to reviewing this (just a visual scan at this stage) -
thanks for the effort. These are mostly "big picture" type comments, so I'm
keeping them here rather than burying them amongst all the details in the code
review tool.
Nick Coghlan added the comment:
I think the biggest thing to take out of my review is that I strongly encourage
deferring the changes for 5(b) and 5(c).
I like the basic idea of using a template-based approach to try to get rid of a
lot of the boilerplate code currently needed for AST
Nick Coghlan added the comment:
OK, I missed the fact that the new optimisation pass isn't run under
PyCF_ONLY_AST.
However, as Eugene picked up, my concern is actually with the collapsing of
Str/Num/Bytes/Ellipsis into the new Lit node, and the changes to the way
None/True/Fals
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-
601 - 700 of 6501 matches
Mail list logo
