Re: [Python-Dev] Search-friendly shortcuts for Windows?
On Tue, Dec 21, 2010 at 6:36 PM, "Martin v. Löwis" wrote: >> Given the changing dynamics of the desktop launch menus to better >> support direct access as an alternative to hierarchical navigation, >> would it be reasonable to consider including the major version number >> in the start menu shortcut names? >> >> (Question is mainly for Martin, obviously, but I'm also curious if >> anyone else has encountered the same thing) > > I can't see anything wrong with that, but I'm terrible with wording. > So somebody would have to spell out the exact wording that each of > the start menu items should have. In doing so, also take into > consideration that some people install 32-bit and 64-bit versions > simultaneously. I put my initial proposal (reproduced below) at http://bugs.python.org/issue10747. I'll let this thread run a bit and see if there are any substantial improvements suggested, or valid objections raised (I tried to pre-empt the length issue by pushing the typically least important information to the end). I also considered using the x86 and x64 abbreviations, but being explicit seemed clearer. Shortcuts currently installed: - Python (command line) - Python Manuals - Module Docs - IDLE (Python GUI) - Uninstall Python Initial proposal for 32 bit builds: - Python 3.2 (command line - 32 bit) - Python 3.2 Manuals - Python 3.2 Docs Server (pydoc - 32 bit) - IDLE (Python 3.2 GUI - 32 bit) - Uninstall Python 3.2 (32 bit) Initial proposal for 64 bit builds: - Python 3.2 (command line - 64 bit) - Python 3.2 Manuals - Python 3.2 Docs Server (pydoc - 64 bit) - IDLE (Python 3.2 GUI - 64 bit) - Uninstall Python 3.2 (64 bit) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 21/12/2010 01:57, Nick Coghlan wrote:
On Tue, Dec 21, 2010 at 1:31 AM, Antoine Pitrou wrote:
Diffing is completely an implementation detail of how the failure
messages are generated. The important thing is that failure messages
make sense with respect to actual result and expected result.
Which, again, they don't. Let's see:
self.assertEqual(actual, expected)
AssertionError: 'a\nb\nc\ne\n' != 'a\nb\nc\nd\n'
a
b
c
- e
+ d
The diff shows "expected - actual", but it would be logical (in your own
logic) to display "actual - expected". The whole issue disappears if you
drop this idea of naming the arguments "actual" and "expected".
To make this a bit clearer...
class Ex(ut.TestCase):
... def demo(self):
... self.assertEqual("actual", "expected")
...
Ex("demo").demo()
Traceback (most recent call last):
AssertionError: 'actual' != 'expected'
- actual
+ expected
For the actual/expected terminology the diff is the wrong way around
(as of 3.2b1, anyway).
The recent commit that sparked the controversy was supposed to ensure
that all the asserts were documented consistently *and* worked as per
the documentation. The error above is from assertMultiLineEqual.
assertListEqual has the same issue:
>>> t.assertListEqual([1], [2])
Traceback (most recent call last):
...
AssertionError: Lists differ: [1] != [2]
First differing element 0:
1
2
- [1]
+ [2]
Interestingly assertSetEqual already uses the first/second symmetric
wording:
>>> t.assertSetEqual({1}, {2})
...
AssertionError: Items in the first set but not the second:
1
Items in the second set but not the first:
2
My own +1 goes to keeping the actual/expected terminology (and
ordering) and adjusting the diffs accordingly (with a header noting
that the diff is old=expected, new=actual).
Well we don't have consensus. Whatever we do we need to be consistent,
and in the absence of an agreement about a change we should at least
make all the behaviour and documentation consistent.
From this discussion and the discussion on the issue tracker:
Myself, Nick Coghlan and Ezio Melotti prefer (actual, expected)
Raymond like (actual, expected) but would be happy with symmetrical diffs
Guido prefers the (actual, expected) ordering but prefers diffs to show
the other way round
R David Murray agreed with Guido
Terry Reedy liked the change
Glenn Linderman wants (actual, expected) and diffing to follow that
Ron Adam ditto
Symmetrical diffs (element in first not in second, element in second not
in first) solves the problem without imposing an order on the arguments.
Actually unittest *has* used (first, second) to refer to the arguments
to asserts pretty much since its inception. Losing the (actual,
expected) terminology is a cost of this but unittest hasn't emphasised
this terminology in the past (as I thought it had).
This won't work for diffing strings (assertMultiLineEqual) which use
difflib and needs a direction for the diff. As above it is currently the
wrong way round for (actual, expected).
The other alternative is to make them consistent and follow Nick's
suggestion adding the header note to the diffs that old=expected,
new=actual.
assertRaises() *is* an exception to the general actual/expected
pattern, but that asymmetry is forced by the ability to pass arbitrary
positional arguments to the function being tested (which later proved
useful for the context manager form as well).
The (actual, expected) pattern matches the way almost everyone I've ever
seen write if statements and asserts:
if x == 5: rather than if 5 == x:
assert x == 5 rather than assert 5 == x
It also matches functions like isinstance and issubclass.
On the other hand it doesn't match the way we report TypeErrors where we
report "expected , got ".
All the best,
Michael Foord
Cheers,
Nick.
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.2 beta 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the second beta preview release of Python 3.2. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * PEP 3149, support for version tagged dynamic libraries * PEP 3148, a new futures library for concurrent programming * PEP 384, a stable ABI for extension modules * PEP 391, dictionary-based logging configuration * an overhauled GIL implementation that reduces contention * an extended email package that handles bytes messages * countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables) * many consistency and behavior fixes for numeric operations * a sysconfig module to access configuration information * a pure-Python implementation of the datetime module * additions to the shutil module, among them archive file support * improvements to pdb, the Python debugger For a more extensive list of changes in 3.2, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk0Q/aAACgkQN9GcIYhpnLDf8gCgkLGAsE+T3R505jZc1RxXDYsa NSsAnRGaFjeTm9o2Z5O8FuIzTUG8t1PT =hHzz -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/21/2010 4:17 AM, Michael Foord wrote: Glenn Linderman wants (actual, expected) and diffing to follow that If you say that is what I said, fine. I might not have understood the example well enough to say the right thing. I liked Nick's explanation, using the actual and expected words in his example, but -expected +actual -old +new is what I would expect in the diff. I didn't say anything about the parameters, I don't care, except that the documentation leads me to use it correctly, so that I get the above diff results. Sadly, if the diff results are not as above, I would probably misuse the parameters to achieve it, unless doing something for which the standard is to do it "backwards". ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Tue, Dec 21, 2010 at 4:17 AM, Michael Foord
wrote:
> On 21/12/2010 01:57, Nick Coghlan wrote:
>>
>> On Tue, Dec 21, 2010 at 1:31 AM, Antoine Pitrou
>> wrote:
Diffing is completely an implementation detail of how the failure
messages are generated. The important thing is that failure messages
make sense with respect to actual result and expected result.
>>>
>>> Which, again, they don't. Let's see:
>>>
>>> self.assertEqual(actual, expected)
>>> AssertionError: 'a\nb\nc\ne\n' != 'a\nb\nc\nd\n'
>>> a
>>> b
>>> c
>>> - e
>>> + d
>>>
>>> The diff shows "expected - actual", but it would be logical (in your own
>>> logic) to display "actual - expected". The whole issue disappears if you
>>> drop this idea of naming the arguments "actual" and "expected".
>>
>> To make this a bit clearer...
>>
> class Ex(ut.TestCase):
>>
>> ... def demo(self):
>> ... self.assertEqual("actual", "expected")
>> ...
>
> Ex("demo").demo()
>>
>> Traceback (most recent call last):
>>
>> AssertionError: 'actual' != 'expected'
>> - actual
>> + expected
>>
>> For the actual/expected terminology the diff is the wrong way around
>> (as of 3.2b1, anyway).
>>
>
> The recent commit that sparked the controversy was supposed to ensure that
> all the asserts were documented consistently *and* worked as per the
> documentation. The error above is from assertMultiLineEqual.
>
> assertListEqual has the same issue:
>
t.assertListEqual([1], [2])
> Traceback (most recent call last):
> ...
> AssertionError: Lists differ: [1] != [2]
>
> First differing element 0:
> 1
> 2
>
> - [1]
> + [2]
>
> Interestingly assertSetEqual already uses the first/second symmetric
> wording:
>
t.assertSetEqual({1}, {2})
> ...
> AssertionError: Items in the first set but not the second:
> 1
> Items in the second set but not the first:
> 2
>
>
>> My own +1 goes to keeping the actual/expected terminology (and
>> ordering) and adjusting the diffs accordingly (with a header noting
>> that the diff is old=expected, new=actual).
>>
>
> Well we don't have consensus. Whatever we do we need to be consistent, and
> in the absence of an agreement about a change we should at least make all
> the behaviour and documentation consistent.
>
> From this discussion and the discussion on the issue tracker:
>
> Myself, Nick Coghlan and Ezio Melotti prefer (actual, expected)
> Raymond like (actual, expected) but would be happy with symmetrical diffs
> Guido prefers the (actual, expected) ordering but prefers diffs to show the
> other way round
Actually I said there was no right answer.
I certainly do not want the diff output to treat the second arg as
"old" and the first one as "new" -- that would be just as confusing.
All in all I'd like to get rid of any vestiges of actual and expected;
I think the first/second wording is the best we can come up with it.
> R David Murray agreed with Guido
That's hard to believe since I don't agree with myself. :-)
> Terry Reedy liked the change
> Glenn Linderman wants (actual, expected) and diffing to follow that
> Ron Adam ditto
>
> Symmetrical diffs (element in first not in second, element in second not in
> first) solves the problem without imposing an order on the arguments.
> Actually unittest *has* used (first, second) to refer to the arguments to
> asserts pretty much since its inception. Losing the (actual, expected)
> terminology is a cost of this but unittest hasn't emphasised this
> terminology in the past (as I thought it had).
>
> This won't work for diffing strings (assertMultiLineEqual) which use difflib
> and needs a direction for the diff. As above it is currently the wrong way
> round for (actual, expected).
>
> The other alternative is to make them consistent and follow Nick's
> suggestion adding the header note to the diffs that old=expected,
> new=actual.
>
>> assertRaises() *is* an exception to the general actual/expected
>> pattern, but that asymmetry is forced by the ability to pass arbitrary
>> positional arguments to the function being tested (which later proved
>> useful for the context manager form as well).
>
> The (actual, expected) pattern matches the way almost everyone I've ever
> seen write if statements and asserts:
>
> if x == 5: rather than if 5 == x:
> assert x == 5 rather than assert 5 == x
>
> It also matches functions like isinstance and issubclass.
>
> On the other hand it doesn't match the way we report TypeErrors where we
> report "expected , got ".
>
> All the best,
>
> Michael Foord
>>
>> Cheers,
>> Nick.
>>
>
>
> --
>
> http://www.voidspace.org.uk/
>
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing http://www.sqlite.org/different.html
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.o
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Tue, Dec 21, 2010 at 11:17 PM, Michael Foord wrote: > On 21/12/2010 01:57, Nick Coghlan wrote: >> My own +1 goes to keeping the actual/expected terminology (and >> ordering) and adjusting the diffs accordingly (with a header noting >> that the diff is old=expected, new=actual). >> > > Well we don't have consensus. Whatever we do we need to be consistent, and > in the absence of an agreement about a change we should at least make all > the behaviour and documentation consistent. > > From this discussion and the discussion on the issue tracker: > > Myself, Nick Coghlan and Ezio Melotti prefer (actual, expected) > Raymond like (actual, expected) but would be happy with symmetrical diffs > Guido prefers the (actual, expected) ordering but prefers diffs to show the > other way round > R David Murray agreed with Guido > Terry Reedy liked the change > Glenn Linderman wants (actual, expected) and diffing to follow that > Ron Adam ditto > > Symmetrical diffs (element in first not in second, element in second not in > first) solves the problem without imposing an order on the arguments. > Actually unittest *has* used (first, second) to refer to the arguments to > asserts pretty much since its inception. Losing the (actual, expected) > terminology is a cost of this but unittest hasn't emphasised this > terminology in the past (as I thought it had). I actually agree with Guido that anything we do is going to be suboptimal in some way. Encouraging the actual/expected ordering and updating the diff output so "expected=old" strikes me as least bad, but using the neutral first/second terminology and doing the diffs as "first=old" wouldn't be terrible (although I'm personally -0 on it because it encourages putting the expected value first in order to get the diffs the right way around when an error occurs). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] [RELEASED] Python 3.2 beta 2
On Wed, Dec 22, 2010 at 6:18 AM, Georg Brandl wrote: > Since PEP 3003, the Moratorium on Language Changes, is in effect, there > are no changes in Python's syntax and built-in types in Python 3.2. Minor nit - we actually did tweak a few of the builtin types a bit (mostly the stuff to improve Sequence ABC conformance and to make range objects more list-like) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On Tue, Dec 21, 2010 at 5:12 PM, Nick Coghlan wrote: > I actually agree with Guido that anything we do is going to be > suboptimal in some way. Encouraging the actual/expected ordering and > updating the diff output so "expected=old" strikes me as least bad, > but using the neutral first/second terminology and doing the diffs as > "first=old" wouldn't be terrible (although I'm personally -0 on it > because it encourages putting the expected value first in order to get > the diffs the right way around when an error occurs). There are several problems with the actual/expected terminology. First of all, the arguments are primarily thought of as (and look) positional, not as having names (and there's nothing you can do about this in the docs -- people copy code without reading docs). Furthermore, Java's jUnit puts expected first (and makes this part of the culture/religion), so people coming from there will use that order and be freaked out if you were to swap them. And last, the order of diff arguments (old new) is also ingrained in the culture (which actually matches the expected/actual order in my mind). I think the least bad thing would be to drop any remnants of expected/actual terminology, keep the diffs in the first-second order, and let developers choose whether they put the expected value first or second. Then of course there will still be the examples in the doc (which some people *do* read and copy) -- I suppose we could alternate here to emphasize that we don't have a preferred order. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/21/2010 7:17 AM, Michael Foord wrote: My first priority is that doc and code match. Close second is consistency (hence, ease of learning and use) between various AssertXs. Symmetrical diffs (element in first not in second, element in second not in first) solves the problem without imposing an order on the arguments. Where applicable, I prefer this as unambiguous output headings. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Search-friendly shortcuts for Windows?
On 12/21/2010 7:01 AM, Nick Coghlan wrote: On Tue, Dec 21, 2010 at 6:36 PM, "Martin v. Löwis" wrote: Given the changing dynamics of the desktop launch menus to better support direct access as an alternative to hierarchical navigation, would it be reasonable to consider including the major version number in the start menu shortcut names? (Question is mainly for Martin, obviously, but I'm also curious if anyone else has encountered the same thing) I can't see anything wrong with that, but I'm terrible with wording. So somebody would have to spell out the exact wording that each of the start menu items should have. In doing so, also take into consideration that some people install 32-bit and 64-bit versions simultaneously. I put my initial proposal (reproduced below) at http://bugs.python.org/issue10747. I'll let this thread run a bit and see if there are any substantial improvements suggested, or valid objections raised (I tried to pre-empt the length issue by pushing the typically least important information to the end). I also considered using the x86 and x64 abbreviations, but being explicit seemed clearer. Shortcuts currently installed: - Python (command line) - Python Manuals - Module Docs - IDLE (Python GUI) - Uninstall Python Initial proposal for 32 bit builds: - Python 3.2 (command line - 32 bit) - Python 3.2 Manuals - Python 3.2 Docs Server (pydoc - 32 bit) Python 3.2 PyDoc Server (32 bit) is shorter. But since pydoc.py is has no 'bitness', PyDoc Server (Python 3.2 - 32 bit) is more in line with below - IDLE (Python 3.2 GUI - 32 bit) I think of IDLE as an IDE, not a GUI, but IDLE IDE does not work too well. In any case, it also has no 'bitness'. IDLE GUI (Python 3.2 - 32 bit) -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87433 - python/branches/py3k/Doc/reference/lexical_analysis.rst
On 12/21/2010 8:37 PM, alexander.belopolsky wrote: Author: alexander.belopolsky Date: Wed Dec 22 02:37:36 2010 New Revision: 87433 Log: Both PEP 3131 and the current implementation use NFKC normalization for identifiers. Fixed the documentation to agree. Modified: python/branches/py3k/Doc/reference/lexical_analysis.rst Modified: python/branches/py3k/Doc/reference/lexical_analysis.rst == --- python/branches/py3k/Doc/reference/lexical_analysis.rst (original) +++ python/branches/py3k/Doc/reference/lexical_analysis.rst Wed Dec 22 02:37:36 2010 @@ -309,8 +309,8 @@ * *Nd* - decimal numbers * *Pc* - connector punctuations -All identifiers are converted into the normal form NFC while parsing; comparison -of identifiers is based on NFC. +All identifiers are converted into the normal form NFKC while parsing; comparison +of identifiers is based on NFKC. A non-normative HTML file listing all valid identifier characters for Unicode 4.1 can be found at Has that file been updated for Unicode 6.0? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r87433 - python/branches/py3k/Doc/reference/lexical_analysis.rst
On Tue, Dec 21, 2010 at 9:16 PM, Terry Reedy wrote:
..
>> A non-normative HTML file listing all valid identifier characters for
>> Unicode
>> 4.1 can be found at
>> http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html
>
> Has that file been updated for Unicode 6.0?
Apparently not. In Python 3.2:
>>> '\N{KANNADA SIGN JIHVAMULIYA}'.isidentifier()
True
$ curl -s http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html|
grep JIHVAMULIYA
$
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Search-friendly shortcuts for Windows?
On Wed, Dec 22, 2010 at 1:39 PM, Terry Reedy wrote: > Python 3.2 PyDoc Server (32 bit) > is shorter. But since pydoc.py is has no 'bitness', > > PyDoc Server (Python 3.2 - 32 bit) > is more in line with below > >> - IDLE (Python 3.2 GUI - 32 bit) > > I think of IDLE as an IDE, not a GUI, but IDLE IDE does not work too well. > In any case, it also has no 'bitness'. > > IDLE GUI (Python 3.2 - 32 bit) The IDLE and Pydoc links implicitly launch an interpreter though - that interpreter definitely has a defined pointer size. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Search-friendly shortcuts for Windows?
Microsoft recommendations: Avoid putting a version number in a program name unless that is how users normally refer to your program. Put only program shortcuts on the Start menu. Don't put shortcuts to the following items on the Start menu: - Program uninstallers. Users access uninstallers through the Programs control panel item. - Help files. Users access Help topics directly from your program. http://msdn.microsoft.com/en-us/library/aa511447.aspx I think it's fine for Python to use a version number and to put links to the manual in the Start Menu (since Python doesn't have a Help menu). But the uninstall shortcut should go. I also don't think that "command line" should be used in the title. And why is the .CHM file called "Manuals"? Why the plural? When seeing this title I thought that maybe it's a link to the Doc directory. Most of the .CHM files that I have in my Start Menu are called "abc Documentation", and a couple "abc Users Manual". The help file it's also titled "Python v2.7 documentation" when opened, so maybe it should be renamed to "Python 3.2 Documentation". > Initial proposal for 32 bit builds: > - Python 3.2 (command line - 32 bit) > - Python 3.2 Manuals > - Python 3.2 Docs Server (pydoc - 32 bit) > - IDLE (Python 3.2 GUI - 32 bit) > - Uninstall Python 3.2 (32 bit) > > Initial proposal for 64 bit builds: > - Python 3.2 (command line - 64 bit) > - Python 3.2 Manuals > - Python 3.2 Docs Server (pydoc - 64 bit) > - IDLE (Python 3.2 GUI - 64 bit) > - Uninstall Python 3.2 (64 bit) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Search-friendly shortcuts for Windows?
> I put my initial proposal (reproduced below) at > http://bugs.python.org/issue10747. I'll let this thread run a bit and > see if there are any substantial improvements suggested, or valid > objections raised (I tried to pre-empt the length issue by pushing the > typically least important information to the end). I also considered > using the x86 and x64 abbreviations, but being explicit seemed > clearer. > > In general, definite +1 on the idea of having version numbers in there. A small comment: "command line" doesn't sound too helpful. Wouldn't "interactive shell" (as they do in ActiveState's Python) be better? Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Search-friendly shortcuts for Windows?
On 12/22/2010 1:23 AM, Adal Chiriliuc wrote: Microsoft recommendations: Irrelevant. Avoid putting a version number in a program name unless that is how users normally refer to your program. Version numbers are the point of this issue, because people *do* have multiple version installed. Put only program shortcuts on the Start menu. Don't put shortcuts to the following items on the Start menu: - Program uninstallers. Users access uninstallers through the Programs control panel item. Many programs put them there where they are EASY to access and invoke. Control panel and add/remove programs are absolute slugs when it comes to starting up. - Help files. Users access Help topics directly from your program. Have you ever run the other items? IDLE has its own help. Control panel has no menu, and what help it does have is for its configuration dialog. \ http://msdn.microsoft.com/en-us/library/aa511447.aspx I think it's fine for Python to use a version number and to put links to the manual in the Start Menu (since Python doesn't have a Help menu). But the uninstall shortcut should go. I also don't think that "command line" should be used in the title. And why is the .CHM file called "Manuals"? Why the plural? Because there are several. When seeing this title I thought that maybe it's a link to the Doc directory. Most of the .CHM files that I have in my Start Menu are called "abc Documentation", and a couple "abc Users Manual". The help file it's also titled "Python v2.7 documentation" when opened, so maybe it That is only true of the 2.7 doc. should be renamed to "Python 3.2 Documentation". The 3.2 doc already is, at least on my system. Initial proposal for 32 bit builds: - Python 3.2 (command line - 32 bit) - Python 3.2 Manuals - Python 3.2 Docs Server (pydoc - 32 bit) - IDLE (Python 3.2 GUI - 32 bit) - Uninstall Python 3.2 (32 bit) Initial proposal for 64 bit builds: - Python 3.2 (command line - 64 bit) - Python 3.2 Manuals - Python 3.2 Docs Server (pydoc - 64 bit) - IDLE (Python 3.2 GUI - 64 bit) - Uninstall Python 3.2 (64 bit) -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Search-friendly shortcuts for Windows?
On 12/22/2010 1:21 AM, Nick Coghlan wrote: On Wed, Dec 22, 2010 at 1:39 PM, Terry Reedy wrote: Python 3.2 PyDoc Server (32 bit) is shorter. But since pydoc.py is has no 'bitness', PyDoc Server (Python 3.2 - 32 bit) is more in line with below - IDLE (Python 3.2 GUI - 32 bit) I think of IDLE as an IDE, not a GUI, but IDLE IDE does not work too well. In any case, it also has no 'bitness'. IDLE GUI (Python 3.2 - 32 bit) The IDLE and Pydoc links implicitly launch an interpreter though - that interpreter definitely has a defined pointer size. That is exactly why I left the identity of the interpreter in parens. It is Python3.2 that is 32 or 64 bit, not IDLE or pydocs, so the modifier should be attached to Python 3.2 and not IDLE or pydocs. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
