Larry Hastings added the comment:
write_clinic_file tells Clinic to start writing to the clinic file, which I
think is best to do at the very top of the file. include_clinic_file spits out
the #include, which you probably want near the bottom of the file, just before
the static module
New submission from Larry Hastings:
To reproduce:
1) Create a file called "foo.txt" in the local directory, put whatever you like
in it.
2) Run "python -m SimpleHTTPServer" or "python3 -m http.server".
3) Point your web browser at "http://127.0.0.1:8000/foo.
Changes by Larry Hastings :
--
stage: -> test needed
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue17324>
___
___
Python-bugs-list
Larry Hastings added the comment:
Thanks for pointing that out! I've fixed it in my local branch, though I'm
fooling around with some new syntax so I'm not ready to publish it yet.
It's not a general problem, exactly; it's a problem with extension types.
After j
Larry Hastings added the comment:
Modern tar programs don't need to be told the compression method--they infer
it. If they can do it in C, we can do it in Python. So we should simply omit
the "-bz2" stuff.
As for what the interface should look like, I'm definitely in
Larry Hastings added the comment:
Huh. tar *can* infer it from the data itself. On the other hand, it chooses
explicitly not to.
% cat ~/Downloads/Python-3.3.0.tar.bz2| tar xvf -
tar: Archive is compressed. Use -j option
tar: Error is not recoverable: exiting now
% cat ~/Downloads/Python
New submission from Larry Hastings:
The documentation for Inspect.Signature and Inspect.Parameter states that the
objects are immutable. And they go to great lengths to provide a convenient
interface allowing you to "replace" members.
However, the objects make only a pathetic effor
Larry Hastings added the comment:
Yes, it seems I've been living in a fool's paradise, happy and ignorant. I
thought that the behavior of garden-variety "immutable" objects was like tuple,
where the implementor shored up the interface and the saboteur had to work
*really
Larry Hastings added the comment:
For what it's worth, here's what we're doing. The new Argument Clinic
"parameter" line looks a great deal like the middle bit of a Python function
declaration. So much so that we can do this:
ast_string = "def x({}
Larry Hastings added the comment:
For the record: I care. Generally speaking CPython is a lovingly
crafted source tree, and the choices its architects made are nearly
always sensible and well-reasoned. When I see things like this, things
that seem kind of dumb on first glance, I worry that
New submission from Larry Hastings:
CPython API "functions" implemented as macros can expand into either
rvalues or statements. Most expand into statements (often using the
do {} while (0) syntactic sugar trick), but occasionally they're legal
as rvalues.
As of this writing Py_
Larry Hastings added the comment:
> Py_INCREF usable as an rvalue sounds more like an accident
> than a deliberate feature
I'd go with "misfeature", but in no way is it accidental. The coding
deliberately preserves the rvalue-ness of it, c.f
Larry Hastings added the comment:
When an issue is marked as "release blocker", the release managers of all
affected versions are automatically added to the issue. I'm the release
manager of 3.4, Georg is for 3.3.
--
___
Python
Larry Hastings added the comment:
Amaury: I'd appreciate it if you'd bring those examples up on bug 17206. If
we're going to change the semantics of Py_INCREF I'd prefer we did it with our
eyes wide open.
--
___
P
Larry Hastings added the comment:
Oh, and, yes, it's true that Py_RETURN_NONE currently takes advantage of
Py_INCREF being an rvalue, and changing Py_INCREF to a statement would break
the existing implementation. But Py_RETURN_NONE itself is of necessity a
statement. We would simply c
Larry Hastings added the comment:
Oh...! Serhiy, I thought you already checked in the AsIndex stuff. Guess I
was asleep at the switch.
Certainly the patch should go in for trunk. I'd be comfortable with it going
in for 3.3 as a bugfix but that's ultimately Georg's call.
Larry Hastings added the comment:
Okay, I got inspired and (in the words of Barry Warsaw) JFDI. Attached is my
revised patch. I took Serhiy's patch and reworked it quite a bit:
* I think it's now easier to follow. In particular:
* The most common case (no overflow) is now
Larry Hastings added the comment:
See my comment above (dated 2013-04-14 04:30). I'm passing the buck.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Larry Hastings :
Added file: http://bugs.python.org/file29883/larry.chown.unsigned.uid.gid.3.diff
___
Python tracker
<http://bugs.python.org/issue15
Larry Hastings added the comment:
Whoops, forgot to write something here. Updated patch (in previous edit to the
issue) incorporating Serhiy's suggestions from Rietveld.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Can I get an LGTM?
--
___
Python tracker
<http://bugs.python.org/issue15301>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Latest patch incorporating Serihy's comments.
--
Added file: http://bugs.python.org/file29977/larry.chown.unsigned.uid.gid.4.diff
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Whoops, meant to throw in a Fraction too. Added that. Also hoisted the
imports out of the function call, just to be a good guy.
--
Added file: http://bugs.python.org/file29978/larry.chown.unsigned.uid.gid.5.diff
Larry Hastings added the comment:
Serhiy: Oh, I get it, your critique was about the "Note:" part at the bottom.
It would have been helpful if you had inserted your feedback there, instead of
at the top. Yeah, you're right, the note was incorrect.
I considered adding a note
Larry Hastings added the comment:
Patch attached. I don't know how to make fdopendir fail, so I had to do it by
inspection.
While I was in there, I ifdef'd out the variable that should only be used if
fdopendir is available.
--
keywords: +patch
stage: needs patch ->
Larry Hastings added the comment:
I would, but I can't get it to apply cleanly, either to tip or to historical
revisions back in Sepember. Kaleb, what revision is the branch that you
generated the diff from?
--
___
Python tracker
Larry Hastings added the comment:
p.s. Thanks for reviving the patch. I forgot about this one!
--
___
Python tracker
<http://bugs.python.org/issue16024>
___
___
Larry Hastings added the comment:
Georg, you want to take a swing at it, be my guest. The current mess is my
doing, and I claim this is an *improvement* over what came before.
--
___
Python tracker
<http://bugs.python.org/issue22
Larry Hastings added the comment:
I remember manually setting/unsetting #defines to force alternate compilation
paths. But I think there were one or two that I didn't have library support
for (testing on Linux and Windows).
--
___
Python tr
Larry Hastings added the comment:
Patch attached. Brett was using a feature that didn't exist, so I'm not sure
how it could have worked for him. But it was a reasonable implicit feature
request, and easy to implement, so here we are.
I'm not sure what's causing the chu
Changes by Larry Hastings :
--
title: "make clinic" doesn't work -> Argument Clinic doesn't support the "type"
argument for the int converter
___
Python tracker
&
Changes by Larry Hastings :
--
assignee: -> larry
resolution: -> fixed
status: open -> closed
type: -> compile error
___
Python tracker
<http://bugs.python
Larry Hastings added the comment:
FWIW, I agree that it should be fixed:
>>> dict(self=1)
{'self': 1}
--
nosy: +larry
___
Python tracker
<http://bugs
Larry Hastings added the comment:
Serhiy: set_literal_2.patch doesn't apply cleanly, so I don't get a "review"
link. And apparently Raymond checked in some other changes separately. Could
you redo your patch so it has the Clinic changes, and ensure I
Larry Hastings added the comment:
The patch is totally fine. I wonder why it was like that in the first place!
--
___
Python tracker
<http://bugs.python.org/issue22
Larry Hastings added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue20662>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Actually this is the wrong issue for that observation. You want the issue
where yselivanov added emitting the "/" to pydoc.
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
I would prefer the backport be more selective. There are other changes (set
literals, fix "--converters") in trunk that aren't in 3.4 and I wouldn't want
them pulled in willy-nilly.
However, I'd accept this backport if the patc
Larry Hastings added the comment:
I'm not sure we support 2.7 supports any versions of Windows earlier than XP.
If so, we could drop the provision entirely.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Still not fixed! This has been marked as "release blocker" for most of a year.
Should I just apply the patch?
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
What does "-m32" mean?
--
___
Python tracker
<http://bugs.python.org/issue22634>
___
___
Python-bugs-list mailing
New submission from Larry Hastings:
Steve is using new technology to make the installers for Windows. He generates
four installers now:
* .exe for Win32
* -amd64.exe for Win64
* -webinstall.exe for Win32 web-based installers
* -amd64-webinstall.exe for Win64 web-based installers
add-to
Larry Hastings added the comment:
I should add, adding the files by hand worked fine. (Which means that if you
experiment with the script, when it blows away the files and re-adds them,
you'll be blowing away the files I added by hand. So if you do so, it's up to
you to ensure the
Larry Hastings added the comment:
Attached for your reading pleasure.
--
keywords: +patch
Added file:
http://bugs.python.org/file38060/larry.add-to-pydotorg.exe.support.1.diff
___
Python tracker
<http://bugs.python.org/issue23
Larry Hastings added the comment:
I'm not opposed to the patch in principle. I assume your goal is to make
Python faster--do you have any data on how much faster?
I don't support immediately changing all uses of Argument Clinic to generate
their code into a separate file. I wou
Larry Hastings added the comment:
Stefan: Serhiy's patch only affects functions taking a single positional-only
parameter.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
lgtm
--
___
Python tracker
<http://bugs.python.org/issue23492>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Larry Hastings :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue24286>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
This looks big and complicated. I'd prefer this skipped 3.5 and just went into
3.6.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Sounds okay in theory. Is the bug in question now tested in our regression
suite?
--
___
Python tracker
<http://bugs.python.org/issue24
Larry Hastings added the comment:
Then you may fire when ready.
--
___
Python tracker
<http://bugs.python.org/issue24320>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
Quoi? Je comprends que le français.
--
___
Python tracker
<http://bugs.python.org/issue18003>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
If I understand this correctly, I can ignore everything up to May 2015, as it
has to do with line-reading a compressed binary file (!) being slow.
Then, Martin Panter proposes a new optimization in May 2015, which is to simply
add __iter__ methods to
Larry Hastings added the comment:
I don't see anything about "closed" in the patch you posted.
--
___
Python tracker
<http://bugs.python.org/issue18003>
___
_
Larry Hastings added the comment:
Go ahead for beta 3.
--
___
Python tracker
<http://bugs.python.org/issue8232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
A small last-minute optimization is not a release-blocker.
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.python.org/issu
Larry Hastings added the comment:
I'll allow it. But I agree with Brett, I really would prefer that the type be
the first thing in the repr. I'd rather fix the lock objects than compound our
error.
--
___
Python tracker
<http://bu
Larry Hastings added the comment:
FWIW I find "unset" more obvious. I don't think it needs the module name.
--
___
Python tracker
<http://bugs.pyt
Larry Hastings added the comment:
The world of reprs already isn't particularly consistent. If you make your
reprs consistent with module X, it'll be *inconsistent* with module Y, and vice
versa. I say let's just worry about making it nice and readable for humans.
That s
Larry Hastings added the comment:
Sounds good to me.
--
___
Python tracker
<http://bugs.python.org/issue18003>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Of the two I prefer Harrison Grundy's patch, simply because it's shorter.
What OS / filesystem did you run the test on, koobs?
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
Sorry, but I think this is more accurately described as a "new feature" than a
"bugfix". Please don't backport this to 3.4.
--
___
Python tracker
<http
Larry Hastings added the comment:
This is not a bugfix to existing code. This is new code to implement a missing
feature.
--
___
Python tracker
<http://bugs.python.org/issue8
Larry Hastings added the comment:
Rules like this are there for a reason. People rely on Python being
consistent. We've added harmless new features to point releases in the past
and broken people's code. So, we don't do it anymore.
It's not because we don't care,
Larry Hastings added the comment:
Yes, which is why I permitted a feature freeze exception for it for 3.5. But
it's simply far, far too late to add a feature like this to 3.4.
--
___
Python tracker
<http://bugs.python.org/i
Larry Hastings added the comment:
Probably, though I want to see a sample implementation before I agree to
anything.
--
___
Python tracker
<http://bugs.python.org/issue24
Larry Hastings added the comment:
"Last installed wins" isn't perfect, but at least it's predictable.
Is it possible to make the 3.4 installer detect that 3.5+ is installed and not
install the launcher?
--
___
P
Larry Hastings added the comment:
I can accept this change, but I don't like that code. Is it really considered
acceptable to have that much copy-and-paste code in the dict implementation for
KnownHash calls?
Could the common code be split off into a Py_LOCAL_INLINE fun
Larry Hastings added the comment:
Patch doesn't build for me against current trunk:
gcc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes-Werror=declaration-after-statement
-I. -IInclude -I./Include-DPy_BUILD_COR
Larry Hastings added the comment:
I suggest that 20 lines of identical code copy-and-pasted between two functions
is not the cleanest way to do it. Find attached my version of the patch, which
splits this common code out into a static function.
--
Added file: http://bugs.python.org
Larry Hastings added the comment:
What's a sensible approach to ameliorate the problem? Gracefully muddle
through without a __name__ on the imported object?
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Yes, by all means, fix for 3.4, 3.5, and 3.6. If possible I'd appreciate you
getting the fix checked in to 3.5 within the next 48 hours, as I'm tagging the
next beta release of 3.5 around then, and it'd be nice if this fix went out i
Changes by Larry Hastings :
--
nosy: -larry
___
Python tracker
<http://bugs.python.org/issue22516>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
This can go in for 3.5 beta 3.
--
___
Python tracker
<http://bugs.python.org/issue24483>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
This is
a) marked as release blocker, and
b) is assigned to nobody.
This is not tenable.
While I want this fixed, I'm not going to hold up beta 3 for it.
--
priority: release blocker -> deferred
Larry Hastings added the comment:
I'll accept it for 3.5. Can it go in for beta 3, tagged in 48 hours?
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
This is fine for 3.5.
--
___
Python tracker
<http://bugs.python.org/issue19235>
___
___
Python-bugs-list mailing list
Unsub
Larry Hastings added the comment:
opcode.patch is okay for 3.5.
--
___
Python tracker
<http://bugs.python.org/issue24468>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
Steve?
--
assignee: -> steve.dower
___
Python tracker
<http://bugs.python.org/issue24432>
___
___
Python-bugs-list mai
Larry Hastings added the comment:
Help me to understand here. You want to check in a patch adding 300 new lines
of C code to the types module during beta, for a speed optimization, after
we've already hit beta?
While I like speedups as much as the next guy, I would be happier if this
w
Larry Hastings added the comment:
Oh, wait, I was confusing myself. This is that new module you guys created for
type hints, and this is a new object with no installed base. (Right?)
Yeah, you can check it in for 3.5.
--
___
Python tracker
<h
Larry Hastings added the comment:
I just wanna say, thanks everybody for tackling this. Here's hoping it makes
it into 3.5 beta 3!
--
___
Python tracker
<http://bugs.python.org/is
Changes by Larry Hastings :
--
priority: release blocker -> deferred blocker
___
Python tracker
<http://bugs.python.org/issue23623>
___
___
Python-bugs-list mai
Changes by Larry Hastings :
--
priority: release blocker -> deferred blocker
___
Python tracker
<http://bugs.python.org/issue23441>
___
___
Python-bugs-list mai
Larry Hastings added the comment:
So, the purpose in marking this as a "release blocker" is so that we can hold
up the release while we wait for Microsoft to release a new compiler? If our
approach to fixing this is to get the compiler fixed, I can live with marking
this as "
Changes by Larry Hastings :
--
priority: release blocker -> normal
stage: -> needs patch
type: crash -> enhancement
___
Python tracker
<http://bugs.python.or
Changes by Larry Hastings :
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.python.org/issue15014>
___
___
Python-bugs-list mai
Changes by Larry Hastings :
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.python.org/issue24485>
___
___
Python-bugs-list mai
Larry Hastings added the comment:
I'm not going to hold up beta 3 while you guys argue about how to round up or
down the number of angels that can dance on the head of a pin.
--
priority: release blocker -> deferred blocker
___
Python tracke
Larry Hastings added the comment:
This regression isn't thrilling, but it's not the kind of "OMG we can't release
with this bug" level of escalation I associate with an actual release blocker.
Let's at least defer it for now, and maybe we'll even reduce it
Larry Hastings added the comment:
FWIW, our "AMD64 Windows7 SP1 3.5" buildbot hits this > 50% of the time in the
regression test suite. So it's not just Terry.
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/78/steps/test/logs/stdio
-
Larry Hastings added the comment:
This issue was created 2015/02/11. Python 3.4 was released on 2014/03/16. Is
there an earlier duplicate issue for this problem that was marked "release
blocker" for 3.4?
--
___
Python trac
Larry Hastings added the comment:
Yeah, considering how long this bug has been sitting around, I think we can
wait for one more release for the fix. 3.6 please.
--
___
Python tracker
<http://bugs.python.org/issue2
Larry Hastings added the comment:
It produces the same exception under Python 3.4, too.
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue24
Changes by Larry Hastings :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24619>
___
___
Python-bugs-list mailing list
Unsubscrib
Larry Hastings added the comment:
Deferring for beta 4. We should still fix before release. Preferably before
RC1 depending on the availability of Certain Persons.
--
nosy: +larry
priority: release blocker -> deferred blocker
___
Python trac
Larry Hastings added the comment:
Since we apparently can't test this without making the release, but it's
important enough to not defer, I am in the unenviable position of shipping the
last beta with this bug marked as a release blocker.
Fingers crossed!
--
no
Larry Hastings added the comment:
Mark's test case file produced a KeyError under 3.4 when I tried it.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
This is a legitimate problem and I'd definitely like it fixed.
However, the angle brackets and the quote marks are ugly:
decode(obj, encoding='', errors='strict')
Attached is a tweaked version of the patch that sidesteps the q
Larry Hastings added the comment:
FWIW I set up a test harness that runs test_collections and odict_reproduce
with monotonically increasing PYTHONHASHSEED values. I let it run overnight;
it's now past iteration 158600. Apart from some weirdness in the low 70ks that
I can't repr
1901 - 2000 of 2389 matches
Mail list logo
