01.06.17 09:36, Benjamin Peterson пише:
Modern GCC can defend against these kinds of problems. If I introduce a
"goto fail" bug somewhere in Python, I get a nice warning:
../Objects/abstract.c: In function ‘PyObject_Type’:
../Objects/abstract.c:35:5: warning: this ‘if’ clause does not guard...
[-
31.05.17 20:27, Guido van Rossum пише:
I interpret the PEP as saying that you should use braces everywhere but
not to add them in code that you're not modifying otherwise. (I.e. don't
go on a brace-adding rampage.) If author and reviewer of a PR disagree I
would go with "add braces" since that'
Modern GCC can defend against these kinds of problems. If I introduce a
"goto fail" bug somewhere in Python, I get a nice warning:
../Objects/abstract.c: In function ‘PyObject_Type’:
../Objects/abstract.c:35:5: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
if (o == NUL
On Wed, May 31, 2017 at 4:00 AM, Serhiy Storchaka
wrote:
> [...] Can pgen be implemented in Python?
>
Yes, an implementation already exists in the stdlib under lib2to3/pgen2/...
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Py
Seems like a good idea to tighten it up.
If a style guide is going to say "you can either do X or
not do X", it might as well not mention X at all. :-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
On Wed, May 31, 2017 at 6:16 AM, Ivan Levkivskyi
wrote:
> On 30 May 2017 at 23:02, Guido van Rossum wrote:
>
>> All in all I'm still leaning towards Naomi's original proposal -- it
>> looks simpler to implement as well.
>>
>
> OK, I think having a bit of verbosity is absolutely fine if we win
>
On Wed, May 31, 2017 at 2:16 AM, Ivan Levkivskyi
wrote:
> On 31 May 2017 at 00:58, Guido van Rossum wrote:
> [...]
>
> Thank you for very detailed answers! I have practically nothing to add.
> It seems to me that most of the Kevin's questions stem from unnecessary
> focus
> on runtime type check
On May 31, 2017, at 02:09 PM, Jim Baker wrote:
>But I object to a completely new feature being added to 2.7 to support the
>implementation of event loop SSL usage. This feature cannot be construed as
>a security fix, and therefore does not qualify as a feature that can be
>added to CPython 2.7 at
So we have two distinct changes that are proposed here:
1. Support alternative implementations of TLS instead of OpenSSL. In
particular this will enable the use of system trust stores for certificates.
2. Implement ABCs and concrete classes to support MemoryBIO, etc., from 3.7.
Supporting system
31.05.17 20:58, Brett Cannon пише:
I assume there's a build rule for Python/graminit.c and porting pgen to
Python would require Python be installed to do a build from scratch.
Have we made that a requirement yet? If so then rewriting pgen in Python
would make it easier to maintain (although whe
On Wed, 31 May 2017 at 04:01 Serhiy Storchaka wrote:
> Currently when you add a new token you need to change a couple of files:
>
> * Include/token.h
> * _PyParser_TokenNames in Parser/tokenizer.c
> * PyToken_OneChar(), PyToken_TwoChars() or PyToken_ThreeChars() in
> Parser/tokenizer.c
> * Lib/to
I interpret the PEP as saying that you should use braces everywhere but not
to add them in code that you're not modifying otherwise. (I.e. don't go on
a brace-adding rampage.) If author and reviewer of a PR disagree I would go
with "add braces" since that's clearly the PEP's preference. This is C
c
2017-05-31 17:45 GMT+02:00 Jim Baker :
> Given that this proposed new feature is for 2.7 to support event loop usage
> and not a security fix, I'm -1 on this change. In particular, it runs
> counter to the justification policy stated in PEP 466.
Hum, it seems like the PEP 546 abstract is incomplet
31.05.17 17:11, Victor Stinner пише:
I have a question on the CPython coding code for C code, the PEP 7:
https://www.python.org/dev/peps/pep-0007/
"""
Code structure: (...); braces are strongly preferred but may be
omitted where C permits, and they should be formatted as shown:
if (mro != NULL)
Jython 2.7.1 is about to be released, with full support of upstream pip
(9.0.1), and corresponding vendored libraries, including requests.
However, this proposed new feature for CPython 2.7, and its usage, will
likely break pip on Jython 2.7.x going forward, given that future versions
of pip will
the 'goto fail' bug is a somewhat extreme reminder for why such braces are
a good idea (as Victor said) -
https://www.imperialviolet.org/2014/02/22/applebug.html
On Wed, May 31, 2017 at 6:25 PM Paul Moore wrote:
> On 31 May 2017 at 15:11, Victor Stinner wrote:
> > So I would suggest to modify t
On 31 May 2017 at 15:11, Victor Stinner wrote:
> So I would suggest to modify the PEP 7 to *always* require braces for if.
>
> I would also suggest to require braces on "for(...) { ... }" and
> "while(...) { ... }". But only if the code has to be modified, not
> only to update the coding style.
>
On May 31, 2017, at 04:13 PM, Victor Stinner wrote:
>Previous discussion which added "strongly preferred" to the PEP 7, January
>2016: https://mail.python.org/pipermail/python-dev/2016-January/142746.html
I had to go back to make sure I wouldn't contradict myself. +1 then, +1
now for requiring b
Previous discussion which added "strongly preferred" to the PEP 7, January 2016:
https://mail.python.org/pipermail/python-dev/2016-January/142746.html
Victor
2017-05-31 16:11 GMT+02:00 Victor Stinner :
> Hi,
>
> I have a question on the CPython coding code for C code, the PEP 7:
> https://www.pyt
Hi,
I have a question on the CPython coding code for C code, the PEP 7:
https://www.python.org/dev/peps/pep-0007/
"""
Code structure: (...); braces are strongly preferred but may be
omitted where C permits, and they should be formatted as shown:
if (mro != NULL) {
...
}
else {
...
}
"""
> On 31 May 2017, at 08:42, Victor Stinner wrote:
>
> Hi,
>
> I wrote a PEP based on the previous thread "Backport ssl.MemoryBIO on
> Python 2.7?". Thanks for Cory Benfield, Alex Gaynor and Nick Coghlan
> who helped me to write it!
It probably goes without saying, given that I helped with the
On 30 May 2017 at 23:02, Guido van Rossum wrote:
>
> All in all I'm still leaning towards Naomi's original proposal -- it looks
> simpler to implement as well.
>
>
OK, I think having a bit of verbosity is absolutely fine if we win
simplicity of implementation (for both static and runtime purposes
Hi,
I'm interested in startup time too, not only execution time.
Here is very rough test:
with open('with_abc.py', 'w') as f:
print("import abc", file=f)
for i in range(1, 1001):
print(f"class A{i}(metaclass=abc.ABCMeta): pass", file=f)
with open('without_abc.py', 'w') as f:
Currently when you add a new token you need to change a couple of files:
* Include/token.h
* _PyParser_TokenNames in Parser/tokenizer.c
* PyToken_OneChar(), PyToken_TwoChars() or PyToken_ThreeChars() in
Parser/tokenizer.c
* Lib/token.py (generated from Include/token.h)
* EXACT_TOKEN_TYPES in Li
On 31 May 2017 at 00:58, Guido van Rossum wrote:
[...]
Thank you for very detailed answers! I have practically nothing to add.
It seems to me that most of the Kevin's questions stem from unnecessary
focus
on runtime type checking. Here are two ideas about how to fix this:
* Add the word "static"
Hi,
I wrote a PEP based on the previous thread "Backport ssl.MemoryBIO on
Python 2.7?". Thanks for Cory Benfield, Alex Gaynor and Nick Coghlan
who helped me to write it!
HTML version:
https://www.python.org/dev/peps/pep-0546/
Inline verison below.
Victor
PEP: 546
Title: Backport ssl.MemoryBIO
26 matches
Mail list logo
