There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting. We should really provide
some sort of transition plan. Consider an example from the logging
docs:
logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
We'd like to support both this style as well as the following style:
logging.Formatter("{asctime} - {name} - {levelname} - {message}")
Perhaps we'd eventually deprecate the %-style formatting, but at least
in the intervening time, we'd have to support both. I see a few
possibilities:
* Add a new class, NewFormatter, which uses the {}-style formatting.
This is ugly because it makes the formatting we're trying to encourage
look like the alternative implementation instead of the standard one.
It also means we have to come up with new names for every API that
uses format strings.
* Have Formatter try to guess whether it got %-style formatting or
{}-style formatting, and then delegate to the appropriate one. I don't
know how accurately we can guess. We also end up still relying on both
formatting styles under the hood.
* Have Formatter convert all %-style formatting strings to {}-style
formatting strings (automatically). This still involves some guessing,
and involves some serious hacking to translate from one to the other
(maybe it wouldn't even always be possible?). But at least we'd only
be using {}-style formatting under the hood.
Thoughts?
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
On Mon, Oct 05, 2009 at 10:43:22AM +0200, Fredrik Lundh wrote:
> it's revews like this that makes me wonder if releasing open source is
> a good idea:
> no egg - worst seen ever, remove it from pypi or provide an egg
> (jensens, 2009-10-05, 0 points)
>
Greetings effbot. :)
As you might already know, "eggs" are not mandatory for pypi. No where
in the documentation it mentions so. Also many good packages in pypi
are not eggs (MaL's egenix packages for e.g) and we have known his
dislike for that particular format too.
But still, sometimes people have found eggs to be convenient.
That was a particularly harsh comment from jensens, should be ignored
or he should be corrected that eggs are not mandatory.
But, i have a feeling that this is going to open up the well known,
can-of-worms on what is the best distribution format for python
packages debate.
--
Senthil
No one may kill a man. Not for any purpose. It cannot be condoned.
-- Kirk, "Spock's Brain", stardate 5431.6
At 12:16 PM 10/6/2009 -0700, Guido van Rossum wrote:
>I think at this point the community should not be forced wait for you
>to get a new supply of round tuits. The wait has been too long
>already. You can stay on in an advisory role, but I don't think it's
>reasonable to block development or decisions until you have time.
Tarek didn't think so either, which is why he created a fork, called
Distribute. So I'm not really clear on what you're trying to say
here (or in the rest of the email, for that matter).
Just received:
https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error:
file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
Ned> Due to a change in distutils released with Python 2.6.3, packages
Ned> that use setuptools (version 0.6c9, as of this writing), or the
Ned> easy_install command, to build C extension modules fail ...
...
Ned> Among the packages known to be affected include lxml,
Ned> zope-interface, jinja2, and, hence, packages dependent on these
Ned> packages (e.g. sphinx, twisted, etc.).
Maybe the Python test suite should include tests with a small number of
widely used non-core packages like setuptools. I realize the pybots project
exists to tackle this sort of stuff in greater detail. I'm thinking more of
a smoke test than a comprehensive test suite covering all external packages.
Setuptools is particularly important because so many extension authors use
it. If it breaks it implicitly breaks a lot of PyPI packages.
Skip
>
Thanks to
http://bugs.python.org/issue7077
I've noticed that the socket-based logging handlers - SocketHandler,
DatagramHandler and SysLogHandler - aren't Unicode-aware and can break in the
presence of Unicode messages. I'd like to fix this by giving these handlers an
optional (encoding=None) parameter in their __init__, and then using this to
encode on output. If no encoding is specified, is it best to use
locale.getpreferredencoding(), sys.getdefaultencoding(),
sys.getfilesystemencoding(), 'utf-8' or something else? On my system:
>>> sys.getdefaultencoding()
'ascii'
>>> sys.getfilesystemencoding()
'mbcs'
>>> locale.getpreferredencoding()
'cp1252'
which suggests to me that the locale.getpreferredencoding() should be the
default. However, as I'm not a Unicode maven, any suggestions would be welcome.
Regards,
Vinay Sajip
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson <benjamin(a)python.org> wrote:
> 2009/9/27 Steven Bethard <steven.bethard(a)gmail.com>:
>> The first release where any real deprecation message would show up is
>> Python 3.4, more than 3 years away. If you think 3 years isn't long
>> enough for people to be over the Python 3 transition, let's stick in
>> another version in there and make it 4.5 years.
>
> So, why even bother deprecating it if nobody is going to see the warnings?
I feel like I'm repeating the PEP, but here it is again anyway. There
will be messages in the docs and pending deprecation warnings (which
don't show up by default but can be requested) starting in Python 2.7
and 3.2. Regular deprecation warnings wouldn't show up until Python
3.4, 3 years away. This compromise was intended exactly to address the
issue you brought up about people getting over the Python 3
transition.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
Is it intentional that locals() returns a copy/snapshot of the local
variables sometimes, and sometimes a reference? Like when enabling
tracing, such as in the code pasted below. The documentation ("Update
and return a dictionary containing the current scope's local
variables.") is pretty unclear.
import sys
def X():
l = locals()
i = "foo"
print "Is 'i' in stored locals()? ", ('i' in l)
print "Running normally"
X()
print "Enabling tracing"
def t(*a):
return t
sys.settrace(t)
X()
Dear Pythonistas:
This issue causes serious problems. Users occasionally get binaries built for a
compatible Linux and Python version but with a different UCS2-vs-UCS4 setting,
and those users get mysterious memory corruption errors which are hard to
diagnose. It is possible that these situations also open up security
vulnerabilities. A couple such instances are documented on
http://bugs.python.org/setuptools/issue78, but you can find more by googling.
I would like to get this problem fixed!
In order to help address this issue I sampled what UCS size is used by python
executables in the wild. I instrumented a few buildslaves that are
contributed by
various people to the Tahoe-LAFS project to print out their platform,
python version,
and sys.maxunicode. The full results are appended below. maxunicode: 1114111
means that python executable was configured with --enable-unicode=ucs4, and
maxunicode: 65535 means that python executable was configured with
--enable-unicode=ucs2 or just with --enable-unicode . The only
incompatibilities
that I found are because some packagers have deliberately set UCS4
configuration and other packagers have left the default setting.
In the three cases where someone configured python with UCS2, one of the three
is certainly an accident (a custom-built python executable on an Ubuntu server)
and the other two just use the default instead of specifically configuring ucs2
in their configurations of Python and I suspect that they don't know the
difference and that it was an accident that they built a Python incompatible
with other distributions of their operating system.
In sum, while it would be good to add the unicode setting to the platform's ABI
(as discussed in setuptools ticket #78), it would also be good to make
the default
value be UCS4 instead of UCS2. This would fix all three of the potential
incompatibilities that I found (listed below), and once we have proper inclusion
of the unicode setting in the ABI in order to prevent the memory corruption,
defaulting to UCS4 would increase the likelihood that a binary built on one
distribution would be usable on another.
I'm sure that someone can come up with a reason why UCS2 is better than UCS4,
but I'm also sure that the benefits of compatibility outweigh any benefits of
UCS2 encoding, and that the widespread use of UCS4 demonstrates that there is
nothing fatally wrong with it, and that people who really value UCS2 encoding
more than compatibility can choose that for themselves by explicitly
setting UCS2.
Let me restate that I am not suggesting taking away anyone's options, only
making the setting for people who don't specify default to the
compatible option.
Hm, I guess that means that it should default to UCS2 on Windows and Mac and
to UCS4 on Linux and Solaris.
Regards,
Zooko
Ubuntu 6.10 "edgy" i386: python: 2.4.4c1 (#2, Mar 7 2008, 03:03:38) [GCC 4.1.2
20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)], maxunicode: 1114111
Ubuntu 7.04 "feisty": python: 2.5.1 (r251:54863, Jul 31 2008, 22:53:39) [GCC
4.1.2 (Ubuntu 4.1.2-0ubuntu4)], maxunicode: 1114111
Ubuntu 7.10 "gutsy" i386: python: 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)], maxunicode: 1114111
Ubuntu 8.04 "hardy" amd64: python: 2.5.2 (r252:60911, Jul 22 2009, 15:33:10)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)], maxunicode: 1114111
Ubuntu 8.04 "hardy" i386: *custom* python: 2.6 (r26:66714, Oct 2 2008,
13:40:28) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)], maxunicode: 65535
Ubuntu 8.04 "hardy" i386: python: 2.5.2 (r252:60911, Jul 22 2009, 15:35:03)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)], maxunicode: 1114111
Ubuntu 9.04 "jaunty" amd64: *custom* python: 2.6.2 (release26-maint, Apr 19
2009, 01:58:18) [GCC 4.3.3], maxunicode: 1114111
Debian 4.0 "etch" i386: python: 2.4.4 (#2, Oct 22 2008, 19:52:44) [GCC 4.1.2
20061115 (prerelease) (Debian 4.1.1-21)], maxunicode: 1114111
Debian 5.0 "lenny" i386: python: 2.5.2 (r252:60911, Jan 4 2009, 17:40:26) [GCC
4.3.2], maxunicode: 1114111
Debian 5.0 "lenny" amd64: python: 2.5.2 (r252:60911, Jan 4 2009, 21:59:32)
[GCC 4.3.2], maxunicode: 1114111
Debian 5.0 "lenny" armv5tel: python: 2.5.2 (r252:60911, Jan 5 2009, 02:00:00)
[GCC 4.3.2], maxunicode: 1114111
Debian unstable "squeeze/sid" i386: python: 2.5.4 (r254:67916, Feb 17 2009,
20:16:45) [GCC 4.3.3], maxunicode: 1114111
Fedora 11 "leonidas" amd64: python: 2.6 (r26:66714, Jul 4 2009, 17:37:13) [GCC
4.4.0 20090506 (Red Hat 4.4.0-4)], maxunicode: 1114111
ArchLinux: python: 2.6.2 (r262:71600, Jul 20 2009, 02:23:30) [GCC 4.4.0
20090630 (prerelease)], maxunicode: 65535
NetBSD 4: python: 2.5.2 (r252:60911, Mar 20 2009, 14:00:07) [GCC 4.1.2 20060628
prerelease (NetBSD nb2 20060711)], maxunicode: 65535
OpenSolaris SunOS-5.11-i86pc-i386-32bit: python: 2.4.4 (#1, Mar 10 2009,
09:35:36) [C], maxunicode: 65535
Nexenta NCP1 SunOS-5.11-i86pc-i386-32bit: python: 2.4.3 (#2, May 3 2006,
19:12:42) [GCC 4.0.3 (GNU_OpenSolaris 4.0.3-1nexenta4)], maxunicode: 1114111
Mac OS 10.6 "snow leopard" i386: python: 2.6.1 (r261:67515, Jul 7 2009,
23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)], maxunicode: 65535
Mac OS 10.5 "leopard" i386: python: 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)], maxunicode: 65535
Mac OS 10.4 "tiger" *custom* python: 2.5.4 (release25-maint:72153M, Apr 30 2009,
12:28:20) [GCC 4.0.1 (Apple Computer, Inc. build 5367)], maxunicode: 65535
Cygwin CYGWIN_NT-5.1-1.5.25-0.156-4-2-i686-32bit-WindowsPE: python: 2.5.2
(r252:60911, Dec 2 2008, 09:26:14) [GCC 3.4.4 (cygming special, gdc 0.12,
using dmd 0.125)], maxunicode: 65535
Windows: python: 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit
(Intel)], maxunicode: 65535
Windows: python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)], maxunicode: 65535