Mailman 3 June 2010 - Python-Dev

Re: [Python-Dev] bytes / unicode
by P.J. Eby 23 Jun '10

23 Jun '10

At 07:41 AM 6/23/2010 +1000, Nick Coghlan wrote: >Then my example above could be made polymorphic (for ASCII compatible >encodings) by writing: > > [x for x in seq if x.endswith(x.coerce("b"))] > >I'm trying to see downsides to this idea, and I'm not really seeing >any (well, other than 2.7 being almost out the door and the fact we'd >have to grant ourselves an exception to the language moratorium) Notice, however, that if multi-string operations used a coercion protocol (they currently have to do type checks already for byte/unicode mixes), then you could make the entire stdlib polymorphic by default, even for other kinds of strings that don't exist yet. If you invent a new numeric type, generally speaking you can pass it to existing stdlib functions taking numbers, as long as it implements the appropriate protocols. Why not do the same for strings?

1 0

State of json in 2.7
by Dirkjan Ochtman 23 Jun '10

23 Jun '10

It looks like simplejson 2.1.0 and 2.1.1 have been released: http://bob.pythonmac.org/archives/2010/03/10/simplejson-210/ http://bob.pythonmac.org/archives/2010/03/31/simplejson-211/ It looks like any changes that didn't come from the Python tree didn't go into the Python tree, either. I guess we can't put these changes into 2.7 anymore? How can we make this better next time? Cheers, Dirkjan

5 4

adding new function
by lesni bleble 22 Jun '10

22 Jun '10

hello, how can i simply add new functions to module after its initialization (Py_InitModule())? I'm missing something like PyModule_AddCFunction(). thank you L.

2 1

Re: [Python-Dev] email package status in 3.X
by P.J. Eby 22 Jun '10

22 Jun '10

At 08:08 AM 6/21/2010 +1000, Nick Coghlan wrote: >Perhaps if people could identify which specific string methods are >causing problems? __getitem__(int) returns an integer rather than a bytestring, so anything that manipulates individual characters can't be given bytes and have it work. That was one of the key differences I had in mind for a bstr type, apart from designing it to coerce normal strings to bstrs in cross-type operations, and to allow O(1) "conversion" to/from bytes. Another randomly chosen byte/string incompatibility (Python 3.1; I don't have 3.2 handy at the moment): >>> os.path.join(b'x','y') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "c:\Python31\lib\ntpath.py", line 161, in join if b[:1] in seps: TypeError: Type str doesn't support the buffer API >>> os.path.join('x',b'y') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "c:\Python31\lib\ntpath.py", line 161, in join if b[:1] in seps: TypeError: 'in <string>' requires string as left operand, not bytes Ironically, it seems to me that in trying to make the type distinction more rigid, Py3K fails in this area precisely because it is not a rigidly typed language in the Java or Haskell sense: i.e., os.path.join doesn't say, "I need two stringlike objects of the *same type*", not even in its docstring. At least in Java, you would either implement a "path" type with coercions from bytes and strings, or you'd have a class with overloaded methods for handling join operations on bytes and strings, respectively, thereby avoiding this whole mess. (Alas, this little example on the 'in' operator also shows that my bstr effort would probably fail anyway, because there's no '__rcontains__' (__lcontains__?) to allow it to override the str type's __contains__.)

11 30

Re: [Python-Dev] email package status in 3.X
by Jess Austin 22 Jun '10

22 Jun '10

On Mon, Jun 22, 2010 at 7:27:31 PM, Steven D'Aprano <steve(a)pearwood.info> wrote: > On Tue, 22 Jun 2010 08:03:58 am Nick Coghlan wrote: >> So, to boil down the ebytes idea, it is basically a request for a >> second string type that holds an octet stream plus an encoding name, >> rather than a Unicode character stream. > > Do any other languages have any equivalent to this ebtyes type? Ruby seems to do this: http://yokolet.blogspot.com/2009/07/design-and-implementation-of-ruby-m17n.… I don't use ruby myself, and I'm probably missing some subtle flaws, but the exposition at that link makes sense to me. cheers, Jess

1 0

Re: [Python-Dev] bytes / unicode
by P.J. Eby 22 Jun '10

22 Jun '10

At 10:51 PM 6/21/2010 +1000, Nick Coghlan wrote: >It may be that there are places where we need to rewrite standard >library algorithms to be bytes/str neutral (e.g. by using length one >slices instead of indexing). It may be that there are more APIs that >need to grow "encoding" keyword arguments that they then pass on to >the functions they call or use to convert str arguments to bytes (or >vice-versa). But without people trying to port affected libraries and >reporting bugs when they find issues, the situation isn't going to >improve. > >Now, if these bugs are already being reported against 3.1 and just >aren't getting fixed, that's a completely different story... The overall impression, though, is that this isn't really a step forward. Now, bytes are the special case instead of unicode, but that special case isn't actually handled any better by the stdlib - in fact, it's arguably worse. And, the burden of addressing this seems to have been shifted from the people who made the change, to the people who are going to use it. But those people are not necessarily in a position to tell you anything more than, "give me something that works with bytes". What I can tell you is that before, since string constants in the stdlib were ascii bytes, and transparently promoted to unicode, stdlib behavior was *predictable* in the presence of special cases: you got back either bytes or unicode, but either way, you could idempotently upgrade the result to unicode, or just pass it on. APIs were "str safe, unicode aware". If you passed in bytes, you weren't going to get unicode without a warning, and if you passed in unicode, it'd work and you'd get unicode back. Now, the APIs are neither safe nor aware -- if you pass bytes in, you get unpredictable results back. Ironically, it almost *would* have been better if bytes simply didn't work as strings at all, *ever*, but if you could wrap them with a bstr() to *treat* them as text. You could still have restrictions on combining them, as long as it was a restriction on the unicode you mixed with them. That is, if you could combine a bstr and a str if the *str* was restricted to ASCII. If we had the Python 3 design discussions to do over again, I think I would now have stuck with the position of not letting bytes be string-compatible at all, and instead proposed an explicit bstr() wrapper/adapter to use them as strings, that would (in that case) force coercion in the direction of bytes rather than strings. (And bstr need not have been a builtin - it could have been something you import, to help discourage casual usage.) Might this approach lead to some people doing things wrong in the case of porting? Sure. But there'd be little reason to use it in new code that didn't have a real need for bytestring manipulation. It might've been a better balance between practicality and purity, in that it keeps the language pure, while offering a practical way to deal with things in bytes if you really need to. And, bytes wouldn't silently succeed *some* of the time, leading to a trap. An easy inconsistency is worse than a bit of uniform chicken-waving. Is it too late to make that tradeoff? Probably. Certainly it's not practical to *implement* outside the language core, and removing string methods would fux0r anybody whose currently-ported code relies on bytes objects having string-like methods.

