Mailman 3 February 2003 - Python-Dev

Re: [Python-Dev] when is binary mode required for pickle?
by Gareth McCaughan Feb. 13, 2003

Feb. 13, 2003

Guido wrote: > For most people, yes. "bin" is deprecated, "proto" should not be named > (cPickle doesn't accept keyword arguments), and passing -1 is the best thing > to do if you don't care about reading a pickle under an older version of > Python than the one that wrote the pickle. For compatibility reasons, > though, the default proto value had to remain 0. Suggestion: pickle.LATEST_PROTOCOL = cPickle.LATEST_PROTOCOL = -1 ? (It could be spelled differently.) Or the string value "latest" could be an acceptable value of proto. Or something. Anything rather than magic numbers. :-) -- g

2 1

Change definition of Py_END_ALLOW_THREADS?
by Mark Hammond Feb. 13, 2003

Feb. 13, 2003

Hi all, As part of my "auto thread state" work, I am discovering some very interesting things - including the fact that pythread.h *already* defines a Python Thread Local Storage API, and that thread_sgi.h contains a safe, portable working implementation :) However, to do this auto thread state work properly, I will need to change the definition of Py_END_ALLOW_THREADS. Specifically, Py_END_ALLOW_THREADS needs to be able to handle the fact that the lock may or may not be held when it is called (whereas now, the lock must *not* be held) Specifically, the changes would look like: * New function to determine if the current thread's threadstate is "current" * New function, PyEval_EnsureThread(), which is nearly identical to PyEval_RestoreThread(), except it only attempts the restore of the thread state if it is not already current. The above 2 are fairly easy to implement in a thread-safe manner - if the thread only checks its *own* thread state is current, the result of that check will remain valid on this thread, even if another thread becomes current during processing. This means that Py_END_ALLOW_THREADS then changes from: #define Py_END_ALLOW_THREADS PyEval_RestoreThread(_save); \ to: #define Py_END_ALLOW_THREADS PyEval_EnsureThread(_save); \ Now, I understand that a complete blessing of this scheme will need more details - but I am concerned that *any* change to Py_END_ALLOW_THREADS will blow this scheme out of the water. For example, the Win32 extensions have, in a few places, emulated Py_BEGIN_ALLOW_THREADS, and all of this code will need to change. From my POV though, the only reason I needed these hacks in the first place was due to an incomplete thread state API, so such changes are worthwhile to me. Other's mileage may vary. FWIW, I have a portable (ie, no windows specific code at all) "auto thread state" implementation fully working with the Win32all extensions. These extensions do some funky things with threads and thread-states, and it all works perfectly. However, it does rely on this Py_END_ALLOW_THREAD change. See the full patch at http://www.python.org/sf/684256 Thanks, Mark.

5 14

when is binary mode required for pickle?
by Skip Montanaro Feb. 13, 2003

Feb. 13, 2003

