On 16 November 2017 at 18:58, Ethan Furman wrote:
> On 11/16/2017 04:22 AM, Ivan Levkivskyi wrote:
>
>> On 16 November 2017 at 07:56, Nick Coghlan wrote:
>>
>
> Jim also raised an important point that needs clarification at the spec
>>>
>> >> level: given multiple entries in "orig_bases" with __m
On Wed, 15 Nov 2017 at 16:27 Ethan Furman wrote:
> So there are currently two ways to customize a module, with PEP 562
> proposing a third.
>
> The first method involves creating a standard class object, instantiating
> it, and replacing the sys.modules entry with it.
>
> The second way is fairly
On 11/16/2017 04:22 AM, Ivan Levkivskyi wrote:
On 16 November 2017 at 07:56, Nick Coghlan wrote:
Jim also raised an important point that needs clarification at the spec
>> level: given multiple entries in "orig_bases" with __mro_entries__ methods,
>> do all such methods get passed the *same*
On Thu, Nov 16, 2017 at 6:28 PM, brent bejot wrote:
> Hello all,
>
> Noticed that "MRO" is not actually defined in the PEP and it seems like it
> should be. Probably in the Performance section where the abbreviation is
> first used outside of a function name.
>
>
I don't think it will hurt if I
On 11/16/2017 7:39 AM, Barry Warsaw wrote:
On Nov 16, 2017, at 09:47, Yury Selivanov wrote:
Let's keep it simple. I'm big -1 on adding different "debug levels",
they are always confusing.
Oh, this one’s easy.
-X dev == some debugging
-X deve == a little more
-X devel == give
My draft addition to the -X dev doc:
"""
The developer mode is different from the "debug mode" of some modules of the
standard library which enables a lot of debug logs. The developer mode should
only log a warning if a potential bug is detected.
The developer mode has a limited effect. Many modul
Le 16/11/2017 à 17:42, Victor Stinner a écrit :
>
> Running an application in debug mode or "developer mode" was never
> recommanded by anyone.
I don't know. Almost everyone runs Python with __debug__ set to True :-)
Regards
Antoine.
___
Python-Dev
2017-11-16 15:47 GMT+01:00 Yury Selivanov :
> Overall I don't see an issue with enabling asyncio debug mode when
> python is executed with "-X dev".
Cool!
> If the purpose of the flag is to
> make Python super verbose and it will not be recommended to use it in
> production -- then why not.
Runn
Hello all,
Noticed that "MRO" is not actually defined in the PEP and it seems like it
should be. Probably in the Performance section where the abbreviation is
first used outside of a function name.
-Brent
On Thu, Nov 16, 2017 at 7:22 AM, Ivan Levkivskyi
wrote:
> On 16 November 2017 at 07:56,
On Nov 16, 2017, at 09:47, Yury Selivanov wrote:
> Let's keep it simple. I'm big -1 on adding different "debug levels",
> they are always confusing.
Oh, this one’s easy.
-X dev == some debugging
-X deve == a little more
-X devel == give it to me!
-X develo== now you’re talki
On Nov 15, 2017, at 21:57, Victor Stinner wrote:
>
> Since Brett and Nick like the idea and nobody complained against it, I
> implemented the -X dev option:
Cool! What would you think about printing a summary of the settings under the
standard banner when you run the REPL under -X dev? I’d ra
On Nov 16, 2017, at 06:53, Victor Stinner wrote:
> What do you think? Is it ok to include asyncio in the global "developer mode"?
I’m +1 on that, and the performance hit doesn’t bother me for a developer mode.
-Barry
signature.asc
Description: Message signed with OpenPGP
On Thu, Nov 16, 2017 at 7:56 AM, Victor Stinner
wrote:
> 2017-11-16 13:43 GMT+01:00 Antoine Pitrou :
>>> About asyncio debug mode, if it's too expensive to be used to develop
>>> an application, maybe there is an issue with additional checks? Should
>>> we remove some of them to be able to use asy
On Nov 16, 2017, at 15:07, Antoine Pitrou wrote:
> I'm having IPv6 issues on *.python.org. Is anyone having the same
> issues or is it just me? Who should I report this to?
The PSF Infrastructure team is available via email or IRC:
http://psf-salt.readthedocs.io/overview/#the-infrastructure-te
On 16 November 2017 at 22:54, Antoine Pitrou wrote:
>
> Hi Victor,
>
> Thanks for the answer!
>
> Le 16/11/2017 à 13:48, Victor Stinner a écrit :
> >
> > faulthandler has a negligible cost on performance/memory.
> >
> > For -W default, I guess that your question is the cost on emitting a
> > warn
2017-11-16 13:54 GMT+01:00 Antoine Pitrou :
> -Wdefault means -Wonce or -Walways? If the former, I don't expect many
> warnings to be emitted.
It's kind of funny that passing "-W default" changes the "default"
behaviour. "-W default" is documented as:
"Explicitly request the default behavior (
2017-11-16 13:43 GMT+01:00 Antoine Pitrou :
>> About asyncio debug mode, if it's too expensive to be used to develop
>> an application, maybe there is an issue with additional checks? Should
>> we remove some of them to be able to use asyncio debug mode in more
>> cases?
>
> Well, I'm sure some peo
Hi Victor,
Thanks for the answer!
Le 16/11/2017 à 13:48, Victor Stinner a écrit :
>
> faulthandler has a negligible cost on performance/memory.
>
> For -W default, I guess that your question is the cost on emitting a
> warning: overhead when a warning is displayed, and overhead when the
> warn
2017-11-16 13:11 GMT+01:00 Antoine Pitrou :
> Could you measure and perhaps document the expected effect on
> performance and memory consumption?
> (it can be a very rough ballpart estimate)
Currently "python3 -X dev script.py" behaves as "PYTHONMALLOC=debug
python3 -W default -X faulthandler scri
Le 16/11/2017 à 13:38, Victor Stinner a écrit :
> 2017-11-16 13:09 GMT+01:00 Antoine Pitrou :
>>> What do you think? Is it ok to include asyncio in the global "developer
>>> mode"?
>>
>> I'd rather not. Those are two orthogonal things. In particular,
>> asyncio debug mode is quite expensive.
>
2017-11-16 13:09 GMT+01:00 Antoine Pitrou :
>> What do you think? Is it ok to include asyncio in the global "developer
>> mode"?
>
> I'd rather not. Those are two orthogonal things. In particular,
> asyncio debug mode is quite expensive.
Is it really an issue? When you develop an application, t
On 16 November 2017 at 07:56, Nick Coghlan wrote:
> On 16 November 2017 at 04:39, Ivan Levkivskyi
> wrote:
>
>> Nick is exactly right here. Jim, if you want to propose alternative
>> wording, then we could consider it.
>>
>
> Jim also raised an important point that needs clarification at the spe
On Thu, 16 Nov 2017 03:57:49 +0100
Victor Stinner wrote:
> Hi,
>
> Since Brett and Nick like the idea and nobody complained against it, I
> implemented the -X dev option:
> https://bugs.python.org/issue32043
> (Right now, it's a pull request.)
Could you measure and perhaps document the expected
On Thu, 16 Nov 2017 12:53:24 +0100
Victor Stinner wrote:
> Ok, I merged my PR adding -X dev: you can now test in Python 3.7 ;-)
>
> > The list of checks can be extended later. For example, we may enable
> > the debug mode of asyncio: PYTHONASYNCIODEBUG=1.
>
> I opened https://bugs.python.org/
Ok, I merged my PR adding -X dev: you can now test in Python 3.7 ;-)
> The list of checks can be extended later. For example, we may enable
> the debug mode of asyncio: PYTHONASYNCIODEBUG=1.
I opened https://bugs.python.org/issue32047 to propose enable asyncio
debug mode using the Python develope
On 16/11/17 04:53, Guido van Rossum wrote:
[snip]
They then go on to explain that sometimes vulnerabilities can be
exploited, but I object to calling all bugs vulnerabilities -- that's
just using a scary word to get attention for a sleep-inducing document
containing such gems as "Use floa
26 matches
Mail list logo
