Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15496>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
See #15496 for an alternative approach to solving this problem, at least in the
test suite - as noted in that issue, the rename dance isn't sufficient when the
problem gets triggered by a different sequence like:
unlink(file_in_parent_dir)
unlink(paren
Nick Coghlan added the comment:
My inclination is to say that using ctypes is a reasonable option for improving
Windows buildbot stability in the near term, but we'd probably want to move
this into _winapi long term.
Adding Antoine & MvL to get their opinion.
--
nosy: +loewi
Nick Coghlan added the comment:
We'll also want to add this to the inheritance tests in test_importlib.test_abc
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
In reviewing Eric's changes, I found what I consider a good reason to keep
Finder as the root of the hierarchy: *all* finders, both meta path and path
entry, will continue to share the optional "invalidate_caches" API.
I'll commit a
Nick Coghlan added the comment:
Specifically, what I did was to drop "find_module" from the Finder ABC, but
keep the ABC itself as a way to document the common "invalidate_caches" API.
The ABC definition no longer cares whether you implement find_module() or not.
MetaPath
Nick Coghlan added the comment:
This didn't close automatically (I assume the open dependency upset matters,
since it also prevented me from closing it manually the first time).
Applied to trunk in http://hg.python.org/cpython/rev/a1ac1e13c5a0
(including the rename from #
Changes by Nick Coghlan :
--
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15519>
___
___
Nick Coghlan added the comment:
I also dealt with #15519
--
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
OK, that last commit (along with one I did earlier for the import statement)
brought over all the fixes I was previously overly hasty in committing to
Barry's importdocs branch.
I've decided I can live with "regular packages" as the
Nick Coghlan added the comment:
We changed quite a bit already as we tried to make everything consistent,
including the importlib ABCs. Current version is on trunk, current
discussion is in #15502
--
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
Barry covered it in a footnote
--
___
Python tracker
<http://bugs.python.org/issue15473>
___
___
Python-bugs-list mailin
Nick Coghlan added the comment:
While I agree this is important (e.g. I know Dave started looking into this as
getting NumPy working is currently a blocker for Fedora migrating their Python
3 stack to 3.3), the burden is definitely on the NumPy side to get the code
point values using the
Nick Coghlan added the comment:
On the "self-contained" packages point, I was going to suggest that name, but
the ability to set __path__ from __init__.py messes with it. "Regular packages"
isn't great, but I'm willing to tolerate it (mainly because it was the
te
Nick Coghlan added the comment:
See my comment above about explicitly defining the "path import subsystem" and
renaming the "path importer" to be the "path import finder". I think the
subsystem is well worth calling out explicitly, as when most people think of
P
New submission from Nick Coghlan:
I've been tinkering with the ipaddress module as I review Eli's documentation
and have uncovered a *very* nasty interaction between ipaddress objects and the
bytes constructor.
Specifically, if you pass an integer to bytes() it will attempt to al
Nick Coghlan added the comment:
It actually wasn't meant to, as I only meant to commit the code changes (I was
still working on the docs, using your patch as a starting point).
However, it makes more sense to just finish my changes and commit them rather
than reverting anything.
Nick Coghlan added the comment:
I'm still not overjoyed with the "this isn't documented here, go read it over
there" situation. However, duplicating the text everywhere isn't ideal either.
So, let's finish it up with my current approach: explicitly listing the m
Nick Coghlan added the comment:
Perhaps if memoryview doesn't understand the format code, it can fall back on
memcmp() if strcmp() indicates the format codes are the same?
Otherwise we're at risk of breaking backwards compatibility with more than just
array('u').
Also,
Nick Coghlan added the comment:
I think Victor's patch is a good solution to killing the 'u' and 'w' exports in
3.4, but we need to restore some tolerance for unknown format codes to
memoryview in 3.3 regardless.
--
New submission from Nick Coghlan:
In discussing #15216, I noticed that the write_through parameter is completely
unused in the Python implementation of TextIOWrapper.
That also means we have a hole in the test coverage: there is no test that is
run on both the C and Python versions to ensure
Nick Coghlan added the comment:
The reason I marked this as a release blocker for 3.4 is because it's a key
piece of functionality for writing command line apps which accept an encoding
argument. I'll use "high" instead.
An interesting proposal was posted to the python-d
Nick Coghlan added the comment:
Ah, thanks. Yes, that could definitely use a comment :)
--
priority: release blocker -> normal
stage: test needed -> needs patch
type: behavior -> enhancement
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
I confess I was thinking of an even simpler "format strings must be identical"
fallback, but agree your way is better, since it reproduces the 3.2 behaviour
in many more cases where ignoring the format string actually did the right
thing.
The struc
New submission from Nick Coghlan:
Currently, if you override a method from a base class, the docstring is not
inherited, even if it remains accurate.
This issue proposes an enhancement to inspect.getdoc() that allows the
docstring to be retrieved from the inheritance hierarchy in the case
Nick Coghlan added the comment:
To bring back Victor's comments from the list:
- stdout/stderr are fairly easy to handle, since the underlying buffers can be
flushed before switching the encoding and error settings. Yes, there's a risk
of creating mojibake, but that's unavo
Nick Coghlan added the comment:
Since the next release of 3.2 is the *last* release of 3.2, yet it will remain
supported by distros well beyond that, yes, I think this should block the final
3.2 release.
--
___
Python tracker
<h
Nick Coghlan added the comment:
Ah, you're right - peeking into the underlying buffer would be enough to
handle encoding detection.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
Done. Only substantive comment was that Finder should be registered with both
of the more specific metaclasses, but there were a couple of docs comments as
well.
--
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
Oh, and +1 for Eric's "path-based finder". States clearly that it is a finder
that *uses* import paths, rather than finding them.
--
___
Python tracker
<http://bugs.pyt
Nick Coghlan added the comment:
Sounds good. Perhaps steal the impl from FileFinder.find_module (i.e. the one
with the ImportWarning).
--
___
Python tracker
<http://bugs.python.org/issue15
Nick Coghlan added the comment:
Stefan's proposed definition is correct. Shapes define array types, format
strings define entry types, then the actual memory contents define the
value.
It's not "Stefan's definition of equivalence", it's what a statically typed
Nick Coghlan added the comment:
Whatever the struct module produces for a format code is the same thing that
memoryview.to_list() should produce.
PEP 3118 contains way too many errors (as has been found out the hard way) to
be considered a normative document
Nick Coghlan added the comment:
The struct module documentation takes precedence over PEP 3118 when it comes to
pre-existing format codes, as changing struct is not feasible due to backwards
compatibility concerns, and we don't want two conflicting notations for binary
format descrip
Nick Coghlan added the comment:
Following up here after rejecting #15622 as invalid
The "unicode" codes in PEP 3118 need to be seriously rethought before any
related changes are made in the struct module.
1. The 'c' and 's' codes are currently used for raw byt
Nick Coghlan added the comment:
However, based on this issue, I have added some comments to #3132 (I think PEP
3118's simplistic approach to embedded text data is broken and a bad idea)
--
___
Python tracker
<http://bugs.python.org/is
Changes by Nick Coghlan :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15622>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
Pretty sure it was just an error on my part.
--
___
Python tracker
<http://bugs.python.org/issue15622>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
OK, I think I finally understand what Martin is getting at from a semantic
point of view, and I think I can better explain the background of the issue and
why Stefan's proposed solution is both necessary and correct.
The ideal definition of equivalenc
Nick Coghlan added the comment:
Short version:
3.3 implemented new constraints on memoryview equality comparisons to eliminate
cases that were incorrectly returning True when they should have returned False.
However, the format constraints are currently too restrictive, so some
memoryview
Nick Coghlan added the comment:
I can see value in adopting the abstraction approach, but it's not part of this
issue. That problem already existed when using memoryview in 3.2, we can wait
until 3.4 to fix it.
There's an actual, concrete regression in 3.3 that may break code, and
Nick Coghlan added the comment:
And, to be honest, I'd be quite happy for "congratulations, you have reached
the threshold where you need NumPy rather than memoryview" to be the long term
answer to getting "by value&q
Nick Coghlan added the comment:
There's still work to be done. The current status in 3.3 trunk is that:
Wide build:
>>> memoryview(array("u")).format
'w'
Narrow build:
>>> memoryview(array("u")).format
'u'
Neither of these
Nick Coghlan added the comment:
Hmm, you're right. OK, here's a simpler proposal for 3.3:
1. Always look at shape first. If they're different, then they're not equal
2. If both formats are known, compare by unpacked value
3. If either format is unknown, compare by memory
Nick Coghlan added the comment:
We do import modules in the Object/* code if we really need to (Grep for
"PyImport_Import" in the Objects dir)
It seems to me like this case is rapidly reaching (or has even gone well past)
the point where that's the sensible thing to do.
Nick Coghlan added the comment:
Yeah, as soon as I got your email I realised I'd only been searching for usage
*in the patch* rather than the full file. Oops :(
More comments in the review.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
I admit that the main thing that bothers me with the proposal in PEP 3118 is
the inconsistency between c -> bytes, while u, w -> str
This was less of an issue in 2.x (which was the main frame of reference when
the PEP was written), with implicit str/u
Nick Coghlan added the comment:
I wouldn't change the export formats used for the 'u' typecode at all in 3.4 -
I'd add new typecodes to array that match any new struct format characters and
are exported accordingly. 'u' would *never* become a formally defi
Nick Coghlan added the comment:
Adding a link to #15625, which is discussing the other end of this issue
(whether or not memorview should support 'u' as a typecode).
--
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
I guess the main alternative to deprecation that preserves the invariant you
describe would be to propagate the "u == Py_UNICODE" definition to memoryview.
Since we're trying to phase out Py_UNICODE, deprecation seems the more sensible
course.
Nick Coghlan added the comment:
As Stefan noted, so long as Py_UNICODE is 16 bits in the Mac OS X builds, then
this should now be back to the 3.2 behaviour.
--
nosy: +ncoghlan
priority: low -> high
___
Python tracker
<http://bugs.pyth
Nick Coghlan added the comment:
I guess the analogy with bytes objects is that UCS-2 code points can be
handled as 16-bit integer objects.
If we're going to do a programmatic deprecation now, that's the only
alternative typecode currently available. Do we want to recommend that? Or
Nick Coghlan added the comment:
I'm at the pyconau sprints for the next couple of days - I'll make sure
this is dealt with.
On Aug 19, 2012 10:07 PM, "Eli Bendersky" wrote:
>
> Eli Bendersky added the comment:
>
> I'm just waiting for a review. If Nic
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue14814>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
Since there was no regression test added for this, it appears to me that it is
broken again now that we're using importlib.
It may be rather hard to fix given the limitations of the set_data API :(
--
assignee: facundobatista ->
nosy: +bret
Nick Coghlan added the comment:
OK, I tracked down the original reason for the behavioural change: #2051
The important aspect in that patch is preserving the *read* permissions from
the .py file so we don't accidentally expose data to other users.
Kevin's patch seems like a good ap
Nick Coghlan added the comment:
(Note: Kevin is looking into this at the PyConAU sprints)
New test case needed (probably in Lib/test/test_import.py):
- create .py file as 0400
- import it
- check .pyc (or .pyo) file is 0600
That ensures the #2501 security bug remains fixed, while also
New submission from Nick Coghlan:
While working on #8810, I was reminded of the problem of wanting to inherit
docstrings while replacing a method implementation.
The abstract base class method docstrings for tzinfo.utcoffset and tzinfo.dst
are also correct for the concrete subclasses in the
Nick Coghlan added the comment:
Slight correction: turns out this docstring appears in a lot of other places,
too.
--
___
Python tracker
<http://bugs.python.org/issue15
Nick Coghlan added the comment:
It turns out these particular docstrings are duplicated all over the place, as
time and datetime both wrap the tzinfo method, and there is both the tzinfo ABC
as well as the concrete fixed offset subclasses, and this happens in both C and
Python.
Ben's
Changes by Nick Coghlan :
--
title: Enhance file.readlines by making line separator selectable -> Add
support for reading records with arbitrary separators to the standard IO stack
versions: +Python 3.4 -Python 3.2
___
Python tracker
&l
Nick Coghlan added the comment:
Just a heads up that I'm about to check in a fairly major change to the
sequence docs layout. I'm leaving the memoryview block alone, so hopefully this
won't cause you any problems, but there's going to be a merge in your future :)
--
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/issue4966>
___
___
Python-bugs-list mai
Changes by Nick Coghlan :
--
Removed message: http://bugs.python.org/msg168621
___
Python tracker
<http://bugs.python.org/issue15731>
___
___
Python-bugs-list m
Changes by Nick Coghlan :
--
Removed message: http://bugs.python.org/msg168622
___
Python tracker
<http://bugs.python.org/issue15731>
___
___
Python-bugs-list m
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file26910/issue8810_reconcile_docs.patch
___
Python tracker
<http://bugs.python.org/issue15731>
___
___
Nick Coghlan added the comment:
Rejecting - if anyone really wants this. they can do it as their own custom
import hook.
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue6074>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
The patch also adds a test suite for the code module, in order to demonstrate
that the issue is actually fixed.
However, due to the interactive nature of the component, the new tests rely on
unittest.mock. Backporting the test suite would mean eliminating that
New submission from Nick Coghlan:
Currently, modules that use the PyGILState* APIs cannot be used with mod_wsgi,
as mod_wsgi uses the subinterpreter support.
Graham Dumpleton and I spent some time discussing this at PyCon AU 2012, and we
believe that the incompatibility can be resolved with a
Nick Coghlan added the comment:
You should be able to just use "tuple(col[0] for col in cursor.description)"
instead of the current list comprehension in order to make the argument
hashable.
--
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
It would twiddle the autoInterpreterState and autoTLSkey entries in the
pystate.c global variables to point to a different subinterpreter.
As I understand the situation, mod_wsgi doesn't need arbitrary externally
created threads to be able to call back
Nick Coghlan added the comment:
Graham, even better would be if you could try the following combination:
_PyGILState_Fini();
_PyGILState_Init(si, st);
(where si and st are the interpreter state and thread state for the target
subinterpreter)
If a new PyGILState_SwitchInterpreter API is going
Nick Coghlan added the comment:
Just as they do today, all externally created threads will still go to *one*
interpreter when they hit PyGILState_Ensure(). It's just that interpreter won't
be the main one.
Since the whole point of the PyGILState API is to support threads that don
Nick Coghlan added the comment:
My understanding of the mod_wsgi architecture is that it uses subinterpreters
to maintain a persistent process, while still providing a relatively pristine
interpreter state to handle each new request. This means even when you're using
multiple processes w
Nick Coghlan added the comment:
Sorry, I mischaracterised the way mod_wsgi works slightly. However, my
understanding is still that the scope of this particular fix is merely to allow
all external threads to be redirected to a different subinterpreter at various
times over the life of a
Nick Coghlan added the comment:
s/slightly/completely/ (I believe my description of the core problem was right,
but my description of why that problem exists was wrong - it actually has to do
with the way mod_wsgi handles virtual hosts and endpoints)
If we expose an official way to switch the
Nick Coghlan added the comment:
Umm, no. The whole point of the GILState API is that you can call it from a
thread which knows *nothing* about Python.
It will then use the *process global* state in the pystate.c statics to
initialise that thread with a Python thread state. Currently, that
Nick Coghlan added the comment:
Aaron was looking for something to work on for the PyConAU sprints, and set
himself the task of closing as many issues related to the code module as
possible.
The main outcome of that was the new test suite added in #12643, which should
make it easier to work
Nick Coghlan added the comment:
Clarifying the request: the constructor signatures for internal types should be
documented in http://docs.python.org/dev/library/types, rather than just
listing the types.
If creation of new instances from Python is not supported, that should also be
Nick Coghlan added the comment:
The first easy part of this patch is to document the signatures for types in
that module where that info is available in the docstring:
CodeType
FunctionType
LambdaType
SimpleNamespace
MethodType
The second easy part is that the following need to be documented
Nick Coghlan added the comment:
Bound methods are created dynamically on lookup, while object ids may be reused
after the original object is destroyed.
There's no bug here - just a combination of those two language behaviours that
is frequently surprising to users that have just notic
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue2051>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
I have a patch that works, and that I think may point the way to a replacement
API for set_data in 3.4. Just running the full test suite before I check it in.
The test you posted definitely saved me a lot of time.
My version bypasses the cache, though. This
Nick Coghlan added the comment:
Also, my patch precisely recreates 3.2 behaviour, so it will mean #6074 may
also affect 3.3. That isn't a regression, hence not a release blocker, but
would still be good to get fixed for rc1.
--
___
Python tr
Nick Coghlan added the comment:
Adding 3.3 to affected versions, since I'm about to check in a fix for #2051
that will reintroduce this problem.
--
nosy: +eric.snow
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/i
Changes by Nick Coghlan :
--
Removed message: http://bugs.python.org/msg168983
___
Python tracker
<http://bugs.python.org/issue2501>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
(oops, transposed the digits in the checkin message)
New changeset 3a831a0a29c4 by Nick Coghlan in branch 'default':
Close #2051: Permission bits are once again correctly copied from the source
file to the cached bytecode file. Test by Eric
Nick Coghlan added the comment:
I'm not sure it makes sense to call this new API "PyGILState_EnsureEx". My
concern is that the behaviour is quite different in the presence of an existing
thread state:
Ensure:
- if a thread state exists, use that interpreter
- otherwise,
Nick Coghlan added the comment:
And the current "autoTLSkey" could move into the interpreter state object? I
like it - that's a lot more flexible than the approach I was thinking of.
--
title: Add PyGILState_SwitchInterpreter -> Support subinterpreters in
Nick Coghlan added the comment:
With Stefan's major improvements to the test suite for 3.3, the risk is low and
I *really* don't want to spend the life of the 3.3 series excusing the current
comparison behaviour.
By contrast, explaining the shift in definition as moving from
Nick Coghlan added the comment:
I'm currently on IRC and double checking the patch locally.
--
___
Python tracker
<http://bugs.python.org/issue15573>
___
___
Nick Coghlan added the comment:
Stefan, was there something specific you wanted to do before committing?
Otherwise I can commit it as soon as this full test run finishes.
--
___
Python tracker
<http://bugs.python.org/issue15
Changes by Nick Coghlan :
--
priority: release blocker -> high
___
Python tracker
<http://bugs.python.org/issue7475>
___
___
Python-bugs-list mailing list
Un
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15781>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
No joy here either - currently at 704 successful runs and counting with
Stefan's command line.
$ uname -a
Linux lancre 3.5.1-1.fc17.x86_64 #1 SMP Thu Aug 9 17:50:43 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
$ cat /proc/cpuinfo | grep "model name&q
Nick Coghlan added the comment:
Despite my earlier comments, I'm now inclined to agree with Martin here -
upgrading to 3.3 fixes so many other problems with memoryview, that's a more
compelling solution.
And, of course, using NumPy instead always remains an option for more robust
Nick Coghlan added the comment:
(Not saying this shouldn't be fixed, just saying it's not a disaster if it
isn't)
--
___
Python tracker
<http://bugs.pyt
Nick Coghlan added the comment:
Up to 2279 runs without a failure here - yay for elusive hardware specific
threading bugs :P
I'll leave it running overnight and see what happens.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Nick Coghlan:
decimal.localcontext() works correctly with both the pure Python decimal module
and the C accelerator.
decimal.localcontext(None) only works with the pure Python version. The C
accelerator throws an exception instead of treating it as equivalent to
omitting
3501 - 3600 of 6301 matches
Mail list logo
