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 Martin <[EMAIL PROTECTED]> added the comment:
This is exactly the same problem I was having with bdist_msi.
--
nosy: +nick.martin
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
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'
New submission from Nick Barnes <[EMAIL PROTECTED]>:
'/'.encode('utf7') returns '+AC8-'. It should return '/'. See RFC 2152.
'/'.decode('utf7') raises an exception (this is a special case of a
general problem with UTF-7 decodi
New submission from Nick Barnes <[EMAIL PROTECTED]>:
UTF-7 decoding raises an exception for any character not in the RFC2152
"Set D" (directly encoded characters). In particular, it raises an
exception for characters in "Set O" (optional direct characters), such
Nick Barnes <[EMAIL PROTECTED]> added the comment:
# Note, this test covers issues 4425 and 4426
# Direct encoded characters:
set_d =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'(),-./:?"
# Optional direct characters:
set_o = '!"#$%&*
Nick Barnes <[EMAIL PROTECTED]> added the comment:
Well, I could submit a diff for unicodeobject.c, but I have never
contributed to Python (or used this particular tracking system) before.
Is there a standard form for contributing changes? Unifie
Nick Barnes <[EMAIL PROTECTED]> added the comment:
I'll try to get to this next week. Right now I'm snowed under. I don't
promise to do any refactoring.
___
Python tracker <[EMAIL PROTECTED]>
<ht
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
Nick Barnes <[EMAIL PROTECTED]> added the comment:
My original defect report here was incorrect, or possibly only relates
to a particular older Python installation. It is still the case that
UTF-7 decoding is fussier than it need be (decoding should be
permissive), and is broken specif
Nick Barnes <[EMAIL PROTECTED]> added the comment:
Here is my patch. This is a rewrite of the UTF7 encoder and decoder.
It now handles surrogate pairs correctly, so non-BMP characters work
with this codec. And my motivating example ('/'.decode('utf7')) works
OK. I&
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
New submission from Nick Coghlan :
test_curses fails for me by default (running on Fedora 35 in KDE's Konsole):
```
[ncoghlan@thechalk cpython]$ echo $TERM
xterm-256color
[ncoghlan@thechalk cpython]$ ./python -m test -u curses test_curses
0:00:00 load avg: 0.88 Run tests sequentially
0:
Change by Nick Coghlan :
--
pull_requests: +30078
pull_request: https://github.com/python/cpython/pull/31987
___
Python tracker
<https://bugs.python.org/issue44
Change by Nick Coghlan :
--
pull_requests: +30113
pull_request: https://github.com/python/cpython/pull/32024
___
Python tracker
<https://bugs.python.org/issue44
Nick Coghlan added the comment:
The import system is already complex, so I think the hesitation about allowing
arbitrary Path-like objects is warranted. (For example: are importlib's caching
semantics really valid for *arbitrary* path-like objects? An object can be
path-like without
Nick Coghlan added the comment:
On the historical front, wraps & update_wrapper were only designed to handle
true wrapper functions (i.e. those that don't change the calling signature).
For anything else (including partial), I considered it unlikely that the doc
string would
1201 - 1300 of 6501 matches
Mail list logo
