On 10/29/2019 06:33 AM, mer...@gmx.net wrote:
Anyways, just failing later would not hurt the Python language I think ;)
It would, as Stephen D'Aprano explained.
--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send
I basically agree with many of your points. I have to admit that I am
likely to be biased from my view, since I got hindered by the current
behavior in that scenario. As you correctly stated,
import module
from module import name
assert name is module.name
and
from
On Oct 29, 2019, at 15:05, Richard Vogel wrote:
>
> Nevertheless, could Python cache that spec and cache also a checksum of whats
> coming out after resolveing the loader ?
>
Sure. In addition to sys.modules mapping names to modules you could have a
similar dict mapping specs to modules. It
On Tue, Oct 29, 2019 at 3:37 PM Todd wrote:
> I think you might be mixing up two different things.
>
> First is the text of the Pytjon-2.0 license. I don't want to change that,
> or the text of any other license.
>
> Second is the LICENSE file. That file includes the text of the Python-2.0
>
On Tue, Oct 29, 2019 at 01:26:36PM -, mer...@gmx.net wrote:
> Yes :)
>
> That looks similiar to my problem, which i fixed for the moment of writing by
> renaming one folder.
> Basically, I would prefer if Python would not treat nth-level import fails
> different than first-level fails.
I
I think you might be mixing up two different things.
First is the text of the Pytjon-2.0 license. I don't want to change that,
or the text of any other license.
Second is the LICENSE file. That file includes the text of the Python-2.0
license, the text of every other license used in the
Although I suspect the actual reasoning is just that, because these
are both rare use cases, nobody bothered to design the behavior around
either of them; instead, they just went with the simplest
implementation that handles the non-rare cases as intended, and then
just documented what it does in
On Oct 29, 2019, at 11:45, Richard Vogel wrote:
>> What happens if you break this rule is exactly what you’re seeing. The way
>> Python ensures that doing `import spam` twice results in the same spam
>> module object (so your globals don’t all get duplicated) is by storing
>> modules by
>
> 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 bugs.python.org
> issue with an attached PR implementing (and
Please quote some text from the message you’re replying to, so we know
what you’re referencing. It’s very hard to carry on discussions on a
mailing list if we have to guess which of the four (or, in along
thread, forty) posts you might be talking about. If your mailing makes
it to much of a pain
Thanks for thinking this through a bit more.
I would be wary of changing the Python license -- it's got loads of baggage
and legally I don't know if we can make that stick. Basically I think we
should let leave well enough alone and let sleeping dogs lie. So I am not
keen to add a sentence to the
On 10/29/2019 10:41 AM, Paul Moore wrote:
On Tue, 29 Oct 2019 at 17:38, Ethan Furman wrote:
On 10/29/2019 10:17 AM, Brian Skinn wrote:
I feel like the semantics of PurePath.suffix
(https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.suffix) and
PurePath.stem define this pretty
On Tue, 29 Oct 2019 at 17:38, Ethan Furman wrote:
>
> On 10/29/2019 10:17 AM, Brian Skinn wrote:
>
> > I feel like the semantics of PurePath.suffix
> > (https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.suffix)
> > and PurePath.stem define this pretty unambiguously.
>
> It does
On Tue, 29 Oct 2019 at 17:08, Andrew Barnert wrote:
>
> If you wanted my safe_create function to do Mac-like “copy 3 of
> spam.eggs.txt” instead of Windows-style “spam.eggs (3).txt”, then you would
> end up calling path.with_stem("copy 3 of spam.eggs"), and you would
> definitely want the
> As you say, it's a minor thing (either way) but I've never had the
> need for a `with_stem` method. Do you have a real-life use case (as
> opposed to just wanting it for completeness)?
>
> Having a real example would help decide the appropriate behaviour for
> corner cases like
I feel like the semantics of PurePath.suffix
(https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.suffix) and
PurePath.stem define this pretty unambiguously.
I.e., it should be:
p = Path("foo.bar.txt")
p.with_stem("quux")
"quux.txt"
p.with_stem("baz.quux")
"baz.quux.txt"
On Oct 29, 2019, at 09:05, Paul Moore wrote:
>
> Having a real example would help decide the appropriate behaviour for
> corner cases like x.with_stem('name.ext').
I just realized that my use case doesn’t help answer your corner case.
Hopefully the OP’s will have one. But I can imagine one
On Oct 29, 2019, at 09:05, Paul Moore wrote:
>
> I've never had the
> need for a `with_stem` method. Do you have a real-life use case (as
> opposed to just wanting it for completeness)?
I have a real-life use case, which I’ll simplify here:
def safe_create(path):
try:
return
On Oct 29, 2019, at 06:33, mer...@gmx.net wrote:
>
> On the first scroll in the docs, that doesn't seem to map to the
> namespace-concepts that are known from C++ or PHP, where you explicitly
> define them within the file, right?
The meaning of “namespace” is a place where you can bind values
On Oct 29, 2019, at 07:54, mer...@gmx.net wrote:
>
> I noticed some different (strange) behaviour when handling projects like that.
Please quote some text from the message you’re replying to, so we know what
you’re referencing. It’s very hard to carry on discussions on a mailing list if
we
On Tue, 29 Oct 2019 at 15:29, Ricky Teachey wrote:
>
> There are already .with_suffix() and with_name() methods. Including
> with_stem() seems obvious, no?
As you say, it's a minor thing (either way) but I've never had the
need for a `with_stem` method. Do you have a real-life use case (as
Correction; I intended to use with_suffix() for the second example:
>>> old_path = Path(r"C:\x.txt")
>>> old_path.with_name("y").with_suffix(old_path.suffix)
WindowsPath('C:/y.txt')
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
This is obviously a small thing, but it would be nice to be able to say:
>>> Path(r"C:\x.txt").with_stem("y")
WindowsPath('C:/y.txt')
Rather than having to do some variation of:
>>> old_path = Path(r"C:\x.txt")
>>> old_path.with_name("y"+old_path.suffix)
WindowsPath('C:/y.txt')
Or:
>>>
I noticed some different (strange) behaviour when handling projects like that.
Imagine following folder structure
# project_folder
# a_submodule
* a.py
* b.py
* __init__.py
* main.py
- content a.py:
class Foo:
pass
- content b.py:
from a import Foo
foo = Foo()
content
I am not really a lawyer, so I don't know for certain how to effectively do
this or how fine-grained it has to be. I can float some possibilities, but
someone more knowledgeable would have to assess them.
There is a page on the python website about the license [1]. As far as I
can tell this
Thanks for that hints!
This namespace module concept indeed looks like that is kind of the behaviour
that would like to achieve. I will take a look at that.
On the first scroll in the docs, that doesn't seem to map to the
namespace-concepts that are known from C++ or PHP, where you
Yes :)
That looks similiar to my problem, which i fixed for the moment of writing by
renaming one folder.
Basically, I would prefer if Python would not treat nth-level import fails
different than first-level fails.
Might seem like a small thing, but in my opinion it would:
- keep the
27 matches
Mail list logo
