> at such a script, which I promptly stopped looking at as soon as it
> worked
Which is quite obvious really given that:
> # nuke ourselves from argv
> del sys.argv[1]
is removing the wrong value!
Mark
___
Python-Dev mailing list
Python-Dev@python.or
> > * Better support for 2to3 in distutils (specifically, the support in
> > build_py is stale, plus 'build_scripts' and 'install_data' should
> > convert
> > .py files to py3k syntax.)
>
> Please do create a bug report for that. It sounds like it's easy to
> fix.
Yeah, build_py is fairly easy to
I've begun the task of assessing the 2.6 commits, but the job is
unexpectedly large.
What I did:
* Took the output of 'svn log -r60999:66717'. (2.5.2 was branched
from rev. 60999, so I'm ignoring commits to the trunk before 2.5.2 was
branch, which may miss some things.)
* Wrote a little sc
Christian Heimes wrote:
> Guido van Rossum wrote:
[...]
>> I have no intention of rolling this back. It isn't compatible with
>> 3.0, but then, 2.6 and 3.0 aren't in general meant to be compatible --
>> 2.6 is a stepping stone, but that's not the same thing. It is
>> backwards compatible with prior
Guido van Rossum wrote:
It was well understood that the bytes "type" in 2.6 and the bytes type
in 3.0 would behave quite different. Attempts to come up with a
separate bytes type that behaved more like its 3.0 counterpart were
doomed, because there just are too many places where the usage was
amb
On Oct 7, 2008, at 23:31, Martin v. Löwis wrote:
In V3 is it your intention that to be a key you must implement
tp_hash and tp_richcompare? If not I'll raise a bug against
3.0 on this issue.
I believe that cmp/tp_compare are being phased out, although
I think there was a heavy debate about th
> In V3 is it your intention that to be a key you must implement
> tp_hash and tp_richcompare? If not I'll raise a bug against
> 3.0 on this issue.
I believe that cmp/tp_compare are being phased out, although
I think there was a heavy debate about this.
In any case, I think you really need to imp
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
-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-
-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
On Oct 5, 2008, at 19:47, Martin v. Löwis wrote:
Why does "key in wc_status_kind_wc" work when I use an object
returned
by keys() by not when I use pysvn.wc_status_kind.unversioned?
This is too little detail to come up with an explanation. Do your
objects support __eq__.
Regards,
Martin
> 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
Allow me to suggest that these get some attention:
http://bugs.python.org/issue3677
http://bugs.python.org/issue3367
Kristján
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
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
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 Tue, Oct 07, 2008 at 09:27:24AM +0200, "Martin v. Löwis" wrote:
> Within a few weeks, we will release Python 2.5.3. This will be the last
> bug fix release of Python 2.5, afterwards, future releases of 2.5 will
> only include security fixes, and no binaries (for Windows or OSX) will
> be provide
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-Dev mailing list
Py
On Sun, Oct 5, 2008 at 11:43 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> This does make it look rather as though bytes == str was a decision
> whose consequences weren't fully appreciated before implementation.
>
> Was this horror anticipated?
It was well understood that the bytes "type" in 2.6
>> Given that p.we.x seems to always return the same object (since the
>> hashes, which which appear to be ids, are the same), an __eq__ method
>> (which gets called in preference to __cmp__), possibly inherited, that
>> always return False is the only thing I can think of. (Hence Martin's
>> ques
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
On Oct 5, 2008, at 22:49, Terry Reedy wrote:
Given that p.we.x seems to always return the same object (since the
hashes, which which appear to be ids, are the same), an __eq__
method (which gets called in preference to __cmp__), possibly
inherited, that always return False is the only thin
> Just to emphasize this, "changes" means "bugfixes". (I'm mentioning this
> mainly because of the people who joined for 2.6/3.0.) For more info,
> see PEP6 about bugfix releases:
> http://www.python.org/dev/peps/pep-0006/
Thanks for clarifying this. For the last 2.5.x release in particular, we
On Oct 5, 2008, at 22:49, Terry Reedy wrote:
Barry Scott wrote:
for key in [pysvn.wc_status_kind.added,
pysvn.wc_status_kind.replaced,
pysvn.wc_status_kind.unversioned]:
print( '2 key', key, key in wc_status_kind_map, cmp( key,
pysvn.wc_status_kind.unversioned ),
> 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
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
On Tue, Oct 07, 2008, "Martin v. L?wis" wrote:
>
> In principle, the release will include all changes that are already on
> the release25-maint branch in subversion [1]. If you think that specific
> changes should be considered, please create an issue in the bug tracker
> [2], and label it with th
[when 2 mailing lists are not enough... :-]
> I'm seeing that people are just starting to download and play with 3.0.
> I expect that we'll start getting more feedback on conversion issues
+1 from this direction too. pywin32 has recently started looking seriously
at py3k, and while things are in
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
Raymond Hettinger rcn.com> writes:
>
> The 2.6/3.0 development process was so disruptive that I doubt
> that 2.5 received adequate attention for bug fixes. Why not wait
> two or three months for the dust to settle?
I know that I, and a couple of others, have tried to backport "important" bug
fi
On Tue, 2008-10-07 at 11:30 +0200, Victor Stinner wrote:
> > - I'd think "find . -type f -print0 | xargs -0 python -c 'pass'"
> > ought to work (with files with "bad" bytes being returned by find),
>
> First, fix your home directory :-) There are good tools (convmv?) to fix
> invalid filenames.
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
Within a few weeks, we will release Python 2.5.3. This will be the last
bug fix release of Python 2.5, afterwards, future releases of 2.5 will
only include security fixes, and no binaries (for Windows or OSX) will
be provided anymore (from python.org).
In principle, the release will include all ch
> ISTM, that 3.0 and 2.6 backports have consumed substantial developer
> attention over the last few months.
Sure - but who is going to sit down and study the commit logs, to do
backporting? Unless someone specifically volunteers to do that (with
a specific timeline when he will start, and when he
40 matches
Mail list logo
