[Python-ideas] Re: Namespace context managers

On Tue, Jul 30, 2019 at 12:54:12PM +1000, Chris Angelico wrote: > A class + decorator gets so almost there that it might be possible > with just a tiny bit of language support. What if there could be a way > to change a function's __globals__? Currently that's readonly > according to funcobject.c,

[Python-ideas] Re: Namespace context managers

On Mon, Jul 29, 2019 at 07:19:42PM -0700, Guido van Rossum wrote: > On Mon, Jul 29, 2019 at 6:55 PM Ricky Teachey wrote: > [Steven] > > > If the core developers don't consider namedtuples important enough to > >> get syntactic support, I doubt that namespaces will. [...] > Except it's wrong. The

[Python-ideas] Re: for ... except, with ... except

On 07/29/2019 06:35 PM, Steven D'Aprano wrote: 3. syntax that solves a problem, but may mislead people to think it solves a different problem until they learn better; 3.1 syntax that solves a problem, but is misleading to many who are still confused after they "have learnt better" I

[Python-ideas] Re: Namespace context managers

On Tue, Jul 30, 2019 at 12:13 PM Steven D'Aprano wrote: > > On Mon, Jul 29, 2019 at 09:53:38PM -0400, Ricky Teachey wrote: > > > But I ask: how is it possible, then, to create a with block that "gobbles > > up" things declared in it and adds those things to some namespace using > > existing python

[Python-ideas] Re: Namespace context managers

