[issue15137] Cleaned source of `cmd` module

2012-06-22 Thread Zearin

New submission from Zearin :

Cleaned up the source of the Standard Library’s `cmd` module.  

Attempted to focus on readability by changing things like using booleans 
instead of 0/1, newer syntax for string formatting, lining up variable 
declarations (judgement call), and adding comments between groups of methods.

Used ace45d23628a to start my work.

--
components: Library (Lib)
files: cmd.py
messages: 163409
nosy: zearin
priority: normal
severity: normal
status: open
title: Cleaned source of `cmd` module
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26082/cmd.py

___
Python tracker 
<http://bugs.python.org/issue15137>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue15137] Cleaned source of `cmd` module

2012-06-22 Thread Zearin

Zearin  added the comment:

Does `hg diff` produce different output than regular `diff`?  

If so, the patch created by regular `diff` is attached.

(I basically did my work without using a local repo, and I have very little 
experience with patching.  I basically just looked up how to create a patch 
with vanilla `diff`.)

--
Added file: http://bugs.python.org/file26083/patch-cmd.txt

___
Python tracker 
<http://bugs.python.org/issue15137>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17074] (docs) Consistent formatting of constants

2013-01-29 Thread Zearin

New submission from Zearin:

When reading the docs, I noticed that the capitalization and formatting of the 
Python constants ``True``, ``False``, and ``None`` were inconsistent.

The attached patch contains a fix for all such occurrences under 
``/Doc/library/``.

(I **think** I correctly made the patch.  I hardly ever make patches, so if I 
screwed up, let me know and I’ll see if I can get it right. ☺)


Parent commit: 
9137e2d1c00c6906af206d1c9d217b15613bb1ed

--
assignee: docs@python
components: Documentation
files: python_docs_constants.diff
keywords: patch
messages: 180918
nosy: docs@python, zearin
priority: normal
severity: normal
status: open
title: (docs) Consistent formatting of constants
versions: Python 2.7
Added file: http://bugs.python.org/file28897/python_docs_constants.diff

___
Python tracker 
<http://bugs.python.org/issue17074>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17074] (docs) Consistent formatting of constants

2013-01-29 Thread Zearin

Changes by Zearin :


--
type:  -> enhancement

___
Python tracker 
<http://bugs.python.org/issue17074>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17074] (docs) Consistent formatting of constants

2013-01-29 Thread Zearin

Zearin added the comment:

Ah; I did look for dupes, but didn’t find it.  (So many issues…!)

Thanks for pointing me in the right direction.

> By the way, you don't always want to replace "true" with ``True``. 

The former has a different connotation/meaning which is boolean true =
rather than the object True.

Yes, I know.  I went through all the occurrences one by one, and I tried to 
take that into account.

*sigh* I guess it’s a moot point, now…



Got more to say on this subject, but I’ll do it in other issue.  Take care!

--

___
Python tracker 
<http://bugs.python.org/issue17074>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue15580] fix True/False/None reST markup

2013-01-29 Thread Zearin

Zearin added the comment:

I recently attempted to enhance the documentation in #17074.  While I wasn’t 
linking all occurrences of True/False/None, I did mark them up as 
``True``/``False``/``None``.  Additionally, I made sure that these were (when 
appropriate) capitalized.

I really disagree with the refusal to accept this issue.  Python is represented 
to the outside world through its documentation. As it is, there are 
inconsistencies in the capitalization and markup of constants.  

CONSTANTS!  

This isn’t exactly a nuanced part of the language.  Constants are dead-easy to 
spot, and they’re dead-easy to fix.  

This issue is **low-hanging fruit**.  

**Consistency** is also one of Python’s core values.  This is built right into 
the language itself --- as indentation-based scope.  The patch by 
chris.jerdonek helps make the documentation more consistent.  

I could understand if this isn’t the type of work you like doing.  If the 
inconsistency was identified, but no one was willing to do the work, **then** 
this might be considered an issue which “cost[...] developer time that can 
better be spent elsewhere.”  

But that’s not the case.  Chris has already done the work.  

It’s low-hanging fruit, it improves Python’s image to the outside world, and it 
noticeably improves the readability (and usability) of the documentation.  

**Please** reconsider accepting this patch.

--
nosy: +zearin

___
Python tracker 
<http://bugs.python.org/issue15580>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4945] json checks True/False by identity, not boolean value

2013-01-29 Thread Zearin

Zearin added the comment:

Note: Javascript has something analogous to Python’s ``==`` and ``is``.  

In JS: 

> 0 == false
true
> 0 === false
false
> 1 == true
true
> 1 === true
false

Perhaps this discrepancy could be fixed in the JSON processing?

--
nosy: +zearin

___
Python tracker 
<http://bugs.python.org/issue4945>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17074] (docs) Consistent formatting of constants

2013-01-29 Thread Zearin

Zearin added the comment:

> By the way, I should have said "something along the same lines."  Issue 15580 
> is about eliminating uses of :const:`None`, etc, whereas this targets a 
> different case.  But it is similar in scope so the same discussion/reasons 
> apply.

Yep!  I read, and understood the difference.  

I still had 2¢ to add.  I’m kind of a nut for good documentation. ;)

--

___
Python tracker 
<http://bugs.python.org/issue17074>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue15580] fix True/False/None reST markup

2013-02-08 Thread Zearin

Zearin added the comment:

I agree that globally linking all occurrences of True/False/None is overkill. 

Perhaps linking the first occurrence per webpage would be a good standard?



However, I *strongly* believe that:

1. The words be capitalized
2. The words should be marked up as ``True``, ``False``, or ``None``

Of course, these two items only apply when appropriate.  But after attempting 
this myself in #17074, I can say with certainty that this is the case *most of 
the time*.

--

___
Python tracker 
<http://bugs.python.org/issue15580>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20393] Docs: mark deprecated items in the TOC

2014-01-25 Thread Zearin

New submission from Zearin:

When exploring the docs for the standard library, it’s frustrating to have an 
idea and look for the answer only to find out that an entire module (or 
package) has been deprecated _after_ I click on it. 

Can we have links to deprecated items on the Standard Library’s TOC page 
flagged?  

I see you’re using multiple CSS classes on some links.  I propose: 

- add a CSS class to flag links to deprecated items
- use something like the following CSS




/*
 * Example 1: color 
 */
.toctree-wrapper a.deprecated {
color: #933;
}

/* 
 * Example 2: "badge" 
 */
.toctree-wrapper a.deprecated:after {
display: inline-block;
content: "deprecated";
margin: 0 1em;
padding: 0 1ex !important;
border-radius:  1ex !important;

font-size: x-small;

background-color: #f66;
color: #933;
}



Of course, since the CSS class '.deprecated' already exists, there's 2 options: 

1. the examples above are rewritten to use a different classname, or 
2. add the following CSS:



/* "Reset" .deprecated in a toctree context */
.toctree-wrapper a.deprecated {
background: none;
border: none;
padding: 0;
}

/* << insert above example CSS here >> */



--
assignee: docs@python
components: Documentation
messages: 209239
nosy: docs@python, zearin
priority: normal
severity: normal
status: open
title: Docs: mark deprecated items in the TOC
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

___
Python tracker 
<http://bugs.python.org/issue20393>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com