> 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
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
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
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
(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,
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
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
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
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
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
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
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
> 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
> 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
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
_
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
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 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
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 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
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
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
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
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
> 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
-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
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 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-
> 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
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
> 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 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
-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
-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
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
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
36 matches
Mail list logo
