Re: [Python-Dev] Warnings
Am 07.12.2011 02:23, schrieb Cameron Simpson: > On 30Nov2011 22:10, Raymond Hettinger wrote: > | When updating the documentation, please don't go overboard with warnings. > | The docs need to be worded affirmatively -- say what a tool does and show > how to use it correctly. > | See http://docs.python.org/documenting/style.html#affirmative-tone > > I come to this late, but if we're going after the docs... > > At the above link one finds this text: > > This assures that files are flushed [...] > > It does not. It _ensures_ that files are flushed. The doco style "affirmative > tone" _assures_. The coding practice _ensures_! > > Pedanticly, Oh, come on, surely this doesn't effect the casual reader? Georg ___ Python-Dev mailing list [email protected] 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] cpython (2.7): PDB now will properly escape backslashes in the names of modules it executes.
> I think we have an unwritten rule that test class and method names > should tell something about what they test. (We do have things like > TestWeirdBugs and test_12345, but I don’t think it’s a useful pattern to > follow :) I completely disagree. test_12345 is a very good name for a test case, in particular if it tests the value of a tau constant in the math module. There can't be any more precise documentation of the test purpose. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Best Again
I've just added a news item to the python.org home page noting that Linux Journal readers have voted Python the Best Programming Language for the third year in a row. This is excellent news, though I find it hard to believe that coming up on the outside we see C++. While it demonstrates that Linux Journal readers like object-oriented programming, it shows an uncomfortable tendency towards masochism :) and implies we can't necessarily trust their judgment. ;-) Attempted humor aside, here I am taking the opportunity as PSF chairman to say a big "thank you" to all developers and everyone else who helps to keep putting out releases that gain the kind of popularity that this most recent vote indicates. I know we do it to create a great programming environment, not for popularity, but the Foundation's mission involves encouraging the growth of the international Python community. Please pass this on to other members of your developer community who may not receive this message directly. Seriously, thanks. Having quality releases of a great language really does make it easier to promote Python! regards Steve -- Steve Holden [email protected], Holden Web, LLC http://holdenweb.com/ Python classes (and much more) through the web http://oreillyschool.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PSF-Members] Python Best Again
Hello Steve, congratulations to all of you in the foundation who work hard to make Python the success that it is. Massimo On Dec 7, 2011, at 12:40 PM, Steve Holden wrote: > I've just added a news item to the python.org home page noting that Linux > Journal readers have voted Python the Best Programming Language for the third > year in a row. > > This is excellent news, though I find it hard to believe that coming up on > the outside we see C++. While it demonstrates that Linux Journal readers like > object-oriented programming, it shows an uncomfortable tendency towards > masochism :) and implies we can't necessarily trust their judgment. ;-) > > Attempted humor aside, here I am taking the opportunity as PSF chairman to > say a big "thank you" to all developers and everyone else who helps to keep > putting out releases that gain the kind of popularity that this most recent > vote indicates. I know we do it to create a great programming environment, > not for popularity, but the Foundation's mission involves encouraging the > growth of the international Python community. Please pass this on to other > members of your developer community who may not receive this message directly. > > Seriously, thanks. Having quality releases of a great language really does > make it easier to promote Python! > > regards > Steve > -- > Steve Holden [email protected], Holden Web, LLC http://holdenweb.com/ > Python classes (and much more) through the web http://oreillyschool.com/ > > > > ___ > PSF-Members mailing list > [email protected] > http://mail.python.org/mailman/listinfo/psf-members ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warnings
Georg Brandl wrote: Am 07.12.2011 02:23, schrieb Cameron Simpson: On 30Nov2011 22:10, Raymond Hettinger wrote: | When updating the documentation, please don't go overboard with warnings. | The docs need to be worded affirmatively -- say what a tool does and show how to use it correctly. | See http://docs.python.org/documenting/style.html#affirmative-tone I come to this late, but if we're going after the docs... At the above link one finds this text: This assures that files are flushed [...] It does not. It _ensures_ that files are flushed. The doco style "affirmative tone" _assures_. The coding practice _ensures_! Pedanticly, Oh, come on, surely this doesn't effect the casual reader? No, of course not -- although it might /affect/ said reader by causing him/her to think, "I don't think that word means what you think it means..." ;) Seriously, it's best to use the correct words with the correct meanings. If someone is willing to fix it, let them. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warnings
On Wed, Dec 7, 2011 at 11:00 AM, Ethan Furman wrote: > > No, of course not -- although it might /affect/ said reader by causing > him/her to think, "I don't think that word means what you think it means..." > ;) > > Seriously, it's best to use the correct words with the correct meanings. If > someone is willing to fix it, let them. I'm sure this hypothetical reader will then look "assure" up in the OED and find this: 5. To make certain the occurrence or arrival of (an event); to ensure. -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warnings
Georg Brandl writes: > Am 07.12.2011 02:23, schrieb Cameron Simpson: > > This assures that files are flushed [...] > > > > It does not. It _ensures_ that files are flushed. The doco style > > "affirmative tone" _assures_. The coding practice _ensures_! > > Oh, come on, surely this doesn't effect the casual reader? Some readers could of been confused irregardless. -- \ “We must find our way to a time when faith, without evidence, | `\disgraces anyone who would claim it.” —Sam Harris, _The End of | _o__) Faith_, 2004 | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2011 01:22 PM, Georg Brandl wrote: > Am 07.12.2011 02:23, schrieb Cameron Simpson: >> On 30Nov2011 22:10, Raymond Hettinger >> wrote: | When updating the documentation, please don't go overboard >> with warnings. | The docs need to be worded affirmatively -- say >> what a tool does and show how to use it correctly. | See >> http://docs.python.org/documenting/style.html#affirmative-tone >> >> I come to this late, but if we're going after the docs... >> >> At the above link one finds this text: >> >> This assures that files are flushed [...] >> >> It does not. It _ensures_ that files are flushed. The doco style >> "affirmative tone" _assures_. The coding practice _ensures_! >> >> Pedanticly, > > Oh, come on, surely this doesn't effect the casual reader? /me presumes an ironic mispeling there. ;) Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7fyZgACgkQ+gerLs4ltQ5eaQCeL+E4CVxa1BWhm/MsPw29u/Ym QnUAoKBOY37dNA9aT5TZkv4hu9ixZjBn =jg86 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Reject characters bigger than U+10FFFF and Solaris issues
Hi,
I would like to deny the creation of an Unicode string containing characters
outside the range [U+; U+10]. The check is already present in some
places (e.g. the builtin chr() function), but not everywhere. The last
important function is PyUnicode_FromWideChar, function used to decode text
from the OS.
The problem is that test_locale fails on Solaris with such checks. I would
like to know how to handle Solaris issues. One possible solution is to not
handle issues, and just raise exceptions and skip the failing tests on Solaris
;-) Another solution is to modify locale.strxfrm() on all platforms to return
a list of int, instead of a str. The type of the result is not really
important, we just have to be able to compare two results (equal, greater,
lesser or equal, etc.). Another solution?
--
The two Solaris issues:
- in the hu_HU locale, localeconv() returns U+3020 for the thousands
separator
- locale.strxfrm() calls wcsxfrm() which returns characters in the range
[0x100; 0x1FF]
For localeconv(), it is the b'\xA0' byte string decoded from an encoding
looking like ISO-8859-?? (b'\xA0' is not decodable from UTF-8). It looks like
a bug in the decoder. It also looks like OpenIndiana doesn't use ISO-8859
locale anymore, only UTF-8 locales (which is much better!). I'm unable to
reproduce the issue on my OpenIndiana VM.
For wcsxfrm(), I'm not sure of the range. Example of a result: {0x1010163,
0x1010101, 0x1010103, 0x1010101, 0x1010103, 0x1010101, 0x1010101}. It looks
like wcsxfrm() uses the result of strxfrm() by grouping bytes 3 by 3 and add
0x100 to each group. Example of strxfrm() output for the same input:
{0x01, 0x01, 0x63, 0x01, 0x01, 0x01, ...}.
See http://bugs.python.org/issue13441 for more information.
Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warnings
Georg Brandl writes: > Oh, come on, surely this doesn't effect the casual reader? Casual readers aren't effective in any case; you want to hear the opinions of those who care. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] readd u'' literal support in 3.3?
On the heels of Armin's blog post about the troubles of making the same
codebase run on both Python 2 and Python 3, I have a concrete
suggestion.
It would help a lot for code that straddles both Py2 and Py3 to be able
to make use of u'' literals. It would seem to be an easy thing to
reenable (see
http://www.reddit.com/r/Python/comments/n3q7q/thoughts_on_python_3_armin_ronachers_thoughts_and/c36397t
) . It would seem to cost very little in terms of maintenance, and not much
in docs.
It would make it possible to share code like this across py2 and py3:
a = u'foo'
Instead of (with e.g. six):
a = u('foo')
Or:
from __future__ import unicode_literals
a = 'foo'
I recognize that the last option is probably the way "its meant to be
done", but in reality it's just more practical to not fail when literal
notation is more specific than strictly necessary.
- C
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
2011/12/8 Chris McDonough : > On the heels of Armin's blog post about the troubles of making the same > codebase run on both Python 2 and Python 3, I have a concrete > suggestion. > > It would help a lot for code that straddles both Py2 and Py3 to be able > to make use of u'' literals. Helpful or not helpful, I think that ship has sailed. The earliest it could see the light of day is 3.3, which would leave people trying to support 3.1 and 3.2 in a bind. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Thu, 2011-12-08 at 01:02 -0500, Benjamin Peterson wrote: > 2011/12/8 Chris McDonough : > > On the heels of Armin's blog post about the troubles of making the same > > codebase run on both Python 2 and Python 3, I have a concrete > > suggestion. > > > > It would help a lot for code that straddles both Py2 and Py3 to be able > > to make use of u'' literals. > > Helpful or not helpful, I think that ship has sailed. The earliest it > could see the light of day is 3.3, which would leave people trying to > support 3.1 and 3.2 in a bind. Right.. the title does say "readd ... support in 3.3". Are you suggesting "the ship has sailed" for eternity because it can't be supported in Python < 3.3? - C ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
2011/12/8 Chris McDonough : > On Thu, 2011-12-08 at 01:02 -0500, Benjamin Peterson wrote: >> 2011/12/8 Chris McDonough : >> > On the heels of Armin's blog post about the troubles of making the same >> > codebase run on both Python 2 and Python 3, I have a concrete >> > suggestion. >> > >> > It would help a lot for code that straddles both Py2 and Py3 to be able >> > to make use of u'' literals. >> >> Helpful or not helpful, I think that ship has sailed. The earliest it >> could see the light of day is 3.3, which would leave people trying to >> support 3.1 and 3.2 in a bind. > > Right.. the title does say "readd ... support in 3.3". Are you > suggesting "the ship has sailed" for eternity because it can't be > supported in Python < 3.3? I'm questioning the real utility of it. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Thu, 2011-12-08 at 01:18 -0500, Benjamin Peterson wrote: > 2011/12/8 Chris McDonough : > > On Thu, 2011-12-08 at 01:02 -0500, Benjamin Peterson wrote: > >> 2011/12/8 Chris McDonough : > >> > On the heels of Armin's blog post about the troubles of making the same > >> > codebase run on both Python 2 and Python 3, I have a concrete > >> > suggestion. > >> > > >> > It would help a lot for code that straddles both Py2 and Py3 to be able > >> > to make use of u'' literals. > >> > >> Helpful or not helpful, I think that ship has sailed. The earliest it > >> could see the light of day is 3.3, which would leave people trying to > >> support 3.1 and 3.2 in a bind. > > > > Right.. the title does say "readd ... support in 3.3". Are you > > suggesting "the ship has sailed" for eternity because it can't be > > supported in Python < 3.3? > > I'm questioning the real utility of it. All I can really offer is my own experience here based on writing code that needs to straddle Python 2.5, 2.6, 2.7 and 3.2 without use of 2to3. Having u'' work across all of these would mean porting would not require as much eyeballing as code modified via "from future import unicode_literals", it would let more code work on 2.5 unchanged, and the resulting code would execute faster than code that required us to use a u() function. What's the case against? - C ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
Such code still won't work on 3.2, hence restoring the redundant notation would be ultimately pointless. -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual) On Dec 8, 2011 4:34 PM, "Chris McDonough" wrote: > On Thu, 2011-12-08 at 01:18 -0500, Benjamin Peterson wrote: > > 2011/12/8 Chris McDonough : > > > On Thu, 2011-12-08 at 01:02 -0500, Benjamin Peterson wrote: > > >> 2011/12/8 Chris McDonough : > > >> > On the heels of Armin's blog post about the troubles of making the > same > > >> > codebase run on both Python 2 and Python 3, I have a concrete > > >> > suggestion. > > >> > > > >> > It would help a lot for code that straddles both Py2 and Py3 to be > able > > >> > to make use of u'' literals. > > >> > > >> Helpful or not helpful, I think that ship has sailed. The earliest it > > >> could see the light of day is 3.3, which would leave people trying to > > >> support 3.1 and 3.2 in a bind. > > > > > > Right.. the title does say "readd ... support in 3.3". Are you > > > suggesting "the ship has sailed" for eternity because it can't be > > > supported in Python < 3.3? > > > > I'm questioning the real utility of it. > > All I can really offer is my own experience here based on writing code > that needs to straddle Python 2.5, 2.6, 2.7 and 3.2 without use of 2to3. > Having u'' work across all of these would mean porting would not require > as much eyeballing as code modified via "from future import > unicode_literals", it would let more code work on 2.5 unchanged, and the > resulting code would execute faster than code that required us to use a > u() function. > > What's the case against? > > - C > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Thu, 2011-12-08 at 17:33 +1000, Nick Coghlan wrote: > Such code still won't work on 3.2, hence restoring the redundant > notation would be ultimately pointless. None of the code I've written which straddles Python 2/3 supports anything except Python 3.2+, and likewise I expect that for the next crop of porters/straddlers, their code won't support anything but Python 3.3+. So there is a point, which is to make it easier for people to port code that can straddle the most recent Python 3 release as well as 2.7/2.6. In that context, I don't see much relevance of having no support for u'' in Python 3.2. - C ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
