Re: [Python-Dev] PEP 557 Data Classes 5th posting

[Eric V. Smith]

On 12/3/2017 9:07 PM, Eric V. Smith wrote:

On 12/3/2017 8:31 PM, Guido van Rossum wrote:
On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith > wrote:


    On 12/3/2017 3:33 PM, Antoine Pitrou wrote:





    Thanks.  I have to ask: why don't "asdict" and "astuple" respect
    PEP 8
    naming?


    I guess it depends if you think the underscore is needed to improve
    readability. "Function names should be lowercase, with words
    separated by underscores as necessary to improve readability."

    I don't feel strongly enough about it to change it, but part of that
    is because I'm burned out on the PEP, so I might not be a good one
    to judge at this point. I guess if I clear my head and I were doing
    it from scratch again I'd make them as_dict and as_tuple, so maybe I
    should brush aside inertia and make the change.


The Python stdlib is incredibly inconsistent where it comes to 
inserting underscores. I think in this case it matches 
`namedtuple._asdict()` and that's good enough for me.


It also matches `attrs.asdict()`, which is what originally inspired it.


After a brief discussion at 
https://github.com/ericvsmith/dataclasses/issues/110, the decision is to 
leave the function names as-is, without underscores, to be consistent 
with namedtuples and attrs.


I'll add a note in the PEP's discussion section.

Eric.

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

[Python-Dev] Accepting PEP 562 -- Module __getattr__ and __dir__

[Guido van Rossum]

Ivan,

Congrats on your PEP. I believe the outstanding issues are now resolved and
I am hereby accepting it.

PS. Sorry, Larry, PEP 549 is rejected. But that happened a while ago.

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

Re: [Python-Dev] PEP 557 Data Classes 5th posting

[Guido van Rossum]

And with this, I'm accepting PEP 557, Data Classes.

Eric, congrats with your efforts in proposing and implementing this PEP and
guiding it through the discussion! It's been great to see this idea come to
fruition. Thanks also to the many people who reviewed drafts or
implementation code, including the very generous authors and maintainers of
"attrs", from which this has taken many ideas.

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

Re: [Python-Dev] PEP 557 Data Classes 5th posting

[Ethan Furman]

On 12/04/2017 09:17 AM, Guido van Rossum wrote:


And with this, I'm accepting PEP 557, Data Classes.


Congratulations, Eric!  Data Classes will be a handy thing to have.  :)

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 562 -- Module __getattr__ and __dir__

[Victor Stinner]

Link for lazy people like me:
https://www.python.org/dev/peps/pep-0562/

I changed the PEP status to fix a typo in the abstract:
https://github.com/python/peps/commit/a87417b22bf15bc4382daeaef6d32886c687ad19

Victor


2017-12-04 17:58 GMT+01:00 Guido van Rossum :
> Ivan,
>
> Congrats on your PEP. I believe the outstanding issues are now resolved and
> I am hereby accepting it.
>
> PS. Sorry, Larry, PEP 549 is rejected. But that happened a while ago.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 557 Data Classes 5th posting

[Eric V. Smith]

Thanks, Guido. And indeed, thanks to everyone else who provided inspiration and 
feedback. I too would like to thank Hynek and the other authors of “attrs”. 

I’ll get the implementation committed in the next day or so. 

--
Eric.

> On Dec 4, 2017, at 12:17 PM, Guido van Rossum  wrote:
> 
> And with this, I'm accepting PEP 557, Data Classes.
> 
> Eric, congrats with your efforts in proposing and implementing this PEP and 
> guiding it through the discussion! It's been great to see this idea come to 
> fruition. Thanks also to the many people who reviewed drafts or 
> implementation code, including the very generous authors and maintainers of 
> "attrs", from which this has taken many ideas.
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

[Guido van Rossum]

Ivan,

Congrats on your PEP. I believe the outstanding issues are now resolved and
I am hereby accepting it.

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

Re: [Python-Dev] Accepting PEP 562 -- Module __getattr__ and __dir__

[Glenn Linderman]

The word "a" is extraneous/confusing-in-grammar in the first line of the 
abstract also. I can't fix it.


On 12/4/2017 9:46 AM, Victor Stinner wrote:

Link for lazy people like me:
https://www.python.org/dev/peps/pep-0562/

I changed the PEP status to fix a typo in the abstract:
https://github.com/python/peps/commit/a87417b22bf15bc4382daeaef6d32886c687ad19

