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.
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3.1 (final).
Python 2.3.1 is a pure bug fix release of Python 2.3, released in late
July. A number of obscure crash-causing bugs have been fixed, various
memory leaks have been squished, but no new features have been added to
the language or to the library.
For more information on Python 2.3.1, including download links for
various platforms, release notes, and known issues, please see:
http://www.python.org/2.3.1
Highlights of this new release include:
- Bugfixes
- The Windows installer now ships with documentation in searchable
htmlhelp format, rather than individual HTML files.
Highlights of the previous major Python release (2.3) are available
from the Python 2.3 page, at
http://www.python.org/2.3/highlights.html
This release was the work of a number of dedicated python-dev folks who
took the time to apply bugfixes back to the 2.3 code. The community owes
them many thanks for this work.
Enjoy the new release,
Anthony
Anthony Baxter
anthony(a)python.org
Python 2.3.1 Release Manager
(on behalf of the entire python-dev team)
After a brief discussion on the Doc-SIG, it looks like I can
reasonably drop the .tar.gz packaging for the documentation, leaving
only .zip and .tar.bz2 formats.
Are there any strong objections to this change?
(If this flies here, I'll ask the larger community, but I wanted to
get and idea of the reaction here first.)
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
For those of you not following every bug in the SF tracker closely,
in http://www.python.org/sf/775414 it's been suggested that the docs
for 2.3.2 include a warning about using the old-style interface to
bsddb (without a DBEnv) with multi-threaded applications. This seems
like a prudent suggestion - does someone want to supply some words?
Anthony
Should imp.find_module() work for modules that are packaged in a zip
file in 2.3.x? I'm seeing that this doesn't, and before I dive in to
figure out why, I want to see if this is the intent.
--
Tom Emerson Basis Technology Corp.
Software Architect http://www.basistech.com
"Beware the lollipop of mediocrity: lick it once and you suck forever"
I just did a bunch of research into trying to find out if using strdup()
in a patch was reasonable. I finally grepped enough to find strdup in
pyconfig.h and configure.in . But that leads to a Brett Newbie Question.
Does there happen to be a better way to find out what functions we check
for beyond grepping configure.in? The entire reason I bothered to do so
much research is I thought we were only supposed to assume ANSI C with
POSIX (which, from what I can tell, strdup() is not). But with more
Googling and grepping I discovered the meaning of AC_REPLACE_FUNCS()
which strdup was being called in configure.in . I would never have
known strdup was available to me for code had I not randomly come across
this patch and done all of this research.
Because of this I would like to list in the Python development guide I
am writing up all of the places one can check for info; what
configure.in checks for or handles and pyport.h come to mind. It would
be nice to have a place that lists all the places one can check for C
functionality that are not in the Python/C API directly. If people have
other places in the code that one should check please let me know so I
can make sure it makes it into the doc and prevents me from having to
come up with another Brett Newbie Question. =)
-Brett
I have a patch (DBCursor.get_current_size(), returns size of data for
current entry) which I'd like to submit. This involves changes to
pybsddb cvs as well as python cvs, from what I can tell (for tests and
docs in the pybsddb repo).
While I have developer access to pybsddb, I don't have it for Python.
Submitting patches for two different repositories seems cumbersome, so
where should I add it? Python SF tracker?
--
Itamar Shtull-Trauring http://itamarst.org/
Available for Python & Twisted consulting
Is this enough reason to use OpenSSL version 0.9.7c instead of 0.9.7b
for the 2.3.2 final windows installer, or should the release candidate
remain unchanged?
<http://www.openssl.org/news/secadv_20030930.txt>
Thomas
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3.2 (release candidate 1).
Python 2.3.2 is a bug-fix release, to repair a couple of build problems
and packaging errors in Python 2.3.1. Assuming no major problems crop up,
a final release of Python 2.3.2 will follow later this week.
For more information on Python 2.3.2, including download links for
various platforms, release notes, and known issues, please see:
http://www.python.org/2.3.2
Highlights of this new release include:
- A bug in autoconf that broke building on HP/UX systems is fixed.
- A bug in the Python configure script that meant os.fsync() was
never available is fixed.
Highlights of the previous major Python release (2.3) are available
from the Python 2.3 page, at
http://www.python.org/2.3/highlights.html
Many apologies for the flaws in 2.3.1 - the final 2.3.2 release should
address the problems.
Enjoy the new release,
Anthony
Anthony Baxter
anthony(a)python.org
Python 2.3.2 Release Manager
(on behalf of the entire python-dev team)
Idle still has it's own NEWS.txt file, and it's own version number
(for instance, 2.3.1's version of idle is "1.0.1". Does this make
sense? What should happen for 2.3.2, where no idle changes have been
made?
Anthony
