[Python-Dev] [Crosspost from python-committers] Announcing: signups are open for the 2018 Python Language Summit

2018-04-02 Thread Larry Hastings 


It’s that time again: time to start thinking about the Python Language 
Summit!  The 2018 summit will be held on Wednesday, May 9, from 10am to 
4pm, at the Huntington Convention Center in Cleveland, Ohio, USA.  Your 
befezzled and befuddled hosts Barry and Larry will once more be behind 
the big desk in front.


The summit’s purpose is to disseminate information and spark 
conversation among core Python developers.  It’s our yearly opportunity 
to get together for an in-person discussion, to review interesting 
developments of the previous year and hash out where we’re going next.  
And we have lots to talk about!  3.7 is in beta, and we've all 
collectively started work on 3.8 too.


As before, we’re using Google Forms to collect signups.  Signups are 
open now; the deadline to sign up is Wednesday April 18th, 2018 (AoE).  
Please do us a favor and sign up sooner rather than later.  The signup 
form is simpler this year--I bet most people can be done in less than 
two minutes!


One difference from last year: there are now *two* forms.  The first 
form is for signing up to attend (the "Request For Invitation" form), 
and the second form is for proposing a talk. Please note: if you want to 
present, you still need to fill out the Request For Invitation form 
too.  (Yes, it's more complicated this way, sorry.  But having both on 
the same form kind of enforced a one-to-one mapping, and it's really a 
many-to-many mapping: one person might propose multiple talks, and one 
talk might have multiple presenters.  Overall this should be less 
complicated.)


You can find links to *both* forms on the official Python Language 
Summit 2018 page:

https://us.pycon.org/2018/events/language-summit/


A few notes:

 * There will be lightning talks!  Signups will only be available
   during the Language Summit itself.
 * You don’t need to be registered for PyCon in order to attend the summit!
 * We’ll have badge ribbons for Language Summit participants, which
   we’ll hand out at the summit room in the morning.
 * We're inviting Jake Edge from Linux Weekly News to attend the summit
   and provide press coverage again.  Jake’s done a phenomenal job of
   covering the last few summits, providing valuable information not
   just for summit attendees, but also for the Python community at
   large.  Jake’s coverage goes a long way toward demystifying the
   summit, while remaining respectful of confidential information
   that’s deemed “off the record” ahead of time by participants.


One big final note (please read this!):

   When using Google Forms, you /can/ edit your responses later!  When
   you fill out the form and hit Submit, the submission complete page
   (the one that says "Thanks for playing!") will have a link on it
   labeled "Edit your response". BOOKMARK THIS LINK!  You can use this
   link at /any time/ to edit your response, up to the point that
   signups close on April 18th.  Keep in mind, you'll need to bookmark
   each response independently: once for signing up to attend ("Request
   For Invitation"), and once for each talk proposal you submit. Again,
   /please/ be sure to save this bookmark yourself--we don't know how
   to find the link for you later if you don't save it.


We hope to see you at the summit!


[BL]arry
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE colorizer

2018-04-02 Thread MRAB 

On 2018-04-02 05:43, Guido van Rossum wrote:
My question for you: how on earth did you find this?! Speaking of a 
needle in a haystack. Did you run some kind of analysis program that 
looks for regexprs? (We've received some good reports from someone who 
did that looking for possible DoS attacks.)



The thread was about string prefixes.

Terry Reedy wrote "IDLE's colorizer does its parsing with a giant regex."

I wondered: "How bad could it be?" (It's smaller now that the IGNORECASE 
flag can have a local scope.)


It wasn't hard to find because it was in a file called "colorizer.py" in 
a folder called "idlelib".


On Sun, Apr 1, 2018 at 6:49 PM, MRAB > wrote:


A thread on python-ideas is talking about the prefixes of string
literals, and the regex used in IDLE.

Line 25 of Lib\idlelib\colorizer.py is:

    stringprefix = r"(?i:\br|u|f|fr|rf|b|br|rb)?"

which looks slightly wrong to me.

The \b will apply only to the first choice.

Shouldn't it be more like:

    stringprefix = r"(?:\b(?i:r|u|f|fr|rf|b|br|rb))?"

?



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IDLE colorizer

2018-04-02 Thread Guido van Rossum 
Heh. The good old manual approach. :-) How bad indeed?

