Nick Coghlan added the comment:
Once again got close to committing this, but then realised it is missing all
the necessary documentation updates for a core language change.
I have uploaded a patch that includes all the changes from Bitbucket as well as
the subsequent fixes to avoid modifying
Nick Coghlan added the comment:
This API has changed around a bit in 3.x, so it is actually
inspect.getfullargspec that needs to change (getargspec will inherit the new
behaviour though, since it uses getfullargspec internally)
With appropriate docs and tests updates, I don't see a pr
Nick Coghlan added the comment:
I moved my personal sandbox from hg.python.org to bitbucket, so it should be
easier for folks to build off the work in progress. (And fixed the typo in
Renaud's name - I at least had it right in ACKS. I also reworded the draft
attribution text in What&
Nick Coghlan added the comment:
Nice, I didn't know we have those comprehensive using docs. However, they
should be linked from http://docs.python.org/dev/tutorial/interpreter.html
(definitely inline and perhaps a see also).
--
___
Python tr
Nick Coghlan added the comment:
The ordering is as it is so that the last line in the displayed traceback
corresponds to the exception that was actually caught. That is, the last line
remains the same regardless of whether or not there was an earlier exception in
the chain. Without that, the
Nick Coghlan added the comment:
The redundancy of the "(most recent call last)" when there's only one frame in
the stack is a separate problem (as it happens even for unchained tracebacks),
but feel free to create a new issue if you'd like to see it changed (I expect
Nick Coghlan added the comment:
+1 for a new exception type to indicate "this may technically be legal Python,
but this Python implementation cannot handle it correctly"
Whatever exception type we add, it would be nice to also be able to use it if
someone eventually fixes th
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue10271>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
On Sat, Jul 16, 2011 at 8:24 PM, Martin v. Löwis wrote:
>> sys.version_info and sys._mercurial provide all the info needed for someone
>> (like me for mnfy)
>
> Can you please elaborate? How do you know from looking at
> sys._mercurial wh
Nick Coghlan added the comment:
NotImplemented is a speed and maintainability hack - the runtime cost and
additional code complexity involved in doing the same operator signalling via
exceptions would be prohibitive (check Objects/abstract.c in the CPython source
if you want the gory details
Nick Coghlan added the comment:
Also, a note regarding efficiency: as it calls the underlying methods directly
and avoids recursing through the full operand coercion machinery, I would
actually expect this approach to run faster than the current implementation
Nick Coghlan added the comment:
It's important to remember that other implementations treat CPython as
the "gold standard" for compatibility purposes. If we declare
something to be an ordinary SyntaxError, then that carries strong
implications for what other implementations s
Nick Coghlan added the comment:
It also makes it clear to users whether they've just run up against a
limitation of the implementation they're using or whether what they've
written is genuinely illegal code. They are NOT the same thing.
Attempting to conflate them into one ex
Nick Coghlan added the comment:
It matters, because Python "users" are programmers, and most
programmers want to know *why* they're being told something is wrong.
Raising MemoryError is technically incorrect at this point, but at
least gives the right flavour of the user not
Nick Coghlan added the comment:
After further reflection, I (eventually) came to the same conclusion as
Benjamin and Antoine - using SyntaxError for this is fine.
However, the exception *message* should make it clear that this is an
implementation limit rather than a language limit
Nick Coghlan added the comment:
Yeah, at the level of *code* the origin doesn't really matter, so re-using the
exception type is actually OK. However, for *people* seeing the stack trace, it
may be useful to know what's genuinely illegal syntax and what's a limitation
Nick Coghlan added the comment:
Load time parameterisation seems more of a worthwhile addition to me, too. As
David noted, runtime parameterisation is pretty easy to do by looping and
consolidating failures into the one error message via self.fail().
For test naming, trying to get too clever
Changes by Nick Coghlan :
--
nosy: +brett.cannon, ncoghlan
___
Python tracker
<http://bugs.python.org/issue12598>
___
___
Python-bugs-list mailing list
Unsub
New submission from Nick Coghlan :
Problems noted by PJE on import-sig:
For example, PathFinder's find_module treats an empty path the same as
sys.path, and will also fail if for some reason the bool() of a PEP 302 finder
or loader object is False.
Nick Coghlan added the comment:
Here's a sketch for a possible decorator factory:
def parameters(params, *, builder=_default_param_builder):
def make_parameterized_test(f):
return ParameterizedTest(f, params, builder)
return make_parameterized_test
(default builder wou
New submission from Nick Coghlan :
General untidiness in the anchor names (and lack of same for entries like
Changes by Nick Coghlan :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Nick Coghlan added the comment:
Should also be an outgoing link to http://bugs.python.org/issue1739468
from the
Changes by Nick Coghlan :
--
Removed message: http://bugs.python.org/msg140819
___
Python tracker
<http://bugs.python.org/issue7897>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
Sorry, misclicked and removed this comment from David:
Oh, I see. Make the name the first element of the argtuple and then strip it
off. Well, that will work, it just seems bass-ackwards to me :)
And why is it 'case'? I thought we were talking a
Nick Coghlan added the comment:
In my example, I needed a word to cover each entry in the collection of
parameter tuples. 'case' fit the bill.
The reason I like the builder approach is that it means the simplest usage is
to just create a list (or other iterable) of parameter tu
Nick Coghlan added the comment:
The best solution is to modify the offending code to use real docstrings.
Failing that, a simple explicit "'\n'.join(line.lstrip('#' for line in
comment.split('\n'))" (i.e. not as part of pydoc) will handle most cases.
A
Nick Coghlan added the comment:
It's rare to receive fixes from Windows users that don't have a dev environment
set up (i.e. they just edited their stdlib code in place, or copied it and
created a modified version). Thanks for persisting in the face of invalid
assumptions o
Nick Coghlan added the comment:
+1 for making this limitation explicit. See the caveat on locals() [1] for an
example of how to note this kind of restriction.
[1] http://docs.python.org/dev/library/functions.html#locals
--
___
Python tracker
Nick Coghlan added the comment:
Compare however the behaviour of bytes() and bytearray() which support direct
zero initialisation of a region of memory by passing an integer to their
constructor.
--
nosy: +ncoghlan
___
Python tracker
<h
Nick Coghlan added the comment:
I agree with Antoine - it's a simple bug introduced by the attempt to allow
temporary directories to be correctly cleaned up during interpreter shutdown.
The race condition due to the usage of LBYL is shared with the full
shutil.rmtree implementation, s
Nick Coghlan added the comment:
See also #1559549, which similarly adds attribute support to ImportError and
covers some of the issues with using positional arguments to do so.
Extending that approach to a path keyword argument as well should work nicely
Nick Coghlan added the comment:
Indeed it is, although we think actually doing that is a bad idea (as discussed
earlier on this tracker item).
See the 3.1 docs for the recommended workaround for the removal (basically grab
a copy of the 3.1 code and drop it into your own utility module
Nick Coghlan added the comment:
It's actually the documentation that's slightly wrong in this case. On Windows,
there is an additional import mechanism based on the Windows registry that is
checked before the ordinary sys.path mechanism. (See
http://docs.python.org/libra
Nick Coghlan added the comment:
Barry convinced me that the test.support docs need to stay in the same repo as
the code they document, so -1 from me as well.
Changed issue title to reflect the real problem that inspired this suggestion
(i.e. test.support.unlink et al appearing in the docs
Nick Coghlan added the comment:
The Windows build actually uses the registry to locate the standard library
rather than sys.path. This is by design, but isn't really documented properly.
It means that code on sys.path (even in the current directory) won't shadow
standard library
Nick Coghlan added the comment:
As far as I know, not as a top-level module in an installed version of Python
(at least, not without mucking about in the registry).
Shadowing standard library modules is generally a bad idea, and this is one of
the reasons
Nick Coghlan added the comment:
I'd assigned this to myself since I was discussing it with Brandon when he was
working on it at the PyCon sprints. Since I certainly don't want to block
anyone else getting to it, I'm unassigning it - feel free to take it forward :)
IIRC, the
Nick Coghlan added the comment:
I'd say the main reason the dev guide is in a separate repo is the historical
one (i.e. Brett was working on it as a separate repo prior to the hg migration
and we never merged it).
However, the version independent nature of the material is the main arg
Nick Coghlan added the comment:
I'm not sure this is 100% fixed. After dist-upgrading the Kubuntu VM on my
netbook and updating to the latest Py3k code, I got a lot of test errors, even
after a make distclean and ./configure.
The errors went away after manually tweaking LDFLAGS as Chri
Nick Coghlan added the comment:
Added Ned to the nosy list.
For Python core, we should also keep in mind that we do have the option of
adding a -X coverage option to avoid the need for the encodings module hack.
--
nosy: +nedbat
___
Python tracker
Nick Coghlan added the comment:
As Georg noted, only individual expressions get parentheses based continuations
automatically. For statement level use of comma separation, it's decided on a
case-by-cases basis as to whether we think it is a legitimate usage based on
our style guide
Nick Coghlan added the comment:
Tennessee, there were a few issues in the original patch - see the attached
update (mostly the use of assert statements instead of methods and the
overbroad scope of the context manager when checking for an expected exception).
However, in getting ready to
Nick Coghlan added the comment:
For 3.3, it may be relevant that send/recvmsg are now available via the socket
API (see #6560)
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue11
New submission from Nick Coghlan :
Had a weird bug in test_array.test_tofromstring failing on Gentoo by generating
too few warning messages:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/568/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all
Nick Coghlan added the comment:
Someone here at the sprints pointed out a redundant unsigned comparison to 0
that I missed, so a second set of eyes to double-check things like that would
be good.
--
___
Python tracker
<http://bugs.python.
Changes by Nick Coghlan :
--
nosy: -python-dev
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
This is a dupe of #10042
--
resolution: -> duplicate
status: open -> closed
superseder: -> total_ordering
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
Changed stage and resolution to reflect the fact that none of the existing
patches adequately address the problem.
--
resolution: fixed ->
stage: committed/rejected -> needs patch
___
Python tracker
Changes by Nick Coghlan :
--
assignee: rhettinger -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list mailing list
Un
Nick Coghlan added the comment:
Reopening to track buildbot failures (at least on Windows) - at a glance, it
looks like the SSL socket wrapper is still adding (and trying to test) the
send/receivemsg methods even when they're missing from the socket object on the
current pla
Nick Coghlan added the comment:
Attached patch (ssl_fixes_v1) makes the presence of the sendmsg/recvmsg methods
in the ssl module conditional on their being present in the underlying socket
module.
However, in doing this, I noticed that these methods will, at best, work during
the time
Nick Coghlan added the comment:
That's the part I'm questioning though. I'm not clear why you'd ever do that
instead of doing everything on the original socket before invoking
ssl.wrap_socket.
What I missed on the original patch before committing it (mea culpa) is t
Nick Coghlan added the comment:
The buildbots are reporting a test failure on Windows:
==
FAIL: test_listmailcapfiles (test.test_mailcap.HelperFunctionTest
Nick Coghlan added the comment:
As you can see, I just pushed a change that removed the new methods from
SSLSocket objects. If anyone wants to step up with a valid use case (not
already covered by wrap_socket), preferably with a patch to add them back that
includes proper tests and
Nick Coghlan added the comment:
Regarding the 'missing methods' aspect, the SSL docs are already pretty clear
that SSLSocket objects don't expose the full socket API:
http://docs.python.org/dev/library/ssl#ssl-sockets
Those docs are actually what really got me started d
Nick Coghlan added the comment:
And the Windows buildbots are now happy (at least with respect to this change,
anyway - they're still griping about a few other issues).
I don't know if it's feasible to support these new APIs at the socket module
level on Windows, but any patc
Nick Coghlan added the comment:
Ah, cheers - closing this one again.
/me wanders off to meta-tracker to ask for a list of "dependency of" and
"superseder of" issues in the issue header...
--
status: open -> closed
__
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue9923>
___
___
Python-bugs-list mai
Changes by Nick Coghlan :
--
stage: test needed -> patch review
versions: +Python 3.2, Python 3.3 -Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Changes by Nick Coghlan :
Added file: http://bugs.python.org/file23018/7cead6bf5832.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list m
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file23018/7cead6bf5832.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bug
Nick Coghlan added the comment:
The diff generator didn't work - I've uploaded the current patch manually to
make it easier to review than it is in my bitbucket repo.
I just noticed there's a missing element in the docs patch at the moment - to
make testing easier, Rya
Nick Coghlan added the comment:
Casting to a flat 1-D array of bytes is reasonable (it's essentially saying
'look, just give me the raw data, it's on my own head if I stuff up the
formatting').
However, requiring an explicit two-step process for any other casting (i.e.
t
Nick Coghlan added the comment:
As Antoine said, good catch. I'll be able to incorporate this in the next
couple of days.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
301 - 400 of 6301 matches
Mail list logo
