Well, "up" it's used in forums to draw attention :)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
On Mon, Aug 17, 2020 at 10:46:58AM +0200, Marco Sulla wrote:
> Well, "up" it's used in forums to draw attention :)
My ex-boss used to do the same thing except he would use "ping" to get
attention.
But in his case he would quote his previous (unanswered) question, so
that we would at least know
On Sun, Aug 16, 2020 at 12:07:47PM -0700, Guido van Rossum wrote:
[...]
> So I probably would be okay with allowing `obj[]` syntactically, as long as
> the dict type could be made to reject it.
I don't absolutely hate the idea, but I do feel that it's semantically
rather dubious. `obj` with no s
On Sun, Aug 16, 2020 at 11:18:40AM -0700, Guido van Rossum wrote:
> > Just to clarify here, I assume you mean that if xarray cares about
> > order-preserving keywords, they should write their methods this way:
> >
> > def __getitem__(self, index=None, **kwargs):
> >
> > rather than mandating t
On Sat, 15 Aug 2020 19:27:24 -0700
Guido van Rossum wrote:
> On Sat, Aug 15, 2020 at 7:14 PM Caleb Donovick
> wrote:
>
> > > To me, the main weakness here is that you couldn't move forward with
> > this unless you also got the various static type checkers on board. But I
> > don't think those
On Mon, Aug 17, 2020 at 7:16 PM Steven D'Aprano wrote:
>
> On Mon, Aug 17, 2020 at 10:46:58AM +0200, Marco Sulla wrote:
> > Well, "up" it's used in forums to draw attention :)
>
> My ex-boss used to do the same thing except he would use "ping" to get
> attention.
>
> But in his case he would quote
On 17/08/20 9:58 pm, Antoine Pitrou wrote:
Probably because exploiting Python abstraction facilities to build DSLs
has/had long been frown upon in this community? That was the leitmotiv
back when people were marvelling over Ruby's flexibility in the area.
As far as I remember, what was frowned
On Mon, 17 Aug 2020 22:54:32 +1200
Greg Ewing wrote:
> On 17/08/20 9:58 pm, Antoine Pitrou wrote:
> > Probably because exploiting Python abstraction facilities to build DSLs
> > has/had long been frown upon in this community? That was the leitmotiv
> > back when people were marvelling over Ruby's
Dear python developers,
As a bioinformatician I work a lot with gzip-compressed data. Recently I
discovered Intel's Storage Acceleration Libraries at
https://github.com/intel/isa-l. These people implemented the DEFLATE and
INFLATE algorithms in assembly language. As a result it is much faster t
On Mon, 17 Aug 2020 08:49:23 -
"Ruben Vorderman" wrote:
> Dear python developers,
>
> As a bioinformatician I work a lot with gzip-compressed data. Recently I
> discovered Intel's Storage Acceleration Libraries at
> https://github.com/intel/isa-l. These people implemented the DEFLATE and
>
On Mon, Aug 17, 2020 at 10:48 PM Ruben Vorderman
wrote:
>
> Dear python developers,
>
> As a bioinformatician I work a lot with gzip-compressed data. Recently I
> discovered Intel's Storage Acceleration Libraries at
> https://github.com/intel/isa-l. These people implemented the DEFLATE and
> IN
Antoine Pitrou schrieb am 17.08.20 um 15:00:
> On Mon, 17 Aug 2020 08:49:23 -
> "Ruben Vorderman" wrote:
>> Dear python developers,
>>
>> As a bioinformatician I work a lot with gzip-compressed data. Recently I
>> discovered Intel's Storage Acceleration Libraries at
>> https://github.com/inte
On Mon, Aug 17, 2020 at 04:08:54PM +0200, Stefan Behnel wrote:
> I re-opened the ticket to allow for some discussion over there in order to
> understand the implications better. But I agree that a third-party package
> on PyPI seems like a good first step, also as a backport.
Perhaps I have misun
Steven D'Aprano schrieb am 17.08.20 um 17:00:
> On Mon, Aug 17, 2020 at 04:08:54PM +0200, Stefan Behnel wrote:
>
>> I re-opened the ticket to allow for some discussion over there in order to
>> understand the implications better. But I agree that a third-party package
>> on PyPI seems like a good
On Tue, Aug 18, 2020 at 1:05 AM Steven D'Aprano wrote:
>
> On Mon, Aug 17, 2020 at 04:08:54PM +0200, Stefan Behnel wrote:
>
> > I re-opened the ticket to allow for some discussion over there in order to
> > understand the implications better. But I agree that a third-party package
> > on PyPI seem
On Mon, Aug 17, 2020 at 8:42 AM Chris Angelico but does it have a compatible API? If it does - if you can drop it in
>
> and everything behaves equivalently - then it sounds like the sort of
>
> thing that can be included in Python 3.10 with minimal fuss.
I’m confused - if it is fully compatible
On Tue, Aug 18, 2020 at 3:00 AM Christopher Barker wrote:
>
> On Mon, Aug 17, 2020 at 8:42 AM Chris Angelico >
>> but does it have a compatible API? If it does - if you can drop it in
>>
>> and everything behaves equivalently - then it sounds like the sort of
>>
>> thing that can be included in Py
The fact of the matter is that you need (at least) two things to get
something new into Python:
1) a good idea that folks will support
2) A "champion" -- someone to keep the conversation going, maybe write a
PEP, etc.
No matter how great an idea is, it takes a lot of work to get it to a
consensu
RE: empty subscripts:
Should something[] be allowed syntax?
TL;DR: no
In a way this comes down to design philosophy vs implementation.
>From an implementation perspective, the [] operator is another way to call
__getitem__ and __setitem__. And from that perspective, why not have it act
like a f
Here's a few words on whether we should allow and whether we can forbid:
>>> something[]
First, in
>>> something[x=1]
what I call the argv is empty, as it is with
>>> something[]
If we represent an empty argv by passing the empty tuple () to __getitem__,
then how are
>>> something
Ugh. It is becoming gradually clear to me that obj[] should be a syntax
error. We should definitely not indulge in obj[-] or {-}.
On Mon, Aug 17, 2020 at 11:41 AM Jonathan Fine wrote:
> Here's a few words on whether we should allow and whether we can forbid:
> >>> something[]
>
> First, in
>
On Mon, 17 Aug 2020 at 11:17, Steven D'Aprano wrote:
> Did you have a specific question to be answered or are you just hoping
> to get people interested in the proposal?
It seems I have to repost the proposal I already wrote...
My proposal is to add a way for third party modules to add custom
ke
Please try to learn how to write a good proposal. A few examples, like you
did here, just isn't enough. It's worth doing right, and it's worth
*learning* how to do it right.
On Mon, Aug 17, 2020 at 1:03 PM Marco Sulla
wrote:
> On Mon, 17 Aug 2020 at 11:17, Steven D'Aprano wrote:
> > Did you hav
On Tue, Aug 18, 2020 at 6:01 AM Marco Sulla
wrote:
>
> On Mon, 17 Aug 2020 at 11:17, Steven D'Aprano wrote:
> > Did you have a specific question to be answered or are you just hoping
> > to get people interested in the proposal?
>
> It seems I have to repost the proposal I already wrote...
>
> My
On Mon, Aug 17, 2020 at 5:02 PM Marco Sulla
wrote:
> On Mon, 17 Aug 2020 at 11:17, Steven D'Aprano wrote:
> > Did you have a specific question to be answered or are you just hoping
> > to get people interested in the proposal?
>
> It seems I have to repost the proposal I already wrote...
> My
On 18/08/20 6:00 am, Christopher Barker wrote:
But from a language design perspective, the [] operator is a way to
"index" a container -- get part of the container's contents. And from
this perspective, no index makes no sense.
It can make sense if you have a zero-dimensional array. Or as much
On 18/08/20 6:37 am, Jonathan Fine wrote:
if
>>> something[*argv]
is allowed, then what was a syntax error becomes a run-time error.
I don't think so. If argv is empty, this is more akin to
x = ()
something(x)
which we presumably still want to allow.
Opponents of a[] aren't trying
On 18/08/20 7:58 am, Marco Sulla wrote:
My proposal is to add a way for third party modules to add custom
keywords. Example:
from mykeywords import @const
@const a = 1
What would that mean?
--
Greg
___
Python-ideas mailing list -- python-ideas@pytho
On Mon, Aug 17, 2020 at 8:02 AM Steven D'Aprano wrote:
> Perhaps I have misunderstood, but isn't this a pure implementation
> change, with no user visible API changes and backward compatible output?
>
According to the documentation [1], it only supports compression levels
0-3. They're supposed t
On Mon, 17 Aug 2020 at 22:10, Guido van Rossum wrote:
>
> Please try to learn how to write a good proposal. A few examples, like you
> did here, just isn't enough. It's worth doing right, and it's worth
> *learning* how to do it right.
Well, I'll try.
In pure python, you can change everything.
Testing myself on a large fasta file, I find far faster performance with
igzip, but also far lower compression rate (than gzip -6, the default).
My gzipped fasta is nearly half the size of igzip at its -3 maximum. I
haven't tried 'gzip -3' to compare that size.
This limitation seems to limit this
31 matches
Mail list logo
