Larry Hastings added the comment:
(Well, except for Object/methodobject.c.)
--
___
Python tracker
<http://bugs.python.org/issue19674>
___
___
Python-bugs-list m
Changes by Larry Hastings :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue19674>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
I was deliberately trying to avoid something that a person might do by
accident. Also, "def (" is consistently only five bytes, whereas "pterodactyl
(" or whatever will often be much longer, in case static data size is a concern.
But
Changes by Larry Hastings :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue19674>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
I changed it to "(". Patch attached. Still works.
--
Added file:
http://bugs.python.org/file32763/larry.introspection.for.builtins.patch.2.txt
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
Anybody have a better name for __textsig__ ?
--
___
Python tracker
<http://bugs.python.org/issue19674>
___
___
Python-bugs-list m
New submission from Larry Hastings:
Attached is a patch exposing the old opcode_stack_effect() function to Python.
The patch does the following:
* renames opcode_stack_effect() to PyCompile_OpcodeStackEffect()
* removes the "static" modifier from PyCompile_OpcodeStackEffect()
Larry Hastings added the comment:
(Sponging around for a reviewer ;-)
--
___
Python tracker
<http://bugs.python.org/issue19722>
___
___
Python-bugs-list mailin
Changes by Larry Hastings :
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue19722>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
New patch, incorporating Antoine's comments. Thanks, Antoine!
--
Added file:
http://bugs.python.org/file32782/larry.expose.stack.effect.patch.2.diff
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
You find the big
/*[clinic checksum: b6ded2204fd0aab263564feb5aae6bac840b5b94]*/
marker insufficient?
Perhaps this is simply something we will quickly get used to. How about we let
this sit for a while and see what other people think.
p.s. I accept your
Larry Hastings added the comment:
I quite agree. My plan is to write a quick HOWTO for now to get
people up and running for now, then flesh it out into a full document.
But I'm working like crazy right now to get a couple things done
before
Larry Hastings added the comment:
> However, to bikeshed a little, I would prefer
> "preprocessor" instead of "clinic", since jokes
> tend to wear off if one sees then too often.
"Argument Clinic" is the name of the tool. The marker /*[clinic]*/
was
Larry Hastings added the comment:
I went with __text_signature__. I also did some more polishing, and added /
fixed the unit tests, and even added a Misc/NEWS. Is it good enough to go in
before the beta?
--
Added file:
http://bugs.python.org/file32785
Larry Hastings added the comment:
Attached is a patch to at least add a "make clinic" target for the UNIX-like
platforms. This doesn't add anything for the Windows build.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file32786/larry.m
Larry Hastings added the comment:
Okay, there's more than one way to skin this cat. This version uses os.walk().
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
(Whoops, forgot to attach the new diff.)
--
Added file: http://bugs.python.org/file32788/larry.make.clinic.patch.2.diff
___
Python tracker
<http://bugs.python.org/issue19
Larry Hastings added the comment:
stack_effect will never know about EXTENDED_ARG. Instead, you simply pass the
already-extended arg as the second argument.
Making the second argument support a default of None will be slightly
inconvenient, but I'll do it if you think it's a big i
New submission from Larry Hastings:
Two minor changes for Argument Clinic.
* Added a "version" directive, so a programmer can require a
specific version (or better) of Clinic.
* Finished off support for all the 'legacy' converters. The ones today
were those tha
Larry Hastings added the comment:
Are you sure the problem is fixed? I still see the same error on the same
buildbot.
http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3168/steps/test/logs/stdio
--
___
Python tracker
<h
Larry Hastings added the comment:
Attached is revision 3 of the patch. I'm gonna check it in pretty soon, so as
to make beta (and feature freeze). I changed the API so the oparg is optional,
and it raises if it gets one it shouldn't have or didn't get one when it should.
-
Larry Hastings added the comment:
Attached is a fresh patch. I added a third new feature: the "self converter",
which allows you to change the type of (or rename) self. For an example of its
use, check out dbm.dbm.get in Modules/_dbmmodule.c.
--
title: Clinic fixes: add
Larry Hastings added the comment:
Fresh patch attached. pydoc now uses inspect.signature instead of
inspect.getfullargspec to generate the arguments for the function, and supports
builtins. That's everything :D
Planning on checking this in pretty soon, to get it in for beta (
Larry Hastings added the comment:
Martin: I think the best choice would be a decimal object--which, now that we
have decimal in C, is probably sufficiently performant for serious
consideration.
--
nosy: +larry
___
Python tracker
<h
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
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Larry Hastings added the comment:
Fixed. By the way, this checkin also added a tiny new feature to Argument
Clinic: if the file hasn't changed, it doesn't bother to rewrite it (or touch
it in any way).
--
assignee: -> larry
resolution: -> fixed
stage: patch review
Changes by Larry Hastings :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Larry Hastings:
test_gdb started failing on me within the past few days. (I would have
reported it sooner but I figured the omniscient CPython core dev community
already knew about it.)
The machine it's failing on is Ubuntu 13.10, 64-bit.
--
components:
Larry Hastings added the comment:
Please see the attached output from the test run. But here's a sample:
==
FAIL: test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of
Larry Hastings added the comment:
Nick: I get that gdb failure, bisecting now. See #19743.
--
___
Python tracker
<http://bugs.python.org/issue19734>
___
___
Pytho
Larry Hastings added the comment:
The first bad revision is:
changeset: 87426:9f2a0043396b
user:Antoine Pitrou
date:Sat Nov 23 17:40:36 2013 +0100
files: Lib/test/test_gdb.py Tools/gdb/libpython.py
description:
Issue #19308: fix the gdb plugin on gdbs linked with Python
Larry Hastings added the comment:
That's correct, it is skipped.
--
___
Python tracker
<http://bugs.python.org/issue19743>
___
___
Python-bugs-list m
Larry Hastings added the comment:
The test passes if I turn on "--with-pydebug". And Antoine told me in IRC that
he sees the failure if he turns off "--with-pydebug". So we're in business.
--
___
Python tracker
<http:
Larry Hastings added the comment:
Here's what I've figured out. If I build trunk then run:
% gdb --batch -iex "add-auto-load-safe-path
/home/larry/src/python/buildtrunk/python-gdb.py" --eval-command="set breakpoint
pending yes" --eval-command="break bui
Larry Hastings added the comment:
Sorry, both exceptions in the output of the traceback are:
Python Exception 'utf-8' codec can't decode byte
0x80 in position 0: invalid start byte:
--
___
Python tracker
<http://bugs.pyt
Larry Hastings added the comment:
Antoine: your checked-in workaround makes the test pass. But I'm leaving this
open because I'm still hoping David will take a look into it.
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
Are the generated files *byte for byte* the same as produced by the existing
parser generation process?
--
___
Python tracker
<http://bugs.python.org/issue19
Larry Hastings added the comment:
The rule is, no new features. Bug and security fixes from now on.
It isn't always clear whether or not something is a new "feature". In the case
of such ambiguity, the decision is up to the sole discretion of the release
manager.
If you se
Larry Hastings added the comment:
Isn't it a little late to be changing the pickle protocol, now that we've hit
feature-freeze? If you want to check something like this in you're going to
have to make a good case for it.
--
___
Larry Hastings added the comment:
If skipping them for optimized builds is the right call, then aren't we done
here? Can we close this bug as fixed?
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
I'll make you a deal. As long as the protocol remains 100% backwards and
forwards compatible (3.4.0b1 can read anything written by trunk, and trunk can
read anything written by 3.4.0b1), you can make optimizations until beta 2.
After that you have to
Larry Hastings added the comment:
I don't know enough about SSL to make a "feature vs bug/security fix" ruling on
this. Can a second person who does--maybe Bill Janssen?--chime in?
--
___
Python tracker
<http://bugs.pyt
Larry Hastings added the comment:
Okay, you have my permission to add match_hostname() and fix the security hole
you cite. Can you have it done soon, so it can bake for a while in trunk
before we cut beta 2?
--
___
Python tracker
<h
Larry Hastings added the comment:
It's *possible* but I'm willing to risk it. You have my permission to apply
that patch.
--
___
Python tracker
<http://bugs.python.o
New submission from Larry Hastings:
Read this today:
http://mortoray.com/2013/11/27/the-string-type-is-broken/
In it the author talks about how the 'ffl' ligature breaks some string
processing. He claimed that Python 3 doesn't uppercase it correctly--well, it
does. Howev
Larry Hastings added the comment:
They're not on Python 3. I think we should keep the deprecation and let them
roll their own when they upgrade. It's not like the module provides much
functionality in the first place.
--
___
Python trac
Larry Hastings added the comment:
I don't want this checked in to 3.4.
(Congratulations, this is my first "no" as a release manager!)
--
___
Python tracker
<http://bugs.pyt
Larry Hastings added the comment:
Since this is a new library in 3.4, I can be more flexible. And since you're
talking about adding a new feature (rather than changing or removing an
existing feature), this has a vanishingly small chance of screwing anything up.
Therefore I'm
Larry Hastings added the comment:
Okay, yeah. I assumed calling .close() was best practice. If it's not, then...
Guido, since this is your library, I delegate the decision to you. You guys
can add this any time before I tag beta 2 if Guido'
Larry Hastings added the comment:
Argument Clinic theoretically could support annotations for builtins, though
it's never been tested. I don't know if it makes sense to close this bug yet.
--
___
Python tracker
<http://bugs.python.
Larry Hastings added the comment:
Why wouldn't "dbm_open((char *)file, flags, mode)" work?
--
___
Python tracker
<http://bugs.python.org/issue19296>
___
__
Larry Hastings added the comment:
I suspect dbm_open predates the common availability of "const". I assert we
can safely assume it won't overwrite the contents of the buffer. (Barring
spectacular memory corruption bugs that "const" woul
Larry Hastings added the comment:
Brett, could you weigh in please?
--
___
Python tracker
<http://bugs.python.org/issue19927>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
Antoine: are you characterizing this as a "bug" rather than a "new feature"?
I'd like to see more of a consensus before something like this gets checked in.
Right now I see a variety of opinions.
When I think "conservative app
Larry Hastings added the comment:
I can live with this in 3.4 if you check it in before beta 2.
--
___
Python tracker
<http://bugs.python.org/issue19343>
___
___
Larry Hastings added the comment:
> The fact that write() uses sys.getfilesystemencoding() is either
> a defect or a bad design (I leave the decision to you).
I have good news for you. write() does not cal sys.getfilesystemencoding(),
because the encoding is set at the time the file is
Larry Hastings added the comment:
Please clarify, what is my "false dilemma"?
--
___
Python tracker
<http://bugs.python.org/issue19145>
___
___
Python-b
Larry Hastings added the comment:
The main thing for me isn't that the function and its documentation-pseudocode
are in sync (though in the long run this is desirable). What's important to me
is that the function have a sensible, relevant signature in Python. There was
simply
Larry Hastings added the comment:
> There is a way using *args and **kwds but that isn't any fun
That's why, earlier, I said a "sensible" signature. Every function *could* get
the signature "(*args, **kwargs)" but this imparts no useful semantic
information
Larry Hastings added the comment:
This test also fails on Linux when using ZFS.
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue19838>
___
___
Larry Hastings added the comment:
Sorry to have such an awful configuration, but this approach won't fix the
problem for me.
I use a Linux "encrypted home directory", which uses crazy loopback mount logic
to create an on-the-fly decrypted representation of my home director
Larry Hastings added the comment:
(By "this approach" I meant "the approach employed in the first patch posted".
Sorry for the ambiguity.)
--
___
Python tracker
<http://bug
Larry Hastings added the comment:
Here's an updated patch. I cleaned it up a little. I think it's about ready
to go in.
Zachary, iirc you're a Windows guy and have helped with ensuring patches apply
cleanly to Windows in the past. Can you give this a try on Windows?
--
Larry Hastings added the comment:
thanks! I'm flying from London to Brisbane (via Singapore), gonna take about a
day. Now I have something to do on the flight ;-)
(that and nullable ints)
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
I'm with Martin. It would be a funny exception, where the reader'd get
confused... why is the impl missing?
Also, any halfway-decent optimizer will inline the impl into the parsing
function, so this has no ru
Larry Hastings added the comment:
Here's a fresh diff. I did some cleanup this time (Clinic now generates the
#ifndef versions of the METHODDEF structures) and I believe solved everything
MSVC complains about.
Zachary, can you try this one?
--
Added file: http://bugs.pytho
Larry Hastings added the comment:
Here's a fresh patch. After discussing with Martin at EuroPython, I moved the
implementation into Python/getargs.c, and the prototypes into modsupport.h.
I'm still using the example of "repeat.new" to show what it looks like and how
Larry Hastings added the comment:
Whoops, here's the patch.
--
Added file: http://bugs.python.org/file36165/larry.nullable.ints.4.txt
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Two small fixes from Zach (thanks again Zach!) and I updated against current
trunk so it should apply cleanly. How's it look now?
--
Added file: http://bugs.python.org/file36172/larry.clinicize.posixmodule.6
Larry Hastings added the comment:
FWIW, Martin agreed with me at EuroPython that "nullable int" is the proper
name. So does Wikipedia:
http://en.wikipedia.org/wiki/Nullable_type
As for "repeat_new": like I said, I don't intend to check in this change when
check
Larry Hastings added the comment:
Moratorium's long over. Will this patch rise from the dead?
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/i
Larry Hastings added the comment:
os.stat can return something more precise than nanosecond resolution?
--
___
Python tracker
<http://bugs.python.org/issue19
Larry Hastings added the comment:
Diff tweaked to undo the ill-concieved Py_RETURN_NONE change. Thanks, Zachary!
Does it now compile and pass tests on Windows?
--
Added file: http://bugs.python.org/file36240/larry.clinicize.posixmodule.7.diff
Larry Hastings added the comment:
So why can't you use the "ns" parameter for os.utime()?
--
___
Python tracker
<http://bugs.python.org/issue19838>
___
__
Larry Hastings added the comment:
A cursory read of the source code suggests everybody is doing the right thing.
Can you run this with a debug build of CPython, put a breakpoint in
posix_utime, and check that when it's called for the second p.touch that it's
correctly calling the
Larry Hastings added the comment:
And was the "time" argument passed in to utimes() set to NULL?
--
___
Python tracker
<http://bugs.python.org/issue19838>
___
__
Larry Hastings added the comment:
The "no debug info" makes me think you're using a release build. Please
recompile making sure that "-O0" and "-g" are both set. By default the
makefile has "-O3" and "-g", so normally you just
Larry Hastings added the comment:
Yeah, I've been meaning to mark all the Derby patches as 3.5. We're not adding
new Clinic conversions to 3.4.
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
Yup, you've got a debug build there. I'm baffled by that gdb "no debug info"
line then.
At line 4801 could you also
print *utime
print tv
--
___
Python tracker
<http://bug
Changes by Larry Hastings :
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20171>
___
___
Python-bugs-list mailing list
Unsub
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
___
Python tracker
<http://bugs.python.org/issue20171>
___
___
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
All the Derby patches should only go into trunk at this point.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue20
Larry Hastings added the comment:
I talked to puppet on IRC for a while and we figured out the following about
his OS:
* He has utime() and utimes(), but no utimensat().
* utimes() can write with *microsecond* resolution.
* stat() reads the time with *nanosecond* resolution. (He has
Larry Hastings added the comment:
This looks reasonable to me. However I'd also change
_PyType_GetDocFromInternalDoc() so that it also returns None if the first byte
of the doc is \0.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
And to further confirm, on my Linux machine with a ZFS partition:
* stat() returns nanosecond resolution.
* I have utimensat(), which supports nanosecond resolution.
* The test code correctly sets "utime.now = 1", so it correctly calls
utimensat() w
Larry Hastings added the comment:
Attached is a simple C test case for the same behavior. On my Linux machine
this prints "This is insane!" on a ZFS partition and "Everything is okay" on an
ext4 partition.
The test case won't work unmodified on FreeBSD. Try c
Larry Hastings added the comment:
Those interested in this issue might also be interested in #19838, in which I
demonstrate that utime(path, NULL) can set mtime to an *earlier* time on ZFS on
Linux.
--
title: Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/
FFS
1001 - 1100 of 2415 matches
Mail list logo
