python / peps Goto Github PK

Not really important, but it does unify things.

Currently in PEP7, in C dialect section, it first states "C++ style line comments" is among the selected C99 features but then states "Never use C++ style // one-line comments". I think it's a confliction.

Run python 3.6.0b2

toxa@work:~$ docker run -it python:3.6 python
Python 3.6.0b2 (default, Nov 10 2016, 08:40:01) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> value = 1234
>>> f'input={value:#0.6x}'
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Precision not allowed in integer format specifier
>>>

Example not work.

From https://mail.python.org/pipermail/python-dev/2017-June/148223.html

But the latter example continuation lines are intended at the same level as the following block of code. I propose to make exception for that case and allow moving an open brace to the start of the next line.

I agree with Serhiy; pull request coming momentarily.

PEP 1 needs to be updated to reflect the new GitHub workflow. For example, the following part is now outdated. They can send a pull request on GitHub:

 Updates to existing PEPs also come in to [email protected].  Many PEP
 authors are not Python committers yet, so PEP editors do the commits for them.

Link: https://www.python.org/dev/peps/pep-0506/

The Q and A portion seems to be inconsistently formatted.

Most (all?) PEPs include a public domain dedication at the end, but that's not necessarily a concept that consistently applies across different jurisdictions.

For PEP 531, I've amended that part of the PEP to say:

This document has been placed in the public domain under the terms of the CC0 1.0 license: https://creativecommons.org/publicdomain/zero/1.0/

Perhaps we should make that the default text in the PEP template? (We can leave it up to individual PEP authors if they want to clarify the terms on their old PEPs)

The root directory listing is currently very long, which means that nobody will see github's readme rendering.

The peps sources could be moved into a subdirectory, separated from the scripts used to generate the rendered versions.

As per http://docutils.sourceforge.net/docs/ref/rst/directives.html#note I would expect admonitions such as .. note: to be rendered in a text box, but that doesn't seem to be the case. See https://www.python.org/dev/peps/pep-0339/ and https://www.python.org/dev/peps/pep-0042/ (as soon as that gets regenerated).

I often find myself writing mixed code like the following.

f = open(filename, 'r+b')
f.write(data)
os.pwrite(f.fileno(), data, offset)
f.flush()
os.fsync(f.fileno())

Essentially the problem is that os module provides more methods than the object returned by open(). I propose that we add or change few methods in IOBase and derived classes to have additional methods:

• f.readp(offset, bytecount) implemented as os.pread(f.fileno(), bytecount, offset)
• f.writep(offset, data) implemented as os.pwrite(f.fileno(), data, offset)
• f.sync() implemented as f.flush() + os.fsync(f.fileno())

Alternatively we could modify existing methods with keyword only arguments. I am not entirely inclined to go this way but it is up to debate:

• f.read(size, *, offset=None) calling pread when offset is int
• f.write(data, *, offset=None) calling pwrite when offset is int
• f.flush(sync=False) calling fsync in addition to what it is doing if told so

For binary files, the implementation is abvious and described above. For text files, either raise NotSupported or count in characters instead of bytes. For in-memory classes sync would do nothing.

For proper rendering.

Could be hosted on Read the Docs.

Depends on #2 .

We are going to need this for the cpython repository too. Perhaps we can create python/webhooks to store customizable webhooks like this one..

c28890f should have removed the line "exc = True".
Problem was copy+pasted to https://docs.python.org/3/reference/compound_stmts.html#the-async-with-statement too.

Squashing commits makes for a cleaner git history and avoids having authors' micro-commits preserved forever. (If you really want to see what they were thinking, the closed PR will still be preserved for eternity.) This is a sticky option on the Merge button; we can also make the repo always do squash commits through some config option.

link there is returning 404 https://github.com/python/peps/blob/master/pep-3107.txt#L278

Typography experts agree: Typewriter quotes in non-code text bodies are wrong.^{1, 2}

I gather that PEP editors might not be willing to learn how to input typographically correct quotes.

If this is case, I propose to start using smartypants or similar code to automatically convert typewriter quotes and apostrophes into curly ones. Smartypants works on HTML and skips <code/>, <pre/> and other literal tags.

I would prefer to directly have curly quotes in the rST document, as “direct” is more readable than “escaped”, while explicit is better than implicit (and smartypants could find false positives, although unlikely).

Might make things easier to manage, style, etc.

Hi, my apologies if this has been asked before. But how do I add a linter rule for making sure all files use one newline character? Say, I only want all of my files in the repo to use \n instead of \r\n or \r. Please shed some light. Thanks.

Discussion:

• https://mail.python.org/pipermail/python-dev/2017-May/148084.html
• https://mail.python.org/pipermail/python-dev/2017-June/148101.html

