Mailman 3 March 2013 - Python-Dev

Re: [Python-Dev] cpython (2.7): Issue #17508: Handled out-of-order handler configuration correctly.
by Antoine Pitrou March 23, 2013

March 23, 2013

Hello, On Fri, 22 Mar 2013 16:28:19 +0100 (CET) vinay.sajip <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/8ae1c28445f8 > changeset: 82881:8ae1c28445f8 > branch: 2.7 > user: Vinay Sajip <vinay_sajip(a)yahoo.co.uk> > date: Fri Mar 22 15:19:24 2013 +0000 > summary: > Issue #17508: Handled out-of-order handler configuration correctly. Could you explain what "out-of-order handler configuration" means? Also, could … [View More]

2 1

Increase the code coverage of "OS" module
by rakesh karanth March 23, 2013

March 23, 2013

Hi python-dev, I'm interested in increasing the code coverage of the Python stdlib library "OS"Can some one who is already working on this or on a similar issue enlighten me on this? Thanks in advance. RegardsRakesh.G.K

2 1

IDLE in the stdlib
by Kurt B. Kaiser March 22, 2013

March 22, 2013

[Barry] > On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote: >>IDLE would be a great first foray into this "separate project" world, because it is many ways a separate project. > I really think that's true. A separate project, occasionally sync'd back > into > the stdlib by a core dev seems like the right way to manage IDLE. It seems to me that we are seeing increasing use of IDLE for beginner training. I've seen several recent Python books that use IDLE as their programming … [View More]environment, and which include IDLE screen captures in the text. I've always felt that IDLE should be targeted to an eight year old beginner, and should work uniformly across the major platforms. That now includes the Raspberry Pi!! I believe it's very important that Python come with an IDE as part of the "batteries" - it's very awkward for a beginner to write code in something like Notepad and then run and debug it in a Windows command shell. Just getting the paths right is problematic (and I'm not talking about backslashes). It's very helpful for an instructor to be able to deal with a single application that runs on all the major platforms, and not have to spend a lot of time getting the tools up to speed before the actual Python training can begin. And, while an instructor can walk a student through downloading and installing some IDE, it's very helpful IMHO for a beginner working alone on Windows or Mac to be able to just click on IDLE. A Raspberry Pi might not even have a web connection! IDLE has a single keystroke round trip - it's an IDE, not just an editor like Sublime Text or Notepad. In the 21st century, people expect some sort of IDE. Or, they should! IDLE forked nearly a decade ago to introduce subprocess execution and the configuration dialog. Subsequently, I merged it back into core and it played a useful role in Python 3 development. Scheme hackers write new Scheme implementations. Python hackers tend to write editors and IDEs, it seems. I think, considering all the competition, that IDLE would have died if it hadn't been merged back. Instead, many of its competitors died. So, although I'm pretty agnostic regarding where development is done, I think Python should continue to release a simple native IDE in its binaries, and I worry that IDLE will be eventually dropped from the binaries if it's separate. Right now, Apple is delivering IDLE along with Python (though there are issues with the current installation) and I hope that will continue. OTOH, development is likely to be more vigorous if it's separate. I'd also like to make a plea to keep IDLE's interface clean and basic. There are lots of complex IDEs available for those who want them. It's natural for developers to add features, that's what they do :-), but you don't hand a novice a Ferrari (or emacs) and expect good results. IMHO some of the feature patches on the tracker should be rejected on that basis. It's sometimes said that IDLE is "ugly" or "broken". These terms are subjective! If it's truly broken, then we should fix it. If it's "broken" because a feature is missing, maybe that's an intentional part of Guido's design of a simple Python IDE. -- KBK [View Less]

3 5

Interested in GSoC for biopython
by 阮铮 March 22, 2013

March 22, 2013

Hi, I'm Zheng from the University of Georgia. I heard about the GSoC several weeks before and found biopython also involved in the peoject. I plan to apply for the GSoC 2013, hoping to make some contributions this summer. I browsed the proposals in biopython wiki sites and find two of them are all interesting topics, especially the codon alignment functionality. I know this has been implemented by pal2nal, and pal2nal is a good program as it accounts for the mismatches between protein and DNA … [View More]

