You've started three separate threads to propose something that has exactly
zero chance of happening, and would be of limited use in uncommon cases.
And that would break literally billions of lines of working code.
If you want the modulo operator, you are more than welcome to use it. If
you want
I cannot speak for the Board, since I'm not currently on it. I think it's
*probable* they'd be willing to be a fiscal sponsor for PyInstaller, as
they have for some other things, but only if the developers really want
that. All that really gets is an ability for donators to flag funds as
This is called sys.version, right?
On Thu, Nov 19, 2020, 3:21 PM William Pickard wrote:
> TL/DR: A new built-in attribute who's purpose is to provide a simple way
> for developers to detect the Python implementation like CPython, JPython,
> IronPython and PyPy among other information.
>
> Ok,
I kinda like it. Definitely +0.0, maybe +0.5.
On Thu, Nov 12, 2020 at 2:46 PM Matt Wozniski wrote:
> if __main__:
>
> It would behave as though
>
> __main__ = (__name__ == "__main__")
>
> is executed in each module's namespace before executing it.
>
Some other commenters say they
On Fri, Oct 23, 2020, 1:28 PM Alex Hall
> Breaking millions of lines of idiomatic code seems like a bad idea.
>>
>> a, b, c = mydict
>>
>> Mary not be so very common, but this is ubiquitous:
>>
>> for k in mydict: ...
>>
>
> What I mean is that maybe `a, b = foo` could first test if `foo` is a
>
On Fri, Oct 23, 2020, 5:44 AM Alex Hall
> (Heretical question: do we *really* need to distinguish it in syntax?
> Iterator unpacking a dict seems like a dumb idea, I wouldn't be sad if we
> broke compatibility there)
>
Breaking millions of lines of idiomatic code seems like a bad idea.
a, b, c
See my very detailed posts on EXACTLY the concepts you discuss.
"whether 'bar' is a name"? It is definitely a name, what you have no means
> to know is whether it has been assigned a value. I suspect you're trying to
> do the thing some people do where they insist on 'name' to avoid using the
>
I really don't see this goal as general purpose enough to merit Python
syntax or standard library inclusion. Needing a PyPI package to do
something slightly uncommon really doesn't feel like a bad obstacle.
Click is perfectly great. It's a nice package for creating a certain kind
of command
On Thu, Oct 22, 2020 at 4:17 AM Guido van Rossum wrote:
> In terms of API, assuming functions, I think there are two basic models.
> We could have two (or more) functions that were related though:
>>
>> # E.g. pat_with_names = "{foo:f}/{bar:4s}/{baz:3d}"
>> matches = scan_to_obj(pat_with_names,
To bring it back to a concrete idea, here's how I see things:
1. The idea of f-string-like assignment targets has little support.
Only Chris, and maybe the OP who seems to have gone away.
2. The idea of a "scanning language" seems to garner a fair amount of
enthusiasm from everyone
On Wed, Oct 21, 2020, 7:21 PM Steven D'Aprano
> There's a middle ground of text parsing tasks that would seem to be a good
> match for some sort of scanner, inspired by C's scanf, whether it uses % or
> {} format codes.
>
Maybe COBOL PICTURE clauses.
Admittedly, I've never used COBOL, but I
On Wed, Oct 21, 2020, 12:12 AM Chris Angelico
> > But I think what you want is for the binding line never to raise, but
> also not to have any local means to know whether 'bar' is a name after that
> line. Or whether 'foo' is, for that matter.
>
> Easy: it always is. Whether it has had a value
On Tue, Oct 20, 2020, 9:17 PM Chris Angelico
> Please explain how it's "spooky action at a distance" if it's a
> self-contained assignment statement?
>
I'm not Steven, but I think I'm the first one in the thread to use
Einstein's phrase. As I understand your current semantics, that phrase is
not
On Wed, Oct 21, 2020 at 1:22 AM Steven D'Aprano wrote:
> I think we have at least six mini-languages now?
> - regexes
> - string interpolation with %
> - template strings
> - format mini-language
> - f-strings
> - date/time format strings
>
We also have the struct mini-language for interpreting
On Tue, Oct 20, 2020 at 8:41 PM Chris Angelico wrote:
> >> f"{spam:d} {eggs:d} {cheese:d}" = "123 456"
> >
> > Wow! That sure looks like a strong anti-pattern.
> >
> > If some variable was assigned somewhere very distant in the program
> flow, a parser might succeed where it would otherwise
On Tue, Oct 20, 2020 at 6:20 PM Chris Angelico wrote:
> spam = eggs = cheese = None
> f"{spam:d} {eggs:d} {cheese:d}" = "123 456"
>
Wow! That sure looks like a strong anti-pattern.
If some variable was assigned somewhere very distant in the program flow, a
parser might succeed where it would
On Sun, Oct 18, 2020, 6:04 PM Steven D'Aprano wrote:
> Oops, I messed up. (Thanks David for pointing that out.)
>
Yup. The below is all entirely correct. Still, as fun as transfinite set
theory is, these bits of it aren't actually relevant to Python and
IEEE-754.
It's enough just to note that
On Fri, Oct 16, 2020, 10:43 PM Steven D'Aprano
> > What manner of savages run a terminal without a multiplexer? :-)
>
I understand using screen or tmux when ssh'ing into a remote machine, but
> what advantage are they when you are using the local machine via a GUI?
>
It was definitely
On Fri, Oct 16, 2020, 10:16 PM Steven D'Aprano
> I think that if we go ahead with this, we shouldn't allow lack
> of support for screen and/or tmux to stand in the way. A 99% solution is
> better than a 0% solution :-)
>
What manner of savages run a terminal without a multiplexer? :-)
On Fri, Oct 16, 2020 at 9:36 PM Steven D'Aprano wrote:
> > Well, in terminals like bash, `clear` does not really delete the
> > previous input. It simply move the scroll so the first line of the
> > input is the current input.
>
> That's not actually correct: in bash, `clear` actually deletes
I agree with Guido here. Although I really don't care about the capability
myself, it feels like enough people do want a "clear screen" function...
and from the discussion, in feels like there are a LOT of variations in how
to do it across different operating systems, OS versions, terminals,
On Thu, Oct 15, 2020 at 2:16 PM Ram Rachum wrote:
> Your use case is valid, there are times in which I'd like a strong
> reference to be kept. But there are also lots of times I want it to not be
> kept. Then I would offer this feature as a flag `weakref=True` with a
> default of `False`. What
On Tue, Oct 13, 2020 at 7:02 PM Steven D'Aprano wrote:
> > I DID in the discussion, immediately think of making an exception a
> > dataclass, as someone else replied with. I guess if you want cargo in
> your
> > exception, that's a pretty good way to do it.
>
> "Cargo", that's an excellent
I teach a lot. But it's adults, and ones who have at least a little bit of
programming experience (perhaps in a different language, but something).
I've never had anyone request a "clear screen" command. Of course, I
usually use Jupyter notebooks for teaching, so I'm not sure what that would
On Tue, Oct 13, 2020 at 8:16 AM Ma Lin wrote:
> Zstd has some advantages: fast speed, multi-threaded compression,
> dictionary for small data, etc. IMO it's suitable as a replacement for
> zlib, but at this time:
> 1, If it is included into stdlib, it will take advantage of the huge
>
I've heard of this thing called "multiple inheritance" :-). Does that fit
into your naming scheme?
On Tue, Oct 13, 2020 at 2:03 PM wrote:
> I keep using a syntax of . for a reason.
> It is piggybacking on an already established exception and in reality just
> providing a sub-type that could
On Tue, Oct 13, 2020 at 1:56 PM wrote:
> I do agree that it is nice to have some ability to type the call more
> rigidly, just like a function call. I could see having functions,
> optionally, advertise exception calls as possible alternate returns but
> this should be just that, optional just
On Tue, Oct 13, 2020 at 1:21 PM Christopher Barker
wrote:
> On Tue, Oct 13, 2020 at 9:55 AM David Mertz wrote:
>
>> If you really want a snazzy highly-parameterized exception, write it
>> yourself as a class factory. I won't particularly like the antipattern,
>>
On Tue, Oct 13, 2020 at 6:18 AM Steven D'Aprano wrote:
> I don't think that a two line class (perhaps a couple of extra
> lines if you give it a docstring) justifies the name "boilerplate":
>
> class MySpecialException(Exception):
> pass
>
I think that in 22 years of using Python, I
On Mon, Oct 12, 2020, 9:50 AM Stephen J. Turnbull
> As far as what Steven discussed, the ordinal numbers have the same
> properties (except I've never heard of ω-1 in a discussion of ordinals, but
> it should work I think). (Maybe the surreals are constructed from the
> ordinals as the reals are
On Sun, Oct 11, 2020, 9:07 PM Steven D'Aprano
> Even in the cardinal numbers, two times infinity (aleph-0) is just
> aleph-0; however you might be pleased to know that two to the power of
> aleph-0 is aleph-1.
>
Oh... So you're one of those who believe the Continuum Hypothesis :-).
I was going
most
actual use cases:
try:
might_raise_OSError()
might_raise_ValueError()
might_raise_other()
except OSError as err:
pass
except ValueError:
pass
except:
oh_well()
On Sun, Oct 11, 2020, 1:05 PM Alex Hall wrote:
> On Sun, Oct 11, 2020 at 6:48 PM David Mertz wr
I'm not advocating for it (nor against it). But the OP proposes something
clear different from the example in current Python.
On Sun, Oct 11, 2020, 12:39 PM Wes Turner
> try:
> f = open('myfile.txt')
> s = f.readline()
> i = int(s.strip())
> except OSError as err:
> print("OS
ion to my example is that this sort of code does not
> belong in python and should be in a systems language, an argument I would
> agree with.
>
>
> -- Caleb Donovick
>
>
> On Wed, Oct 7, 2020 at 3:38 PM David Mertz wrote:
>
>> On Wed, Oct 7, 2020 at 6:24 PM Caleb
On Wed, Oct 7, 2020 at 6:24 PM Caleb Donovick
wrote:
> Itertools.count was an example (hence the use of "e.g.") of an iterator
> which can be efficiently
> advanced without producing intermediate state. Clearly anyone can advance
> it manually.
> My point is that an iterator may have an
On Tue, Oct 6, 2020, 1:21 PM Christopher Barker
> if you want to iterate through items N to the end, then how do you do that
> without either iterating through the first N and throwing them away, or
> making a slice, which copies the rest of the sequence?
>
it = (lst[i] for i in range(N,
On Wed, Sep 30, 2020 at 7:30 PM Greg Ewing
wrote:
> On 1/10/20 4:25 pm, David Mertz wrote:
> > In all the years I've used and taught namedtuples, I think I've never
> > used the ._replace() method. The leading underscore is a hint that the
> > method is "private"
On Wed, Sep 30, 2020 at 4:24 PM Ben Rudiak-Gould
wrote:
> On Wed, Sep 30, 2020 at 1:43 PM David Mertz wrote:
>
>> Fluent programming is uncommon in Python, and hence few methods return a
>> call of the same or similar type.
>>
>
> I think that if you include bu
-1.
Fluent programming is uncommon in Python, and hence few methods return a
call of the same or similar type. Methods on strings are an exception here,
but they are unusual (partly because strings are immutable).
Methods in Python tend to do one of two things:
1. Mutate in place, returning
On Tue, Sep 29, 2020, 2:41 PM Sebastian Kreft
> You mean that internally_inches means the stored values are in inches, and
> that by specifying a unit, you will scale up all the passed values?
>
> So that, internally_inches[4:6, 8:10, unit="meters"] = [[4, 2], [1, 3]]
> would save in the (4:6,
On Tue, Sep 29, 2020 at 12:09 PM Sebastian Kreft wrote:
> On Tue, Sep 29, 2020 at 6:56 PM David Mertz wrote:
>
>> I still think it would improve the PEP significantly if it added one case
>> of mixed positional/keyword indexing. Lots of suggestions have floated by,
>>
I still think it would improve the PEP significantly if it added one case
of mixed positional/keyword indexing. Lots of suggestions have floated by,
and I don't care which one is used, but something to demonstrate that
within the PEP.
On Tue, Sep 29, 2020 at 11:43 AM Guido van Rossum wrote:
>
On Sun, Sep 27, 2020 at 10:41 AM Stefano Borini
wrote:
> I kept the tuple as the accepted option, but I am personally open to
> NoIndex as well. I am not sure how the SC would take a non-hashable, new
> constant to be
> honest, for such a specific use case.
>
My "vote" is for NoIndex. I
None of the examples posted in use cases show combinations of position and
keyword indexing. This feels like an important example, and moreover
without it, the discussion of what sentinel to use is less motivated.
In discussions, I have mentioned two examples, e.g.
distances[4:7, 100:120,
On Sat, Sep 26, 2020 at 11:45 AM Nicholas Cole
wrote:
> > I think this is a very natural looking use case, and is not as well
> addressed by putting the multiplier outside the indexing. Imagine you have
> two arrays that store lengths, but not necessarily in the same units.
> Whatever the
On Sat, Sep 26, 2020 at 12:50 AM Stefano Borini
wrote:
> Other use cases are certainly allowed, but to me, something like
>
> a[1, 2, unit="meters"]
> a[1, 2, unit="meters"] = 3
makes me feel uncomfortable, although I might learn to accept it.
Then why isn't the unit close to 3, as in
>
>
On Fri, Sep 25, 2020, 5:49 PM Steven D'Aprano
> Since both None and () are likely to be legitimate indexes, and
> NotImplemented is less likely to be such, I think this supports using
> NotImplemented.
>
I think your arguments for NotImplemented vs None or () are solid. But I'm
having trouble
On Fri, Sep 25, 2020 at 4:36 PM Steven D'Aprano wrote:
> > I.e. consider:
> > >>> d = dict()
> > >>> d[()] = "foo"
> > >>> d
> > {(): 'foo'}
>
> I agree with Ricky that the choice of empty tuple should be justified
> better by the PEP, and alternatives (None, NotImplemented) discussed.
> But I
Is this a breaking change? It feels borderline.
Keyword-only subscripts are permitted. The positional index will be the
> empty tuple:
> obj[spam=1, eggs=2]
> # calls type(obj).__getitem__(obj, (), spam=1, eggs=2)
I.e. consider:
>>> d = dict()
>>> d[()] = "foo"
>>> d
{(): 'foo'}
I don't
I feel like this paragraph in the PEP goes a little bit too far, but I
understand its good intention.
The first difference is in meaning to the reader. A function call says
> "arbitrary function call potentially with side-effects". An indexing
> operation says "lookup", typically to point at a
Let's put it this way. If you can only support 3 compression algorithms in
the stdlib, which there would you choose? If only 4? If only 10?
Each one is concrete maintenance work. There's nothing *wrong* with any of
them, and someone uses each of the top 10 or 50. But some kind of cut-off
of
On Tue, Sep 22, 2020 at 11:55 PM Paul Moore wrote:
> The point of this request is that Python's packaging infrastructure is
> looking at what compression we use for wheels - the current
> compression is suboptimal for huge binaries like tensorflow. Packaging
> is in a unique situation, because
wrote:
>
> On Mon, 21 Sep 2020, 23:13 David Mertz, wrote:
>
> This is a silly proposal with absolutely zero benefit, none that I can
> even see purported in the suggestion itself, let alone in reality.
>
> Thank you for your thoughts but i guess
> this mail does not add anyt
This is a silly proposal with absolutely zero benefit, none that I can even
see purported in the suggestion itself, let alone in reality.
On Mon, Sep 21, 2020 at 8:47 AM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:
>
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about
On Fri, Sep 18, 2020, 2:22 AM Ricky Teachey
> On Fri, Sep 18, 2020, 6:35 AM Alex Hall
>
>> The point is that this:
>>
>
>> (a, b) = c
>>
>> is 'assigning to a literal' just as much as this:
>>
>> f"{a} {b}" = c
>>
>> Both are just things that look like expressions with dynamic values but
On Thu, Sep 17, 2020, 4:30 PM Steven D'Aprano wrote:
> On Thu, Sep 17, 2020 at 01:12:02PM -1000, David Mertz wrote:
> > I did actually "write the book" on text processing in Python. I think
> it's painful and awkward, and a terrible idea.
>
> *Text pr
On Thu, Sep 17, 2020, 4:04 PM Chris Angelico
> > >>> my_string = "It might be 11:45 PM"
> > >>> # ... many lines later ...
> > >>> f"It is {hh}:{mm} {am_or_pm}" = my_string
> >
> > What are hh, mm, and am_or_pm now? Do we raise an exception? Do we run
> the line having no real idea whether they
On Thu, Sep 17, 2020 at 2:31 PM Dennis Sweeney
wrote:
> I was definitely not proposing "spooky action at a distance". My proposal
> is to existing f-strings as the `__setattr__` protocol is to the
> `__getattr__` protocol. The template would only ever be hard-coded inline
> during the f-string
This library I like!
It's very similar to the hypothetical 'template()' function I mention in my
other email. But this doesn't mess with Python's model of assignment
targets, names, etc.
I haven't seen this before, but I want to play around with it.
On Thu, Sep 17, 2020, 1:24 PM Wes Turner
I did actually "write the book" on text processing in Python. I think it's
painful and awkward, and a terrible idea.
On Thu, Sep 17, 2020, 1:00 PM Chris Angelico wrote:
> On Fri, Sep 18, 2020 at 8:54 AM Ben Rudiak-Gould
> wrote:
> > This is a terrible idea.
>
> Python is an excellent language
On Thu, Sep 17, 2020, 2:36 AM Dennis Sweeney
wrote:
> >>> f"It is {hh}:{mm} {am_or_pm}" = "It is 11:45 PM"
> >>> f"It is {hh}:{mm} {am_or_pm}" == "It is 11:45 PM"
I cringe at every part of this proposal. But this is especially perplexing.
How can it POSSIBLY work, unless we have
Thanks so much Ben for documenting all these examples. I've been frustrated
by the inconsistencies, but hasn't realized all of those you note.
It would be a breaking change, but I'd really vastly prefer if almost all
of those OverflowErrors and others were simply infinities. That's much
closer to
Yes, that is a design flaw in the stdlib. There ought to be an opt-in
switch for accepting/producing those special values, not the current
opt-out for strictness... And the misnamed parameter is 'allow_nan' whereas
it also configures 'Infinity'.
On Sun, Sep 13, 2020, 3:16 PM Matthias Bussonnier <
On Sun, Sep 13, 2020 at 8:59 AM Christopher Barker
wrote:
> On Sun, Sep 13, 2020 at 7:58 AM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> > encoding=None: this is the important one -- json is always UTF-8 yes?
>>
>> Standard JSON is always UTF-8. Nevertheless, I'm
sly, this is a very advanced use case, probably not worth
> Python guaranteeing such behavior.
> Here is one article:
> https://brionv.com/log/2018/05/17/javascript-engine-internals-nan-boxing/
>
> On Sat, Sep 12, 2020, 8:10 PM David Mertz wrote:
>
>> On Sat, Sep
On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano wrote:
> In general though, Python doesn't support generating the full range of
> NANs with payloads directly.
I've researched this a little bit for discussion in a book I'm writing, and
I have not been able to identify ANY widely used programming
On Fri, Sep 11, 2020, 12:59 PM Guido van Rossum wrote:
> What happened to "not every three-line function needs to be a built-in"?
> This is *literally* a three-line function. And I know the proposal is not
> to make it a builtin, but still... ISTM down here lies the path to PHP.
>
By the same
I like the idea of having these functions, but I don't like overloading the
argument to a function with "filename or file-like object" as is common in
libraries like Pandas. I think there are a few places the standard library
does it, but the separation seems better to me.
I don't LOVE the names
On Fri, Sep 11, 2020 at 10:19 AM Guido van Rossum wrote:
> While one may argue that writing `1e1000` is not an "arithmetic
> operation", certainly it's certainly not "casting strings to floats", and
> it's the simeplest way of producing `inf` in a pinch (in theory it's not
> portable, but I
On Fri, Sep 11, 2020 at 8:58 AM Guido van Rossum wrote:
> What's wrong with 1e1000?
>
As a spelling of "infinity" generically, or just as an example of an
"arithmetic operation"?
On the latter, I didn't use that just because it feels sort of like a
"cheat" rather than an "operation." I.e. my
On Fri, Sep 11, 2020 at 6:48 AM Stephen J. Turnbull
> inf and nan only exist in Python the
>
language (including builtins) via casting strings to floats (there are
> no arithmetic operations that produce them).
>>> import sys; sys.version
'3.8.3 (default, May 19 2020, 18:47:26) \n[GCC 7.3.0]'
On Sat, Sep 5, 2020 at 7:26 PM Greg Ewing
wrote:
> On 6/09/20 8:08 am, David Mertz wrote:
> > The only real goal I've seen is that you hope that `x == eval(repr(x))`
> > for floating point numbers. But that is doomed to failure since it
> > cannot work for NaN by its v
it should be a constant
> rather than a function call to retrieve the value
>
> On Sat, Sep 5, 2020, 4:08 PM David Mertz wrote:
>
>> On Sat, Sep 5, 2020 at 3:39 PM Cade Brown wrote:
>>
>>> The fact that so many modules and packages must define an 'inf' is, to
>>>
On Sat, Sep 5, 2020 at 3:39 PM Cade Brown wrote:
> The fact that so many modules and packages must define an 'inf' is, to me,
> a signal that such a constant WOULD be useful. All of them (should) be
> referring to the same value, anyways, so why not make a global constant
> instead?
>
`pi` is a
Thank you Steven,
This exactly matches what my goal would be, except the below.
On Tue, Sep 1, 2020 at 11:45 AM Steven D'Aprano wrote:
> (8) Dict unpacking is permitted:
>
> items = {'spam': 1, 'eggs': 2}
> obj[index, **items]
> # equivalent to obj[index, spam=1, eggs=2]
>
I would
> On 30/08/20 3:06 pm, Steven D'Aprano wrote:
> (There are a few gray areas, such as array/matrix/vector addition, which
> sneak into the "acceptable" area by virtue of their long usage in
> mathematics.)
>
>>> a / b/ c
0.01
>>> home / 'git' / 'pip'
On Sat, Aug 29, 2020, 10:30 PM Steven D'Aprano wrote:
> I expect that the first will be the most common. If we add a keyword to
> the subscript:
>
> obj[1, a=3]
>
> I would expect that the it turns into `__getitem__(1, a=3)` which is
> almost surely what the reader and coder expects. It
On Fri, Aug 28, 2020 at 4:30 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > > Suppose we didn't have dict.get(). I would then probably write:
> > > val = mydict[key] if key in mydict else None
> > >
> > > Likewise, since we don't have list.get(), I would write:
On Fri, Aug 28, 2020 at 4:30 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > tuple, or dict themselves. So `mylist[99, default=4]` would still
> > be a syntax error (or maybe a different exception).
>
> I don't think it can be a SyntaxError because you can't always
On Thu, Aug 27, 2020, 1:35 PM Ricky Teachey
> Conceptually, an "immutable collection" serves a different purpose than "a
>> collection of axes", even if they work then same under the hood.
>>
>
> What about something like this:
>
> class Name(NamedTuple):
> first: str
> last: str
>
> d =
On Thu, Aug 27, 2020, 1:15 PM Christopher Barker
> I agree -- this is very much a feature for third party packages -- or
> *maybe* some future stdlib class, but the builtins are fine as they are.
>
> In fact, I don't think there's a single use of a tuple of indexes (meaning
> something other than
On Thu, Aug 27, 2020 at 11:37 AM M.-A. Lemburg wrote:
> Asking a dict d of potentially any number of items for
> existence of a particular item x is somewhat different than asking
> a list l of a certain length i for the item at position i+1.
>
Suppose we didn't have dict.get(). I would then
On Thu, Aug 27, 2020 at 10:51 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> They're going to get one, is my reading of the "named indicies"
> thread. That is, it looks to me very likely that index notation
> (`x[i]`) is going to support keyword arguments (`x[i, k=v]`).
On Wed, Aug 26, 2020 at 4:01 PM Christopher Barker
wrote:
> Yes, it's slightly funny that square brackets convert to `index` rather
>> than `*index`, but that ship sailed very long ago, and it's no big deal.
>> There's no problem that needs solving and no need for code churn.
>>
> TL;DR -- let's
I think this method would be useful for list itself (maybe tuple, but I
care less about that). It certainly should not be part of the Sequence
protocol.
I have often programmed a pattern where I .append() elements to a list in a
loop, and *expect* at least N things to make it in. In such case,
In my mind, *anything* other than the straightforward and obvious signature
`__getitem__(self, index, **kws)` is a pointless distraction.
We don't need new custom objects to hold keywords. We don't need funny
conditional logic about one versus multiple index objects. We don't need
some other
On Tue, Aug 25, 2020 at 2:26 AM Christopher Barker
wrote:
> As for "why not" not being a motivator -- I agree, I posted it that easy
> because this conversation has brought up a number of examples where slice
> syntax is nice to use. And David Mertz pointed out, both nump
tions make overall performance
> better. I don't know how 'objective' we can be here without discussing
> specific data sets people may be using.
>
> On Mon, Aug 24, 2020, 7:15 PM David Mertz wrote:
>
>> The main purpose of sets is FAST membership testing. Everything I've seen
The main purpose of sets is FAST membership testing. Everything I've seen
in prior discussions convinced me that preserving insertion order would
slow that down.
If membership testing lost even 10% speed, I would be -1000 on the idea. If
someone comes up with actual working code that is no more
On Mon, Aug 24, 2020 at 12:43 AM Christopher Barker
wrote:
> Why not allow slice syntax as an expression everywhere? Everywhere I’ve
> tried, it’s a syntax error now, but is there any technical reason that it
> couldn’t be used pretty much anywhere?
>
How often do you do this?
>>> class Slice:
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
The more this discussion goes on, the more convinced I am of my initial
opinion. A matrix library doesn't belong in the standard library.
What is happening in the discussion is that each potential user who
comments finds some related capability that is relevant to their particular
needs. But the
On Sat, Aug 15, 2020 at 4:38 PM Caleb Donovick
wrote:
> > Why would it require a metaclass? Rather than just: ...
>
> Because I want the following to be true:
> x = Struct[x=int, y=str](...)
> assert isinstance(x, Struct)
> assert isinstance(x, Struct[x=int, y=str])
> assert not isinstance(x,
On Fri, Aug 14, 2020, 7:53 PM Caleb Donovick
wrote:
> > I don't see what that can possible get you that `Struct(x=int, y=str)`
> doesn't.
>
> Using `Struct(x=int, y=str)` requires a metaclass, where `Struct[x=int,
> y=str]` does not.
>
Why would it require a metaclass? Rather than just:
class
On Fri, Aug 14, 2020, 7:39 PM Caleb Donovick
> class T(Protocol):
> x: int
> y: str
> # with some abuse of notation obviously these would generate unique
> typesassert T == Struct[x=int, y=str]
>
> I don't see what that can possible get you that `Struct(x=int, y=str)`
doesn't.
I'm +0 on
This is a lot to add to Python itself to poorly reproduce well-tested
functionally in a very popular library. There are many Python distributions
that come with that extra battery included, just not the one from the PSF.
On Thu, Aug 13, 2020, 6:20 PM Stefano Borini
wrote:
> Excuse me if I am
The start/stop/step sound like they might be nice. But that wouldn't give
you a length, since you never know when an iterator will be exhausted. I
feel like `len(islice(it, 1, 1_000_000))` telling you the "maximum possible
length" is more a danger than a help.
On Wed, Aug 12, 2020 at 4:41 AM
On Mon, Aug 10, 2020 at 9:05 AM Alex Hall wrote:
> Yes, we can implement things in Python that aren't allowed in formal
> mathematics and some fun questions arise. What should `set.UNIVERSAL in
> set.UNIVERSAL` return? Bertrand Russell thinks it's False.
>
Well... Russell thinks that the answer
On Sun, Aug 9, 2020, 12:07 AM Steven D'Aprano
> > [*] For languages with bounded data types, this is more compelling. If
> I think a variable will *definitely* fit in a uint8, having the static tool
> tell me it might not is powerful.
>
> uint8 = int[0:256]
>
> So if it's useful to know that
On Sat, Aug 8, 2020, 7:40 PM Steven D'Aprano
> Any checker capable of doing bounds checks would know that the range of
> possible ints is unbounded in both directions, and therefore an int does
> not fit into the range [1:10**9]. Hence that will be a static bounds
> check failure:
Just so you
301 - 400 of 1105 matches
Mail list logo
