On Sat, Nov 21, 2020 at 07:16:22AM -0500, Edwin Zimmerman wrote:
> On 11/20/2020 11:53 PM, Chris Angelico wrote:
> > [snip]
> > Use the simpler options until you can't use them. Then use the more
> > complicated options.
> Yea, use the simpler options. This is why I have switched from Python
>
On Fri, Nov 20, 2020 at 01:06:11AM -0800, Brendan Barnwell wrote:
> So are you suggesting that every single app should always be
> distributed as source code, run by a separate interpreter that users
> install separately?
My system has approximately sixty gajillion[1] apps installed that
On Thu, Nov 19, 2020 at 10:46:50PM -0800, Brendan Barnwell wrote:
> Yes, that's correct. All of what you described is how ordinary apps
> work. If I install a program and it has a bug or security
> vulnerability, then I am affected by that vulnerability. Having a way
> to install a
On Thu, Nov 19, 2020 at 11:24:32PM +, Paul Moore wrote:
> I'm not sure about an installer. To me that means integrating with
> system "installed apps" mechanisms. But I *would* support building an
> "unzip and run" style of distribution.
Don't zip files support self-extracting archives?
On Thu, Nov 19, 2020 at 08:21:26PM -, William Pickard wrote:
> TL/DR: A new built-in attribute who's purpose is to provide a simple
> way for developers to detect the Python implementation like CPython,
> JPython, IronPython and PyPy among other information.
>>> import sys
>>>
On Fri, Nov 20, 2020 at 02:05:02AM +1300, Greg Ewing wrote:
> On 20/11/20 12:24 am, Chris Angelico wrote:
> >
> >Have you considered the value of using zipapp
>
> >You get all the advantages of a single runnable file, and
> >all the advantages of NOT including the full Python interpreter with
>
On Thu, Nov 19, 2020 at 01:02:17PM +0400, Abdur-Rahmaan Janhangeer wrote:
> Thank you for your input Mr Steven.
> If we go along the same lines, i should
> begin checking whether anyone who replies
> forms part of the SC or not, whether they
> have the right or not to reply to this thread etc.
On Thu, Nov 19, 2020 at 10:29:38AM +0100, M.-A. Lemburg wrote:
> Note that this does not mean "relinquishing" the copyright as
> Steven put it. The copyright owners keep their copyright. They
> only give permission specifically to the PSF to relicense the
> code.
Oops, thank you for the
On Thu, Nov 19, 2020 at 08:22:40AM +0400, Abdur-Rahmaan Janhangeer wrote:
>
> What do you think of adding PyInstaller as an official
> part of CPython?
Before asking *us*, you ought to ask what the PyInstaller developers
think of the idea of:
- relinquishing copyright to the PSF;
- operating
On Thu, Nov 19, 2020 at 10:49:13AM +0400, Abdur-Rahmaan Janhangeer wrote:
> Greetings list,
>
> > The purpose of executables is to make it harder to apply bug fix
> releases of Python? I thought that was an unwanted side effect.
>
> I think you mis-understood me by me making myself not clear
>
On Tue, Nov 17, 2020 at 10:17:32PM +, Oscar Benjamin wrote:
> It would be nice if islice gave an object that supported slicing so
> that you could spell it like:
>
>for x in islice(a)[5:]:
>
> I find it hard to decipher the meaning of the arguments to islice
> compared to reading a
On Tue, Nov 17, 2020 at 03:42:54AM -, Nuri Jung wrote:
> How about enabling subscription operator (`[]`) for generator expressions?
Generator expressions are iterators, and the iterator protocol is
intentionally very simple. You only need to provide two things for an
object to be an
On Sat, Nov 14, 2020 at 10:17:34PM -0800, Guido van Rossum wrote:
> It’s a usability issue; mappings are used quite differently than sequences.
> Compare to class patterns rather than sequence patterns.
I'm keeping an open mind on this question, but I think David
is right to
raise it. I think
On Sat, Nov 14, 2020 at 05:22:41PM +, Jonathan Fine wrote:
> The module __main__ is somewhat special. It's there from the very beginning
> (so far as I can tell).
https://docs.python.org/3/library/__main__.html
[...]
> 2. When initializing the built-in __main__ module, set
>
On Sat, Nov 14, 2020 at 08:10:44AM -0400, André Roberge wrote:
> > What if you import the `__main__` module? What does `__imported__` say
> > now, and how do you check for "running as a script" if `__main__` has
> > imported itself -- or some other module has imported it?
> >
>
> Running a
On Fri, Nov 13, 2020 at 05:59:29AM -0400, André Roberge wrote:
> As a goal of making it even more obvious what the (new) idiom mans, I would
> suggest a variable named __imported__ with the opposite value to what is
> proposed.
What if you import the `__main__` module? What does `__imported__`
On Sat, Nov 14, 2020 at 04:32:20AM +, Steve Barnes wrote:
> I love the idea of __imported__ but would like to suggest taking it
> even further - why not, rather that a bool for __imported__, have the
> value of it be either None (if __name__ == "__main__")
What if you imported `__main__`?
On Thu, Nov 12, 2020 at 06:33:52PM +, Rob Cliffe via Python-ideas wrote:
> I find this a curious argument. A bit like saying "Here are your new
> shoes; they weigh 10Kg but that's absolutely great because you'll
> develop stronger legs wearing them".
Do you honestly think that writing
On Thu, Nov 05, 2020 at 09:41:45PM +0300, Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 5 Nov 2020 18:46:53 +0100
> Hans Ginzel wrote:
>
> > Is there a reason, why not to make python useful for practical one
> > liners to replace perl and awk?
> > There is page Powerful Python One-Liners,
> >
On Tue, Nov 03, 2020 at 11:10:37AM -0800, Ethan Furman wrote:
> After discussions with Guido I made a (largely done) PR [3] which:
>
> for stdlib global constants (such as RE)
>- repr() -> uses `module.member_name`
>- str() -> uses `member_name`
What's `RE`? Do you mean the enums in the
On Sat, Oct 31, 2020 at 09:05:43PM -0700, Guido van Rossum wrote:
> Hm, for PEP 622/634 we looked at this and ended up making it so that this
> is the default -- you only have to write
> ```
> {'spam': spam, 'eggs': eggs} = mapping
> ```
> and any extra keys are ignored. This is because for the
On Sat, Oct 31, 2020 at 08:24:04AM +, Barry Scott wrote:
> > On 31 Oct 2020, at 06:35, Steven D'Aprano wrote:
> >
> > I think we can promise that:
> >
> > * if the mapping on the right has missing keys, no assignments occur;
> >
> > *
On Mon, Oct 26, 2020 at 04:56:24AM -, Dennis Sweeney wrote:
> What if the mapping assignment were more harmonious with the pattern matching
> PEP? Something like this:
>
> items = {'eggs': 2, 'cheese': 3, 'spam': 1}
> {'eggs': eggs, 'spam': i_dont_need_to_name_this_spam, **rest} =
On Sat, Oct 24, 2020 at 09:26:23PM -, Joseph Martinot-Lagarde wrote:
> Steven D'Aprano wrote:
> > # Dotted names
> > from types import SimpleNamespace
> > obj = SimpleNamespace()
> > obj.spam = **{'obj.spam': 1}
> > assert obj.spam == 1
> >
> > #
On Fri, Oct 23, 2020 at 02:23:58AM -0400, David Mertz wrote:
> See my very detailed posts on EXACTLY the concepts you discuss.
>
> "whether 'bar' is a name"? It is definitely a name, what you have no means
> > to know is whether it has been assigned a value. I suspect you're trying to
> > do the
On Fri, Oct 23, 2020 at 10:19:07AM +0200, Alex Hall wrote:
> On Fri, Oct 23, 2020 at 5:27 AM Steven D'Aprano wrote:
>
> > Background
> > --
> >
> > Iterable unpacking assignment:
> >
> > values = (1, 2, 3)
> > a, b, c = *values
>
On Thu, Oct 22, 2020 at 09:11:57PM -0700, Guido van Rossum wrote:
> Oh, that's quite different than mapping patterns in PEP 634. :-(
That wasn't intentional, and to be honest I hadn't noticed the mapping
patterns in 634 as yet. (There's a lot in that PEP.)
Having read that now, I think I see
I would like to propose dict (or mapping) unpacking assignment. This is
inspired in part by the Python-Ideas thread "f-strings as assignment
targets", dict unpacking in function calls, and iterable unpacking
assignment.
Comments welcome.
Background
--
Iterable unpacking assignment:
On Thu, Oct 22, 2020 at 09:09:07AM -0700, Guido van Rossum wrote:
> On Thu, Oct 22, 2020 at 3:37 AM Hans Ginzel wrote:
>
> > Thank you for (ugly) workaorund.
> >
>
> Careful who you're calling ugly.
"Who"? Syntax is a person now?
For what it's worth, I don't think escaping special symbols is
On Thu, Oct 22, 2020 at 12:29:22PM +0200, Hans Ginzel wrote:
> >We could do that, but this is more likely to just hide bugs in the
> >f-string than be useful.
>
> Thank you, that would be great and useful.
Oh, sorry Hans, I think that you may have misunderstood me.
In English, "We could do
On Thu, Oct 22, 2020 at 10:58:00AM +0200, Hans Ginzel wrote:
> Hello,
>
> consider this snippet please
>
> cursor.execute(f"INSERT INTO {table} VALUES (1, '{}');")
> SyntaxError: f-string: empty expression not allowed
Escape the braces by doubling them:
f"INSERT INTO {table} VALUES (1,
On Wed, Oct 21, 2020 at 07:17:21PM -0700, Guido van Rossum wrote:
> Hmm, if the above is acceptable, maybe f-strings are still the logical next
> step, since they bring the format and the target name together again.
That's not the only way to bring the format and target name together.
Both
On Wed, Oct 21, 2020 at 12:16:16PM +1100, Chris Angelico wrote:
> Please explain how it's "spooky action at a distance" if it's a
> self-contained assignment statement?
"Spooky action at a distance" is your phrase, not mine, or Rob's.
(I think David Mertz may have used it first, but I don't
On Wed, Oct 21, 2020 at 11:07:28AM -0700, Christopher Barker wrote:
> As for the question of do we need a scanning language at all? We already
> have pretty full features string methods, and regex for the complex stuff.
>
> I think yes -- for both simplicity for the simple stuff (the easy stuff
On Wed, Oct 21, 2020 at 10:49:41AM +1100, Chris Angelico wrote:
> On Wed, Oct 21, 2020 at 10:39 AM Steven D'Aprano wrote:
> > > The
> > > f-string has to be a literal - it's not a magic object that you can
> > > assign to and new locals appear.
> >
>
On Tue, Oct 20, 2020 at 04:26:16PM -0700, Guido van Rossum wrote:
> So this would break many uses of locals(). I'm not sure I like that.
That's a good point I didn't think of.
We could rescue the concept by saying that any reference to locals()
inside the function disables the elimination, but
On Wed, Oct 21, 2020 at 02:15:40AM +1100, Chris Angelico wrote:
> On Tue, Oct 20, 2020 at 11:54 PM Steven D'Aprano wrote:
> > The only advantage, I guess, of f-string like syntax is that the
> > variable names can be embedded inside the template string:
> >
> > f&q
On Wed, Oct 21, 2020 at 06:17:27AM +1100, Chris Angelico wrote:
> No; it can fail if the pattern actually rejects it. For instance, a
> pattern of "a{x}b{y}c" can match the string "a" but won't assign to y,
It won't assign to x either, if I'm understanding it correctly, since
there is nothing
On Tue, Oct 20, 2020 at 05:30:54PM +0300, Serhiy Storchaka wrote:
> I do not want to create tens of alternate PEPs with minor variations,
> and this issue is not worth a PEP. What is your opinion about this? Is
> it worth to include such optimization? For what kind of variables should
> it be
On Wed, Oct 21, 2020 at 03:19:20AM +1100, Chris Angelico wrote:
> In every sscanf-like system I've used, there is a default value of
> some sort, either because variables are automatically initialized, or
> because the sscanf construct itself provides a default.
Then it won't go "Boom!" as you
On Wed, Oct 21, 2020 at 02:18:49AM +1100, Chris Angelico wrote:
> > Er, well, why not just add a sscanf to Python?
>
> A couple of reasons, but the main one is that you can't have "output
> variables" (in C, sscanf takes pointers, so you pass it the address of
> your variables), which means that
On Sun, Sep 20, 2020 at 03:59:40AM +0100, Rob Cliffe via Python-ideas wrote:
> -1 on the whole proposal.
I agree with the negative on this proposal. I don't think that f-strings
are a good fit for this, and I'm not sure that we need syntax for
something that could be handled by a function
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
Oops, I messed up. (Thanks David for pointing that out.)
On Sun, Oct 18, 2020 at 07:45:40PM +1100, Steven D'Aprano wrote:
> Each of these number systems have related, but slightly different,
> rules. For example, IEEE-754 has a single signed infinity and 2**INF is
> exactly equ
On Sun, Oct 18, 2020 at 03:26:11AM -0400, Wes Turner wrote:
> assert math.inf**0 == 1
> assert math.inf**math.inf == math.inf
Wes, I don't understand what point you are trying to make here. Are you
agreeing with that behaviour? Disagreeing? Thought it was so surprising
that you can't imagine
On Fri, Oct 16, 2020 at 10:28:20PM -0400, David Mertz wrote:
> On Fri, Oct 16, 2020, 10:16 PM Steven D'Aprano
>
> > I think that if we go ahead with this, we shouldn't allow lack
> > of support for screen and/or tmux to stand in the way. A 99% solution is
> > b
On Fri, Oct 16, 2020 at 09:53:35PM -0400, David Mertz wrote:
> On Fri, Oct 16, 2020 at 9:36 PM Steven D'Aprano wrote:
>
> > > Well, in terminals like bash, `clear` does not really delete the
> > > previous input. It simply move the scroll so the first line of the
> >
On Fri, Oct 16, 2020 at 11:30:56PM +0200, Marco Sulla wrote:
> Well, in terminals like bash, `clear` does not really delete the
> previous input. It simply move the scroll so the first line of the
> input is the current input.
That's not actually correct: in bash, `clear` actually deletes the
On Sat, Oct 17, 2020 at 05:44:12AM +1100, Chris Angelico wrote:
> On Sat, Oct 17, 2020 at 5:40 AM Jonathan Crall wrote:
> >
> > I just want to point out that I can think of a valid use case for `clf`.
> > I'm not sure if it was mentioned.
> >
> > In the case where you have a script that produces
On Fri, Oct 16, 2020 at 02:14:27AM +0100, Rob Cliffe via Python-ideas
wrote:
> >You mean like a goto statement? I'm not sure what a "pseudo-loop"
> >is, other than a way to use break as goto.
> >
> >ChrisA
>
> Is that bad? As I tried to explain, sometimes a process may need to be
>
On Thu, Oct 15, 2020 at 11:28:36AM +1100, Chris Angelico wrote:
> Neither 1/3 nor sqrt(2) can be *exactly represented* as a decimal
> fraction.
Indeed, I am very aware of that, and in fact they were precisely the
examples I gave to question Random's assertion that inexact rounding is
something
On Wed, Oct 14, 2020 at 03:33:22PM -0400, Random832 wrote:
> That is nonsense. "exactly representable" is a plain english phrase
> and has a clear meaning that only involves the actual data format, not
> the context.
Perhaps your understanding of plain English is radically different from
On Tue, Oct 13, 2020 at 02:08:11PM -, jmwar...@gmail.com wrote:
> I am not particularly concerned with performance here. I am more
> worried about code clarity, boilerplate that de-incentivizes a feature
> and hidden values.
Okay.
> The current exception mechanism encourages passing,
>
Hello Ankith,
On Tue, Oct 13, 2020 at 11:37:25AM +0530, ankith abhayan wrote:
> Hi,
> I would like to request a new feature that allows you to clear the console
> screen.
> Like in c++, the CLS function
Can you be specific? I can think of at least three behaviours:
1. Move all existing
On Tue, Oct 13, 2020 at 03:35:58PM -0700, Guido van Rossum wrote:
> Can one of the educators on the list explain why this is such a commonly
> required feature? I literally never feel the need to clear my screen -- but
> I've seen this requested quite a few times in various forms, often as a bug
On Tue, Oct 13, 2020 at 12:47:45PM -0400, David Mertz wrote:
> On Tue, Oct 13, 2020 at 6:18 AM Steven D'Aprano wrote:
>
> > I don't think that a two line class (perhaps a couple of extra
> > lines if you give it a docstring) justifies the name "boilerplate":
> >
Hi jmward01,
I'm not really sure what you mean by "boilerplate heavy objects".
*Boilerplate* generally applies to the amount of source code you have to
write. I don't think that a two line class (perhaps a couple of extra
lines if you give it a docstring) justifies the name "boilerplate":
On Mon, Oct 12, 2020 at 09:40:40PM +1100, Steven D'Aprano wrote:
> Using the proposed syntax, both of these would be written as:
>
> try:
> ...
> except A try:
> ...
> except B:
> ...
> except C:
> ...
>
On Sun, Oct 11, 2020 at 01:04:46PM -0400, Wes Turner wrote:
> (I must have missed the 'try' suffix)
Indeed. And this is, in my opinion, a major problem with the suggestion.
It obfuscates the code, hiding the fact that a new try block has been
started.
To be fair to the proposal, it does save
On Sun, Oct 11, 2020 at 05:47:44PM -0400, Wes Turner wrote:
> No, 2 times something is greater than something. Something over something
> is 1.
Define "something". Define "times" (multiplication). Define "greater
than". Define "over" (division).
And while you are at it, don't forget to define
On Fri, Oct 09, 2020 at 03:53:24AM +1100, Chris Angelico wrote:
> On Fri, Oct 9, 2020 at 3:43 AM Steven D'Aprano wrote:
> >
> > On Thu, Oct 08, 2020 at 11:58:04AM -0400, Random832 wrote:
> >
> > > I was making a "convert Fraction to Decimal, exactly if possible&
On Thu, Oct 08, 2020 at 11:58:04AM -0400, Random832 wrote:
> I was making a "convert Fraction to Decimal, exactly if possible"
> function and ran into a wall: it's not possible to do some of the
> necessary operations with exact precision in decimal:
Of course you can't do them with *exact*
On Wed, Sep 30, 2020 at 11:03:28AM -0300, Sebastian Kreft wrote:
> Have you considered using matrix[row=3], matrix[col=3]? In that case it
> would be a keyword only access. What advantages do you see with your
> current API?
Yes I have considered it.
One possible advantage is that with
On Wed, Oct 07, 2020 at 01:59:24PM +1100, Chris Angelico wrote:
> On Wed, Oct 7, 2020 at 1:46 PM Steven D'Aprano wrote:
> > > Recall that we already have literal expressions such as
> > > >>> [1, 2, 3] # List literal
> > > >>> (1, 2,
On Tue, Oct 06, 2020 at 10:25:01PM -0700, Guido van Rossum wrote:
> On Tue, Oct 6, 2020 at 18:16 Steven D'Aprano wrote:
>
> > For `__advance__` to be an official Python protocol, it would almost
> > certainly have to be of use for *general purpose iterators*, not just
&g
On Tue, Oct 06, 2020 at 04:04:37PM +0100, Jonathan Fine wrote:
> PEP 1, which defines the PEP process, states that any PEP that changes the
> existing language specification should clearly explain "why the existing
> language specification is inadequate to address the problem that the PEP
>
Jonathan,
It sounds like you want to propose a competing PEP that provides your
kwkey as a built-in as an alternative to PEP 637.
I encourage you to do so, although I have no interest in acting as
sponsor, and I fear that your window of opportunity to write a competing
PEP is small.
On Tue, Oct 06, 2020 at 09:30:06AM -0700, aleksiy123 wrote:
> Currently there are a few Protocols
> https://docs.python.org/3/library/typing.html#protocols defined in the
> typing module. One that I recently felt like was missing was a typing
> annotation for classes with a __str__() method
On Tue, Oct 06, 2020 at 02:27:54PM -0700, Caleb Donovick wrote:
> I am +0.3 on this as I don't personally have a need for this but do see the
> utility.
>
> I can think of a number of examples where an `__advance__` would be
> preferable to any of the proposed solutions:
[...]
For `__advance__`
On Fri, Oct 02, 2020 at 11:49:02AM +0900, Stephen J. Turnbull wrote:
> -1 for various reasons expressed by several authors. But I'm not sure
> I agree with this:
>
> Steven D'Aprano writes:
>
> > I think this might make good sense for string methods:
> >
> &
On Thu, Oct 01, 2020 at 04:02:20AM +1000, Steven D'Aprano wrote:
> Hi Konatan, welcome! Comments below.
Oh I'm very sorry, that was a typo, I meant Jonatan.
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an em
Hi Konatan, welcome! Comments below.
On Wed, Sep 30, 2020 at 06:41:04PM +0300, Jonatan wrote:
[...]
> it would be nice if you could implement also __igetattr__ or something,
> which means:
>
> instead of
> con = "some text here"
> con = con.replace("here", "there")
>
> we could do
>
> con =
On Mon, Sep 28, 2020 at 08:19:01PM -0700, Ben Rudiak-Gould wrote:
> Maybe a singleton that supported no useful operations, not even __eq__ or
> __bool__, would be sufficiently inconvenient that it would only be used for
> defaults and "is" tests for said defaults.
NotImplemented is halfway
On Sun, Sep 27, 2020 at 07:59:18AM -0300, Sebastian Kreft wrote:
> Hi Steven, could you share some examples of what you have in mind. Having a
> more concrete example of an API that would benefit from mixed-subscripting
> would allow us to better understand its usefulness.
I have an experimental
On Sat, Sep 26, 2020 at 07:12:00PM -0400, Ricky Teachey wrote:
> Another inconsistency is that the case of keyword arguments only would bind
> the RHS value to the first positional argument, which is the index, and not
> the value. I think this is what Guido was referring to when he responded
>
On Sat, Sep 26, 2020 at 10:43:23PM -0400, Ricky Teachey wrote:
> The problem is that there is lots of existing code like this:
>
> def __setitem__(self, index, value): ...
>
> But the new features will almost certainly lead people to write new code
> like this:
>
> d={}
> obj[**d] = "foo" #
On Sat, Sep 26, 2020 at 03:48:42PM -0700, Christopher Barker wrote:
> On Fri, Sep 25, 2020 at 11:50 PM Steven D'Aprano
> wrote:
> >>
> >> 1. We have to pass a sentinel to the setitem dunder if there is no
> >> positional index passed.
>
>
> I still do
On Sat, Sep 26, 2020 at 10:43:01PM +0100, Nicholas Cole wrote:
> I don't find such examples a conclusive argument in favour of this
> syntax at all.
I wouldn't expect you would -- Stefano made it up as an example of
something that he felt was a poor use of subscripts!
You should not be
On Sat, Sep 26, 2020 at 01:47:56PM -0300, Sebastian Kreft wrote:
> In this fashion have you considering having keyword only indices, that is
> to only allow either obj[1, 2] or obj[row=1, col=2] (if the class supports
> it), and disallow mixing positional and keyword indices, meaning obj[1,
>
On Sat, Sep 26, 2020 at 09:59:27AM +0200, Sascha Schlemmer via Python-ideas
wrote:
> I think a clear distinction has to be made between errors that belong
> to the api surface of a function e.g. some `ValueError` or
> `ZeroDivisionError` and *exceptional* errors e,g.`KeyboardInterrupt`
> or
On Fri, Sep 25, 2020 at 08:52:45PM -1000, David Mertz wrote:
> On Fri, Sep 25, 2020, 5:49 PM Steven D'Aprano
>
> > Since both None and () are likely to be legitimate indexes, and
> > NotImplemented is less likely to be such, I think this supports using
> > NotImplemente
On Sat, Sep 26, 2020 at 01:43:18AM -0400, Ricky Teachey wrote:
> On Fri, Sep 25, 2020 at 11:50 PM Steven D'Aprano
> wrote:
>
> > TL;DR:
> >
> > 1. We have to pass a sentinel to the setitem dunder if there is no
> > positional index passed. What should
Thanks Eric,
On Fri, Sep 25, 2020 at 09:23:56AM +0100, Eric Wieser wrote:
> Thanks for the PEP, and for pinging the numpy list about it. Some comments:
>
> Sequence unpacking remains a syntax error inside subscripts:
> Reason: unpacking items would result it being immediately repacked into a
>
Change of subject line as I wish to focus on a single critical point of
the PEP: keyword-only subscripts.
TL;DR:
1. We have to pass a sentinel to the setitem dunder if there is no
positional index passed. What should that sentinel be?
* None
* the empty tuple ()
* NotImplemented
*
On Fri, Sep 25, 2020 at 09:53:41PM +0100, Stefano Borini wrote:
> On Fri, 25 Sep 2020 at 05:55, David Mertz wrote:
> > Smuggling in a generic function calls in square brackets is
> > undesirable (but obviously not preventable at a language level).
> > However, I feel like keywords might very
On Fri, Sep 25, 2020 at 05:05:52PM -0400, Ricky Teachey wrote:
> * sheepishly, whispering mostly to myself *
>
> All of that could be solved with new dunders.
What would be the signature of the new dunders? How will the new dunders
be backwards compatible?
Previous discussions on this
Quoting levels are a bit messed up in David's post, I've tried to fix
them bu apologies if I'm attributing words to David that he didn't
write.
On Thu, Sep 24, 2020 at 07:04:31PM -1000, David Mertz wrote:
> Is this a breaking change? It feels borderline.
>
> > Keyword-only subscripts are
On Fri, Sep 25, 2020 at 04:58:00PM -0400, Wes Turner wrote:
> On Fri, Sep 25, 2020 at 1:43 PM Steven D'Aprano wrote:
> > Of course rare or unusual exceptions probably won't be discovered
> > without a lot of testing, including stress testing, or not until the
> > code goe
On Fri, Sep 25, 2020 at 08:01:39PM +0100, Paul Moore wrote:
> On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano wrote:
> > There may be practical difficulties in sticking exceptions into
> > annotations. Annotations already can be pretty long and bulky. But if
> > you ar
On Fri, Sep 25, 2020 at 11:14:01PM +1000, Chris Angelico wrote:
> On Fri, Sep 25, 2020 at 7:59 PM Sergio Fenoll wrote:
> > Surely there has to be a better way of programming than running stuff,
> > watching it fail, and then keeping track of how it fails so you can
> > later handle that failure?
On Thu, Sep 24, 2020 at 10:47:21AM +0200, Sergio Fenoll wrote:
> Hi,
>
> I was wondering if the following idea would be a useful addition to the
> Python language and if it could use a new PEP.
> I personally find myself often looking into the documentation &
> implementation of libraries I use
On Thu, Sep 24, 2020 at 07:32:37PM -, henr...@princeton.edu wrote:
> Where is the discussion on this PEP going to be? In this thread, or a
> new thread?
I see no reason why we cannot continue discussion in this thread.
> Sorry for not having followed these closely enough to know. I'd like
On Mon, Sep 21, 2020 at 11:25:52AM +0400, Abdur-Rahmaan Janhangeer wrote:
> > How would this work in practice? After a PEP is accepted, are we
> > supposed to go back through all the references to it and change them all
> > to PAP? Do we expect people to search for "PAP 12345" and "PEP 12345" if
On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote:
> Greeting lists,
>
> I am thinking of proposing to name accepted PEPs as PAPs
> namely: Python Accepted Proposals.
I immediately think of these:
https://www.merriam-webster.com/dictionary/pap
On Fri, Sep 18, 2020 at 12:32:32PM -0400, Wes Turner wrote:
> Is there a list of supported preprocessor directives or compiler directives
> supported by CPython and other tools?
I expect that most tools will have their own list. Python doesn't really
have directives other than `from __future__
On Fri, Sep 18, 2020 at 08:05:27AM -, Joseph Perez wrote:
> Steven D'Aprano wrote:
> > I'm not aware of many refactoring tools for Python at all, [...] I don't
> > know how well IDEs like VisualStudio and PyCharm do refactoring.
>
> This help me to understa
On Fri, Sep 18, 2020 at 10:53:57AM +1000, Chris Angelico wrote:
> On Fri, Sep 18, 2020 at 10:51 AM Steven D'Aprano wrote:
> >
> > On Thu, Sep 17, 2020 at 11:09:35PM +1000, Chris Angelico wrote:
> >
> > > I've frequently yearned for an sscanf-like feature in
On Thu, Sep 17, 2020 at 01:12:02PM -1000, David Mertz wrote:
> I did actually "write the book" on text processing in Python. I think it's
> painful and awkward, and a terrible idea.
*Text processing* is a terrible idea?
Or hammering the square peg of scanf into the round hole of f-strings?
On Thu, Sep 17, 2020 at 09:44:09PM +0200, Alex Hall wrote:
> > The intent being: save the f-string as a variable, and then use it to
> > assign later. But that can obviously never work because q would just become
> > the string "1 2 3" .
> >
>
> The same problem exists for assignments to tuples,
On Thu, Sep 17, 2020 at 09:16:46PM +0200, Alex Hall wrote:
> On Thu, Sep 17, 2020 at 8:57 PM Brendan Barnwell
> wrote:
> > I don't like this at all. It looks like assigning to a literal,
> > which
> > is weird.
>
>
> People keep saying this, but iterable unpacking looks like assigning
801 - 900 of 2842 matches
Mail list logo