2 1

Summary of Python tracker Issues
by Python tracker March 22, 2013

March 22, 2013

ACTIVITY SUMMARY (2013-03-15 - 2013-03-22) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 3908 (+20) closed 25389 (+73) total 29297 (+93) Open issues with patches: 1735 Issues opened (56) ================== #12098: Child process running as debug on Windows http://bugs.python.org/issue12098 reopened by kristjan.jonsson #17430: missed peephole … [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython (2.7): - Issue #13150: sysconfig no longer parses the Makefile and config.h files
by Andrew Svetlov March 22, 2013

March 22, 2013

Great! On Thu, Mar 21, 2013 at 3:02 PM, matthias.klose <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/66e30c4870bb > changeset: 82872:66e30c4870bb > branch: 2.7 > parent: 82843:71adf21421d9 > user: doko(a)ubuntu.com > date: Thu Mar 21 15:02:16 2013 -0700 > summary: > - Issue #13150: sysconfig no longer parses the Makefile and config.h files > when imported, instead doing it at build time. This makes … [View More]importing > sysconfig faster and reduces Python startup time by 20%. > > files: > Lib/distutils/sysconfig.py | 63 +-------------------- > Lib/pprint.py | 5 +- > Lib/sysconfig.py | 75 ++++++++++++++++++++++++- > Makefile.pre.in | 12 +++- > Misc/NEWS | 4 + > 5 files changed, 93 insertions(+), 66 deletions(-) > > > diff --git a/Lib/distutils/sysconfig.py b/Lib/distutils/sysconfig.py > --- a/Lib/distutils/sysconfig.py > +++ b/Lib/distutils/sysconfig.py > @@ -387,66 +387,11 @@ > > def _init_posix(): > """Initialize the module as appropriate for POSIX systems.""" > - g = {} > - # load the installed Makefile: > - try: > - filename = get_makefile_filename() > - parse_makefile(filename, g) > - except IOError, msg: > - my_msg = "invalid Python installation: unable to open %s" % filename > - if hasattr(msg, "strerror"): > - my_msg = my_msg + " (%s)" % msg.strerror > - > - raise DistutilsPlatformError(my_msg) > - > - # load the installed pyconfig.h: > - try: > - filename = get_config_h_filename() > - parse_config_h(file(filename), g) > - except IOError, msg: > - my_msg = "invalid Python installation: unable to open %s" % filename > - if hasattr(msg, "strerror"): > - my_msg = my_msg + " (%s)" % msg.strerror > - > - raise DistutilsPlatformError(my_msg) > - > - # On AIX, there are wrong paths to the linker scripts in the Makefile > - # -- these paths are relative to the Python source, but when installed > - # the scripts are in another directory. > - if python_build: > - g['LDSHARED'] = g['BLDSHARED'] > - > - elif get_python_version() < '2.1': > - # The following two branches are for 1.5.2 compatibility. > - if sys.platform == 'aix4': # what about AIX 3.x ? > - # Linker script is in the config directory, not in Modules as the > - # Makefile says. > - python_lib = get_python_lib(standard_lib=1) > - ld_so_aix = os.path.join(python_lib, 'config', 'ld_so_aix') > - python_exp = os.path.join(python_lib, 'config', 'python.exp') > - > - g['LDSHARED'] = "%s %s -bI:%s" % (ld_so_aix, g['CC'], python_exp) > - > - elif sys.platform == 'beos': > - # Linker script is in the config directory. In the Makefile it is > - # relative to the srcdir, which after installation no longer makes > - # sense. > - python_lib = get_python_lib(standard_lib=1) > - linkerscript_path = string.split(g['LDSHARED'])[0] > - linkerscript_name = os.path.basename(linkerscript_path) > - linkerscript = os.path.join(python_lib, 'config', > - linkerscript_name) > - > - # XXX this isn't the right place to do this: adding the Python > - # library to the link, if needed, should be in the "build_ext" > - # command. (It's also needed for non-MS compilers on Windows, and > - # it's taken care of for them by the 'build_ext.get_libraries()' > - # method.) > - g['LDSHARED'] = ("%s -L%s/lib -lpython%s" % > - (linkerscript, PREFIX, get_python_version())) > - > + # _sysconfigdata is generated at build time, see the sysconfig module > + from _sysconfigdata import build_time_vars > global _config_vars > - _config_vars = g > + _config_vars = {} > + _config_vars.update(build_time_vars) > > > def _init_nt(): > diff --git a/Lib/pprint.py b/Lib/pprint.py > --- a/Lib/pprint.py > +++ b/Lib/pprint.py > @@ -37,7 +37,10 @@ > import sys as _sys > import warnings > > -from cStringIO import StringIO as _StringIO > +try: > + from cStringIO import StringIO as _StringIO > +except ImportError: > + from StringIO import StringIO as _StringIO > > __all__ = ["pprint","pformat","isreadable","isrecursive","saferepr", > "PrettyPrinter"] > diff --git a/Lib/sysconfig.py b/Lib/sysconfig.py > --- a/Lib/sysconfig.py > +++ b/Lib/sysconfig.py > @@ -278,9 +278,10 @@ > return os.path.join(_PROJECT_BASE, "Makefile") > return os.path.join(get_path('platstdlib'), "config", "Makefile") > > - > -def _init_posix(vars): > - """Initialize the module as appropriate for POSIX systems.""" > +def _generate_posix_vars(): > + """Generate the Python module containing build-time variables.""" > + import pprint > + vars = {} > # load the installed Makefile: > makefile = _get_makefile_filename() > try: > @@ -308,6 +309,49 @@ > if _PYTHON_BUILD: > vars['LDSHARED'] = vars['BLDSHARED'] > > + # There's a chicken-and-egg situation on OS X with regards to the > + # _sysconfigdata module after the changes introduced by #15298: > + # get_config_vars() is called by get_platform() as part of the > + # `make pybuilddir.txt` target -- which is a precursor to the > + # _sysconfigdata.py module being constructed. Unfortunately, > + # get_config_vars() eventually calls _init_posix(), which attempts > + # to import _sysconfigdata, which we won't have built yet. In order > + # for _init_posix() to work, if we're on Darwin, just mock up the > + # _sysconfigdata module manually and populate it with the build vars. > + # This is more than sufficient for ensuring the subsequent call to > + # get_platform() succeeds. > + name = '_sysconfigdata' > + if 'darwin' in sys.platform: > + import imp > + module = imp.new_module(name) > + module.build_time_vars = vars > + sys.modules[name] = module > + > + pybuilddir = 'build/lib.%s-%s' % (get_platform(), sys.version[:3]) > + if hasattr(sys, "gettotalrefcount"): > + pybuilddir += '-pydebug' > + try: > + os.makedirs(pybuilddir) > + except OSError: > + pass > + destfile = os.path.join(pybuilddir, name + '.py') > + > + with open(destfile, 'wb') as f: > + f.write('# system configuration generated and used by' > + ' the sysconfig module\n') > + f.write('build_time_vars = ') > + pprint.pprint(vars, stream=f) > + > + # Create file used for sys.path fixup -- see Modules/getpath.c > + with open('pybuilddir.txt', 'w') as f: > + f.write(pybuilddir) > + > +def _init_posix(vars): > + """Initialize the module as appropriate for POSIX systems.""" > + # _sysconfigdata is generated at build time, see _generate_posix_vars() > + from _sysconfigdata import build_time_vars > + vars.update(build_time_vars) > + > def _init_non_posix(vars): > """Initialize the module as appropriate for NT""" > # set basic install directories > @@ -565,3 +609,28 @@ > > def get_python_version(): > return _PY_VERSION_SHORT > + > + > +def _print_dict(title, data): > + for index, (key, value) in enumerate(sorted(data.items())): > + if index == 0: > + print '%s: ' % (title) > + print '\t%s = "%s"' % (key, value) > + > + > +def _main(): > + """Display all information sysconfig detains.""" > + if '--generate-posix-vars' in sys.argv: > + _generate_posix_vars() > + return > + print 'Platform: "%s"' % get_platform() > + print 'Python version: "%s"' % get_python_version() > + print 'Current installation scheme: "%s"' % _get_default_scheme() > + print > + _print_dict('Paths', get_paths()) > + print > + _print_dict('Variables', get_config_vars()) > + > + > +if __name__ == '__main__': > + _main() > diff --git a/Makefile.pre.in b/Makefile.pre.in > --- a/Makefile.pre.in > +++ b/Makefile.pre.in > @@ -437,15 +437,20 @@ > Modules/python.o \ > $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST) > > -platform: $(BUILDPYTHON) > +platform: $(BUILDPYTHON) pybuilddir.txt > $(RUNSHARED) $(PYTHON_FOR_BUILD) -c 'import sys ; from sysconfig import get_platform ; print get_platform()+"-"+sys.version[0:3]' >platform > > +# Create build directory and generate the sysconfig build-time data there. > +# pybuilddir.txt contains the name of the build dir and is used for > +# sys.path fixup -- see Modules/getpath.c. > +pybuilddir.txt: $(BUILDPYTHON) > + $(RUNSHARED) $(PYTHON_FOR_BUILD) -S -m sysconfig --generate-posix-vars > > # Build the shared modules > # Under GNU make, MAKEFLAGS are sorted and normalized; the 's' for > # -s, --silent or --quiet is always the first char. > # Under BSD make, MAKEFLAGS might be " -s -v x=y". > -sharedmods: $(BUILDPYTHON) > +sharedmods: $(BUILDPYTHON) pybuilddir.txt > @case "$$MAKEFLAGS" in \ > *\ -s*|s*) quiet="-q";; \ > *) quiet="";; \ > @@ -955,7 +960,7 @@ > else true; \ > fi; \ > done > - @for i in $(srcdir)/Lib/*.py $(srcdir)/Lib/*.doc $(srcdir)/Lib/*.egg-info ; \ > + @for i in $(srcdir)/Lib/*.py `cat pybuilddir.txt`/_sysconfigdata.py $(srcdir)/Lib/*.doc $(srcdir)/Lib/*.egg-info ; \ > do \ > if test -x $$i; then \ > $(INSTALL_SCRIPT) $$i $(DESTDIR)$(LIBDEST); \ > @@ -1133,6 +1138,7 @@ > --install-scripts=$(BINDIR) \ > --install-platlib=$(DESTSHARED) \ > --root=$(DESTDIR)/ > + -rm $(DESTDIR)$(DESTSHARED)/_sysconfigdata.py* > > # Here are a couple of targets for MacOSX again, to install a full > # framework-based Python. frameworkinstall installs everything, the > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -216,6 +216,10 @@ > Library > ------- > > +- Issue #13150: sysconfig no longer parses the Makefile and config.h files > + when imported, instead doing it at build time. This makes importing > + sysconfig faster and reduces Python startup time by 20%. > + > - Issue #10212: cStringIO and struct.unpack support new buffer objects. > > - Issue #12098: multiprocessing on Windows now starts child processes > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > -- Thanks, Andrew Svetlov [View Less]

