On Fri, 8 Jan 2021 at 22:25, Greg Ewing wrote:
>
> On 9/01/21 10:19 am, Ram Rachum wrote:
> > In short, I want `reversed(itertools.chain(x, y, z))` that behaves like
> > `itertools.chain(map(reversed, (z, y, x)))`.
>
> I think you mean `itertools.chain(*map(reversed, (z, y, x)))`
>
> You can get t
On Sun, 7 Feb 2021 at 23:55, Greg Ewing wrote:
>
> On 8/02/21 6:59 am, Christopher Barker wrote:
>
> > I find myself reading entire files into memory and then processing
> > them, so as to avoid having to extra-indent all the processing code.
>
> I don't know why some people seem to be so afraid o
On Fri, 26 Feb 2021 at 02:49, Stephen J. Turnbull
wrote:
>
> David Mertz writes:
> > On Wed, Feb 24, 2021 at 1:38 PM Paul Korir wrote:
> >
> > > I've been using the argparse library for a long time and one use case
> that
> > > repeatedly shows us is the need to have two arguments appear tog
On Sun, 11 Apr 2021 at 10:25, Stéfane Fermigier wrote:
>
> On Sat, Apr 10, 2021 at 9:08 PM Guido van Rossum wrote:
>>
>>
>> I owe you an answer here. For large projects with long lifetimes that expect
>> their API to evolve, experience has taught that any part of the API that
>> *can* be used
On Mon, 12 Apr 2021 at 21:27, Brendan Barnwell wrote:
>
> On 2021-04-12 03:13, Stéfane Fermigier wrote:
> > The public API of a library is the one which is documented as
> > such.
> >
> > Right, except that in practice:
> >
> > 1) Many useful libraries are not documented or properly docume
On Fri, 14 May 2021 at 19:41, Paul Moore wrote:
>
> On Fri, 14 May 2021 at 16:54, Martin Teichmann
> wrote:
> > That is absolutely what I would like to have. The fractions module is very
> > small, it can easily be made a builtin. This would also speed it up
> > significantly, I hope. Probably
On Sat, 15 May 2021 at 09:55, Steven D'Aprano wrote:
>
> On Sat, May 15, 2021 at 07:14:47AM -, Martin Teichmann wrote:
>
> > In general, doing symbolic math in Python is not very beautiful.
> [...]
> > It could be fruitful to add syntax for symbolic math, but this is a
> > whole new topic. Loo
On Sat, 15 May 2021 at 12:52, Steven D'Aprano wrote:
>
> On Fri, May 14, 2021 at 09:39:33PM +0100, Oscar Benjamin wrote:
>
> > Yes, but having a faster fraction type would be great. SymPy doesn't
> > actually use the fractions module because it's too slow
On Sat, 15 May 2021 at 05:54, Steven D'Aprano wrote:
>
> On Sat, May 15, 2021 at 01:57:29AM +1000, Chris Angelico wrote:
>
> > Decimal literals have a number of awkward wrinkles, so I'd leave them
> > aside for now;
>
> I'm surprised at this.
>
> Decimal literals have come up at least twice in the
On Sat, 15 May 2021 at 20:52, David Mertz wrote:
>
> On Sat, May 15, 2021, 3:13 PM Oscar Benjamin
>>
>> That would mean that a simple statement like x = -1.01d could assign
>> different values depending on the context. Maybe with the new parser it is
>> easier t
On Tue, 18 May 2021 at 11:41, Stephen J. Turnbull
wrote:
>
> Christopher Barker writes:
>
> > Python assumes, and converts to, floats all over the place. So users need
> > to understand and accommodate the limitations of floats anyway. Having
> > exact fractions in seemingly arbitrary places w
On Tue, 18 May 2021 at 15:56, Paul Moore wrote:
>
> On Tue, 18 May 2021 at 15:16, Martin Teichmann
> wrote:
> >
> > Because reality. People would like to write 1/2 * m * v**2 to mean the
> > obvious thing, without having to think about the details. And there are
> > many people like this, this
On Wed, 19 May 2021 at 07:41, Martin Teichmann
wrote:
>
> Hi list,
>
> as you might have noticed, I am trying to improve the syntax and semantics
> for symbolic math in Python. Until now, I have to say, my ideas were not that
> well received, but I learned from the discussion and maybe this time
On Tue, 25 May 2021 at 13:31, Sergey B Kirpichev wrote:
>
> > >>> solve(x**2 == 1/2)
> > as you might notice, this is fully legal Python syntax. Unfortunately
> > the semantics is such that sympy has no way to determine what is
> > actually going on, this is why they invented all those helper
> >
On Mon, 31 May 2021 at 13:10, Neil Girdhar wrote:
>
> Have you considered using the JAX library's trick of decorating functions to
> provide automatic symbols?
>
> For example, your problem could be done in current Python with an
> appropriately-coded library:
>
> @symbolic
> def f(x, a, b, c):
On Tue, 1 Jun 2021 at 05:16, Neil Girdhar wrote:
>
> Hi Oscar,
>
> The problem that the original poster was trying to address with
> additional syntax is the automatic naming of symbols. He wants to
> omit this line:
>
> x = symbols("x")
>
> You're right that if you have many one-character symbol
On Tue, 1 Jun 2021 at 10:53, Neil Girdhar wrote:
>
> On Tue, Jun 1, 2021 at 5:39 AM Oscar Benjamin
> wrote:
> >
> > On Tue, 1 Jun 2021 at 05:16, Neil Girdhar wrote:
> > >
> > > Hi Oscar,
> > >
> > > The problem that the original poster
On Sun, 20 Jun 2021 at 23:29, Greg Ewing wrote:
>
> On 21/06/21 6:04 am, Sebastian Berg wrote:
> > * `flatten()` (alwasy copy)
> > * `ravel()` (copies if needed, and additionally ensures contiguity)
> > * `reshape(-1)` (copies if needed)
> >
> > They are all subtly different, unfortunately.
>
> Th
On Sat, 26 Jun 2021 at 01:23, Eric V. Smith wrote:
>
> On 6/25/2021 8:09 PM, Steven D'Aprano wrote:
> > Hi Thomas,
> >
> > On Fri, Jun 25, 2021 at 09:06:58AM -, Thomas Grainger wrote:
> >
> >> I'd like invalid attribute assignment to be prevented at runtime
> > Are you making a specific reques
On Thu, 29 Jul 2021 at 16:00, Paul Moore wrote:
>
> On Thu, 29 Jul 2021 at 15:39, Leonardo Freua
> wrote:
> >
> > Would it be interesting to create a @deprecated decorator to avoid adding
> > warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in
> > methods body?
>
> I don't
On Wed, 1 Sept 2021 at 01:20, Matthias Bussonnier <
[email protected]> wrote:
> > Are there other such classes?
>
[snip]
> ... stuff, let's pick a few:
>
> sympy.physics.optics.Medium:
>
> def __eq__(self, other):
> return self.refractive_index == other.refractive_index
>
>
On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka wrote:
>
> There are two different kinds of TypeError: if the end user passes an
> instance of wrong type and if the author of the library makes an error
> in implementation of some protocols.
>
> For example, len(obj) raises TypeError in two cases: i
On Fri, 3 Sept 2021 at 17:32, Guido van Rossum wrote:
>
> On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin
> wrote:
>>
>> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka wrote:
>> >
>> > There are two different kinds of TypeError: if the end user passes an
On Mon, 6 Sept 2021 at 01:13, Greg Ewing wrote:
>
> On 6/09/21 3:07 am, C. Titus Brown via Python-ideas wrote:
> > with csv.DictReader.open(filename) as r:
> > for row in r:
> >…
>
> You can do this now:
>
> from contextlib import closing
> with closing(csv.DictReader.open(filename)) a
On Thu, 16 Sept 2021 at 19:34, Jonatan wrote:
> Currently, math.factorial only supports integers and not floats, whereas
> the "mathematical" version supports both integers and floats.
> I.e:
> ```
> import math
>
>
> def better_factorial(n):
> return n * math.gamma(n)
>
> print(math.factoria
On Sun, 10 Oct 2021 at 04:56, Steven D'Aprano wrote:
> On Fri, Oct 08, 2021 at 01:42:35PM -0700, Christopher Barker wrote:
>
> > Anyway, I do see the benefit of adding first() to itertools -- there
> really
> > is a key problem with:
> >
> > next(iter(an_iterable))
> >
> > for newbies -- you can
On Tue, 12 Oct 2021 at 11:48, Chris Angelico wrote:
> On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
> wrote:
> > A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
> attempted to solve this by turning StopIteration into RuntimeError if it
> gets caught
On Tue, 12 Oct 2021 at 12:50, Chris Angelico wrote:
>
> On Tue, Oct 12, 2021 at 10:24 PM Oscar Benjamin
> wrote:
> >
> > On Tue, 12 Oct 2021 at 11:48, Chris Angelico wrote:
> >>
> >> ValueError is no safer. The first() function would have, as its API,
&g
On Wed, 13 Oct 2021 at 18:30, Chris Angelico wrote:
>
> On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
> wrote:
> > Your suggestion is that this is a bug in map() which is a fair
> > alternative view. Following through to its conclusion your suggestion
> > is that e
On Thu, 2 Dec 2021 at 17:28, Chris Angelico wrote:
>
> On Fri, Dec 3, 2021 at 4:22 AM Nicholas Cole wrote:
> > There is nothing that this proposal makes possible that is not already
> > possible with more explicit code.
>
> It's worth noting that "explicit" does not mean "verbose". For
> instance
On Mon, 17 Jan 2022 at 00:46, Christopher Barker
wrote:
> I’m a bit confused — would adding a “literal” form for frozenset provide
> much, if any, of an optimization? If not,
> that means it’s only worth doing for convenience.
>
> How often do folks need a frozen set literal? I don’t think I’ve
On Thu, 20 Jan 2022 at 10:19, Ricky Teachey wrote:
> On Thu, Jan 20, 2022 at 3:35 AM Stephen J. Turnbull <
> [email protected]> wrote:
>
>> Christopher Barker writes:
>>
>> > If this does all come to pass, then:
>> >
>> > s = {3,8,2}.frozen()
>> > will be slightly faster, in some cas
On Fri, 21 Jan 2022 at 12:15, Chris Angelico wrote:
>
> On Fri, 21 Jan 2022 at 22:52, Oscar Benjamin
> wrote:
> >
> > I really don't understand (having read everything above) why anyone prefers
> > {1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from som
On 30 July 2018 at 20:15, Rudy Matela wrote:
> Hello,
Hi Rudy,
> Do you think it would be nice to allow with statements inside genexps or
> list comprehensions? The functions __enter__ and __exit__ would be
> automatically called as iterables are traversed. I am thinking of
> drafting a PEP ab
On 8 August 2018 at 08:48, Nathaniel Smith wrote:
> On Tue, Aug 7, 2018 at 11:14 PM, Ken Hilton wrote:
>>
>> Now, let's take a look at the following scenario:
>>
>> def read_multiple(*filenames):
>> for filename in filenames:
>> with open(filename) as f:
>>
On 8 August 2018 at 07:32, Chris Angelico wrote:
> On Wed, Aug 8, 2018 at 4:14 PM, Ken Hilton wrote:
>>
>> Now, let's take a look at the following scenario:
>>
>> def read_multiple(*filenames):
>> for filename in filenames:
>> with open(filename) as f:
>> y
On 8 August 2018 at 15:22, Ronald Oussoren via Python-ideas
wrote:
>>
>> On 08/08/18 07:14, Ken Hilton wrote:
>>> Now, let's take a look at the following scenario:
>>> def read_multiple(*filenames):
>>> for filename in filenames:
>>> with open(filename) as f:
>>>
On 8 August 2018 at 15:37, Oscar Benjamin wrote:
> On 8 August 2018 at 15:22, Ronald Oussoren via Python-ideas
> wrote:
>>
>> It is also possible to fix the particular issue by using another with
>> statement, that is use:
>>
>> with contextlib.closing(re
On Tue, 28 Aug 2018 at 08:12, Jacco van Dorp wrote:
>
> Op ma 27 aug. 2018 om 23:18 schreef James Lu :
>>
>> > As Matthew points out, you could use numpy.array. Or code your own
>> > class, by providing __add__ and __iadd__ methods.
>>
>> I could, but I don't think that justifies not having this f
On Thu, 30 Aug 2018 at 17:36, Stephan Houben wrote:
>
> I would also like to point out that the current behavior of Fraction
> is consistent with other parts of the numeric system, e.g.
> 1/1 produces 1.0 (rather than 1)
> math.sqrt(4) produces 2.0 (rather than 2)
> 1j-1j produces 0j (rather than
On Sat, 29 Sep 2018 at 19:38, Steve Barnes wrote:
>
> On 29/09/2018 09:56, Serhiy Storchaka wrote:
> > 29.09.18 11:43, Steve Barnes пише:
> >> On 29/09/2018 08:50, Serhiy Storchaka wrote:
> >>> Python is dynamically typed language. What is such processing that would
> >>> work with iNaN, but doesn
On Sun, 30 Sep 2018 at 02:01, Steven D'Aprano wrote:
>
> On Sat, Sep 29, 2018 at 09:43:42PM +0100, Oscar Benjamin wrote:
> > On Sat, 29 Sep 2018 at 19:38, Steve Barnes wrote:
>
> > > > I converted to int because I needed a whole number, this was intended to
&
On Mon, 1 Oct 2018 at 00:00, Chris Angelico wrote:
>
> On Mon, Oct 1, 2018 at 8:53 AM Oscar Benjamin
> wrote:
> >
> > On Sun, 30 Sep 2018 at 02:01, Steven D'Aprano wrote:
> > >
> > > On Sat, Sep 29, 2018 at 09:43:42PM +0100, Oscar Benjamin wrote:
On Mon, 7 Jan 2019 at 09:27, Chris Angelico wrote:
>
> On Mon, Jan 7, 2019 at 7:11 PM Anders Hovmöller wrote:
> >
> >
> > > This proposal is basically about introducing goto to the language.
> >
> > A bit hyperbolic but I agree that it has the same problem as goto. But the
> > specific suggested
On Wed, 9 Jan 2019 at 05:20, Steven D'Aprano wrote:
>
> On Mon, Jan 07, 2019 at 11:27:22AM +1100, Steven D'Aprano wrote:
>
> [...]
> > I propose adding a "nan_policy" keyword-only parameter to the relevant
> > statistics functions (mean, median, variance etc), and defining the
> > following polici
On Sun, 5 May 2019 at 11:08, Luca Baldini wrote:
>
> Hi here,
> I wonder if the idea of adding to the statistics module a class to
> calculate the running statistics (average and standard deviation) of a
> generic input data stream has ever come up in the past.
There was discussion around this wh
On Tue, 7 May 2019 at 06:42, Christopher Barker wrote:
>
> Oddly, it seems everyone in this thread thinks it would be "Better" to have a
> bunch of constructors, ratehr than the overloading, of only we didn't have
> backward compatibility to worry about.
>
> I disagree -- these efficiencies are
On Tue, 7 May 2019, 19:25 Chris Angelico, wrote:
> On Wed, May 8, 2019 at 4:17 AM Oscar Benjamin
> wrote:
> > Admittedly the non-ASCII unicode digit example is not one that has
> > actually caused me a problem but what I have had a problem with is
> > floats. Given th
On Sun, 16 Jun 2019 at 12:54, Franklin? Lee
wrote:
>
> On Sat, Jun 15, 2019 at 10:26 PM Guido van Rossum wrote:
> > I don't actually know how viable this proposal is, but given that it's
> > being debated at some length, I'd like to put in my opinion that *if*
> > we're going to define an oper
On Sun, 29 Sep 2019 at 08:28, Kyle Stanley wrote:
>
> Raymond also brought up a strong point to consider in
> https://bugs.python.org/issue25988:
>
> > The OP has a sense that Mapping and Sequence are "too heavy"
> but I think the reality that useful classes almost never use
> __getitem__ in isola
On Tue, 1 Oct 2019 at 11:24, Steven D'Aprano wrote:
>
> On Mon, Sep 30, 2019 at 06:00:44PM +0900, Stephen J. Turnbull wrote:
>
> > Technical questions: does "Subscriptable" mean non-negative ints only,
> > or does it include the negative "count from the end" protocol? How
> > about slices?
>
> It
On Mon, 14 Oct 2019 at 05:47, Andrew Barnert via Python-ideas
wrote:
>
> `1 in complex` is _not_ mathematically true. Simplifying a bit, the elements
> of the algebra of complex numbers are ordered pairs of real numbers, and `1`
> is not a pair. When you’re working in, say, complex analysis, you
On Fri, 15 Nov 2019 at 12:04, Serhiy Storchaka wrote:
>
> 15.11.19 12:40, Jonathan Fine пише:
> > The original poster wanted, inside 'with' context management, to open
> > several files. Context management is, roughly speaking, deferred
> > execution wrapped in a try ... except statement.
>
>
On Fri, 15 Nov 2019 at 22:54, Chris Angelico wrote:
>
> On Sat, Nov 16, 2019 at 9:44 AM Oscar Benjamin
> wrote:
> >
> > On Fri, 15 Nov 2019 at 12:04, Serhiy Storchaka wrote:
> > >
> > > 15.11.19 12:40, Jonathan Fine пише:
> > > > The original
On Sun, 17 Nov 2019 at 06:28, Random832 wrote:
> On Sat, Nov 16, 2019, at 16:13, Greg Ewing wrote:
> >
> > I seem to remember we had such a context manager for a brief
> > time after the with-statement was invented, until someone had
> > the bright idea to make open() do double duty.
> >
> > The m
On Mon, 18 Nov 2019 at 08:42, Paul Moore wrote:
>
> On Sun, 17 Nov 2019 at 19:18, Oscar Benjamin
> wrote:
> >
> > Ultimately the problem is that the requirements on a context manager
> > are not clearly spelled out. The with statement gives context manager
> > a
On Mon, 18 Nov 2019 at 13:12, Soni L. wrote:
>
> On 2019-11-18 9:10 a.m., Oscar Benjamin wrote:
> > [snip]
> >
> > To me that seems clumsy and awkward compared to nested though:
> >
> > with nested(*map(open, filenames)) as files:
> > ...
> &
On Mon, 18 Nov 2019 at 14:07, Soni L. wrote:
> On 2019-11-18 11:32 a.m., Oscar Benjamin wrote:
> > On Mon, 18 Nov 2019 at 13:12, Soni L. wrote:
> > >
> > > On 2019-11-18 9:10 a.m., Oscar Benjamin wrote:
> > > >
> > > > with nested
On Mon, 18 Nov 2019 at 15:54, Paul Moore wrote:
>
> On Mon, 18 Nov 2019 at 11:12, Oscar Benjamin
> wrote:
>
> > I am proposing the root of the problem here is the fact that open
> > acquires its resource (the opened file descriptor) before __enter__ is
> > ca
On Mon, 18 Nov 2019 at 17:46, Paul Moore wrote:
>
> On Mon, 18 Nov 2019 at 17:17, Oscar Benjamin
> wrote:
> > The problem with a misbehaving context manager is that it creates a
> > future need to call __exit__ before it has been passed to a with
> > statement or a
On Mon, 18 Nov 2019 at 22:00, Paul Moore wrote:
>
> On Mon, 18 Nov 2019 at 18:34, Oscar Benjamin
> wrote:
> >
> > On Mon, 18 Nov 2019 at 17:46, Paul Moore wrote:
>
> > I think that nested was fine but in combination with open it was prone
> > to misuse.
On Tue, 19 Nov 2019 at 00:35, Soni L. wrote:
>
> On 2019-11-18 5:22 p.m., Soni L. wrote:
> >
> > could we tweak open() so it doesn't raise immediately? this would make
> > it play nicer with __enter__ but would probably break some things.
> > this would make open() itself "never" fail.
>
> let me
On Tue, 19 Nov 2019 at 08:21, Paul Moore wrote:
>
> On Mon, 18 Nov 2019 at 23:42, Oscar Benjamin
> wrote:
>
> > Context managers and the
> > with statement are all about assigning responsibility so there needs
> > to be an understanding of what has responsibility
Whoops I sent too soon. I'll try again...
On Tue, 19 Nov 2019 at 11:01, Oscar Benjamin wrote:
>
> On Tue, 19 Nov 2019 at 08:21, Paul Moore wrote:
> >
> > On Mon, 18 Nov 2019 at 23:42, Oscar Benjamin
> > wrote:
> >
> > > Context managers and the
On Tue, 19 Nov 2019 at 12:03, Paul Moore wrote:
>
> On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin
> wrote:
>
> > If I was to propose anything here it would not be to disallow anything
> > that you can currently do with context managers. Rather the suggestion
> &g
On Wed, 20 Nov 2019 at 02:36, Richard Damon wrote:
>
> On 11/19/19 8:57 PM, Oscar Benjamin wrote:
> > On Tue, 19 Nov 2019 at 12:03, Paul Moore wrote:
> >> On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin
> >> wrote:
> >>
> >>> If I was to propose
On Sat, 30 Nov 2019 at 22:24, Steven D'Aprano wrote:
>
> On Sat, Nov 30, 2019 at 06:16:49PM -0300, Soni L. wrote:
>
> > It'd be quite nice if dict.items() returned a namedtuple so all these
> > x[0], x[1], el[0], el[1], etc would instead be x.key, x.value, el.key,
> > el.value, etc. It would be mo
On Tue, 3 Dec 2019 at 12:48, Paul Moore wrote:
>
> My impression is that he was asking for a re.findfirst(...) function
> to give a more discoverable name to the next(re.finditer((...)) idiom.
>
> As a single example of defining a dedicated function to replace a
> one-liner, I think it's marginal
On Wed, 4 Dec 2019 at 21:16, Anders Hovmöller wrote:
> > On 4 Dec 2019, at 21:28, Soni L. wrote:
> >> On 2019-12-04 5:12 p.m., Mike Miller wrote:
> >>
> >>> On 2019-12-04 11:05, David Mertz wrote:
> >>> I've often wanted named loops. I know approaches to this have been
> >>> proposed many times,
> On Wed, Dec 4, 2019 at 16:33 Juancarlo Añez wrote:
is troublesome.
>>
>> The proposed implementation of a findfirst() would handle many common cases,
>> and be friendly to newcomers (why do I need to deal with a Match object?),
>> specially if the semantics are those of findall():
>>
>> n
On Sat, 7 Dec 2019 at 00:43, Steven D'Aprano wrote:
>
> On Fri, Dec 06, 2019 at 09:11:44AM -0400, Juancarlo Añez wrote:
>
> [...]
> > > Sure, but in this case, it isn't a fragment of a larger function, and
> > > that's not what it looks like. If it looked like what you wrote, I would
> > > underst
On Sun, 8 Dec 2019 at 14:37, Chris Angelico wrote:
>
> PEP 479 (https://www.python.org/dev/peps/pep-0479/) changed the rules
> around generators: if it would have leaked StopIteration, it instead
> raises RuntimeError. This converts hard-to-debug premature termination
> into easily-spotted excepti
On Sun, 8 Dec 2019 at 18:42, Guido van Rossum wrote:
>
> We're not changing next(). It's too fundamental to change even subtly.
I don't think that anyone has proposed to change the behaviour of
next. I have suggested that if there is to be a new function very
similar to next then it can also solv
On Tue, 10 Dec 2019 at 00:26, Steven D'Aprano wrote:
>
> On Tue, Dec 10, 2019 at 10:54:10AM +1300, Greg Ewing wrote:
>
> > Can you provide any insight into why you think it's better for
> > it never to raise an exception, as opposed to raising something
> > other than StopIteration when the iterat
On Fri, 13 Dec 2019 at 22:47, Tim Peters wrote:
>
> [Christopher Barker]
> >> I think we all agree that it does not belong in __builtins__,
>
> [Greg Ewing]
> > Do we?
>
> Nobody yet has argued in favor of it - or even suggested it.
>
> > I'm not convinced.
>
> And that remains true even now ;-)
On Sun, 15 Dec 2019 at 05:54, David Mertz wrote:
>
> A pattern I've written a number of times is roughly:
>
> lines = open(fname)
> header = next(lines)
> for line in lines:
> process (line, header)
>
> That's not so artificial, I think. Of course, first() would also work here.
> But I'm not
On Mon, 24 Feb 2020 at 17:47, Aaron Hall via Python-ideas
wrote:
>
> The context for this is statistics , so I'll quote Wolfram on tilde in the
> context of statistics: http://mathworld.wolfram.com/Tilde.html
>
> "In statistics, the tilde is frequently used to mean "has the distribution
> (of),"
On Sat, 2 May 2020 at 20:50, Serhiy Storchaka wrote:
>
> 02.05.20 21:34, Ahmed Amr пише:
> > I see there are ways to compare them item-wise, I'm suggesting to bake
> > that functionality inside the core implementation of such indexed
> > structures.
> > Also those solutions are direct with tuples
On Thu, 7 May 2020 at 02:07, David Mertz wrote:
>
> That's the point though. For *most* functions, the substitution principle is
> fine in Python. A whole lot of the time, numeric functions can take either
> an int or a float that are equal to each other and produce results that are
> equal t
On Thu, 7 May 2020 at 08:54, Greg Ewing wrote:
>
> On 7/05/20 1:07 pm, David Mertz wrote:
> > For *most* functions, the substitution
> > principle is fine in Python. A whole lot of the time, numeric functions
> > can take either an int or a float that are equal to each other and
> > produce resul
On Sun, 17 May 2020 at 07:10, Christopher Barker wrote:
>
> > PS. Why wasn't a new builtin zip_strict() on the menu? I think I would have
> > given it at least +0.5, because of this rule of thumb.
>
> I would think that if zip_strict() added as a builtin, then zip_longest()
> should too.
>
> And
On Mon, 15 Jun 2020 at 00:21, Greg Ewing wrote:
>
> On 15/06/20 3:52 am, David Mertz wrote:
> > I've had occasion to use math.isclose(), np.isclose(), and np.allclose()
> > quite often.
>
> Can you elaborate a bit on the kinds of things you use them for?
I can't elaborate on David's use but in my
On Wed, 1 Jul 2020 at 05:36, Christopher Barker wrote:
>
> On Tue, Jun 30, 2020 at 11:55 AM Rhodri James wrote:
>>
>> Don't get me wrong, if it's not going to cause performance issues I
>> think being able to index views would be great, but I don't think this
>> is the right way to justify it.
>
On Fri, 10 Jul 2020 at 06:56, Chris Angelico wrote:
>
> On Fri, Jul 10, 2020 at 3:41 PM Inada Naoki wrote:
> >
> > On Fri, Jul 10, 2020 at 1:53 PM Chris Angelico wrote:
> > >
> > >
> > > And immediately above that part, I said that I had made use of this,
> > > and had used it in Python by listi
I posted this in the thread about indexing dict items but it seems to
have been buried there so I'm starting a new thread.
Maybe there could be a function in the random module for making a
random choice from an arbitrary (finite) iterable. This implementation
can choose a random element from an it
> On Mon, Jul 13, 2020, 7:53 AM Oscar Benjamin
> wrote:
>>
>> I posted this in the thread about indexing dict items but it seems to
>> have been buried there so I'm starting a new thread.
>>
>> Maybe there could be a function in the random module for ma
On Mon, 13 Jul 2020 at 19:39, Christopher Barker wrote:
>
> On Mon, Jul 13, 2020 at 7:44 AM Guido van Rossum wrote:
>>
>> I think you all should get together and come up with a good implementation,
>
> In any case, a good implementation would be a lot easier to evaluate for
> inclusion.
>
>> Or
On Mon, 17 Aug 2020 at 07:14, Stephen J. Turnbull
wrote:
>
> Christopher Barker writes:
>
> > Anyway, I would like to see a nice linear algebra lib -- but not 'cause I'd
> > use it, only because I find it interesting.
>
> SymPy.
>
> Except that in this conversation, "linear algebra" is likely ne
On Fri, 25 Sep 2020 at 15:57, Paul Moore wrote:
>
> On Fri, 25 Sep 2020 at 14:15, Chris Angelico wrote:
>
> > Why? Do you really think you can enumerate EVERY possible way that
> > something might fail?
>
> Rust does a surprisingly good job of that, actually. But the point is
> that Python is not
On Fri, 25 Sep 2020 at 18:59, Chris Angelico wrote:
>
> On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin
> wrote:
> > I do agree but maybe that suggests a different role for annotated
> > exceptions in Python. Rather than attempting to enumerate all possible
> > exce
On Fri, 25 Sep 2020 at 20:36, Chris Angelico wrote:
>
> On Sat, Sep 26, 2020 at 5:27 AM Oscar Benjamin
> wrote:
> >
> > On Fri, 25 Sep 2020 at 18:59, Chris Angelico wrote:
> > >
> > > On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin
> > > wro
On Fri, 25 Sep 2020 at 22:05, Chris Angelico wrote:
>
> On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin
> wrote:
> >
> > There are many common bugs that arise as a result of exceptions that
> > are overlooked. There are also often simple ways to rewrite the code
>
On Thu, 8 Oct 2020 at 16:59, Random832 wrote:
>
> I was making a "convert Fraction to Decimal, exactly if possible" function
> and ran into a wall: it's not possible to do some of the necessary operations
> with exact precision in decimal:
>
> - multiplication
> - division where the result can b
On Mon, 12 Oct 2020 at 07:23, Christopher Barker wrote:
>
> FWIW, if a change were to be made, I'd rather it be some kind of float error
> handling context: either a global setting, like numpy's, or a context
> manager. With, of course, the default behavior just like it's been forever.
You can
On Thu, 15 Oct 2020 at 04:22, Guido van Rossum wrote:
>
> This all seems a pretty artificial argument.
>
> In plain English, "1/3" is not exactly representable in decimal form, but
> something like 0. * 0.22
> *is* (assuming the inputs are what
> > On Tue, 17 Nov 2020 at 10:35, Nuri Jung wrote:
> >>
> >> How about enabling subscription operator (`[]`) for generator expressions?
> >> Also for all `zip()`, `key()`, etc. They could be evaluated in the
> >> background only for the requested amount, to avoid evaluating the whole
> >> expre
On Tue, 17 Nov 2020 at 22:35, Paul Moore wrote:
>
> On Tue, 17 Nov 2020 at 22:19, Oscar Benjamin
> wrote:
> > It would be nice if islice gave an object that supported slicing so
> > that you could spell it like:
> >
> >for x in islice(a)[5:]:
> >
>
On Thu, 19 Nov 2020 at 23:13, Chris Angelico wrote:
>
> On Fri, Nov 20, 2020 at 10:05 AM Eric V. Smith wrote:
> > I just don't think we need to be immediately dismissive of people's
> > desire to create a platform native executable that disguises the fact
> > that the code is written in Python.
>
On Sat, 21 Nov 2020 at 09:30, Ronald Oussoren via Python-ideas
wrote:
>
>
>
> > On 20 Nov 2020, at 16:42, Ricky Teachey wrote:
> >
> > I was reading the pyinstaller thread and had this idea but didn't want to
> > hijack.
> >
> > Maybe a wild idea, and very possible totally impractical or hopeles
On 17 October 2016 at 09:08, Nathaniel Smith wrote:
> Hi all,
Hi Nathaniel. I'm just reposting what I wrote on pypy-dev (as
requested) but under the assumption that you didn't substantially
alter your draft - I apologise if some of the quoted text below has
already been edited.
> Always inject r
1 - 100 of 107 matches
Mail list logo