(I'm really not asking how to use pickle.) Unused as I am to programming on Windows, it's not clear to me under what circumstances I might need to open a file in binary mode for Pickle's consumption. The reason I ask is that while working on the csv PEP and module, we had some input complaining about our requirement that CSV files be opened with the 'b' flag (where it matters). Andrew mentioned that Pickle requires files be opened in binary mode. However, the documentation doesn't explicitly state this. Must, for example, a file be opened with the 'b' flag if an ASCII pickle is to be written? The doc for the Unpickler class says the file-like object must support both read(n) and readline() methods. The requirement for readline() suggests the file be opened in text mode. (Maybe this is just a nit with the Pickle docs and I don't know it?) Skip

4 4

Overly creative config in socketmodule.c
by Tim Peters Feb. 13, 2003

Feb. 13, 2003

Someone very recently checked in this change: static PyObject* socket_inet_aton(PyObject *self, PyObject *args) { #ifndef INADDR_NONE #define INADDR_NONE (-1) #endif /* Have to use inet_addr() instead */ char *ip_addr; #if 1 ... if (inet_aton(ip_addr, &buf)) return PyString_FromStringAndSize((char *)(&buf), ... sizeof(buf)); #else /* In case you don't have inet_aton() */ ... #endif } Now in case you were wondering, #if 1 #else #endif isn't a robust way to do platform configuration <wink/arghghgh>. Whoever did this, please back it out or do it right. inet_aton doesn't exist on Windows, so socketmodule.c no longer compiles there.

2 2

SF CVS down?
by Brett Cannon Feb. 13, 2003

Feb. 13, 2003

Or is just me? -Brett

2 2

[meta] EIBTI: can we acronimize?
by Lalo Martins Feb. 12, 2003

Feb. 12, 2003

I just realized I'm finally tired of typing "Explicit is better than implicit". Can we agree to call this maxim EIBTI? Or is this too implicit? ;-) []s, |alo +---- -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ GNU: never give up freedom http://www.gnu.org/

3 2

RE: some data on the debate [Python-Dev] Update to PEP308: if-then-else expression
by Chermside, Michael Feb. 12, 2003

Feb. 12, 2003

> The relevant data for me was that 1/4, 1/2 of the total posts were made by just > a small "vocal" group of people Please don't think I missed the importance of this fact. The details of the count were unimportant compared to what this says about how the perceived level of vigorous argument may actually be an artifact of a few outliers. I actually only posted thinking that there might be a bug in your counting algorithm... I still believe that in the end Guido will wind up finding a way to extract a reasonable decision from this mess, although I have a hard time seeing how he'll manage that! Knowing that a few individuals account for a lot of the "noise" may help him. -- Michael Chermside

2 1

Codecs data
by Gustavo Niemeyer Feb. 12, 2003

Feb. 12, 2003

I belive we have a problem in our current codecs implementation: it doesn't work for multiple interpreter states, because the data is currently statically allocated in codecs.c. That way, only the first interpreter is going to have the codecs lookup working. The following interpreters will try to cross the interpreter state boundary and use the lookup function from the first interpreter, issuing all kinds of weird errors. One solution would be to store that data in the "sys" module (e.g. codec_search_path, codec_search_cache, codec_inited). Can you please advice on how to fix that? I'll be willing to provide a fix with the proposed solution. -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

3 5

Re: some data on the debate [Python-Dev] Update to PEP308: if-then-else expression
by Chermside, Michael Feb. 12, 2003

Feb. 12, 2003

[Samuele Pedroni creates list of # of posts per person] I'm not quite sure how you generated this list, but I notice that I'm not on it. Now I *HAVE* been trying very hard to make FEW posts (but hopefully insightful ones), but I still made it to the threshold of 3. I don't particularly care about the list, but if Guido wants a listing of who's pro/con, then we shouldn't exclude people who have tried to REDUCE the amount of noise by posting a SMALL number of times. -- Michael Chermside

2 1

str.join, string.join
by Christian Tismer Feb. 11, 2003

Feb. 11, 2003

Hi Tim, pydev, while fighting this conditional super thread, I stumbled over something about "".join, as it was used as an argument for reading LtoR. Citing A. Koenig and Ahz: """ ','.join(lines) Aahz> Many people (including me) think it's *NOT* Pythonic. If I were trying to make code easy to understand for inexperienced programmers, I would write str.join(',', lines) instead of ','.join(lines). """ I have two observations: 1) Through introduction of strings as class-like objects, new calling patterns are generated. Unfortunately, this is the opposite as in the string module: str.join(',', lines) # vs. string.join(lines, ',') What is now pythonic. Was it (a posteriori) a mistake to add join as a method to strings, since it creates a calling pattern that is incompatible with the string function? Side remark: This error message is confusing: >>> str.join(" ") Traceback (most recent call last): File "<interactive input>", line 1, in ? TypeError: join() takes exactly one argument (0 given) Well, the method is probably not well suited to be called by the class, only (expecting to be a method, always). But now it exists. 2) Given the str "class", we could use it to make the string module absolutely redundant, since we can put all string constants into str now. So we would be able to use str.digits # instead of string.digits Trying to make sense of 1) and 2), I get into trouble because of the inconsistent join issue. What is the long-term way to make this pythonic again: Should "".join be dropped in favor of a class method which reads like the old string.join? Or should it be kept like today, exist as "".join(stuff) and str.join("", stuff), and string.join becomes deprecated? ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

4 3