Victor


2017-12-04 17:58 GMT+01:00 Guido van Rossum :

Ivan,

Congrats on your PEP. I believe the outstanding issues are now resolved and
I am hereby accepting it.

PS. Sorry, Larry, PEP 549 is rejected. But that happened a while ago.

--
--Guido van Rossum (python.org/~guido)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com



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

[Python-Dev] 3.7.0a3 still open

[Ned Deily]

Congratulations to the owners of the newly accepted PEPs.  The code cutoff for 
3.7.0 alpha 3 is scheduled for today (along with 3.6.3rc1).  I know at least 
one of the PEPs has code ready to commit.  I will hold off on tagging 3.7.0a3 
for another 6 hours or so.  If you feel your code is adequately reviewed and 
ready to go, go for it; likewise for normal bug fixes and doc changes.  But 
keep in the mind that there is still one more alpha preview release coming 
prior to the beta 1 feature code freeze, so no need to panic.

--
  Ned Deily
  n...@python.org -- []

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

Re: [Python-Dev] Accepting PEP 562 -- Module __getattr__ and __dir__

[Guido van Rossum]

Thanks, I fixed it. Will be live in 15-60 minutes.

On Mon, Dec 4, 2017 at 10:52 AM, Glenn Linderman 
wrote:

> The word "a" is extraneous/confusing-in-grammar in the first line of the
> abstract also. I can't fix it.
>
>
> On 12/4/2017 9:46 AM, Victor Stinner wrote:
>
> Link for lazy people like me:https://www.python.org/dev/peps/pep-0562/
>
> I changed the PEP status to fix a typo in the 
> abstract:https://github.com/python/peps/commit/a87417b22bf15bc4382daeaef6d32886c687ad19
>
> Victor
>
>
> 2017-12-04 17:58 GMT+01:00 Guido van Rossum  
> :
>
> Ivan,
>
> Congrats on your PEP. I believe the outstanding issues are now resolved and
> I am hereby accepting it.
>
> PS. Sorry, Larry, PEP 549 is rejected. But that happened a while ago.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing 
> listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
> ___
> Python-Dev mailing 
> listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev
>
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> 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
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations (Draft 3)

[Guido van Rossum]

Łukasz,

I am hereby accepting your PEP. This will be a great improvement in the
experience of users annotating large complex codebases. Congrats on the
design and implementation and on your shepherding the PEP through the
discussion phase. Also a special thanks to Serhiy for thoroughly reviewing
and contributing to the ast-expr-stringification code.

--Guido

PS. I have some editorial quibbles (mostly suggestions to make the
exposition clearer in a few places) but they don't affect acceptance of the
PEP and I will contact you at a later time with these.


On Tue, Nov 21, 2017 at 4:26 PM, Lukasz Langa  wrote:

