[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Bernat Gabor]

The only other thing that would make sense is a folder in the current
working directory named ".", not?

On Thu, Jun 3, 2021 at 5:05 PM Larry Hastings  wrote:

>
> On 6/3/21 4:20 AM, Chris Johns wrote:
>
> Might be out of context here, but IMHO "." shouldn't be assumed to be the 
> current directory anyway.
>
> As someone who has ported python to a system where it isn't, these 
> assumptions tend to cause problems.
>
>
> That sounds miserable.  What does "." signify on such a system, if not the
> current directory?
>
>
> */arry*
> ___
> 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/archives/list/python-dev@python.org/message/LVOYZGSOJ3OGDX7OUTDXRQVXZ7YGGPS7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/archives/list/python-dev@python.org/message/DZRKL3Q7JHT2RQ3UW3E724VSPTWPCS4L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In support of PEP 649

[Bernat Gabor]

Hello,

I'm a bit surprised that this topic is brought up just days before the
feature freeze of Python 3.10.  How did tools work until now with from
future import annotations? This feature has been in the language for years
(since 3.7), and I haven't heard until today anyone complaining about this
feature gap. Did everyone just told users not to use lazy evaluation of
type hints until now? Also there's been advertised for at least a year that
next python will make it default 🤔

Thanks,

Bernat

On Thu, Apr 15, 2021, 23:13 Paul Bryan  wrote:

