New submission from Larry Hastings:
5e73bb72662e
--
assignee: larry
components: Library (Lib)
messages: 211817
nosy: larry
priority: release blocker
severity: normal
status: open
title: 3.4 cherry-pick: 5e73bb72662e pydoc shouldn't display "self" for bound
methods
versi
Changes by Larry Hastings :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Larry Hastings :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20716>
___
___
Python-bugs-list
Larry Hastings added the comment:
I just put the third preview up. There are no diffs between that asyncio and
the one in default.
Is this torrent coming to a close? We really should keep the changes from rc2
to final to a bare minimum
Larry Hastings added the comment:
ok
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20721>
___
___
Pyth
Larry Hastings added the comment:
Okay, I'm accepting this. I really just wanted to get more eyes on it, and I'm
happy to see that python-dev was pretty unanimous.
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
Stefan: does the checkin in d6aa3fa646e2 fix your problem? I'm willing to
cherry-pick for this but I'd prefer to only have to do it once.
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
I'm waiting to hear back from scoder about whether or not this really fixes his
problem before I cherry-pick. I'm still willing to do it for tagging for rc2
(about 20 hours from now) if I can hear back during that time.
--
nos
Changes by Larry Hastings :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20679>
___
___
Python-bugs-list
Larry Hastings added the comment:
ok.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20715>
___
___
Pyth
Larry Hastings added the comment:
I reconsidered, and the sense I get is "yeah it fixes the problem". And even
if it didn't, I'd wind up cherry-picking it anyway just to make the diffs
easier. So I'm accepting this.
--
resolution: ->
Larry Hastings added the comment:
Can I close this issue now?
--
___
Python tracker
<http://bugs.python.org/issue20648>
___
___
Python-bugs-list mailing list
Unsub
Larry Hastings added the comment:
ok.
--
___
Python tracker
<http://bugs.python.org/issue20734>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Larry Hastings :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20734>
___
___
Python-bugs-list
Larry Hastings added the comment:
This issue is okay, but it helps my workflow if you'd create a new "3.4
cherry-pick" revision for me when it's ready.
--
___
Python tracker
<http://bug
Larry Hastings added the comment:
I'll cherry-pick 8f54f601fd75.
--
___
Python tracker
<http://bugs.python.org/issue20199>
___
___
Python-bugs-list m
Larry Hastings added the comment:
ok.
--
___
Python tracker
<http://bugs.python.org/issue20738>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Larry Hastings :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20738>
___
___
Python-bugs-list
Larry Hastings added the comment:
My understanding is, this is fixed, and cherry-picked into 3.4. If that's in
error please reopen.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Larry Hastings added the comment:
My understanding is this is now done. If it isn't please reopen.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
New submission from Larry Hastings:
Lib/tests/test_robotparser.py uses the following url:
http://mueblesmoraleda.com/robots.txt
That file now serves a 404.
This should be disabled for 3.4, and the test rewritten for 3.5. If we get a
patch quickly I would probably cherry-pick it for 3.4
Changes by Larry Hastings :
--
title: disable test_robotparser -> disable test_robotparser test that uses an
invalid URL
___
Python tracker
<http://bugs.python.org/issu
Larry Hastings added the comment:
Doc changes are fine basically anytime, but I don't want low-priority changes
in Lib for 3.4.0. But this would be fine for 3.4.1 if you like, or you could
just wait for 3.5.
--
___
Python tracker
Larry Hastings added the comment:
The patch attached to this issue has changes to Lib/test/test_itertools.py.
--
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
It's fine that we're not fixing this in 3.3, but since this did get fixed in
3.4, I propose dropping 3.3 from the version list and changing the resolution
to "fixed".
*waves magic wand*
--
resolution: wont fix -> fixed
stage: n
Changes by Larry Hastings :
--
nosy: -larry
___
Python tracker
<http://bugs.python.org/issue20778>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
> Barring c++, are we using any C compilers that don't support inlines?
CPython advertises itself as C89 compliant, and C89 doesn't have inlines. You
need to go to C99 to get inlines.
And before you ask--yes, we support a compiler that is not
Larry Hastings added the comment:
I'm pretty sure that if you import "x", there are zero guarantees that "x.y"
will work. The offical line is that you must explicitly import all the deepest
submodules you use. So I don&#
Larry Hastings added the comment:
> So, it's a very common idiom.
"Common" doesn't imply "correct" or "supported". There are plenty of other
packages/modules who don't import their subpackages/submodules during
initialization. Unless expli
Larry Hastings added the comment:
Why can't you remove the "= NULL" from the Clinic input for "string"?
--
___
Python tracker
<http:
Larry Hastings added the comment:
Why can't you build the docs on your system? "make html" works for me every
time--it even downloads the packages it needs.
--
___
Python tracker
<http://bugs.pyt
Larry Hastings added the comment:
ok.
--
___
Python tracker
<http://bugs.python.org/issue20807>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
So you're asking that I cherry pick six revisions here?
6a1711c96fa6
fa160c8145e5
efaf12106d68
7ecee9e0dc58
10ea3125d7b8
488ccbee6ee6
--
___
Python tracker
<http://bugs.python.org/is
Changes by Larry Hastings :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20807>
___
___
Python-bugs-list
Larry Hastings added the comment:
ok.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20831>
___
___
Pyth
Larry Hastings added the comment:
ok.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20832>
___
___
Pyth
Larry Hastings added the comment:
ok.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20829>
___
___
Pyth
Larry Hastings added the comment:
ok. I agree it's not critical, but on the other hand it's low-risk.
--
___
Python tracker
<http://bugs.python.o
Changes by Larry Hastings :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20834>
___
___
Python-bugs-list
Larry Hastings added the comment:
According to #19021, this actually requires six revisions:
6a1711c96fa6
fa160c8145e5
efaf12106d68
7ecee9e0dc58
10ea3125d7b8
488ccbee6ee6
Is that correct?
--
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
ok.
(I thought the change to not-automatically-getting-sphinx was deferred?)
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Larry Hastings added the comment:
ok.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20843>
___
___
Pyth
Larry Hastings added the comment:
ok.
--
nosy: +larry
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20850>
___
__
Changes by Larry Hastings :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20830>
___
___
Python-bugs-list
Larry Hastings added the comment:
ok. And, my cherry-picking automation will automatically sort the revisions by
original checkin order.
--
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
ok.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20818>
___
___
Pyth
Larry Hastings added the comment:
ok.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20789>
___
___
Pyth
Larry Hastings added the comment:
What do you want me to do? Hold off while you determine the correct set of
changes, or proceed with these six?
(p.s. rebasing = headache, so having the right set of changes up front would be
super-swell
Larry Hastings added the comment:
Those six revisions have been cherry-picked into 3.4.0.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Larry Hastings added the comment:
ok.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20808>
___
___
Pyth
Larry Hastings added the comment:
Antoine: As the patch matured I would obviously provide documentation
and examples and such. The point of submitting the patch in this form
was a) so it was alive somewhere besides my hard drive, and b) to get
some public review from the core team to ensure I
Larry Hastings added the comment:
Whoops! I think I'll finish that unfinished sentence.
"The patch attempts to mitigate this as much as possible with the
backwards-compatibility"
header file; it minimizes as much as possible the changes you need to
perform to get your code
New submission from Larry Hastings :
The documentation for platform.python_version_tuple() says:
"Returns the Python version as tuple (major, minor, patchlevel) of strings."
In 2.4 and 2.5 it correctly returned a tuple of strings. In 2.6 it
returns a tuple of ints.
In 2.4 a
Larry Hastings added the comment:
I'm not saying that killing a two-year-old DOA patch is the wrong
move--though I hold out hope that lazy string concatenation in CPython
will yet happen. But you shouldn't kill this patch just because you
think it has something to do with "st
Larry Hastings added the comment:
rhettinger: It's a bit unfair to paint the lazy string concatenation
patch with the adjective "ropes", then point out ropes have been
rejected many times. Lazy string concatenation objects are a form of
specialized rope but they don't sh
Larry Hastings added the comment:
Thanks for pointing that out! I think I found it; the discussion is
actually about lazy string slices, and it starts here:
http://mail.python.org/pipermail/python-dev/2000-February/002317.html
If I were to resubmit lazy string slices (which wouldn't be in
New submission from Larry Hastings :
The CObject API has two flaws.
First, there is no usable type safety mechanism. You can store a void
*object, and a void *description. There is no established schema for
the description; it could be an integer cast to a pointer, or it could
point to memory
Larry Hastings added the comment:
dalcinl:
I made the destructor the first argument because APIs where arguments
move around irritate me. In the existing CObject API, the destructor is
"always" the last argument--which means in practice it is either the
second or third argument, de
Larry Hastings added the comment:
Sorry, in editing I forgot to finish my sentence. In the middle of the
second paragraph, the sentence should read:
But 90% of the time all you'll need is PyCObject_FromVoidPtr().
My other editing mistakes will just have to
Larry Hastings added the comment:
Having slept on it, I agree that we only need one API to create an
object. Since passing in a "context" will be relatively rare, users who
need that can use PyCObject_SetContext(). I'll remove
PyCObject_FromVoidPtrWithContext() i
New submission from Larry Hastings :
"make clean" fails in my tree. There's an inscrutable new directory,
"@test", which is chmod 400, and therefore "find" isn't allowed to
descend into it, so it fails and aborts the clean early. I don't know
what
Larry Hastings added the comment:
I discussed this off-list with GvR. He was primarily concerned with
fixing the passing-around-a-vtable C API usage of CObject, but he wanted
to preserve as much backwards compatibility as possible. In the end, he
suggested I create a new API and leave CObject
New submission from Larry Hastings :
Two minor tweaks to unicode_repeat:
* If the number of repeats (len) is < 1, we're always going to return
the empty Unicode string. So I incr and return unicode_empty.
* The current code has "if (done < nchars)" around the first copy
Larry Hastings added the comment:
So what's the fix? I upgraded to r71304 and it still does this. Worse,
it adds all sorts of complaints to "make test"--and it actually slows
down hg. (hg can't cd into that directory, so it gives up on creating
its inotify socket.) Can
Larry Hastings added the comment:
% rm -rf @test
rm: cannot remove `...@test': Permission denied
And, before you helpfully chime in with "chmod", yes I know how to run
that too.
I stuck in and figured it out. The bug: "test_on_error" in
"test_shutil" is
Larry Hastings added the comment:
Crapdoodles, I didn't update the patch to get the "regrtest" change I
threw in at the last minute. Please see the "v2" patch.
--
Added file: http://bugs.python.org/file13640/lch.t
Larry Hastings added the comment:
The analysis I wrote on 2009/4/6 is correct, but I just discovered
another important detail: it only happens on my ZFS partition. I'm
using ZFS on Linux, via FUSE. No wonder I'm the only person it's
happening to! I don't know whether it&
Larry Hastings added the comment:
I should be more specific: patch was written against py3k/trunk r71404.
Though I imagine a very similar patch could be written for 2.7 (or 2.6
if appropriate).
--
___
Python tracker
<http://bugs.python.
Larry Hastings added the comment:
Done and done. I also changed cleanup_test_droppings() in
Lib/test/regrtest.py; it now chmods the, uh, droppings before it
attempts their removal.
--
Added file: http://bugs.python.org/file13699/lch.test_shutil.r71641.diff
Larry Hastings added the comment:
I've updated the patch:
* Capsule now has a custom repr that includes whatever name is set.
* I've updated the documentation to talk about Capsules and not
CObjects; the documentation discusses naming your capsules.
* PyCapsule_Import now takes a
Larry Hastings added the comment:
Whoopsie-daisy, I forgot to touch up a whole lot of places to match the
new API. Attached is an updated patch; here's what changed:
* The documentation is now much better; there is a capsule.rst, and
cobject.rst has a deprecation warning.
* Added a deprec
New submission from Larry Hastings :
This patch changes "ntpath" so all functions handle UNC paths.
In a Windows path string, a UNC path functions *exactly* like a drive
letter. This patch means that the Python path split/join functions
treats them as if they were.
Fo
New submission from Larry Hastings :
Makefile.pre.in as checked in has several small bugs:
First, the altbininstall target runs "ln -s" without first ensuring the
destination doesn't exist. If you run "make install" twice, without
manually deleting $prefix/bin/python3
Larry Hastings added the comment:
Minor correction for the "First" bug mentioned: altbininstall is running
"ln", not "ln -s".
--
___
Python tracker
<
New submission from Larry Hastings :
The attached patch adds support for a new environment variable,
PYTHONPREFIXES. PYTHONPREFIXES is similar to PYTHONUSERBASE: it lets
you add "prefix directories" to be culled for site packages. It differs
from PYTHONUSERBASE in three ways:
* PYTH
Larry Hastings added the comment:
Whoops, didn't classify the patch before submission.
--
components: +Library (Lib)
type: -> feature request
versions: +Python 3.1
___
Python tracker
<http://bugs.python.or
Larry Hastings added the comment:
Thanks for your battle-tested feedback, Mr. Bicking! I reply inline.
> The biggest problem is that the environmental variable is inherited by
> subprocesses. [...] Another problem is that scripts aren't really
> sticky with respect to t
New submission from Larry Hastings :
EXECUTIVE SUMMARY
I've written a patch against py3k trunk creating a new function-based
API for creating extension types in C. This allows PyTypeObject to
become a (mostly) private structure.
THE PROBLEM
Here's how you create an extension type
New submission from Larry Hastings :
PyGetSetDef has a "void *context" field. This field is passed in to the
get and set functions implementing the property. The field is almost
never used, so it adds unnecessary complexity. Clearly, YAGNI.
There are two places in CPython where i
Larry Hastings added the comment:
Whoops, forgot to categorize the issue before submitting it.
--
components: +Interpreter Core
type: -> feature request
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/iss
New submission from Larry Hastings :
While hacking on CPython I noticed a couple of attributes that were
there strictly for backwards compatibility with ancient modules or pure
mistakes. They are:
_hashlib.hash.digestsize
pwd.struct_pwent
_sha224.digestsize
_sha256.digestsize
_sha384
Larry Hastings added the comment:
Ping? Is the fate of this patch waiting on anything I can help with?
In case it helps you decide, you don't see this behavior on a ZFS
partition on Mac OS X. It appears to only happen under FUSE. So it's
just me and my computers. (And
Larry Hastings added the comment:
Added a test case for capsules to _testcapimodule.c, and updated to the
latest trunk.
--
title: Create alternatieve CObject API that is safe and clean -> Create
alternative CObject API that is safe and clean
Added file: http://bugs.python.
Larry Hastings added the comment:
I've generated a new patch, attached. I don't know why you had trouble
applying. I tested this one with a clean tree and "patch -p1 < ..." and
it applied cleanly. If it fails again, how about I upload the three
modified files?
I
Larry Hastings added the comment:
Updated patch based on impressively thorough Rietveld feedback from
Benjamin Peterson. Thanks, Benjamin!
This patch should not be considered final; we already know the API
documentation in the comments in Include/pycapsule.h needs to change
(somehow
Larry Hastings added the comment:
Mark Dickinson: no extension module would ever *need* it. One could
reproduce the functionality with stub intermediary functions, as follows:
PyObject *my_getter_with_context(PyObject *self, void *context) {
/* ... /
}
PyObject *my_getter_A(PyObject *self
Larry Hastings added the comment:
Oh, and, I looked at pyephem. It uses the context field to... store an
integer. In this case, the offset in a structure where it's going to
pull out a value (float or double). This code would probably be clearer
if forced to make do without the &qu
Larry Hastings added the comment:
Sweet jumping rhubarb! I didn't know about this "for ...: else:"
construct in Python. When I was editing it I thought it was my editor
stumbling over a tab, and the "else" went with the "if" *inside* the
"for".
Larry Hastings added the comment:
As promised, a fresh patch. Note that the current formulation of that
troublesome loop in relpath() is *very* much on purpose. The removal of
the "else" is no longer a bug :)
--
Added file: http://bugs.python.org/file13890/lch.ntpath.r
Larry Hastings added the comment:
Sorry for the quick double-patch, but I realized that there was no test
for the obverse case, where "path" is / and "curdir" is non-empty. So I
threw in some more tests.
--
Added file: http://bugs.python.org/file13891/lch.
Larry Hastings added the comment:
I stared at it some more. Now I understand what "for ... : else:" was
for in the original. The "else: i += 1" ensures that if the "for" loop
runs to completion "i" is set to the length of the shorter of the t
Larry Hastings added the comment:
dalcinl: Thanks, I've fixed the doc wrt writing "int" where I meant
"void *".
As for using "disambiguate" in many places: there are a couple of
sentences that are repeated in the documentation for several functions.
Those re
New submission from Larry Hastings :
The changes in PEP 3123 require that all type objects be statically
declared with PyVarObject_HEAD_INIT. However, the Noddy examples in
Doc/ still use PyObject_HEAD_INIT.
--
assignee: georg.brandl
components: Documentation
messages: 87214
nosy
New submission from Larry Hastings :
If my patch in issue 53046 is accepted, I hereby agree to figure out if
the calls to PyCapsule_GetPointer() in Modules/_ctypes/callproc.c need
more error checking or what.
--
components: Interpreter Core
messages: 87215
nosy: benjamin.peterson, larry
Larry Hastings added the comment:
Whoops, I thought PEP 3123 applied to 2.7 as well. PEP *3*123. Duh, me
slow today.
--
versions: -Python 2.7
___
Python tracker
<http://bugs.python.org/issue5
Larry Hastings added the comment:
A nice fresh patch, against r72309. Incorporates changes based on
Benjamin's latest batch of Rietveld comments. They're thinning out, so
we must be near the end--and with a day to spare. Also strips out
almost-all documentation from "pyca
Larry Hastings added the comment:
Whoops, yeah, that was me forgetting that in py3k itertools.izip became
just "zip". I'll remove it in my branch in case I generate another patch.
--
___
Python tracker
<http://bugs.py
Larry Hastings added the comment:
Just 'cause I like you, here's an updated patch. The only change is the
removal of "import itertools" and the update of the base version.
--
Added file: http://bugs.python.org/file13896/lc
Larry Hastings added the comment:
I've never understood what is the "philosophical problem" per se. It's
clear from his implementation--Guido created "splitunc" when he removed
my patch--that he thinks these should be precise string operations.
Whereas I propos
New submission from Larry Hastings :
In the comments for the Capsule patch:
http://bugs.python.org/issue5630
dalcinl correctly pointed out that I had misspelled "disambiguate",
which I missed. This patch fixes that mistake.
--
assignee: georg.brandl
components: Documenta
1701 - 1800 of 2415 matches
Mail list logo
