Re: [Python-Dev] Replacement for print in Python 3.0
(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 goes between and (where newlines do matter)? Skip ___ Python-Dev mailing list [email protected] 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 3000 and iterators
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 synonym for > dict.iteritems and programs that don't care about compat with 2.X can > just use dict.items from then on. And everybody can be happy. A small > number of redundant methods is a small price to pay for compatibility. But it breaks the desire to keep the Python 3.0 language clean from deprecated features. Given that I don't expect there will be much compatibility *anyway*, I don't want to promise this. I expect that we'll have to write a source-level translator -- which could replace all iteritems() calls to items(), for example. Such a source-level translator may not be able to reach perfection, but it should take care of the tedious tasks and leave the rest up to manual polishing. This doesn't mean that there's no point in trying to introduce certain 3.0 features in 2.x; it's always good to have early experience with a new feature, and in some cases it *will* improve forward compatibility. But just installing python3.0 as python and expecting nothing will break is not a goal -- it would be too constraining. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 3000 and iterators
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 break is not a goal -- it would be too constraining. > 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. And, now is probably not really the right time to discuss such minor issues as whether to keep iteritems in Py3.0, but, if it is kept, it becomes easier to write such code. It is of course still possible to write compatible code without keeping iteritems, you just have to replace all the method calls with a function wrapper which calls one of items or iteritems depending on the version. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pygettext() without newlines (Was: Re: Replacement for print in Python 3.0)
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> superfluous. > > How will you know you're generating output that goes between and > (where newlines do matter)? The great majority of the strings are _(), but in my web app framework I use __() for that specific purpose you mention, which invokes the "normal" behaviour of pygettext (which my patch doesn't remove, BTW). Here is how I invoke pygettext from my Makefile: POTCMD = pygettext.py \ --verbose --extract-all --no-default-keywords \ --keyword-single=_ --keyword-single=N_ \ --keyword=__ I use _() and N_() for single-line'd strings (runtime and marker-only versions), and __() for the usual multi-line strings. It works well, I've been using this for a while on a web application I'm building. cheers, ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3 executable name (was: Re: PEP 3000 and iterators)
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 distributions choosing their own naming schemes (like the python/python2 redhat fiasco) perhaps the Python 3 executable should have a different name as part of the standard distribution? I suggest "py" / "py.exe" Oren ___ Python-Dev mailing list [email protected] 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 3000 and iterators
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) and list(dict_instance) as appropriate. Tim Delaney ___ Python-Dev mailing list [email protected] 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 executable name
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 NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] 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 3000 and iterators
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 unicode-aware code needs to deal with the > fact that other libraries or clients may produce 8-bit strings rather than > unicode text). And be careful not to pass them to old code which expects the traditional versions of these objects. Sounds far too tricky and error-prone to be worth the trouble to me. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unintentional and unsafe use of realpath()
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 broken by design since it is impossible to determine a suitable size for the output buffer. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing mem- ory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded. So maybe it shouldn't be using realpath() at all? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
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, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] 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 executable name
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 to make the default "python" the new version. Any damage is usually limited to third party extension modules because python versions are source compatible. But this time it isn't. So do you keep the name "python3" forever? Do you keep unqualified "python" as 2.x forever? I expect many installations to keep 2.x around for many years. How do you keep different distributions from making their own incompatible decisions about naming conventions? Using version numbers in the executable name is just asking for this to happen. I suggest an explicitly and permanently different name for the interpreter executable of this new and incompatible branch of the language. I want Python 3 scripts starting with #! to have an average shelf life longer than 18 months. Oren ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
