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
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
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/bin,
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.
Fixing
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
[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
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 the
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 here.
I'm
Raymond Hettinger python at 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
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.
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,
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
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
will
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
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
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
question, I
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 and the
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 fdrake at acm.org
___
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 provided
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 this a
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 effect of
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 *is* of much
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 not
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:
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
Given what still needs to be
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 3
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
-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
-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
-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
-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
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
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
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
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
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
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
* 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 fix, but
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.org
40 matches
Mail list logo
