Le 10/09/2017 à 18:36, Eric V. Smith a écrit :
> On 9/10/2017 10:00 AM, Michel Desmoulin wrote:
>> The reaction is overwhelmingly positive everywhere: hacker news, reddit,
>> twitter.
>
> Do you have a pointer to the Hacker News discussion? I missed it.
Err... I may have been over enthusiastic
On Mon, Sep 11, 2017 at 8:51 AM, Nick Coghlan wrote:
> On 10 September 2017 at 04:04, Nathaniel Smith wrote:
> > On Sep 8, 2017 4:06 PM, "Eric Snow" wrote:
> >
> >
> >run(code):
> >
> > Run the provided Python code in the interpreter, in the current
> > OS thread. If the interp
On 10 September 2017 at 19:42, Skip Montanaro wrote:
> This popped up on python-list. It actually seems to me like it might be
> interesting to the core developers. Apologies if I've missed my guess.
Thanks for passing this along. If it's the document I think it is,
I've reviewed at least one pre
On 10 September 2017 at 04:04, Nathaniel Smith wrote:
> On Sep 8, 2017 4:06 PM, "Eric Snow" wrote:
>
>
>run(code):
>
> Run the provided Python code in the interpreter, in the current
> OS thread. If the interpreter is already running then raise
> RuntimeError in the interpr
On 10 September 2017 at 03:54, Nathaniel Smith wrote:
> On Sep 9, 2017 9:07 AM, "Nick Coghlan" wrote:
>
>
> To immediately realise some level of efficiency benefits from the
> shared memory space between the main interpreter and subinterpreters,
> I also think these low level FIFOs should be defi
On 09/06/2017 02:13 PM, Ronald Oussoren wrote:
To be honest this sounds like a fairly crude hack. Updating the
__class__ of a module object feels dirty, but at least you get normal
behavior w.r.t. properties.
Okay. Obviously I disagree, I think it's reasonable. But I'll assume
you're -1.
On 09/06/2017 08:26 AM, Guido van Rossum wrote:
So we've seen a real use case for __class__ assignment: deprecating
things on access. That use case could also be solved if modules
natively supported defining __getattr__ (with the same "only used if
attribute not found otherwise" semantics as
Hi Eric,
A few quick comments:
Why do you even have a hash= argument on individual fields? For the whole
class, I can imagine you might want to explicitly mark a whole class as
unhashable, but it seems like the only thing you can do with the
field-level hash= argument is to create a class where t
> On Sep 10, 2017, at 4:54 PM, Eric V. Smith wrote:
>
> And now I've pushed a version that works with Python 3.6 to PyPI at
> https://pypi.python.org/pypi/dataclasses
>
> It implements the PEP as it currently stands. I'll be making some tweaks in
> the coming weeks. Feedback is welcomed.
>
>
On Mon, Sep 11, 2017 at 07:39:07AM +1000, Chris Angelico wrote:
[...]
> As a language change, definitely not. But I like this idea for
> PYTHONBREAKPOINT. You set it to the name of a function, or to "pass"
> if you want nothing to be done. It's a special case that can't
> possibly conflict with no
> On Sep 10, 2017, at 5:13 PM, Mike Miller wrote:
>
> Thanks for the info.
>
> On 2017-09-08 15:40, Eric V. Smith wrote:
>>> - Are types required?
>> Annotations are required, the typing module is not.
>>> Maybe an example or two with Any?
>> I'd rather leave it like it is: typing is reference
On Mon, Sep 11, 2017 at 11:03 AM, Barry Warsaw wrote:
> On Sep 10, 2017, at 14:39, Chris Angelico wrote:
>>
>> As a language change, definitely not. But I like this idea for
>> PYTHONBREAKPOINT. You set it to the name of a function, or to "pass"
>> if you want nothing to be done. It's a special c
On Sep 10, 2017, at 14:39, Chris Angelico wrote:
>
> As a language change, definitely not. But I like this idea for
> PYTHONBREAKPOINT. You set it to the name of a function, or to "pass"
> if you want nothing to be done. It's a special case that can't
> possibly conflict with normal usage.
I hav
On 9/8/2017 11:01 AM, Eric V. Smith wrote:
Oops, I forgot the link. It should show up shortly at
https://www.python.org/dev/peps/pep-0557/.
And now I've pushed a version that works with Python 3.6 to PyPI at
https://pypi.python.org/pypi/dataclasses
It implements the PEP as it currently stand
On 2017-09-10 14:23, Ivan Levkivskyi wrote:
This is not the case, static support for dataclasses is an import point of
motivation.
I've needed this functionality a decade before types became cool again. ;-)
It is hard to support static typing for many third party packages like attrs,
since
On Mon, Sep 11, 2017 at 7:29 AM, Koos Zevenhoven wrote:
> On Sun, Sep 10, 2017 at 8:21 PM, Barry Warsaw wrote:
>>
>> On Sep 9, 2017, at 15:12, Guido van Rossum wrote:
>> >
>> > I can't tell whether this was meant seriously, but I don't think it's
>> > worth it. People can easily write their own
On Sun, Sep 10, 2017 at 8:21 PM, Barry Warsaw wrote:
> On Sep 9, 2017, at 15:12, Guido van Rossum wrote:
> >
> > I can't tell whether this was meant seriously, but I don't think it's
> worth it. People can easily write their own dummy function and give it any
> damn semantics they want. Let's re
On 10 September 2017 at 23:05, Mike Miller
wrote:
> [...]
> As the problem this PEP is solving is orthogonal to typing improvements
>
This is not the case, static support for dataclasses is an import point of
motivation.
It is hard to support static typing for many third party packages like
attr
Thanks for the info.
On 2017-09-08 15:40, Eric V. Smith wrote:
- Are types required?
Annotations are required, the typing module is not.
Maybe an example or two with Any?
I'd rather leave it like it is: typing is referenced only once, for ClassVar.
Guess I really meant "object" or "ty
Thanks for the info.
On 2017-09-08 15:40, Eric V. Smith wrote:
- Are types required?
Annotations are required, the typing module is not.
Maybe an example or two with Any?
I'd rather leave it like it is: typing is referenced only once, for ClassVar.
Guess I really meant "object" or "ty
On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote:
> For PEP 553, I think it’s a good idea to support the environment variable
> $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get
> some feedback.
>
> Should $PYTHONBREAKPOINT be consulted in breakpoint() or in
> sys.
I think programmatic overrides should be able to decide for themselves if
they want to honor PYTHONBREAKPOINT or not, since I can imagine use cases
that go both ways. So it should be checked in sys.breakpointhook().
On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote:
> For PEP 553, I think it’
For PEP 553, I think it’s a good idea to support the environment variable
$PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get
some feedback.
Should $PYTHONBREAKPOINT be consulted in breakpoint() or in
sys.breakpointhook()?
If we support it in breakpoint() then it means
On Sun, Sep 10, 2017 at 9:36 AM, Eric V. Smith wrote:
> On 9/10/2017 10:00 AM, Michel Desmoulin wrote:
>
>> - any chance it becomes a built in later ? When classes have been
>> improved in Python 2, the object built-in was added. Imagine if we had
>> had to import it every time... Or maybe just p
On Sep 9, 2017, at 15:12, Guido van Rossum wrote:
>
> I can't tell whether this was meant seriously, but I don't think it's worth
> it. People can easily write their own dummy function and give it any damn
> semantics they want. Let's reject the PEP.
Alrighty then! (Yes, it was serious, but I
On 9/10/2017 10:00 AM, Michel Desmoulin wrote:
The reaction is overwhelmingly positive everywhere: hacker news, reddit,
twitter.
Do you have a pointer to the Hacker News discussion? I missed it.
People have been expecting something like that for a long time.
Me, too!
3 questions:
- is pr
The reaction is overwhelmingly positive everywhere: hacker news, reddit,
twitter.
People have been expecting something like that for a long time.
3 questions:
- is providing validation/conversion hooks completely out of the
question of still open for debate ? I know it's to keep the
implementati
Don't we already have the mock module for that ? A mowk works as a noop,
will be ok with being used as a context manager and allow chaining...
Either way, what would a noop function really give you compared to
lambda *a, **b: None ?
A be bit shorter to write. Maybe faster to run. But do you use i
This popped up on python-list. It actually seems to me like it might be
interesting to the core developers. Apologies if I've missed my guess.
Skip
-- Forwarded message --
From: Stephen Michell
Date: Fri, Sep 8, 2017 at 12:34 PM
Subject: Python programming language vulnerabilitie
29 matches
Mail list logo
