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
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 sour
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, t
On Thu, Oct 2, 2008 at 12:08 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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
> 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
> 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
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 cha
> 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
(
On Thu, Oct 2, 2008 at 11:11 AM, Fred Drake <[EMAIL PROTECTED]> 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*
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 passe
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.or
On Thu, Oct 2, 2008 at 10:08 AM, Fred Drake <[EMAIL PROTECTED]> 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.
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
2008/10/2 Guido van Rossum <[EMAIL PROTECTED]>:
> 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
On Thu, Oct 2, 2008 at 9:36 AM, Barry Warsaw <[EMAIL PROTECTED]> 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
-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 - cutt
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 i
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 id
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 d
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.
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 decodin
-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 rel
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 th
On Thu, Oct 2, 2008 at 4:47 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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 el
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 manag
25 matches
Mail list logo
