On Sun, Jun 10, 2018 at 10:01:09PM -0700, Chris Barker via Python-ideas wrote:
> In regard to the "special values", and exact results -- a good math lib
> should return results that are "exact" in all but maybe the last digit
> stored. So you could check inputs and outputs with, e.g.
On Sun, Jun 10, 2018 at 11:26 AM, Robert Vanden Eynde <
robertvandeney...@hotmail.com> wrote:
> I agree that a big python library is more close to the standard python lib
> than matlab. However, helping transition from matlab is a great concern in
> the python scientific community, because matlab
On Sun, Jun 10, 2018 at 5:41 PM Terry Reedy wrote:
> On 6/10/2018 10:44 AM, Stephan Houben wrote:
>
> > I would suggest that compatibility with a major Python library such as
> > SciPy is more important than compatibility
> > with other programming languages.
> >
> > I would go even further and
On 6/10/2018 10:44 AM, Stephan Houben wrote:
I would suggest that compatibility with a major Python library such as
SciPy is more important than compatibility
with other programming languages.
I would go even further and argue that scipy.special.sindg and its
friends cosdg and tandg
can
I agree that a big python library is more close to the standard python lib than
matlab. However, helping transition from matlab is a great concern in the
python scientific community, because matlab is used is a lot of engineering
classes at University.
That's a tough call hmmm.
I'll look at
> As the PEP author, that's your job.
>
I started writing the PEP, and I found an interesting example:
if not (m := re.match(r'^(\d+)-(\d+)$', identifier):
raise ValueError('f{identifier} is not a valid identifier')
print(f'first part is {m.group(1)}')
print(f'first part is
2018-06-09 8:18 GMT+02:00 Robert Vanden Eynde :
> For the naming convention, scipy using sindg (therefore Nor sind nor
> sindeg) will make the sind choice less obvious. However if Matlab and Julia
> chooses sind that's a good path to go, Matlab is pretty popular, as other
> pointed out, with
On Sun, Jun 10, 2018 at 08:08:13AM -0400, Juancarlo Añez wrote:
> > while (condition := expression) as flag:
> > ...
> >
>
> Ah! Are the parenthesis necessary there?
It's your PEP, you tell us.
> > Accepting "while/if as name" would remove much (but not all) of the
> > motivation
On Sun, Jun 10, 2018 at 10:08 PM, Juancarlo Añez wrote:
>
> There can be cases in which combining both syntaxes is useful:
>
> x = None
> while compute(x := v for v in next_series_value(x)) as comp:
> ...
> x = comp
Why not just:
while comp := compute(x := v for v in
> The only difference is that the `except` block implicitly unbinds the
> variable when the block ends.
>
Mmmm. Good to know, because that means that the semantics are the same,
except...
>
> while (condition := expression) as flag:
> ...
>
Ah! Are the parenthesis necessary there?
I think this suggestion should result in a library on PyPi, which can then
be considered for the standard library if it sees a lot of use.
Also, modern OpenGL does this just like Python does: all of the
trigonometric functions take radians and a "radians" function is provided.
Best,
Neil
On
Policy locking is a viable idea at first glance.
On Sun, Jun 10, 2018 at 8:05 AM Nick Coghlan wrote:
> On 10 June 2018 at 07:59, Michel Desmoulin
> wrote:
>
>> What I'm proposing is to make that easy to implement by just letting
>> anyone put a check in there.
>>
>> Overriding policy, loops or
12 matches
Mail list logo