>>> from idlelib import colorizer; colorizer.make_pat()
from idlelib import colorizer; colorizer.make_pat()
'\\b(?PFalse|None|True|and|as|assert|break|class|continue|def|del|elif|else|except|finally|for|from|global|if|import|in|is|lambda|nonlocal|not|or|pass|raise|return|try|while|with|yield)\\b|([^.\'\\"#]\\b|^)(?PArithmeticError|AssertionError|AttributeError|BaseException|BlockingIOError|BrokenPipeError|BufferError|BytesWarning|ChildProcessError|ConnectionAbortedError|ConnectionError|ConnectionRefusedError|ConnectionResetError|DeprecationWarning|EOFError|Ellipsis|EnvironmentError|Exception|FileExistsError|FileNotFoundError|FloatingPointError|FutureWarning|GeneratorExit|IOError|ImportError|ImportWarning|IndentationError|IndexError|InterruptedError|IsADirectoryError|KeyError|KeyboardInterrupt|LookupError|MemoryError|ModuleNotFoundError|NameError|NotADirectoryError|NotImplemented|NotImplementedError|OSError|OverflowError|PendingDeprecationWarning|PermissionError|ProcessLookupError|RecursionError|ReferenceError|ResourceWarning|RuntimeError|RuntimeWarning|StopAsyncIteration|StopIteration|SyntaxError|SyntaxWarning|SystemError|SystemExit|TabError|TimeoutError|TypeError|UnboundLocalError|UnicodeDecodeError|UnicodeEncodeError|UnicodeError|UnicodeTranslateError|UnicodeWarning|UserWarning|ValueError|Warning|ZeroDivisionError|abs|all|any|ascii|bin|bool|bytearray|bytes|callable|chr|classmethod|compile|complex|copyright|credits|delattr|dict|dir|divmod|enumerate|eval|exec|exit|filter|float|format|frozenset|getattr|globals|hasattr|hash|help|hex|id|input|int|isinstance|issubclass|iter|len|license|list|locals|map|max|memoryview|min|next|object|oct|open|ord|pow|print|property|quit|range|repr|reversed|round|set|setattr|slice|sorted|staticmethod|str|sum|super|tuple|type|vars|zip)\\b|(?P#[^\\n]*)|(?P(?i:\\br|u|f|fr|rf|b|br|rb)?\'\'\'[^\']*((.|\'(?!\'\'))[^\']*)*(\'\'\')?|(?i:\\br|u|f|fr|rf|b|br|rb)?"""[^"]*((.|"(?!""))[^"]*)*(""")?|(?i:\\br|u|f|fr|rf|b|br|rb)?\'[^\'\\n]*(.[^\'\\n]*)*\'?|(?i:\\br|u|f|fr|rf|b|br|rb)?"[^"\\n]*(.[^"\\n]*)*"?)|(?P\\n)'
>>>

On Mon, Apr 2, 2018 at 11:32 AM, MRAB  wrote:

> On 2018-04-02 05:43, Guido van Rossum wrote:
>
>> My question for you: how on earth did you find this?! Speaking of a
>> needle in a haystack. Did you run some kind of analysis program that looks
>> for regexprs? (We've received some good reports from someone who did that
>> looking for possible DoS attacks.)
>>
>> The thread was about string prefixes.
>
> Terry Reedy wrote "IDLE's colorizer does its parsing with a giant regex."
>
> I wondered: "How bad could it be?" (It's smaller now that the IGNORECASE
> flag can have a local scope.)
>
> It wasn't hard to find because it was in a file called "colorizer.py" in a
> folder called "idlelib".
>
>
> On Sun, Apr 1, 2018 at 6:49 PM, MRAB > [email protected]>> wrote:
>>
>> A thread on python-ideas is talking about the prefixes of string
>> literals, and the regex used in IDLE.
>>
>> Line 25 of Lib\idlelib\colorizer.py is:
>>
>> stringprefix = r"(?i:\br|u|f|fr|rf|b|br|rb)?"
>>
>> which looks slightly wrong to me.
>>
>> The \b will apply only to the first choice.
>>
>> Shouldn't it be more like:
>>
>> stringprefix = r"(?:\b(?i:r|u|f|fr|rf|b|br|rb))?"
>>
>> ?
>>
>>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

2018-04-02 Thread Lukasz Langa 
Pickle protocol version 4.0 was originally defined back in PEP 3154 and shipped 
as part of Python 3.4 back in 2011. Yet it's still not the default. There's a 
number of things that would run faster with it like multiprocessing.

This is too late for 3.7 which is a shame but can we at least bump it for 3.8?

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

2018-04-02 Thread Antoine Pitrou 
On Mon, 2 Apr 2018 13:48:46 -0700
Lukasz Langa  wrote:
> Pickle protocol version 4.0 was originally defined back in PEP 3154 and 
> shipped as part of Python 3.4 back in 2011. Yet it's still not the default.

Because we want pickles produced with the default to be readable by
earlier Python 3 versions.
(the same reason protocol 0 stayed the default throughout the Python 2
lifetime)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