1 0

Re: [Python-Dev] [Python-checkins] cpython: Issue #13248: removed deprecated and undocumented difflib.isbjunk, isbpopular.
by Eli Bendersky March 21, 2013

March 21, 2013

A mention in Misc/NEWS can't hurt here, Terry. Even though it's undocumented, some old code could rely on it being there and this code will break with the transition to 3.4 Eli On Tue, Mar 19, 2013 at 4:44 PM, terry.reedy <python-checkins(a)python.org>wrote: > http://hg.python.org/cpython/rev/612d8bbcfa3a > changeset: 82807:612d8bbcfa3a > user: Terry Jan Reedy <tjreedy(a)udel.edu> > date: Tue Mar 19 19:44:04 2013 -0400 > summary: > Issue #… [View More]

3 4

backporting the _sysconfigdata.py module to 2.7
by Matthias Klose March 21, 2013

March 21, 2013

I'd like to backport issue13150, the _sysconfigdata.py module to 2.7. My motivation is not the improved startup time, but the ability to cross-build extension modules using distutils/setuptools. The basic idea is to use the python interpreter of the build machine (the machine you build on), and the _sysconfigdata.py for the host machine (the machine you build for). This kind of setup works fine as long as the setup.py for a third party package gets all build related information from the … [View More]

