ync callables
will almost never come up.
As a result, we decided to leave it in for now, but would be happy to remove it
if the SC would prefer that.
If there are no other concerns, we'd like to move forward and submit it to the
SC.
Cheers,
Steven
---
[1] PEP 677: https://www.python
t:
def foo(x): f"is this a docstring? x is {x}"
I'm pretty sure f-strings cannot be used as docstrings in other contexts
because of how broken they'd be in functions.
--
Steven Barker
___
Python-Dev mailing list -- python-dev@py
On Thu, Jan 13, 2022 at 06:41:14PM +1000, Nick Coghlan wrote:
> If such a protocol were to be proposed, then int.__arrow__ could be defined
> such that "1 -> 100" was equivalent to "range(1, 100)"
Why? What's the benefit? It is slightly shorter, but no more clear than
range. I would never guess
On Thu, Jan 13, 2022 at 04:23:09AM -, Dennis Sweeney wrote:
> Like others expressed, I don't like the idea of the typing and
> non-typing parts of Python separating.
Its a good thing that this PEP doesn't separate the typing and
non-typing world. The arrow syntax will be a plain old Python
Good catch, thanks Nick!
It's been specified in a linked doc [0] but I forgot to move that into the PEP
itself.
I'll aim to get that done today.
---
[0]
https://docs.google.com/document/d/15nmTDA_39Lo-EULQQwdwYx_Q1IYX4dD5WPnHbFG71Lk/edit
___
Python-Dev
Using an operator is an interesting idea, and we should probably call it out as
an alternative in the PEP.
It's not a substitute for the current PEP from the standpoint of typing-sig for
a few reasons:
(A) We care that the syntax be forward-compatible with supporting named
arguments, as outline
We just merged changes to the PEP with a detailed runtime API specification.
Highlights are that:
- The new type should have an `inspect.Signature`- inspired structured API
- It should have a backward-compatible interface with the `__args__` and
`__params__`
- As with the PEP 604 union syntax, `_
I've been wondering whether it would make sense to have a function in `inspect`
that returns the signature of a type, rather than the signature of a specific
callable object.
I'm not attached to any name for such a function, two ideas are
`inspect.signature_of` or `inspect.signature_of_type`.
> It would be nice if someone did some work and collected a list of tutorials
> about type annotations that exist (especially the ones that are discoverable
> with a simple Bing query) and ranked them by quality.
I went with Google rather than Bing but here's what I found:
https://gist.github.c
On Wed, Jan 26, 2022 at 02:40:32PM -0800, Neil Schemenauer wrote:
> On 2022-01-18 23:14, Gregory P. Smith wrote:
> >
> >Our stdlib unittest already enables warnings by default per
> >https://bugs.python.org/issue10535.
> >
> >Getting the right people to pay attention to them is always the hard par
On Sun, Jan 30, 2022 at 08:36:43AM -0800, Jelle Zijlstra wrote:
> Agree, the count of 1.6k open PRs is not a good look for new contributors.
How does that compare to other comparable open source projects?
Number of open PRs per KLOC seems like a more useful metric than just
the number of open P
On Tue, Feb 08, 2022 at 12:44:46PM +, Steve Dower wrote:
> Agreed. CPython should be specific, Python should be as vague as
> possible. Otherwise, we would prevent _by specification_ using Python as
> a scripting language for things where floats may not even be relevant.
I don't think that
On Mon, Feb 07, 2022 at 05:35:17PM -0800, Gregory P. Smith wrote:
> CPython: yes. we use a double.
> Python the language: no. (float is single precision on many micropython
> platforms as it saves precious ram and performance, plus microcontroller
> fpu hardware like an M4 is usually single prec
On Mon, Feb 07, 2022 at 06:23:52PM +, Mark Dickinson wrote:
> - Should we require IEEE 754 floating-point for CPython-the-implementation?
> - Should we require IEEE 754 floating-point for Python-the-language?
If the answer to those questions are Yes, that rules out using Unums,
posits, sigmo
On Tue, Feb 08, 2022 at 05:48:46PM -0800, Gregory P. Smith wrote:
> On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano wrote:
> > If the answer to those questions are Yes, that rules out using Unums,
> > posits, sigmoid numbers etc as the builtin float. (The terminology is a
On Sat, Mar 05, 2022 at 11:27:44AM +0200, Serhiy Storchaka wrote:
> Currently the class can inherit from arbitrary objects, not only types.
Is that intentionally supported?
I know that metaclasses do not have to be actual classes, they can be
any callable with the correct signature, but I didn
On Sat, Mar 05, 2022 at 04:42:55PM -, Jason Madden wrote:
> zope.interface relies on this behaviour.
The example you give shows that Interface is a class. It merely has a
metaclass which is not `type`. (I presume that is what's going on
behind the scenes.)
I'm asking about the example that
On Sat, Apr 02, 2022 at 09:28:55AM -0700, Christopher Barker wrote:
> Anyway, it would be nice for someone to take up the mantle of getting an
> immutable Mapping into the stdlib.
Here is a "FrozenMapping" class that could be added to collections. I
have tested it ~~extensively~~ for nearly two
On Mon, Apr 04, 2022 at 09:27:46AM -0700, Coyot Linden (Glenn Glazer) wrote:
> On 4/4/22 09:25, Paul Moore wrote:
> >On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer)
> > wrote:
> >>>I would welcome a multiline comment format that didn't involve
> >>>docstrings.
> >>Err, sorry, I meant mult
On Fri, Apr 08, 2022 at 08:24:40AM +, Malthe wrote:
> But firstly, let me present the idea. It is very simple, that Python
> should have declarative imports,
I'm not sure I understand why you consider this "declarative".
https://en.wikipedia.org/wiki/Declarative_programming
As I see it, th
On Sun, Apr 17, 2022 at 08:35:06PM +0100, MRAB wrote:
> You could return only the current attributes by default, but the extra
> attributes on demand. (Slightly strange, but backwards-compatible.)
> Slicing could also return what was requested, e.g. t[ : 4] would return
> the first 4, t[ : 5] t
On Sun, Apr 17, 2022 at 06:20:53PM +0100, Pablo Galindo Salgado wrote:
> These APIs are inspect.getframeinfo, inspect.getouterframes,
> inspect.getinnerframes, inspect.stack and inspect.trace.
Are you referring to the FrameInfo namedtuple rather than the functions
themselves?
inspect.stack() a
On Fri, Apr 22, 2022 at 06:13:57PM -0700, Larry Hastings wrote:
> This PEP proposes an additional syntax for declaring a class which splits
> this work across two statements:
> * The first statement is `forward class`, which declares the class and binds
> the class object.
> * The second stateme
On Sat, Apr 23, 2022 at 06:41:23AM -, Mehdi2277 wrote:
> My main question for this approach is how would this work with type
> checkers? Is there any restriction that forward class's continuation
> must appear in same module? If it's allowed that a forward class may
> be continued in a dif
On Fri, Apr 22, 2022 at 10:09:33PM -0700, Larry Hastings wrote:
[Larry]
> >>To be clear: `forward class` creates the official, actual class object.
> >>Code that wants to take a reference to the class object may take
> >>references
> >>to the `forward class` declared class, and interact with it a
On Sat, Apr 23, 2022 at 12:46:37AM -0700, Larry Hastings wrote:
> But rather than speculate further, perhaps someone who works on one of
> the static type analysis checkers will join the discussion and render an
> informed opinion about how easy or hard it would be to support "forward
> class"
On Mon, Apr 25, 2022 at 10:32:15PM -0700, Larry Hastings wrote:
[...]
> Whichever spelling we use here, the key idea is that C is bound to a
> "ForwardClass" object. A "ForwardClass" object is /not/ a class, it's a
> forward declaration of a class. (I suspect ForwardClass is similar to a
> ty
I believe that your example is the same as this recently opened bug
report.
https://github.com/python/cpython/issues/93167
--
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
Now that we have a new parser for CPython, can we fix the old gotcha
that raw strings cannot end in a backslash?
Its an FAQ and has come up again on the bug tracker.
https://docs.python.org/3/faq/design.html#id26
https://github.com/python/cpython/issues/93314
--
Steve
__
Thank you to everyone who responded, it is now clear to me that this
genuinely is a feature, not a bug or limitation of the parser or lexer.
And that there is code relying on that behaviour, including in the
stdlib, so we shouldn't change it even if we could.
--
Steve
On Wed, Jul 20, 2022 at 05:43:26PM -0700, Ethan Furman wrote:
> It works, but I wouldn't say "quite well" -- any thread from discourse is
> one long linear series of replies, and reading them in chronological order
> means jumping around and trying to figure what is a reply to what.
Sometimes,
On Mon, Jul 18, 2022 at 6:28 AM Petr Viktorin wrote:
> On 16. 07. 22 8:48, Miro Hrončok wrote:
> > On 15. 07. 22 13:18, Petr Viktorin wrote:
> >> - You can use discuss.python.org's “mailing list mode” (which
> >> subscribes you to all new posts), possibly with filtering and/or
> >> categorizing m
On Thu, Jul 21, 2022 at 07:06:47PM -0400, Edwin Zimmerman wrote:
> Mailing list mode is not what you want. Instead, turn mailing list mode off
> and set your email settings to these:
>
>
>
> You can adjust the categories you receive email notifications for by changing
> your list of watched
On Thu, Jul 21, 2022 at 3:42 PM Steven Barker wrote:
> So last night I tried activating mailing list mode [...]
>
To follow up on my own post, here's an update. I figured out that I'd done
something incorrectly the first time I tried muting certain categories of
posts on Disc
PI"
is, I think, unrealistic puritism, not to mention unfairly disparaging
towards the programmers who write those APIs.
> The problem is, that I never actually thought about his suggested way.
Some people have, and found that it doesn't always simplify the API that
On Mon, Nov 28, 2022 at 11:13:34PM +, Oscar Benjamin wrote:
> On Mon, 28 Nov 2022 at 22:56, Brett Cannon wrote:
> > That's actually by design. Sets are not meant to be deterministic
> > conceptually as they are essentially a bag of stuff. If you want
> > deterministic ordering you should co
On Tue, Nov 29, 2022 at 01:34:54PM +1300, Greg Ewing wrote:
> I got the impression that there were some internal language reasons
> to want stable dicts, e.g. so that the class dict passed to __prepare__
> preserves the order in which names are assigned in the class body. Are
> there any such use
On Tue, Nov 29, 2022 at 02:07:34AM +, Oscar Benjamin wrote:
> Let's split this into two separate questions:
Let's not. Your first question about non-deterministic set order being
"innately good" is a straw man: as we've already discussed, set order is
not non-deterministic (except in the in
On Tue, Nov 29, 2022 at 08:51:09PM -, Yoni Lavi wrote:
> It does make your argument invalid though, since it's based on this
> assumption that I was asking for a requirement on iteration order
> (e.g. like dict's iteration order = insertion order guarantee), which
> is not the case.
Yoni,
On Thu, Dec 01, 2022 at 10:18:49PM +, Rob Cliffe via Python-Dev wrote:
> Wild suggestion:
> Make None.__hash__ writable.
> E.g.
> None.__hash__ = lambda : 0 # Currently raises AttributeError:
> 'NoneType' object attribute '__hash__' is read-only
You would have to write to `type(None)
On Sun, Dec 04, 2022 at 08:20:56PM +, Barney Gale wrote:
> Oh brilliant. I'll unsubscribe from this list then. It sounds like the only
> people using it will be those folks who think their tooling preferences are
> more important than creating a joined-up Python community; I can survive
> with
On Thu, Jan 26, 2023 at 08:34:04PM +0100, Thomas Ratzke wrote:
> Hi all,
>
> i would like to suggest the following Python feature. It naturally
> happens that one want's to repeat the current iteration of a for loop
> for example after an error happened.
Can you give an example of when you wou
es, I have needed to do this.) All of these
raise the same TypeError, even though only one of them is an actual
error with the type:
len(1) # An actual TypeError
len([], None) # The type of the argument is fine.
len(spam=[]) # The type of the argument is fine.
Plea
ges are not part of the API and could change at any time,
including in bug fix releases. Over the last few years, we've made a lot
of progress in making error messages more informative:
python2.4 -c "len(None)"
TypeError: len() of unsized object
python2.7 -c "len(None)"
On Thu, Aug 08, 2019 at 04:28:28PM -0700, Barry Warsaw wrote:
> On Aug 8, 2019, at 14:58, Steven D'Aprano wrote:
>
> > It's not a syntax error. There's nothing wrong with the syntax per-say:
> > we still have ``target := expression``. There's a problem w
On Wed, Aug 07, 2019 at 07:47:45PM +1000, Chris Angelico wrote:
> On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote:
> > What's the rush? Let's be objective here: what benefit are we going to
> > get from this change? Is there anyone hanging out desperately f
r"""Documentation ...
C:\directory\
"""
[...]
> >Even in a raw literal, quotes can be escaped with a backslash
Indeed, they're not so much "raw" strings as only slightly blanched
strings.
--
Steven
_
I'm not trying to be confrontational, I'm trying to understand your
use-case(s) and see if it would be broken by the planned change to
string escapes.
On Fri, Aug 09, 2019 at 03:18:29PM -0700, Glenn Linderman wrote:
> On 8/9/2019 2:53 PM, Steven D'Aprano wrote:
> >On Fr
ng Github.)
I have reported it to docutils:
https://sourceforge.net/p/docutils/bugs/373/
[...]
> So put these warnings front and center now
> so package and code maintainers actually see it
The problem is that this seriously and negatively affects the experience
for many end-users. That
ode, we can
read them from a config file or database.
It is unfortunate that Windows is so tricky with backslashes and
forwards slashes, and that it clashes with the escape character, but I'm
sure that other languages which use \ for escaping haven't proliferated
a four or more kinds of
e (hopefully
there is only one!) that needs it, by a simple global that shadows the
built-in:
import builtins
def str(obj):
assert not isinstance(obj, bytes)
return builtins.str(obj)
instead of putting it into builtins itself.
--
Steven
___
ines or comments. Machine generated code surely doesn't need blank
lines. Blank lines could be stripped out; comments could be moved to
another file. I see no real difficulty here.
--
Steven
___
Python-Dev mailing list -- python-dev@pyth
ary precision rationals (fractions) as their numeric type. That
sounds all well and good, until you try doing a bunch of calculations
and your numbers start growing to unlimited size. Do you really want a
hundred billion digits of precision for a calculation based on
measurements m
suppose there could
be a justification for such a design.
(Quoted sizes on my system running 3.5; YMMV.)
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.
etc. But I suppose there could
> > be a justification for such a design.
>
> You're saying that someone might have a justification for deliberately
> creating a million classes,
Yes. I *personally* cannot think of an example that wou
Z4RVSHSQG52VKCQ
and may not reflect the current state of the PEP.)
Having said that though, I think you are right that the PEP could do
with a bit more detail on the current status quo and existing limits,
and how the proposed changes will improve safety and memory use.
--
Steven
_
subsequent versions can work fine with this (although it is slow).
Thanks, this is a good practical anecdote of real-life experience.
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@
the old "narrow
versus wide Unicode" builds. It doubles (at least!) the amount of effort
needed to maintain Python, for something which (if the PEP is correct)
benefits nearly nobody but costs nearly everyone.
--
Steven
___
Python-Dev
pt the three
you've decided to remove from the PEP (number of coroutines, number of
classes, number of lines of code).
Better to pick differing limits without caring if they are the same,
based on the need for that specific resource.
--
Steven
___
order to gain this much in safety, maintainability, efficiency.
And before people jump down my throat again, I've already said -- on
multiple occassions -- that the onus is on Mark to demonstrate the
plausibility of any such gains.
Thank you for reading :-)
--
Steven
thon.org/3/library/functions.html#sorted
Should we document that all four functions will use l.t. if it exists,
otherwise g.t. if it exists, but don't need both?
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe s
On Sat, Dec 14, 2019 at 02:40:04PM +0200, Serhiy Storchaka wrote:
> 14.12.19 12:45, Steven D'Aprano пише:
> >The list.sort method is documented to only use less than:
> >
> >https://docs.python.org/3/library/stdtypes.html#list.sort
> >
> >but I don't thi
On Sat, Dec 14, 2019 at 04:20:43PM +0200, Serhiy Storchaka wrote:
> 14.12.19 15:29, Steven D'Aprano пише:
> >I might be misinterpreting the evidence, but sorting works on objects
> >that define `__gt__` without `__lt__`.
[...]
> The `<` operator try to use `__lt__`, but
e reason we have sets, rather than a
bunch of extra methods like intersection and symmetric_difference on
lists, is because we considered performance.
[1] Well... maybe a tiny bit... *wink*
--
Steven
___
Python-Dev mailing list -- python-dev@pytho
or
double quotes for the std lib, except that doc strings should use triple
double-quotes. Each project or even each module is free to choose its
own rules.
https://www.python.org/dev/peps/pep-0008/#string-quotes
--
Steven
___
Python-Dev mailing
. I'm just thinking that there should be
> some way to guarantee a well defined "useful" float output formatting.
https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting
https://docs.python.org/3/library/string.html#format-string-syntax
--
Steven
_
I understand that %.17e
is guaranteed to round-trip exactly for all floats (C doubles):
py> '%.17e' % 94.0
'9.4e+01'
If you care about length, "94" is shorter than "94.0" and it still
losslessly converts back to the float 94.0:
Python please see the Python help page.
https://mail.python.org/mailman3/lists/python-dev.python.org/
Is there something we could do to make that more obvious, clear or
helpful?
Regards,
Steven
On Tue, Jan 21, 2020 at 08:38:30PM +, Zak Mabbott via Python-Dev wrote:
> I am rea
why NAN != NAN except inside
collections.
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
htt
n(x) for x in values)
that does not mean that
math.nan in values
*should*, let alone *will*, return True.
> So it's not even an "optimization" but rather "behavior".
It is both. It is an optimization which also have an observable change
in behaviour.
--
Steven
_
PyPy nevertheless offers the illusion that such lists
contain objects, complete with IDs. They even manage to keep the ID
consistent across copies. For example:
>>>> L = [99]
>>>> id(L[0])
1585
>>>> id(L[:][0])
1585
so even if the list
On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote:
> On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote:
> >
> > The only thing I'm unsure of here is whether direct use of the `==` and
> > `!=` operators are included as "implicit calls" t
the word "equivalent" be used for this, perhaps?
We don't need and shouldn't have a dunder for this, but the word
"equivalent" would be wrong in any case. Two objects may be equivalent
but not equal, for example, when it com
identical or equal"
API will (as far as I can see) change nothing about the semantics,
behaviour or even implementation (since the C-level containers like list
will surely still call PyObject_RichCompareBool rather than a
Python-level wrapper).
So whatever inconsistencies exist, they will still exis
[Brandt]
> So this has immediate benefits for both usability and maintenance:
> subclasses only need to override `copy()` to get working
> `__or__`/`__ror__` behavior.
Indeed, except it should be the dunder `__copy__`.
--
Steven
__
On Sun, Feb 16, 2020 at 02:12:48PM -0800, Guido van Rossum wrote:
> So can we just finish PEP 584 without the .copy() call?
Fine by me.
Thanks to everyone!
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an em
On Tue, Feb 18, 2020 at 05:35:38PM -, Brandt Bucher wrote:
> > I am accepting this PEP. Congratulations Steven and Brandt!
>
> Thank you for your guidance, especially the suggestions late last
> year. And thanks Steven for taking me on as a co-author and shaping
> the bu
g `==`, yes, I see that frequently. But relying on object identity
to see whether a new string was created by a method, no.
If you want to know whether a prefix/suffix was removed, there's a more
reliable way than identity and a cheaper way than O(N) equality. Jus
tion,
metaclass, thread, process, CPU, gigabyte, async, ethernet, socket,
hexadecimal, iterator, class, instance, HTTP, boolean, etc without
blinking, but you're shying at prefix and suffix?
--
Steven
___
Python-Dev mailing list -- python-dev@py
s to delete a prefix or suffix, but when the only other choices are
such obviously wrong methods as upper(), find(), replace(), count() etc
it is easy to jump to the wrong conclusion that strip does what is
wanted.
--
Steven
___
Python-Dev mailin
and
this isn't supported:
"extraordinary".replace(('ex', 'extra'), '')
We ought to get some real-life exposure to the simple case first, before
adding support for multiple prefixes/suffixes.
--
Steven
__
ons
You already state that the methods will show "roughly the following
behavior", so there's no expectation that it will be precisely what
the real methods do.
Aim for clarity over emulation of unusual corner cases. The reference
implementation is info
a good reason to
add this feature and you haven't established any good use-cases for it.
A closer analog is str.replace(substring, ''), and after almost 30 years
of real-world experience, that method still only takes a single
substring, not a tuple.
--
Steven
__
The Zen of Python has something to say about guessing in the face of
ambiguity.
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/py
h sense as any other null-operation, such as subtracting
0 or deleting empty slices from lists.
Every string s is unchanged if you prepend or concatenate the empty
string:
assert s == ''+s == s+''
so removing the empty string should obey the same invariant:
a
On Sat, Mar 28, 2020 at 01:20:11PM +0200, Serhiy Storchaka wrote:
> 2. In many case it is more convenient to have a repr in the form
> Color.RED or even just RED instead of .
+1
--
Steven
___
Python-Dev mailing list -- python-dev@python.
the start value as a start value
(1, 'c'), (0, 'b'), (-1, 'a')
# treat the start value as an end value
(3, 'c'), (2, 'b'), (1, 'a')
Something else?
My preference would be to treat the starting value as an ending value.
Steven
On Wed,
idn't we conclude from `as` that having context-sensitive keywords was
a bad idea?
Personally, I would not like to have to explain to newcomers why `match`
is a keyword but you can still use it as a function or variable, but not
other keywords like `raise`, `in`, `def` etc.
match e
even harder because we have three
classes of words:
* words that are never reserved
* words that are sometimes reserved, depending on what is around them
* words that are always reserved
I had thought that "no context-sensitive keywords" was a hard rule, so I
was surprised that you a
On Mon, Apr 06, 2020 at 07:03:30PM -0700, Guido van Rossum wrote:
> After 30 years am I not allowed to take new information into account and
> consider a change of heart? :-)
Of course :-)
--
Steven
___
Python-Dev mailing list -- pyth
ximately equal".
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archi
ceive an extra argument, fill in the
default if missing, and branch is significant.
I don't think that `zip(*args, strict=flag)` is the wrong choice because
it's a nanosecond slower, I think it's the wrong choice because it makes
for a p
Note that options 1 and 2 have an important advantage over options 3 and
4: the strict version of zip is a first-class callable object that can
be directly passed around and used indirectly in a functional way.
E.g. for testing using unittest:
assertRaises(zip.strict, 'a
flag makes the zip strict a second class citizen.
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived a
hen the object is an instance of `object`:
versus for example:
Since there's no builtin type `instance` and is unlikely to ever be one,
I think that "instance" is a better word to use.
It's probably not worth changin
EP, it was requested in the discussions on Python-Ideas.
> That improved self-documentation then becomes what I would consider the
> strongest argument in favour of the flag-based approach:
I don't think that "truncate=False" (which can mean three different
things) is mor
oing to communicate
everything we need to communicate. Function and parameter names are
mnemonics, not documentation.
So on that note, and in regard only to the choice between "strict"
versus "truncate" etc, I'm going to bow out: call it what you will. I&
. The whole point of the REPL is to evaluate an
expression and have the result printed. (That's the P in REPL :-)
`stdout.write(...)` is an expression that returns a value, so the REPL
prints it.
--
Steven
___
Python-Dev mailing list -- python-d
e perspectives.
The CoC doesn't mention the word "tolerant" or "tolerance", but there
was nothing of either in Thomas' post. And coming from a PSF Board
member, I think that is extremely worrying.
Steven
On Tue, Jun 30, 2020 at 12:42:40PM +0200, Antoine Pitr
enturies, it was in common use at least back in the 1970s and
1980s, e.g. see the citations here:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4293036/
--
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python
901 - 1000 of 1900 matches
Mail list logo