Nick Coghlan ncogh...@gmail.com added the comment:
It turns out my proposed patch is incorrect anyway - it will do the wrong thing
if a thread *other* than the one doing the fork is in the middle of a nested
import at the time the fork occurs.
With issue 7242 establishing that the current
Nick Coghlan ncogh...@gmail.com added the comment:
On further further reflection - I'm back to thinking my patch is correct. With
the way fork is now implemented, the forking thread *always* holds the import
lock, so the assumption in my patch regarding the meaning of the nesting level
Nick Coghlan ncogh...@gmail.com added the comment:
How?
It was easy for wraps to add the __wrapped__ attribute, since it has access to
both the wrapping function and the function being wrapped.
But it hasn't got a clue as to the identity of the decorator that is applying
the wrapper.
Absent
Nick Coghlan ncogh...@gmail.com added the comment:
That's a lot of boilerplate for minimal gain. The Django commenter was right -
proposals that start with everybody in the world needs to do X differently
from the way they do it now for this to be useful aren't ever likely to gain
much
Nick Coghlan ncogh...@gmail.com added the comment:
With the new setUp and tearDown methods, the threadedimp2 patch doesn't apply
cleanly any more.
Looks good and passes for me - fixed patch attached.
Was I meant to still be looking at mtimport or threadimp, or have both of those
been applied
Nick Coghlan ncogh...@gmail.com added the comment:
The generalist in me is inclined to suggest a depth parameter (with depth=1
equivalent to direct dependencies only, and depth = None meaning all
dependencies), but I must admit I don't have a concrete use case for the extra
generality. So
Nick Coghlan ncogh...@gmail.com added the comment:
Although I do find it a little concerning that there is no mention of
sys.path_hooks or sys.meta_path in the modulefinder source code. I suspect this
module only works correctly with vanilla filesystem based imports and can't
handle anything
Nick Coghlan ncogh...@gmail.com added the comment:
It would be good if the test timed out rather than deadlocking in the face of a
broken import lock.
I suggest:
1. Make the two test threads daemon threads
2. Specify a timeout to the join() calls
3. Use self.assertFalse(t1.is_alive
Nick Coghlan ncogh...@gmail.com added the comment:
Both good points - don't worry about it then. +1 to add to the test suite as-is.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9657
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1868
___
___
Python-bugs-list mailing
New submission from Nick Coghlan ncogh...@gmail.com:
As part of the PEP 384 discussion, it was noted that one of the problems with
mixed C runtimes on Windows is that each C runtime in the process has it's own
idea of the current locale setting.
This can be addressed to some degree by having
Nick Coghlan ncogh...@gmail.com added the comment:
For this one, I suggest adding something to
http://docs.python.org/dev/c-api/unicode.html#plain-py-unicode
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Nick Coghlan ncogh...@gmail.com:
As noted in [1] the refcount data for the C API documentation is contained in a
separate file at Doc/data/refcounts.dat.
This file is not mentioned in Documenting Python and hence has not been
correctly updated for Py3k (e.g. none
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - d...@python
nosy: +d...@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9755
New submission from Nick Coghlan ncogh...@gmail.com:
memoryview objects currently offer no way to explicitly release the underlying
buffer.
This may cause problems for mutable objects that are locked while PEP 3118
buffer references remain unreleased (e.g. in 3.2, io.BytesIO supports
Nick Coghlan ncogh...@gmail.com added the comment:
The test suite actually does force a GC collection cycle, so the test may be
more portable than I first thought, but the need to do that suggests an
explicit buffer release API may be a more appropriate solution
Nick Coghlan ncogh...@gmail.com added the comment:
Thanks for that link. Compared to what either of us managed in the original
thread, I think my first post here better articulates why the ability to
explicitly release the buffer is important - not because of general memory
usage, but because
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9789
Changes by Nick Coghlan ncogh...@gmail.com:
--
superseder: - Add context manager protocol to memoryviews
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9789
Nick Coghlan ncogh...@gmail.com added the comment:
I closed 9789 as a duplicate of this. Bringing the details from that issue over
here:
memoryview objects currently offer no way to explicitly release the underlying
buffer.
This may cause problems
Nick Coghlan ncogh...@gmail.com added the comment:
Is this not covered by PEP 3118 at all?
The PEP says “this memory view object holds on to the memory of base
[i.e. the object the buffer was acquired from] until it is deleted”.
Apparently issues pertaining to delayed garbage collection
Nick Coghlan ncogh...@gmail.com added the comment:
On an eyeball review, the structure of do_release seems a little questionable
to me. I'd be happier if view.obj and view.buf were copied to C locals and then
set to NULL at the start of the function before any real work is done.
I believe
Nick Coghlan ncogh...@gmail.com added the comment:
One other question: should IS_RELEASED use || rather than ?
Is there any case where either of those pointers can be NULL and we still want
to continue on rather than bailing out with a ValueError
Nick Coghlan ncogh...@gmail.com added the comment:
Sounds good - I'd say just commit whenever you're happy with it then.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9757
Nick Coghlan ncogh...@gmail.com added the comment:
I assume Brett marked this 3.x only because we currently don't support builtin
packages at all, so making this work crosses way over into feature request
territory. That makes it unsuitable for a branch in maintenance mode (i.e. 2.7).
Added
Changes by Nick Coghlan ncogh...@gmail.com:
--
title: cgi handling of POSTed files is broken - urlparse
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8077
New submission from Nick Coghlan ncogh...@gmail.com:
As per python-dev discussion in June, many Py3k APIs currently gratuitously
prevent the use of bytes and bytearray objects as arguments due to their use of
string literals internally.
Examples:
urllib.parse.urlparse
urllib.parse.urlunparse
New submission from Nick Coghlan ncogh...@gmail.com:
The observation has been made that there are some idioms related to key
functions passed to various methods and functions that aren't particularly easy
to discover.
One suggestion is to create a key function glossary entry that provides
Nick Coghlan ncogh...@gmail.com added the comment:
From the python-dev thread
(http://mail.python.org/pipermail/python-dev/2010-September/103780.html):
==
So the domain of any polymorphic text manipulation functions we define would be:
- Unicode strings
- byte sequences where
Nick Coghlan ncogh...@gmail.com added the comment:
Swapnil's analysis looks correct to me - there are certain rules you have to
follow before calling back into the Python interpreter core. If you don't
follow them, the behaviour you will get is completely undefined.
If the problem still
Nick Coghlan ncogh...@gmail.com added the comment:
The suggestion in http://bugs.python.org/issue6627#msg116722 is a good one.
This a case where the user may legitimately not realise that threading.local is
stored in the *temporary* state created by ctypes rather than in something more
Nick Coghlan ncogh...@gmail.com added the comment:
To make the distinction easier to remember, would it help if the methods that
are currently set to return bytes instead accepted the typical encoding+errors
parameters, with parallel *b APIs to get at the raw bytes?
My concern
Nick Coghlan ncogh...@gmail.com added the comment:
I'm rejecting this due to the effect it has on the output parameters.
The patch ends up have to stick (char *) casts in several places because a
pointer into the string provided via the char * input parameter is returned by
each affected API
Nick Coghlan ncogh...@gmail.com added the comment:
The design approach (at least for urllib.parse) is to add separate *b APIs that
operate on bytes rather than implicitly allowing bytes in the ordinary versions
of the function.
Allowing programmers to manipulate correctly encoded (and hence
Nick Coghlan ncogh...@gmail.com added the comment:
On Tue, Sep 21, 2010 at 2:39 PM, Swapnil Talekar rep...@bugs.python.org wrote:
Swapnil Talekar swapnil...@gmail.com added the comment:
Nick, the last statement,
While this is correct for most purposes, it does mean that...
can be simplified
Nick Coghlan ncogh...@gmail.com added the comment:
I've thought about this in the past, but never really pursued it due to the
question of what to do with the __main__ namespace.
There are three options here:
1. Use runpy.run_module to run the module in a fresh __main__ namespace
2. Use
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, I realised shortly after I sent my email in response to the checkin that
the original version was covering more cases in that first try-block.
I'll defer to you when it comes to exactly which case that NotImplementedError
was covering
Nick Coghlan ncogh...@gmail.com added the comment:
Having seen the reversion go by on the checkins list, I think there are
distinctions the interpreter should be making here in order to improve the
error messages, but it isn't.
Ideally, we want to be able to tell the user (without writing War
Nick Coghlan ncogh...@gmail.com added the comment:
Attached patch is a very rough first cut at this. I've gone with the basic
approach of simply assigning the literals to local variables in each function
that uses them. My rationale for that is:
1. Every function has to have some kind
Nick Coghlan ncogh...@gmail.com added the comment:
Possible approach (untested):
def get_tokens(source):
if hasattr(source, encode):
# Already decoded, so bypass encoding detection
return _tokenize(io.StringIO(source).readline, None)
# Otherwise attempt to detect
Nick Coghlan ncogh...@gmail.com added the comment:
A possible duck-typing approach here would be to replace the instance(x, str)
tests with hasattr(x, 'encode') checks instead.
Thoughts?
--
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
As per Antoine's comment on #9873, requiring a real string via
isinstance(source, str) to trigger the string IO version is likely to be
cleaner than attempting to duck-type this. Strings are an area where we make so
many assumptions about
Nick Coghlan ncogh...@gmail.com added the comment:
Agreed - I think there's a non-zero chance of triggering the str-path by
mistake if we try to duck-type it (I just added a similar comment to #9969
regarding a possible convenience API for tokenisation
Nick Coghlan ncogh...@gmail.com added the comment:
Added to Reitveld: http://codereview.appspot.com/2318041/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9873
Nick Coghlan ncogh...@gmail.com added the comment:
One of Antoine's review comments made me realise I hadn't explicitly noted the
why not decode with latin-1? rationale for the bytes handling. (It did come
up in one or more of the myriad python-dev discussions on the topic, I just
hadn't
Nick Coghlan ncogh...@gmail.com added the comment:
I think it's quite misguided. latin1 encoding and decoding is blindingly
fast (on the order of 1GB/s. here). Unless you have multi-megabyte URLs,
you won't notice any overhead.
Ah, I didn't know that (although it makes sense now I think
Nick Coghlan ncogh...@gmail.com added the comment:
From a function *user* perspective, the latter API (bytes-bytes, str-str) is
exactly what I'm doing.
Antoine's point is that there are two ways to achieve that:
Option 1 (what my patch currently does):
- provide bytes and str variants of all
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, the general implementation concept I'm thinking of going with for option
2 will use a few helper functions:
url, coerced_to_str = _coerce_to_str(url)
if coerced_to_str:
param = _force_to_str(param) # as appropriate
...
return
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9951
___
___
Python-bugs-list mailing
Nick Coghlan ncogh...@gmail.com added the comment:
Patch generally looks good, but the type of retbuf is incorrect (should be
Py_UNICODE* rather than wchar_t*).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9951
Nick Coghlan ncogh...@gmail.com added the comment:
As per RDM's email to python-dev, a better way to create the pseudo_str values
would be by decoding as ascii with a surrogate escape error handler rather than
by decoding as latin-1.
--
___
Python
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, I'll have to time it to see how much difference latin-1 vs
surrogateescape makes when the MSB is set in any bytes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9873
Nick Coghlan ncogh...@gmail.com added the comment:
On Tue, Oct 5, 2010 at 5:32 PM, STINNER Victor rep...@bugs.python.org wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
If you were worried about performance, then surrogateescape is certainly
much slower than latin1
Nick Coghlan ncogh...@gmail.com added the comment:
On Wed, Oct 6, 2010 at 2:59 AM, Alexander Belopolsky
rep...@bugs.python.org wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am afraid, for ordinary scripts these modules effectively use option 3. I
think
Nick Coghlan ncogh...@gmail.com added the comment:
I've been pondering the idea of adopting a more conservative approach here,
since there are actually two issues:
1. Properly quoted URLs are transferred as pure 7-bit ASCII (due to
percent-encoding of everything else). However, most
Nick Coghlan ncogh...@gmail.com added the comment:
The difference here is the one pointed out in the original post: for a
function, you usually only care about having a value, so if you don't want to
call it, you can just swap in a None value instead. If you need an actual
callable
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10049
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
To me, this is more a matter of conceptual completeness than one of practical
utility (ala fractions.Fraction). That said, I *have* personally encountered
the I only sometimes want to wrap this code in a CM situation, so it isn't
completely
Nick Coghlan ncogh...@gmail.com added the comment:
I suggest using sys._xoptions to make it clearer that this is for CPython
specific internal implementation runtime tweaks. We're putting it in sys so
*we* can get at it, not applications.
(It also makes it clear that other implementations
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5178
___
___
Python-bugs-list
Changes by Nick Coghlan ncogh...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8202
___
___
Python-bugs-list
New submission from Nick Coghlan ncogh...@gmail.com:
During interpreter shutdown, modules can become unusable as module globals are
set to None. This is a problem for tempfile.TemporaryDirectory, as it needs
working os, os.path and stat modules in order to clean up the filesystem.
The class
Nick Coghlan ncogh...@gmail.com added the comment:
Cleanup of sys and __builtin__ is already delayed - this particular issue could
be fixed by delaying cleanup of a few more modules, along with the proposed
change to GC invocation in issue #1545463
Nick Coghlan ncogh...@gmail.com added the comment:
Committed (with enhanced tests and a few fixes) in r85818
And credit where it's due to test___all__ for picking up a typo in my
adjustment to tempfile.__all__ :)
I created issue #10188 to track the shutdown problem. I'm considering taking
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5178
Nick Coghlan ncogh...@gmail.com added the comment:
Unless I hear some reasonable objections within the next week or so, I'm going
to document and commit the ascii-strict coercion approach for beta 1.
The difference in code clarity is such that I'm not even going to try to
benchmark the two
Nick Coghlan ncogh...@gmail.com added the comment:
I find Raymond's perspective persuasive in this case. Feel free to post either
the original idea or my later variant as an ASPN cookbook recipe. (you could
actually combine the two, and use NullContext as an implementation detail
Nick Coghlan ncogh...@gmail.com added the comment:
I'd still like to have another look at this before beta 1, but can't promise
I'll get to it. Unassigning in case someone else has some roundtuits to spare
over the next few weeks.
--
assignee: ncoghlan
Nick Coghlan ncogh...@gmail.com added the comment:
R.I.P contextlib.nested (it is gone in 3.2 following the deprecation in 3.1).
The issue is obscure enough that I don't see much value in updating the
documentation for the versions that still contain it in deprecated form
Nick Coghlan ncogh...@gmail.com added the comment:
I still think this is a good idea, I'm just not actively working on it. It
might make a good project for someone wanting to get to know the process of
working on CPython without having to deal with anything that is particularly
tricky
Nick Coghlan ncogh...@gmail.com added the comment:
Merging the interfaces for mkdtemp and TemporaryDirectory isn't going to happen.
mkstemp/mkdtemp are for when the user wants to control the lifecycle of the
filesystem entries themselves. (Note that context management on a regular
file-like
Nick Coghlan ncogh...@gmail.com added the comment:
Unassigning from ping given the lack of comments - I should be able to have a
look at this in time for beta 1
--
assignee: ping - ncoghlan
___
Python tracker rep...@bugs.python.org
http
New submission from Nick Coghlan ncogh...@gmail.com:
Generators can be in four different states that may be relevant to framework
code making use of them (especially as coroutines). This state is all currently
available from Python code, but is rather obscure and could be made readable
Nick Coghlan ncogh...@gmail.com added the comment:
On Thu, Oct 28, 2010 at 10:55 PM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou pit...@free.fr added the comment:
Is it CPython-specific?
The states are not CPython-specific (they're logical states of the
underlying generator
Nick Coghlan ncogh...@gmail.com added the comment:
So something like:
GEN_CREATED, GEN_ACTIVE, GEN_CLOSED = range(3)
def getgeneratorstate(g):
Get current state of a generator-iterator.
Possible states are:
GEN_CREATED: Created, waiting to start execution
GEN_ACTIVE: Currently
Nick Coghlan ncogh...@gmail.com added the comment:
Indeed, the minimal lifecycles are:
GEN_CREATED-GEN_CLOSED (exception thrown in before the generator was even
started)
GEN_CREATED-GEN_RUNNING-GEN_CLOSED (initial next() with internal logic that
skips all yields)
GEN_CREATED-GEN_RUNNING
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10220
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
Since it works for me (I tried both r84120, my old 2.7 build from August or so,
and r86033, which is the 2.7 head), we'll need more information. The starting
blurb from the interactive prompt would be a good place to start.
(-m was slightly
Nick Coghlan ncogh...@gmail.com added the comment:
Note also that site.py runs twice when used with -m: once implicitly during
interpreter startup, and a second time as the main module. Due to the way the
interpreter starts up and figures out sys.path, it is possible for the implicit
import
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10263
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
r82508 is the correct release binary (created after the error I mentioned above
was fixed).
I've CC'ed Ronald to see if he can shed any light - it may be a platform
specific issue with the way sys.path is calculated
Nick Coghlan ncogh...@gmail.com added the comment:
No, there won't be another binary release until 2.7.1 comes out. The SVN
revision number ratchets up pretty fast, since it is counting checkins on *all*
branches, even experimental ones
Nick Coghlan ncogh...@gmail.com added the comment:
Yeah, because the internal import system isn't fully exposed, runpy and a
couple of other tools in the standard library rely on the emulation in pkgutil
instead. I know there are some differences between the emulation and the
builtin
Nick Coghlan ncogh...@gmail.com added the comment:
On Wed, Nov 3, 2010 at 2:17 AM, Ron Adam rep...@bugs.python.org wrote:
Ron Adam ron_a...@users.sourceforge.net added the comment:
Nick, I can update the patch and move the server back into pydoc.py if that
will help you get this into 3.2
Nick Coghlan ncogh...@gmail.com added the comment:
I still like the higher level API concept, although I might not do it exactly
as presented here any more.
Independently of introducing a new parsing API, it would be worthwhile
extracting the parsing tests from the attached module to make
Nick Coghlan ncogh...@gmail.com added the comment:
As far as I know, PEP 3118 serves its purpose of allowing extension modules
like numpy and PIL to share data without needing to copy it around all the
time. It's just that memoryview wasn't really part of that purpose (since all
the affected
Nick Coghlan ncogh...@gmail.com added the comment:
Read the Releasing the buffer section in PEP 3118 again. Unless I'm
misunderstanding you completely, the rules you're asking for are already in
place: those fields are entirely the responsibility of the exporting object,
and it needs
Nick Coghlan ncogh...@gmail.com added the comment:
Ah, yes, I see what you mean - because runpy ignores the sys.modules cache (by
design), it won't see the precached module instance placed there by the
bootstrap code.
We actually *could* make this work on our end: if we find an existing
Nick Coghlan ncogh...@gmail.com added the comment:
Hmm, if we're ever creating a new copy of a Py_buffer without calling GetBuffer
again on the original object, then *that* is a bug (exactly comparable to
copying a PyObject pointer without incrementing the reference count - it's OK
if you can
Changes by Nick Coghlan ncogh...@gmail.com:
--
title: get_shape0 in memoryobject.c not checked for error return - Problems
with Py_buffer management in memoryobject.c (and elsewhere?)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
It doesn't help that neither PEP 3118 nor the Py_buffer docs mention the obj
member of the Py_buffer struct that refers back to the original object
providing the buffer - that's fairly fundamental to understanding how
PyBuffer_Release
Nick Coghlan ncogh...@gmail.com added the comment:
So the overall to-do list here is sounding like:
1. Document Py_buffer-obj appropriately in both the C API documentation and
in PEP 3118
2. Ensure GetBuffer/ReleaseBuffer are used as the moral equivalent of
INCREF/DECREF for Py_buffer
Nick Coghlan ncogh...@gmail.com added the comment:
Just to be clear, even *I* don't think adding urischemes as it stands is a
particularly great idea, and I wrote it. The only reason I haven't closed the
issue is because I'd like to see it mined for additional tests in test_urlparse
Nick Coghlan ncogh...@gmail.com added the comment:
Removing shebang lines from svn completely and only *adding* them during
installation steps as appropriate may be an interesting approach. (I noted that
my grep of my local build found only correct references to python3.2 in the
built scripts
Nick Coghlan ncogh...@gmail.com added the comment:
For the record, my list is from an svn checkout of r86191
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10318
Nick Coghlan ncogh...@gmail.com added the comment:
A few more deeper in the py3k source tree:
Doc/tools/docutils/_string_template_compat.py
Doc/tools/docutils/readers/python/pynodes.py
Doc/tools/sphinx/pycode/pgen2/token.py
Lib/lib2to3/tests/data/different_encoding.py
Adding Georg, since
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: d...@python -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10318
___
___
Python-bugs
Nick Coghlan ncogh...@gmail.com added the comment:
Reopening as a reminder to myself that I have a new PEP I want to write in this
area. The idea is essentially a lighter weight alternative to PEP 377 that adds
an optional __entered__ method to the context management protocol along
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10329
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
Just a note for myself when I next update the patch: the 2-tuple returned by
defrag needs to be turned into a real result type of its own, and the
decode/encode methods on result objects should be tested explicitly
301 - 400 of 6264 matches
Mail list logo