3 2

Federated repo model [was: IDLE in the stdlib]
by fwierzbicki＠gmail.com March 21, 2013

March 21, 2013

On Thu, Mar 21, 2013 at 8:23 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > I think a federated repo model in general is something we need to > consider, it's not something we should consider IDLE specific. I would love to have a federated repo model. I have recently made the attempt to port the devguide for CPython to Jython with some reasonable success. Part of that success has come because the devguide is in its own repo and so forking it and continuing to merge improvements … [View More]

1 0

Re: [Python-Dev] IDLE in the stdlib
by Eli Bendersky March 21, 2013

March 21, 2013

> > On Mar 20, 2013, at 12:38 PM, Barry Warsaw <barry(a)python.org > > <mailto:barry@python.org>> wrote: > > > >> Right. Ultimately, I think IDLE should be a separate project > entirely, but I > >> guess there's push back against that too. > > > > The most important feature of IDLE is that it ships with the > standard library. > > Everyone who clicks on the Windows MSI on the python.org < > … [View More]http://python.org> > > webpage > > automatically has IDLE. That is why I frequently teach Python with > IDLE. > > > > If this thread results in IDLE being ripped out of the standard > distribution, > > then I would likely never use it again. > > > > > > Why is it necessary to conflate distribution and development. "standard > library" > > != "Python distribution". > > Because that's how CPython defines its distribution. We distribute things > that > are in the CPython/standard library repo, and nothing else. > Yes, I realize this is the case. I was wondering whether it's hard to change. > > > Take the ActivePython distribution for example. They ship with extra > packages > > for Windows (pywin32, etc) and our Python installer doesn't. This is a > reason > > many Windows people prefer ActivePython. That's their right, but this > preference > > is not the point. The point is that it's perfectly conceivable to ship > IDLE with > > Python releases on Windows, while managing it as a separate project > outside the > > CPython core Mercurial repository. > > And what's the benefit? I just don't see it. It just makes it harder to > create > a Python release. > > This is the feedback I was looking for. If this will make Python distribution non-trivially harder, then it's a point against the proposal. > > This seems to me to combine benefits from both worlds: > > > > 1. IDLE keeps being shipped to end users. I have to admit the reasons > made in > > favor of this in the thread so far are convincing. > > 2. IDLE is developed as a standalone project. As such, it's much easier > to > > contribute to, which will hopefully result in a quicker pace of > improvement. > > Why? You won't magically gather more people that are interested in IDLE > development. > But that's the point - If there are not enough people interested in it, it should then die. Right now it's a burden of Python core developers to keep it functional even if no one else cares (and if anything, the low amount of open issues Terry quoted elsewhere may be a sign that indeed not many care). > > > The > > only demand is that it keeps working with a release version of Python, > and this > > is pretty easy. It's even possible and easy to have a single IDLE > version for > > Python 3.x instead of contributors having to propose patches for 3.2, > 3.3 and > > 3.4 simultaneously. > > They don't anyway. > But we know perfectly well that a core dev is expected to backport reasonably. In an outside repo, it can have a single-code base. It's not hard to avoid the new features of 3.3 and 3.4 and be compatible with all active Python 3 versions. Note that even if the same is done in our Mercurial repo, each commit still needs to be triplicated in the push dance. Eli [View Less]

1 0