On Wed, Apr 24, 2019 at 6:17 AM Mark Shannon wrote:
>
> Hi,
>
> On 12/04/2019 2:44 pm, Inada Naoki wrote:
> > Hi, all.
> >
> > I propose adding new method: dict.with_values(iterable)
>
> You can already do something like this, if memory saving is the main
> concern. This should work on all
Le mer. 24 avr. 2019 à 01:44, Victor Stinner a écrit :
> The current blocker issue is that
> the Py_DEBUG define imply the Py_TRACE_REFS define (...):
>
> https://bugs.python.org/issue36465
> https://github.com/python/cpython/pull/12615
I updated my PR:
"""
Release build and debug build are now
On 24.04.2019 2:44, Victor Stinner wrote:
Hi,
Two weeks ago, I started a thread "No longer enable Py_TRACE_REFS by
default in debug build", but I lost myself in details, I forgot the
main purpose of my proposal...
Let me retry from scratch with a more explicit title: I would like to
be able to
Le mer. 24 avr. 2019 à 01:44, Victor Stinner a écrit :
> The first requirement for the use case is that a Python debug build
> supports the ABI of a release build. (...) I
> propose to no longer imply Py_TRACE_REFS (...)
>
> Apart of Py_TRACE_REFS, I'm not aware of other ABI differences in
>
Hi,
Two weeks ago, I started a thread "No longer enable Py_TRACE_REFS by
default in debug build", but I lost myself in details, I forgot the
main purpose of my proposal...
Let me retry from scratch with a more explicit title: I would like to
be able to run C extensions compiled in release mode
Hi,
On 12/04/2019 2:44 pm, Inada Naoki wrote:
Hi, all.
I propose adding new method: dict.with_values(iterable)
You can already do something like this, if memory saving is the main
concern. This should work on all versions from 3.3.
def shared_keys_dict_maker(keys):
class C: pass
Ok thanks for explaining. I will proceed by trying it with typeshed.
Best Regards,
--
Ilya Kamenshchikov
On Tue, Apr 23, 2019 at 9:44 PM Ivan Levkivskyi
wrote:
> Mypy doesn't use source code of stlib for analysis and instead uses stub
> files from typeshed. IIUC PyCharm can also do that (i.e.
Mypy doesn't use source code of stlib for analysis and instead uses stub
files from typeshed. IIUC PyCharm can also do that (i.e. use the typeshed
stubs).
The whole idea of typeshed is to avoid changing stlib solely for the sake
of static analysis. Please open an issue on typeshed an/or PyCharm
The general solution is
import typing
if typing.TYPE_CHECKING:
The hack of starting with
TYPE_CHECKING = False
happens to work but is not endorsed by PEP 484 so is not guaranteed for the
future.
Note that 3rd party code is rarely in such a critical part for script
startup that the cost
How would we answer the same question if it was not a part of stdlib?
I am not sure it is fair to expect of Pycharm to parse / execute the
__getattr__ on modules, as more elaborate implementation could even contain
different types per some condition at the runtime or anything at all.
The code:
12.04.19 19:17, Inada Naoki пише:
Maybe, collections.DictBuilder may be another option. e.g.
from collections import DictBuilder
builder = DictBuilder(tuple("abc"))
builder.build(range(3))
{"a": 0, "b": 1, "c": 2}
Nitpicking: this is rather a factory than a builder. The difference
between
In any case I think this should be filed (by the OP) as an issue against
JetBrains' PyCharm issue tracker. Who knows they may be able to
special-case this in a jiffy. I don't think we should add any clever hacks
to the stdlib for this.
On Tue, Apr 23, 2019 at 9:59 AM Nathaniel Smith wrote:
> On
On Tue, Apr 23, 2019, 05:09 Andrew Svetlov wrote:
> I agree that `from typing import TYPE_CHECKING` is not desirable from
> the import time reduction perspective.
>
> From my understanding code completion *can* be based on type hinting
> to avoid actual code execution.
> That's why I've
On Wed, Apr 24, 2019 at 12:34 AM Steve Dower wrote:
>
> >> If it's a key-sharing dict, then all the keys are strings. We know that
> >> when we go to do the update, so we can intern all the strings (going to
> >> do that anyway) and then it's a quick check if it already exists. If
> >> it's a
On Wed, Apr 24, 2019 at 12:28 AM Steve Dower wrote:
>
> >
> > But if the original dictionary wasn't created with shared keys... the
> > copy can't share them either. Or are you suggesting adding new code to
> > create a shared key dictionary from one that isn't?
>
> This is a good point. Maybe
On 23Apr2019 0008, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 2:54 PM Steve Dower wrote:
On 22Apr2019 2143, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote:
Or possibly just "dict(existing_dict).update(new_items)".
Do you mean .update accepts values tuple?
I can't
On 23Apr2019 0034, Glenn Linderman wrote:
On 4/22/2019 10:59 PM, Steve Dower wrote:
On 22Apr2019 2119, Glenn Linderman wrote:
While Inada's suggested DictBuilder interface was immediately
obvious, I don't get how either copy or update would achieve the
goal. Perhaps you could explain?
I agree that `from typing import TYPE_CHECKING` is not desirable from
the import time reduction perspective.
>From my understanding code completion *can* be based on type hinting
to avoid actual code execution.
That's why I've mentioned that typeshed already has the correct type
information.
if
On 4/22/2019 10:59 PM, Steve Dower wrote:
On 22Apr2019 2119, Glenn Linderman wrote:
While Inada's suggested DictBuilder interface was immediately
obvious, I don't get how either copy or update would achieve the
goal. Perhaps you could explain? Particularly, what would be the
trigger that
On Tue, Apr 23, 2019 at 2:54 PM Steve Dower wrote:
>
> On 22Apr2019 2143, Inada Naoki wrote:
> > On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote:
> >>
> >> Or possibly just "dict(existing_dict).update(new_items)".
> >>
> >
> > Do you mean .update accepts values tuple?
> > I can't think it's
>
On 22Apr2019 2119, Glenn Linderman wrote:
While Inada's suggested DictBuilder interface was immediately obvious, I
don't get how either copy or update would achieve the goal. Perhaps you
could explain? Particularly, what would be the trigger that would make
dict() choose to create a shared key
On 22Apr2019 2143, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote:
Or possibly just "dict(existing_dict).update(new_items)".
Do you mean .update accepts values tuple?
I can't think it's
Not sure what you were going to go on to say here, but why not?
If it's a
22 matches
Mail list logo
