[Python-Dev] In Python 2.6, bytes is str (fwd)
Saw this on python-list. I suspect it's a known issue, but just in case, I thought I'd pass it along. Skip --- Begin Message --- 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 be dict keys. There's a mutable version too, called "bytearray". In Python 2.6, the name 'bytes' is defined, and bound to str. The 2.6 assignment presents some pitfalls. Be aware. Consider constructing a bytes object as: b = bytes([68, 255, 0]) In Python 3.x, len(b) will be 3, which feels right. In Python 2.6, len(b) will be 12, because b is the str, '[68, 255, 0]'. I'm thinking I should just avoid using 'bytes' in Python 2.6. If there's another Python release between 2.6 and 3.gold, I'd advocate removing the pre-defined 'bytes', or maybe defining it as something else. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list --- End Message --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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 likely that they > come up with things like Sorry, I was not advising that structure, just mentioning that if you'll follow it, don't include the minor version, just the major one. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Fwd: In Python 2.6, bytes is str]
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 in 2.6 - yes, that's not the same thing as what they represent in 3.0, and no, you don't magically get the benefits of byte/str separation in the 2.x series. Maybe that could be caveat'ed better somewhere in the docs, but it does reflect the reality of the situation. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future __ import planning)
Martin v. Löwis 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 information in the standard PyPI site where people look for Python 2.x packages. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
2008/10/6 Antoine Pitrou <[EMAIL PROTECTED]>: > Martin v. Löwis 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 information in the > standard PyPI site where people look for Python 2.x packages. Agreed. Although there are significant differences to consider, I think the last thing we want to do is to encourage the impression that Python 3 is a different language from Python 2. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] status of 2.5
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, it will be clean and easy. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of 2.5
[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 release for 2.5, it will be clean and easy. 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? Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of 2.5
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 security release for 2.5, it will be clean and easy. That is my plan also. I would like to release 2.5.2 two weeks after Python 3.0, or on November 1st, whatever happens later (and it seems that Python-3-plus-two-weeks happens later). So one week after Python 3, there would be a release candidate, and two weeks, the final release. Simultaneously, I would also release 2.4.6. If people think 2.5.2 should be released earlier than that, please let me know. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of 2.5
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of 2.5
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 * we haven't been backporting fixes to 2.5? * we should wait to see if any horrible problems are reported in 2.6? * we need to look at the logs for commits that should be applied to 2.5? --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an Python account
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 issues. Most issuses are specific to Python3. === Fix bugs === [Py3k] line number is wrong after encoding declaration (2008-03-18) http://bugs.python.org/issue2384 |--> one liner fix \--> patch + testcase compile() cannot decode Latin-1 source encodings (2008-08-17) http://bugs.python.org/issue3574 \--> patch + multiple tests (eg. test_pep3120.py) PyTraceBack_Print() doesn't respect # coding: xxx header (2008-09-26) http://bugs.python.org/issue3975 |--> complex patch: rewrite _Py_DisplaySourceLine() to support unicode |--> patch \--> a testcase is included in the related issue: issue2384 IDLE: checksyntax() doesn't support Unicode? (2008-10-01) http://bugs.python.org/issue4008 |--> refactoring to reuse tokenizer.detect_encoding() \--> patch missing newline in "Could not convert argument %s to string" error message (2008-09-30) http://bugs.python.org/issue4004 |--> trivial fix \--> patch === Improvments === Support bytes for os.exec*() (2008-10-03) http://bugs.python.org/issue4035 Support bytes for subprocess.Popen() (2008-10-03) http://bugs.python.org/issue4036 -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of 2.5
[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 look at the logs for commits that should be applied to 2.5? Yes. That would be a great idea too. ISTM, that 3.0 and 2.6 backports have consumed substantial developer attention over the last few months. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of 2.5
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 way if we put out a security release for 2.5, it will be clean and easy. That is my plan also. I would like to release 2.5.2 two weeks after Python 3.0, or on November 1st, whatever happens later (and it seems that Python-3-plus-two-weeks happens later). You of course meant 2.5.3. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposed Python 3.0 schedule
-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 need two more betas? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSOqxvnEjvBPtnXfVAQIR5QP/coSi2ltsZSpE2dyUg7Y35QcSk/+4ZbGK zF0AgLaOkGs+DFnxRH9vy9kN3JaEkp1MhEpDjkomE7kNpnJB7bWotTrHI67HD9ma ZDqqmaCc02IeUtLm7HuELvofjCgh+gryKWvRc71ErRHmn/YxMGr1OcEirPpx4nZ9 DeDV0OeUtTE= =RchU -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Proposed Python 3.0 schedule
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 > > Given what still needs to be done, is this a reasonable schedule? Do we > need two more betas? 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. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed Python 3.0 schedule
[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 both questions. 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, the C API, screwy interactions with operating systems, bytes/text issues, unanticipated interactions with other tools, etc. Each user will stress it in new ways and perhaps reveal a bunch of little integration issues and documentation issues. Those little fixups way go a long way toward establishing a good first impression and reputation for 3.0 from the outset. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed Python 3.0 schedule
-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 what still needs to be done, is this a reasonable schedule? Do we need two more betas? Yes to both questions. I think that's contradictory :). If we need two betas, then 05-Nov becomes beta 5, 19-Nov is rc 2. If we don't need another rc then we can still do a final release on 03-Dec, otherwise we probably go 2 weeks later. I don't want to go much later than that though because then we get into the holiday season. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSOrFs3EjvBPtnXfVAQJceQP/QJN7oLM4nG+iXmgdb0NmKzOzaE3J89sQ UWZnc/hp618QNH4JWC8v2bYApFu+iVg3pcv1Lnmhuql6mOuDhSuKKJVA5jTdR7U2 2enhAEY2DXtmav/29nn2Fy6PYcWJy9pE2xBsbBW8qXc6tYww0iEBsz9SU68jPzPk x5LFC5NqmXo= =Kyr4 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Proposed Python 3.0 schedule
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"
allow access to all system APIs using either byte or unicode strings,
then it seems to me that there's a rather large amount of work left to
do...
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.
Currently Python outputs:
Could not find platform independent libraries
Could not find platform dependent libraries
Consider setting $PYTHONHOME to [:]
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8
Aborted
- I'd think "find . -type f -print0 | xargs -0 python -c 'pass'"
ought to work (with files with "bad" bytes being returned by find),
which means that Python shouldn't blow up and refuse to start when
there's a non-properly-encoding argv ("Could not convert argument 1 to
string" and exiting isn't appropriate behavior).
- Of course, just being able to start the interpreter isn't quite
enough: you'll want to be able to access that argument list too,
somehow (add sys.argvb?).
- 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.
- There's no os.environb for bytewise access to the environment.
Seems important.
- Isn't it a potential security issue that " 'WHATEVER' in
os.environ" can return False if WHATEVER had some "bad" bytes in it,
but spawning a subprocess actually will include WHATEVER in the
subprocess's environment? Actually, even better: the behavior depends
on whether you use subprocess.call('foo') or subprocess.call('foo',
os.environ). The first passes through the "bad" environment variables,
while the second does not. A bit surprising, perhaps.
- Shouldn't this work?
subprocess.call(b'/bin/echo')
Currently raises an exception:
AttributeError: 'int' object has no attribute 'rfind'
- I suppose sys.path should handle bytestrings on the path, and
should be populated using the bytes-version of os.environ so that
PYTHONPATH gets read in properly. Which of course implies that all the
importers need to handle byte filenames.
- zipfile.ZipFile(b'whatever.zip') doesn't work.
- zipfile decodes/encodes the filenames inside the zip file to
unicode, so thus can only handle correctly encoded filenames.
I'm sure there's even more APIs dealing with pathnames, command line
arguments, or environment variables that ought to be able to handle
both bytes and strings, that currently don't.
James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