> (On the other hand, if this is just a hypothetical "wouldn't it be cool > if this worked?" post, then we're actually no closer to a technical > solution.) That's how I took it. And as has already been said, I definitely don't see how it could be made to work using current syntax. __

[Python-ideas] Re: Namespace context managers

> > Except it's wrong. The successor of namedtuple is typing.NamedTuple which > supports this syntactically. > Point taken. And I definitely don't mean to imply the core devs aren't reasonable people or are unwilling to make big changes, I'm just not experienced enough to be the guy making the ver

[Python-ideas] Re: for ... except, with ... except

On Jul 29, 2019, at 14:49, Guido van Rossum wrote: > > Still I wouldn't call this "a lot worse". What makes you say that? Not “worse” as in more common, or more dangerous (I don’t know if that’s true or not), but as in harder to work around. for…else being confusing and effectively “experts o

[Python-ideas] Re: Namespace context managers

On Mon, Jul 29, 2019 at 6:55 PM Ricky Teachey wrote: [Steven] > If the core developers don't consider namedtuples important enough to >> get syntactic support, I doubt that namespaces will. >> > [Ricky] > This by itself is pretty convincing. > Except it's wrong. The successor of namedtuple is t

[Python-ideas] Re: Namespace context managers

On Mon, Jul 29, 2019 at 09:53:38PM -0400, Ricky Teachey wrote: > But I ask: how is it possible, then, to create a with block that "gobbles > up" things declared in it and adds those things to some namespace using > existing python syntax...? [...] > I currently can't create an object that allows

[Python-ideas] Re: for ... except, with ... except

On Fri, Jul 26, 2019 at 09:26:00PM +0300, Serhiy Storchaka wrote: > Python allows you to write code in tight and readable form. Consider the > following example. > > with connect() as stream: # connect() or __enter__() can fail. > for data in stream: # __next__() can fail >

[Python-ideas] Re: Namespace context managers

> > If the core developers don't consider namedtuples important enough to > get syntactic support, I doubt that namespaces will. > This by itself is pretty convincing. This doesn't "just happen", but because the interpreter does the work I understand that; my conception of the idea was to add t

[Python-ideas] Re: for ... except, with ... except

On Mon, Jul 29, 2019 at 03:12:21PM +0100, Rhodri James wrote: > I'm afraid I agree with Guido. I don't imagine I will use this feature > very often, and I can see myself making that mistake every time. Well, if you don't use this feature very often, you aren't really the audience for the featu

[Python-ideas] Re: for ... except, with ... except

On 30/07/2019 00:07:52, Guido van Rossum wrote: On Mon, Jul 29, 2019 at 3:51 PM Eric Fahlgren > wrote: On Mon, Jul 29, 2019 at 2:58 PM Guido van Rossum mailto:gu...@python.org>> wrote: I am *guessing* the problem here is something like this:

[Python-ideas] Re: Namespace context managers

On Mon, Jul 29, 2019 at 05:58:02PM -0400, Ricky Teachey wrote: > I agree. This is why my preferred solution would be more something like I > proposed, such as: > > def my_namespace: > a = 1 > def f(x): ... This has the advantages of: 1. Avoiding the need to repeat the name twice. 2. Av

[Python-ideas] Re: for ... except, with ... except

On Mon, Jul 29, 2019 at 3:51 PM Eric Fahlgren wrote: > On Mon, Jul 29, 2019 at 2:58 PM Guido van Rossum wrote: > >> I am *guessing* the problem here is something like this: >> >> with open(filename) as f: >> data = f.read() >> >> raises an exception if the open() call fails, but putting try.

[Python-ideas] Re: for ... except, with ... except

On Mon, Jul 29, 2019 at 2:58 PM Guido van Rossum wrote: > I am *guessing* the problem here is something like this: > > with open(filename) as f: > data = f.read() > > raises an exception if the open() call fails, but putting try... except > IOError: ... around the whole thing also catches I/O

[Python-ideas] Re: Namespace context managers

> > This proposal seems to be harking back to the meaning of 'with' in > earlier languages, e.g. Pascal, where it makes the fields of a > structure temporarily accessible without qualification. > > Before we got the current version of 'with' in Python, there were > periodic proposals to add a simil

[Python-ideas] Re: for ... except, with ... except

On Mon, Jul 29, 2019 at 2:36 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > On Jul 29, 2019, at 12:24, Dominik Vilsmeier > wrote: > > > > I could imagine that due to the awkward workaround, especially regarding > `with`, corresponding "self-made" code is either error-prone

[Python-ideas] Re: Namespace context managers

This proposal seems to be harking back to the meaning of 'with' in earlier languages, e.g. Pascal, where it makes the fields of a structure temporarily accessible without qualification. Before we got the current version of 'with' in Python, there were periodic proposals to add a similar kind of '

[Python-ideas] Re: for ... except, with ... except

On Jul 29, 2019, at 12:24, Dominik Vilsmeier wrote: > > I could imagine that due to the awkward workaround, especially regarding > `with`, corresponding "self-made" code is either error-prone or people will > not even try to work around it in the first place. This feature will probably > be am

[Python-ideas] Re: for ... except, with ... except

Sorry, that does not convince me. You're assuming that everybody is a language designer. Many Python users actually have little language design sense, and you shouldn't need to have it in order to be able to use the language. People are productive by learning to recognize and copy patterns, but th

[Python-ideas] Re: for ... except, with ... except

On 07/29/2019 12:24 PM, Dominik Vilsmeier wrote: I think the focus shouldn't be on whether such syntax is possibly confusing or not because a) People will always remember that's *either* one way or the other No, they won't. b) It's actually pretty easy to remember which way it is, by just

[Python-ideas] Re: for ... except, with ... except

I think the focus shouldn't be on whether such syntax is possibly confusing or not because a) People will always remember that's *either* one way or the other, but are very unlikely to just assume one; hence they can always check what it does, and more importantly, b) It's actually pretty easy

[Python-ideas] Fwd: for ... except, with ... except

And another message that was rejected (I sent from an unregistered email address) On Sat, Jul 27, 2019 at 1:49 AM Serhiy Storchaka wrote: > 26.07.19 21:52, Bruce Leban пише: > > > To put this in a simpler way: the proposal is to add an except clause that > applies ONLY to the direct operation o

[Python-ideas] Fwd: for ... except, with ... except

I sent this message earlier but it was rejected by the mailer. On Fri, Jul 26, 2019 at 11:27 AM Serhiy Storchaka wrote: > > So you will be able to add errors handling like in: > > with connect() as stream: > for data in stream: > try: > write(data) >

[Python-ideas] Re: support toml for pyproject support

On Mon, Jul 29, 2019 at 12:57 AM Sardorbek Imomaliev < sardorbek.imomal...@gmail.com> wrote: > Thanks, Brett. You've brought good points. And I wasn't necessarily > advocating about adding TOML support to stdlib, actually it was more about > having a defacto library for TOML parsing. Currently set

[Python-ideas] Re: Skip modules by default in star-import

On Fri, Jul 26, 2019 at 11:51 PM Anders Hovmöller wrote: > > > > On 26 Jul 2019, at 22:53, Guido van Rossum wrote: > > > > Serhiy proposed a relatively minor change to the behavior of `import *` > in the absence of __all__. This sounds like an idea we could try though we > should have a look at