> I've been working on a similar framework, Fondat [1], that shares similar
> objectives as Pydantic and FastAPI, albeit implementing in a different
> manner.
>
> I believe other frameworks will have to "run a gauntlet" (as I already
> have)  to deal with the affects of PEP 563. If anyone on these teams are
> interested in how I've dealt with such issues, please feel free to contact
> me directly.
>
> I also recommend members of these teams monitor and/or participate in the
> typing-sig (and maybe the python-dev) mailing list, as discussions in these
> lists are likely to affect their work in the future.
>
> Paul
>
> [1] https://github.com/fondat/fondat-core
>
>
> On Thu, 2021-04-15 at 17:49 -0400, Paul Ganssle wrote:
>
> I should point out that "accept PEP 649" and "break pydantic" are not the
> only options here. The thing that will break pydantic is the end of PEP
> 563's deprecation period, not a failure to implement PEP 649.
>
> Other viable options include:
>
> - Leave PEP 563 opt-in until we can agree on a solution to the problem.
> - Leave PEP 563 opt-in forever.
> - Deprecate PEP 563 and go back to status quo ante.
>
> I haven't followed this closely enough — if PEP 649 were accepted today,
> would it even be ready for use before the 3.10 code freeze (which is in a
> few weeks)?
>
> Assuming this is a real problem (and based in part on how long it took
> for attrs to get what support it has for PEP 563
> , I wouldn't be
> surprised if PEP 563 is quietly throwing a spanner in the works in several
> other places as well), my vote is to leave PEP 563 opt-in until at least
> 3.11 rather than try to rush through a discussion on and implementation of
> PEP 649.
>
> Best,
> Paul
> On 4/15/21 4:20 PM, Bluenix wrote:
>
> Please accept PEP 649!
>
>
> Python's type hinting has become so much more useful than originally thought, 
> and without this change much of that will be hindered. For example (you 
> already know about Pydantic and FastAPI) 
> [discord.py](https://github.com/Rapptz/discord.py)'s commands system allows 
> you to use typehinting to specify how arguments should be converted. Take the 
> following code:
>
>
> ```py
>
> import discord
>
> from discord.ext import commands
>
>
> bot = commands.Bot(command_prefix='>')
>
>
> @bot.command()
>
> # discord.py reads the typehints and converts the arguments accordingly
>
> async def reply(ctx, member: discord.Member, *, text: str):  # ctx is always 
> passed
>
> await ctx.send(f'{member.mention}! {text}')
>
>
> bot.run('token')
>
> ```
>
>
> I must say, this is extremely ergonomic design! Don't break it :)
>
> ___
>
> 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/archives/list/python-dev@python.org/message/S2O7SE4QZQARAYSCOT7PQUEPNENHDJTQ/
>
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> 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/archives/list/python-dev@python.org/message/GT2HQDH2HOZFSOTA5LHTFL5OV46UPKTB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> 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/archives/list/python-dev@python.org/message/PBGFXPC7D3NFLJSFQBDAQQCW6JCMVCFC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/archives/list/python-dev@python.org/message/7KU4WMWD3U6AFVDFOGVZER4QWZJFPAB4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

[Bernat Gabor]

Hello,

In general, I love the idea and implementation. I'm not in love with the
name though, it makes it sound like it contains all module names
imported/available. We have sys.module already containing all module
imported. So without a deeper knowledge sys.modules_names is very close to
sys.module.keys() or all available modules. Can we name it instead
sys.stdlib_modules_names to clarify that this is standard library only
subset and not all available modules for the interpreter?

Thanks,

On Mon, Jan 25, 2021 at 4:33 PM Victor Stinner  wrote:

> Hi Ivan,
>
> On Mon, Jan 25, 2021 at 4:53 PM Ivan Pozdeev via Python-Dev
>  wrote:
> > Just _names_? There's a recurring error case when a 3rd-party module
> overrides a standard one if it happens to have the same name. If you
> > filter such a module out, you're shooting yourself in the foot...
>
> Overriding stdlib modules has been discussed in the issue.
>
> For example, it was proposed to add an attribute to all stdlib modules
> (__stdlib__=True or __author__ = 'PSF'), and then check if the
> attribute exists or not. The problem is that importing a module to
> check for its attribute cause side effect or fail, and so cannot be
> used for some use cases. For example, it would be a surprising to open
> a web browser window when running isort on a Python code containing
> "import antigravity". Another problem is that third party can also add
> the attribute to pretend that their code is part of the stdlib.
>
> In a previous version of my PR, I added a note about sys.path and
> overriding stdlib modules, but I have been asked to remove it. Feel
> free to propose a PR to add such note if you consider that it's
> related to sys.module_names.
>
> Please read the discussion at https://bugs.python.org/issue42955 and
> https://github.com/python/cpython/pull/24238
>
> Victor
> ___
> 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/archives/list/python-dev@python.org/message/7HMWTGBECAVLINLO3MAEN74YVDHOMZKM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/archives/list/python-dev@python.org/message/GPKQLWO2SMJWHPEDSJZZ27BSGZR7YK4W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: SC 2020 recommendation for PEP 634

[Bernat Gabor]

This opens the door for people voting on A or B depending on if they would
accept or reject the PEP. Is this something we're willing to accept?

On Mon, Dec 7, 2020 at 9:29 PM Ethan Furman via Python-Dev <
python-dev@python.org> wrote:

> On 12/7/20 11:29 AM, Brett Cannon wrote:
>
> > After much deliberation, the 2020 SC will be making a recommendation to
> the 2021 SC to accept PEP 634 (although this was
> > not a unanimous decision).
>
> This seems very odd.  The Steering Council is elected to make decisions,
> but it feels like the current SC is passing the
> buck.  You (the current SC) have spent much time on this, so it seems that
> you are in the best position to make a final
> decision.  If you don't, then the next SC may have to also spend a lot of
> time on the issue as well to be comfortable
> accepting your recommendation -- time that could be better spent on other
> issues.
>
> If you (the current SC) were actually accepting PEP 634, would the vote be
> the same?  Then accept it, and let's all move on.
>
> --
> ~Ethan~
> ___
> 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/archives/list/python-dev@python.org/message/EP7GRKHV7OGRA5S44LIELFMVKILEUS2I/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/archives/list/python-dev@python.org/message/7U466T6NQZGQB2DFA7R67JNGKQK2KDIQ/
Code of Conduct: http://python.org/psf/codeofconduct/