2018-04-02 Thread Christian Heimes 
On 2018-04-02 22:48, Lukasz Langa wrote:
> Pickle protocol version 4.0 was originally defined back in PEP 3154 and 
> shipped as part of Python 3.4 back in 2011. Yet it's still not the default. 
> There's a number of things that would run faster with it like multiprocessing.
> 
> This is too late for 3.7 which is a shame but can we at least bump it for 3.8?

It sounds like a reasonable request. Python 3.4 is out of commission by
then. I'm sure the release manager for 3.8 is going to agree with you,
too. :)

Christian

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

2018-04-02 Thread Gregory P. Smith 
Given that, go ahead and change in master (3.8).

On Mon, Apr 2, 2018 at 3:13 PM Christian Heimes 
wrote:

> On 2018-04-02 22:48, Lukasz Langa wrote:
> > Pickle protocol version 4.0 was originally defined back in PEP 3154 and
> shipped as part of Python 3.4 back in 2011. Yet it's still not the default.
> There's a number of things that would run faster with it like
> multiprocessing.
> >
> > This is too late for 3.7 which is a shame but can we at least bump it
> for 3.8?
>
> It sounds like a reasonable request. Python 3.4 is out of commission by
> then. I'm sure the release manager for 3.8 is going to agree with you,
> too. :)
>
> Christian
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

2018-04-02 Thread Lukasz Langa 

> On Apr 2, 2018, at 2:13 PM, Antoine Pitrou  wrote:
> 
> On Mon, 2 Apr 2018 13:48:46 -0700
> Lukasz Langa  wrote:
>> Pickle protocol version 4.0 was originally defined back in PEP 3154 and 
>> shipped as part of Python 3.4 back in 2011. Yet it's still not the default.
> 
> Because we want pickles produced with the default to be readable by
> earlier Python 3 versions.
> (the same reason protocol 0 stayed the default throughout the Python 2
> lifetime)

Alright, so that means we can easily do this for Python 3.8, right? I mean, 
following Christian's logic, Python 3.3 is already dead, with its final release 
done in February 2016 and support dropped in September 2017 per PEP 398.

I think we need to get past thinking about "Python 2" vs. "Python 3". This 
frame of mind creates space for another mythical release of Python that will 
break all the compatibilities, something we promised not to do. A moving 
backward compatibility window that includes the last release still under 
security fixes seems like a good new framework for this.

What do you think?

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

2018-04-02 Thread Gregory P. Smith 
On Mon, Apr 2, 2018 at 3:57 PM Lukasz Langa  wrote:

>
> > On Apr 2, 2018, at 2:13 PM, Antoine Pitrou  wrote:
> >
> > On Mon, 2 Apr 2018 13:48:46 -0700
> > Lukasz Langa  wrote:
> >> Pickle protocol version 4.0 was originally defined back in PEP 3154 and
> shipped as part of Python 3.4 back in 2011. Yet it's still not the default.
> >
> > Because we want pickles produced with the default to be readable by
> > earlier Python 3 versions.
> > (the same reason protocol 0 stayed the default throughout the Python 2
> > lifetime)
>
> Alright, so that means we can easily do this for Python 3.8, right? I
> mean, following Christian's logic, Python 3.3 is already dead, with its
> final release done in February 2016 and support dropped in September 2017
> per PEP 398.
>
> I think we need to get past thinking about "Python 2" vs. "Python 3". This
> frame of mind creates space for another mythical release of Python that
> will break all the compatibilities, something we promised not to do. A
> moving backward compatibility window that includes the last release still
> under security fixes seems like a good new framework for this.
>
> What do you think?
>

+1 - That puts the words to the reason I suggest just running with the
change for 3.8.  If we had noticed in time I'd've suggested doing it in
3.7, too late and not a huge deal so just wait for 3.8.

Never changing it in the past during 1 and 2.x led a lot of code to always
specify HIGHEST as the protocol because the default was unreasonable.

-gps
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] building extensions as builtins is broken in 3.7

2018-04-02 Thread Pablo Galindo Salgado 
Hi,

I am working on the release blocker https://bugs.python.org/issue32232. I
tried to apply the patch proposed by Matthias Klose and I found that it
works on Unix but it fails to build on Windows (probably because circular
imports). I tried to add some tests but after some work on the problem and
some comments by Ned Deily I am starting to think that the test for this is
basically compiling the whole interpreter with static linking of the
built-ins and run the whole test suite. This has to be done as a new build
target on Travis. I did some experiments with this following:

https://wiki.python.org/moin/BuildStatically

But I run into multiple linking errors. The Travis build hangs forever and
then fails in the best case.

Here is an example of what I am talking:
https://github.com/pablogsal/cpython/pull/1

In this PR you can see the patch and the static linking configured as per
above and the Travis output.

I am happy to work on this as long as someone can tell me what is the
appropriate course of action.

Thank you very much for your time!
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com