I propose that the release of 3.0rc2 is deferred until all release blockers have been resolved (either by actually fixing them, or by carefully considering that they shouldn't actually block the release).
What else is the point of having the "release blocker" priority, if they don't actually manage to block the release?
Also, I would like to think that there shouldn't be any non-documentation changes between the last release candidate, and the final release(*). Otherwise, what's the point of calling it a "release candidate" if it doesn't actually get released, later? IOW, what's the difference to a beta release?
(*) Consequently, there doesn't need to be much more time between the release candidate and the final release except but a few days, or, at most, a week.
Regards, Martin
On Thu, Oct 2, 2008 at 4:47 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I propose that the release of 3.0rc2 is deferred until all release blockers have been resolved (either by actually fixing them, or by carefully considering that they shouldn't actually block the release).
What else is the point of having the "release blocker" priority, if they don't actually manage to block the release?
+10. Absolutely.
Also, I would like to think that there shouldn't be any non-documentation changes between the last release candidate, and the final release(*). Otherwise, what's the point of calling it a "release candidate" if it doesn't actually get released, later? IOW, what's the difference to a beta release?
(*) Consequently, there doesn't need to be much more time between the release candidate and the final release except but a few days, or, at most, a week.
That's been the policy for the last few releases, as far as I can recall.
Martin> I propose that the release of 3.0rc2 is deferred until all
Martin> release blockers have been resolved (either by actually fixing
Martin> them, or by carefully considering that they shouldn't actually
Martin> block the release).+1. Even though it's not 3.0-specific, I think the highest priority problem which should be resolved ASAP is the 403 Forbidden which essentially all doc pages return right now.
Skip
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 2, 2008, at 2:47 AM, Martin v. Löwis wrote:
I propose that the release of 3.0rc2 is deferred until all release blockers have been resolved (either by actually fixing them, or by carefully considering that they shouldn't actually block the release).
We should reconsider whether 3.0 is ready for release candidates.
Perhaps it makes more sense to rename rc1 to beta4 and fix some of
these blockers. Now that 2.6 is (mostly) out of the way, we can
concentrate on getting 3.0 right.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOTECXEjvBPtnXfVAQIX6AP5ART0TxYwBVVg4BixDD7Fua7WXFmFcJJA JXkr8fXQPlGsTWychGSXHpaWOuS2qoSPZd/NC1KLcctkkJO1YC7Uuw3iT06XYEOC DbHbCQHmH7sSQmVCYHC1azibHCAdL5uvJLtVoc3GC0aOkV3XRlieVo7k2PhdvwIJ Wok8R0eQwq8= =IkmX -----END PGP SIGNATURE-----
Barry Warsaw wrote:
We should reconsider whether 3.0 is ready for release candidates. Perhaps it makes more sense to rename rc1 to beta4 and fix some of these blockers. Now that 2.6 is (mostly) out of the way, we can concentrate on getting 3.0 right.
Yes, with Victor's filesystem decoding related changes still to go in, along with a a few other API changes to be forward ported from 2.6, calling the current state of 3.0 a release candidate definitely seems to be getting ahead of ourselves.
A big +1 from me for declaring it still in beta until all the 3.0 release blockers are fixed.
Cheers, Nick.
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
http://www.boredomandlaziness.org
On Oct 2, 2008, at 8:59 AM, Nick Coghlan wrote:
A big +1 from me for declaring it still in beta until all the 3.0 release blockers are fixed.
+1 from me as well. From what I've read about the pathname issues,
I'm pretty worried about the usability of 3.0.
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org>
Fred Drake wrote:
On Oct 2, 2008, at 8:59 AM, Nick Coghlan wrote:
A big +1 from me for declaring it still in beta until all the 3.0 release blockers are fixed.
+1 from me as well. From what I've read about the pathname issues, I'm pretty worried about the usability of 3.0.
If you don't make a habit of borking your own filesystems with dodgy filenames, it runs fine.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
http://www.boredomandlaziness.orgIMHO if there's still big scary stuff out there, calling this a release candidate does us no good PR-wise, and does no good for our users. 3.0 is going to be scary enough for them as it is - cutting a release candidate that we either know is broken, or else has significant changes, is a very bad idea.
On Fri, Oct 3, 2008 at 12:39 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Fred Drake wrote:
On Oct 2, 2008, at 8:59 AM, Nick Coghlan wrote:
A big +1 from me for declaring it still in beta until all the 3.0 release blockers are fixed.
+1 from me as well. From what I've read about the pathname issues, I'm pretty worried about the usability of 3.0.
If you don't make a habit of borking your own filesystems with dodgy filenames, it runs fine.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
http://www.boredomandlaziness.org
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
IMHO if there's still big scary stuff out there, calling this a release candidate does us no good PR-wise, and does no good for our users. 3.0 is going to be scary enough for them as it is - cutting a release candidate that we either know is broken, or else has significant changes, is a very bad idea.
I concur. Better to go through another beta. It feels like 3.0 is being rushed.
Raymond
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 2, 2008, at 12:31 PM, Raymond Hettinger wrote:
IMHO if there's still big scary stuff out there, calling this a release candidate does us no good PR-wise, and does no good for our users. 3.0 is going to be scary enough for them as it is - cutting a release candidate that we either know is broken, or else has significant changes, is a very bad idea.
I concur. Better to go through another beta. It feels like 3.0 is being rushed.
I agree. I'm swamped right now, but I will try to put together a
revised schedule proposal later tonight.
Someone please distract Guido while I "borrow" the keys to the time
machine.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSOT4nnEjvBPtnXfVAQLR3QP+NW6g5vNb6Avqk42lXg1I0vvhYn7UoR5q Of7u7OSjuir2rK3srvZyzsUuPNeFANY1vNwPD+j3WT2fL+ZgdVzefYHNGtk3CPG6 L9NvTRvMhj17rFjFMV9hng5CgCS4bKGfg5/yrKeOBL8/MPeQfF2p3+UWYdBWNAfV p+1vmjTMcUk= =LdRB -----END PGP SIGNATURE-----
On Thu, Oct 2, 2008 at 9:36 AM, Barry Warsaw <barry@python.org> wrote:
On Oct 2, 2008, at 12:31 PM, Raymond Hettinger wrote:
IMHO if there's still big scary stuff out there, calling this a release candidate does us no good PR-wise, and does no good for our users. 3.0 is going to be scary enough for them as it is - cutting a release candidate that we either know is broken, or else has significant changes, is a very bad idea.
I concur. Better to go through another beta. It feels like 3.0 is being rushed.
I agree. I'm swamped right now, but I will try to put together a revised schedule proposal later tonight.
Someone please distract Guido while I "borrow" the keys to the time machine.
No need to be sneaky about it, go right ahead. I don't think we should retroactively rename rc1 to beta4, but we can certainly label the next release as beta5, with an explanation, and the first real release candidate should be called rc2 to avoid confusion.
BTW I'll go over the release blockers today and see what I can do. We've got to get this baby back on the road! :-)
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
2008/10/2 Guido van Rossum <guido@python.org>:
No need to be sneaky about it, go right ahead. I don't think we should retroactively rename rc1 to beta4, but we can certainly label the next release as beta5, with an explanation, and the first real release candidate should be called rc2 to avoid confusion.
+1.
This is not the normal standardized way to release software, but I'm sure this will prove our commitment to the quality of the product.
Thank you!
-- . Facundo
Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
If you don't make a habit of borking your own filesystems with dodgy filenames, it runs fine.
I really hope the individuals making this argument are being
facetious. I don't think this is the source of the problem at all.
The expect the most common occurrence of the problem comes from
sharing of drives between operating systems and individual
configurations; those ubiquitous little USB "thumb" drives get shared
between all kinds of computers these days as people share files they
don't want to or can't pass over a network for whatever reason.
(Those drives might actually serve other purposes first, such as being
music players, and so may have no other interfaces for transferring
files.)
If someone hands me a USB flash drive with filenames encoded in
whatever is reasonable for them, I should be able to use Python tools
on the files without having to use non-Python tools to copy or rename
the file first. The possibility of a conflicting encoding is
increased if the source machine is configured to use a very different
encoding, clearly, but that's not that unusual.
The world is smaller than it used to be, and we really need to
understand that.
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org>
On Thu, Oct 2, 2008 at 10:08 AM, Fred Drake <fdrake@acm.org> wrote:
On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
If you don't make a habit of borking your own filesystems with dodgy filenames, it runs fine.
I really hope the individuals making this argument are being facetious. I don't think this is the source of the problem at all.
The expect the most common occurrence of the problem comes from sharing of drives between operating systems and individual configurations; those ubiquitous little USB "thumb" drives get shared between all kinds of computers these days as people share files they don't want to or can't pass over a network for whatever reason. (Those drives might actually serve other purposes first, such as being music players, and so may have no other interfaces for transferring files.)
If someone hands me a USB flash drive with filenames encoded in whatever is reasonable for them, I should be able to use Python tools on the files without having to use non-Python tools to copy or rename the file first. The possibility of a conflicting encoding is increased if the source machine is configured to use a very different encoding, clearly, but that's not that unusual.
The world is smaller than it used to be, and we really need to understand that.
All good points.
However no matter how you spin it, we're in a hard place. If we maintain that filenames should always be represented as text strings, we have no choice of coming up with a way of encoding all possible byte sequences into Unicode strings, using a reversible encoding. This has been shown to be hard no matter what encoding you favor -- as soon as those "Unicode" strings are passed on to other libraries or programs nobody is sure how they will be treated.
If we switch to the view that all filenames are bytes after all, Windows loses, because because not all filenames are representable that way (unless you deviate from the encoding that Windows has chosen for you, which presents other problems). Also, it would be a *huge* project, since filenames are so ubiquitous.
There are a number of ways out, but I don't think we'll be able to come up with a solution without doing a lot of experimentation. Therefore I believe the best thing to do is to release 3.0 with a low-level solution that makes it possible to carry out those experiments. I am hoping that Martin will check in his sys.setfilesystemencoding() function, and am am working on Victor Stinner's code for better supporting filenames-as-bytes (in addition to, not instead of filenames-as-text), and I expect that these two are together to allow the necessary experimentation to take place post-3.0.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
I forgot one thing. In the *long* run I expect the problem to go away -- UTF-8 is going to win out. But this is years off, and that's why we need to support non-UTF-8-encoded filenames in the short and medium term. And this can be many years.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Oct 2, 2008, at 1:53 PM, Guido van Rossum wrote:
we have no choice of coming up with a way of encoding all possible byte sequences into Unicode strings, using a reversible encoding. This has been shown to be hard no matter what encoding you favor -- as soon as those "Unicode" strings are passed on to other libraries or programs nobody is sure how they will be treated.
Indeed; weird encoding heuristics would be unusable in practice, and
don't seem to offer benefits to those building higher-level
portability layers either. I see no future for that approach.
If we switch to the view that all filenames are bytes after all, Windows loses, because because not all filenames are representable that way (unless you deviate from the encoding that Windows has chosen for you, which presents other problems). Also, it would be a *huge* project, since filenames are so ubiquitous.
As much as I'd like to say files and paths are bytes ('cause that's
easy), I agree that it doesn't work that way either. Paths are
platform-specific, and Windows and Unix might disagree just for the
principal of the thing for many years to come.
There are a number of ways out, but I don't think we'll be able to come up with a solution without doing a lot of experimentation. Therefore I believe the best thing to do is to release 3.0 with a low-level solution that makes it possible to carry out those experiments.
Agreed. Having it be possible to use whatever the "right" solution is
on each platform is about as good as it gets in the short term.
Getting good, portable abstractions on top of that will take time.
That doesn't mean it's not scary when thinking about writing portable
code in this environment. That's not entirely new, but the fact that
so much of these details are being addressed so late in the release
cycle *should* give cause for concern, especially to those of use who
are still a long way from stepping up to current versions.
-Fred
-- Fred Drake <fdrake at acm.org>
On Thu, Oct 2, 2008 at 11:11 AM, Fred Drake <fdrake@acm.org> wrote:
That doesn't mean it's not scary when thinking about writing portable code in this environment. That's not entirely new, but the fact that so much of these details are being addressed so late in the release cycle *should* give cause for concern, especially to those of use who are still a long way from stepping up to current versions.
I had always expected that issues like these would crop up fairly late in the Py3k development cycle -- the first two years were completely filled with discussions about language changes, and then their implementation. Library stuff (and this *is* library stuff, even if it's pretty fundamental) necessarily had to come later, once we had a more-or-less usable version of the language.
FWIW, I don't expect any of the other release blockers to be quite this invasive -- and this one is actually not all that invasive, since most system calls *already* supported bytes alongside with text strings. There are only two C-level changes: the addition of getcwdb() (and the removal of getcwdu()), and the change in behavior for listdir() with a text string argument (skipping undecodable filenames rather than returning raw bytes). There was a one-line change in io.py to make the built-in open() function (which is really an alias for io.open()) accept bytes, and then a bunch of changes to posixpath.py, glob.py and fnmatch.py to support bytes.
It's really not very invasive, and not much changes -- the changes are mostly in our minds, as we now have all learned about the issues and the differences between platforms, and know what to tell people to do about them. *That* is the major change, not the few code changes.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
If someone hands me a USB flash drive with filenames encoded in whatever is reasonable for them, I should be able to use Python tools on the files without having to use non-Python tools to copy or rename the file first.
I agree. I disagree that you should be able to do so with Python 3.0 (although it looks like you might).
Regards, Martin
On Oct 2, 2008, at 2:46 PM, Guido van Rossum wrote:
It's really not very invasive, and not much changes -- the changes are mostly in our minds, as we now have all learned about the issues and the differences between platforms, and know what to tell people to do about them. *That* is the major change, not the few code changes.
Heh. Doesn't pay to educate users, does it? :-/
At about the same time, Martin said:
I agree. I disagree that you should be able to do so with Python 3.0 (although it looks like you might).
Why do you disagree that I should be able to do this with Python 3.0?
(I can guess, but that just increases the likelihood that I'll be
wrong, which I don't like.)
-Fred
-- Fred Drake <fdrake at acm.org>
That doesn't mean it's not scary when thinking about writing portable code in this environment. That's not entirely new, but the fact that so much of these details are being addressed so late in the release cycle *should* give cause for concern, especially to those of use who are still a long way from stepping up to current versions.
That sounds pretty much like an outsider view. I knew about this issue right since PEP 277 was implemented, in 2002, see issue 594001. See then issue 683592 which discusses Unicode file names returned from listdir on POSIX. Take particular notice of Guido's comment
# FWIW, I like Just's "fall back to bytestrings" aproach.
Python 3.0rc1, as released, *does* give you access to all files.
People have been going forth an back considering all the design options; the details have been addressed years ago. It's just that now, the way of addressing them is reconsidered (in the light of other things having changed along, of course).
Regards, Martin
At about the same time, Martin said:
I agree. I disagree that you should be able to do so with Python 3.0 (although it looks like you might).
Why do you disagree that I should be able to do this with Python 3.0? (I can guess, but that just increases the likelihood that I'll be wrong, which I don't like.)
There might be systems and environments where Python doesn't work at all, or doesn't work "correctly" (i.e. as the majority of users would expect). There have been such systems and environments always. There will always be bugs. There will always be later releases to fix them. Python 3.0 doesn't have to be perfect, and won't be.
I'm still in favor of a solution that doesn't divide the APIs into "character file names" and "byte file names"; I want the "character file names" to work always. However, I find it completely unrealistic to make this work in Python 3.0. Providing that feature in 3.1 is still early enough, plus it requires a PEP.
Regards, Martin
On Thu, Oct 2, 2008 at 12:08 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I'm still in favor of a solution that doesn't divide the APIs into "character file names" and "byte file names"; I want the "character file names" to work always.
I wish we could do that too, but I don't see how to make it work in all contexts. If you are passing filenames to other programs or libraries you may be forced to pass bytes, or in other cases you may be forced to give up on supporting undecodable filenames (e.g. when passing filenames to something written in Java).
However, I find it completely unrealistic to make this work in Python 3.0. Providing that feature in 3.1 is still early enough, plus it requires a PEP.
Right.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Oct 2, 2008, at 3:08 PM, Martin v. Löwis wrote:
I'm still in favor of a solution that doesn't divide the APIs into "character file names" and "byte file names"; I want the "character file names" to work always. However, I find it completely unrealistic to make this work in Python 3.0.
Ok, that's reasonable. I'm not expecting to be able to use character-
file-names everywhere in 3.0, or really anywhere, as nice as that
would be. I just want to be able to perform all operations with all
files (to the extent they're supported by the O/S and filesystem, etc.).
Making a convenient, portable API that lets me do that easily is
certainly out of scope.
-Fred
-- Fred Drake <fdrake at acm.org>
On 2008-10-02 19:08, Fred Drake wrote:
On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
If you don't make a habit of borking your own filesystems with dodgy filenames, it runs fine.
I really hope the individuals making this argument are being facetious. I don't think this is the source of the problem at all.
FWIW: In Germany you run into those filename encoding problems all the time, esp. when using Windows shares on Unix.
It is not uncommon at all to have all user files reside in a user folder with accented characters or Umlauts.
And the story goes on: if you then have set Unix to a different locale (and encoding), it is possible to have Unix create file names on the Windows share that don't look right when viewed on other Windows machines.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Oct 02 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
Fred Drake wrote:
On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
If you don't make a habit of borking your own filesystems with dodgy filenames, it runs fine.
I really hope the individuals making this argument are being facetious. I don't think this is the source of the problem at all.
To quote Raymond: "native speakers of ASCII will never be able to master Unicode like a native"
I.E. not being facetious, so much as underestimating the frequency of the problem occurring in other parts of the world due to living and working in a single language environment where encoding issues almost never arise (and where UTF-8 is by far the most common encoding after ASCII and iso-8859-1).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
http://www.boredomandlaziness.org
participants (10)
-
"Martin v. Löwis" -
Anthony Baxter -
Barry Warsaw -
Facundo Batista -
Fred Drake -
Guido van Rossum -
M.-A. Lemburg -
Nick Coghlan -
Raymond Hettinger -
skip＠pobox.com