[Python-ideas] Re: Suggestion for behaviour change import mechanics

2019-10-30 Thread Andrew Barnert via Python-ideas
On Oct 30, 2019, at 16:17, Brendan Barnwell wrote: > >There's nothing new about that either, though. Any imported module can > already monkeypatch a stdlib module to add such typo-names and map them to > malicious functions. Well, for that attack to work you have to get the user to

[Python-ideas] Re: Suggestion for behaviour change import mechanics

2019-10-30 Thread Steven D'Aprano
On Wed, Oct 30, 2019 at 12:54:13AM +0100, Richard Vogel wrote: > However, I don't see where > > > # Support many different versions of Python, or old versions > > # of the module, or drop-in replacement of the module. > > try: > > from module import name > > except

[Python-ideas] Re: Suggestion for behaviour change import mechanics

2019-10-30 Thread Paul Moore
On Wed, 30 Oct 2019 at 18:45, Brendan Barnwell wrote: > There's nothing new about that either, though. Any imported module > can > already monkeypatch a stdlib module to add such typo-names and map them > to malicious functions. lol, and that's why I'd never make a good security

[Python-ideas] Re: Suggestion for behaviour change import mechanics

2019-10-30 Thread Brendan Barnwell
On 2019-10-30 02:50, Paul Moore wrote: If an attacker can write files in sys.path, they've already won :-) Conceded. Although the normal attack vector is to get someone to import your malicious package. With this change, there's a new attack vector, getting someone to reference an undefined

[Python-ideas] Re: add a .with_stem() method to pathlib objects

2019-10-30 Thread Ricky Teachey
> Seems like the right implementation to me. Does anybody disagree that a >> bug report with a PR is the way to move forward on this? >> > > Depends if you're okay with the PR potentially being rejected because the > idea gets rejected. If you're fine with that then do both, if you're not > then I

[Python-ideas] Re: add a .with_stem() method to pathlib objects

2019-10-30 Thread Brett Cannon
On Tue, Oct 29, 2019 at 12:29 PM Ricky Teachey wrote: > Cool. Sounds like >> >> def with_stem(self, new_stem): >> self.with_name(new_stem + self.suffix) >> >> is the preferred solution. I agree it seems like the right option. >> >> As I said, I don't think it's a big deal either way. A

[Python-ideas] Re: Suggestion for behaviour change import mechanics

2019-10-30 Thread Serhiy Storchaka
30.10.19 00:41, Steven D'Aprano пише: Think about the behaviour of ``from module import name`` in pure Python. Currently, it is straightforward to explain: try to import module, or fail if it doesn't exist; name = module.name, or fail if the name doesn't exist. Things are more

[Python-ideas] Re: Suggestion for behaviour change import mechanics

2019-10-30 Thread Paul Moore
On Wed, 30 Oct 2019 at 08:32, Steven D'Aprano wrote: > > On Wed, Oct 30, 2019 at 08:12:12AM +, Paul Moore wrote: > > > > If you add a module with the same name as a stdlib module to sys.path, > > current semantics are that the stdlib wins. > > I don't think so... shadowing of the stdlib by

[Python-ideas] Re: Suggestion for behaviour change import mechanics

2019-10-30 Thread Steven D'Aprano
On Wed, Oct 30, 2019 at 08:12:12AM +, Paul Moore wrote: > On Tue, 29 Oct 2019 at 22:42, Steven D'Aprano wrote: > > I expect that with a bit more thought I could come up with some more > > scenarios where the behaviour of Python programs could change in very > > surprising ways. > > If you

[Python-ideas] Re: Suggestion for behaviour change import mechanics

2019-10-30 Thread Paul Moore
On Tue, 29 Oct 2019 at 22:42, Steven D'Aprano wrote: > I expect that with a bit more thought I could come up with some more > scenarios where the behaviour of Python programs could change in very > surprising ways. If you add a module with the same name as a stdlib module to sys.path, current