On 2019-06-04 14:34, Ricky Teachey wrote:
"update an object with another" (dunder update)
Yes, that's essentially what I meant. To me, "assign an object in place"
and "update an object with another" mean the same thing.
A few come to mind:
my_dict.update
This is PEP 584, where += is
On 2019-06-04 13:29, Steven D'Aprano wrote:> As far as I can tell, there
is no difference between your proposal
and the OP's proposal except you have changed the name of the dunder
from __arrow__ to __iassign__.
I never claimed that there was a difference. I just tried to clarify
what the
I'd like to get rid of all the signal and HDL stuff (whatever that
means) in this thread, so I think what the original poster really wants
is an "assign in place" operator. Basically, something like += or *= but
without the arithmetic.
When you think of it this way, it's not an unreasonable
On 2019-04-11 00:09, Stefano Borini wrote:
I occasionally found situations where I want to raise an exception for
errors that can only arise because the developer made a mistake, for
example:
I use AssertionError for this. An assertion failure means "this is a
bug", so that seems the right
On 2019-03-21 17:11, Guido van Rossum wrote:
I don't find it easy to understand or remember that d1.update(d2)
modifies d1 in place, while d1.merge(d2) first copies d1.
That would be an advantage with + versus += (or | versus |=).
___
Python-ideas
On 2019-03-08 22:16, Martin Bammer wrote:
Hi,
what about the idea that the interpreter preallocates and preinitializes
the
tuples and dicts for function calls where possible when loading a module?
The basic premise here is wrong: function calls using the METH_FASTCALL
convention don't need
On 2018-10-03 17:56, Wes Turner wrote:
The phrase "core developers and the BDFL"
is where some sort of alternate quorum/majority policy would need to be
specified if this is a contentious issue in practice?
The whole point of the process described in PEP 8000 is to make this
more precise. The
On 2018-09-11 14:20, Steven D'Aprano wrote:
On Tue, Sep 11, 2018 at 08:53:55PM +1000, Steven D'Aprano wrote:
[...]
Or perhaps we could have an officially blessed way to give tools a hint
as to what the real signature is.
class Child(Parent):
@signature_hint(Parent.method)
def
With gmpy2 (note that mpq=fractions, mpfr=floating-point reals):
>>> from gmpy2 import mpq
>>> mpq("1/1") ** mpq("2/3")
mpfr('1.0')
>>> mpq("-1/1") ** mpq("2/3")
mpfr('nan')
>>> mpq("0/1") ** mpq("2/3")
mpfr('0.0')
___
Python-ideas mailing list
On 2018-08-30 11:11, Jonathan Fine wrote:
If anyone has time and ready access, it would help to know what
https://www.sympy.org/en/index.html does with this.
It handles such powers symbolically, not actually returning a numerical
result:
>>> from sympy import Rational
>>> Rational(1,2) **
On 2018-08-30 11:05, Jonathan Fine wrote:
I'm used to using a number theory computer algebra system
https://pari.math.u-bordeaux.fr/.
I don't think that a comparison with PARI is very relevant because PARI
doesn't really have a type system the way that Python does. For example
the fraction
On 2018-08-30 06:39, Neil Girdhar wrote:
I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
Why? I cannot think of any natural use case why you would want Fractions
for a few special cases on an operation which returns non-Fractions
generically.
I consider it a feature to know
On 2018-08-04 09:43, Steven D'Aprano wrote:
If you want to
propose a general exception suppressing mechanism (aside from the
existing try...except statement) then propose it as an independent PEP.
This was already tried in PEP 463 (which IMHO is a pity that it wasn't
accepted because it seems
On 2018-07-27 00:50, David Mertz wrote:
I often use doctests to verify APIs and behaviors when I update code. I
know I'm in a minority and most developers slightly disparage doctests.
If it makes you feel better, SageMath development uses only doctests for
testing. We have over 30
On 2018-07-23 12:24, Jeroen Demeyer wrote:
Another solution that nobody has mentioned (as far as I know) is to add
additional syntax to the language for that. For example, one could say
that (1:3) could be used to construct slice(1, 3) directly. The
parentheses are required to avoid confusion
On 2018-07-23 11:58, Grégory Lielens wrote:
Not sure slice[1::3] can be done
It can be done. Since "slice" is a class, it would require a metaclass
though.
Another solution that nobody has mentioned (as far as I know) is to add
additional syntax to the language for that. For example, one
On 2018-07-13 14:11, Steven D'Aprano wrote:
What it *actually* does is:
is_almost_certainly_prime_except_for_a_ludicrously_microscopic_chance_of_error_thousands_of_times_less_likely_than_a_stray_cosmic_ray_flipping_a_bit_in_memory_and_causing_the_wrong_result_to_be_returned()
That's just a
On 2018-07-13 14:26, Steven D'Aprano wrote:
I'm pretty sure that Sage is using numpy
This computation uses PARI/GP, a dedicated library for number theory
(https://pari.math.u-bordeaux.fr/) with a Python interface
(https://github.com/defeo/cypari2).
And it's
probably making far less
On 2018-07-13 11:50, Jacco van Dorp wrote:
At the very least, use is_likely_prime() as function name.
I agree with you here: the function name should reflect what it actually
does. (Note that the technical term is "probable prime", so it should be
is_probable_prime)
But I don't think that
On 2018-07-13 10:43, Jacco van Dorp wrote:
If there's going to be failure possible primality tests, there should
also exist certain ones. No matter how slow it can be to do it.
A certain primality test would be too specialized for the Python stdlib.
If you really need that (which you
On 2018-07-13 04:02, Chris Angelico wrote:
Haha. Okay. I'm not familiar with every possible primality test, so I
had no idea that they ALL have the same failure mode :)
There exist guaranteed primality tests, but those are much slower and
more complicated. The state of the art is ECPP:
On 2018-07-12 20:11, Steven D'Aprano wrote:
about 4.7 seconds to test 2**800 + 1;
In SageMath:
sage: n = 2**800+1; timeit('is_prime(n)')
625 loops, best of 3: 303 µs per loop
That's 4 orders of magnitude faster...
___
Python-ideas mailing list
If you want inspiration:
https://github.com/sagemath/sage/blob/master/src/sage/arith/misc.py
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
On 2018-06-21 11:00, INADA Naoki wrote:
When Python 4, I think we can even throw away classmethod and
staticmethod object.
PyFunction can have binding flag instead, like METH_CLASS and
METH_STATIC for PyCFunction.
classmethod and staticmethod is just a function which modify the flag.
One issue
On 2018-06-21 10:33, Serhiy Storchaka wrote:
Status quo wins.
Well, I'm already planning to make changes to staticmethod/classmethod
(not right now, but it's on my post-PEP-580 roadmap). So the "status
quo" argument doesn't apply.
My question is really: assuming that we redesign
On 2018-06-20 19:33, Serhiy Storchaka wrote:
20.06.18 12:56, Jeroen Demeyer пише:
Are there any reasons to *not* make staticmethod and classmethod callable?
There were no reasons to make staticmethod and classmethod callable.
You have to compare the advantages of making them callable vs
While working on PEP 579 and friends, I noticed one oddity with
classmethods: for Python classes, the object stored in the class
__dict__ is of type "classmethod". For extension types, the type is
"classmethod_descriptor". In turns out that the latter is callable
itself, unlike staticmethod or
On 2018-06-09 14:43, Juancarlo Añez wrote:
Is there a guide about writing (and publishing) PEPs?
https://www.python.org/dev/peps/pep-0001/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Hello,
Both PEP 573 and PEP 575 deal with built-in functions. Additionally,
some people (Stefan Behnel, Robert Bradshaw, Jim Pivarski and me) are
currently brainstorming about a yet-to-be-written PEP to allow calling
the underlying C function of a built-in function using native types (for
On 2018-04-28 18:26, Paul Moore wrote:
"""
If a file named filename is not found, the function will look for it
in the module search path, sys.path, after first checking for a PEP
302 __loader__ in module_globals, in case the module was imported from
a zipfile or other non-filesystem import
The documentation of __loader__.get_source() says
"Returns None if no source is available (e.g. a built-in module)."
But what does "no source is available" mean precisely? It could mean
either of two things:
(A) I am absolutely certain that there is no source anywhere to be found.
(B) I
On 2018-04-25 09:57, Ivan Levkivskyi wrote:
In the latter case rewriting EnumMeta in C
... or Cython. It's a great language and I'm sure that the Python
standard library could benefit a lot from it.
___
Python-ideas mailing list
On 2018-04-02 12:39, INADA Naoki wrote:
Thanks for writing such hard PEP.
At first glance, it new type hierarchy seems OK.
But I can't understand rational for new flags.
Which flags in particular do you mean? I just pushed an update
explaining the rationale of METH_ARG0_FUNCTION:
On 2018-03-31 21:12, Terry Reedy wrote:
I would be all for more of the builtins and stdlib being converted.
Can't 3rd-party C code use ArgumentClinic?
ArgumentClinic stores the signature as text. For default values, only a
few specific classes are supported. I want to support arbitrary Python
On 2018-03-31 18:09, Steven D'Aprano wrote:
It seems like a huge amount of work
What is a huge amount of work? Writing the PEP? Implementing the PEP?
Using the PEP? Adapting existing Python code to the PEP?
Why isn't the answer to provide a hook to support introspection?
That is a lot
I have prepared a PEP draft for unifying function/method classes. You
can find it at
https://github.com/jdemeyer/PEP-functions
This has not officially been submitted as PEP yet, I want to hear your
comments first.
Thanks,
Jeroen.
___
Python-ideas
Dear Nick Coghlan,
First of all, thanks for your insightful comments!
On 2018-03-24 09:09, Nick Coghlan wrote:
As Antoine notes, unifying user-defined functions and builtin functions
would be fraught with backwards compatibility problems, so you probably
don't want to go down that path when
On 2018-03-23 00:36, Antoine Pitrou wrote:
It does make sense, since the proposal sounds ambitious (and perhaps
impossible without breaking compatibility).
Well, *some* breakage of backwards compatibility will be unavoidable.
My plan (just a plan for now!) is to preserve backwards
Dear python-ideas,
I would like to draft a PEP to change the implementation of functions
and methods in CPython. The idea for this PEP come from a discussion on
https://bugs.python.org/issue30071
The core idea of the PEP is to reorganize classes for functions and
methods with the goal of
39 matches
Mail list logo
