Larry Hastings added the comment:
I can confirm that the behavior is fixed in ZFS on Linux. My test case C
program now prints "Everything is okay." when run on a ZFS partition on Linux,
and test_touch_common from the current tree passes every time. ZFS fixing this
was the bes
Change by Larry Hastings :
--
components: -2to3 (2.x to 3.x conversion tool), Build, C API, Cross-Build,
Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE,
IO, Installation, Interpreter Core, Library (Lib), Parser, Regular Expressions,
SSL, Subinterpreters
Change by Larry Hastings :
--
components: +Library (Lib) -Argument Clinic
___
Python tracker
<https://bugs.python.org/issue43424>
___
___
Python-bugs-list mailin
Change by Larry Hastings :
--
components: +Documentation
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue43424>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
The function will still leak "kwnames" and "default" if creating the "func"
object fails. Admittedly that would only happen in a low-memory condition
which is a) rare and b) probably only happens just before the interpreter
Larry Hastings added the comment:
(Sorry--it'll leak "kwnames", "newargs", and "defaults".)
--
___
Python tracker
<https://bugs.python.org/issue46347>
___
_
Larry Hastings added the comment:
So, can we shoot for adding this to 3.11? Jack, do you consider the code is in
good shape?
I'd be up for shepherding it along in the process. In particular, I can
contribute the bindings so BLAKE3 is a first-class citizen of ha
Change by Larry Hastings :
--
components: -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API,
Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules,
FreeBSD, IDLE, IO, Installation, Library (Lib), Parser, Regular Expressions,
SSL, Subinterpreters
Larry Hastings added the comment:
> In setup.py I assume that the target platform of the build is the same as the
> current interpreter's platform.
If this is included in CPython, it won't be using setup.py, so this isn't a
concern.
I don't think there's
Larry Hastings added the comment:
I assume by "intrinsics" you mean using the GCC SIMD stuff, not like inlining
memcpy() or something. My assumption is yes, that's fine, we appear to already
be using them for BLAKE2.
--
___
New submission from Larry Hastings :
It's considered good hygiene to use functools.update_wrapper() to make your
wrapped functions look like the original. However, when using
functools.partial() to pre-supply arguments to a function, if you then call
functools.update_wrapper() to u
Larry Hastings added the comment:
I thought someone volunteered to do it--if that's not happening, I could take a
look at it next week. Shouldn't be too hard... unless I have to touch
autoconf, which I only barely understand.
--
Change by Larry Hastings :
--
components: -Argument Clinic
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue46783>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
Just checking--I can liberally pull code from
https://github.com/BLAKE3-team/BLAKE3 yes?
--
___
Python tracker
<https://bugs.python.org/issue39
Larry Hastings added the comment:
Yury, Ka-Ping, can you guys shed any light on this? Your names are still on
inspect.py.
--
nosy: +ping, yselivanov
___
Python tracker
<https://bugs.python.org/issue46
Larry Hastings added the comment:
Yeah, it's the same behavior. In that class, you have defined Str to be "",
then you reference Str in the annotation, and its value is "". Whatever you
set Str to in the example in [21], that's the value of the annotation.
Larry Hastings added the comment:
Ofey, I appreciate your enthusiasm, but you should probably slow down. Fixing
the bug is probably going to be the easy part here. But we're not to that
stage quite yet. First, we need to determine
* why the code behaves like this--is this behav
Larry Hastings added the comment:
Okay, so, I considered the problem for a while, and I have a reasonable theory
about what follow_wrapper_chains was for in the first place.
If you have a generic decorator, like functools.cache(), it usually looks like
this:
def my_decorator(fn):
def
New submission from Larry Hastings :
I ran across an interesting bug in issue #46761. If you call
functools.update_wrapper on a functools.partial object, inspect.signature will
return the wrong (original) signature for the partial object.
We're still figuring that one out. And, of c
New submission from Larry Hastings :
functools.update_wrapper currently copies over every attribute listed in the
"assigned" parameter, which defaults to WRAPPER_ASSIGNMENTS, which means it
copies the wrapped function's __annotations__ to the wrapper. This is slightly
wrong
Change by Larry Hastings :
--
nosy: -larry, loewis
___
Python tracker
<https://bugs.python.org/issue28824>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
I emailed the Pydantic and FastAPI guys and didn't hear back. Given what you
found on their issue trackers, I think it's unlikely that they care a lot about
this issue (but were too busy to reply). It's far more likely that they don&#x
Change by Larry Hastings :
--
pull_requests: +29805
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31686
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
Okay, so. Here's a PR that adds BLAKE3 support to hashlib.
The code was straightforward; I just took the BLAKE2 module and modified it to
only have one algorithm. I also copied over the whole C directory tree from
BLAKE3, which is totally okay fi
Larry Hastings added the comment:
Also, for what it's worth: I just ran my checksum benchmarker using a freshly
built python a la my PR. Here are my results when hashing 462183782 bytes
(dicey-dungeons-linux64.zip):
hash
algorithm timebyte
Larry Hastings added the comment:
Jack O'Connor:
> Was any of the experimental C extension code [...] useful to you?
> I was wondering if it could be possible to copy blake3module.c from
> there verbatim.
I concede I didn't even look at it. The glue code to mate the librar
Larry Hastings added the comment:
Right, and I did say "(or BDFL)". Apparently you didn't bother to consult with
the BDFL in advance, or at least not in the usual public venues--I haven't
found a record of such a conversation on the bpo issue, nor in python-dev.
BT
Larry Hastings added the comment:
When accessing __annotations__ *in a class without annotations*, and *for the
first time*. And your workaround seems reasonable.
--
___
Python tracker
<https://bugs.python.org/issue46
Larry Hastings added the comment:
Whoops, copy & paste error on the title, there.
--
title: ix dumbdbm, which fixes test_shelve (for me); instrument other tests so
we catch this sooner (and more directly) -> Fix dumbdbm, which fixes
test_shelve (for me); instrument other test
Larry Hastings added the comment:
Yeah, Neil Norwitz added the one-line dumbdbm fix in r57358.
Thanks!
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1007>
__
__
Larry Hastings added the comment:
Mark Dickinson wrote:
> I think this could work.
"could"? Oh ye of little faith!
Attached is a patch against a nice fresh trunk (2b47f0146639) that adds Decimal
attributes "ctime", "mtime", and "atime" to the ob
New submission from Larry Hastings :
After the great Capsule flame wars of 2011, it became clear that we need
documentation on migrating from CObject to Capsules, as CObject is gone as of
3.2. Nick made me promise to write the documentation, and Raymond steered me
in the direction of
New submission from Larry Hastings :
The title of howto/cporting.rst is "Porting Extension Modules To 3.0". It then
talks about 3.0 in a whole bunch of places. Considering that we're working on
3.3, and considering that 3.0 is end-of-lifed (not even meriting a branch in
hg),
Larry Hastings added the comment:
Attached is a patch against trunk branch "2.7" (rev dec00ae64ca8) adding
documentation on how to migrate CObjects to Capsules. Delta the inevitable
formatting bikeshedding, this should be ready to go. I've smoke-tested the
"capsulethu
Larry Hastings added the comment:
Whoops, forgot to attach. *Here's* the patch.
--
keywords: +patch
Added file: http://bugs.python.org/file23282/larry.cporting.capsules.r1.diff
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Why shouldn't I check this in to the 2.7 / 3.1 branches?
--
___
Python tracker
<http://bugs.python.org/issue13086>
___
___
Larry Hastings added the comment:
Attached is r2 of the patch, incorporating Nick's suggestions. Base revision
hasn't changed.
--
Added file: http://bugs.python.org/file23301/larry.cporting.capsules.r2.diff
___
Python trac
Larry Hastings added the comment:
In case you're curious, here's how I tested "capsulethunk.h". I added the file
to Python 2.7 (hg head), 3.0.0 (tarball), and 3.1.0 (tarball). For 2.7 ad
3.0.0 I quickly hacked four files to use the Capsule API instead of CObjects:
Larry Hastings added the comment:
New patch based on comments from Ezio Melotti--thanks, Ezio!
* capsulethunk.h is now its own file in Doc/includes.
* Various minor formatting touchups.
* I added some rationale behind the thunked PyCapsule_SetName behavior.
--
Added file: http
New submission from Larry Hastings :
It wasn't clear to me after reading the "Forward Porting" section exactly what
was going on. Nick Coghlan spelled it out for me in a private email, and
suggested that maybe this stuff should be in the devguide proper. Here's some
s
Larry Hastings added the comment:
What follows is the original email from Nick.
--
We maintain two independent heads in hg: 2.7 and default
3.2 is open for general bugfixes
2.5 (IIRC), 2.6 and 3.1 are open for security fixes
Security fixes (if applicable to both heads) go:
2.5 ->
Larry Hastings added the comment:
Can I get some thoughts / votes on whether to
a) check in with the current performance regression, or
b) do the work to make it lazy-created?
--
___
Python tracker
<http://bugs.python.org/issue11
Larry Hastings added the comment:
Attached is my first revision patch. I did some other editing for
clarity / 80 columns, though I can back those out from this patch (and put in
another) if that's best.
Patch is against the 2.7 branch; once this goes in I'll port all my recent
cp
Larry Hastings added the comment:
So what about doing the same for FreeBSD, SunOS, and Windows? The conversation
about this point sort of trailed off. But, dammit, a foolish consistency is
the hobgoblin of my small mind.
If we're changing "linux2" / "linux3" to j
New submission from Larry Hastings :
With the recent spate of POSIX *at() functions added to os, we now have a bunch
of places in the API that take directory fds. But afaict there's no way to get
a directory fd in Python! The only calls to opendir() in the tree are
internal, in os.li
New submission from Larry Hastings :
The new functions os.futimens() and os.utimensat() update the timestamps of a
file with nanosecond precision. However, both functions take atime and mtime
as a tuple: (seconds since epoch, nanoseconds). Contrast this with os.utime(),
which produces atime
Larry Hastings added the comment:
Well, there's no os.fdopendir(); I think you're referring to fdlistdir(), which
uses the C function fdopendir() internally. The DIR structure is not exposed
to the Python caller at any point.
I did miss the whole opendir-returns-a-DIR-not-
Larry Hastings added the comment:
fdlistdir() is largely irrelevant to the discussion. I was proposing adding a
function to open directory fds, because there isn't one; fdlistdir(), like many
other POSIX functions available in Python, consumes director
Larry Hastings added the comment:
> Is there anything you want to do on a "directory fd"
> except listing its contents?
In the first message in this bug, I wrote: "With the recent spate of POSIX
*at() functions added to os, we now have a bunch of places in the API tha
Larry Hastings added the comment:
I'm withdrawing this, as I've found a better way to approach the problem.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.py
New submission from Larry Hastings :
Since Linux 2.5 stat() has supported reading nanosecond resolution (1b/sec) for
atime and mtime. However, the utime() family of functions could only write
atime and mtime with microsecond resolution (1m/sec) until relatively recently.
On POSIX platforms
Larry Hastings added the comment:
A small aside:
An IEEE 754 double is insufficient to store a modern timestamp with nanosecond
accuracy. We're currently at just over 1.3 billion seconds since the epoch.
This eats 28 bits of the mantissa. (The value is actually 31 bits to the left
o
Larry Hastings added the comment:
> It's a duplicate of issue #11457.
No. #11457 is a how-many-angels-on-the-head-of-a-pin discussion proposing new
representations of ctime/mtime/atime to preserve nanosecond accuracy. This
patch changes the behavior of os.utime, os.futimes, os.luti
Larry Hastings added the comment:
This is probably a terrible idea, but: what about using a subclass of float
that internally preserves the original sec / usec values? Call it a
utime_float for now. os.stat would produce them, and os.utime would look for
them--and if it found one it'd
Larry Hastings added the comment:
Here's a better idea: we add a new IEEE 754-2008 quad-precision float type.
The IEEE 754-2008 quad precision float has 1 sign bit, 15 bits of exponent, and
112 bits of mantissa, so it should have enough precision to last utime until
humanity trans
Larry Hastings added the comment:
I think a pair of integers is a poor API. It ties the value of the fractional
part to nanoseconds. What happens when a future filesystem implements
picosecond resolution? And then later goes to femtoseconds? Or some platform
chooses another divisor (2
Larry Hastings added the comment:
> To support higher resolution
> will need to supply 3 fields in st_xtimesuperspec: tv_sec and tv_nsec
> packed in st_xtimespec (say tv_timespec) and new tv_psec field.
> st_xtime will now be st_xtimesuperspec.tv_timespec.tv_sec and
> st_xtim
Larry Hastings added the comment:
I've drawn an ASCII table summarizing the proposals so far. If I've made any
factual errors I trust you'll let me know.
= means os.stat().st_mtime is changed to that type.
+ means os.stat() grows a new field using that type,
and the curr
Larry Hastings added the comment:
s/pair-of-floats/pair-of-ints/
Also, to be clear: yocto is the smallest defined SI prefix. And what I meant
when I referred to 10**-3 was, float128 could handle 10**-24 but not 10**-27.
According to my back-of-the-envelope calculations, float128 could
Larry Hastings added the comment:
Mark Dickinson:
> > I realize a new float type would be a major undertaking
> That's an understatement and a half. The only way this could ever
> be viable is if float128 support becomes widespread enough that we
> don't have to wri
Larry Hastings added the comment:
Victor STINNER:
> Python is compiled using Visual Studio 2008 on Windows. Portability
> does matter on Python. If a type is not available on *all* platforms
> (including some old platforms, e.g. FreeBSD 6 or Windows XP), we
> cannot use it by defaul
New submission from Larry Hastings :
The documentation for configparser.RawConfigParser.read_file() states:
"Read and parse configuration data from the file or file-like object in f (only
the readline() method is used)."
This was true in Python 3.1 and before. However
Larry Hastings added the comment:
By the same token, readfp is now deprecate in favor of the new spelling
read_file. That change *is* mentioned in configparser. If I'm touching What's
New In Python 3.2, mind if I add a mention o
Larry Hastings added the comment:
"To reproduce: add a typo on "_curses" on line 1666."
Of what file?
--
___
Python tracker
<http://bu
Larry Hastings added the comment:
Patch to make testcapsule clear import errors when testing. Sorry about the
whitespace changes, but I outdented a bunch of code--I think it's clearer this
way.
--
Added file: http://bugs.python.org/file16223/lch.patch.trunk.py3k.r
Larry Hastings added the comment:
I finally reviewed this, and I think it does need additional armor against
attack. I think a user could insert a different object into the thread local
dict with the hard-coded name and get CPython to crash.
This patch fixes the vulnerability:
http
Larry Hastings added the comment:
This is also (naturally) being discussed on python-dev. I've posted a long
message there about it; you can find that message here:
http://mail.python.org/pipermail/python-dev/2010-March/098904.html
I don't know whether it's best to conduct su
Larry Hastings added the comment:
Florent: that's because the Windows build projects don't build capsule.c. I
don't have an appropriate Windows development environment; I'll try to fix them
by hand tonight, but if that doesn't work we'll have to call fo
Changes by Larry Hastings :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Kyle asked me to look at this; I think it looks ready for checkin, so unless
someone else jumps in with something to say I'll check it in in a day or two.
It's not going in to 2.6 however, just 2.7 trunk and probably 3.2.
--
nosy: +larr
Larry Hastings added the comment:
Committed in Python 2.7 as revision r79592
Committed in Python 3.2 as revision r79594
Thanks for the patch!
--
assignee: -> larry
resolution: -> accepted
status: open -> closed
versions: +Python 3.2
_
Larry Hastings added the comment:
Yes. I was told it was inappropriate for me to change the bsddb module, as
it's independently maintained by Jesus Cea. I sent Mr. Cea a patch last night;
I hope he chooses to merge it soon.
Since CObjects are marked Pending Deprecation, and bsddb is
Larry Hastings added the comment:
Oh, and, last night I checked in r79590. This is the checkin that ameliorates
the backwards compatibility issues. Specifically, I changed four things:
* PyCObject_AsVoidPtr() can now open capsules. This addresses
most of the remaining backwards
Larry Hastings added the comment:
The patch is a bit more involved than that. Capsules didn't exist in 3.0, and
the bsddb module published a CObject in 3.1. So bsddb must continue to use
CObject for those two releases.
Therefore the patch to the line you were addressing looks like
Larry Hastings added the comment:
Marking closed, as promised; 2.7b1 has been out for nine days and there hasn't
been a peep. If new problems crop up from the capsule backport, please create
a new issue and assign it to me.
For posterity: 2.7b1 shipped with a bsddb that still publis
Larry Hastings added the comment:
> In Windows the high-precision counter might return different results
> on different cores in some hardware configurations (older multi-core
> processors).
More specifically: some older multi-core processors where the HAL implements
QueryPerforman
Larry Hastings added the comment:
This isn't a CPython bug. It's a change in CPython behavior that wrapt needs
to accommodate. In particular, it isn't 'causing a regression for C subclasses
of heap types when the parent class has an "__annotations__" descripto
Larry Hastings added the comment:
(It's also possible your workaround where wrapt explicitly defines an
"__annotations__" getset on every child of ObjectProxy is the right fix. I
don't know; I don't know the fine points of attribute access, like when does it
acces
Larry Hastings added the comment:
Graham: I'm happy to help. I can write a more elaborate explanation of what's
happening, or answer questions, whatever you like. I'm a fan of wrapt so I'd
certainly like to see this issue resolved.
And, seeing as you're the autho
Larry Hastings added the comment:
I only did my experiments with the _wrappers.c Christian gave me. If that's
not the shipping version of wrapt, and wrapt doesn't exhibit this behavior in
3.10, then that's good. I agree you can wait to address this behavior until it
a
Larry Hastings added the comment:
Nobody I've nosied on this issue recently has expressed any opinion on the
matter. I'm gonna try one more person: Graham Dumpleton, the maintainer of
"wrapt", Python's premier function-wrapping.
Graham, care to express any opinio
Larry Hastings added the comment:
You make a good point. I filed a separate bug (#46846) suggesting that partial
objects should set their own annotations and signature. I agree that objects
performing such magic should take care of these details themselves, rather than
requiring the
Larry Hastings added the comment:
Jack: I've updated the PR, improving compatibility with the "blake3" package on
PyPI. I took your notes, and also looked at the C module you wrote.
The resulting commit is here:
https://github.com/python/cpython/pul
Larry Hastings added the comment:
> Given that I don't want to see us gain new vendored copies of
> significant but non-critical third party hash code in our tree
> (Modules/_blake3/impl/ in PR 31686) for anything but a known
> fixed term need (ex: the sha2 libtomcrypt code i
Larry Hastings added the comment:
Ok, I give up.
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Larry Hastings added the comment:
The Rust version is already quite "lean". And it can be much faster than the C
version, because it supports internal multithreading. Even without
multithreading I bet it's at least a hair faster.
Also, Jack has independently written a Pytho
Larry Hastings added the comment:
I can't answer why the Rust one is so much larger--that's a question for Jack.
But the blake3-py you built might (should?) have support for SIMD extensions.
See the setup.py for how that works; it appears to at least try to use the SIMD
extensi
Larry Hastings added the comment:
> Performance wise... The SHA series have hardware acceleration on
> modern CPUs and SoCs. External libraries such as OpenSSL are in a
> position to provide implementations that make use of that. Same with
> the Linux Kernel CryptoAPI (https://bug
Larry Hastings added the comment:
I heard back from both Samuel Colvin (Pydantic) and Sebastián RamÃrez
(FastAPI). They said neither of them use update_wrapper with partial objects.
They also took a peek in a bunch of other projects (FastAPI, Typer, SQLModel,
Asyncer, SQLAlchemy, Trio, and
Larry Hastings added the comment:
Ooh, good one. I don't know anybody in the Django project to contact though.
Anybody have any leads?
--
___
Python tracker
<https://bugs.python.org/is
New submission from Larry Hastings :
I've maintained my own topological sort class for a while now. The API I came
up with (or was it Tim and I?) was adopted for graphlib.TopologicalSort().
Some of my method names are slightly different, but the APIs are so similar, I
can do a l
Larry Hastings added the comment:
I'm using my graph library to manage a list of tasks that need doing in some
sort of proper order. One task may spawn other tasks at runtime, and we don't
necessarily know what the tasks will be until runtime. It's way more
convenient to
Larry Hastings added the comment:
> Assuming we do want to be able to add() after a get_ready(), is there
> a reason that "forgetting" already-produced nodes is the correct
> behavior, as opposed to remembering all nodes ever added, and
> raising iff the addition cre
Larry Hastings added the comment:
Having slept on it, I think the footgun is slightly bigger than I gave it
credit for. Also the problem of nodes lingering forever is easily solved: give
the user control.
My next iteration will keep the done nodes around, but I'll also add a f
Larry Hastings added the comment:
I'm not sure I follow you. What do you suggest graphlib is guessing at? I
thought we were discussing what graphlib's (documented, intentional) behavior
should be; if there was any guessing going on, it was us doing it, guessing at
what behavio
Larry Hastings added the comment:
I agree that the API should have as few surprises as possible. AFAICT you
haven't made any terminal pronouncements like "it's impossible to add this
feature without too many unacceptable surprises", so I'll proceed assuming
Larry Hastings added the comment:
One final aside. Let me preface this by saying: I'm not proposing the
following for graphlib.TopologicalSort. It's obviously too late to change that
object this much. It's just something I'm thinking about--maybe I'll use this
Larry Hastings added the comment:
New changeset 063eba280a11d3c9a5dd9ee5abe4de640907951b by larryhastings
(Abhilash Raj) in branch '3.5':
[3.5] bpo-34155: Dont parse domains containing @ (GH-13079) (#15317)
https://github.com/python/cpython/commit/063eba280a11d3c9a5dd9ee5abe4de
Larry Hastings added the comment:
All PRs merged. Thanks, everybody!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Larry Hastings added the comment:
New changeset 4d1c2541c125fe9d211016193ebfd5899a8511aa by larryhastings (Victor
Stinner) in branch '3.5':
bpo-36576: Skip test_ssl and test_asyncio tests failing with OpenSSL 1.1.1
(#12694)
https://github.com/python/cpyt
1 - 100 of 2389 matches
Mail list logo
