(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 become
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
> Mar
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 havi
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_instanc
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 citiz
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 a
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 b
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, +-
On 9/12/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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 :-)
Generally, each distribution makes its own decision about when
11 matches
Mail list logo
