Re: [Python-Dev] svn.python.org confusion
On Wed, Jun 29, 2011 at 03:05, Vinay Sajip wrote: > Ned Deily acm.org> writes: > >> Could some text be added to the svn browser pages to at least indicate >> that the repo is no longer being updated with a link to the >> hg.python.org browser? I'm not sure what to do about the repos >> themselves if people attempt to do an svn co. Perhaps that should just >> be disabled totally for python? > > At least some of the stuff in the SVN repo is still needed, AFAICT. I recently > did a build of the Python Windows binary installer, and I understand (from the > buildbot instructions) that the best source of some of the external > dependencies > (bz2, Tcl/Tk, openssl etc.) is still the SVN repo. SVN is also used to fetch third-party tools to build documentation, such as: sphinx, docutils, jinja, and pygments. These locations are also advertised on http://docs.python.org/py3k/documenting/building.html (that contains outdated info, but that's another story). Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] open(): set the default encoding to 'utf-8' in Python 3.3?
Le 28/06/2011 16:46, Paul Moore a écrit :
-1. This will make things harder for simple scripts which are not
intended to be cross-platform.
+1 to all you said.
I frequently use the python command prompt or "python -c" for various quick
tasks (mostly on linux). I would hate to replace my ugly, but working
>>> open('example.txt').read()
with the unnecessarily verbose
>>> open('example.txt',encoding='utf-8').read()
When using python that way as a "swiss army knife", typing does matter.
My preferred solution would be:
- emit a warning if the encoding argument is not set
By the way, I just thought that for real programming, I would love to have a
-Wcrossplatform command switch, which would warn for all unportable constructs
in one go. That way, I don't have to remember which parts of 'os' wrap
posix-only functionnality.
Baptiste
___
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] open(): set the default encoding to 'utf-8' in Python 3.3?
On Jun 28, 2011, at 09:42 PM, Georg Brandl wrote: >We need to stop making incompatible changes to Python 3. We had the chance >and took it to break all kinds of stuff, some of it gratuitous, with 3.0 and >even 3.1. Now the users need a period of compatibility and stability (just >like the language moratorium provided for one aspect of Python). +1. I think this is the #1 complaint I hear about Python in talking to users. I think in general we do a pretty good job of maintaining backward compatibility between releases, but not a perfect job, and the places where we miss can be painful for folks. It may be difficult to achieve in all cases, but compatibility should be carefully and thoroughly considered for all changes, especially in the stdlib, and clearly documented where deliberate decisions to break that are adopted. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] open(): set the default encoding to 'utf-8' in Python 3.3?
Victor Stinner wrote: > Le mardi 28 juin 2011 à 16:02 +0200, M.-A. Lemburg a écrit : >> How about a more radical change: have open() in Py3 default to >> opening the file in binary mode, if no encoding is given (even >> if the mode doesn't include 'b') ? > > I tried your suggested change: Python doesn't start. No surprise there: it's an incompatible change, but one that undoes a wart introduced in the Py3 transition. Guessing encodings should be avoided whenever possible. > sysconfig uses the implicit locale encoding to read sysconfig.cfg, the > Makefile and pyconfig.h. I think that it is correct to use the locale > encoding for Makefile and pyconfig.h, but maybe not for sysconfig.cfg. > > Python require more changes just to run "make". I was able to run "make" > by using encoding='utf-8' in various functions (of distutils and > setup.py). I didn't try the test suite, I expect too many failures. This demonstrates that Python's stdlib is still not being explicit about the encoding issues. I suppose that things just happen to work because we mostly use ASCII files for configuration and setup. > -- > > Then I tried my suggestion (use "utf-8" by default): Python starts > correctly, I can build it (run "make") and... the full test suite pass > without any change. (I'm testing on Linux, my locale encoding is UTF-8.) I bet it would also with "ascii" in most cases. Which then just means that the Python build process and test suite is not a good test case for choosing a default encoding. Linux is also a poor test candidate for this, since most user setups will use UTF-8 as locale encoding. Windows, OTOH, uses all sorts of code page encodings (usually not UTF-8), so you are likely to hit the real problem cases a lot easier. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 29 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] svn.python.org confusion
In article , Sandro Tosi wrote: > On Wed, Jun 29, 2011 at 03:05, Vinay Sajip wrote: > > Ned Deily acm.org> writes: > >> Could some text be added to the svn browser pages to at least indicate > >> that the repo is no longer being updated with a link to the > >> hg.python.org browser? I'm not sure what to do about the repos > >> themselves if people attempt to do an svn co. Perhaps that should just > >> be disabled totally for python? > > At least some of the stuff in the SVN repo is still needed, AFAICT. I > > recently > > did a build of the Python Windows binary installer, and I understand (from > > the > > buildbot instructions) that the best source of some of the external > > dependencies > > (bz2, Tcl/Tk, openssl etc.) is still the SVN repo. > > SVN is also used to fetch third-party tools to build documentation, > such as: sphinx, docutils, jinja, and pygments. These locations are > also advertised on > http://docs.python.org/py3k/documenting/building.html (that contains > outdated info, but that's another story). Yes, by "for python", I meant the active python development "branches" (py3k->default, 3.2, 2.7). -- Ned Deily, n...@acm.org ___ 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] open(): set the default encoding to 'utf-8' in Python 3.3?
Le mercredi 29 juin 2011 à 10:18 +0200, M.-A. Lemburg a écrit : > Victor Stinner wrote: > > Le mardi 28 juin 2011 à 16:02 +0200, M.-A. Lemburg a écrit : > >> How about a more radical change: have open() in Py3 default to > >> opening the file in binary mode, if no encoding is given (even > >> if the mode doesn't include 'b') ? > > > > I tried your suggested change: Python doesn't start. > > No surprise there: it's an incompatible change, but one that undoes > a wart introduced in the Py3 transition. Guessing encodings should > be avoided whenever possible. It means that all programs written for Python 3.0, 3.1, 3.2 will stop working with the new 3.x version (let say 3.3). Users will have to migrate from Python 2 to Python 3.2, and then migration from Python 3.2 to Python 3.3 :-( I would prefer a ResourceWarning (emited if the encoding is not specified), hidden by default: it doesn't break compatibility, and -Werror gives exactly the same behaviour that you expect. > This demonstrates that Python's stdlib is still not being explicit > about the encoding issues. I suppose that things just happen to work > because we mostly use ASCII files for configuration and setup. I did more tests. I found some mistakes and sometimes the binary mode can be used, but most function really expect the locale encoding (it is the correct encoding to read-write files). I agree that it would be to have an explicit encoding="locale", but make it mandatory is a little bit rude. > > Then I tried my suggestion (use "utf-8" by default): Python starts > > correctly, I can build it (run "make") and... the full test suite pass > > without any change. (I'm testing on Linux, my locale encoding is UTF-8.) > > I bet it would also with "ascii" in most cases. Which then just > means that the Python build process and test suite is not a good > test case for choosing a default encoding. > > Linux is also a poor test candidate for this, since most user setups > will use UTF-8 as locale encoding. Windows, OTOH, uses all sorts of > code page encodings (usually not UTF-8), so you are likely to hit > the real problem cases a lot easier. I also ran the test suite on my patched Python (open uses UTF-8 by default) with ASCII locale encoding (LANG=C), the test suite does also pass. Many tests uses non-ASCII characters, some of them are skipped if the locale encoding is unable to encode the tested text. Victor ___ 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] open(): set the default encoding to 'utf-8' in Python 3.3?
Le mercredi 29 juin 2011 à 09:21 +0200, Baptiste Carvello a écrit : > By the way, I just thought that for real programming, I would love to have a > -Wcrossplatform command switch, which would warn for all unportable > constructs > in one go. That way, I don't have to remember which parts of 'os' wrap > posix-only functionnality. When I developed using PHP, error_reporting(E_ALL) was really useful. I would like a same function on Python, but I realized that it is not necessary. Python is already strict *by default*. Python can help developers to warn them about some "corner cases". We have already the -bb option for bytes/str warnings (in Python 3), -Werror to convert warnings to exceptions, and ResourceWarning (since Python 3.2) for unclosed files/sockets. I "just" would like a new warning for an implicit locale encoding, so -Wcrossplatform would be as easy as -Werror. -Werror is like Perl "use strict;" or PHP error_reporting(E_ALL). Use -Wd if you prefer to display warnings instead of raising exceptions. See issue #11455 and #11470 for a new "CompatibilityWarning", it's not "cross platform" but "cross Python" :-) It warns about implementation details like non strings keys in a type dict. Victor ___ 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] open(): set the default encoding to 'utf-8' in Python 3.3?
Victor Stinner wrote: > Le mercredi 29 juin 2011 à 10:18 +0200, M.-A. Lemburg a écrit : >> Victor Stinner wrote: >>> Le mardi 28 juin 2011 à 16:02 +0200, M.-A. Lemburg a écrit : How about a more radical change: have open() in Py3 default to opening the file in binary mode, if no encoding is given (even if the mode doesn't include 'b') ? >>> >>> I tried your suggested change: Python doesn't start. >> >> No surprise there: it's an incompatible change, but one that undoes >> a wart introduced in the Py3 transition. Guessing encodings should >> be avoided whenever possible. > > It means that all programs written for Python 3.0, 3.1, 3.2 will stop > working with the new 3.x version (let say 3.3). Users will have to > migrate from Python 2 to Python 3.2, and then migration from Python 3.2 > to Python 3.3 :-( I wasn't suggesting doing this for 3.3, but we may want to start the usual feature change process to make the change eventually happen. > I would prefer a ResourceWarning (emited if the encoding is not > specified), hidden by default: it doesn't break compatibility, and > -Werror gives exactly the same behaviour that you expect. ResourceWarning is the wrong type of warning for this. I'd suggest to use a UnicodeWarning or perhaps create a new EncodingWarning instead. >> This demonstrates that Python's stdlib is still not being explicit >> about the encoding issues. I suppose that things just happen to work >> because we mostly use ASCII files for configuration and setup. > > I did more tests. I found some mistakes and sometimes the binary mode > can be used, but most function really expect the locale encoding (it is > the correct encoding to read-write files). I agree that it would be to > have an explicit encoding="locale", but make it mandatory is a little > bit rude. Again: Using a locale based default encoding will not work out in the long run. We've had those discussions many times in the past. I don't think there's anything bad with having the user require to set an encoding if he wants to read text. It makes him/her think twice about the encoding issue, which is good. And, of course, the stdlib should start using this explicit-is-better-than-implicit approach as well. >>> Then I tried my suggestion (use "utf-8" by default): Python starts >>> correctly, I can build it (run "make") and... the full test suite pass >>> without any change. (I'm testing on Linux, my locale encoding is UTF-8.) >> >> I bet it would also with "ascii" in most cases. Which then just >> means that the Python build process and test suite is not a good >> test case for choosing a default encoding. >> >> Linux is also a poor test candidate for this, since most user setups >> will use UTF-8 as locale encoding. Windows, OTOH, uses all sorts of >> code page encodings (usually not UTF-8), so you are likely to hit >> the real problem cases a lot easier. > > I also ran the test suite on my patched Python (open uses UTF-8 by > default) with ASCII locale encoding (LANG=C), the test suite does also > pass. Many tests uses non-ASCII characters, some of them are skipped if > the locale encoding is unable to encode the tested text. Thanks for checking. So the build process and test suite are indeed not suitable test cases for the problem at hand. With just ASCII files to decode, Python will simply never fail to decode the content, regardless of whether you use an ASCII, UTF-8 or some Windows code page as locale encoding. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 29 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] cpython: Issue #12400: fix test_faulthandler if regrtest captures sys.stderr
On Wed, Jun 29, 2011 at 9:43 PM, victor.stinner wrote: > http://hg.python.org/cpython/rev/80c7d63325f6 > changeset: 71065:80c7d63325f6 > user: Victor Stinner > date: Wed Jun 29 13:44:05 2011 +0200 > summary: > Issue #12400: fix test_faulthandler if regrtest captures sys.stderr > > faulthandler.enable() requires that sys.stderr has a fileno() method. Would there be any value in falling back to sys.__stderr__ in the case where sys.stderr has been redirected? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 397 (Python launcher for Windows) reference implementation
PEP 397 (Python launcher for Windows) has a reference implementation in Python. Does anyone know of a C implementation, or is planning/working on one? I realise this is the final objective, so such implementation might be premature, but perhaps someone has been experimenting ... Regards, Vinay Sajip ___ 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] cpython (3.2): Issue #12400: runtest() truncates the StringIO stream before a new test
Le mercredi 29 juin 2011 à 13:05 -0400, Terry Reedy a écrit :
> On 6/29/2011 11:30 AM, victor.stinner wrote:
>
> > summary:
> >Issue #12400: runtest() truncates the StringIO stream before a new test
> >
> > files:
> >Lib/test/regrtest.py | 1 +
> >1 files changed, 1 insertions(+), 0 deletions(-)
> >
> >
> > diff --git a/Lib/test/regrtest.py b/Lib/test/regrtest.py
> > --- a/Lib/test/regrtest.py
> > +++ b/Lib/test/regrtest.py
> > @@ -793,6 +793,7 @@
> > if runtest.stringio is None:
> > runtest.stringio = io.StringIO()
> > stream = runtest.stringio
> > +stream.truncate(0)
>
> You *MUST* seek to 0 to reset the file position, which I presume is your
> intention. 'Resize' does not mean what you probably think is does (and
> what I thought once either ;-).
>
> "truncate(size=None)
> Resize the stream to the given size in bytes (or the current position if
> size is not specified). The current stream position isn’t changed."
>
> >>> s=io.StringIO()
> >>> s.write('abc')
> 3
> >>> s.truncate(0)
> 0
> >>> s.tell()
> 3
> >>> s.write('abc')
> 3
> >>> s.getvalue()
> '\x00\x00\x00abc'
Oh crap. I read _pyio source code and .truncate(0) was looking for the
right method to "reset" a StringIO. I tried .truncate(0) in a terminal,
but the zeros ('\x00') are "hidden". sys.stdout.write("\0") doesn't
print anything in my Linux terminal.
Fixed by commit 450209efe272, thank you.
Victor
___
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] svn.python.org confusion
> Could some text be added to the svn browser pages to at least indicate > that the repo is no longer being updated with a link to the > hg.python.org browser? Adding some text to only some pages (namely those that have been migrated to mercurial) is difficult - so difficult that I won't have time for it within the next 12 months. Contributions are welcome. > I'm not sure what to do about the repos > themselves if people attempt to do an svn co. Perhaps that should just > be disabled totally for python? It would certainly be possible to "svn rm" the trunk directory, if that is any help. Of course, this would also break all URL links into this tree, of which there are still plenty (and they likely won't go away in the years to come). So I would rather check a file into the directory with the name THIS_SUBVERSION_REPOSITORY_HAS_BEEN_MIGRATED_TO_MERCURIAL_DO_NOT_USE_IT_FOR_ANYTHING_BUT_ARCHEOLOGICAL_RESEARCH.txt See also http://python.cvs.sourceforge.net/viewvc/python/python/ http://python.cvs.sourceforge.net/viewvc/python/python/dist/src/ Regards, Martin ___ 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] cpython (2.7): Fixup repr for dict_proxy objects.
Hi, On Thu, Jun 30, 2011 at 2:51 AM, raymond.hettinger < python-check...@python.org> wrote: > http://hg.python.org/cpython/rev/9a0b6c07b488 > changeset: 71086:9a0b6c07b488 > branch: 2.7 > parent: 71055:cdfcd00873cd > user:Raymond Hettinger > date:Thu Jun 30 00:44:36 2011 +0100 > summary: > Fixup repr for dict_proxy objects. > This was already fixed in a slightly different way in 3.x. Unless there's a valid reason to have two different implementations of dict_proxy.__repr__ in 2.x and 3.x, I would suggest to pick the best one and use it on all the branches. See also http://bugs.python.org/issue5587 Best Regards, Ezio Melotti ___ 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] speed.python.org machine online
I've posted a more expansive entry on my blog: http://jessenoller.com/2011/06/29/announcing-the-new-speed-python-org-machine/ But the short version, that as discussed at the VM and language summit, we now have a hosted machine dedicated to the running of cross-interpreter speed tests, etc. The hardware was generously donate by HP and the hosting provided, again, free, by OSU/OSL. DL380 HP DL380G7 X5670 LFF (2U) Dual HP NC382i Dual Port Multifunction Gigabit Server Adapters HP Smart Array P410i/1GB FBWC Controller 4x 4GB (1x4GB) Dual Rank x4 PC3-10600 (DDR3-1333) Registered CAS-9 Memory Kit 2x HP 750W Common Slot Gold Hot Plug Power Supply Kit HP iLO Advanced including 1yr 24x7 Technical Support and Updates Electronic License 4x HP 300GB 6G SAS 15K rpm LFF (3.5-inch) Dual Port Enterprise 3yr Warranty Hard Drive 2 HP DL380 G7 Intel® Xeon® X5680 (3.33GHz/6-core/130W/12MB) FIO Processor Kit With hyperthreading on, the machine has 24 cores, and handily translates pypy using cpython 2.7 in about half the time it typically takes. I am looking forward to handing this over to the team who will be running with the project from here on out - special thanks to Van, Bob Gobeille at HP and the entire OSU/OSL team. jesse ___ 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 397 (Python launcher for Windows) reference implementation
On 30/06/2011 3:00 AM, Vinay Sajip wrote: PEP 397 (Python launcher for Windows) has a reference implementation in Python. Does anyone know of a C implementation, or is planning/working on one? I realise this is the final objective, so such implementation might be premature, but perhaps someone has been experimenting ... Not yet - my last update of the PEP has made the existing reference implementation out-of-date, so I want to work on that before starting on the C version. However, seeing as my note about the most recent PEP update attracted zero comments, I admit I lost any sense of urgency on actually doing this... I'll make an effort to update that reference impl in the next week or so (but obviously anyone else is free to help ;) Cheers, Mark ___ 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] speed.python.org machine online
On Wed, Jun 29, 2011 at 10:05 PM, Jesse Noller wrote: > I've posted a more expansive entry on my blog: > http://jessenoller.com/2011/06/29/announcing-the-new-speed-python-org-machine/ > > But the short version, that as discussed at the VM and language > summit, we now have a hosted machine dedicated to the running of > cross-interpreter speed tests, etc. The hardware was generously donate > by HP and the hosting provided, again, free, by OSU/OSL. > > DL380 HP DL380G7 X5670 LFF (2U) > Dual HP NC382i Dual Port Multifunction Gigabit Server Adapters > HP Smart Array P410i/1GB FBWC Controller > 4x 4GB (1x4GB) Dual Rank x4 PC3-10600 (DDR3-1333) Registered CAS-9 Memory > Kit > 2x HP 750W Common Slot Gold Hot Plug Power Supply Kit > HP iLO Advanced including 1yr 24x7 Technical Support and Updates > Electronic License > 4x HP 300GB 6G SAS 15K rpm LFF (3.5-inch) Dual Port Enterprise 3yr > Warranty Hard Drive > 2 HP DL380 G7 Intel® Xeon® X5680 (3.33GHz/6-core/130W/12MB) FIO Processor > Kit > > With hyperthreading on, the machine has 24 cores, and handily > translates pypy using cpython 2.7 in about half the time it typically > takes. > > I am looking forward to handing this over to the team who will be > running with the project from here on out - special thanks to Van, Bob > Gobeille at HP and the entire OSU/OSL team. > Thanks for the continuing effort, Jesse, Van, and everyone! This is why Python is great and not just good. I can't say thank you enough to all the people that work so hard on tracker issues, documentation, conferences, outreach, infrastructure, and all the pieces that make Python more than just a good idea. Not to discount the effort leading up to the ideas, but the Python community realizes them through the hard work of so many individuals willing to "sacrifice" for something they love. I've been following this list for a year and have not seen much recognition, so it likely goes without saying (or I've just broken an unwritten rule :), but sometimes it needs to be said out loud regardless and sometimes loudly. So thanks everyone! -eric > jesse > ___ > 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/ericsnowcurrently%40gmail.com > ___ 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] cpython (2.7): Fixup repr for dict_proxy objects.
On Jun 30, 2011, at 2:14 AM, Ezio Melotti wrote: > Hi, > > On Thu, Jun 30, 2011 at 2:51 AM, raymond.hettinger > wrote: > Fixup repr for dict_proxy objects. > > > This was already fixed in a slightly different way in 3.x. The %R formatting code is not available in 2.x Raymond___ 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