> Based on the feedback I gather in early November,
> I'm publishing the third draft for consideration on python-dev.
> I hope you like it!
>
> A nicely formatted rendering is available here:
> https://www.python.org/dev/peps/pep-0563/
>
> The full list of changes between this version and the previous draft
> can be found here:
> https://github.com/ambv/static-annotations/compare/
> python-dev1...python-dev2
>
> - Ł
>
>
>
> PEP: 563
> Title: Postponed Evaluation of Annotations
> Version: $Revision$
> Last-Modified: $Date$
> Author: Łukasz Langa 
> Discussions-To: Python-Dev 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 8-Sep-2017
> Python-Version: 3.7
> Post-History: 1-Nov-2017, 21-Nov-2017
> Resolution:
>
>
> Abstract
> 
>
> PEP 3107 introduced syntax for function annotations, but the semantics
> were deliberately left undefined.  PEP 484 introduced a standard meaning
> to annotations: type hints.  PEP 526 defined variable annotations,
> explicitly tying them with the type hinting use case.
>
> This PEP proposes changing function annotations and variable annotations
> so that they are no longer evaluated at function definition time.
> Instead, they are preserved in ``__annotations__`` in string form.
>
> This change is going to be introduced gradually, starting with a new
> ``__future__`` import in Python 3.7.
>
>
> Rationale and Goals
> ===
>
> PEP 3107 added support for arbitrary annotations on parts of a function
> definition.  Just like default values, annotations are evaluated at
> function definition time.  This creates a number of issues for the type
> hinting use case:
>
> * forward references: when a type hint contains names that have not been
>   defined yet, that definition needs to be expressed as a string
>   literal;
>
> * type hints are executed at module import time, which is not
>   computationally free.
>
> Postponing the evaluation of annotations solves both problems.
>
> Non-goals
> -
>
> Just like in PEP 484 and PEP 526, it should be emphasized that **Python
> will remain a dynamically typed language, and the authors have no desire
> to ever make type hints mandatory, even by convention.**
>
> This PEP is meant to solve the problem of forward references in type
> annotations.  There are still cases outside of annotations where
> forward references will require usage of string literals.  Those are
> listed in a later section of this document.
>
> Annotations without forced evaluation enable opportunities to improve
> the syntax of type hints.  This idea will require its own separate PEP
> and is not discussed further in this document.
>
> Non-typing usage of annotations
> ---
>
> While annotations are still available for arbitrary use besides type
> checking, it is worth mentioning that the design of this PEP, as well
> as its precursors (PEP 484 and PEP 526), is predominantly motivated by
> the type hinting use case.
>
> In Python 3.8 PEP 484 will graduate from provisional status.  Other
> enhancements to the Python programming language like PEP 544, PEP 557,
> or PEP 560, are already being built on this basis as they depend on
> type annotations and the ``typing`` module as defined by PEP 484.
> In fact, the reason PEP 484 is staying provisional in Python 3.7 is to
> enable rapid evolution for another release cycle that some of the
> aforementioned enhancements require.
>
> With this in mind, uses for annotations incompatible with the
> aforementioned PEPs should be considered deprecated.
>
>
> Implementation
> ==
>
> In Python 4.0, function and variable annotations will no longer be
> evaluated at definition time.  Instead, a string form will be preserved
> in the respective ``__annotations__`` dictionary.  Static type checkers
> will see no difference in behavior, whereas tools using annotations at
> runtime will have to perform postponed evaluation.
>
> The string form is obtained from the AST during the compilation step,
> which means that the string form might not preserve the exact formatting
> of the source.  Note: if an annotation was a string literal already, it
> will still be wrapped in a string.
>
> Annotations need to be syntactically valid Python expressions, also when
> passed as literal strings (i.e. ``compile(literal, '', 'eval')``).
> Annotations can only u

Re: [Python-Dev] PEP 557 Data Classes 5th posting

[Raymond Hettinger]

> On Dec 4, 2017, at 9:17 AM, Guido van Rossum  wrote:
> 
> And with this, I'm accepting PEP 557, Data Classes.

Woohoo!  I think everyone was looking forward to this moment.


Raymond



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

Re: [Python-Dev] PEP 557 Data Classes 5th posting

[Ivan Levkivskyi]

Congratulations, Eric! This is a great PEP and I am looking forward to
implement support for it in mypy ;-)

--
Ivan


On 4 December 2017 at 18:17, Guido van Rossum  wrote:

> And with this, I'm accepting PEP 557, Data Classes.
>
> Eric, congrats with your efforts in proposing and implementing this PEP
> and guiding it through the discussion! It's been great to see this idea
> come to fruition. Thanks also to the many people who reviewed drafts or
> implementation code, including the very generous authors and maintainers of
> "attrs", from which this has taken many ideas.
>
> --
> --Guido van Rossum (python.org/~guido)
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 557 Data Classes 5th posting

[Eric V. Smith]

On 12/4/2017 5:19 PM, Ivan Levkivskyi wrote:
Congratulations, Eric! This is a great PEP and I am looking forward to 
implement support for it in mypy ;-)


Thanks for all of your help, Ivan, especially for design decisions that 
help interoperability with mypy. I'm looking forward to mypy support, too!


Eric.

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

Re: [Python-Dev] Accepting PEP 562 -- Module __getattr__ and __dir__

[Ivan Levkivskyi]

Thank you Guido!

And thanks everyone for help, discussions, and ideas (in particular Larry
who started this discussion).
I will submit a PR with implementation soon.

--
Ivan


On 4 December 2017 at 17:58, Guido van Rossum  wrote:

> Ivan,
>
> Congrats on your PEP. I believe the outstanding issues are now resolved
> and I am hereby accepting it.
>
> PS. Sorry, Larry, PEP 549 is rejected. But that happened a while ago.
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

[Ivan Levkivskyi]

