Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doc files deleted from repo are not deleted from docs.python.org. #66155

Closed
brandon-rhodes mannequin opened this issue Jul 11, 2014 · 10 comments
Closed

Doc files deleted from repo are not deleted from docs.python.org. #66155

brandon-rhodes mannequin opened this issue Jul 11, 2014 · 10 comments
Labels
docs Documentation in the Doc dir

Comments

@brandon-rhodes
Copy link
Mannequin

brandon-rhodes mannequin commented Jul 11, 2014

BPO 21956
Nosy @stevendaprano, @bitdancer, @JulienPalard

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2022-04-05.09:15:56.714>
created_at = <Date 2014-07-11.13:07:11.946>
labels = ['docs']
title = 'Doc files deleted from repo are not deleted from docs.python.org.'
updated_at = <Date 2022-04-05.09:15:56.711>
user = 'https://bugs.python.org/brandon-rhodes'

bugs.python.org fields:

activity = <Date 2022-04-05.09:15:56.711>
actor = 'mdk'
assignee = 'docs@python'
closed = True
closed_date = <Date 2022-04-05.09:15:56.714>
closer = 'mdk'
components = ['Documentation']
creation = <Date 2014-07-11.13:07:11.946>
creator = 'brandon-rhodes'
dependencies = []
files = []
hgrepos = []
issue_num = 21956
keywords = []
message_count = 10.0
messages = ['222741', '222755', '222758', '222759', '222770', '222778', '222787', '222790', '223043', '416762']
nosy_count = 6.0
nosy_names = ['steven.daprano', 'r.david.murray', 'brandon-rhodes', 'docs@python', 'audreyr', 'mdk']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue21956'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

@brandon-rhodes
Copy link
Mannequin Author

brandon-rhodes mannequin commented Jul 11, 2014

There was an old document in the "howto" folder whose advice was in many cases flat-out wrong, so Raymond Hettinger performed a wonderful public service by deleting it back in 2011:

http://hg.python.org/cpython/rev/80ff78425419

Unfortunately it looks like the process for publishing Python documentation only adds documents, but never deletes them, so a copy of the documentation is still available under the "3.4" document tree:

https://docs.python.org/3.4/howto/doanddont.html

It should be deleted as soon as possible. Because it is presumed that only the most accurate and up-to-date documentation lives under the URL "3.4", people are reading and debating this document's bad advice as though it is official guidance as to how to use the language. (The only hint that something is wrong, alas, is the tiny detail that the top-left of the page says “Python v3.3a0 documentation”).

The advice is currently being debated on Twitter and people are sad that they are supposed to stop using “from foo import bar” in Python.

@brandon-rhodes brandon-rhodes mannequin added the docs Documentation in the Doc dir label Jul 11, 2014
@stevendaprano
Copy link
Member

in many cases flat-out wrong

What advice is "flat-out wrong"? All the advice seems excellent to me:

  • avoid "from spam import *" (with a very few exceptions)
  • be cautious about "from spam import eggs"
  • avoid bare "except" clauses
  • watch out for "time from check to time to use" race conditions
    (e.g. prefer EAFP over LBYL when opening files)
  • don't reinvent the wheel poorly when the std lib already solves
    your problem
  • avoid backslash as line continuation

It should be deleted as soon as possible.

Why delete it rather than fix any (alleged) problems with it?

The advice is currently being debated on Twitter and people
are sad that they are supposed to stop using “from foo import bar”

Debated on Twitter. Why am I not surprised that they've misunderstood it?

The document explains why "from foo import bar" can *sometimes* be harmful. The wording could be improved, and isn't as clear as it should be, but the advice is broadly correct: "from foo import bar" injects the object bar into the current namespace, not the name, which means that if foo rebinds bar, that change will not be seen in the current namespace. If foo never rebinds bar, then there is no problem, but if bar is a *variable* rather than a (pseudo-)constant, you may run into subtle and tricky problems.

-1 on deleting.

If the consensus is to keep it, I'll look at rewording and improving some of the weaker descriptions.

@brandon-rhodes
Copy link
Mannequin Author

brandon-rhodes mannequin commented Jul 11, 2014

The question of whether the document ought to be removed is not at issue here. The document was already deleted, in 2011, by Raymond Hettinger, with the consent of its author. I told that story merely as background.

