Re: SCons build tool speed
Hi Neil, ted, et al.-- > > How does the speed of the Scons build tool compare with Ant? > > Right now with out Ant builds take around an hour. Hoping to > > speed that up. > > Scons emphasises accuracy over speed and is normally a little > slower than other build tools although still fast enough for most > purposes. One cause of slowness is that it reads the source files, > traces include files and checksums them all rather than relying > on file times. There are some things you can do to speed it up: > http://www.scons.org/cgi-bin/wiki/GoFastButton In anticipation of the next release of SCons, we've been doing a *lot* of work on profiling the performance and eliminating bottlenecks. It turns out that scanning the source files and performing the MD5 calculation is not the dominant factor that we've all assumed it is. There were some other inefficiencies in some of our algorithms that were much more significant, including some unnecessary disk scans, recomputing the same dependencies for every target in a list of targets generated by one command, and repeated just-in-time creation of some internal objects that could be created just once and cached. That said, SCons will never be as fast as Make, because it *is* doing more for you under the covers. Although the next version won't necessarily speed up every configuration (the bottlenecks are extremely configuration dependent), it should be a significant improvement for many configurations out there. --SK -- http://mail.python.org/mailman/listinfo/python-list
Re: SCons build tool speed
Hi Peter-- > > How does the speed of the Scons build tool compare with > > Ant? Right now with out Ant builds take around an hour. Hoping > > to speed that up. > > Don't tools like Scons, Ant, and for that matter "make" just > execute other programs? So that 99% of the time is consumed > external to the Scons, Ant, or make process itself? Why > do you think the speed of the build tool is of any significance > compared to the time for things like compilers and linkers > to execute? You're right that build times are dominated by the external commands when rebuilds occur. If nothing needs to be rebuilt, though, the wall-clock time is obviously dominated by how long it takes for the build tool to decide that. A build tool that doesn't decide whether or not targets are up-to-date *and* dispatch the commnds to rebuild them reasonably quickly and efficiently doesn't do a good job of serving its users. --SK -- http://mail.python.org/mailman/listinfo/python-list
identifying 64-bit Windows from 2.3.5?
If I have installed 2.3.5 from the python.org Windows installer, can
any one point me to a run-time way to identify whether I'm running on
a 32-bit vs. 64-bit version of Windows XP, given that Python itself was
built on/for a 32-bit system?
I hoped sys.getwindowsversion() was the answer, but it returns the same
platform value (2) on both 32-bit and 64-bit systems. sys.platform
("win32") and sys.maxint are both set at compile time. Things like
os.uname() aren't on Windows.
Can some Windows-savvy Pythonista point me to some way to distinguish
between these two?
Thanks,
--SK
--
http://mail.python.org/mailman/listinfo/python-list
RE: identifying 64-bit Windows from 2.3.5?
Hi Ivan-- >> If I have installed 2.3.5 from the python.org Windows installer, can >> any one point me to a run-time way to identify whether I'm running on >> a 32-bit vs. 64-bit version of Windows XP, given that Python itself was >> built on/for a 32-bit system? > > I really don't think it matters too much which one you have, I have 64 bit > and it works fine. Yes, the same Python executable and code works just fine on both systems, but I need to do different things (in this case, invoke a different compiler with a different set of compiler options) based on whether or not I'm building on a 32-bit or 64-bit system. Thanks, --SK -- http://mail.python.org/mailman/listinfo/python-list
ANNOUNCE: SCons 0.97 has been released
SCons is a software construction tool (build tool, or make tool) written in Python. It is based on the design which won the Software Carpentry build tool competition in August 2000. Version 0.97 of SCons has been released and is available for download from the SCons web site: http://www.scons.org/download.php An RPM package and a Win32 installer are all available, in addition to the traditional .tar.gz and .zip files. A Debian package is available in Debian unstable. WHAT'S NEW IN THIS RELEASE? This release contains two fixes for problems discovered since 0.96.96 (the last testing version) was released. There are a HUGE number of fixes and new features since the last "stable" 0.96.1 release. If you are updating from 0.96.1 or an earlier version, BE SURE to read the release notes for important information about changes which may trigger rebuilds, or otherwise impact your configuration: http://www.scons.org/RELEASE.txt You can see a complete list of changes in the change log at: http://www.scons.org/CHANGES.txt ABOUT SCONS Distinctive features of SCons include: - a global view of all dependencies; no multiple passes to get everything built properly - configuration files are Python scripts, allowing the full use of a real scripting language to solve difficult build problems - a modular architecture allows the SCons Build Engine to be embedded in other Python software - the ability to scan files for implicit dependencies (#include files); - improved parallel build (-j) support that provides consistent build speedup regardless of source tree layout - use of MD5 signatures to decide if a file has really changed; no need to "touch" files to fool make that something is up-to-date - extensible through user-defined Builder and Scanner objects - build actions can be Python code, as well as external commands An SCons users' mailing list is available for those interested in getting started. You can subscribe by sending email to: [EMAIL PROTECTED] Alternatively, we invite you to subscribe to the low-volume SCons announcement mailing list to receive notification when new versions of SCons become available. Send email to: [EMAIL PROTECTED] ACKNOWLEDGEMENTS Many, many thanks to all of the following people for their contributions during the entire protracted 0.97 development cycle, and its numerous pre-release testing versions: Anonymous, Anatoly, Matthias, Paul, Steve-o, Erling Andersen, Chad Austin, Stanislav Baranov, Timothee Besset, Joe Bloggs, Ken Boortz, John Calcote, Steve Christensen, Charles Crain, Matt Doar, Matthew Doar, Christopher Drexler, Bjorn Eriksson, Walter Franzini, Eric Frias, Gottfried Ganssauge, Dmitry Grigorenko, Helmut Grohne, Ralf W. Grosse-Kunstleve, David Gruener, Fawad Halim, Bob Halley, August Hörandl, Steven Johnson, Stephen Kennedy, Jay Kint, James Y. Knight, Arve Knudsen, Carsten Koch, Jean-Baptiste Lab, Chen Lee, Wayne Lee, Baptiste Lepilleur, Ben Leslie, Clive Levinson, Ben Liblit, Christian Maaser, Adam MacBeth, Sanjoy Mahajan, Jeff Mahovsky, Rob Managan, Rob Managan, Shannon Mann, Michael McCracken, Patrick Mezard, Dmitry Mikhin, Georg Mischler, Joel B. Mohler, Elliot Murphy, Leanid Nazdrynau, Christian Neeb, Matthew A. Nicholson, Han-Wen Nienhuys, Jan Nieuwenhuizen, Jan Nijtmans, Greg Noel, Gary Oberbrunner, Kian Win Ong, Tom Parker, Gerard Patel, Chris Pawling, Karol Pietrzak, Chris Prince, John Pye, Asfand Yar Qazi, Kevin Quick, Jon Rafkind, Steve Robbins, Christoph Schulz, Craig Scott, Stefan Seefeld, Jose Pablo Ezequiel "Pupeno" Fernandez Silva, Adam Simpkins, Vaclav Smilauer, a smith, Sohail Somani, Jeff Squyres, Levi Stephen, Amir Szekely, Matthias Troffaes, Erick Tryzelaar, Jonathan Ultis, Dobes Vandermeer, David J. Van Maren, Atul Varma, Nicolas Vigier, Richard Viney, David Vitek, Edward Wang, Greg Ward, Thad Ward, Ben Webb, Christoph Wiedemann, Russell Yanofsky and Johan Zander. On behalf of the SCons team, --SK-- http://mail.python.org/mailman/listinfo/python-list
Re: IP address
Klaus Alexander Seistrup wrote:
> urllib.urlopen("http://myip.dk/";)
http://whatismyip.org gives it to you in a more usable format. But, as
others have pointed out, it might return your router's IP.
--
Garry Knight
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: book for a starter
Excellent choice. I used the 2nd edition for better than a year as a reference as I "came up to speed" on the language. Didn't know there was a 3rd edition out. Doug On Tue, 2007-02-27 at 11:08 -0800, Sriram wrote: > Hi, > > If you have experience programming, just read the online tutorial at > http://docs.python.org/tut/tut.html > > I find Python Essential Reference (3rd Edition) (Developer's Library) > (Paperback) invaluable though. BTW I have the 2nd edition. > Amazon link : > http://www.amazon.com/gp/pdp/profile/A9N9B1L0O4BYJ/ref=cm_blog_dp_pdp/002-7062034-2980840 > > > On Feb 27, 10:58 am, Bjoern Schliessmann [EMAIL PROTECTED]> wrote: > > Wensui Liu wrote: > > > I just start learning python and have a question regarding books > > > for a newbie like me. > > > > http://wiki.python.org/moin/IntroductoryBooks > > > > > If you are only allowed to buy 1 python book, which one will you > > > pick? ^_^. > > > > I'd pick a reference. YMMV. > > > > Regards, > > > > Björn (having been allowed to buy more than one Python book) > > > > -- > > BOFH excuse #314: > > > > You need to upgrade your VESA local bus to a MasterCard local bus. > > -- http://mail.python.org/mailman/listinfo/python-list
ANNOUNCE: SCons 0.98.1 (candidate for 1.0) is now available
SCons is a software construction tool (build tool, or make tool) written in Python. It is based on the design which won the Software Carpentry build tool competition in August 2000. Version 0.98.1 of SCons has been released and is now available at the SCons download page: http://www.scons.org/download.php RPM and Debian packages and a Win32 installer are all available, in addition to the traditional .tar.gz and .zip files. This release is considered a candidate for the (long-awaited) official 1.0 SCons release. We welcome and encourage widespread testing and use of this release to try to identify any problems. Please report your bugs following the guidelines at: http://scons.tigris.org/bug-submission.html WHAT'S NEW IN THIS RELEASE? This release contains a huge number of new features, fix, performance improvements, and other changes since the last widely-publicized release (0.97, last year). For a description of important changes that affect upgrading and backwards compatibility, please see our release notes: http://scons.tigris.org/RELEASE.txt For a very complete list of changes, please see our change log: http://scons.tigris.org/CHANGES.txt ABOUT SCONS Distinctive features of SCons include: - a global view of all dependencies; no multiple passes to get everything built properly - configuration files are Python scripts, allowing the full use of a real scripting language to solve difficult build problems - the ability to scan files for implicit dependencies (#include files); - improved parallel build (-j) support that provides consistent build speedup regardless of source tree layout - use of MD5 signatures to decide if a file has really changed; no need to "touch" files to fool make that something is up-to-date - easily extensible through user-defined Builder and Scanner objects - build actions can be Python code, as well as external commands A scons-users mailing list is available for those interested in getting started using SCons. You can subscribe by sending email to: [EMAIL PROTECTED] Alternatively, we invite you to subscribe to the (very) low-volume scons-announce mailing list to receive notification when new versions of SCons become available: [EMAIL PROTECTED] On behalf of the SCons team, --SK -- http://mail.python.org/mailman/listinfo/python-list
Re: Cheat sheet for the new string formatting?
June 8 2015 3:11 PM, "Skip Montanaro" wrote:
I have so far ignored the new string formatting (you know, the stuff
with all the braces, dots and brackets that make Python strings look like Perl
code ). I am still only using Python 2.7, but have recently started forcing
myself to use the print() function. I figure maybe I should also start to come
to grips with the fancy new string formatting.
Is there a cheat sheet around which shows some side-by-side examples of the
{}-style and printf-style? I didn't see anything with a few Google searches.
Thx,
Skip
Hi,
I think http://pyformat.info/ (http://pyformat.info/) is what you're looking
for.
Thanks,
--
Steven Knight
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] PEP 382: Namespace Packages
On Apr 15, 2009, at 12:15 PM, M.-A. Lemburg wrote: The much more common use case is that of wanting to have a base package installation which optional add-ons that live in the same logical package namespace. The PEP provides a way to solve this use case by giving both developers and users a standard at hand which they can follow without having to rely on some non-standard helpers and across Python implementations. I'm not sure I understand what advantage your proposal gives over the current mechanism for doing this. That is, add to your __init__.py file: from pkgutil import extend_path __path__ = extend_path(__path__, __name__) Can you describe the intended advantages over the status-quo a bit more clearly? James -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces
On Apr 22, 2009, at 2:50 AM, Martin v. Löwis wrote: I'm proposing the following PEP for inclusion into Python 3.1. Please comment. +1. Even if some people still want a low-level bytes API, it's important that the easy case be easy. That is: the majority of Python applications should *just work, damnit* even with not-properly-encoded- in-current-LC_CTYPE filenames. It looks like this proposal accomplishes that, and does so in a relatively nice fashion. James -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] PEP 384: Defining a Stable ABI
On May 17, 2009, at 4:54 PM, Martin v. Löwis wrote: Currently, each feature release introduces a new name for the Python DLL on Windows, and may cause incompatibilities for extension modules on Unix. This PEP proposes to define a stable set of API functions which are guaranteed to be available for the lifetime of Python 3, and which will also remain binary-compatible across versions. Extension modules and applications embedding Python can work with different feature releases as long as they restrict themselves to this stable ABI. It seems like a good ideal to strive for. But I think this is too strong a promise. IMO it would be better to say that ABI compatibility across releases is a goal. If someone does make a change that breaks the ABI, I'd expect whomever is proposing it to put forth a fairly strong argument towards why it's a worthwhile change. But it should be possible and allowed, given the right circumstances. Because I think it's pretty much inevitable that it *will* need to happen, sometime. (of course there will need to be ABI tests, so that any potential ABI breakages are known about when they occur) Python is much more defined by its source language than its C extension API, so tying the python major version number to the C ABI might not be the best idea from a "marketing" standpoint. (I can see it now..."Python 4.0 major new features: we changed the C method definition struct layout incompatibly" :) James -- http://mail.python.org/mailman/listinfo/python-list
