Yeah, I should have done that instead of replying without context. 🤦
On Tue, 2020-10-20 at 17:43 +1100, Chris Angelico wrote:
> On Tue, Oct 20, 2020 at 3:47 PM Paul Bryan wrote:
> >
> > print is now a function, and as such can be passed to something
> > that expects a callable. We would lose thi
On Tue, Oct 20, 2020 at 3:47 PM Paul Bryan wrote:
>
> print is now a function, and as such can be passed to something that expects
> a callable. We would lose this if it were restored to a statement.
> Consequently this would be a breaking change, so I don't see it happening.
>
Did you read the
On Tue, Oct 20, 2020 at 01:29:42PM +0900, Stephen J. Turnbull wrote:
> Michael Smith writes:
>
> > On the other hand, assert has no parentheses, and gets committed for
> > posterity everywhere.
>
> ISTR that assert was not converted to a function along with print
> because it's a control flow c
print is now a function, and as such can be passed to something that
expects a callable. We would lose this if it were restored to a
statement. Consequently this would be a breaking change, so I don't see
it happening.
On Tue, 2020-10-20 at 01:21 +0200, J. Pic wrote:
> +1 because print is a debugg
J. Pic writes:
> +1 because print is a debugging tool mostly used in short lived
> temporary code as such the parenthesis do not matter and do not
> provide any value.
Sez you. In *my* "business process automation" (I'm a professor), its
primary use is for normal output.
In debugging such co
Michael Smith writes:
> On the other hand, assert has no parentheses, and gets committed for
> posterity everywhere.
ISTR that assert was not converted to a function along with print
because it's a control flow construct.
___
Python-ideas mailing list
On Mon, Oct 19, 2020 at 19:28 J. Pic wrote:
> +1 because print is a debugging tool mostly used in short lived
> temporary code as such the parenthesis do not matter and do not
> provide any value.
A lot of debugger use print to instrumentalize their code during
> development or debugging, as in
ERRATA : s/A lot of debuggers/A lot of developers/ (sorry I think I squinted)
___
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
+1 because print is a debugging tool mostly used in short lived
temporary code as such the parenthesis do not matter and do not
provide any value.
A lot of debugger use print to instrumentalize their code during
development or debugging, as in: "I want to dump some variable and run
my test again"
Nope, this time I really have nothing more to say.
On Mon, Oct 19, 2020, 9:22 AM Paul Moore wrote:
> Wes, you seem to just be throwing out a load of questions, to all of
> which my answer is "I don't know" (and usually "I don't care either").
>
> Do you have an actual proposal here, and if so co
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 t
Wes, you seem to just be throwing out a load of questions, to all of
which my answer is "I don't know" (and usually "I don't care either").
Do you have an actual proposal here, and if so could you state it
clearly and in the form of a description, not a question, please? I'm
struggling to find any
Which [Python,] CAS support transfinite and/or surreal numbers and/or other
piecewise axioms for an infinity symbol?
Are they vectorizable?
What's wrong with substituting a standard symbol for infinity (instead of
prematurely discarding e.g. coefficients/scalars and exponents)?
https://github.co
I have commented on Steven's comments about alephs below.
It seems to me that this discussion (on having "different" infinities and
allowing/storing arithmetic on them) is dead-on-arrival because:
- the scope of people who would find this useful is very small
- it would change current behaviour
-
14 matches
Mail list logo
