This should be brought up on the python-3000 list; I'm moving it there
using a Bcc to python-ideas.
To some extent it is up to the vendors who distribute binaries -- they
decide what to call it.
Perhaps we should only install "python3.0" and not "python". That is a
valid choice already and always
Guido van Rossum schrieb:
> This should be brought up on the python-3000 list; I'm moving it there
> using a Bcc to python-ideas.
>
> To some extent it is up to the vendors who distribute binaries -- they
> decide what to call it.
>
> Perhaps we should only install "python3.0" and not "python". T
Georg> I would prefer a "python3" alias analogous to the current
Georg> "python" alias, at least as long as Python 2.x is still in wide
Georg> use.
So, "make install" would install a python3.0 executable and make python3 a
symlink. Makes sense to me. "make bdfl-install" could also cr
On Feb 2, 2008 6:55 AM, <[EMAIL PROTECTED]> wrote:
>
> Georg> I would prefer a "python3" alias analogous to the current
> Georg> "python" alias, at least as long as Python 2.x is still in wide
> Georg> use.
>
> So, "make install" would install a python3.0 executable and make python3 a
Georg Brandl wrote:
> I would prefer a "python3" alias analogous to the current "python" alias,
> at least as long as Python 2.x is still in wide use.
>
> Having to type "python3.0" explicitly strikes me as unnecessarily verbose.
+1
> As for module file name extensions, what speaks against allow
Guido van Rossum wrote:
> On Feb 2, 2008 6:55 AM, <[EMAIL PROTECTED]> wrote:
> >
> > Georg> I would prefer a "python3" alias analogous to the current
> > Georg> "python" alias, at least as long as Python 2.x is still
in
> > Georg> wide use.
> >
> > So, "make install" would install a py
Christian Heimes schrieb:
> Georg Brandl wrote:
>> I would prefer a "python3" alias analogous to the current "python" alias,
>> at least as long as Python 2.x is still in wide use.
>>
>> Having to type "python3.0" explicitly strikes me as unnecessarily verbose.
>
> +1
>
>> As for module file nam
On Sat, Feb 02, 2008 at 11:16:16AM +0900, Stephen J. Turnbull wrote:
> Greg Ewing writes:
>
> > Also, if generator expressions had come first, we
> > would probably never have gotten list comprehensions.
>
> I don't understand. A list comprehension is for when you know you're
> going to want t
As has occurred since the inception of PyCon, there will be a sprint
on the Python core at this year's conference!
If you will be attending PyCon (or will be in Chicago during the dates
of the sprints), attending the sprint is a great way to give back to
Python. Working on Python itself tends to d
On Sat, 2 Feb 2008 08:55:10 -0600 [EMAIL PROTECTED] wrote:
> Anybody who installed multiple versions of Python on their computer today -
> at least in the Unixoid world - already has to know about "make altinstall"
> so they don't accidentally obliterate the python symlink. I don't
> understand wh
Christian Heimes writes:
> > Having to type "python3.0" explicitly strikes me as unnecessarily verbose.
>
> +1
It won't once python 3.1 is released.
> > As for module file name extensions, what speaks against allowing (not
> > mandating) "py3" for Python 3.x modules?
Namespace pollution,
Georg Brandl wrote:
> No, but Python looks for modules with the extension ".py" and not ".py3".
Python should still use the .py, .pyc and .pyo extensions for Python
3.0. I'm proposing a different extension for entry points to programs -
the Python file that starts a program and contains the if __n
Stephen J. Turnbull wrote:
> Mac OS X's open command does something according to extension:
>
> chibi:tmp steve$ echo 'print "hello, world"' >> hello.py
> chibi:tmp steve$ python hello.py
> hello, world
> chibi:tmp steve$ open hello.py
> chibi:tmp steve$
>
> I don't know what, though. The dis
On Feb 2, 2008 4:15 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Python should still use the .py, .pyc and .pyo extensions for Python
> 3.0. I'm proposing a different extension for entry points to programs -
> the Python file that starts a program and contains the if __name__ ==
> "__main__" m
Stephen> FWIW, I can tell you that Skip will get pushback from me if he
Stephen> proposes registering those extensions in XEmacs's
Stephen> auto-mode-alist. I won't absolutely veto it, but I'll
Stephen> certainly suggest to the other reviewers that this is a bad
Stephen> idea.
Stephen J. Turnbull wrote:
> Greg Ewing writes:
>
> > Also, if generator expressions had come first, we
> > would probably never have gotten list comprehensions.
>
> I don't understand. A list comprehension is for when you know you're
> going to want to work with the whole list.
But list(gene
Greg Ewing schrieb:
> Stephen J. Turnbull wrote:
>> Greg Ewing writes:
>>
>> > Also, if generator expressions had come first, we
>> > would probably never have gotten list comprehensions.
>>
>> I don't understand. A list comprehension is for when you know you're
>> going to want to work with t
Mike Meyer wrote:
> And - at least in my experience - chances are good that nothing but
> the simplest scripts will work on multiple versions anyway, because
> they don't have the same set of third party - or possibly even builtin
> - modules installed, unless someone took care to make sure that
>
Stephen J. Turnbull wrote:
> Mac OS X's open command does something according to extension:
>
> I don't know what, though. The disk spun, I waited a second, and then
> the prompt returned. :-)
I just tried an experiment on my system, and it appears
to want to launch IDLE -- but IDLE seems to be
Georg Brandl wrote:
> Hm, but wouldn't he then have removed list comprehensions
> by now using the time machine?
I seem to remember that LCs were being seriously considered
for removal in 3.x at one point. I'm not sure of all the
reasons why they were kept.
--
Greg
___
Leif Walsh wrote:
> It doesn't make any sense to me why we would want a different
> extension just because some code is the "part to run first". Isn't it
> all the same code?
It makes perfectly sense for some OSes. On Windows there is already a
second file extension for Python scripts called "pyw
Greg Ewing writes:
> But list(genexp) gives you very nearly the same thing [as a list
> comprehension] -- so near that I find it hard to imagine anyone
> would have thought to suggest a dedicated LC syntax if genexps had
> already been present in the language.
Point taken, except that I find
[EMAIL PROTECTED] writes:
>
> Stephen> FWIW, I can tell you that Skip will get pushback from me if he
> Stephen> proposes registering those extensions in XEmacs's
> Stephen> auto-mode-alist. I won't absolutely veto it, but I'll
> Stephen> certainly suggest to the other review
Guido asked that this thread be moved to python-3000. Reply-To set.
Greg Ewing writes:
> Adam Olsen wrote:
> > They also have often broken python code that depended on one or two
> > small details, and we haven't needed a new extension before.
>
> But we haven't had such major incompatibil
Christian Heimes wrote:
> Stephen J. Turnbull wrote:
>> Mac OS X's open command does something according to extension:
>>
>> chibi:tmp steve$ echo 'print "hello, world"' >> hello.py
>> chibi:tmp steve$ python hello.py
>> hello, world
>> chibi:tmp steve$ open hello.py
>> chibi:tmp steve$
>>
>>
On Feb 2, 2008 8:38 PM, Ron Adam <[EMAIL PROTECTED]> wrote:
> Instead of a shebang which depends on the shell, maybe a version specifier
> of some sort could be used?
>
> # -*- pyversions: 2.5, 2.6 -*-
>
> So if a python 3.x detects a too low a version, maybe it can try to restart
> the program
Leif> There is already an idiom with other packages (pygtk etc.) that
Leif> suggests syntax like
Leif> try:
Leif> python.require('3.1')
Leif> except:
Leif> print('Some warning about version incompatibility')
Leif> exit(1)
It won't work in this case. Compi
Stephen J. Turnbull wrote:
> I don't see any need to shorten "python3.0" to "python3".
I was thinking that "python3" would be the 3.x series
equivalent of what "python" is now, i.e. installation
of 3.0 would create links called "python3.0" and (unless
you're doing altinstall) also "python3".
> A
yep we've already been through that problem in the past when list
comprehensions, generators and with were added to name a few. since python
3 code is highly unlikely to even parse with a 2.x interpreter much of the
time thats a reason to consider a .py3 extension if this precedent of not
caring i
29 matches
Mail list logo