The issue here is that the Python web site is out of date with the documentation in the Mercurial source repository, which is clear because what is clearly marked as an old 3.3-alpha document is being served out of the /3.4/ directory. This is probably because the documentation “push” script does not remove documents from the site, and can be corrected through a simple "rm" by anyone with access to the server.

@bitdancer
Copy link
Member

The file no longer exists in the 3.5 tree on the server. Since it isn't linked from the 3.4 index, it may be more effort than it is worth to get someone to delete the file from the 3.4 tree on the server. On the other hand, fixing the publication process to delete files is something the doc team should probably tackle (note: it might be a sphinx issue, but as Brandon says is more likely an issue with the script that publishes the pages to the server).

As for revising the howto and re-adding it, that is a separate issue and should be discussed on the original bpo-7391, where the possibility was already raised and got some support.

@bitdancer bitdancer changed the title Deleted document should not appear in 3.4 docs Doc files deleted from repo are not deleted from docs.python.org. Jul 11, 2014
@audreyr
Copy link
Mannequin

audreyr mannequin commented Jul 11, 2014

Since it isn't linked from the 3.4 index, it may be more effort than
it is worth to get someone to delete the file from the 3.4 tree on the
server.

It would be worthwhile to delete or fix it in the 2.7 and 3.4 tree.

It accidentally gets linked, still causing confusion to 2.7 and 3.4 users:
https://twitter.com/audreyr/status/487446878837944320

@BreamoreBoy
Copy link
Mannequin

BreamoreBoy mannequin commented Jul 11, 2014

The docs state 'from module import name1, name2. - This is a “don’t” which is much weaker than the previous “don’t”s but is still something you should not do if you don’t have good reasons to do that.' How does that translate into 'The Python docs say that "from module import name1, name2" is an anti-idiom' ?

@audreyr
Copy link
Mannequin

audreyr mannequin commented Jul 11, 2014

Mark, I and a number of others simply misinterpreted the text in that section.

@brandon-rhodes
Copy link
Mannequin Author

brandon-rhodes mannequin commented Jul 11, 2014

I do not find it unreasonable, on a page of Python idioms, the we would call an example that explicitly says "Don't" in its title an "anti-idiom."

@brandon-rhodes
Copy link
Mannequin Author

brandon-rhodes mannequin commented Jul 14, 2014

Now that I am back at a full keyboard, I see that my previous response
to @breamoreboy about this issue is too short and too cryptic to really
serve as a fair answer to his question. And, with some embarrassment, I
note that my words did not even achieve the dignity of forming an actual
English sentence. Alas for cramped travel laptop keyboards and airport
wi-fi!

Might I be allowed another try? If so, then: @breamoreboy, I think that
your confusion ("How does that translate?") can be blamed squarely on
the document in question. Instead of introducing and maintaining a
consistent terminology, it manages to burden the reader with two
parallel and redundant sets of terms for exactly the same idea.

In short, the document title does not match the document itself.

The title of the document sets forth the terms "Idiom" and "Anti-idiom"
as its subject. But then it completely drops the ball. The terms are
not defined in the document itself. They are not clarified anywhere in
its text. Nor are they even *used* anywhere in its body, with a single
lonely exception buried down somewhere around the middle (second
paragraph under "Exceptions").

Instead, the body uses the simpler phrases "Do", "do not", and "should
not." It is running in its "do not" / "don't" mode when it reaches the
sentence you quote, Mark, about "from...import" statements.

So the answer to your "How does that translate" question is that what
the title promises as "Idioms" and "Anti-idioms" actually come out
verbally in the text as "do" and "don't" instead. When someone jumps
into the middle of the document without context, they see only "do" or
"don't" and are left wondering where the terminology of "idioms" is even
coming from. But it comes directly from the title, as the only possible
mapping between the document's terms and those of its title.

So when the document says:

    from module import name1, name2. - This is a "don’t"...

the careful reader who has noticed and remembered the title will
simultaneously read:

    from module import name1, name2. - This is an anti-idiom...

Which is almost exactly the text of Audrey's tweet.

@JulienPalard
Copy link
Member

This is resolved since python/docsbuild-scripts#28.

It could still happen in very specific conditions, but not for a long time, see:

python/docs-community#41 (comment)

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir
Projects
None yet
Development

No branches or pull requests

3 participants