Nick Coghlan added the comment:
Fixed committed to SVN as r57461
--
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1764407
Nick Coghlan added the comment:
Fixed for 2.6 in rev 58103
(Is the head still being merged to the py3k branch? Or does this need to
be forward-ported manually?)
--
nosy: +ncoghlan
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED
Nick Coghlan added the comment:
I like PJE's approach, and the patch works for me.
About the only thing I'd change is to switch the expression in
PyImport_GetImporter to a simple chain of if-statements in order to:
- silence the warning from GCC about an unused value
- make it more obvious
Changes by Nick Coghlan ncogh...@gmail.com:
--
versions: +Python 3.2 -Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9732
___
___
Python
Nick Coghlan ncogh...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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 rep
Nick Coghlan ncogh...@gmail.com 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
New submission from Nick Coghlan ncogh...@gmail.com:
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
Nick Coghlan ncogh...@gmail.com 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 ncogh...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue10586
Changes by Nick Coghlan ncogh...@gmail.com:
--
stage: - committed/rejected
status: open - closed
type: - feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10586
Nick Coghlan ncogh...@gmail.com added the comment:
Switched to strings in r86879.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10220
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com added the comment:
Added the missing CSS file in r86971. Hopefully that will make the buildbots a
little happier.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2001
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue2001
Nick Coghlan ncogh...@gmail.com added the comment:
On Sat, Dec 4, 2010 at 2:26 AM, Daniel Stutzbach rep...@bugs.python.org wrote:
Daniel Stutzbach stutzb...@google.com added the comment:
(I also noticed that the new methods from issue #9213 are not mentioned
in the range() docs
Wasn't
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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: closed - open
Nick Coghlan ncogh...@gmail.com 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 or
via
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com added the comment:
The general idea is sound. My work colleagues have certainly had to implement
their own reader/writer thread equivalents to keep subprocess from blocking.
It makes sense to provide more robust public support for such techniques in
process
Nick Coghlan ncogh...@gmail.com added the comment:
Actually, I take it back. The default state of logging appears to do the right
thing with no special handler installed - both the .critical() and .exception()
messages are written out to stderr by default, so the futures tests pass even
after
Changes by Nick Coghlan ncogh...@gmail.com:
--
title: test_concurrent_futures implicitly installs a logging handler on import
- Bad interaction between test_logging and test_concurrent_futures
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
Or various incarnations of functools.partial applied to subprocess.Popen.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10482
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, I think that comment was just a mistaken impression on my part.
Definitely something odd going on with the test interaction though.
--
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
The other major change for ranges is that in and not in are no longer
inefficient for actual instances of int (it does an arithmetic calculation
instead of a linear search).
--
___
Python tracker
Nick Coghlan ncogh...@gmail.com added the comment:
No, I believe it was added as part of the .index() and .count() implementation.
Checking the source, there's definitely no sq_contains implementation in 3.1 or
2.7.
--
___
Python tracker rep
New submission from Nick Coghlan ncogh...@gmail.com:
make altinstall is currently installing python3.2m rather than python3.2.
Since PEP 3149 makes no mention of changing the executable name, this should be
fixed to correctly install the executable as python3.2.
I suspect this will also
Changes by Nick Coghlan ncogh...@gmail.com:
--
components: +Build
stage: - needs patch
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10677
New submission from Nick Coghlan ncogh...@gmail.com:
make altinstall installs 2to3, pydoc3 and idle3 without version
specific names.
This was at least a deliberate decision in the case of 2to3, but there doesn't
appear to be any reason not to use a properly qualified version suffix
Nick Coghlan ncogh...@gmail.com added the comment:
Softened the wording, since OS packages will often omit installing any
executable files other than the main python binary.
--
title: make altinstall will clobber OS provided scripts - make altinstall
may clobber OS provided scripts
Nick Coghlan ncogh...@gmail.com added the comment:
The other thing that makes this clearly an error is, of course, the fact that
all the shebang lines expect the executable to be called python3.2
--
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
I have a slightly better fix for that coming soon. There's a subtle race
condition in the proposed approach that can lead to the temporary dir not being
deleted if an asynchronous exception, such as KeyboardInterrupt, arrives after
mkdtemp
Nick Coghlan ncogh...@gmail.com added the comment:
Although it may be better to just raise a new, more meaningul, exception and
let the runtime take care of ignoring it (since it happens in __del__)
--
___
Python tracker rep...@bugs.python.org
http
Changes by Nick Coghlan ncogh...@gmail.com:
--
stage: needs patch - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9232
Nick Coghlan ncogh...@gmail.com added the comment:
Tidy ups committed in r87182. Shutdown problems now result in a slightly more
meaningful message on stderr, a ResourceWarning is triggered when an implicit
teardown occurs and the chances of an AttributeError due to an exception in
__init__
Nick Coghlan ncogh...@gmail.com added the comment:
Sorry, I realised after I had logged off and gone to bed that I hadn't finished
the last test. Fixed in r87204 with an approach that should exercise the
relevant behaviour regardless of platform.
The commit message has also been updated
Nick Coghlan ncogh...@gmail.com added the comment:
Ah, yes, I failed to account for the additional string escaping performed by
the IO stream. I think I've been bitten by that before, but I always forget
since I try to always use forward slashes for paths, even on Windows.
r87212 modifies
Nick Coghlan ncogh...@gmail.com added the comment:
An open issue more accurately reflects the lack of consensus than a closed one,
though. We just won't commit it until there *is* consensus that it is a better
option than the status quo.
--
keywords: +after moratorium -patch
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: rejected - duplicate
superseder: - Allow trailing comma in any function argument list.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10682
Nick Coghlan ncogh...@gmail.com added the comment:
From 10682: the grammar is also inconsistent as to when trailing commas are
allowed in function calls, not just definitions.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
The PEP is quite clear that the object providing the buffer owns those fields.
Last time I checked, the memoryview implementation appeared broken because it
didn't respect that ownership (and created the potential for confusion on the
topic
Nick Coghlan ncogh...@gmail.com added the comment:
Indeed, getsizeof() on containers only gives the amount of memory consumed by
the container itself (this can be difficult to figure out externally for
potentially sparse containers like dicts), but leaves the question of the size
New submission from Nick Coghlan ncogh...@gmail.com:
This issue is to propose specific wording to Martin for inclusion of version
details in the Windows shortcuts. This is to make the shortcuts easier to use
when the hierarchical menu information is lost for any reason (e.g frequently
used
Nick Coghlan ncogh...@gmail.com added the comment:
No, the context must always be included unless explicitly suppressed. The
interpreter can't reliably tell the difference between a raise statement in the
current exception handler and one buried somewhere inside a nested function
call
Nick Coghlan ncogh...@gmail.com added the comment:
For can't tell in my previous message, read we aren't going to impose the
requirement to be able to tell if an exception is being raised directly in the
current exception handler as a feature of conforming Python implementations.
We probably
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, I think I wrote this issue based on the diff that added the new note at
the top, rather than looking at the existing intro text that already references
unittest and doctest.
No need to change anything after all.
--
resolution
Nick Coghlan ncogh...@gmail.com added the comment:
Agreed. I'll put something on python-dev about that, so MvL sees it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10181
Nick Coghlan ncogh...@gmail.com added the comment:
More direct - added MvL to nosy list.
Martin, we would like to exclude Py_buffer from the stable ABI for Python 3.2,
until we have a chance to thrash out the missing pieces of the documentation
for 3.3. I *think* it is a documentation problem
Nick Coghlan ncogh...@gmail.com added the comment:
Closing as a dupe of 10181, but transferring Lenard's comments over there.
--
resolution: - duplicate
status: open - closed
superseder: - Problems with Py_buffer management in memoryobject.c (and
elsewhere
Nick Coghlan ncogh...@gmail.com added the comment:
From Lenard Lindstrom in issue 10001 (closed as dupe of this issue):
The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a
wrapper, includes the field in gc traversal. Also, if the field is not
initialized by bf_getbuffer
Nick Coghlan ncogh...@gmail.com added the comment:
Added Travis to nosy list - even if he doesn't have time to finish this off
himself, hopefully he can point us in the right direction.
--
nosy: +teoliphant
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
PEP 3118 makes it clear that the underlying object should see *two* pairs of
calls to the buffer methods:
http://www.python.org/dev/peps/pep-3118/#the-py-buffer-struct
Even if we ignore the undocumented obj field, the target object needs
Nick Coghlan ncogh...@gmail.com added the comment:
It's OK if the Py_buffer is on the stack - it's just a unique identifier for
the exporter to use as a key, not something the exporter controls the lifecycle
of (the latter is true only for the pointers *inside* the struct, such as buf,
shape
Nick Coghlan ncogh...@gmail.com added the comment:
Martin's patch for the PEP 384 adjustments looks good to me.
A note in the PEP that we've deliberately excluded this on a temporary basis
due to the implementation/documentation mismatch and expect to have it back in
for 3.3 might be helpful
Nick Coghlan ncogh...@gmail.com added the comment:
@Antoine: I actually had a closer look at the way dup_buffer is used, and I
think it is currently legitimate (including for the anonymous memory case). It
just isn't documented very well. For the FromBuffer case, it assumes the
calling code
Nick Coghlan ncogh...@gmail.com added the comment:
I'm curious as to the results you get running python -m test.__main__ and
python Lib/test/__main__.py as well. I suspect both will fail.
Looking at the forking.py code, I think multiprocessing makes some assumptions
that are flat out invalid
Nick Coghlan ncogh...@gmail.com added the comment:
It only needs to be unique for the lifetime of the buffer reference - for a
Py_buffer struct on the stack, by the time the relevant C stack frame goes
away, ReleaseBuffer should already have been called
Nick Coghlan ncogh...@gmail.com added the comment:
As per the discussion over in issue #10181, I've changed my position on this
issue.
Since the PEP isn't explicit on the exact semantics here, I think we should be
guided by the memoryview behaviour and make it official that bf_releasebuffer
Nick Coghlan ncogh...@gmail.com added the comment:
The alternative (if we declare that clients should treat Py_buffer contents as
completely read-only) is to update memoryview to include a separate orig_view
field that would never be touched. The GetBuffer and ReleaseBuffer calls would
Nick Coghlan ncogh...@gmail.com added the comment:
Ah, sorry - no, I misunderstood the question. I think that example actually
*is* a bug in the memoryview implementation. The GetBuffer call should use the
persistent address (mview-view) that will be used in the ReleaseBuffer call,
as per
Nick Coghlan ncogh...@gmail.com added the comment:
I'd like to leave the door open to some tweaks in the GCM implementation for
3.3, so making it officially private (by adding the leading underscore) sounds
good to me.
--
keywords: +easy
___
Python
Nick Coghlan ncogh...@gmail.com added the comment:
If I recall correctly, st_nblocks and st_future are there for consistency with
the corresponding compiler structures.
I believe st_future is also needed whenever a future flag affects the symtable
construction (there aren't any at the moment
Nick Coghlan ncogh...@gmail.com added the comment:
Even more special: put a test_doctest in first and the attempt to clean up
sys.modules in test_zipimport_support leaves things alone so the _ssl module
doesn't break (test_doctest just leaves sys.modules alone and doesn't even try
to remove
Nick Coghlan ncogh...@gmail.com added the comment:
Fixed for 3.2 in r87925. (I simply dropped the attempt to restore sys.modules
to its original state from test_zipimport_support)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
2.7 and 3.1 don't appear to exhibit the fault, so closing this one.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
New submission from Nick Coghlan ncogh...@gmail.com:
Enhancement to range to correctly handle indexing and slicing when len(x)
raises OverflowError.
Note that this enables correct calculation of the length of such ranges via:
def _range_len(x):
try:
length
Nick Coghlan ncogh...@gmail.com added the comment:
Having started work on this, the code changes are probably too significant to
consider adding it to 3.2 at this late stage.
Writing my own slice interpretation support which avoids the ssize_t limit is
an interesting exercise
Nick Coghlan ncogh...@gmail.com added the comment:
Attached patch moves range indexing and slicing over to PyLong and updates the
tests accordingly.
Georg, I think this really makes the large range story far more usable - if
you're OK with it, I would like to check it in this week so it lands
Nick Coghlan ncogh...@gmail.com added the comment:
Oh, and to explain my negative comment from earlier: that was my reaction when
I realised I also needed to write PyLong versions of _PyEval_SliceIndex and
PySlice_GetIndicesEx to make range slicing with large integers work properly
Nick Coghlan ncogh...@gmail.com added the comment:
Committed as r87948.
I added a few large_range tests to those in the patch. I checked that
IndexError is raised when appropriate, as well as a specific test for the
combination of a large range with a large negative step
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: - accepted
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10889
Nick Coghlan ncogh...@gmail.com added the comment:
A quick Google search suggests that code is there to make Insure++ happy, so +1
for Eli's simple fix. Georg hasn't closed the py3k branch yet, so go ahead and
commit it.
(3.2c1 is due this Saturday, so it's worth keeping a close eye
Nick Coghlan ncogh...@gmail.com added the comment:
Yep, go ahead.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10902
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
Ah, true - I forgot svnmerge for 27-maint was based on the py3k branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10902
Nick Coghlan ncogh...@gmail.com added the comment:
As Martin says, we aren't inclined to implement or maintain the equivalent of
depends.exe in order to provide a slightly better error message.
If anyone wants to reopen this issue, provide a patch. Otherwise devs are just
going to close
Nick Coghlan ncogh...@gmail.com added the comment:
Sorry, I missed that the request had changed to just the .pyd name. That at
least is useful, since you then know where to start with depends.exe. It should
be fairly straightforward to implement as well.
Adjusted issue title accordingly
Nick Coghlan ncogh...@gmail.com added the comment:
For the record, the gory details as to *why* RichCompareBool makes more
assumptions as to the meaning of equality than the basic RichCompare function
can be found in issue 4296 (I just found that issue myself by looking at Mark's
response
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, to prevent perfectly reasonable why questions, it is probably worth
providing a little extra justification as an addendum to your new note (which
is already an improvement on the complete silence on the topic that existed
before
Nick Coghlan ncogh...@gmail.com added the comment:
A TLS based approach would presumably allow an embedding application like
mod_wsgi to tinker with the state of threads created by naive modules that are
unaware of the existence of subinterpreters.
That said, I don't see anything
Nick Coghlan ncogh...@gmail.com added the comment:
Indeed. I was actually wondering if it would be worth trying to write up a
section for the language reference to describe the cases where a Python
implementation is *expected* to assume reflexive equality. We (IMO) have a
problem
Nick Coghlan ncogh...@gmail.com added the comment:
There's no point improving the multiple interpreter support if it doesn't help
applications that are currently broken because of that lack of support.
I believe the patch as currently proposed actually makes things *worse*. With
autoTLSkey
Nick Coghlan ncogh...@gmail.com added the comment:
Added Mark Hammond to the nosy list, as the original author and implementor of
PEP 311 (which added the GILState APIs).
Mark, since your PEP deliberately punted on multiple interpreter support, feel
free to take yourself off the list again
Nick Coghlan ncogh...@gmail.com added the comment:
Graham - the cases you describe are the things I was saying don't currently
work in my post and wouldn't be helped by Antoine's patch. Your thoughts on how
we could possibly make it work actually parallel mine (although there may be
fun
Nick Coghlan ncogh...@gmail.com added the comment:
I like the idea of adding these tests as well.
Probably worth bringing up on python-dev - folks like Tarek should definitely
be able to help with alternative ways of building a test application for this.
There is also always the possibility
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, 7902 was a bug that tried to do an absolute import if an explicit
relative import failed to find anything (i.e. it had inherited the old implicit
relative import fallback, which was entirely inappropriate for the new use
case).
Since
Nick Coghlan ncogh...@gmail.com added the comment:
Good point - consider that comment revised to refer to the GIL acquisition
counter in the thread state struct. It may just be a matter of having
ThreadState_Swap complain loudly if the gilstate_counter isn't set to a value
it knows how
Nick Coghlan ncogh...@gmail.com added the comment:
Victor, could you please create a Reitveld review for this? The auto-review
creator can't cope with the Git diffs.
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
OK - I'll wait until that is ready before digging into this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3080
Nick Coghlan ncogh...@gmail.com added the comment:
After applying the patch, doing a make clean and rebuild, I found that
test_importlib fails with a segmentation fault, but the default test suite
otherwise runs without error (that's on Linux with a UTF-8 filesystem, though).
I'll see how
1 - 100 of 6264 matches
Mail list logo
