Nick Coghlan added the comment:
As noted in the commit message, I didn't backport this, since it didn't seem
worth risking breaking even the unlikely case that someone actually *was* using
the MAILCAP environment variable on Windows.
--
resolution: -> fixed
stage:
Nick Coghlan added the comment:
Putting this back to open until we decide what to do about the OS X test
failures. It sounds like it could really do with some more poking and prodding
to figure out whether or not it poses a potential security risk or is just a
relatively cosmetic problem
Nick Coghlan added the comment:
Rather than exposing the function pointers directly to the linker, I'd be
happier with a function based API, with the pointer storage then being made
static inside ceval.c.
/* Each function returns the old func, or NULL on failure */
_PyEval_GIL
Nick Coghlan added the comment:
Nothing specific, just a reflexive C++ induced dislike for linker-accessible
globals in general.
However, while I slightly prefer the function driven API, I wouldn't actively
oppose direct linker access if someone else wanted to check
Nick Coghlan added the comment:
The pep380 branch in my bitbucket repo has been updated with the refactored
tests that Ryan Kelly put together at the PyconAU sprints (as well as being
brought up to speed with 3.x tip).
The update depends on the new dis.get_opinfo() API added by issue #11816
New submission from Nick Coghlan :
Section 4 of the Standard Library reference currently includes the two
following sections (amongst others):
4.6. Sequence Types — str, bytes, bytearray, list, tuple, range
4.9. memoryview type
This is crazy - memoryview, a fairly niche type, gets its own
Changes by Nick Coghlan :
--
title: Rearrange descriptions of builtin types -> Rearrange descriptions of
builtin types in the Library reference
___
Python tracker
<http://bugs.python.org/issu
Changes by Nick Coghlan :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue12874>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
Better titles for the proposed new sections:
4.7 Text Data - str
4.8 Binary Data - bytes, bytearray, memoryview
--
___
Python tracker
<http://bugs.python.org/issue12
Nick Coghlan added the comment:
Putting the new sections on tier 2 makes a big difference in discoverability,
since that's the lowest level the main ToC page shows. Perhaps just including
the phrase "Sequence Type" in the new section titles would provide enough
logical group
Nick Coghlan added the comment:
'Sequence Types - list, tuple, str, bytes, etc' *might* work, but I think part
of the problem is that str's brevity is actually a downside in this case. I
know I missed it when I was scanning the ToC earlier (I wanted to check if the
internal U
Nick Coghlan added the comment:
Bringing a suggestion over from #12874, I think it may be worth splitting the
current "Sequence Types" section into 3 pieces that all appear in the top level
table of contents for the library reference:
4.6 Sequence Types - list, tuple, range
4.7 Tex
Nick Coghlan added the comment:
I tend to be fairly paranoid about operating systems doing occasionally bizarre
things, so I like having clearly defined behaviour even when the OS does
something arguably nuts, but permitted by the relevant standard. Hence I think
keeping the check is the
Nick Coghlan added the comment:
I quite like the last idea. Something like:
_PyEval_SuspendOtherThreads(PyThreadState *tstate, PyThread_lock_type lock);
All threads other than tstate will be prevented from executing further
interpreter bytecodes until "lock" is released.
Offerin
Nick Coghlan added the comment:
Regenerated the get_opinfo patch against current 3.3 tip.
Still haven't fixed the missing doc updates mentioned in my last message,
though.
--
Added file:
http://bugs.python.org/file23095/issue11816_get_opinfo_branch_20110904
Nick Coghlan added the comment:
Uploaded a patch that should be complete. Note that my pep380 branch is based
on my get_opinfo branch (see #11816), so if you're applying patches manually
rather than updating directly from my sandbox with hg, you'll need to apply the
latest patch f
Nick Coghlan added the comment:
Actually, not assigning to Raymond for review yet, after all - I just noticed
there are some of Benjamin's review comments relating to cosmetic details
rather than functionality that I still need to address.
I'll kick it in Raymond's direction
Nick Coghlan added the comment:
Do we really want to enshrine shadowing the encodings module as the one true
way to do this kind of thing?
Although I guess defining a way to do it properly would be a fairly major
undertaking, so perhaps blessing the encodings hack is the practical way
Nick Coghlan added the comment:
If Bill gets a chance to investigate this before the weekend, great, otherwise
my plan to stop making noise in the buildbot results will be to:
1. Create a separate issue specifically for the errors reported by the Mac OS X
buildbots (allowing the problem to
New submission from Nick Coghlan :
Several of the new socket tests introduced in #6560 are failing on the Mac OS X
buildbots. These appear to be due to platform problems rather than anything in
the test suite or the new sendmsg/recvmsg code, but it would be good if a
developer on Mac OS X
Nick Coghlan added the comment:
Closing the feature request as complete. The remaining Mac OS X buildbot issues
now have their own tracker item: #12958
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> test_socket fai
Nick Coghlan added the comment:
First attempt didn't quite work - the FD passing tests somehow seem to be
reporting both 'ERROR' *and* 'expected failure', which is causing the test
overall to remain red.
http://www.python.org/dev/buildbot/all/builders/AMD64%20Sn
Nick Coghlan added the comment:
Ah, I believe I see why the expected failure isn't working properly - the
failing testFDPass* tests are causing the subsequent tear down code to also
fail.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue9567>
___
___
Python-bugs-list mai
Nick Coghlan added the comment:
python-dev thread:
http://mail.python.org/pipermail/python-dev/2010-August/102988.html
--
___
Python tracker
<http://bugs.python.org/issue9
Changes by Nick Coghlan :
--
title: Add attribute pointing to wrapped function to partial objects -> Add
attribute pointing to wrapped function in functools.update_wrapper
___
Python tracker
<http://bugs.python.org/iss
Nick Coghlan added the comment:
Have we had any luck getting this to play nicely with the buildbots yet? (I
lost track of where the last checkin got to). The necessary Modules/Setup
change to adjust when _collections is built should have propagated through by
now
Nick Coghlan added the comment:
Note that the following sequence should work even without changing the buildbot
behaviour:
- in one checkin, modify Modules/Setup.dist. The buildbots will pick up this
change on their *subsequent* build (as the build triggered by this checkin, so
long as it
Changes by Nick Coghlan :
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/issue9567>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue9573>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
As we move more and more infrastructure into Python code, we're going to see
this pattern (i.e. a bootstrap module underlying the real module) more and more
often (e.g. I seem to recall Brett has to do something similar when playing
with the pure P
Nick Coghlan added the comment:
On Sun, Aug 15, 2010 at 6:44 PM, Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> Re msg113792: Nick, running the clean step before configure is not possible.
> It requires a Makefile, which isn't there yet.
Ah, of cours
Nick Coghlan added the comment:
Added Greg to nosy list as the one that fixed issue 7242 with the current
_PyImport_ReInitLock semantics.
Also kicking over to Barry regarding implications for 2.6.6 (this is a
regression from 2.6.4 due to the resolution of 7242).
7242 was about forking from
Nick Coghlan added the comment:
One slight tweak to that suggested change - the lock reinitialisation needs to
acquire the new lock in the first branch.
--
___
Python tracker
<http://bugs.python.org/issue9
Nick Coghlan added the comment:
Minimal patch attached (no niceties like NEWS or unit tests included yet)
--
keywords: +patch
Added file: http://bugs.python.org/file18551/issue9573_fork_on_import.diff
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
Test script attached that demonstrates the underlying problem directly via
imp.lock_held() (this could easily form the basis of a unit test)
--
Added file: http://bugs.python.org/file18552/fork_on_import.py
Nick Coghlan added the comment:
Implemented in r84132
--
stage: unit test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Nick Coghlan added the comment:
Implemented in r84132 (not based on this patch though).
--
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Nick Coghlan added the comment:
Implemented in r84133
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
Final name was dis.code_info() and it accepts functions, methods, code objects
and source strings.
--
___
Python tracker
<http://bugs.python.org/issue9
Nick Coghlan added the comment:
I changed the test to a regex match that ignores the specific ID value of the
nested function in r84137. That should make the buildbots happier.
--
___
Python tracker
<http://bugs.python.org/issue9
Nick Coghlan added the comment:
Switching to a regex match made the backslashes in windows paths a problem.
r84139 changes the test to just ignore all the variable info in the code_info
results so we'll see how that goes.
--
___
Python tr
Nick Coghlan added the comment:
Implemented in r84140.
Leaving issue open until the buildbots give it a clean bill of health (since
the command line tests can be a little quirky when it comes to cross platform
differences)
--
resolution: -> accepted
stage: unit test nee
Nick Coghlan added the comment:
The windows buildbot still doesn't appear to be particularly happy, but this
issue also doesn't appear to be the culprit anymore.
--
status: open -> closed
___
Python tracker
<http://bugs.pyth
New submission from Nick Coghlan :
Watching the Windows buildbot to check if test_dis was working yet, I found
this output:
http://www.python.org/dev/buildbot/stable/builders/x86%20XP-4%203.x/builds/2774/steps/test/logs/stdio
It appears something still had files open in the directory when
Nick Coghlan added the comment:
The ref count over 1 million at the end of that output is also rather
suspicious.
--
___
Python tracker
<http://bugs.python.org/issue9
Nick Coghlan added the comment:
Reading through the other issue, I think you're right. Closing as a duplicate
of issue 7443.
--
resolution: -> duplicate
status: open -> closed
superseder: -> test.support.unlink issue on Wi
Nick Coghlan added the comment:
I closed issue 9627 as a duplicate of this - the buildbot failure referenced
there was most likely due to something else holding open a temporary file that
the test suite thought was closed.
--
nosy: +ncoghlan
Nick Coghlan 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 thread ID may not
Nick Coghlan 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
is correct.
It
Nick Coghlan 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 a con
Nick Coghlan 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
Nick Coghlan 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 ap
Nick Coghlan 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.
Nick Coghlan 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 imported vi
Nick Coghlan 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()) and self.assertFalse(t2
Nick Coghlan added the comment:
Both good points - don't worry about it then. +1 to add to the test suite as-is.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue1868>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nick Coghlan :
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 extension mo
Nick Coghlan 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
<http://bugs.python.org/issue8
New submission from Nick Coghlan :
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 of the PyStri
Changes by Nick Coghlan :
--
assignee: -> d...@python
nosy: +d...@python
___
Python tracker
<http://bugs.python.org/issue9755>
___
___
Python-bugs-list mai
Nick Dowell added the comment:
We've just noticed this same problem with Python 3.1.2 on Mac OS X.
The problem is that the program source in the configure script has extraneous
'[' and ']' characters in it, causing compilation to fail.
Excerpt of configure from lin
Changes by Nick Dowell :
--
keywords: +patch
Added file: http://bugs.python.org/file18736/8746-3.1.2.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Nick Dowell :
Added file: http://bugs.python.org/file18737/8746-2.7.patch
___
Python tracker
<http://bugs.python.org/issue8746>
___
___
Python-bugs-list mailin
Changes by Nick Dowell :
Added file: http://bugs.python.org/file18738/8746-2.6.6.patch
___
Python tracker
<http://bugs.python.org/issue8746>
___
___
Python-bugs-list m
New submission from Nick Coghlan :
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
getbuffer() for direct
Nick Coghlan 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 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 the object owning
Changes by Nick Coghlan :
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9789>
___
___
Python-bugs-list
Changes by Nick Coghlan :
--
superseder: -> Add context manager protocol to memoryviews
___
Python tracker
<http://bugs.python.org/issue9789>
___
___
Python-
Nick Coghlan 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 for mutable objects that
Nick Coghlan 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
Nick Coghlan 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 the buffer re
Nick Coghlan 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 b
Nick Coghlan added the comment:
Sounds good - I'd say just commit whenever you're happy with it then.
--
___
Python tracker
<http://bugs.python.
Nick Dowell added the comment:
Why should it only be available on OS X if built with MACOSX_DEPLOYMENT_TARGET
of 10.5 or higher?
chflags() should be available in earlier versions of the OS:
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/10.3/man2/chflags.2.html
Nick Coghlan 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 the rel
Changes by Nick Coghlan :
--
title: cgi handling of POSTed files is broken -> urlparse
___
Python tracker
<http://bugs.python.org/issue8077>
___
___
Python-
New submission from Nick Coghlan :
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 :
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 provid
Nick Coghlan 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 the encod
Nick Coghlan 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 occurs even
Nick Coghlan 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
persistent inside the
Nick Coghlan 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 with the current API is that
Nick Coghlan 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 to the ca
Nick Coghlan 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 ASCII
compatible
Nick Coghlan added the comment:
On Tue, Sep 21, 2010 at 2:39 PM, Swapnil Talekar wrote:
> Swapnil Talekar added the comment:
> Nick, the last statement,
> "While this is correct for most purposes, it does mean that..."
> can be simplified to,
> "It means..."
Nick Coghlan 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 runpy.run_module t
Nick Coghlan 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 - patch looks
Nick Coghlan 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 and Peace a
Nick Coghlan 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 of boilerplate to s
Nick Coghlan 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 the correc
Nick Coghlan 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
<
Nick Coghlan 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 the way
Nick Coghlan 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 tokenis
Nick Coghlan added the comment:
Added to Reitveld: http://codereview.appspot.com/2318041/
--
___
Python tracker
<http://bugs.python.org/issue9873>
___
___
Pytho
Nick Coghlan 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&#
Nick Coghlan 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
Nick Coghlan 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 var
401 - 500 of 6501 matches
Mail list logo