Thank you! It looks like we have a bunch of accepted PEPs today.
It is great to see all this! Thanks everyone who participated in
discussions here, on python-ideas and
on typing tracker. Special thanks to Mark who started this discussion.

--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Zero-width matching in regexes

[MRAB]

I've finally come to a conclusion as to what the "correct" behaviour of 
zero-width matches should be: """always return the first match, but 
never a zero-width match that is joined to a previous zero-width match""".


If it's about to return a zero-width match that's joined to a previous 
zero-width match, then backtrack and keep on looking for a match.


Example:

>>> print([m.span() for m in re.finditer(r'|.', 'a')])
[(0, 0), (0, 1), (1, 1)]

re.findall, re.split and re.sub should work accordingly.

If re.finditer finds n matches, then re.split should return a list of 
n+1 strings and re.sub should make n replacements (excepting maxsplit, 
etc.).

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

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations (Draft 3)

[Ivan Levkivskyi]

Congratulations, Łukasz!

--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs: ``.. code:: python`` or ``::`` (syntax highlighting)

[Jeff Allen]

The way this is expressed to docutils is slightly different from the way 
it would be expressed to Sphinx. I expected someone would mention this 
in relation to a possible move to RTD and Sphinx for PEPs and potential 
to have to re-work the ReST. Sorry if this was obvious, and the re-work 
simply too trivial to mention.


Both use pygments, but the directive to Sphinx is ".. code-block:: 
". The "::" shorthand works, meaning to take the language from 
the last ".. highlight:: " directive, or conf.py (usually 
"python"). This may be got from the references [1] vs [2] and [3] in 
Wes' original post, but in addition there's a little section in the 
devguide [6].


In my experience, when browsing a .rst file, GitHub recognises my code 
blocks (Sphinx "code-block::") and it colours Python (and Java) but not 
Python console. It does not use the scheme chosen in conf.py (but nor 
does RTD [7]). There are other limitations. Browsing the devguide source 
[8] there gives a good idea what the GitHub can and cannot represent in 
this view.


[6] https://devguide.python.org/documenting/#showing-code-examples
[7] 
https://docs.readthedocs.io/en/latest/faq.html#i-want-to-use-the-blue-default-sphinx-theme

[8] https://github.com/python/devguide

Jeff Allen

On 03/12/2017 04:49, Wes Turner wrote:

Add pygments for ``.. code::`` directive PEP syntax highlighting #1206
https://github.com/python/pythondotorg/issues/1206

Syntax highlighting is an advantage for writers, editors, and readers.

reStructuredText PEPs are rendered into HTML with docutils. Syntax 
highlighting in Docutils 0.9+ is powered by Pygments. If Pygments is 
not installed, or there is a syntax error, syntax highlighting is 
absent. Docutils renders ``.. code::`` blocks with Python syntax 
highlighting by default. You can specify ``.. code:: python`` or ``.. 
code:: python3``.


- GitHub shows Pygments syntax highlighting
for ``.. code::`` directives for .rst and .restructuredtext documents
- PEPs may eventually be hosted on ReadTheDocs with Sphinx (which 
installs docutils and pygments as install_requires in setup.py).

https://github.com/python/peps/issues/2
https://github.com/python/core-workflow/issues/5

In order to use pygments with pythondotorg-hosted PEPs, a few things 
need to happen:


- [ ] Include ``pygments`` in ``base-requirements.txt``
- [ ] Pick a pygments theme
  - Should we use the sphinx_rtd_theme default for consistency with 
the eventual RTD-hosted PEPs?

- [ ] Include the necessary pygments CSS in the PEPs django template
- [ ] rebuild the PEPs
- Start using code directives in new PEPs
- Manually review existing PEPs after adding code directives

PEPs may use ``.. code::`` blocks instead of ``::`` so that code is 
syntax highlighted.


On Saturday, December 2, 2017, Nick Coghlan > wrote:


On 3 December 2017 at 12:32, Wes Turner > wrote:
> Pending a transition of PEPs to ReadTheDocs (with HTTPS on a
custom domain?
> and redirects?) (is there a gh issue for this task?),

See https://github.com/python/peps/projects/1
 and
https://github.com/python/core-workflow/issues/5


Cheers,
Nick.

--
Nick Coghlan   | ncogh...@gmail.com   |   Brisbane,
Australia



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/ja.py%40farowl.co.uk


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