2008/10/8 "Martin v. Löwis" <[EMAIL PROTECTED]>:
>> How is this supposed to work?
>
> The design was that you use PyState_FindModule, as an efficient way for
> getting a module object if you have the module def. The implementation
> fills an index into the module def (which will stay constant acros
On Oct 7, 2008, at 4:45 PM, Adam Olsen wrote:
So what does Qt do when given a file name already using those PUA?
Looks like they get passed through untouched when decoded, but will
get translated into invalid names upon encoding.
Well, I'd say that looks like a bug. It should probably decode th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 7, 2008, at 6:01 PM, Barry Warsaw wrote:
I won't be able to cut another release between the 15th and 5th, so
at least that one should be 2 weeks. If we don't need the
additional rc, then we can release early, which would put us just
bef
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 7, 2008, at 4:28 PM, Guido van Rossum wrote:
15-Oct-2008 3.0 rc 2
05-Nov-2008 3.0 rc 3
19-Nov-2008 3.0 rc 4
03-Dec-2008 3.0 final
I've updated PEP 361 and the Google calendar with this schedule,
except that the PEP says that rc3 and r
Le mardi 07 octobre 2008 à 18:00 -0400, Barry Warsaw a écrit :
> On Oct 7, 2008, at 4:28 PM, Guido van Rossum wrote:
> > 15-Oct-2008 3.0 rc 2
> > 05-Nov-2008 3.0 rc 3
> > 19-Nov-2008 3.0 rc 4
> > 03-Dec-2008 3.0 final
>
> I'm okay with that too. It does seem odd to go back to beta then
> re
> How is this supposed to work?
The design was that you use PyState_FindModule, as an efficient way for
getting a module object if you have the module def. The implementation
fills an index into the module def (which will stay constant across
interpreters), this this should give you your module ob
Le mercredi 08 octobre 2008 à 00:00 +0200, "Martin v. Löwis" a écrit :
> You seem to think that the notion of "file system encoding"
> is also flawed - but do you infer from that that it also should be
> removed?
Under the condition we find something better, yes.
Otherwise, let's keep the heuristi
> The posix version should hardcode it as b'/'; I only meant windows to
> use UTF-16. You could perhaps use sys.getfilesystemencoding(), but
> I'm unsure what it does if the encoding isn't an ascii superset (or
> even if that can actually happen.)
POSIX has the notion of a "portable character set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 7, 2008, at 5:47 PM, Nick Coghlan wrote:
Barry Warsaw wrote:
On Oct 6, 2008, at 9:48 PM, Raymond Hettinger wrote:
[Barry Warsaw]
So, we need to come up with a new release schedule for Python 3.0.
My suggestion:
15-Oct-2008 3.0 beta 4
05-
Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>> I expect that the only effect of this change would be that the
>> filesystem encoding would become the de-facto default encoding for
>> other contexts as well.
>
> But there is no such thing as "the" filesystem encoding (except in Py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 7, 2008, at 4:28 PM, Guido van Rossum wrote:
On Mon, Oct 6, 2008 at 5:47 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
So, we need to come up with a new release schedule for Python 3.0.
My
suggestion:
15-Oct-2008 3.0 beta 4
05-Nov-2008 3.0
> Do we need the full two weeks between rc's?
If they are just other names for betas, yes. If they are true
release candidates (in the sense of "we really want to release this
as-is unless somebody tells us why this is a really bad idea"), then
no.
> Or is it too much of a pain
> to cut releases
Barry Warsaw wrote:
> On Oct 6, 2008, at 9:48 PM, Raymond Hettinger wrote:
>
>> [Barry Warsaw]
>>> So, we need to come up with a new release schedule for Python 3.0.
>>> My suggestion:
>>> 15-Oct-2008 3.0 beta 4
>>> 05-Nov-2008 3.0 rc 2
>>> 19-Nov-2008 3.0 rc 3
>>> 03-Dec-2008 3.0 final
>>> Give
Terry Reedy <[EMAIL PROTECTED]> wrote:
> Mark Seaborn wrote:
> > It appears that unbound methods do what you want in the general case
> > in Python 2.5 and 2.6. It's just that __lt__ behaves unlike normal
> > unbound methods. So this isn't an argument against unbound methods,
> > it's an argumen
Guido van Rossum python.org> writes:
>
> I expect that the only effect of this change would be that the
> filesystem encoding would become the de-facto default encoding for
> other contexts as well.
But there is no such thing as "the" filesystem encoding (except in Python's
simplified heuristics
On 2008-10-07 22:18, Fred Drake wrote:
> On Oct 7, 2008, at 4:06 PM, Martin v. Löwis wrote:
>> b) I would propose that the notion of a default encoding is entirely
>> eliminated from Python, along with sys.(get|set)defaultencoding
>
> +1
As already mentioned in my reply to Viktor: +1. It's n
On Tue, Oct 7, 2008 at 9:51 AM, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Oct 7, 2008, at 3:47 AM, Martin v. Löwis wrote:
>>>
>>> - Having os.getcwdb isn't much use when you can't even run python in
>>> the first place when the current directory has "bad" bytes in it.
>>
>> That's not true: it
Guido van Rossum wrote:
On Mon, Oct 6, 2008 at 5:47 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
So, we need to come up with a new release schedule for Python 3.0. My
suggestion:
15-Oct-2008 3.0 beta 4
05-Nov-2008 3.0 rc 2
19-Nov-2008 3.0 rc 3
03-Dec-2008 3.0 final
Given what still needs to be
On Tue, Oct 7, 2008 at 1:18 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Oct 7, 2008, at 4:06 PM, Martin v. Löwis wrote:
>>
>> b) I would propose that the notion of a default encoding is entirely
>>eliminated from Python, along with sys.(get|set)defaultencoding
>
> +1
I expect that the only
On Mon, Oct 6, 2008 at 5:47 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> So, we need to come up with a new release schedule for Python 3.0. My
> suggestion:
>
> 15-Oct-2008 3.0 beta 4
> 05-Nov-2008 3.0 rc 2
> 19-Nov-2008 3.0 rc 3
> 03-Dec-2008 3.0 final
>
> Given what still needs to be done, is t
On Oct 7, 2008, at 4:06 PM, Martin v. Löwis wrote:
b) I would propose that the notion of a default encoding is entirely
eliminated from Python, along with sys.(get|set)defaultencoding
+1
-Fred
--
Fred Drake
___
Python-3000 mailing list
P
James Y Knight wrote:
> or at least fully recognized and documented as a half-baked
> solution.
I would prefer that, leaving a full resolution to 3.1 (or perhaps 3.2).
If we wait long enough, the issue will disappear (a strategy that Sun
is apparently taking for Java :-)
Regards,
Martin
_
> First of all, please read my document:
> http://wiki.python.org/moin/Python3UnicodeDecodeError
I have problems understanding that document. Is it supposed to
be a PEP (i.e. a proposal to enhance Python), or is it a description
of the status quo?
If it is a PEP, it should clearly separate status
> More specifically, I think 2to3 is shaping up well. pywin32 is taking the
> approach of "port where possible, but keep in py2x syntax and convert at
> 'setup.py' time" and this is working out fairly well
I can't say how glad I am that you say that. It supports lib2to3 being a
proper library, de
James Y Knight wrote:
FWIW: Qt works fine with undecodeable filenames, and it too uses unicode
strings everywhere in its API. I looked into what it does, and found
that it uses your (Martin)'s original idea for solving this: it stores
undecodeable bytes as characters from 0x10fe00 to 0x10feff
Guido van Rossum schrieb:
> Someone please fix the PEP. There are very good reasons for *not*
> allowing "except X, Y:" to have a meaning -- if 2.x code somehow
> accidentally ended up in the 3.0 world without having been run through
> 2to3, it would silently perturb the meaning in the most confusi
On Oct 7, 2008, at 3:47 AM, Martin v. Löwis wrote:
- Having os.getcwdb isn't much use when you can't even run python in
the first place when the current directory has "bad" bytes in it.
That's not true: it *is* of much use. Python will live in /usr/bin,
which has a nicely-decodable path.
Curr
Nick Coghlan wrote:
(added Michael to the CC list)
It isn't object that has grown an __lt__ method, but type. The extra
check Michael actually wants is a way to make sure that the method isn't
coming from the object's metaclass, and the only reliable way to do that
is the way collections.Hashabl
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> > - And then, getopt and optparse modules should work on bytestring
> > vectors, so that you can use sys.argvb without writing your own
> > argument parser. They don't currently.
>
> Then we will gradually start moving all modules even remotely re
Hello,
Extension modules have a new "md_state" member, I understand that it
is designed to hold the "static" state of the module.
IIUC, for example in _cpickle.c, the "PyObject *dispatch_table"
variable is a good candidate for such module state.
This would allow to play more nicely with multiple s
Antoine Pitrou wrote:
Hi,
James Y Knight fuhm.net> writes:
- Having os.getcwdb isn't much use when you can't even run python in
the first place when the current directory has "bad" bytes in it.
I don't agree it's a similar problem. Python should be installed in a well-known
place with a s
2008/10/6 Raymond Hettinger <[EMAIL PROTECTED]>:
>> 15-Oct-2008 3.0 beta 4
>> 05-Nov-2008 3.0 rc 2
>> 19-Nov-2008 3.0 rc 3
>> 03-Dec-2008 3.0 final
>>
>> Given what still needs to be done, is this a reasonable schedule? Do we
>> need two more betas?
>
> Yes to both questions.
I agree with you h
Hi,
James Y Knight fuhm.net> writes:
>
> - Having os.getcwdb isn't much use when you can't even run python in
> the first place when the current directory has "bad" bytes in it.
I don't agree it's a similar problem. Python should be installed in a well-known
place with a sensible path. Of
(added Michael to the CC list)
It isn't object that has grown an __lt__ method, but type. The extra
check Michael actually wants is a way to make sure that the method isn't
coming from the object's metaclass, and the only reliable way to do that
is the way collections.Hashable does it when looking
Hi,
First of all, please read my document:
http://wiki.python.org/moin/Python3UnicodeDecodeError
I moved the document to a public wiki to allow anyone to edit it!
Le Tuesday 07 October 2008 05:22:09 James Y Knight, vous avez écrit :
> On Oct 6, 2008, at 8:52 PM, Benjamin Peterson wrote:
> > I'm
> Here's some I found from a few minutes of futzing around with r66821 of
> py3k on Linux.
>
> - Having os.getcwdb isn't much use when you can't even run python in
> the first place when the current directory has "bad" bytes in it.
That's not true: it *is* of much use. Python will live in /usr/b
36 matches
Mail list logo
