On Sun, 10 Apr 2022, 15:53 Guido van Rossum, wrote:
> On Sun, Apr 10, 2022 at 2:31 AM Daniel Pope wrote:
>
>> On Fri, 8 Apr 2022, 17:44 Guido van Rossum, wrote:
>>
>>> The interesting idea here seems to make "lazy imports" easier to
>>> impleme
On Fri, 8 Apr 2022, 17:44 Guido van Rossum, wrote:
> The interesting idea here seems to make "lazy imports" easier to implement
> by making them explicit in the code. So far, most lazy import frameworks
> for Python have done hacks with `__getattribute__` overrides.
>
The value is more than
On Fri, 8 Apr 2022 at 12:23, Steve Dower wrote:
>
> I've read the rest of the thread so far, and agree strongly that we
> can't do this at the language/runtime level.
You mean the hoisting, right?
I don't see any reason why an import expression without hoisting would
be impractical. But I'd
On Fri, 8 Apr 2022 at 11:26, Malthe wrote:
> Perhaps `some_regex = re::compile(r"...")` could work.
>
> That is, :: to delineate the import.
As I mentioned in the Discourse thread, this syntax chimes with Rust
(and C++, and also PHP, triggering fond memories of Paamayim
Nekudotayim).
There are
On Fri, 8 Apr 2022, 09:30 Malthe, wrote:
> For example, `some_regex = @re.compile(...)`.
>
I like the idea of import expressions. I pitched it on Discourse recently:
https://discuss.python.org/t/import-expressions/11582
However, I do not see hoisting as something that should be done by Python.
On Sun, 14 Nov 2021, 19:07 Christopher Barker, wrote:
> On Sun, Nov 14, 2021 at 10:27 AM MRAB wrote:
>
>> Unfortunately, it goes too far, because it's unlikely that we want "ᵖ"
>> ("\N{MODIFIER LETTER SMALL P}') to be equivalent to "P" ("\N{LATIN
>> CAPITAL LETTER P}".
>>
>
> Is it possible to
Serhiy Storchaka wrote:
> From my C++ and Java experience, hashtable-based containers are much
> more useful than tree-based containers. They are more compact and fast.
> In most cases the only reason of using sorted container is supporting
> deterministic iteration order, but often it is enough
On Fri, 8 Oct 2021 at 03:50, Sam Gross wrote:
> My goal with the proof-of-concept is to demonstrate that removing the GIL is
> feasible and worthwhile, and that the technical ideas of the project could
> serve as a basis of such an effort.
I'm a novice C programmer, but I'm unsure about the
As someone who was involved in implementing these, I think they should not
be in builtins if that means they have to be in C.
My argument is from a point of maintainability. Writing them was plenty of
effort in the first place; Josh had written them in idiomatic async Python
in the first place,
