Mailman 3 October 2001 - Python-Dev

RE: [Python-Dev] Those import related syntax errors again...
by Samuele Pedroni 23 Feb '05

23 Feb '05

Hi. [Mark Hammond] > The point isn't about my suffering as such. The point is more that > python-dev owns a tiny amount of the code out there, and I don't believe we > should put Python's users through this. > > Sure - I would be happy to "upgrade" all the win32all code, no problem. I > am also happy to live in the bleeding edge and take some pain that will > cause. > > The issue is simply the user base, and giving Python a reputation of not > being able to painlessly upgrade even dot revisions. I agree with all this. [As I imagined explicit syntax did not catch up and would require lot of discussions.] [GvR] > > Another way is to use special rules > > (similar to those for class defs), e.g. having > > > > <frag> > > y=3 > > def f(): > > exec "y=2" > > def g(): > > return y > > return g() > > > > print f() > > </frag> > > > > # print 3. > > > > Is that confusing for users? maybe they will more naturally expect 2 > > as outcome (given nested scopes). > > This seems the best compromise to me. It will lead to the least > broken code, because this is the behavior that we had before nested > scopes! It is also quite easy to implement given the current > implementation, I believe. > > Maybe we could introduce a warning rather than an error for this > situation though, because even if this behavior is clearly documented, > it will still be confusing to some, so it is better if we outlaw it in > some future version. > Yes this can be easy to implement but more confusing situations can arise: <frag> y=3 def f(): y=9 exec "y=2" def g(): return y return y,g() print f() </frag> What should this print? the situation leads not to a canonical solution as class def scopes. or <frag> def f(): from foo import * def g(): return y return g() print f() </frag> [Mark Hammond] > > This probably won't be a very popular suggestion, but how about pulling > > nested scopes (I assume they are at the root of the problem) > > until this can be solved cleanly? > > Agreed. While I think nested scopes are kinda cool, I have lived without > them, and really without missing them, for years. At the moment the cure > appears worse then the symptoms in at least a few cases. If nothing else, > it compromises the elegant simplicity of Python that drew me here in the > first place! > > Assuming that people really _do_ want this feature, IMO the bar should be > raised so there are _zero_ backward compatibility issues. I don't say anything about pulling nested scopes (I don't think my opinion can change things in this respect) but I should insist that without explicit syntax IMO raising the bar has a too high impl cost (both performance and complexity) or creates confusion. [Andrew Kuchling] > >Assuming that people really _do_ want this feature, IMO the bar should be > >raised so there are _zero_ backward compatibility issues. > > Even at the cost of additional implementation complexity? At the cost > of having to learn "scopes are nested, unless you do these two things > in which case they're not"? > > Let's not waffle. If nested scopes are worth doing, they're worth > breaking code. Either leave exec and from..import illegal, or back > out nested scopes, or think of some better solution, but let's not > introduce complicated backward compatibility hacks. IMO breaking code would be ok if we issue warnings today and implement nested scopes issuing errors tomorrow. But this is simply a statement about principles and raised impression. IMO import * in an inner scope should end up being an error, not sure about 'exec's. We will need a final BDFL statement. regards, Samuele Pedroni.

18 78

PEP 273: Import Modules from Zip Archives
by James C. Ahlstrom 09 Nov '01

09 Nov '01

The PEP for zip import is 273. Please take a look and comment. http://python.sourceforge.net/peps/pep-0273.html Jim Ahlstrom

13 46

Patch submitted for cross-platform newline support
by Jack Jansen 05 Nov '01

05 Nov '01

