GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing mail.python.org — Mailman 3 October 2001 - Python-Dev - python.org Python-Dev
Threads by month
October 2001
Feb. 23, 2005
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.
The PEP for zip import is 273. Please take a look and comment.
http://python.sourceforge.net/peps/pep-0273.html
Jim Ahlstrom
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/ ++++
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
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')))
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/
> > 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
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."""
Oct. 31, 2001
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
> 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
|
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |
