Python-Dev September 2003

python-dev@python.org

102 participants
102 discussions

RE: [Python-Dev] Those import related syntax errors again...

by Samuele Pedroni

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.

15 years, 4 months

RELEASED Python 2.3.1

by Anthony Baxter

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)

16 years, 9 months

Documentation packages

by Fred L. Drake, Jr.

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

16 years, 9 months

2.3.2 and bsddb

by Anthony Baxter

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

16 years, 9 months

imp.findmodule and zip files

by Tom Emerson

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"

16 years, 9 months

Good way of finding out what C functions we have?

by Brett C.

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

16 years, 9 months

Procedures for submitting patches to pybsddb

by Itamar Shtull-Trauring

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

16 years, 9 months

OpenSSL vulnerability

by Thomas Heller

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

16 years, 9 months

RELEASED Python 2.3.2, release candidate 1

by Anthony Baxter

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)

16 years, 9 months

Lib/idlelib/NEWS.txt

by Anthony Baxter

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

16 years, 9 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev September 2003