Re: [Python-Dev] len(chr(i)) = 2?
On 11/22/2010 5:48 AM, Stephen J. Turnbull wrote: I disagree. I do see a problem with UCS-2, because it fails to tell us that Python implements a large number of features that make it easy to do a very good job of working with non-BMP data in 16-bit builds of Yes. As I read the standard, UCS-2 is limited to BMP chars. So I was a bit confused when Python was described as UCS-2, until I realized that the term was inaccurate. Using that term punishes people like me who take the time to read the standard or otherwise learn what the term means. What Python does might be called USC-2+ or UCS-2e (xtended). -- 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] Missing Python Symbols when Starting Python App (Apache/Django/Mod_Wsgi)
On 11/22/2010 5:46 PM, Anurag Chourasia wrote: [Mon Nov 22 09:45:43 2010] [error] [client 108.10.0.191] mod_wsgi (pid=1273874): Target WSGI script '/u01/home/apli/wm/app/gdd/pyserver/ apache/django.wsgi' cannot be loaded as Python module. All other error stem probably from this. Please guide. Ask usage questions like this on python-list or a django-specific list. python-list is for discussion of development of future versions of Python, not usage of current versions. -- 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] r86702 - python/branches/py3k/Lib/idlelib/IOBinding.py
On 11/23/2010 1:01 AM, terry.reedy wrote: Author: terry.reedy Date: Tue Nov 23 07:01:31 2010 New Revision: 86702 Log: Issue 9222 Fix filetypes for open dialog Sorry, forgot to add this before clicking [go] or whatever the button is. Is there any way to revise a revision ;-? Modified: python/branches/py3k/Lib/idlelib/IOBinding.py Modified: python/branches/py3k/Lib/idlelib/IOBinding.py == --- python/branches/py3k/Lib/idlelib/IOBinding.py (original) +++ python/branches/py3k/Lib/idlelib/IOBinding.py Tue Nov 23 07:01:31 2010 @@ -476,8 +476,8 @@ savedialog = None filetypes = [ -(Python and text files, *.py *.pyw *.txt, TEXT), -(All text files, *, TEXT), +(Python files, *.py *.pyw, TEXT), +(Text files, *.txt, TEXT), (All files, *), ] ___ 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] r86703 - python/branches/release31-maint/Lib/idlelib/IOBinding.py
On 11/23/2010 1:16 AM, Senthil Kumaran wrote: Hi Terry, On Tue, Nov 23, 2010 at 2:07 PM, terry.reedypython-check...@python.org wrote: Author: terry.reedy Date: Tue Nov 23 07:07:04 2010 New Revision: 86703 Log: Issue 9222 Fix filetypes for open dialog Modified: python/branches/release31-maint/Lib/idlelib/IOBinding.py You should be using svnmerge.py script ( referenced in the dev FAQ), to merge your changes to release31-maint. This helps in merge tracking and helpful to release managers when they do the release. It is pretty simple, in your release31-maint checkout: Just run python svnmerge.py merge -r 9221 (your py3k revision value) If successful, do a svn commit -F svnmerge-output-filename ( this file is autogenerated) I am using TortoiseSVN which has a similar merge but does not seem to autogenerate anything. I did use its merge + commit for the 2.7 backport. Terry ___ 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] r86702 - python/branches/py3k/Lib/idlelib/IOBinding.py
On 11/23/2010 1:44 AM, Georg Brandl wrote: Am 23.11.2010 07:13, schrieb Terry Reedy: On 11/23/2010 1:01 AM, terry.reedy wrote: Author: terry.reedy Date: Tue Nov 23 07:01:31 2010 New Revision: 86702 Log: Issue 9222 Fix filetypes for open dialog Sorry, forgot to add this before clicking [go] or whatever the button is. Is there any way to revise a revision ;-? Yes, with SVN there is. I don't know if you can do it with whatever GUI tool you use, but the command is the following: svn propedit --revprop -r 86702 svn:log (followed by new message?) OK, done. TortoiseSVN has a nice revision log dialog. Right click and one of the choices is 'edit log message'. Easy. I see that there is a TortoiseHg as well. -- 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] len(chr(i)) = 2?
On 11/23/2010 2:11 PM, Alexander Belopolsky wrote:
This discussion motivated me to start looking into how well Python
library itself is prepared to deal with len(chr(i)) = 2. I was not
Good idea!
surprised to find that textwrap does not handle the issue that well:
len(wrap(' \U00010140' * 80, 20))
12
len(wrap(' \U0140' * 80, 20))
8
How well does textwrap handles composable pairs (letter + accent)? Does
is count two codepoints as one char space? and avoid putting line breaks
between? I suspect textwrap should be regarded as
(extended?)_ascii_textwrap.
That module should probably be rewritten to properly implement the
Unicode line breaking algorithm
http://unicode.org/reports/tr14/tr14-22.html.
Probably a good idea
Yet finding a bug in a str object method after a 5 min review was a
bit discouraging:
'xyz'.center(20, '\U00010140')
Traceback (most recent call last):
File stdin, line 1, inmodule
TypeError: The fill character must be exactly one character long
Again, what does it do with letter + decorator combinations? It seems to
me that the whole notion that one code point == one printed character
space is broken once one leaves ascii. Perhaps we need an is_uchar
function to recognize multi-code sequences, inclusing surrogate pairs,
that represent one char for the purpose of character oriented functions.
Given the apparent difficulty of writing even basic text processing
algorithms in presence of surrogate pairs, I wonder how wise it is to
expose Python users to them. As Wikipedia explains, [1]
Because the most commonly used characters are all in the Basic
Multilingual Plane, converting between surrogate pairs and the
original values is often not tested thoroughly. This leads to
persistent bugs, and potential security holes, even in popular and
well-reviewed application software.
So we did not test thoroughly enough and need to add appropriate unit
tests as bugs are fixed.
--
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] r86720 - python/branches/py3k/Misc/ACKS
On 11/23/2010 5:43 PM, Éric Araujo wrote: Modified: python/branches/py3k/Misc/ACKS == --- python/branches/py3k/Misc/ACKS (original) +++ python/branches/py3k/Misc/ACKS Tue Nov 23 21:32:47 2010 @@ -1,4 +1,4 @@ -Acknowledgements +Acknowledgements This change introduced a so-called UTF-8 BOM in the file. Is TortoiseSvn the culprit or a text editor? I used Notepad to edit the file, TortoiseSvn to commit, the same as I did for #9222, rev86702, Lib\idlelib\IOBinding.py, yesterday. If the latter is OK, perhaps *.py gets filtered better than misc. text files. I believe I have the config as specified in dev/faq. [miscellany] enable-auto-props = yes [auto-props] * = svn:eol-style=native *.c = svn:keywords=Id *.h = svn:keywords=Id *.py = svn:keywords=Id *.txt = svn:keywords=Author Date Id Revision Terry ___ 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] Sporadic problems with bugs.python.org
On 11/23/2010 8:32 PM, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/11/10 01:31, Jesus Cea wrote: Still retrying, with no luck. Anybody else can reproduce?. One of my tracker changes was just processed. The important one still retrying every 5 minutes... I hope I can go sleep before dawn :-P. I added a comment to one issue and opened another with no problem during the last couple of hours. -- 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] r86720 - python/branches/py3k/Misc/ACKS
On 11/24/2010 2:04 PM, Brett Cannon wrote: On Tue, Nov 23, 2010 at 15:07, Terry Reedytjre...@udel.edu wrote: I used Notepad to edit the file, TortoiseSvn to commit, the same as I did for #9222, rev86702, Lib\idlelib\IOBinding.py, yesterday. If the latter is OK, perhaps *.py gets filtered better than misc. text files. I believe I have the config as specified in dev/faq. Adding the BOM will be an editor thing, not a svn thing. Doing a Google search for [ms notepad bom] shows that Notepad did the helpful, invisible edit. So I presume it did the same with IOBinding.py. Does *.py get filtered is a way that could be extended to no-extention files? Do *.txt files get BOM filtered off? Should all text files in repository have some extension (default .txt)? More to the point, can better filtering be added to the new hg repository? Or can a local Windows hg setup have such filtering on local commits before pushing? I know now that I could always edit with IDLE's editor, but it is a lot easier to right click and select edit than it is to run thru the directory tree in an open dialog. And of course, since the pseudo-BOM addition is undocumented within notepad itself, and probably other editors, it is easy to not know. -- 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] r86720 - python/branches/py3k/Misc/ACKS
On 11/24/2010 3:04 PM, Georg Brandl wrote: Adding the BOM will be an editor thing, not a svn thing. Doing a It should show up as an invisible change in the first line of a file when you look at a svn diff. (It is a very good practice to look at a diff before committing anyway.) It does show up, and yes I agree. That should be in dev/faq if not already -- 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] r86720 - python/branches/py3k/Misc/ACKS
On 11/24/2010 5:13 PM, Martin v. Löwis wrote: So I presume it did the same with IOBinding.py. No. This file contains only ASCII characters, so notepad has decided to not add the BOM. Or it somehow got removed from the .py file. I tried with another .py file (and reverted!) and the diff showed the invisible change to the first line that Georg predicted. -- 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] len(chr(i)) = 2?
On 11/24/2010 3:06 PM, Alexander Belopolsky wrote: Any non-trivial text processing is likely to be broken in presence of surrogates. Producing them on input is just trading known issue for an unknown one. Processing surrogate pairs in python code is hard. Software that has to support non-BMP characters will most likely be written for a wide build and contain subtle bugs when run under a narrow build. Note that my latest proposal does not abolish surrogates outright. Users who want them can still use something like surrogateescape error handler for non-BMP characters. It seems to me that what you are asking for is an alternate, optional, utf-8-bmp codec that would raise an error, in either direction, for non-bmp chars. Then, as you suggest, if one is not prepared for surrogates, they are not allowed. -- 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] r86745 - in python/branches/py3k: Doc/library/difflib.rst Lib/difflib.py Lib/test/test_difflib.py Misc/NEWS
On 11/27/2010 7:17 AM, Nick Coghlan wrote: On Thu, Nov 25, 2010 at 4:12 PM, terry.reedypython-check...@python.org wrote: The :class:`SequenceMatcher` class has this constructor: -.. class:: SequenceMatcher(isjunk=None, a='', b='') +.. class:: SequenceMatcher(isjunk=None, a='', b='', autojunk=True) Optional argument *isjunk* must be ``None`` (the default) or a one-argument function that takes a sequence element and returns true if and only if the @@ -340,6 +349,9 @@ The optional arguments *a* and *b* are sequences to be compared; both default to empty strings. The elements of both sequences must be :term:`hashable`. + The optional argument *autojunk* can be used to disable the automatic junk + heuristic. + Catching up on checkins traffic, so a later checkin may already fix this, but there should be a versionchanged tag in the docs to note when the autojunk parameter was added. Right. When S.C. forward-ported the 2.7 patch. he must have thought it not needed and I missed the difference between the diffs. Will add note in both places needed immediately. Terry ___ 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] constant/enum type in stdlib
On 11/27/2010 6:26 PM, Raymond Hettinger wrote: Can I suggest that an enum-maker be offered as a third-party module Possibly with competing versions for trial and testing ;-) rather than prematurely adding it into the standard library. I had same thought. -- 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 and the Unicode Character Database
On 11/28/2010 3:58 PM, Alexander Belopolsky wrote:
On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrousolip...@pitrou.net wrote:
..
For example,
I don't think that supporting
float('١٢٣٤.٥٦')
1234.56
Even if this is somehow an accident or something that someone snuck in,
I think it a good idea that *users* be able to input amounts with their
native digits. That is different from requiring *programmers* to write
literals with euro-ascii-digits
is more important than to assure users that once their program
accepted some text as a number, they can assume that the text is
ASCII.
Why would they assume the text is ASCII?
def deposit(self, amountstr):
self.balance += float(amountstr)
audit_log(Deposited: + amountstr)
If the programmer want to assure ascii, he can produce a string,
possible formatted, from the amount
depform = Deposited: ${:14.2f}.format
def deposit(self, amountstr):
amount = float(amountstr)
self.balance += amount
# audit_log(Deposited: + str(amount) # simple version
audit_log(depform(amount))
Given that amountstr could be something like '182.33', I
think programmer should plan to format it.
--
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 and the Unicode Character Database
On 11/28/2010 5:51 PM, Alexander Belopolsky wrote: The Language Spec (whatever it is) should not, but hopefully the Library Reference should. If you follow http://docs.python.org/dev/py3k/library/functions.html#float link and the references therein, you'll end up with digit ::= 0...9 http://docs.python.org/dev/py3k/reference/lexical_analysis.html#grammar-token-digit So fix the doc for builtin float() and perhaps int(). -- 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] PEP 384 final review
On 11/28/2010 6:40 PM, Martin v. Löwis wrote: I have now completed http://www.python.org/dev/peps/pep-0384/ The current text contains several error messages like: System Message: WARNING/2 (pep-0384.txt, line 194) Bullet list ends without a blank line; unexpected unindent. 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 and the Unicode Character Database
On 11/29/2010 10:19 AM, M.-A. Lemburg wrote: Nick Coghlan wrote: On Mon, Nov 29, 2010 at 9:02 PM, M.-A. Lemburgm...@egenix.com wrote: If we would go down that road, we would also have to disable other Unicode features based on locale, e.g. whether to apply non-ASCII case mappings, what to consider whitespace, etc. We don't do that for a good reason: Unicode is supposed to be universal and not limited to a single locale. Because parsing numbers is about more than just the characters used for the individual digits. There are additional semantics associated with digit ordering (for any number) and decimal separators and exponential notation (for floating point numbers) and those vary by locale. We deliberately chose to make the builtin numeric parsers unaware of all of those things, and assuming that we can simply parse other digits as if they were their ASCII equivalents and otherwise assume a C locale seems questionable. Sure, and those additional semantics are locale dependent, even between ASCII-only locales. However, that does not apply to the basic building blocks, the decimal digits themselves. If the existing semantics can be adequately defined, documented and defended, then retaining them would be fine. However, the language reference needs to define the behaviour properly so that other implementations know what they need to support and what can be chalked up as being just an implementation accident of CPython. (As a point in the plus column, both decimal.Decimal and fractions.Fraction were able to handle the '١٢٣٤.٥٦' example in a manner consistent with the int and float handling) The support is built into the C API, so there's not really much surprise there. Regarding documentation, we'd just have to add that numbers may be made up of an Unicode code point in the category Nd. See http://www.unicode.org/versions/Unicode5.2.0/ch04.pdf, section 4.6 for details Decimal digits form a large subcategory of numbers consisting of those digits that can be used to form decimal-radix numbers. They include script-specific digits, but exclude char- acters such as Roman numerals and Greek acrophonic numerals. (Note that1, 5 = 15 = fifteen, butI, V = IV = four.) Decimal digits also exclude the compatibility subscript or superscript digits to prevent simplistic parsers from misinterpreting their values in context. int(), float() and long() (in Python2) are such simplistic parsers. Since you are the knowledgable advocate of the current behavior, perhaps you could open an issue and propose a doc patch, even if not .rst formatted. -- 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 and the Unicode Character Database
On 11/30/2010 3:23 AM, Stephen J. Turnbull wrote: I see no reason not to make a similar promise for numeric literals. I see no good reason to allow compatibility full-width Japanese ASCII numerals or Arabic cursive numerals in for i in range(...) for example. I do not think that anyone, at least not me, has argued for anything other than 0-9 digits (or 0-f for hex) in literals in program code. The only issue is whether non-programmer *users* should be able to use their native digits in applications in response to input prompts. -- 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 and the Unicode Character Database
On 11/30/2010 10:05 AM, Alexander Belopolsky wrote:
My general answers to the questions you have raised are as follows:
1. Each new feature release should use the latest version of the UCD as
of the first beta release (or perhaps a week or so before). New chars
are new features and the beta period can be used to (hopefully) iron out
any bugs introduced by a new UCD version.
2. The language specification should not be UCD version specific. Martin
pointed out that the definition of identifiers was intentionally written
to not be, bu referring to 'current version' or some such. On the other
hand, the UCD version used should be programatically discoverable,
perhaps as an attribute of sys or str.
3.. The UCD should not change in bugfix releases. New chars are new
features. Adding them in bugfix releases will introduce gratuitous
imcompatibilities between releases. People who want the latest Unicode
should either upgrade to the latest Python version or patch an older
version (but not expect core support for any problems that creates).
Given that 2.7 will be maintained for 5 years and arguably Unicode
Consortium takes backward compatibility very seriously, wouldn't it
make sense to consider a backport at some point?
I am sure we will soon see a bug report that the following does not
work in 2.7: :-)
ord('\N{CAT FACE WITH WRY SMILE}')
128572
3 (cont). 2.7 is no different in that regard. It is feature frozen just
like all other x.y releases. And that is the answer to any such report.
If that code became valid in 2.7.2, for instance, it would still not
work in 2.7 and 2.7.1. Not working is not a bug; working is a new
feature introduced after 2.7 was released.
- How specific should library reference manual be in defining methods
affected by UCD such as str.upper()?
It should specify what this actually does in Unicode terminology
(probably in addition to a layman's rephrase of that)
I opened an issue for this:
http://bugs.python.org/issue10587
1,2 (cont). Good idea in general.
I was more concerned about wide an narrow unicode CPython builds. Is
it a bug that '\U'.isalpha() may disagree even when the two
implementations are based on the same version of UCD?
4. While the difference between narrow/wide builds of (CPython) x.y
(which should have once constant UCD) cannot be completely masked, I
appreciate and generally agree with your efforts to minimize them. In
some cases, there will be a conflict/tradeoff between eliminating this
difference versus that.
--
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 and the Unicode Character Database
On 12/1/2010 12:55 PM, Alexander Belopolsky wrote:
On Sun, Nov 28, 2010 at 5:48 PM, M.-A. Lemburgm...@egenix.com wrote:
..
With Python 3.1:
exec('\u0CF1 = 1')
Traceback (most recent call last):
File stdin, line 1, inmodule
File string, line 1
ೱ = 1
^
SyntaxError: invalid character in identifier
but with Python 3.2a4:
exec('\u0CF1 = 1')
eval('\u0CF1')
1
Such changes are not new, but I agree that they should probably
be highlighted in the What's new in Python x.x.
As of today, What’s New In Python 3.2 [1] does not even mention the
unicodedata upgrade to 6.0.0. Here are the features form the
unicode.org summary [2] that I think should be reflected in Python's
What's New document:
* adds 2,088 characters, including over 1,000 additional symbols—chief
among them the additional emoji symbols, which are especially
important for mobile phones;
* corrects character properties for existing characters including
- a general category change to two Kannada characters (U+0CF1,
U+0CF2), which has the effect of making them newly eligible for
inclusion in identifiers;
- a general category change to one New Tai Lue numeric character
(U+19DA), which would have the effect of disqualifying it from
inclusion in identifiers unless grandfathering measures are in place
for the defining identifier syntax.
The above may be too verbose for inclusion to What’s New In Python
3.2,
I think those 11 lines are pretty good. Put them in
('\N{CAT FACE WITH WRY SMILE}'!
Plus give a link to Unicode site (Issue numbers are implicit links).
--
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
[Python-Dev] Deprecating undocumented, unused functions in difflib.
Difflib.SequenceMatcher object currently get two feature attributes: self.isbjunk = junk.__contains__ self.isbpopular = popular.__contains__ Tim Peters agrees that the junk and popular sets should be directly exposed and documented as part of the api, thereby making the functions redundant. The two functions are not currently documented (and should not be now). A google codesearch of 'isbjunk' and 'isbpopular' only returns hits in difflib.py itself (and its predecessor, ndiff.py). It would be easiest to just remove the two lines above. Or should I define functions _xxx names that issue a deprecation warning and attach them as attributes to each object? (Defining instance methods would not be the same). There is only one internal use of one of the two functions which is easily edited. -- 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] Deprecating undocumented, unused functions in difflib.
On 12/1/2010 8:22 PM, Michael Foord wrote: I would still be tempted to go through a single release of deprecation. You can add a test that the names are gone if the version of Python is 3.3. When the tests start failing the code and the tests can be ripped out. I was wondering how people remember... It would be nice is there were instead a central place to 'deposit' simple future patches that just consist of removals -- 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] Porting Ideas
On 12/1/2010 8:17 PM, Michael Foord wrote: It is well *possible* that there are packages with a runtime dependency on libraries in mercurial however. Those would need mercurial porting to Python 3 if they are to run on Python 3. If they simply shell out to mercurial that wouldn't be the case. It would be nice is all the Python-coded tools needed to work on Python3 ran on Python3, so one did not have to install 2.x just for that purpose ;-). Does Sphinx run on PY3 yet? -- 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] Deprecating undocumented, unused functions in difflib.
On 12/1/2010 8:22 PM, Nick Coghlan wrote: On Thu, Dec 2, 2010 at 6:23 AM, Terry Reedytjre...@udel.edu wrote: It would be easiest to just remove the two lines above. Or should I define functions _xxx names that issue a deprecation warning and attach them as attributes to each object? (Defining instance methods would not be the same). Given that functions are converted to bound methods only on retrieval from an instance, why wouldn't it be the same? The two SequenceMatcher instance attributes are bound functions of the two sets, not of the instance. But you are right in the sense that the usage would be the same. Since, as of a week ago, the sets were implemented as dicts, any code depending on the class of the underlying instance is already broken. So I will go with S-M methods and add a doc string like Undocumented, deprecated method that will disappear in 3.3. Do not use! to show up in a help() listing. But yes, if you want to get rid of them, then deprecation for 3.2 and removal in 3.3 is the way to go. OK. Alternatively, not deprecating them at all and just leaving them undocumented with a comment in the source to say they have been deliberately omitted from the docs would also be fine. Too messy and too useless ;-). -- 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 and the Unicode Character Database
On 12/1/2010 7:44 PM, Alexander Belopolsky wrote: it. The argument was that if there was a use case for parsing Eastern Arabic numerals, it would be better served by a module written by someone who speaks one of the Arabic languages and knows the details of how Eastern Arabic numerals are written. So far nobody has even claimed to know conclusively that Arabic-Indic digits are always written left-to-right. Both my personal observations when travelling from Turkey to India and Wikipedia say yes. When representing a number in Arabic, the lowest-valued position is placed on the right, so the order of positions is the same as in left-to-right scripts. https://secure.wikimedia.org/wikipedia/en/wiki/Arabic_language#Numerals -- 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] r86930 - in python/branches/py3k: Doc/library/os.rst Lib/os.py Lib/test/test_os.py Misc/ACKS Misc/NEWS
On 12/2/2010 4:32 AM, Nick Coghlan wrote: On Thu, Dec 2, 2010 at 5:05 PM, terry.reedypython-check...@python.org wrote: (except I did not write most of the patch) + If + the target directory with the same mode as we specified already exists, + raises an :exc:`OSError` exception if *exist_ok* is False, otherwise no + exception is raised. If the directory cannot be created in other cases, + raises an :exc:`OSError` exception. I would suggest being explicit here that directory exists, but has a mode other than the one requested always triggers an exception. Perhaps something like the following: Raises an :exc:`OSError` exception if the target directory already exists, unless *exist_ok* is True and the existing directory has the same mode as is specified in the current call. Also raises an :exc:`OSError` exception if the directory cannot be created for any other reason. Georg has already patched that paragraph. I will let him decide if any further change is needed. Terry ___ 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] Porting Ideas
On 12/2/2010 8:36 AM, Lennart Regebro wrote: On Wed, Dec 1, 2010 at 20:17, Antoine Pitrousolip...@pitrou.net wrote: And I'm not sure what this package called Python is (“a high-level object-oriented programming language”? like Java?), but I'm pretty sure I've heard there's a Python 3 compatible version. Uhm... http://pypi.python.org/pypi/Python Anybody wanna remove that, or update it or something? :-) Entry is for Python 2.5. # Package Index Owner: guido, anthony, barry -- 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 and the Unicode Character Database
On 12/2/2010 6:54 PM, Alexander Belopolsky wrote:
On Thu, Dec 2, 2010 at 4:14 PM, M.-A. Lemburgm...@egenix.com wrote:
..
Some examples:
http://www.bdl.gov.lb/circ/intpdf/int123.pdf
I looked at this one more closely. While I cannot understand what it
says, It appears that Arabic numerals are used in dates. It looks
like Python want be able to deal with those:
When I travelled in S. Asia around 25 years ago, arabic and indic
numerals were in obvious use in stores, road signs, and banks (as with
money exchange receipts). I learned the digits partly for
self-protestions ;-). I have no real idea of what is done *now* in
computerized business, but I assume the native digits are used.
It may well be that there is no Python software yet that operates with
native digits. The lack of direct output capability would hinder that.
Of course, someone could run both input and output through
language-specific str.translate digit translators.
datetime.strptime('١٩٩٩/١٠/٢٩', '%Y/%m/%d')
Googling ١٩٩٩ gets about 83,000 hits.
..
ValueError: time data '١٩٩٩/١٠/٢٩' does not match format '%Y/%m/%d'
Interestingly,
datetime.strptime('١٩٩٩', '%Y')
datetime.datetime(1999, 1, 1, 0, 0)
which further suggests that support of such numerals is accidental.
As I think more about it, though I am becoming less avert to accepting
these numerals for base 10 integers.
Both input and output are needed for educational programming, though
translation tables might be enough.
Integers can be easily extracted
from text using simple regex and '\d' accepts all category Nd
characters. I would require though that all digits be from the same
block, which is not hard because Unicode now promises to only have
them in contiguous blocks of 10.
That seems sensible.
This rule seems to address some of
security issues because it is unlikely that a system that can display
some of the local digits would not be able to display all of them
properly.
I still don't think it makes any sense to accept them in float().
For the present, I would pretty well agree with that, at least until we
know more.
You have raised an important issue. It is a bit of a chicken and egg
problem though. We will not really know what is needed until Python is
used more in non-english/non-euro contexts, while such usage may await
better support.
--
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] gc ideas -- sparse memory
On 12/3/2010 5:55 PM, Dima Tisnek wrote: How hard or reasonable would it be to free memory pages on OS level? [pcmiiw] Gabage collection within a generation involves moving live objects to compact the generation storage. This separates the memory region into 2 parts live and cleared, the pointer to the beginning of the cleared part is where next allocation is going to happen. When this is done, does Python gc move the objects preserving order or does it try to populate garbaged slot with some live object disregarding order? Earlier case is more applicable, but latter case is a target for below too. If we were to look at memory regions from the OS point of view, they are allocated as pages (or possibly as hugetlb pages). So if we are to compact something like this [LL__][_L__][][L_LL][LFFF] where [] is a page, L is live object and _ is garbage and F is free memory, would it not make more sense to tell OS that [] is not needed anymore, and not move some of the consequtive [L_LL][LFFF] at all, or at least not move those objects as far down the memory region? This would of course have a certain overhead of tracking which pages are given back to OS and mapping them back when needed, but at the same time, be beneficial because fewer objets are moved and also possibly improve cpu cache performance because objects won't be moved so far out. p.s. if someone has an athoritative link to modern python gc design, please let me know. gc is implementation specific. CPython uses ref counting + cycle gc. A constraint on all implementations is that objects have a fixed, unique id during their lifetime. CPython uses the address as the id, so it cannot move objects. Other implementations do differently. Compacting gc requires an id to current address table or something. -- 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] PEP 384 accepted
On 12/3/2010 5:52 PM, Martin v. Löwis wrote: Am 03.12.2010 23:48, schrieb Éric Araujo: But I'm not interested at all in having it in distutils2. I want the Python build itself to use it, and alas, I can't because of the freeze. You can’t in 3.2, true. Neither can you in 3.1, or any previous version. If you implement it in distutils2, you have very good chances to get it for 3.3. Isn’t that a win? It is, unfortunately, a very weak promise. Until distutils2 is integrated in Python, I probably won't spend any time on it. Éric, I have the impression from Tarek and you together that D2 is still in alpha only because it is not feature frozen and that it is as capable and stable as D1. I do not know what Martin means by 'integrate' (other than that he be able to use it to build Python), but if my first sentence is true, I cannot help but wonder whether a snapshot of D2 could be included with 3.2, perhaps as '_distribute2' (note leading underscore) at least for Python's use. The doc, if any, could just say 'Development snapshot of D2.a4 (or whatever) for building Python. Other uses should get the latest public release from PyPI. -- 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] PEP 384 accepted
On 12/3/2010 6:46 PM, Martin v. Löwis wrote: and stable as D1. I do not know what Martin means by 'integrate' (other than that he be able to use it to build Python) That the master copy of the source code is in the Python source repository. Is a separate branch acceptible, as long as you can commit changes? Does the meaning of 'repository' change any with the hg switch? -- 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] gc ideas -- sparse memory
On 12/3/2010 6:15 PM, James Y Knight wrote: On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote: gc is implementation specific. CPython uses ref counting + cycle gc. A constraint on all implementations is that objects have a fixed, unique id during their lifetime. CPython uses the address as the id, so it cannot move objects. Other implementations do differently. Compacting gc requires an id to current address table or something. I left out that the id must be an int. It's somewhat unfortuante that python has this constraint, instead of the looser: objects have a fixed id during their lifetime, which is much easier to implement, and practically as useful. Given that the only different between 'fixed and unique' and 'fixed' is the uniqueness part, I do not understand 'practically as useful'. Duplicate ids (in the extreme, that same for all objects) hardly seem useful at all. -- 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] gc ideas -- sparse memory
On 12/3/2010 7:46 PM, James Y Knight wrote: Sure they are. This is what Java provides you, for example. If you have fixed, but potentially non-unique ids (in Java you get this using identityHashCode()), you can still make an identity I do not see the point of calling a (non-unique) hash value the identity hashtable. You simply need to *also* check using is that the two In Python, that unique isness is the identify. (a is b) == (id(a) == id(b)) by definition. objects really are the same one after finding the hash bin using id. by using the hash value, which is how Python dict operate. -- 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] gc ideas -- sparse memory
On 12/3/2010 11:06 PM, Cameron Simpson wrote: On 03Dec2010 18:15, James Y Knightf...@fuhm.net wrote: | On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote: | gc is implementation specific. CPython uses ref counting + cycle | gc. A constraint on all implementations is that objects have a fixed, | unique id during their lifetime. CPython uses the address as the id, so | it cannot move objects. Other implementations do differently. Compacting | gc requires an id to current address table or something. | | It's somewhat unfortuante that python has this constraint, instead of | the looser: objects have a fixed id during their lifetime, which is | much easier to implement, and practically as useful. Python doesn't have the constraint you imagine; it _does_ have objects have a fixed id during their lifetime. id(object) Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Of course, other implementations are free to change builtins, but code that depends on CPython's definitions will not run. -- 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] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py
DeprecationWarnings that show up in a lot of existing code are controversial and have caused pain in the past. I'd like to leave this on for 3.2 beta1 and see how things go. We can remove the warning if it is deemed too noisy during any betas. (case study: the md5 and sha module DeprecationWarnings are loathed around the world as those modules were never going to be removed in 2.x and 2to3 has a fixer for code that uses them) My understanding is that DeprecationWarnings are now off by default in part because of issues like the above. So they should only be seen by programmers who turn them of for the purpose of seeing them so they can future-proof their code before it fails. As a result, there have been several added recently in efforts to clean up the APis. The real issue is changing the default. If allowed, should it be switched in one release or should there be an intermediate release with no default. Which are you planning? My feeling is that we should be able to correct bad-enough mistakes. Code can easily be made portable across all 3.x versions by given an explicit value and not depending on defaults. I think there should be an intermediate version to cause overt failure of code that is not upgraded, because the programmer neglected either to turn DeprecationWarnings on for test runs or to read the News releases. Terry J. 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] PEP 11: Dropping support for ten year old systems
On 12/5/2010 4:48 PM, Martin v. Löwis wrote: I'd like to tighten PEP 11, and declare a policy that systems older than ten years at the point of a feature release are not supported anymore by default. Older systems where support is still maintained need to be explicitly listed in the PEP, along with the name of the responsible maintainer (I think this would currently only cover OS2/EMX which is maintained by Andrew MacIntyre). Support for such old platforms can then be removed from the codebase immediately, no need to go through a PEP 11 deprecation cycle. As a consequence, I would then like to remove support for Solaris versions older than Solaris 8 (released in January 2000, last updated by Sun in 2004) from the configure script for 3.2b2. A number of other tests in configure.in could probably also be removed, although I personally won't touch them before 3.2. The other major system affected by this would be Windows 2000, for which we already decided to not support it anymore. WinXP (released August 2001) should be supported a lot longer than another year ;-) . It is still supported and installed on new systems. -- 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] PEP 11: Dropping support for ten year old systems
On 12/6/2010 4:08 AM, Martin v. Löwis wrote: For Windows and Solaris, it seems that some users continue to use the system after the vendor stops producing patches, and dislike the prospect of not having Python releases for it anymore. However, they are in clear minority, so by our current policy for minority platforms I quite suspect that XP will be in major use (more than say, current BSD) for some years after MS stops official support. Why rush to drop it? Is there much XP specific stuff in the current xp/vista/7 code? It seems to me that the rule should be something like around 10 years or end of support, as modified by popularity, the burden of continued support, the availability of test machines, and the availability of people. -- 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] PEP 11: Dropping support for ten year old systems
On 12/6/2010 3:46 PM, Martin v. Löwis wrote: Am 06.12.2010 20:25, schrieb Terry Reedy: I quite suspect that XP will be in major use (more than say, current BSD) for some years after MS stops official support. Why rush to drop it? What rush to drop it, On the day MS stops support. But it is a moot support until them. -- 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] Using logging in the stdlib and its unit tests
On 12/8/2010 2:00 PM, Vinay Sajip wrote: Actually, I don't think my response to Nick's post (about concurrent.futures) could be characterized as I don't care, as I even made a specific proposal about how a change could be implemented. Your proposal struck me as probably the best way forward. Can you code it up and put a patch on the tracker that people can test before the next beta? A couple of other notes: 1. The number of participants in this thread is probably larger than average. So I think the responses so far can be taken as representative of those here who care enough to say something. 2. To me, Django is more an app framework than a mere 'library', and one with extra problems of error reporting in that it needs to send messages to both client and server and possibly elsewhere. So I as a user would expect it to embody extra thought about message disposition relative to a typical library. -- 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] Using logging in the stdlib and its unit tests
On 12/10/2010 5:16 PM, Vinay Sajip wrote: IMO as long as it's just a small amount of work to get the specific effect that you want, it doesn't really matter too much what the default is - though of course I'd like it to be right, whatever that means ;-) I think the default should accomodate both internal uses (stdlib and elsewhere) and beginner uses. I suspect the latter would mean outputting most everything, to the convenience functions work (as a beginner might expect). -- 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] API for the new sysconfig module
On 12/10/2010 4:59 PM, R. David Murray wrote: Like Éric, I'm not sure what the implications of the existing module having been released in 2.7 and 3.2 beta are in terms of making such an API change. I am with Raymond on this: the purpose of betas is so we can test *and* make changes. No one should base production software on a beta release. -- 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] porting python.org
On 12/11/2010 12:19 PM, Georg Brandl wrote: Am 11.12.2010 11:36, schrieb Prashant Kumar: I was wondering if we could contribute in porting of python.org http://python.org website over to python3k. I think this is an excellent idea. It will test Python3 and the modules and external packages used and once successful, advertise that all such are production-ready Py3 software. If and when there is a test version I can access (py3.python.org?), I will happily help test by browsing around and downloading stuff. -- 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] use case for bytes.format
On 12/12/2010 2:04 PM, Zeljko wrote: This post should have gone to python-list, mirrored as gmane.comp.python.general. Please limit any further response to either of those (or c.l.p) and delete pydev. I'm considering to write some pure python pdf lib from from scratch, but found there is no built-in formating for bytes. Bytes do, but you should use text str for general text manipulation. It's very frustrating to use some inefficient surogate funtion, which is gong to be called thousands times. This sentence has 3 spelling mistakes, 2 of which would be caught with a mail client like Thunderbird (free) that has spelling correction. Please consider switching. -- 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] logging doc broken
On 12/13/2010 6:04 AM, Vinay Sajip wrote: True, but this area changed after 2.6 was released (after even 2.7, IIRC), so I want to be sure that if I'm going to change the doc sources on release26-maint, 2.6 is in security-fix only mode. I am not sure if that precludes doc fixes, on the chance that there will ever be a security fix, as it does non-security bug fixes, but is it hardly worth the bother compared to improving active releases. -- 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] A grammatical oddity: trailing commas in argument lists -- continuation
On 12/13/2010 2:17 PM, Antoine Pitrou wrote: On Mon, 13 Dec 2010 14:09:02 -0500 Alexander Belopolskyalexander.belopol...@gmail.com wrote: On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossumgu...@python.org wrote: I'm at least +0 on allowing trailing commas in the situation the OP mentioned. FWIW, I am also about +0.5 on allowing trailing comma. Note that in a similar situation, the C standardization committee has erred on the side of consistency: A new feature of C99: a common extension in many implementations allows a trailing comma after the list of enumeration constants. The Committee decided to adopt this feature as an innocuous extension that mirrors the trailing commas allowed in initializers. http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf Similarly, I find allowing trailing comma in keyword only arguments lists to be an innocuous extension that mirrors the trailing commas allowed in the positional arguments lists. +1 from me as well. Special cases are hard to remember. Same here. A strong +1 for a consistent rule (always or never allowed) with a +1 for always given others use case of one param/arg per line. So I think the issues should be reopened. -- 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/18/2010 3:48 PM, Antoine Pitrou wrote: On Sat, 18 Dec 2010 21:00:04 +0100 (CET) ezio.melottipython-check...@python.org wrote: Author: ezio.melotti Date: Sat Dec 18 21:00:04 2010 New Revision: 87389 Log: #10573: use actual/expected consistently in unittest methods. Change was requested by M. Foord and R. Hettinger (and G.Brandl for b2). IMHO, this should be reverted. The API currently doesn't treat these arguments differently, so they should really be labeled first and second. Otherwise, the user will wrongly assume that the signature is asymmetric and that they should be careful about which order they pass the arguments in. The error report on assert failure *is* often asymmetrical ;=). From Michael's post: This is particularly relevant for the methods that produce 'diffed' output on failure - as the order determines whether mismatched items are missing from the expected or additional to the expected. This change struck me as a nice bit of polishing. -- 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] Locale-specific formatting
On 12/18/2010 10:33 AM, Oleg Broytman wrote: This is quite a known problem, not specific to Python. Locale settings are global for a process, and this is one of the thousands reasons why locale is considered so horrible. ICU is perhaps the only way around the problem. This is about the third mention of 'ICU' in the last few weeks, so I looked it up: International Components for Unicode http://site.icu-project.org/ Several libraries (C/C++,Java), including prebuilt binaries for Windows (and some others). There is already a Python .cpp wrapper (but no Windows binaries, which limits usefulness) http://pyicu.osafoundation.org/ http://pypi.python.org/pypi/PyICU/1.0.1 -- 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] [feature request] add .svgz to mimetypes.suffix_map
On 12/18/2010 4:37 PM, Grygoriy Fuchedzhy wrote: Hi. I've created bug on bugtracker, and then I was told there that I should post this on this mailing list for discussion. Here is link to bug: http://bugs.python.org/issue10730 Please add'.svgz':'.svg.gz' map to mimetypes.suffix_map This issue is actually a request to add .svg to the types map and the the abbreviation .svgz for .svg.gx to the suffix_map. I believe Scalable Vector Graphics are well on the way to becoming *the* standard vector graphics format for the web, especially with upcoming IE9 support. https://secure.wikimedia.org/wikipedia/en/wiki/Svg It (they) are already supported by the other major browsers. In addition, Google announced on 31 August 2010 that it had begun to index SVG content on the web, whether it is in standalone files or embedded in HTML. So it might be sensible to add these now rather than two years from now. But if it is too late for 3.2, then I expect addition for 3.3 will be obvious. -- 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/19/2010 1:41 PM, Guido van Rossum wrote: On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrousolip...@pitrou.net wrote: This could be nicely resolved by renaming the arguments a and b, and having the diff display a, b. It's quite natural (both the diff ordering and the arguments ordering), and they are consistent with each other. So 'a' stands for 'after' and 'b' for 'before', right? :-) difflib uses 'a' and 'b' for before and after (orig,new in svn terms, with edits/diffs from a to b) respectively. Not really great. The docs then have to explain what 'a' and 'b' are and the implications for interpreting the output. -- 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/20/2010 8:38 PM, Nick Coghlan 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? I would very much like that. I once changed some the entries but bugfix or later alpha/beta/gamma/final installation reset everything. (Question is mainly for Martin, obviously, but I'm also curious if anyone else has encountered the same thing) Now that I have multiple versions of Python installed (for development testing), I have *three* identical 'IDLE (Python GUI)' entries in the left-hand frequently-used programs column of the Start panel. This is really useless and therefore a waste of space. -- 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öwismar...@v.loewis.de 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] 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] nonlocal x = value
On 12/22/2010 5:11 PM, Laurens Van Houtven wrote: On Sat, Dec 18, 2010 at 1:12 PM, Georg Brandlg.bra...@gmx.net wrote: Am 17.12.2010 17:52, schrieb Laurens Van Houtven: +1 for throwing it out of the PEP. Assignment is a thing, nonlocal/global is a thing, don't mix them up :) (That in addition to the grammar cleanliness argument Stephan already made) The trouble is what to make of nonlocal x = 3, y Is it two nonlocal declarations or one with a tuple assignment? Georg I'm not sure I understand. Isn't that another reason to throw it out? I am sure he meant it to be, and I agree. We lived without global x = 3, y all these years. If you don't allow such assignments, there can't be any ambiguity, right? (Or am I missing something?) -- 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] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS
On 12/24/2010 11:09 AM, Michael Foord wrote: On 22/12/2010 02:26, Terry Reedy wrote: 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. Could you explain what you mean? I was referring back to an output example symmetric diff that was clipped somewhere along the way: In x not in y: ... In y not in x: ... rather than just using -,+ prefixes which are not necessarily self-explanatory. 'Not applicable' would refer to output from difflib which necessarily is ordered. -- 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] Range __contains__ and objects with __index__ methods
On 12/26/2010 7:15 PM, Nick Coghlan wrote: Starting in Python 3.2, range() supports fast containment checking for integers (i.e. based on an O(1) arithmetic calculation rather than an O(N) iteration through the entire sequence). Currently, this fast path ignores objects that implement __index__ - they are relegated to the slow iterative search. This seems wrong to me - the semantics of __index__ are such that it is meant to be used for objects that are alternative representations of the corresponding Python integers (e.g. numpy scalars, or integers that use a particular number of bits in memory). Under that interpretation, if an object provides __index__, we should use the fast path instead of calling __eq__ multiple times. If I understand, you are proposing 'replacing' o with o.__index__() (when possible) and proceeding on the fast path rather than iterating the range and comparing o for equality each value in the range (the slow path). I suppose this would change semantics if o != o.__index__(). Equality is not specified in the manual: object.__index__(self) Called to implement operator.index(). Also called whenever Python needs an integer object (such as in slicing, or in the built-in bin(), hex() and oct() functions). Must return an integer. However operator.__index__(a) Return a converted to an integer. Equivalent to a.__index__(). comes close to implying equality (if possible). What are the actual used of .__index__? -- 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] r87445 - python/branches/py3k/Lib/numbers.py
On 12/26/2010 7:01 PM, Nick Coghlan wrote: Yes, the definition in the language reference could definitely be improved to mention the semantics first, and then reference operator.index second. Possible wording Indicates to the Python interpreter that the object is semantically equivalent to the returned integer, rather than merely supporting a possibly lossy coercion to an integer If that is the intent of __index__, the doc should say so more clearly. That clarification would change my answer to your question about range. (i.e. as the __int__ method allows for types like float and decimal.Decimal). This allows non-builtin objects to be used as sequence indices, elements of a slice definition, multiplies in sequence repetition, etc. Can be invoked explicitly from Python code via operator.index() Removing the circularity from the definitions of __index__ and operator.index doesn't have a great deal to do with the docstrings in numbers.py, though. It is both related and needed though. IE, it is hard to answer questions about what to to with .index if the intended meaning of .index is not very clear ;-). -- 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] r87537 - in python/branches/py3k: Doc/library/struct.rst Doc/whatsnew/3.2.rst Lib/test/test_struct.py Lib/wave.py Misc/NEWS Modules/_struct.c
On 12/28/2010 8:26 AM, victor.stinner wrote: Author: victor.stinner Date: Tue Dec 28 14:26:42 2010 New Revision: 87537 Log: Issue #10783: struct.pack() doesn't encode implicitly unicode to UTF-8 Modified: python/branches/py3k/Doc/whatsnew/3.2.rst == --- python/branches/py3k/Doc/whatsnew/3.2.rst (original) +++ python/branches/py3k/Doc/whatsnew/3.2.rst Tue Dec 28 14:26:42 2010 @@ -1705,3 +1705,7 @@ (Contributed by Georg Brandl and Mattias Brändström; `appspot issue 53094http://codereview.appspot.com/53094`_.) + +* :func:`struct.pack` doesn't encode implicitly unicode to UTF-8 anymore: That phrasing is awkward at best. I believe you mean struct.pack no longer implicitly encodes unicode to UTF-8, which will be clearer to most people. Terry ___ 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] Compile() and Windows/Mac newlines
In python-list thread Does Python 3.1 accept \r\n in compile()?
jmfauth notes that
compile('print(999)\r\n', 'in', 'exec')
works in 2.7 but not 3.1 (and 3.2 not checked) because 3.1 sees '\r' as
SyntaxError.
I started to respond that this is part of Py3 cleanup with newlines
converted on input and back-compatibility with ancient Python not
needed. Then I saw in 3.2 manual
Changed in version 3.2: Allowed use of Windows and Mac newlines. Also
input in 'exec' mode does not have to end in a newline anymore. Added
the optimize parameter.
I verified second statement (print(999) works) (and remember commit
for third), but original above gives same error. Should Allowed use of
Windows and Mac newlines. be deleted? What else could it mean other
than use of '\r' or '\r\n'?
--
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] Compile() and Windows/Mac newlines
On 12/29/2010 2:31 PM, Terry Reedy wrote:
In python-list thread Does Python 3.1 accept \r\n in compile()?
jmfauth notes that
compile('print(999)\r\n', 'in', 'exec')
works in 2.7 but not 3.1 (and 3.2 not checked) because 3.1 sees '\r' as
SyntaxError.
I started to respond that this is part of Py3 cleanup with newlines
converted on input and back-compatibility with ancient Python not
needed. Then I saw in 3.2 manual
Changed in version 3.2: Allowed use of Windows and Mac newlines. Also
input in 'exec' mode does not have to end in a newline anymore. Added
the optimize parameter.
I verified second statement (print(999) works) (and remember commit
for third), but original above gives same error. Should Allowed use of
Windows and Mac newlines. be deleted? What else could it mean other
than use of '\r' or '\r\n'?
After tracing the questioned comment to B.Peterson's r76232 merged from
2.7 r76230 fix several compile() issues by translating newlines in the
tokenizer, I decided to open http://bugs.python.org/issue10792
--
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] Compile() and Windows/Mac newlines
On 12/29/2010 2:53 PM, Benjamin Peterson wrote: Type help, copyright, credits or license for more information. compile(print(999)\r\n, blah, exec) code objectmodule at 0xb353e8, file blah, line 1 I made a mistake in testing. Issue closed. Sorry for the noise. -- 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] Issue #10348: concurrent.futures doesn't work on BSD
On 12/29/2010 5:44 PM, David Bolen wrote: Or, I'll make the same offer I think I made in the multiprocessing case, which is I can build a kernel on the buildbot with a higher limit, if that's needed just to ensure test completion. Yes, it would also mean that users would need to do the same (or in later FreeBSD releases it can be done dynamically via sysctl), but that didn't seem to be considered a big hurdle in the prior discussion for multiprocessing. That would essentially switch this to a documentation issue, to document that on older FreeBSD platforms a user needs to take some steps, either as a startup configuration, or a kernel rebuild depending on release. Testing on updated buildbots and documenting older BSD limits and fixes seems like the best solution. Martin is right that we really do want the tests to run to catch any real bugs (on our side). -- 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] Backport troubles with mercurial
On 12/30/2010 4:44 PM, Georg Brandl wrote: But you can't use Mercurial's merge functionality for that, right? You have to use some kind of transplant/cherry-picking to merge from the 3.3 branch to the 3.2 branch, right? Oh, I wrote the above assuming 3.2-3.3 merging. For the other direction you need cherry-picking, yes. I have the impression that Benjamin plans to continue 3.1 bug maintenance for months after 3.2 final rather than issue the last bug fix the traditional 1 week after. That would make the sequence 3.1-3.2-3.3 or 3.1-3.2-3.3 or ... . The transition would be a lot easier, I think, if 3.1.4 was released along with 3.2, so most of us would never have to bother with 3.1 and hg together. -- 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] r87603 - python/branches/py3k/Misc/NEWS
On 1/1/2011 5:07 AM, georg.brandl wrote: Author: georg.brandl Date: Sat Jan 1 11:07:30 2011 New Revision: 87603 Log: Fix issue references. (add '#' to issue numbers). Whoops, two of those are mine. I am still learning and will try to remember to include it in both log messages and NEWS entries. Terry ___ 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] Possible optimization for LOAD_FAST ?
On 1/2/2011 10:18 PM, Guido van Rossum wrote:
My proposed way out of this conundrum has been to change the language
semantics slightly so that global names which (a) coincide with a
builtin, and (b) have no explicit assignment to them in the current
module, would be fair game for such optimizations, with the
understanding that the presence of e.g. len = len anywhere in the
module (even in dead code!) would be sufficient to disable the
optimization.
I believe this amounts to saying
1) Python code executes in three scopes (rather than two): global
builtin, modular (misleadingly call global), and local. This much is a
possible viewpoint today.
2) A name that is not an assignment target anywhere -- and that matches
a builtin name -- is treated as a builtin. This is the new part, and it
amounts to a rule for entire modules that is much like the current rule
for separating local and global names within a function. The difference
from the global/local rule would be that unassigned non-builtin names
would be left to runtime resolution in globals.
It would seem that this new rule would simplify the lookup of module
('global') names since if xxx in not in globals, there is no need to
look in builtins. This is assuming that following 'len=len' with 'del
len' cannot 'unmodularize' the name.
For the rule to work 'retroactively' within a module as it does within
functions would require a similar preliminary pass. So it could not work
interactively. Should batch mode main modules work the same as when
imported?
Interactive mode could work as it does at present or with slight
modification, which would be that builtin names within functions, if not
yet overriden, also get resolved when the function is compiled.
--
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] Possible optimization for LOAD_FAST ?
On 1/4/2011 6:39 PM, Guido van Rossum wrote: So, that significantly weakens the argument that this optimization will break unit tests, since I am happy to promise never to optimize these builtins, and any other builtins intended for I/O. This is one comprehensible rule rather than a list of exceptions, so easier to remember. It has two rationales: such often need to be over-riden for testing, possibly in hidden ways; such are inherently 'slow' so optimizing dict lookup away hardly makes sense. -- 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] devguide: Strip out all generic svn instructions from the FAQ. It's not only
On 1/5/2011 1:18 AM, Eli Bendersky wrote: On Wed, Jan 5, 2011 at 04:13, Nick Coghlan ncogh...@gmail.com Your call as the author, but please reconsider this one. I've found it *hugely* convenient over the years to have these task oriented answers in the FAQ. The problem with the answers all over the internet is that I (or someone new to our source control tool) may not know enough to ask the right question, and hence those answers may as well not exist. Even if these FAQ answers don't always provide everything needed, they usually provide enough information to let me search for the full answers. I agree with Nick here. I also found these instructions useful in the past, although I'm quite familiar with SVN. New devs interested in contributing to Python but not too familiar with the source-control tool it's using at the time will benefit even more from this. As for maintenance nightmare, I'm sure it's simple enough to attract contributors. For example, I can volunteer to maintain it. As a complete neophyte at actually using a source code system, I found the stripped-down step-by-step instructions useful even though I am using TortoiseSVN. Even the TortoiseSVN help doc is a bit overwhelming because it includes so much that I do not need to read. It would be a bit like a beginning programmer trying to learn Python from the Langauge Reference without having the Tutorial to read. (And even as an experienced C programmer, I started with the latter.) -- 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] r87768 - in python/branches/py3k: Lib/socket.py Lib/test/test_socket.py Misc/NEWS
Issue #7995: When calling accept() on a socket with a timeout, the returned socket is now always non-blocking, regardless of the operating system. Seems clear enough +# Issue #7995: if no default timeout is set and the listening +# socket had a (non-zero) timeout, force the new socket in blocking +# mode to override platform-specific socket flags inheritance. Slightly confusing +# Issue #7995: when calling accept() on a listening socket with a +# timeout, the resulting socket should not be non-blocking. Seems to contradict the first. 'sould not be non-blocking' to me means 'should be blocking', as opposed to 'is now ... non-blocking'. Terry ___ 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] devguide: Start a doc on running and writing unit tests.
+The shortest, simplest way of running the test suite is:: + +./python -m test Not on Windows. C:\Programs\Python32./python -m test '.' is not recognized as an internal or external command, operable program or batch file. python -m test works (until it failed, separate issue). I would like to know, insofar as possible, how to run tests from the interpreter prompt (or IDLE simulation thereof) from whatmod import whatfunc; whatfunc() # ?? ditto for such remaining alternatives you give as can be made from prompt. Besides the convenience for Windows users (for whom the Command Prompt window is hidden away and possibly unknown), I think we should know if any tests are incompatible with interactive mode. --- 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] devguide: Start a doc on running and writing unit tests.
+Running +--- Is there a way to skip a particular test, such as one that crashes the test process? Terry ___ 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] 3.2b2 fails test suite on (my) Windows XP
To test Brett's test running instruction, I ran python -m test # not ./Python! in a Command Prompt window --- Microsoft Windows XP [Version 5.1.2600] == CPython 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] == Windows-XP-5.1.2600-SP3 little-endian == c:\docume~1\terry\locals~1\temp\test_python_3528 [ 1/351] test_grammar ... [ 10/351] test___all__ Warning -- os.environ was modified by test___all__ [ 11/351] test___future__ ... [ 37/351] test_capi Window hangs, can only close. Error popup says python.exe has encountered a problem... at 000a03f7 in python32.dll RUN 2, same command, I get [ 37/351] test_capi test test_capi failed -- Traceback (most recent call last): File C:\Programs\Python32\lib\test\test_capi.py, line 50, in test_no_FatalEr ror_infinite_loop b'Fatal Python error:' AssertionError: bFatal Python error: PyThreadState_Get: no current thread\r\n\r \nThis application has requested the Runtime to terminate it in an unusual way.\ nPlease contact the application's support team for more information. != b'Fatal Python error: PyThreadState_Get: no current thread' and it continued on with test_cfgparser, etc, so crashing rather than mere failure is intermitant. BUT process then stopped (hung, no error popup) at [ 67/351] test_concurrent_futures Traceback (most recent call last): File string, line 1, in module File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369, in main prepare(preparation_data) File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477, in prepa re assert main_name not in sys.modules, main_name AssertionError: __main__ RUN 3 python -m test -x test_capi test_concurrent_futures went further, more failed tests, then process started repeatedly (hundred of times) outputting assert main_name not in sys.modules, main_name AssertionError: __main__ Traceback (most recent call last): File string, line 1, in module File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369, in main prepare(preparation_data) File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477, Occasionally a new test would start in between this stuff. It ended with test_sax. I cannot say when it began because the volume overfilled the output buffer. [306/349] test_ttk_guionly # and test_tk test_ttk_guionly skipped -- ttk not available: Can't find a usable init.tcl in t he following directories: C:/Programs/Python32/lib/tcl8.5 C:/Programs/lib/tcl8.5 C:/lib/tcl8.5 C:/Prog rams/library C:/library C:/tcl8.5.9/library C:/tcl8.5.9/library This probably means that Tcl wasn't installed properly. Funny, IDLE works fine. In any case, I did a standard install from the distributed installer. Something is definitely not ready for final release. The final mishmash: [349/349] test_zlib 295 tests OK. 11 tests failed: test_datetime test_difflib.bak test_ftplib test_lib2to3 test_multiprocessing test_os.bak test_pep277 test_pkgutil test_posixpath test_runpy test_tcl 2 tests altered the execution environment: test___all__ test_site 41 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue test_largefile test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_smtpnet test_socketserver test_syslog test_threadsignals test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net test_zipfile64 4 skips unexpected on win32: test_gdb test_readline test_tk test_ttk_guionly Traceback (most recent call last): File C:\Programs\Python32\lib\test\support.py, line 468, in temp_cwd yield os.getcwd() File C:\Programs\Python32\lib\test\__main__.py, line 13, in module regrtest.main() File C:\Programs\Python32\lib\test\regrtest.py, line 704, in main sys.exit(len(bad) 0 or interrupted) SystemExit: True During handling of the above exception, another exception occurred: Traceback (most recent call last): File C:\Programs\Python32\lib\runpy.py, line 160, in _run_module_as_main __main__, fname, loader, pkg_name) File C:\Programs\Python32\lib\runpy.py, line 73, in _run_code exec(code, run_globals) File C:\Programs\Python32\lib\test\__main__.py, line 13, in module regrtest.main() File C:\Programs\Python32\lib\contextlib.py, line 46, in __exit__ self.gen.throw(type, value, traceback) File C:\Programs\Python32\lib\test\support.py, line 472, in temp_cwd rmtree(name) File C:\Programs\Python32\lib\test\support.py, line 198, in rmtree shutil.rmtree(path) File C:\Programs\Python32\lib\shutil.py, line 287, in rmtree onerror(os.rmdir, path, sys.exc_info()) File C:\Programs\Python32\lib\shutil.py, line 285, in rmtree
Re: [Python-Dev] [Python-checkins] devguide: Start a doc on running and writing unit tests.
On 1/5/2011 5:57 PM, Antoine Pitrou wrote: On Wed, 05 Jan 2011 17:43:32 -0500 Terry Reedytjre...@udel.edu wrote: Not on Windows. C:\Programs\Python32./python -m test Installation, not checkout. '.' is not recognized as an internal or external command, operable program or batch file. python -m test works (until it failed, separate issue). This will not run the right interpreter, unless this is an installed build. It is, from 32b2.msi. I have no compiler ;-). -- 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] r87768 - in python/branches/py3k: Lib/socket.py Lib/test/test_socket.py Misc/NEWS
On 1/5/2011 5:43 PM, Antoine Pitrou wrote: On Wed, 05 Jan 2011 17:21:23 -0500 Terry Reedytjre...@udel.edu wrote: Thank you for spotting the contradiction; this is now fixed. I am following your example of looking at checkins. -- 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] 3.2b2 fails test suite on (my) Windows XP
On 1/5/2011 8:59 PM, Nick Coghlan wrote:
On Thu, Jan 6, 2011 at 9:47 AM, Terry Reedytjre...@udel.edu wrote:
To test Brett's test running instruction, I ran
python -m test # not ./Python!
in a Command Prompt window
Does it behave itself if you add -x test_capi to the command line?
No, it gets worse. Really.
Let me summarize a long post.
Run 1: normal (as above)
Process stops at capi test with Windows error message.
Close command prompt window with [x] buttom (crtl-whatever had no effect).
Run 2: normal (as before)
Process reported capi test failure (supposedly fatal) but continued.
Process just stopped ('hung') at concurrent futures. Close as before.
Run 3: -x test_capi test_concurrent_futures
Instead of the normal output I expected, I got some of the craziest
stuff I have ever seen. Things like
assert main_name not in sys.modules, main_name
AssertionError: __main__
Traceback (most recent call last):
File string, line 1, in module
File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369,
in main
prepare(preparation_data)
File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477,
were printed 100s of times intermixed with the normal sequential test
startup lines. They stopped after text_sax started and output became
normal through the end of the report.
295 tests OK.
11 tests failed:
test_datetime test_difflib.bak test_ftplib test_lib2to3
test_multiprocessing test_os.bak test_pep277 test_pkgutil
test_posixpath test_runpy test_tcl
2 tests altered the execution environment:
test___all__ test_site
41 tests skipped:
[snip]
4 skips unexpected on win32:
test_gdb test_readline test_tk test_ttk_guionly
(It previously said it could not find tk (or ttk), even though IDLE does
just fine.)
Then chained error craziness during shutdown: SystemExit, WindowsError,
AttributeError, EOFError (details in original post).
I forgot to mention before that test_ftplib runs into Windows security
and pops up a window (which I closed).
If I did not know better, I might have thought python to be a buggy
piece of junk, but my well-tested package-in-progress runs fine (from
IDLE edit window) in 3.2b2, unchanged from 3.1. I think fixing test
regressions should happen before a 'release candidate'.
On same machine (again, installed from Martin's .msi)
C:\Programs\Python31python -m test.regrtest
seems to run 'normally' (same security popup), no craziness (except for
blocked ftplib test), with results
298 tests OK.
3 tests failed:
test_ftplib test_lib2to3 test_tcl
39 tests skipped:
[snip]
2 skips unexpected on win32:
test_tk test_ttk_guionly
test_tcl had multiple errors, tk,ttk skips are from not finding usable
init.tcl
Similar result with 2.7 with addition of test_distutils failure and
'unexpected skips' of test_gbd and test_readline (but I presume these
really should be expected).
--
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] 3.2b2 fails test suite on (my) Windows XP
On 1/6/2011 11:54 PM, Nick Coghlan wrote:
On Thu, Jan 6, 2011 at 4:00 PM, Terry Reedytjre...@udel.edu wrote:
Does it behave itself if you add -x test_capi to the command line?
No, it gets worse. Really.
Let me summarize a long post.
Run 1: normal (as above)
Process stops at capi test with Windows error message.
Close command prompt window with [x] buttom (crtl-whatever had no effect).
Run 2: normal (as before)
Process reported capi test failure (supposedly fatal) but continued.
Process just stopped ('hung') at concurrent futures. Close as before.
Run 3: -x test_capi test_concurrent_futures
Instead of the normal output I expected, I got some of the craziest stuff I
have ever seen. Things like
Does it all go back to normal if you use python -m test.regrtest
instead? Antoine discovered that multiprocessing on Windows gets
thoroughly confused if __file__ in the main module ends with
__main__.py (see http://bugs.python.org/issue10845)
Yes. As I reported on the issue, only 'normal' test failure output.
Later, I will try to see if there are already issues for all of them.
--
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] Add sendfile() to core?
On 1/8/2011 2:55 AM, max ulidtko wrote: On Wed, 20 Mar 2002 14:53:58 -0500, Andrew Kuchling wrote: | sendfile() is used when writing really high-performance Web servers, | in order to save an unnecessary memory-to-memory copy. Question: | should I make up a patch to add a sendfile() wrapper to Python? There is no issue on the tracker and he apparently never did. There is a general policy of lightly wrapping useful os calls in os. Martin said this already in what was essentially a 'go ahead'. Problems include os differences, The only difficulty I can see is the choice of name for the wrapper. IMO, using sendfile from Linux and FreeBSD is pretty much okay; but objections may arise. [1] http://mail.python.org/pipermail/python-dev/2002-March/021543.html such as name differences (but I think *nix generally wins ;-), and the need for 'someone' to write the patches for the appropriate C-coded os files: posix, nt, os2, ce. Patch write makes initial decision on ironing out differences. The above was the second and last substantive answer to Andrew, as there was nothing much more to say. The tracker awaits ;-). Specify, if you can, whether you think the windows TransmitFile or modern equivalent is sufficiently compatible with the *nix sendfile to be wrapped with the same API or whether you propose Availability: Unix only. -- 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] r88032 - in python/branches/py3k/Doc: c-api/code.rst howto/logging-cookbook.rst howto/logging.rst library/2to3.rst library/importlib.rst library/stdtypes.rst library
On 1/15/2011 12:03 PM, georg.brandl wrote: Fix a few doc errors, mostly undefined keywords. I am not sure what you mean by 'undefined keyword', but -integer. If there is no source code, return :keyword:`None`. If the +integer. If there is no source code, return ``None``. If the [etc] you have seem to have systematically removed the :keyword: role from None, False, and True. Since Language Reference 2.3.1 Keywords defines them as keywords, the entry keyword The name of a keyword in Python. in 4.5. Inline markup, Additional Markup Constructs, should specify except for None, False, or True, which should just be marked as code literal ``None``, etc.. Or perhaps The name of a statement keyword (other than None, False, or True) in Python. If your rule is even more nuanced (only sometimes make an exception), please elucidate. --- 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] I want my sugar...
On 1/16/2011 12:44 PM, Peter Hall wrote: I am a newbie to python, and am curious why the following syntax is not supported: This list is for development of future releases. Please ask such questions on python-list or other forums for discussion of current Python. -- 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] Import and unicode: part two
On 1/19/2011 7:34 AM, Victor Stinner wrote: Hi, I patched Python 3.2 to support modules with non-ASCII paths (*). It works well on all operating systems. But the task is not completly done: (a) Python 3 doesn't support non-ASCII module names (b) Python 3 doesn't support unencodable characters in the module path I would like to know if we need to support that. Terry J. Reedy wrote (issue #10828): I think bugs in core syntax should have high priority. I appreciate your work toward fixing it. I am a little shocked at the so-far tepid response to (a), so let me defend and explain my claim that it is a bug. In the simplest case (from 6.11. The import statement and 2.3. Identifiers and keywords) import_stmt ::= import module module ::= indentifier identifier ::= appropriate Unicode start and continue chars There is nothing, nothing, about any restriction on identifiers. The rest of 6.11 discusses the complex import algorithm but leaves out the simple semantics that cover 99% of cases (import a ???.py file in a directory on sys.path), and never mentions .py. So lets go to Tutorial 6. Modules which does explain the simple case: A module is a file containing Python definitions and statements. The file name is the module name with the suffix .py appended. So, if xyz is a legal identifier and xyx.py exists on sys.path, it is reasonable from the docs to expect 'import xyz' to work. (Sys.path is memtioned in the reference.) But we now have the following possibility: Let xyz.py be def double(x): return 2*x if __name__==__main__: if double(2) == 4: print(test passed) We run the file, get test passed, and write zyx.py: import xyz ... We run zyx and Python says No module named xyz. Bad, and quite puzzling to anyone who does not understand the subtle difference between running and importing a file. -- 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] devguide: Cover how to (un-)apply a patch.
On 1/19/2011 1:25 PM, Brett Cannon wrote: On Wed, Jan 19, 2011 at 10:10,s...@pobox.com wrote: Antoine Ok, thank you but... are you suggesting something or not? Yes. Keep the vcs command recommendations simple. At least mention idioms which likely to apply across a wider range of version control systems. I was hoping this would flame out, but two days of discussion suggests otherwise. I am of the opinion of always listing how to use the CVS to its fullest. It is the thing you will have to interact with the most when doing work on Python, so trying to avoid it is not doing anyone any favours. That being said, I am not opposed to someone (other than me as I am not going to bother) **adding** a not about `patch -R`, but it should not replace the `svn revert` explanation. As a neophyte vcs user, I like specific commands that can only do what I want, and not screw up with a wrong flag, so I agree with this. The most important thing is being clear about which data will have which effect on which other data. -- 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] Import and unicode: part two
On 1/19/2011 4:05 PM, Simon Cross wrote: I have no problem with non-ASCII module identifiers being valid syntax. It's a question of whether attempting to translate a non-ASCII If the names are the same, ie, produced with the same sequence of keystrokes in the save-as box and importing box, then there is no translation, at least from the user's view. module name into a file name (so the file can be imported) is a good idea and whether these sorts of files can be safely transferred among diverse filesystems. I believe we now have the situation that a package that works on *nix could fail on Windows, whereas I believe that patch would *improve* portability. For similar reasons we tend to avoid capital letters in module names. That is a stdlib style guide followed by many, but intentionally not enforced. -- 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] Import and unicode: part two
On 1/19/2011 6:44 PM, Toshio Kuratomi wrote: I believe we now have the situation that a package that works on *nix could fail on Windows, whereas I believe that patch would *improve* portability. I'm not so sure about this Forget that claim if it is not true. The patch will certainly improve consistency with a box so that files that run can also be imported. -- 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] Import and unicode: part two
On 1/19/2011 6:05 PM, Alexander Belopolsky wrote: On Wed, Jan 19, 2011 at 5:47 PM, Brett Cannonbr...@python.org wrote: .. Indeed. Last time I looked, we still had cProfile in stdlib. Yes, but that is because no one got around to hiding cProfile behind profile before we released Python 3.0. I would still like to see it (slowly) go away from being directly visible. Another big offender is the idlelib package. Most of the modules there are in mixed case. Given that the individual modules are not documented and that the only programs importing the individual modules are other idlelib modules (true?) then a rename should be possible. In the other hand, the same facts sort of make it unnecessary ;-). -- 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] Import and unicode: part two
On 1/20/2011 12:44 PM, Toshio Kuratomi wrote: The problem occurs in that the code that one of the parties develops (either the students or the professors) is developed on one of those OS's and then used on the other OS. The problem that I reported and hope will be fixed is that private code written and tested on one machine, which will never be distributed, could not be imported on the *same* machine, with nothing changed on that machine except for writing a second file that does the import. If filenames get mangled when file are transported (admittedly more likely with non-ascii chars), that is a different issue. -- 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] web framework for py3k
On 1/22/2011 1:16 PM, yeswanth wrote: In general, this list is for development of Python, CPython, and its stdlib, not 3rd party modules. I would want to help porting some web framework for py3k .. The target of any such efforts should be 3.2 as it has changes intended to help web programming. I want to know to know which one is good and which can be ported easily Opinions will depend on the person. Such questions might be better asked on Python list or the specialized web-sig list, where there are more people involved with web frameworks. Most frameworks have their own lists. Some can be accessed as newsgroups at news.gmane.org in the gmane.comp.python hierarchy. -- 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
[Python-Dev] What's new 2.x in 3.x docs.
The 3.x docs mostly started fresh with 3.0. The major exception is the What's new section, which goes back to 2.0. The 2.x stuff comprises about 650KB in the repository and whatever that translates into in the distribution. I cannot imagine that anyone who only has 3.x and no 2.x version would have any interest in the 2.x history. And of course, the complete 2.x history will always be available with the latest 2.7.z. And the cover page for 3.x could even say so and include a link. So why not remove it from the 3.2 release (and have two separate pages for the online version)? -- 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] What's new 2.x in 3.x docs.
On 1/22/2011 2:20 PM, Antoine Pitrou wrote: On Sat, 22 Jan 2011 14:04:00 -0500 Terry Reedytjre...@udel.edu wrote: The 3.x docs mostly started fresh with 3.0. The major exception is the What's new section, which goes back to 2.0. The 2.x stuff comprises about 650KB in the repository and whatever that translates into in the distribution. I cannot imagine that anyone who only has 3.x and no 2.x version would have any interest in the 2.x history. And of course, the complete 2.x history will always be available with the latest 2.7.z. And the cover page for 3.x could even say so and include a link. So why not remove it from the 3.2 release (and have two separate pages for the online version)? Well, is there any point in doing so, apart from saving 650KB in the repository? I'm not sure we care about the latter (right now the whole source tree is more than 50MB, and that's without version control information). I was only proposing actual removal of what to me is noise from the windows help file (now 5.6 mb) with a link to the online version. But the idea is rejected. Fini. -- 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] r88147 - in python/branches/py3k: Misc/NEWS Modules/_pickle.c Tools/scripts/find_recursionlimit.py
On 1/23/2011 1:58 PM, Antoine Pitrou wrote: Issue #10987: Fix the recursion limit handling in the _pickle module. 12 hours after the report! I am still curious why a previous exception changed pickle behavior, and only in 3.2, but I would rather you fix another bug than speeding much time to get me up to speed on the intricacies of _pickle ;-). -- 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] Keeping __init__.py empty for Python packages used for module grouping.
On 1/24/2011 2:18 PM, Georg Brandl wrote: Am 24.01.2011 20:04, schrieb Raymond Hettinger: Looking at http://docs.python.org/dev/library/html.html#module-html it would appear that we've created a new module with a single trivial function. In reality, there was already a python package, html, that served to group two loosely related modules, html.parser and html.entities. ISTM, that if we're going to use python packages as namespace containers for categorizing modules, then the top level __init__ namespace should be left empty. Before the placement of html.escape() becomes set in stone, I think we should consider putting it somewhere else. To be honest, I don't see the issue. I don't see stdlib packages as namespace containers, but rather as a nice way of structuring functionality. And remember that flat is better than nested -- why should escape() be put away into a new submodule? At least you'll need to let us know where you would rather put that function. I would put in html.entities, which is also sparse, as it seems to me vaguely related. -- 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] Byte code arguments from two to one byte: did anyone try this?
On 1/31/2011 5:31 AM, Steven D'Aprano wrote: Jurjen N.E. Bos wrote: I was impressed by the optimizations already in there, but I still dare to suggest an optimization that from my estimates might shave off a few cycles, speeding up Python about 5%. The idea is simple: change the byte code argument values from two bytes to one. Interesting. Have you seem Cesare Di Mauro's WPython project, which takes the opposite strategy? http://code.google.com/p/wpython2/ The two strategies could be mixed. Some 'word codes' could consist of a bytecode + byte arg, and others a real word code. Maybe WPython does that already. Might end up being slower though. -- 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 3.2 (fwd)
On 2/9/2011 12:32 PM, s...@pobox.com wrote: Passing this along from webmaster. It is hard to reply to an attachment rather than inline forwarded message. However, with rc1 import sqlite3 sqlite3.version '2.6.0' sqlite3.sqlite_version '3.7.4' I added 'pysqlite' to the What's new entry. -- 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] devguide: More clarifications: use the term 'working copy' and mention 'hg update'.
On 2/9/2011 3:29 PM, Antoine Pitrou wrote: Why talk about checkout at all? It's an SVN/CVS/RCS term, if I'm not mistaken (even though it may occasionally be used with hg, it's a synonym of working copy there). I believe it harkens back to early source code control systems where one person literally 'checked out' a file and got a write lock on it, similar to checking out a particular volume from the library )except that others could still read, unlike with the library). yes. good riddance (already done). -- 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] API bloat
On 2/11/2011 4:29 AM, Mark Shannon wrote: Nick Coghlan wrote: Now that the issue has been brought up, it can certainly be taken into consideration for 3.3. The idea of defining a Py_PORTABLE_API that is even more restrictive than PEP 384 (e.g. eliminating lots of old cruft that is a legacy of CPython's long history of development when it was the *only* viable Python implementation) may also be worth exploring. Absolutely. I intend to do just that. I think we should try to have deprecations and removals in the codebase by the first alpha release for maximal testing. GP's asyncore changes inspired this thought, but I would apply it generally. -- 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] API bloat
On 2/11/2011 1:35 PM, Benjamin Peterson wrote: 2011/2/11 Antoine Pitrousolip...@pitrou.net: On Fri, 11 Feb 2011 13:16:12 -0500 Terry Reedytjre...@udel.edu wrote: On 2/11/2011 4:29 AM, Mark Shannon wrote: Nick Coghlan wrote: Now that the issue has been brought up, it can certainly be taken into consideration for 3.3. The idea of defining a Py_PORTABLE_API that is even more restrictive than PEP 384 (e.g. eliminating lots of old cruft that is a legacy of CPython's long history of development when it was the *only* viable Python implementation) may also be worth exploring. Absolutely. I intend to do just that. I think we should try to have deprecations and removals in the codebase by the first alpha release for maximal testing. My next sentence [snipped] was GP's asyncore changes inspired this thought, but I would apply it generally. Why would we deprecate or remove anything? Are some functions useless? Shannon thinks so. I am specifically suggesting that he make any removal suggestion well before the alpha release. I think he's referring to deprecations and removals in general. Yes, as I said. I am also thinking about 3.2 deprecations that will become 3.3 removals. That includes one that I am responsible for. -- 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] Rights on the tracker
On 2/13/2011 9:47 AM, Alexis Métaireau wrote: Tarek co-opts this. Do you meant that Tarek supports or approves of this? (Co-opt means something rather different in English.) -- 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] r88395 - python/branches/py3k/Lib/asyncore.py
On 2/13/2011 5:23 PM, Nick Coghlan wrote: On Mon, Feb 14, 2011 at 8:11 AM,exar...@twistedmatrix.com wrote: Excluding stuff is not hard, seriously. It's not hard to see that wxPython integration doesn't belong in the stdlib. There are more useful aspects of the task to discuss. I think part of the problem is that those of us that aren't Twisted users aren't familiar enough with it to know which of the elements in twisted.internet would be important to include in a stdlib reactor package (or whatever it ended up being called). To me, this is what a PEP would be for -- to present a concrete proposal listing inclusions that could be evaluated. The someone familiar with asyncore could compare feature lists to decide if the new module would have everything needed without too much other stuff. -- 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
[Python-Dev] 3.2.0
I would like the next release called 3.2.0 rather than just 3.2. 'x.y' is known to be ambiguous and confusing. In most actual usages, I believe, it refers to the latest x.y.z release. On the site, the 'x.y' docs are almost always the latest version of the docs (actually x.y.z+additional fixes). In discussions on python-list, for instance, advice to use 'x.y' means to download and use the latest x.y.z release, not the initial x.y(.0) release. Similarly on the tracker, 'what happens with x.y' means the same. So the alternate use of 'x.y' to mean x.y(.0) is both confusing and correctable, at least for the future. -- 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] 3.2.0
On 2/16/2011 5:39 PM, Nick Coghlan wrote: On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsawba...@python.org wrote: On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote: I would like the next release called 3.2.0 rather than just 3.2. +1 (I'd have said +0 for the humor of it :). +0 I actually *am* only +0, since I like the idea in principle, but it is Georg, Ronald and Martin that would need to do the work, and I'm not sure it's a great idea to be messing with it a couple of days out from the release. So it may be better to do this for 3.3.0, rather than 3.2.0. My immediate suggestion is predicated on the assumption that it would be easy and safe to change '3.2rc2' in the various places it appears to '3.2.0' instead of '3.2'. If that is not true, then my suggestion is that after 3.2 is released, that trunk be regarded as 3.3.0a0 rather than 3.3a0 as soon as it make any difference anywhere. -- 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] 3.2.0
On 2/17/2011 1:36 AM, Senthil Kumaran wrote: On Thu, Feb 17, 2011 at 1:34 AM, Terry Reedytjre...@udel.edu wrote: 'x.y' is known to be ambiguous and confusing. Not really. Actually, to me, the confusion is slightly worse, and the reason to change slightly stronger, than I initially explained. Python x.y is a version of the *language*. CPython x.y.z is an occasional marked release of an *implementation*. For instance, Python 3.2 is a version of the language and stdlib. It has been pretty well defined since new features were prohibited. The 3.2 docs are the specification of Python 3.2 (with a few CPython-specific notes). The 3.2 docs will be continuously upgraded as deficiencies are noted and fixed. As I understand it, all patches are expected to leave the docs in an improved and buildable state, so that updates can be built and uploaded to the site frequently (daily?). CPython 3.2.0 will be the first 'production' release of the CPython implementation of Python 3.2. It will be one in a series of approximation of an ideal bug-free 'CPython 3.2'. Some have already been released, more will come. Like the docs, the concrete CPython 3.2 codebase will also be continuously upgraded. For various reasons, it will probably not always be buildable on all platforms and not always be production ready. For practical reasons, marked releases will be spaced some months apart. So, for me, Python 3.2 is a now theoritically fixed version of the language. The Python 3.2 docs document that version, but will be upgraded as mistaked, ambiguities, and omissions are found. The CPython 3.2 codebase is an evolving approximation of an ideal bug-free CPython 3.2 (that will never be reached). And CPython 3.2.0 is an early snapshot release of that evolving codebase. -- 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