Hi folks, I've just submitted a patch that allows Python to do cross-platform newline handling, #476814. This sort-of happened after the promised PEP didn't materialise, and there was discussion about this among myself, Guido and the pythonmac-sig, and at some point Guido said "Ok, code it!". The patch has been tested on SGI Irix and in MacPython only. I'd like people to have a look at this. There's one thing I don't like, and that's the changes I had to make to the parser sourcefiles. They're needed, but I'm open to suggestions as to a better way to do this. And of course I'm open to any suggestions. I'm also interested in discussing whether a patch like this is appropriate while we're in beta. On the one hand I would say it is, because the feature is disabled by default. On the other hand there are changes (albeit mainly cosmetic ones) in a large number of places. Another argument for allowing this even while in beta is that I really really want it for Mac OS X (but this might not be a very strong argument, I guess:-). Here's the summary of the patch: This patch enables Python to interpret all known newline conventions, CR, LF or CRLF, on all platforms. This support is enabled by configuring with --with-universal-newlines (so by default it is off, and everything should behave as usual). With universal newline support enabled two things happen: - When importing or otherwise parsing .py files any newline convention is accepted. - Python code can pass a new "t" mode parameter to open() which reads files with any newline convention. "t" cannot be combined with any other mode flags like "w" or "+", for obvious reasons. File objects have a new attribute "newlines" which contains the type of newlines encountered in the file (or None when no newline has been seen, or "mixed" if there were various types of newlines). Also included is a test script which tests both file I/O and parsing. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

6 6

OS/2 VAC++ patches
by Andrew MacIntyre 05 Nov '01

05 Nov '01

I have looked at Michael Muller's VAC++ patches, and added comments as followups. In summary: 473749 - has several (minor IMO) stylistic issues (addition of OS/2 #ifdefs). The intent of the changes looks OK, as do most of the actual changes (those in OS/2 VAC specific files or existing OS/2 #ifdefs). 474169 - looks good to go (changes inside existing OS/2 #ifdef) 474500 - looks good to go (isolated to OS/2 specific file) Comments on the stylistic issues? -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac(a)bullseye.apana.org.au | Snail: PO Box 370 andymac(a)pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia

2 2

Future of SSL
by Gerhard Häring 02 Nov '01

02 Nov '01

First I'd like to say hello. I'm new to this list :-) I've some concerns with the latest development wrt SSL development in Python. The SSL support in the Python core seems to have been added with Python 2.0, and Guido told me in a SF patch discussion, that Pythonlabs doesn't know the code very well. Meanwhile it seems like Jeremy has tried fixing bugs. I've also submitted several patches to the SSL code. As you might know, there are several third-party SSL implementatations for Python (m2crypto, pyOpenSSL, POW). I've contacted the maintainers of these packages and asked them if they'd like to review my patches. The two that answered told me that the reason they implemented their own packages was that the SSL support in Python itself was very incomplete and, to sum it up, Python's SSL is just plain broken. The current state is that there is a single ssl() method in the socket module that can be used to instantiate client-side SSL connections. There's also a patch on Sourceforge that adds server-side SSL functionality. Several points why the current API is broken: - no support for specifying the SSL protocol (SSL v2/SSL v3/SSL v2|3) - no proper certicate checking - SSL objects are neither compatible with sockets nor are they file-like objects - no advanced features like SSL callbacks (to allow the user to accept a cerficicate, for example) What I'd suggest for Python 2.2 is to *not* add any new features, like server-side SSL but only accept bugfixes for the current client-side code. As the current implementation is broken and there is probably little SSL knowledge in the Python core team, I propose to "outsource" the problem: It should be possible to define a "Python SSL interface" that describes an API for SSL. The various modules in Python that use SSL (urllib, smtp, ...) would then be rewritten to use the new API. The socketmodule.c would be rewritten to use the new API instead. Then, wrappers could be written for the various SSL modules that wrap them into the new "Python SSL interface" API. As for me, I'm not an expert in SSL, but I'd be willing to try coordinate the efforts, write a PEP, talk with the module maintainers and such. I'd be grateful to hear your opinions about this newbie proposal :-) Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

9 23

pickle faster in 2.2 ?
by M.-A. Lemburg 01 Nov '01

01 Nov '01

While hacking on an XML pickler, I found that pickle.py got nearly twice as fast in 2.2 comparing to 2.1 and 2.0. The code in pickle.py doesn't seem to have changed much. Anybody know where that speedup came from ? Can somebody on another (non-Linux) system please verify this. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

3 5