4 5

Adding additional level of bookmarks and section numbers in python pdf documents.
by Peng Yu 22 Jun '10

22 Jun '10

Hi, Current pdf version of python documents don't have bookmarks for sussubsection. For example, there is no bookmark for the following section in python_2.6.5_reference.pdf. Also the bookmarks don't have section numbers in them. I suggest to include the section numbers. Could these features be added in future release of python document. 3.4.1 Basic customization -- Regards, Peng

2 1

[RELEASED] Python 2.7 release candidate 2
by Benjamin Peterson 22 Jun '10

22 Jun '10

On behalf of the Python development team, I'm tickled pink to announce the second release candidate of Python 2.7. Python 2.7 is scheduled (by Guido and Python-dev) to be the last major version in the 2.x series. However, 2.7 will have an extended period of bugfix maintenance. 2.7 includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7 visit: http://www.python.org/download/releases/2.7/ While this is a preview release and is thus not suitable for production use, we strongly encourage Python application and library developers to test the release with their code and report any bugs they encounter to: http://bugs.python.org/ This helps ensure that those upgrading to Python 2.7 will encounter as few bumps as possible. 2.7 documentation can be found at: http://docs.python.org/2.7/ Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7's contributors)

1 0

Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)
by Nick Efford 21 Jun '10

21 Jun '10

> I'm sorry if you had the impression people wanted to nail you at the > stake for using Python 3. If that's how you felt, it isn't true. I > basically agree with Glyph. I don't think we've recently (I'm not > omnipresent) told anyone who had any good reasons to to stop using > Python 3. If someone's doing work that actually needs Python 3 (most > recent example a GSOC student porting Sphinx), we try our best to > help, and AFAICT we've mostly been successful. (Please correct me if > you think this is erroneous.). We don't get too many people that > actually want or need that, but I'm guessing that's mostly because > people porting libraries to py3k usually already know what they're > doing so they don't need the first-line-of-defense thing for Python > questions that #python tries to be. Thanks for explaining your position on this so carefully, Laurens. You've made many reasonable points which I hope will help to cool things down a little. Clearly, there are situations where it makes sense to advocate Python 2.X and other situations where people can be encouraged to consider Python 3. The issues that potential users need to consider are too subtle to be represented fairly by the simple advice to 'avoid Python 3', so can we not all agree to remove it as a #python topic as a gesture of goodwill? Nobody need change their opinions or adovacy as a result, but it would have the benefit of presenting #python in a more neutral and inclusive light. I've not used IRC much in the past, but if it would be useful for someone like myself - a longtime Python user but recent and enthusiastic Python 3 adopter - to offer my opinions and advice on the issue to newcomers then I'm certainly willing to get involved. > We're still telling people to use Python 2.x by default because of a > few major things: > > 1. going out on a limb here: well over 90% of those people are > completely new to Python and out of those most of them completely new > to programming too, Not sure if I agree with you here; I regard people new to programming as the prime candidates for using Python 3. Many of the language changes have the effect of making it significantly easier to learn for newcomers (I wrote about this a while ago - see http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html). Also, people new to Python or programming in general won't have the burden of legacy code that needs to be converted. The only situation in which I'd direct someone new to programming away from Python 3 would be if they had a specific need to use a library that wasn't yet supported. > 2. the nicest libraries for doing a lot of stuff aren't ported yet, or > are in the process of being ported but not yet recommended for actual > use by their authors, (this seems to be a point of contention?) This has certainly been the key issue for me. Only in the past two or three months have we got to the point where I feel can commit to Python 3 fully. Six months ago, I definitely could not have done so. This is progress, and we need to be positive about it. Regards, Nick -- Dr Nick Efford, School of | E: N.D.Efford(a)leeds.ac.uk Computing, University of | T: +44 113 343 6809 Leeds, Leeds, LS2 9JT, UK | W: http://www.comp.leeds.ac.uk/nde/ --------------------------+----------------------------------------- PGP fingerprint: 6ADF 16C2 4E2D 320B F537 8F3C 402D 1C78 A668 8492

4 4

issue 8959
by Benjamin Peterson 21 Jun '10

21 Jun '10

We currently have one release blocker for 2.7: http://bugs.python.org/issue8959 It is a Windows and a ctypes regression. As far as I can tell, the offending revision could just be reverted but it does not merge cleanly. Can anyone offer more expertise? -- Regards, Benjamin

1 0