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
Nick Coghlan 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 itself
Nick Coghlan 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 Brian's pat
Changes by Nick Coghlan :
--
title: test_concurrent_futures implicitly installs a logging handler on import
-> Bad interaction between test_logging and test_concurrent_futures
___
Python tracker
<http://bugs.python.org/issu
Nick Coghlan added the comment:
Or various incarnations of functools.partial applied to subprocess.Popen.
--
___
Python tracker
<http://bugs.python.org/issue10
Nick Coghlan 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
<http://bugs.python.org/issue10
Nick Coghlan 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).
--
___
P
Nick Coghlan 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
<http://bugs.py
New submission from Nick Coghlan :
"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 affe
Changes by Nick Coghlan :
--
components: +Build
stage: -> needs patch
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue10677>
___
___
Pyth
New submission from Nick Coghlan :
"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 proper
Nick Coghlan 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 clob
Nick Coghlan 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
<http://bugs.python.o
Nick Coghlan 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 comp
Nick Coghlan 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
<http://bugs.python.org/issue10
Changes by Nick Coghlan :
--
stage: needs patch -> commit review
___
Python tracker
<http://bugs.python.org/issue9232>
___
___
Python-bugs-list mailing list
Un
Nick Coghlan 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__ are minimised
Nick Coghlan 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 to refer to the co
Nick Coghlan 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 the test to e
Nick Coghlan 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
resolution: rej
Changes by Nick Coghlan :
--
resolution: rejected -> duplicate
superseder: -> Allow trailing comma in any function argument list.
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan 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
<http://bugs.python.org/
Nick Coghlan 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
Nick Coghlan 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
of the referenced objects open
New submission from Nick Coghlan :
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 program list
Nick Coghlan 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. The whole point
Nick Coghlan 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&qu
Nick Coghlan 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: -> invalid
sta
Nick Coghlan added the comment:
Agreed. I'll put something on python-dev about that, so MvL sees it.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan 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, but until we&#x
Nick Coghlan 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 (
Nick Coghlan 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 its value can
Nick Coghlan 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
<http://bugs.python.org/is
Nick Coghlan 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 to
Nick Coghlan 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, st
Nick Coghlan 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 he
Nick Coghlan 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 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 ar
Nick Coghlan 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 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
imple
Nick Coghlan 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
then use
Nick Coghlan 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 Antoine
Nick Coghlan 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 tracker
Nick Coghlan 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, but a
Nick Coghlan 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 all the
Nick Coghlan 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
<http://bugs.python.org/issue10
Nick Coghlan 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
<http://bugs.pyth
New submission from Nick Coghlan :
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 = len(x
Nick Coghlan 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 :)
--
versions: +Python
Nick Coghlan 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 i
Nick Coghlan 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.
As it turned out, the end
Nick Coghlan 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 :
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nick Coghlan 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 on
python
Nick Coghlan added the comment:
Yep, go ahead.
--
___
Python tracker
<http://bugs.python.org/issue10902>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Ah, true - I forgot svnmerge for 27-maint was based on the py3k branch.
--
___
Python tracker
<http://bugs.python.org/issue10
Nick Coghlan 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 it again.
Optio
Nick Coghlan 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.
--
resolution
Nick Coghlan 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 to the python
Nick Coghlan 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).
A possibl
701 - 800 of 6501 matches
Mail list logo