Re: [Python-Dev] Slices and "==" optimization
by Martin v. Loewis 01 Nov '01

01 Nov '01

> > That's why I would like the simple > > > > if (v == w) return 0; > > > > integrated into the ceval loop right along the INT-compare > > optimization. > > Maybe this could be done as follows: > > if (v == w && PyString_CheckExact(v)) return 0; Maybe I'm missing some context here: where is this fragment supposed to go to? into ceval.c:COMPARE_OP? What is the "return 0;" doing then? In any case, I think measurements should show how much speed improvement is gained by taking this short-cut. It sounds nice in theory, but ... I just added the block else if ((v == w) && (oparg == EQ) && PyString_CheckExact(v)) { x = Py_True; Py_INCREF(x); } into the code. In an application that almost exclusively does COMPARE_OPs on identical strings, I got a 30% speed-up. OTOH, this same code caused a 10% slowdown if I converted the "==" into "<>". In a real application, total speed-up will depend on two things: - how many COMPARE_OPs are done in the code? - how many of those compare identical strings for equality? Running the PyXML test suite, I counted 120000 cases where slow_compare was done, and only 700 cases identical strings were compared for equality. Regards, Martin

5 5

statcache.lstat?
by Skip Montanaro 01 Nov '01

01 Nov '01

Does this (untested) code make sense as a possible addition to statcache? One obvious problem I see is that if stat(path) had been called before lstat(path), you'd pull the wrong info out of the cache. You could get around this by maintaining separate stat and lstat caches or caching a different key (e.g. (path, "l")) for the lstat variety. If this is deemed worthwhile I'll make it work and submit a patch to SF. I wanted to check first to make sure I wasn't missing something obvious that would keep it from ever working. Skip *** /tmp/skip/statcache.py.~1.11~fVASKs Wed Oct 31 13:10:22 2001 --- /tmp/skip/statcache.pyfVAfUy Wed Oct 31 13:10:22 2001 *************** *** 6,12 **** import os as _os from stat import * ! __all__ = ["stat","reset","forget","forget_prefix","forget_dir", "forget_except_prefix","isdir"] # The cache. Keys are pathnames, values are os.stat outcomes. --- 6,12 ---- import os as _os from stat import * ! __all__ = ["stat","lstat","reset","forget","forget_prefix","forget_dir", "forget_except_prefix","isdir"] # The cache. Keys are pathnames, values are os.stat outcomes. *************** *** 22,27 **** --- 22,37 ---- if ret is None: cache[path] = ret = _os.stat(path) return ret + + if hasattr(_os, "lstat"): + def lstat(path): + """Lstat a file, possibly out of the cache.""" + ret = cache.get(path, None) + if ret is None: + cache[path] = ret = _os.lstat(path) + return ret + else: + lstat = stat def reset(): """Clear the cache."""

3 6

Re: [Python-Dev] Patch submitted for cross-platform newline support
by Jack Jansen 01 Nov '01

01 Nov '01

Recently, "Tim Peters" <tim(a)zope.com> said: > Well, the "t" modifier isn't std; does anyone other than Microsoft support > it? MS also gives meaning to non-std "c" and "n" modifiers. Luckily, > Python doesn't define which modes or modifiers it accepts <wink>. Oops, big oops! I picked the "t" because it was intended _not_ to be supported on any platform: my code eats it, and turns on the universal newline feature on the file object. What does "t" do on Windows? What would be a better choice? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

Re: [Python-Dev] slicing of structseq objects fails
by Jack Jansen 31 Oct '01

31 Oct '01

> Bingo. First Jack reports a bug here, [...] Ok, Tim, sorry! You're right, of course, that I should have submitted the bug, it was just that I was really busy with other things, and cc-ing python-dev was a lot quicker than first replying to the message to the poster and pythonmac-sig, finding out who owns structseq, filing the bug report and telling the poster about the id (I've found that pointing people to the sourceforge bug reporter to report the bug themselves means the bug is lost in >50% of the cases). But saving my time shouldn't be an excuse for wasting everyone else's. Sorry, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Python-Dev October 2001