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
Nick Coghlan 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 that prevents us from pur
Nick Coghlan 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 at the moment due to
Nick Coghlan 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
"autoTLSk
Nick Coghlan 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. If you spot any
Nick Coghlan 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 and ga
Nick Coghlan 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 of writing it in
Nick Coghlan 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 the significant
Nick Coghlan 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 to h
Nick Coghlan 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
<http://bugs.python.org/i
Nick Coghlan added the comment:
OK - I'll wait until that is ready before digging into this.
--
___
Python tracker
<http://bugs.python.org/issue3080>
___
___
Nick Coghlan 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 a -uall
Nick Coghlan added the comment:
As for the more limited run, I get a clean run with -uall except for the
segfault in test_importlib.
I'll switch to a pydebug build and see how a verbose run of that test fares.
--
___
Python tracker
Nick Coghlan added the comment:
I haven't investigated in detail yet, but this is the final line showing the
failing test:
test_module (importlib.test.builtin.test_loader.LoaderTests) ... Segmentation
fault
--
___
Python tracker
Nick Coghlan added the comment:
Oops, missed that post - that was indeed the problem. With that fixed, tests
are all good on this system. I'll give the patch a look anyway, but I'm going
to have trouble diagnosing things that don't fail on my development machine.
As far as t
Nick Coghlan added the comment:
On Sat, Jan 22, 2011 at 3:08 AM, STINNER Victor wrote:
> I should maybe add some unit tests for non-ASCII module paths and non-ASCII
> module names :-)
Indeed. There are a few tests in test_runpy that could be adapted to
that task fairly easily (it creat
Nick Coghlan added the comment:
For flip, const and identity I agree there are already better ways to handle
them using either itertools or comprehension syntax.
The problem I have with trampoline is that it depends on the function's *return
values* being defined in a certain way
New submission from Nick Coghlan :
The test.support docs are there to help CPython devs with writing good unit
tests more easily. There are a few additions we've made in recent years that
haven't made it into the .rst file, so it is easy to miss useful tools if you
don't go
Nick Coghlan added the comment:
How the conversion from a recursive algorithm to an iterative one works depends
on the specific algorithm involved. A trampoline does the job for tail calls,
but not necessarily any other recursive algorithm.
Factorial actually has a fairly trivial iterative
Nick Coghlan added the comment:
As I recall, STDTESTS is there to check we have a basically functioning
interpreter (i.e. the compiler works, etc). The idea is that if any of those
fail, everything else is likely to go belly up as well. If regrtest is being
used to run some other set of
Nick Coghlan added the comment:
Object instances don't get a __dict__ by default to save the space the pointer
and dict instance would require. Most builtins are missing that pointer. It is
also the main memory saving provided by the use of __slots__.
As far as AttributeError vs Type
Nick Coghlan added the comment:
Along the lines of RDM's last post, see:
http://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named/
Or, if you do a few web searches for terms like "bethard coghlan namespaces" or
"bethard generic objects
Nick Coghlan added the comment:
verbose isn't a boolean at all - it's an integer. You can supply it multiple
times to bump the logging level up even higher than normal.
~/devel/py3k/Lib/test$ grep "verbose >" *.py
regrtest.py:if self.verbose >
Nick Coghlan added the comment:
There isn't really much "-m test" can do to flag this - multiprocessing is
making assumptions about the meaning of __file__ that may be flat out invalid
when -m is used to execute the main module.
Fixing that properly is going to requi
Nick Coghlan added the comment:
test_warnings actually includes sanity checks for import_fresh_module - they
could be adapted into a separate unit test easily enough.
--
___
Python tracker
<http://bugs.python.org/issue11
Nick Coghlan added the comment:
"Useless" is a rather strong word. Every change we've made to the import system
(or, more accurately, the main module identification system) has been backed up
with decent use cases - nearly all of the subsequent problems can be traced
back to
Nick Coghlan added the comment:
(Replaced patch file to fix a typo in a comment)
--
Added file: http://bugs.python.org/file20603/issue10845_mitigation.diff
___
Python tracker
<http://bugs.python.org/issue10
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file20601/issue10845_mitigation.diff
___
Python tracker
<http://bugs.python.org/issue10845>
___
___
Pytho
Nick Coghlan added the comment:
Georg, it would be very good to have this fix in for RC2. Otherwise any use of
multiprocessing in conjunction with zipfile, package or directory execution
will fail on Windows in 3.2.
--
assignee: -> georg.brandl
priority: critical -> release b
Nick Coghlan added the comment:
__main__.py files aren't like ordinary modules - they should *not* be defining
classes or anything like that. Instead, they should be treated as if the entire
file was implicitly inside an "if __name__ == '__main__':" clause - when
Nick Coghlan added the comment:
To answer Antoine's question directly:
With the patch, it works just as well as multiprocessing on Windows currently
does if the objects marshalled between parent and
child refer to classes defined inside a "if __name__ == '__main__':&
Nick Coghlan added the comment:
Committed for 3.2 in r88247.
--
___
Python tracker
<http://bugs.python.org/issue10845>
___
___
Python-bugs-list mailing list
Unsub
New submission from Nick Coghlan :
Reviewing the What's New docs, this seemed like the easiest way to give Raymond
a list of things I noticed:
- first sentence in the "ast" module section needs rewording (currently
includes fragments from a couple of different phrasings)
Nick Coghlan added the comment:
A couple more in the Build and CAPI section:
- "The is a new function" should be "There is a new function"
- "The PyUnicode_CompareWithASCIIString() now" either needs to drop the "The"
or add "function" before
Nick Coghlan added the comment:
Another significant logging change: the addition of the "style" parameter for
Formatter objects (allowing the use of str.format and string.Template style
substitution instead of percent formatting)
--
Nick Coghlan added the comment:
The last two logging changes potentially worth mentioning that I noticed:
- simple callables can now be supplied as logging filters (see the version 3.2
note in http://docs.python.org/dev/library/logging#filter-objects)
- the logging API docs now include a
Nick Coghlan added the comment:
I was wrong, I found one more potentially notable logging change:
http://docs.python.org/dev/library/logging#logging.setLogRecordFactory
--
___
Python tracker
<http://bugs.python.org/issue11
Nick Coghlan added the comment:
Adding Vinay, given the number of logging changes in 3.2 that don't appear to
be in the What's New yet (the only logging change noted there at the moment is
the inclusion of PEP 391)
--
nosy: +vinay.sajip
Changes by Nick Coghlan :
--
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issue9931>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
Correct docs links for LogRecord attributes section:
http://docs.python.org/dev/library/logging#logrecord-attributes
--
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue8998>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
My fix for the issues with reloading of the _ssl module meant that a couple of
temporary modules weren't getting cleared out of sys.modules properly, thus
confusing the second and later runs of affected tests.
Attached patch adds explicit removal calls fo
701 - 800 of 6301 matches
Mail list logo
