Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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 ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com added the comment:
On Sat, Jan 22, 2011 at 3:08 AM, STINNER Victor rep...@bugs.python.org 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
Nick Coghlan ncogh...@gmail.com 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
New submission from Nick Coghlan ncogh...@gmail.com:
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 ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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 you'll
Nick Coghlan ncogh...@gmail.com 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 1
Nick Coghlan ncogh...@gmail.com 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 require a PEP
Nick Coghlan ncogh...@gmail.com 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 rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue10845
Changes by Nick Coghlan ncogh...@gmail.com:
Removed file: http://bugs.python.org/file20601/issue10845_mitigation.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10845
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
imported
Nick Coghlan ncogh...@gmail.com 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__': clause
Nick Coghlan ncogh...@gmail.com added the comment:
Committed for 3.2 in r88247.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10845
New submission from Nick Coghlan ncogh...@gmail.com:
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 ncogh...@gmail.com 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 the now.
It's fascinating to read all
Nick Coghlan ncogh...@gmail.com 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 ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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 rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com 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 ncogh...@gmail.com:
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9931
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
Correct docs links for LogRecord attributes section:
http://docs.python.org/dev/library/logging#logrecord-attributes
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11071
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8998
___
___
Python-bugs-list mailing
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com added the comment:
Helps to add the patch rather than the whole file...
--
Added file: http://bugs.python.org/file20702/issue10971_temp_module_cleanup
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Nick Coghlan ncogh...@gmail.com:
Removed file: http://bugs.python.org/file20701/test_zipimport_support.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10971
Nick Coghlan ncogh...@gmail.com added the comment:
Fixed for 3.2 in r88368 (no backport needed, since the older test suites didn't
exhibit the original problem with the _ssl module reloading)
--
resolution: - fixed
status: open - closed
___
Python
Nick Coghlan ncogh...@gmail.com added the comment:
(Georg reviewed the patch after I mentioned it to him on IRC)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10971
New submission from Nick Coghlan ncogh...@gmail.com:
There are currently undocumented PyEval_Call* equivalents to a number of the
PyObject_Call* functions.
Since there are resources out there on the web that direct people to use the
currently undocumented PyEval functions, it would be good
Nick Coghlan ncogh...@gmail.com added the comment:
Removed the easy tag, since this may involve some python-dev discussion as to
where to put them in C API docs (they don't really fit in any of the current
sections).
Perhaps an advanced APIs section, for things that most C extensions
Nick Coghlan ncogh...@gmail.com added the comment:
It is, but keep issue 10181 in mind (since that may lead to some restructuring
of the memoryview code, potentially leading to a need to update your patch).
--
___
Python tracker rep
Nick Coghlan ncogh...@gmail.com added the comment:
I'm still not comfortable with a convention that relies on *clients* of the PEP
3118 API not mucking with the internals of the Py_buffer struct.
I'm *much* happier with the rule based on malloc/free semantics where the
*pointer* passed
Nick Coghlan ncogh...@gmail.com added the comment:
As far as the question of re-exporting the underlying view or not goes, I agree
having memoryview(a) potentially refer to different underlying memory from
a itself (because the source object has changed since the first view was
exported
Nick Coghlan ncogh...@gmail.com added the comment:
I should note that the idea of using a Py_buffer's internal field as the
unique ID rather than the Py_buffer's address does have some merit, but I still
overall prefer a design that places fewer constraints on API consumers
Nick Coghlan ncogh...@gmail.com added the comment:
On Mon, Feb 14, 2011 at 8:33 AM, Antoine Pitrou rep...@bugs.python.org wrote:
I'm still not comfortable with a convention that relies on *clients*
of the PEP 3118 API not mucking with the internals of the Py_buffer
struct.
Which clients
Nick Coghlan ncogh...@gmail.com added the comment:
Another idea we may want to revisit is the PyManagedBuffer concept, which would
be a true PyObject that existed solely to simplify sharing of Py_buffer structs.
If memoryview used such an object internally, then copying and slicing would
Nick Coghlan ncogh...@gmail.com added the comment:
OK, to summarise that revisit into a coherent proposal:
1. Add PyManagedBuffer as an even lower level wrapper around Py_buffer. The
only thing this would support is doing GetBuffer on construction and
ReleaseBuffer when destroyed (or when
Nick Coghlan ncogh...@gmail.com added the comment:
On further reflection, I realised point 4 in that suggestion isn't reliable in
a formal sense. Consider:
with memoryview(a) as m:
m[:]
The slice won't reference the buffer again, but isn't guaranteed by the
language definition to have
Nick Coghlan ncogh...@gmail.com added the comment:
The managed buffer needs to be a separate object so that multiple memoryview
objects can share it. Essentially, we would end up with two APIs - the raw
Py_buffer API and the higher level PyManagedBuffer one.
C extensions would have the choice
Nick Coghlan ncogh...@gmail.com added the comment:
If it helps, one way to think of it is that post-redesign, the PyManagedBuffer
would be the real API object, with Py_buffer merely a way for data exporters
to provide the information needed to initialise the managed buffer properly
Nick Coghlan ncogh...@gmail.com added the comment:
On Sun, Feb 20, 2011 at 4:22 AM, Éric Araujo rep...@bugs.python.org wrote:
It appears that Misc/NEWS in 3.2 lists the new functions under the 3.1
section, among other strange differences.
new in 3.2 changes are relative to 3.1, while 2.7
Nick Coghlan ncogh...@gmail.com added the comment:
Antoine's patch looks good to me.
Given the assumptions in the memoryview code, disallowing NULL for the buf
pointer sounds like the right thing to do, even for zero-length buffers.
--
___
Python
Nick Coghlan ncogh...@gmail.com added the comment:
A SystemError indicates that an internal API was given bogus input or produces
bogus output (i.e. we screwed up somewhere, or a third party is messing with
interfaces they shouldn't be)
If data validation fails for part of the public C API
Nick Coghlan ncogh...@gmail.com added the comment:
People may use SystemError for other purposes, but the docs are pretty clear it
is only for internal errors that indicate an interpreter bug:
http://docs.python.org/dev/library/exceptions.html#SystemError
Extension modules or an embedding
Nick Coghlan ncogh...@gmail.com added the comment:
I can definitely confirm that one:
~/devel/py3k$ gcc -I/usr/local/include/python3.3m -o issue11321 issue11321.c
-L/usr/local/lib/python3.3 -lpython3.3m -lm -lpthread -ldl -lutil -rdynamic
~/devel/py3k$ ./issue11321
START
Try import #0
Nick Coghlan ncogh...@gmail.com added the comment:
I haven't worked out where the error is happening yet, but the 13 allocated
static variables and the complete lack of a module cleanup function aren't
going to be helping matters.
--
___
Python
Nick Coghlan ncogh...@gmail.com added the comment:
Here's a sample stack trace of it blowing up:
Program received signal SIGSEGV, Segmentation fault.
0x00479404 in type_dealloc (type=0x76a82f20) at
Objects/typeobject.c:2523
2523_PyObject_GC_UNTRACK(type);
(gdb) bt
#0
Nick Coghlan ncogh...@gmail.com added the comment:
I like the idea, and it seems to work as expected (i.e. an empty __slots__
doesn't conflict with inheritance from a C defined type or a type with
non-empty __slots__).
However, __slots__ is one of the sections of the type machinery I'm least
Nick Coghlan ncogh...@gmail.com added the comment:
While Andreas's patch does indeed prevent the crash, there is something more
going on here.
I modified his patch to print out the reference counts immediately after the
new INCREF commands.
With the INCREF commands commented out, it looks
Nick Coghlan ncogh...@gmail.com added the comment:
Merging this into issue11321 since that relates to the same underlying problem
and includes a simpler test case.
--
nosy: +ncoghlan
resolution: - duplicate
status: open - closed
superseder: - 9th import of module _pickle always
New submission from Nick Coghlan ncogh...@gmail.com:
As discussed in issue11321, _pickle allocates a number of module level objects,
but doesn't use the appropriate PEP 3121 mechanisms to manage their lifecycle.
It should be updated to follow the relevant development guidelines
Nick Coghlan ncogh...@gmail.com added the comment:
Looking at the example of _struct.c, I'll withdraw my objection to the patch.
The segfault is due to the attempt to destroy a statically allocated type
object, and the only viable solution to that is to ensure the reference count
never drops
Nick Coghlan ncogh...@gmail.com added the comment:
Given the deprecation of PyEval_ReleaseLock in issue10913, should this be
closed as out of date?
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1720250
Nick Coghlan ncogh...@gmail.com added the comment:
In that case, the request should probably read _pickle should implement the
module finalisation protocol, and module finalisation should be designed so
that doing so isn't a recipe for segfaults.
It strikes me as being very similar
New submission from Nick Coghlan ncogh...@gmail.com:
Catching ImportError in order to switch to an alternate implementation can mask
real failures in imported modules. Attaching the module name as an attribute
would allow this to be handled correctly by doing something like:
try:
import
Nick Coghlan ncogh...@gmail.com added the comment:
We might be able to tapdance our way around the issue by falling back to the
old mechanism when dealing with extension modules without
traverse/clear/dealloc methods.
--
___
Python tracker rep
Changes by Nick Coghlan:
--
assignee: - ncoghlan
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1705170
_
___
Python-bugs-list mailing list
Unsubscribe:
http
Nick Coghlan added the comment:
Fixed for 2.6 in rev 58766. I'm not sure if it will be possible to get
this into 2.5.2.
Leaving open against 2.5 until it is checked in on the maintenance branch.
--
components: +Library (Lib) -None
resolution: - accepted
versions: +Python 2.5
Nick Coghlan added the comment:
Close, but not quite. The problem is that the 'value' argument may be
None if instantiation of the exception hasn't been forced before
__exit__ gets called.
class TestWith(object):
... def __enter__(self):
... pass
... def __exit__(self, exc_type
Nick Coghlan added the comment:
I just hit this as well when rerunning the 2.5 tests before checking
something else in. The test itself appears to be fine, but the call to
f.close() outside the try/except block attempting to flush the file to
disk and raising an IOError.
Didn't something like
Nick Coghlan added the comment:
Done in rev 58901
--
resolution: accepted - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1705170
Nick Coghlan added the comment:
I just compared the 2.5 test_resource with the trunk test_resource - the
latter has been modified to remove the file size limitation before it
attempts to close the file, eliminating the test failure without
changing the underlying behaviour of f.close
Nick Coghlan added the comment:
Attached an updated version of PJE's patch with the suggested cleanups
and a new unit test file (test_cmd_line_script.py). Finding the
roundtuits to finish the latter is actually what has taken me so long.
The basic tests and the directory tests are currently
Nick Coghlan added the comment:
Committed as rev 59039 (now to see how the buildbots react for other
platforms...)
--
resolution: - accepted
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1739468
Nick Coghlan added the comment:
Reverted status to open until I figure out why the tests are failing on
the Mac OSX buildbot.
--
resolution: accepted -
status: closed - open
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1739468
New submission from Nick Coghlan:
Patch to implement PEP 366.
Note that it doesn't implement precisely the semantics described in the
version of the PEP posted in July, as some of those ideas didn't prove
feasible due to the fact that imp.new_module can't tell the difference
between normal
Nick Coghlan added the comment:
I forgot to update the special _run_module_as_main variant when I
modified run_module. I'll modify the patch to fix that and to test '-m'
explicitly in test_cmd_line_script.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Changes by Nick Coghlan:
Removed file: http://bugs.python.org/file8794/pep_366_v1.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1487
__
___
Python-bugs-list mailing list
Nick Coghlan added the comment:
Posted v2 of the patch, which fixes the problem Guido noted, and
improved the tests to make sure __package__ is being set correctly.
There's also now an explicit test for using -m on a module inside a
package (which proved harder to write than I expected
Nick Coghlan added the comment:
Checked in as rev 59288.
--
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1487
__
___
Python-bugs-list mailing
Nick Coghlan added the comment:
PEP 366 has been implemented for 2.6, which fixes this bug. The fix
turned out to be quite invasive (hence the PEP), so it won't be
backported to 2.5.
--
resolution: - fixed
status: open - closed
type: - behavior
Nick Coghlan added the comment:
This has been implemented for 2.6
--
priority: high - normal
resolution: later - fixed
status: open - closed
type: - rfe
versions: +Python 2.6 -Python 2.5
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Nick Coghlan added the comment:
In what sense is this being flagged as easy? All the runpy code knows at
this point is that it asked the import system for the __main__ module's
code object and didn't get one. __main__ always exists, so the module is
definitely able to be found - working out
Nick Coghlan added the comment:
I removed the easy tag. I'll try to come up with some ideas for making
the error message more helpful without making it misleading.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1877
Nick Coghlan added the comment:
Very nice solution Amaury. As far as I can tell, this should be
backported to 2.5 as well.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1750076
Nick Coghlan added the comment:
I don't have any objection in principle, but I would like to see the
updated rules based on the 2.6 and 3.0 Grammar files (they should only
be minor variants of what you have already done for 2.5)
__
Tracker [EMAIL PROTECTED]
http
Changes by Nick Coghlan:
--
assignee: - ncoghlan
nosy: +ncoghlan
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2021
__
___
Python-bugs-list mailing list
Unsubscribe
Nick Coghlan added the comment:
Perhaps the best we can do is a warning from the DictMixin constructor
in 2.6 when the -3 flag is specified?
--
nosy: +ncoghlan
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2012
Nick Coghlan added the comment:
I thought WINVER defaulted to something like 0x0400 (i.e. you can't use
things specifically defined for even Win2k without setting it, let alone
things first defined for XP).
I know I had to force it to 0x0500 recently for a non-Python project to
get access
Nick Coghlan added the comment:
I've changed the issue type from rfe to behaviour. NamedTemporaryFile
actually provides __enter__ and __exit__ methods in 2.5, they just don't
work (it tries to use the methods from the underlying file object
directly which turns out to be a doomed exercise
Changes by Nick Coghlan:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1706
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python
Nick Coghlan added the comment:
I just checked the current PC/pyconfig.h: with the current settings in
that file, the core is already limited to using NT4 compatible Win32 API
calls. Unless the specific source file takes steps to override it (i.e.
setting WINVER before including python.h
Nick Coghlan added the comment:
Given that whether or not Py_BUILD_CORE is defined flips the direction
of the DLL exports/import for the main python DLL, I don't see how it
could be defined for the separately compiled extension modules like
_tkinter, _sqlite3, _ctypes, _socket, _ssl, etc
Nick Coghlan added the comment:
Backported to 2.5 in r60728
P.S. To elaborate a bit more on why converting NamedTemporaryFile to
subclass file would be a much bigger deal than it is to just fix its
__enter__ and __exit__ methods:
- converts from old-style to new-style class
- imposes
Nick Coghlan added the comment:
The wrapper approach has the virtue of providing easy access to the
underlying file object and its methods. That actually gets a bit more
difficult when you switch to a subclassing approach (you need to either
explicitly qualify the methods or play around
Nick Coghlan added the comment:
Thanks for adding the class methods back Mark.
On the constructor front, we got a fair payoff in the early Decimal days
just by reordering the type checks in the constructor. Other than that,
I'd have to dig into the code a bit more to offer any useful
Nick Coghlan added the comment:
I mentioned my dislike of the classmethod-staticmethod change on the
python-checkins list, but given the lack of response there, I figure I
should bring it up here. It is well established that the way to
implement an alternate constructor in Python is to write
Nick Coghlan added the comment:
The test suite is run via test/regrtest.py. If you aren't on windows,
'make test' works as well.
For myself, I tend to just run ./python -m test.regrtest in the
directory where I built Python.
--
nosy: +ncoghlan
Nick Coghlan added the comment:
We don't want to restore Python 2.5 behaviour - directories containing a
__main__.py file are meant to be executable in 2.6. With your proposed
change test_cmd_line_script will fail its directory execution tests
(since those rely on the default importer to find
Nick Coghlan added the comment:
I've checked in friendlier error messages as r60955
Examples (paths somewhat redacted):
$ ./python bob
./python: can't open file 'bob': [Errno 2] No such file or directory
$ ./python .
/devel/python/python: can't find '__main__.py' in '.'
$ ./python Lib
/devel
Nick Coghlan added the comment:
Interesting - I'll try to find the time to take a look at this. (I also
added PJE to the nosy list - hopefully he will get a chance to look at it)
--
nosy: +ncoghlan, pje
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Nick Coghlan added the comment:
The mutation of sys.path is deliberate - the use case is to allow the
interpreter to execute a zipfile directly and have access to all of the
Python modules and packages bundled along with __main__.py. Supporting
execution of directories as well makes it much
Nick Coghlan added the comment:
Updated issue title to reflect what was actually implemented
--
title: Add a -z interpreter flag to execute a zip file - Allow interpreter to
execute a zip file
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Changes by Nick Coghlan:
Removed file: http://bugs.python.org/file8767/runmain_with_tests.diff
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1739468
_
___
Python-bugs
101 - 200 of 6264 matches
Mail list logo