[Python-ideas] Re: Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)

+1 Will implement and circle back around to this list. best, --titus On Mon, Jul 29, 2019 at 08:38:22AM -0700, Guido van Rossum wrote: > I suggest to put this in the devguide and deep-link there from the > python-ideas (and python-dev?) description. The more we have under version > control the b

[Python-ideas] Re: Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)

+1, will circle back around to this list with news. best, —titus > On Jul 29, 2019, at 11:38 AM, Guido van Rossum wrote: > > I suggest to put this in the devguide and deep-link there from the > python-ideas (and python-dev?) description. The more we have under version > control the better. Th

[Python-ideas] Re: Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)

I suggest to put this in the devguide and deep-link there from the python-ideas (and python-dev?) description. The more we have under version control the better. There shouldn't be a need for too much bikeshedding on the first iteration -- just get a simple PR (along the lines of what you wrote) up

[Python-ideas] Re: Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)

Hosting? I suggest Python wiki Abdur-Rahmaan Janhangeer ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archive

[Python-ideas] Re: for ... except, with ... except

On 27/07/2019 09:19, Serhiy Storchaka wrote: 26.07.19 23:57, Guido van Rossum пише: These are interesting ideas. It looks like you intend the except clause of the for loop to *only* cover the iter() and next() calls that are implicit in the for loop. You're right that it's awkward to catch exc

[Python-ideas] Re: Namespace context managers

On 26/07/2019 08:13, Batuhan Taskaya wrote: I am proposing namespace context managers with implementing `__enter__` and `__exit__` on dict objects. Didn't we have this discussion recently? What do these __enter__() and __exit__() do? Please don't answer with an example, I want to understand

[Python-ideas] Re: Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)

On Mon, Jul 29, 2019 at 9:51 PM C. Titus Brown wrote: > I’m responding to this message out of several on this topic, because it > brings up an interesting point - do we have good documents on this process > that are attached to python-ideas and/or core mentoring lists? > Documents? I don't thin

[Python-ideas] Meta question: python-ideas HOWTO (re Re: PEP's shouldn't require a sponsor)

Hi folks, one of the list admins here, my eye was caught by this ongoing discussion. I’m responding to this message out of several on this topic, because it brings up an interesting point - do we have good documents on this process that are attached to python-ideas and/or core mentoring lists?

[Python-ideas] Re: [SPAM?] Re: PEP's shouldn't require a sponsor

On 7/29/19 4:33 AM, Paul Moore wrote: > On Sat, 27 Jul 2019 at 03:51, Kyle Stanley wrote: >> Eric V. Smith wrote: >>> In addition, I find it hard to believe someone couldn't find a sponsor >>> for a well-written PEP. I'm happy to sponsor such a PEP, even if I think >>> it will be rejected. Rejecte

[Python-ideas] Fwd: Re: Universal parsing library in the stdlib to alleviate security issues

Nam Nguyen writes: > Since my final exam was done this weekend, I gathered some more info into > this spreadsheet. > > https://docs.google.com/spreadsheets/d/1TlWSf8iM7eIzEPXanJAP8Ztyzt4ZD28xFvUKeBuQtdA/ This is useful! > Most grammars I have seen here come straight from RFCs, Grammars ar

[Python-ideas] Re: PEP's shouldn't require a sponsor

On Sat, 27 Jul 2019 at 03:51, Kyle Stanley wrote: > > Eric V. Smith wrote: > > In addition, I find it hard to believe someone couldn't find a sponsor > > for a well-written PEP. I'm happy to sponsor such a PEP, even if I think > > it will be rejected. Rejected PEPs serve a useful purpose, too, if

[Python-ideas] Re: support toml for pyproject support

Hi, Adnrew! I agree with you for the most parts. But one thing to note my actual point was not about specifically adding TOML parsing lib to stdlib, but about having some defacto TOML parser under PSF supervision. So it could be used by most users without any additional jumps through hoops if th

[Python-ideas] Re: support toml for pyproject support

Thanks, Brett. You've brought good points. And I wasn't necessarily advocating about adding TOML support to stdlib, actually it was more about having a defacto library for TOML parsing. Currently setuptools, pip and others(now even requests) are under supervision(not total but some) of PSF. I su