Guido Van Rossum's email:

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
code. We should play it safe.

time=10000
print(f'{time:025_}')
print(f'{time:025_o}')
print(f'{time:025_b}')
print(f'{time:025_x}')

output:
0_000_000_000_000_010_000
0_0000_0000_0000_0002_3420
0_0000_0010_0111_0001_0000
0_0000_0000_0000_0000_2710

focus on the length.

When assigning a function to an instance, the self parameter should not be included.

> python
Python 3.5.2 |Anaconda 4.2.0 (64-bit)| (default, Jul  5 2016, 11:41:13) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class MyClass:
...    pass
...
>>> def my_function(self):
...    pass
...
>>> my_instance = MyClass()
>>> my_instance.my_function = my_function
>>> my_instance.my_function()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: my_function() missing 1 required positional argument: 'self'

I'm not sure if this repo is the right place to discuss proposed peps, so please let me know if there's a better forum.

In PEP 0512, under the Document steps to commit a pull request section, there is a preference described for one commit for each single change. I'm not exactly clear what this means, but I think this might mean that each merged PR should show up as a single commit, no matter how many commits the developer made while developing the PR.

If that is so, would github's facility to squash commits for PR's meet this requirement? https://help.github.com/articles/about-pull-request-merge-squashing/

Attn @brettcannon

Mainly .hgignore and .hgtags.

I have attempted multiple times to discover this information but no one seems to know.

Notes from the linux-sig thread at: https://mail.python.org/pipermail/linux-sig/2017-January/000014.html

• change the sense of the environment variable to be an explicit off-switch for the coercion behaviour (PYTHONCOERCECLOCALE=0) rather than being an on-switch for more permissive behaviour
• add a "--with[out]-c-locale-coercion" configure flag and a related PY_COERCE_C_LOCALE preprocessor definition (for the command line app coercion behaviour)
• add a "--with[out]-c-locale-warning" configure flag and a related PY_WARN_ON_C_LOCALE preprocessor definition (for the runtime library warning behaviour)
• in the command line app, check the result of the C.UTF-8 locale coercion, complain if it doesn't work, and then try the en_US.UTF-8 locale. If that still doesn't work, complain again, then continue with the C locale
• simplify the library warning to:

Python runtime initialized with LC_CTYPE=C (a locale with default ASCII encoding), which may cause Unicode compatibility problems. Using C.UTF-8 as an alternative Unicode-compatible locale is recommended.

I would like to propose a new PEP and have a discussion here. Is that okay? Mailing list is soo uncomfortable.

Provisionally accepted PEPs are currently marked in the PEP repo as simply "Accepted".

This doesn't cause any major problems for CPython, as the only real difference is that the PEP doesn't get marked as Final until the "Provisional" markers get removed from the module documentation.

It's a bit more of an issue for distutils-sig, as our provisionally accepted PEPs may need to be implemented in multiple tools, and the purely informational PEPs may end up going to the Active status rather than to Final the way normal standards track PEPs do.

Having Provisional as a defined state for both Standards Track and Informational PEPs (and updating the PEP 0 listing accordingly) would allow such cases to be handled in a more transparent manner, rather than relying on written notes in the PEP body, or folks having seen the appropriate posts to distutils-sig about it.

Items a PR will need to cover

