Steven D'Aprano wrote:
> On Fri, Jun 08, 2018 at 10:53:34AM +0200, Adam Bartoš wrote:
>> Wouldn't sin(45 * DEG) where DEG = 2 * math.pi / 360 be better that
>> sind(45)? This way we woudn't have to introduce new functions. (The
problem
>> with nonexact results for nice angle
Wouldn't sin(45 * DEG) where DEG = 2 * math.pi / 360 be better that
sind(45)? This way we woudn't have to introduce new functions. (The problem
with nonexact results for nice angles is a separate issue.)
Regards,
Adam Bartoš
___
Python-ideas mailing
update is not None:
yield y, potential_update
where
from:
would be equivalent to
def _():
_ = _()
Best regards,
Adam Bartoš
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ide
On Wed May 16 20:53:46 EDT 2018, Steven D'Aprano wrote:
> On Wed, May 16, 2018 at 07:24:19PM +0200, Adam Bartoš wrote:
>> Hello,
>>
>> I have yet another idea regarding the the clashes between new keywords
and
>> already used names. How about introducing two new keywords
tax error when a keyword occurs at a place of a formal parameter
(similarly to 'def f(x): nonlocal x').
Clearly, even if this proposal diminished the cost of adding new keywords,
the cost would still be high.
Best regards,
Adam Bartoš
___
Python-id
, Adam Bartoš
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Just a small suggestion:
wouldn't it be better to use adjectives instead of verbs for proposed
builtin names and their variants?
existing(foo) else bar
non_None(foo) else bar
instead of
exists(foo) else bar
is_not_None(foo) else bar
Regards,
Adam Bartoš
Hello,
will await be allowed also in the "if" part of comprehensions? And what
about the "in" part? (e.g. if I'm not mistaken, we may have an asynchronous
function returning an asynchronous iterator.)
Regards,
Adam Bartoš
___
Pytho
-- to be viewed as a stdio stream.
> - When using os.read/write for data that represents text, the data still
> should be encoded in the console encoding and not in utf-8 or utf-16.
I don't know what to do with this. Generally I wouldn't use bytes to
communicate textual data.
Regards,
Ad
actual
transcoding in sys.std* objects. It's just a signal for PyOS_Readline
consumers, and the transcoding occurs in a custom readline hook. Nothing
like this would be needed if PyOS_Readline was replaced by some Python API
wrapper around sys.readlinehook that would be Unicode string b
of
work, I just think it's pity that something natural doesn't work only
because of implementation reasons. However, introducing async generators is
an important step in the right way. Thank you for that.
Regards, Adam Bartoš
___
Python-ideas mailing list
11 matches
Mail list logo
