On 23/07/2019 21:59, Kristian Klette wrote:
Hi!
During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.
Currently the following works as expected:
```
d = {'a': 1234}
d.keys() == d.keys()
d.items() == d.items()
```
but
23.07.19 23:59, Kristian Klette пише:
During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.
Currently the following works as expected:
```
d = {'a': 1234}
d.keys() == d.keys()
d.items() == d.items()
```
but `d.values(
On 7/23/2019 8:27 PM, Steven D'Aprano wrote:
On Tue, Jul 23, 2019 at 08:59:09PM -, Kristian Klette wrote:
Hi!
During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.
Currently the following works as expected:
```
d
On Tue, Jul 23, 2019 at 08:59:09PM -, Kristian Klette wrote:
> Hi!
>
> During the sprints after EuroPython, I made an attempt at adding support for
> comparing the results from `.values()` of two dicts.
>
> Currently the following works as expected:
>
> ```
> d = {'a': 1234}
>
> d.keys() ==
I find myself in agreement with Inada (https://bugs.python.org/issue12445), in
that comparing the values view between two dictionaries by itself would not be
particularly useful for enough people to warrant implementing the comparison.
In most situations when using the data structure, it is only
On 2019-07-23 21:59, Kristian Klette wrote:
Hi!
During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.
Currently the following works as expected:
```
d = {'a': 1234}
d.keys() == d.keys()
d.items() == d.items()
```
but
Hi!
During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.
Currently the following works as expected:
```
d = {'a': 1234}
d.keys() == d.keys()
d.items() == d.items()
```
but `d.values() == d.values()` does not return th
On Jul 23, 2019, at 12:02, Steve Dower wrote:
>
> Even if the performance impact is zero, commits that span the entire codebase
> for not-very-impactful changes have a negative impact on readability (for
> example, someone will suddenly become responsible for every single module as
> far as so
Steve Dower wrote:
> So I apologise for mentioning that people care about import performance.
> Let's ignore them/that issue for now and worry instead about making sure
> people (including us!) know what the canonical reference for
> public/internal is.
Good point, the discussion about __all__,
On 23Jul2019 1128, Kyle Stanley wrote:
Barry Warsaw wrote:
My package has a C version. If public() were a builtin (which I’ve implemented)
it wouldn’t have that much import time overhead.
Is there a way we could estimate the approximate difference in overhead this
would add using benchmarks?
Barry Warsaw wrote:
> This leads to the second problem, which is that it’s too easy for the __all__
> to get
> out of sync with the module’s contents. Often a function or class is renamed,
> removed, or
> added without the __all__ being updated.
IMO, this seems to be the best part of the @publi
FWIW, I actually like the idea - though not strongly enough to really
campaign for it.
My reasoning is that I think that both the current "consenting adults"
policy and possibly more importantly the fact that we are implicitly
supporting private interfaces by our reluctance to changing them has
ha
On 07/23/2019 10:21 AM, Barry Warsaw wrote:
On Jul 23, 2019, at 09:20, Ethan Furman wrote:
On 07/23/2019 08:44 AM, Steve Dower wrote:
It's trivial, but it adds a runtime overhead that is also trivially avoided by
putting the name in __all__ manually. And once it's public API, we shouldn't be
On Jul 23, 2019, at 09:20, Ethan Furman wrote:
>
> On 07/23/2019 08:44 AM, Steve Dower wrote:
>
>> The @public decorator is basically:
>> def public(fn):
>> __all__.append(fn.__name__)
>> return fn
>> It's trivial, but it adds a runtime overhead that is also trivially avoided
>> by putt
On 07/23/2019 08:44 AM, Steve Dower wrote:
The @public decorator is basically:
def public(fn):
__all__.append(fn.__name__)
return fn
It's trivial, but it adds a runtime overhead that is also trivially avoided by
putting the name in __all__ manually. And once it's public API, we shou
On Jul 23, 2019, at 08:44, Steve Dower wrote:
> The @public decorator is basically:
>
> def public(fn):
>__all__.append(fn.__name__)
>return fn
>
> It's trivial, but it adds a runtime overhead that is also trivially avoided
> by putting the name in __all__ manually. And once it's publi
On 22Jul2019 2051, Kyle Stanley wrote:
Also, is the rule "unless explicitly documented public, all
imports are private even if not prefixed with an underscore" officially stated
anywhere, or is it mostly implied? Personally, I think that it should be explicitly
stated in a public manner if it'
On 23Jul2019 0812, Kacvinsky, Tom wrote:
Tests passed once I used the right Visual Studio Command prompt. I was using
the
x64 Native toolchain command shell. Once I switched to the generic command
shell,
all is well. Thanks for the lick in the right direction, it got me to thinking
that eve
> -Original Message-
> From: Steve Dower
> Sent: Monday, July 22, 2019 11:36 PM
> To: Kacvinsky, Tom ; python-dev@python.org
> Subject: [Python-Dev] Re: Python 3.7.4, Visual Studio versions for building
> modules from source
> This is probably not the best place to ask, though I can
Hi Karl,
Maybe have a look at https://discuss.python.org/c/ideas where you could
open up a discussion about your ideas. It's maybe a easier tool than the
mailing list.
On Tue, Jul 23, 2019 at 2:05 PM Karl Dolenc wrote:
> I have changed my mind. I will not be taking part in these mailing lists
Hi Karl,
Email should not have a latency of "several hours" unless there is
something seriously wrong, perhaps your mail server (your ISP?) is
broken. Or possibly you're still being moderated: we recently changed to
moderating newcomers, in response to a flurry of spam.
As a newcomer to this c
On Tue, 23 Jul 2019 at 04:58, Kyle Stanley wrote:
>
> My primary motivation was to provide more explicit declaration of public vs
> private, not only for the purpose of shifting the responsibility to the
> authors, but also to shift the liability of using private members to the user.
My view is
22 matches
Mail list logo
