Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2592>
__
___
Python-b
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Marking as easy - it should be possible to just look at what the code in
Objects\weakref.c is already doing for slots like tp_len and tp_int and
do the same thing for tp_index.
--
keywords:
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Georg Brandl applied Santiago's patch in rev. 54329, 54330
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bu
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
As of 2.5.1, a missing trailing newline no longer causes a Syntax Error,
making the second part of the caveat in the documentation unnecessary.
Changing to a documentation bug applicable to 2.5+.
--
assignee: -> geo
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I think the lowered priority got lost somewhere along the line.
--
priority: normal -> low
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyth
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Using relative imports within smtplib wouldn't have made any difference
in this case. Your dummy email package was the first one encountered on
sys.path, so the "import email.smtplib" line (which does an "import
emai
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
This is actually a pretty tough problem - fixing it would involve some
fairly subtle changes to the way imports from packages are handled.
Given that I'm of the opinion that permitting circular imports in a code
base is an extraord
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I should be able to review/commit this for the next alpha (looking into
it right now).
--
assignee: -> ncoghlan
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Test file added in rev 62351 (forgot to svn add it the first time around)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Commited as rev 62350
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Yeah, it's actually still blowing up for me to. I have no idea what I
actually tested when I thought it was working in 2.6/3.0 - I must have
managed to sneak an extra carriage return into the test string. So
reverting back to mark
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Given that range() produced a list in the 2.x series (hence limited to
available memory), and xrange() uses int internally for its values (and
hence couldn't even cope with short ranges with values greater than
sys.maxint).
So my pr
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
It also isn't what range() and xrange() are used for now in 2.x. range()
returns an actual list, hence is limited to sequences that fit in a
reasonable amount of memory, and xrange() doesn't support values greater
than sys.maxi
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
What does this offer over using NamedTemporaryFile(delete=False)?
--
nosy: +ncoghlan
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The delete flag on NamedTemporaryFile is new for 2.6, so it isn't
surprising people aren't familiar with it. The other advantage of using
NamedTemporaryFile is that its name attribute is set correctly, which
isn't the ca
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Updated in rev 62593.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
(I changed the issue title to better reflect where the discussion has
moved to)
I really like the approach of a custom internal type for the mantissa
storage (the module containing would probably best be called _decimal).
Then it sho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The ability to execute packages was never intended, since doing so
breaks imports in a variety of subtle ways. It was actually a bug in 2.5
that it was permitted at all, so 2.6 not only disabled it again, but
also added a test to make s
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Added revised version of patch with test cases and documentation
updates, as well as fixing a potential recursion issue with pathological
packages where __main__ was also a package)
--
keywords: +patch
Added file:
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
I personally wonder if we should be moving towards a more systematic
means of identifying the underlying Python VM than the current fairly ad
hoc use of sys.platform.
By that I mean adding another sys attribute (e.g. sys.vm) which co
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Interesting, I hadn't noticed that addition to the platform module for 2.6.
A bit more verbose than sys.vm, but it would certainly do the trick :)
In that case, I would suggest something along the lines of the fol
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
My idea above won't really support Armin's idea of being able to exclude
certain known-broken implementations. The check function would need to
be handled differently to support that use case:
# In te
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
FWIW, I agree with the idea of fixing it for 3.0 and leaving it in for 2.x.
--
nosy: +ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
nosy: +ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2029>
___
___
Python
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Christian, is this still a problem for you after the release or can we
close it?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
So what could be different between my x86 system and your x86_64 system
that it works for me and not for you?
Could you try doing "python -i -m site" and poke around in the main
namespace (which is where the interactive sessi
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
That does remind me of another problem though - __main__.__file__ isn't
currently set correctly when runpy picks up the module to run from
inside a zipfile (zipimporter doesn't support runpy/pkgutil's
non-standard get_fi
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
The memory layout of PyType object's changes in Py3k from the
*compiler's* point of view. This means PyObject_HEAD_INIT can no longer
be used to initialise PyVarObject type definitions.
However, the documentation doesn'
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Missed the window for 2.6/3.0. Guido agreed on python-dev that it counts
as a new feature, so it was definitely out for the already-released 2.6,
and also wasn't really an option for the release candidate phase of 3.0.
Assigning to
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Morphing the issue to refer to the __main__.__file__ problem I mentioned
in my previous comment.
--
assignee: -> ncoghlan
title: python2.6 -m site doesn't run site._script() any more ->
__main__.__file__ not set
New submission from Nick Coghlan <[EMAIL PROTECTED]>:
The interactive interpreter doesn't appear to like it if __cause__ and
__context__ are both set on the current exception.
=
>>> try:
... raise IOError
... except:
... raise AttributeError from KeyErr
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Such a bizarre corner case probably isn't an actual release blocker, but
I'm setting it as such so that Barry can make that call explicitly
before the final 3.0 release.
--
assignee: -> barry
nosy: +barry
priority:
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Note that the display is correct in the case where the chaining is
"right", i.e.:
try:
raise IOError
except:
try:
raise KeyError
except Exception as ex:
raise AttributeError from ex
In that case, IOError is corr
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Looks to me like the display code is getting confused by the lack of a
non-None __context__ on the KeyError.
Perhaps the "raise ex from cause" syntax should be setting the
__context__ on the "cause" exception if it i
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
runpy needs a non-standard PEP 302 extension to set __file__ correctly
in the modules it runs. The pkgutil stuff it uses to find pure Python
modules in the filesystem supports that extension, but zipimport doesn&
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Just to confirm - this is specific to __main__.py right?
The problem is actually with runpy not being able to set __file__
correctly, rather than being pdb specific.
___
Python tracker <[EMAIL
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Issues with the tracker itself go in the meta tracker (see the "Report
Tracker Problem" link at the bottom of the left hand navigation menu).
It's a separate tracker in order to handle cases where the main tracker
is actu
Changes by Nick Coghlan <[EMAIL PROTECTED]>:
--
assignee: -> ncoghlan
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4512>
___
___
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Copy & paste from python-dev post:
The problem with memoryview appears to be related to the way it
calculates its own length (since that is the check that is failing when
the view blows up):
>>> a = array('i', ra
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The patch still gets the length of memory view objects wrong - it just
makes it *consistently* wrong so that the specific assignment being
tested appears to work.
Note the following behaviour with the current memoryview :
>>
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
The reason memoryview's current len() implementation is wrong is because
its indexing is per element in the original object, not per byte:
>>> a = array('i', range(10))
>>> m = memoryview(a)
>>>
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Regarding ndim > 0 and shape=NULL, the PEP doesn't allow it. Any code
that does it is already broken - we're just making it fail cleanly at
the point where it is broken rather than in some obscure fas
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
It's quite possible that I misread the array.array implementation since
I only glanced at the code where it fills in the Py_buffer details - I
saw the point where it set shape to NULL, but there may have been code
later on to
Nick Coghlan <[EMAIL PROTECTED]> added the comment:
Antoine's latest patch looks to me like it will fix the current actual
errors in the 1-D case.
Something that may also be considered part of this bug is the fact that
"m[i] = m[i]" doesn't currently work for ite
Nick Coghlan added the comment:
> I'm trying to be practical. If the additional shape/strides storage is
> in Py_buffer, it can benefit anyone wanting to create a subview or doint
> to do something else with shape and strides. If the storage is in
> memoryview, it only benefits
Nick Coghlan added the comment:
I still don't see the problem:
Py_buffer is a minimal description of a region of memory. No more, no
less. It doesn't *do* anything, it's just a description.
memoryview is an object that will (when it's finished) provide an easy
way to
Nick Coghlan added the comment:
Trying another way of getting the point across... if Py_buffer wasn't
defined in PEP 3118, there would have to be some *other* API there
whereby the memoryview implementation could ask an object for a
description of the data layout of the object's buff
Nick Coghlan added the comment:
After looking into this, I think Alexander is correct. There is no
standard mapping between __file__ and __name__ and linecache is mistaken
in assuming such a mapping exists for all importers (and is the same as
the standard filesystem to name mapping to boot
Nick Coghlan added the comment:
The spec get_filename is pretty simple:
Return whatever __file__ would be set to if load_module() was called for
this module.
(runpy's problem is that it never actually loads the module in question,
so it never gets the chance to interrogate __f
New submission from Nick Coghlan :
When writing the unit tests for running doctests from inside a zipfile,
I initially had "" as the name being passed to the
doctest.DocTestFinder.find method.
With that name, the line numbers coming back for all of the examples
were being increm
Nick Coghlan added the comment:
Correction - added as _get_filename() in that revision.
Documenting it and making it public (i.e. removing the underscore) is
still to be done, and will only be done for 2.7/3.1
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
Fixed for 2.7 in r67750.
Will be ported to 2.6, 3.0 and 3.1.
___
Python tracker
<http://bugs.python.org/issue4082>
___
___
Python-bug
Nick Coghlan added the comment:
Final revisions for fix:
2.7 = r67751 (there was a new test file missing from the initial checkin)
2.6 = r67752
3.1 = r67753
3.0 = r67754
--
resolution: -> fixed
status: open -> closed
___
Python tracker
Nick Coghlan added the comment:
Final revisions for fix:
2.7 = r67751 (there was a new test file missing from the initial checkin)
2.6 = r67752
3.1 = r67753
3.0 = r67754
--
resolution: -> fixed
status: open -> closed
___
Python tracker
Nick Coghlan added the comment:
Fixed for 2.7 in r67750.
Will be ported to 2.6, 3.0 and 3.1.
___
Python tracker
<http://bugs.python.org/issue4197>
___
___
Python-bug
Nick Coghlan added the comment:
Fixed for 2.7 in r67750.
Will be ported to 2.6, 3.0 and 3.1.
___
Python tracker
<http://bugs.python.org/issue4512>
___
___
Python-bug
Nick Coghlan added the comment:
Fixed for 2.7 in r67750.
Will be ported to 2.6, 3.0 and 3.1.
___
Python tracker
<http://bugs.python.org/issue4201>
___
___
Python-bug
Nick Coghlan added the comment:
Final revisions for fix:
2.7 = r67751 (there was a new test file missing from the initial checkin)
2.6 = r67752
3.1 = r67753
3.0 = r67754
--
resolution: -> fixed
status: open -> closed
___
Python tracker
Nick Coghlan added the comment:
Final revisions for fix:
2.7 = r67751 (there was a new test file missing from the initial checkin)
2.6 = r67752
3.1 = r67753
3.0 = r67754
--
resolution: -> fixed
status: open -> closed
___
Python tracker
Nick Coghlan added the comment:
Fixed for 2.7 in r67750.
Will be ported to 2.6, 3.0 and 3.1.
___
Python tracker
<http://bugs.python.org/issue4223>
___
___
Python-bug
Nick Coghlan added the comment:
I have a test case locally that demonstrates both the missing line
number in the __main__.py from a zipfile case, as well as the display of
main.c as the filename (the latter is not specific to the zipfile case -
it also happens for a normal main module).
It
Nick Coghlan added the comment:
Re-opening, pending development of a fully passing test specifically for
the __main__.py in zipfile case.
--
resolution: fixed ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/
Nick Coghlan added the comment:
It turns out you were pretty close to pinpointing the problem in
doctest, but didn't quite manage to identify which step was going wrong.
The problem was actually that even after __file__ was being set
correctly, the call to linecache.getlines wasn't b
Nick Coghlan added the comment:
The origin of the unnecessary hashfunc casts is just me following some
of the more specific examples of filling in the tp_hash slot too closely
without checking if the cast was still needed.
I'll apply and backport Hagen's patches to 3.0 soon (as well
Nick Coghlan added the comment:
OK, the discrepancy with bytearray turns out to be fairly
straightforward: bytearray overrides the comparison operations, so
inheritance of the default object.__hash__ is automatically blocked.
range() objects don't support comparison, so they inherit __h
Nick Coghlan added the comment:
It has been pointed out to me that xrange() objects are hashable in 2.x,
and since these range objects are immutable, I don't believe there is
any driving reason for them not to be hashable.
At that point the question becomes one of why xrange() is
Nick Coghlan added the comment:
Bumping to release blocker for 3.0.1 - until I understand this better,
I'm not sure if the xrange->range hashing behaviour change between 2.x
and 3.x is a type specific problem or a general issue in the
implementation of the new approach to tp_hash inh
Nick Coghlan added the comment:
Ah, I think I figured it out - in 2.x, PyObject_Hash itself includes the
fallback to _PyHash_Pointer if none of tp_hash, tp_compare or the
tp_richcompare slots have been implemented on the type.
So long as a type is only trying to inherit object.__hash__ (as is
Nick Coghlan added the comment:
Hagen Fürstenau wrote:
> Hagen Fürstenau added the comment:
>
>> I don't believe there is any driving reason for them not to be hashable.
>
> On the other hand, what is the use case for hashing objects whose
> equality is defined
Nick Coghlan added the comment:
A new function sounds like a good solution to me. How about just calling
it "os.path.commonpath" though?
I agree having a path component based prefix function in os.path is
highly desirable, particularly since the addition of relpath in 2.6:
Nick Coghlan added the comment:
enumerate can be added to the list of builtin types which isn't
initialised correctly, as can the callable+sentinel iterator return from
the 2-argument version of iter() and the default sequence iterator
returned by iter() when given a type with both __len_
Nick Coghlan added the comment:
Copied from python-dev post:
Perhaps the path of least resistance is to change PyObject_Hash to be
yet another place where PyType_Ready will be called implicitly if it
hasn't been called already?
That approach would get us back to the Python 2.x statu
Nick Coghlan added the comment:
Fixed using a lazy call to PyType_Ready in PyObject_Hash:
2.7: r68051
2.6: r68052
Forward-port to Py3k still to come.
___
Python tracker
<http://bugs.python.org/issue4
Nick Coghlan added the comment:
Forward port to 3.x:
3.1: r68058
3.0: r68060
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Nick Coghlan added the comment:
1. The discussion on python-dev shows that the current documentation of
os.path.commonprefix is incorrect - it technically works element by
element rather than character by character (since it will handle
sequences other than strings, such as lists of path
Nick Coghlan added the comment:
The regex based approach to the component splitting when os.altsep is
defined obviously works as well. Duplicating the values of sep and
altsep in the default regex that way grates a little though...
___
Python tracker
<h
Nick Coghlan added the comment:
It certainly looks like all direct calls to PyObject_DEL/PyObject_Del
from outside tp_dealloc implementations are going to be broken in
pydebug builds.
Replacing those calls with either Py_DECREF operations (as Victor's
patch does) or direct calls to _Py_De
Nick Coghlan added the comment:
(changing title and unassigning from Fredrik since this isn't an RE
specific problem, flagged as also affecting interpreter core, flagged as
affecting all currently maintained versions)
--
assignee: effbot ->
components: +Interpreter Core
title:
Nick Coghlan added the comment:
Ah, now that I go to implement it, I remember why I didn't like the idea
of doing anything directly in PyObject_Del. While the Python memory
allocator is primarily designed for allocation of Python objects, it
isn't actually *limited* to that. So t
Nick Coghlan added the comment:
Finally got around to looking at the most recent patch
(issue4580-2.patch). It looks good to me.
I still think something needs to change when it comes to item assignment
for memoryviews with itemsize > 1, but that's not as urgent as fixing
the res
Nick Coghlan added the comment:
FWIW, I actually prefer Mark's graduated approach to the Python->C
migration since we have a continuously working module that will get
incrementally faster over time. As profiling finds performance
bottlenecks in the Python code, those parts can be migra
Nick Coghlan added the comment:
Physically splitting the code base? Ick... I'd prefer just to flag the
parts of the test suite that are optional and let the developers of
other implementations pick and choose as to how much of the pure Python
code they want to adopt to pass the non-opt
Nick Coghlan added the comment:
Reassigning to Raymond (as per the thread at
http://mail.python.org/pipermail/python-dev/2009-January/085030.html)
--
assignee: georg.brandl -> rhettinger
nosy: +ncoghlan
___
Python tracker
<http://bugs.pyth
Nick Coghlan added the comment:
Would a C API in CPython to set the value returned by sys.vm be enough
to help Cython out Stefan?
Such a feature would help with any CPython based variant - the
implementers could either leave sys.vm as "cpython" and attempt to be
fully compatible, o
Nick Coghlan added the comment:
I got the impression from Stefan's question that he would like to be
able to run the stdlib tests with Cython enabled for all of the stdlib
Python modules and know which tests still needed to pass and which could
be safely skipped as being specific to va
Nick Coghlan added the comment:
weakref.proxy needs to be fixed to delegate the unicode slot correctly.
>>> from weakref import proxy
>>> "__unicode__" in dir(type(proxy(Exception)))
False
That predicate must return true in order for the delegation to do the
right
Nick Coghlan added the comment:
Rather than deleting the isinstance() check from the tests completely, I
suggest changing it to be:
self.assert_(isinstance(vi[:], tuple))
Also, comparing directly with a tuple is also a fairly common use of
version_info so it would be worth adding a test to
Nick Coghlan added the comment:
The reason I like the simplegeneric name is that that is exactly what
this feature is: a *simple* generic implementation that is deliberately
limited to dispatching on the first argument (because that is easily
explained to users that are already familiar with
Nick Coghlan added the comment:
Failure to respect isinstance() should be fixed, not documented :)
As far as registering existing functions goes, I also expect registering
lambdas and functools.partial will be popular approaches, so keeping
direct registration is a good idea. There isn'
Nick Coghlan added the comment:
Hmm, there is such a thing as being *too* simple... a generic function
implementation that doesn't even respect ABCs seems pretty pointless to
me (e.g. I'd like to be able to register a default Sequence
implementation for pprint and have all declared
Nick Coghlan added the comment:
Even more inconveniently, the existence of unregister() on ABCs makes it
difficult for the generic to cache the results of the isinstance()
checks (you don't want to be going through the chain of registered ABCs
every time calling isinstance(), since that
Nick Coghlan added the comment:
A __del__ method is definitely desirable (tempfile._TemporaryFileWrapper
gives an example of how to cache the relevant globals on the class
object to avoid attempting calls to None during interpreter shutdown).
The new examples are good, but may give the
Nick Coghlan added the comment:
Incorporated as:
2.7: r69419
3.1: r69421
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
ZipImporter.get_filename() made public in:
2.7: r69425
3.1: r69426
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Nick Coghlan :
--
priority: -> normal
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue5178>
___
___
Python-
Changes by Nick Coghlan :
--
title: Add content manager for temporary directory -> Add context manager for
temporary directory
___
Python tracker
<http://bugs.python.org/iss
Nick Coghlan added the comment:
Any further work on this should wait until the io-in-c branch has landed
(or at least be based on that branch).
--
stage: test needed -> needs patch
___
Python tracker
<http://bugs.python.org/issue1
1101 - 1200 of 6301 matches
Mail list logo
