On Thu, Nov 29, 2018 at 5:10 PM Armin Rigo wrote:
> PS: on CPython could use ``typedef struct { PyObject *_obj; }
> PyHandle;``. This works like a pointer, but you can't use ``==`` to
> compare them.
And then you could have a macro or inline function to compare them,
simply by looking at that pr
Hi Steve,
On Tue, 27 Nov 2018 at 19:14, Steve Dower wrote:
> On 27Nov2018 0609, Victor Stinner wrote:
> > Note: Again, in my plan, the new C API would be an opt-in API. The old
> > C API would remain unchanged and fully supported. So there is no
> > impact on performance if you consider to use th
On Wed, Nov 28, 2018 at 07:14:03PM -0800, Brett Cannon wrote:
> On Wed, 28 Nov 2018 at 13:29, Steven D'Aprano wrote:
>
> > On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote:
> >
> > > PyPI makes getting more algorithms easy.
> >
> > Can we please stop over-generalising like this? P
On Wed, 28 Nov 2018 at 13:29, Steven D'Aprano wrote:
> On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote:
>
> > PyPI makes getting more algorithms easy.
>
> Can we please stop over-generalising like this? PyPI makes getting
> more algorithms easy for *SOME* people. (Sorry for shout
On Wed, Nov 28, 2018, 12:08 Antoine Pitrou On Wed, 28 Nov 2018 19:35:31 +
> Jonathan Underwood wrote:
> > On Wed, 28 Nov 2018 at 18:57, Antoine Pitrou
> wrote:
> > >
> > > On Wed, 28 Nov 2018 10:43:04 -0800
> > > "Gregory P. Smith" wrote:
> > [snip]
> > > > I don't think adding lz4 to the s
On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote:
> PyPI makes getting more algorithms easy.
Can we please stop over-generalising like this? PyPI makes getting
more algorithms easy for *SOME* people. (Sorry for shouting, but you
just pressed one of my buttons.)
PyPI might as we
On Wed, 28 Nov 2018 19:35:31 +
Jonathan Underwood wrote:
> On Wed, 28 Nov 2018 at 18:57, Antoine Pitrou wrote:
> >
> > On Wed, 28 Nov 2018 10:43:04 -0800
> > "Gregory P. Smith" wrote:
> [snip]
> > > I don't think adding lz4 to the stdlib is worthwhile. It isn't required
> > > for core fun
On Wed, 28 Nov 2018 at 18:57, Antoine Pitrou wrote:
>
> On Wed, 28 Nov 2018 10:43:04 -0800
> "Gregory P. Smith" wrote:
[snip]
> > I don't think adding lz4 to the stdlib is worthwhile. It isn't required
> > for core functionality as zlib is (lowest common denominator zip support).
>
> Actually, i
On Wed, 28 Nov 2018 10:43:04 -0800
"Gregory P. Smith" wrote:
> On Wed, Nov 28, 2018 at 9:52 AM Brett Cannon wrote:
>
> > Are we getting to the point that we want a compresslib like hashlib if we
> > are going to be adding more compression algorithms?
> >
>
> Lets avoid the lib suffix when unn
On Wed, Nov 28, 2018 at 9:52 AM Brett Cannon wrote:
> Are we getting to the point that we want a compresslib like hashlib if we
> are going to be adding more compression algorithms?
>
Lets avoid the lib suffix when unnecessary. I used the name hashlib
because the name hash was already taken by
On Wed, 28 Nov 2018 09:51:57 -0800
Brett Cannon wrote:
> Are we getting to the point that we want a compresslib like hashlib if we
> are going to be adding more compression algorithms?
It may be useful as a generic abstraction wrapper for simple usage but
some compression libraries have custom fa
+1 to Brett's idea. It's hard to have a good mental model already of which
compression algorithms are and are not in stdlib. A package to contain them
all would help a lot.
On Wed, Nov 28, 2018, 12:56 PM Brett Cannon Are we getting to the point that we want a compresslib like hashlib if we
> are
Are we getting to the point that we want a compresslib like hashlib if we
are going to be adding more compression algorithms?
On Wed, 28 Nov 2018 at 08:44, Antoine Pitrou wrote:
> On Wed, 28 Nov 2018 10:28:19 +
> Jonathan Underwood wrote:
> > Hi,
> >
> > I have for sometime maintained the P
On Wed, 28 Nov 2018 10:28:19 +
Jonathan Underwood wrote:
> Hi,
>
> I have for sometime maintained the Python bindings to the LZ4
> compression library[0, 1]:
>
> I am wondering if there is interest in having these bindings move to
> the standard library to sit alongside the gzip, lzma etc bi
Hi,
I have for sometime maintained the Python bindings to the LZ4
compression library[0, 1]:
I am wondering if there is interest in having these bindings move to
the standard library to sit alongside the gzip, lzma etc bindings?
Obviously the code would need to be modified to fit the coding
guide
15 matches
Mail list logo