• Adding relevant text to PEP 1
• Updating pep2html.py to handle the new status (no changes needed)
• Adding a new section to the PEP 0 generator
• Reviewing the currently accepted PEPs and marking the Provisional ones
• Reference https://www.pypa.io/en/latest/specifications/#provisional-acceptance for the meaning of provisional in Discussions-to: distutils-sig PEPs (I now feel PEP 1 shouldn't be aware of this level of detail)
• Reference PEP 411 for the meaning of provisional in other PEPs (I now feel PEP 1 shouldn't be aware of this level of detail)

Another option compared to Read the Docs is GH Pages where Travis uploads the rendered HTML pages. That way there are rendered copies that are available to view almost immediately instead of waiting for python.org/dev/peps/ to have its cron job to trigger or wait until we get the build process on Sphinx so we can host on Read the Docs.

I was reading pep 440 and in particular the "Version specifier section".

The following sentence caught my eye:

The comma (",") is equivalent to a logical and operator: a candidate version must match all given version clauses in order to match the specifier as a whole.

Is there no way to have a "or" ? It seem to me that it might be useful for package that want to express compatibility with 2.6, 2.7 or >3.3 for example, in the form =~2.6 <or operator> =~3.3.

I completely agree that the use case is limited and rare, I was just wondering if I'm missing something, if it was an oversight and if not if adding a section detailing that "or" was not considered, or that "or" was explicitly not included for X,Y,Z reason would be a good thing.

Thanks,

I've seen a couple of project getting pep440 "wrong" because they don't want to include a lot of dependencies just to check version number.

The canonical public version identifiers MUST comply with the following scheme:
[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

Is relatively easy to read. Not so to automatically check, especially if you don't read all the sections with the allowed valued of N, and whether there should be dot. If you get a version number wrong, some things can be annoying (like publishing wheels can have a version number that don't match the sdist, ... ) ...

AFAICT the following regex should check whether a version is canonical, doyou think it would be a good idea to give it as an example in pep 440, in order for developers to "just" copy past it ?

'^([1-9]\d*!)?(0|[1-9]\d*)(.(0|[1-9]\d*))((a|b|rc)(0|[1-9]\d))?(.post(0|[1-9]\d*))?(.dev(0|[1-9]\d*))?$'

PEP 8 says the following:

In Python code, it is permissible to break before or after a binary operator, as long as the convention is consistent locally. For new code Knuth's style is suggested.

However, I don't see how Knuth's style applies to code. Knuth's style distinguishes between formulas within paragraphs and displayed formulas. What is the analogous distinction in a coding context?

how do you get people to see what they can't imagine?

It makes sense for code to have a line length limit, but not for prose:

When editing a document with manual breaks, lines will either be constantly uneven or you will have to manually reflow whole paragraphs all the time, breaking diffs.

I propose to do one sentence per line, and break after commas in long composite sentences. This will be nice for diffs, and result in no useless manual reflowing.

This field, used in PKG-INFO is now in production use despite not being defined in a PEP. Someone should take this up.

I'm talking to our lawyer to find out what the best license is.

The PEP is currently pre-drafted here:
https://github.com/ilevkivskyi/peps/blob/protocols/pep-0544.txt

I'm thinking we should have something like the following for all PRs opened on this repo to make sure people don't skip steps:
"""
Please make sure you have completed this checklist before submitting a pull request:

• Has this idea been proposed on python-ideas and received general acceptance as being an idea worth pursuing? (if not then please start a discussion there before submitting a pull request)
• Has a draft of this PEP been sent to python-ideas for discussion and proofreading? (if not then we recommend you fork this repository, add your PEP, and then send the PEP as plaintext and a link to your fork so people can send you pull requests for your PEP)
• Do you have an implementation of your idea? (this is important for when you propose this PEP to python-dev as code maintenance is a critical aspect of all PEP proposals prior to a final decision; in special circumstances an implementation can be deferred)

If the above have all been met then you may submit a pull request here prior to beginning a discussion on the python-dev mailing list.
"""
Basically I want to avoid people send us PEPs prematurely where we shouldn't be acting as copy editors for ideas that can't make it past python-ideas.

We need to replace irker with GitHub's IRC hook.

The link to https://www.python.org/dev/peps/pep-0547/ leads to a 404 page.

That way people can still pass Travis testing but won't be using a number that might get used before their PEP is accepted into the repo.

So.. it seems like recent commits aren't showing up in python.org 😅

For example:

• the change in #213 is not yet reflected in https://www.python.org/dev/peps/pep-3333/
• PEP 512 is still active https://www.python.org/dev/peps/pep-0512/ , but the status was changed in #212
• Still no mention about trailing comma in PEP 8 https://www.python.org/dev/peps/pep-0008/ (added in #211)

Any ideas of where to look on how to fix this? 🤔
Thanks :)

Given enumerate was added to Python via PEP279 https://www.python.org/dev/peps/pep-0279/ should the older loop counter iteration PEP212 https://www.python.org/dev/peps/pep-0212 which is currently "Deferred" be updated to "Rejected" or "Withdrawn"?

(This is based on my reading of PEP1 https://www.python.org/dev/peps/pep-0001/ on the lifecycle of a PEP)

That way we can make sure there are no errors.

Not sure if there's a way to make warnings into errors, but if there is then we should do that.

https://github.com/python/peps/blob/master/pep-0423.txt

explicitely -> explicitly

create something

From the Abstract in the PEP, the comparison functions are given as:

def __eq__(self, other):
    if other.__class__ is self.__class__:
        return (self.name, self.unit_price, self.quantity_on_hand) == (other.name, other.unit_price, other.quantity_on_hand)
    return NotImplemented

There's been discussion on whether this should be a subclass check, or an exact match. I plan on looking in to this and addressing it before the next PEP version. This is a placeholder to remind me, and for discussion.

Since PEP 515 were implement in 3.6.1, its status should be updated to finished

Requires not only renaming all relevant files but also updating code to accept the file extension. As part of this we can probably consider dropping the Content-Type as it will be known from the file extension (although others may disagree).

This will allow for rich rendering of the reST-based PEPS by GitHub.