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.
Well, you could say that about almost any change.
Was this horror anticipated?
I
Saw this on python-list. I suspect it's a known issue, but just in case, I
thought I'd pass it along.
Skip
---BeginMessage---
Python 3 has the 'bytes' type, which the string type I've long wanted in
various languages. Among other advantages, it is immutable, and
therefore bytes objects can
2008/10/5 Martin v. Löwis [EMAIL PROTECTED]:
foobar-1.0-py2.6.tar.gz
foobar-1.0-py3.0.tar.gz
More likely, in this way:
foobar-1.0-py2.tar.gz
foobar-1.0-py3.tar.gz
How do you implement this in distutils? People probably won't rename
the files from how sdist names them. So it's more
Brett Cannon wrote:
What I would like to know if there are any other gotchas beyond the
constructor as all of the other uses act as you would expect.
Mainly that indexing returns one character substrings instead of ints.
The bytes type is there as an indicator of what bytes literals represent
2008/10/6 Antoine Pitrou [EMAIL PROTECTED]:
Martin v. Löwis martin at v.loewis.de writes:
Although it would be possible, I think it's not appropriate.
I also think it's inappropriate. We want people to know about the existence of
Python 3, and the best for that is to have Python 3-related
Should we plan to put out a final 2.5 release? If so, should we
continue to backport fixes (like Martin's removal of Alpha in
setup.py)? My preference is that we do put out a final 2.5 that has
all accumulated bug fixes. Then close the branch. That way if we put
out a security release for 2.5,
Neal Should we plan to put out a final 2.5 release?
I'm probably a bad person to ask. At work we are still using 2.4. :-/
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
[Neal Norwitz]
Should we plan to put out a final 2.5 release? If so, should we
continue to backport fixes (like Martin's removal of Alpha in
setup.py)? My preference is that we do put out a final 2.5 that has
all accumulated bug fixes. Then close the branch. That way if we put
out a security
Neal Norwitz wrote:
Should we plan to put out a final 2.5 release? If so, should we
continue to backport fixes (like Martin's removal of Alpha in
setup.py)? My preference is that we do put out a final 2.5 that has
all accumulated bug fixes. Then close the branch. That way if we put
out a
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?
Would it receive more attention in the next three months? Who
specifically would give it that attention?
Regards,
Martin
On Mon, Oct 06, 2008 at 12:53:01PM -0700, Raymond Hettinger wrote:
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?
Can you please clarify your meaning? Do you mean that
Hi,
Brett gave me permissions to edit the bug tracker, yeah!
I also would like an SVN account
If I can't get an account, can anyone review my issues and/or commit the
attached patches? Most contributions are recent but I'm waiting for some of
these issues to be fixed before fixing other
[A.M. Kuchling]
Can you please clarify your meaning? Do you mean that
* we haven't been backporting fixes to 2.5?
Unsure. I surely have given zero attention to 2.5.
* we should wait to see if any horrible problems are reported in 2.6?
Yes. That would be a great idea.
* we need to
Martin v. Löwis wrote:
Neal Norwitz wrote:
Should we plan to put out a final 2.5 release? If so, should we
continue to backport fixes (like Martin's removal of Alpha in
setup.py)? My preference is that we do put out a final 2.5 that has
all accumulated bug fixes. Then close the branch. That
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 reasonable schedule? Do
we
On Mon, Oct 6, 2008 at 7:47 PM, Barry Warsaw [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
[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 done, is this a reasonable schedule? Do
we need two more betas?
Yes to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
On Oct 6, 2008, at 8:52 PM, Benjamin Peterson wrote:
I'm not sure we do. Correct me if I'm wrong, but the big ticket,
issue bytes/unicode filepaths, has been resolved. And looking at the
tracker, I only see 18 release blockers.
Well, if you mean that the resolution decided upon is to simply
19 matches
Mail list logo
