On 10/21/15, Serhiy Storchaka wrote:
> On 21.10.15 04:25, Gregory P. Smith wrote:
>> https://www.python.org/dev/peps/pep-0008/#names-to-avoid
>>
>> /"Since module names are mapped to file names, and some file systems are
>> case insensitive and truncate long names, it is important that module
>> n
It mentions fr'...' as a formatted raw string but doesn't say anything about
rf'...'. Right now, in implementing PEP 498 support in Howl
(https://github.com/howl-editor/howl/pull/118 and
https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346cf586d6#diff-851d9b84896270cc7e3b
Well the whole point is not to have to figure out how to implement that
right now.
On Wed, Oct 21, 2015 at 6:45 PM, Random832 wrote:
> Guido van Rossum writes:
> > The proposal is to allow this to be written as follows in
> > implementation (non-stub) modules:
> >
> > class Foo(Generic[T]):
> >
Guido van Rossum writes:
> The proposal is to allow this to be written as follows in
> implementation (non-stub) modules:
>
> class Foo(Generic[T]):
> @overload
> def __getitem__(self, i: int) -> T: ...
> @overload
> def __getitem__(self, s: slice) -> Foo[T]: ...
> def __getitem__(self, x):
>
>
>
PEP 484 (Type Hinting) currently disallows @overload outside stub files.
The hope was that a PEP for multi-dispatch would emerge, but that's been
slow coming.
Meanwhile, over in https://github.com/ambv/typehinting/issues/72 a proposal
has emerged to allow @overload in regular modules, as long as i
On Wed, Oct 21, 2015 at 10:10:56AM -0700, Ethan Furman wrote:
> On 10/21/2015 08:53 AM, Random832 wrote:
>
> >If a pure python class can cause a reference leak, doesn't that mean it
> >is only a symptom rather than the real cause? Or is it that the use of
> >@object.__new__ is considered "too clev
On 10/21/2015 08:53 AM, Random832 wrote:
If a pure python class can cause a reference leak, doesn't that mean it
is only a symptom rather than the real cause? Or is it that the use of
@object.__new__ is considered "too clever" to be worth fixing?
Where can I find out more about using `object._
On Wed, 21 Oct 2015 at 09:33 Joe Jevnik wrote:
> Sorry about introducing this. Where can I subscribe to these automated
> emails.
>
The emails are sent to the python-checkins mailing list.
> Also, how do I go about running this locally?
>
If you look at the bottom of the email that reports th
Sorry about introducing this. Where can I subscribe to these automated
emails. Also, how do I go about running this locally? On default I tried
running
`./python -m test -l test_capi` did not print anything about leaks. I think
that
using `object.__new__` as a decorator here is the same as subclass
Le 21/10/2015 17:32, Raymond Hettinger a écrit :
>
> Thanks for hunting this down. I had seen the automated reference leak posts
> but didn't suspect that a pure python class would have caused the leak.
Yes, it's a bit baffling at first.
> I'm re-opening
> https://mail.python.org/pipermail/
Raymond Hettinger writes:
> Thanks for hunting this down. I had seen the automated reference leak
> posts but didn't suspect that a pure python class would have caused
> the leak.
>
> I'm re-opening
> https://mail.python.org/pipermail/python-dev/2015-October/141993.html
> and will take a look at
On Wed, Oct 21, 2015 at 9:32 AM, Raymond Hettinger
wrote:
> I'm re-opening
> https://mail.python.org/pipermail/python-dev/2015-October/141993.html
Presumably you meant http://bugs.python.org/issue24379. :)
-eric
___
Python-Dev mailing list
Python-Dev@
> On Oct 20, 2015, at 3:57 PM, Antoine Pitrou wrote:
>
>
>> These leaks have been here a while. Anyone know the cause?
>>
>> On Tue, 20 Oct 2015 at 01:47 wrote:
>>
>>> results for d7e490db8d54 on branch "default"
>>>
>>>
>>> test_capi leaked [541
On 21.10.15 04:25, Gregory P. Smith wrote:
https://www.python.org/dev/peps/pep-0008/#names-to-avoid
/"Since module names are mapped to file names, and some file systems are
case insensitive and truncate long names, it is important that module
names be chosen to be fairly short -- this won't be a
14 matches
Mail list logo
