(Maybe someone else has already raised this point. I'm a bit behind.)
Martin Here goes something: for applications targeted to the web, where
Martin newlines don't matter, the line breaks in _()'ed strings are
Martin superfluous.
How will you know you're generating output that
On 9/10/05, James Y Knight [EMAIL PROTECTED] wrote:
No, that cannot work. However, there is a very obvious and trivial
solution. Do not remove dict.iteritems in Py 3.0. Py2.X programs
wishing forward compat can avoid dict.items and use instead
dict.iteritems. In Py3.0, dict.items becomes a
On Sep 11, 2005, at 11:24 AM, Guido van Rossum wrote:
But it breaks the desire to keep the Python 3.0 language clean from
deprecated features.
That is a nice goal, another nice goal is to not unnecessarily break
things.
But just installing python3.0 as python and expecting
nothing will
On 9/11/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
(Maybe someone else has already raised this point. I'm a bit behind.)
Martin Here goes something: for applications targeted to the web, where
Martin newlines don't matter, the line breaks in _()'ed strings are
Martin
On 9/11/05, Guido van Rossum [EMAIL PROTECTED] wrote:
...
But just installing python3.0 as python and expecting
nothing will break is not a goal -- it would be too constraining.
It should be expected that many users will keep both 2.x and 3 side by
side for quite a long time. Instead of having
James Y Knight wrote:
Just to be clear, I do not want nor expect this. I wish to be able to
specifically modify code with full knowledge of what has changed in
Py3.0 such that it will work with both Py2.X and Py3.0.
If you want these things to work in 2.x and 3.0, just use
iter(dict_instance)
Oren Tirosh wrote:
perhaps the Python 3 executable should have a different name as part
of the standard distribution? I suggest py / py.exe
Or python3? EIBTI :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of
Nick Coghlan wrote:
However, such a future_builtins module could still include modified
versions
of those standard objects - such future-proofed code would simply still
need
to deal with the fact that other libraries or clients may pass in the
old-style components (e.g. just as
Peter Jones wrote:
Another problem (which I have not fixed) is that when realpath() is
used, in some cases MAXPATHLEN is smaller than the system's
PATH_MAX/pathconf(path, _PC_PATH_MAX).
The linux man page for realpath() has this at the bottom:
BUGS
Never use this function. It is
Nick Coghlan wrote:
Not to mention the annoyingly large number of fonts that make '`' and '''
look
virtually identical :(
Well, you need to be careful about choice of font for
programming anyway, for 0/O, 1/l, etc.
--
Greg Ewing, Computer Science Dept,
10 matches
Mail list logo
