On Feb 4, 2008, at 10:06 PM, Andrew McNabb wrote:
> In Python 2, "import wxPython" will import wxPython based on Python 2,
> and on Python 3, it will import wxPython based on Python 3. There
> wouldn't be a Python 2 version of wxPython in the python3.0
> site-packages.
Not much fun for users of
I really like your point about how Python should give a better error
than a SyntaxError when a Python 2 script is run on a Python 3
interpreter. I agree that the cause of problems should be pointed out
clearly to end users. However, I disagree that adding a new file
extension is necessary.
On Mo
On 2/4/08, Charles Merriam <[EMAIL PROTECTED]> wrote:
> What about a formal dependency plan instead?
> Python would remain 'batteries included', perhaps verging on 'kitchen
> sink included'.
> Those users working to embed Python or work in other situations where
> a large set of available librari
Neal Becker writes:
> Would be even nicer if python could say: require python_version >=
> x.y or some such.
The starting point of this discussion was that Python 3 proves this to
be impossible. The app cannot be sure at write time that no Python
released in the future will make the app illega
Nick Coghlan wrote:
> I personally haven't seen anything to convince me that the 2.x -> 3.0
> upgrade cycle is going to be significantly worse from a deployment point
> of view than a 2.x -> 2.(x+2) upgrade cycle where breakages are also
> possible (e.g. code using 'with' or 'as' as identifiers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 4, 2008, at 6:20 PM, Stephen J. Turnbull wrote:
>>> On the contrary, Python 3.1 itself may be buggy. I do not think is
>>> it appropriate for the Python installer to make that decision for
>>> the user by creating a link to the most recent pyt
Mike Meyer writes:
> On Mon, 04 Feb 2008 20:22:04 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]>
> wrote:
> > Marcin ___Qrczak___ Kowalczyk writes:
> > > Dnia 03-02-2008, N o godzinie 10:24 +0900, Stephen J. Turnbull pisze:
> > > > I don't see any need to shorten "python3.0" to "python3".
Leif Walsh wrote:
> On Feb 4, 2008 2:34 PM, Neal Becker <[EMAIL PROTECTED]> wrote:
>> Would be even nicer if python could say:
>> require python_version >= x.y
>> or some such.
>
> I already had this suggestion shot down in the "Namespaces are etc."
> thread. The argument goes a bit like "if the
On Feb 4, 2008 2:34 PM, Neal Becker <[EMAIL PROTECTED]> wrote:
> That was unfortunate. What they should have done, IMO, is install python as
> a link to the latest version. Where they had tools that had not been
> ported, those tools should have explicitly said #!/usr/bin/python1.5.
>
> Would be
Guido van Rossum wrote:
> On Feb 4, 2008 5:52 AM, <[EMAIL PROTECTED]> wrote:
>> This discussion of what to install Python 3.0 as reminded me that we've
>> already encountered this problem before. As I recall, when Python 2.0
>> was released Red Hat steadfastly refused to ship it with their then
What about a formal dependency plan instead?
Python would remain 'batteries included', perhaps verging on 'kitchen
sink included'.
Those users working to embed Python or work in other situations where
a large set of available libraries is a problem would have some help
in cutting down the footpri
How about the ellipses as a Python 3 marker?
>From a previous discussion, the error messages on this null-op should
be made better in Python 3.0 anyway.
If ellipses are allowed as a stand-alone statement, much like pass,
then we could just have these messages:
Python 2.6: "Unexpected '...'. E
On Feb 4, 2008 5:52 AM, <[EMAIL PROTECTED]> wrote:
> This discussion of what to install Python 3.0 as reminded me that we've
> already encountered this problem before. As I recall, when Python 2.0 was
> released Red Hat steadfastly refused to ship it with their then current
> version of Linux. I
Ron Adam wrote:
> I like .pst better, or maybe reuse .pth files?
MS Outlook uses the file extension .pst. Python has a history to "claim"
the .py? namespace. I like to stick to the tradition.
Christian
___
Python-3000 mailing list
Python-3000@python.or
Christian Heimes wrote:
> Mike Meyer wrote:
>> -2 on using the shebang line for this. The 2.X version-specific
>> binaries are python2.X, so to use that, you'd have to make the shebang
>> line invoke python2.X. Right now, if you upgrade an installation from
>> 2.X to 2.X+1, you can expect most of
> First of all, under current policy, installing Python 3.1 would not
> uninstall or overwrite Python 3.0, so nothing "breaks" when the user
What policy?
Bill
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/py
Mike Meyer wrote:
> -2 on using the shebang line for this. The 2.X version-specific
> binaries are python2.X, so to use that, you'd have to make the shebang
> line invoke python2.X. Right now, if you upgrade an installation from
> 2.X to 2.X+1, you can expect most of the scripts to work assuming yo
This discussion of what to install Python 3.0 as reminded me that we've
already encountered this problem before. As I recall, when Python 2.0 was
released Red Hat steadfastly refused to ship it with their then current
version of Linux. It wasn't until the next RH product came out that they
shippe
Guido van Rossum wrote:
> 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". Tha
On Mon, 04 Feb 2008 12:55:29 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]>
wrote:
> Greg Ewing writes:
> I wonder how many people out there will be "surprised" by sudden
> changes in the version of Python installed.
It's happened in the past. I've been dealing with supporting multiple
incompati
On Sat, 2 Feb 2008 23:47:50 -0800 "Gregory P. Smith" <[EMAIL PROTECTED]> wrote:
> +1 on devising a way (to appear starting in 2.6 and 3.0) of marking the
> minimum language version required by a file near the top so that the parser
> can bail with a useful error message instead of one confusing to
On Sun, 03 Feb 2008 11:45:38 +1300 Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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 possi
Marcin ‘Qrczak’ Kowalczyk writes:
> Dnia 03-02-2008, N o godzinie 10:24 +0900, Stephen J. Turnbull pisze:
>
> > I don't see any need to shorten "python3.0" to "python3".
>
> There is a need. Using #!/usr/bin/python3.0 would break as soon as
> python3.1 is released, while #!/usr/bin/python3
Dnia 03-02-2008, N o godzinie 10:24 +0900, Stephen J. Turnbull pisze:
> I don't see any need to shorten "python3.0" to "python3".
There is a need. Using #!/usr/bin/python3.0 would break as soon as
python3.1 is released, while #!/usr/bin/python3 would be fine, at least
in the next few years.
Usin
Brett Cannon wrote:
> If you want to trim more then
> push for stuff to be removed on a module-to-module basis. But going
> from "batteries included" to "batteries easily downloaded" is quite a
> shift for Python.
Not to mention it being a serious pain in the rear for those of us who
have to get
25 matches
Mail list logo
