From anthony.tuininga at gmail.com Sat Nov 4 22:27:29 2017 From: anthony.tuininga at gmail.com (Anthony Tuininga) Date: Sat, 4 Nov 2017 20:27:29 -0600 Subject: cx_Freeze 5.1 and 6.0b1 Message-ID: What is cx_Freeze? cx_Freeze is a set of scripts and modules for freezing Python scripts into executables, in much the same way that py2exe and py2app do. Unlike these two tools, cx_Freeze is cross platform and should work on any platform that Python itself works on. It supports Python 2.7 or higher, including Python 3. More information can be found at the web site: https://anthony-tuininga.github.io/cx_Freeze What's new? cx_Freeze 5.1 supports Python 2.7 and higher. Besides bug fixes, the main change is the use of a common library directory on all platforms. The full release notes can be read here: http://cx-freeze.readthedocs.io/en/latest/releasenotes.html#version-5-1-november-2017. To install, use the following command: python -m pip install cx_Freeze --upgrade cx_Freeze 6.0b1 supports Python 3.5 and higher and is the first prerelease of version 6 which only supports Python 3. The full release notes can be read here: http://cx-freeze.readthedocs.io/en/latest/releasenotes.html#version-6-0b1-november-2017. To install, use the following command: python -m pip install cx_Freeze --upgrade --pre From g.rodola at gmail.com Sat Nov 4 04:41:52 2017 From: g.rodola at gmail.com (Giampaolo Rodola') Date: Sat, 4 Nov 2017 09:41:52 +0100 Subject: ANN: pyftpdlib 1.5.3 with SITE MFMT command support is out Message-ID: Hello all, I'm glad to announce the release of pyftpdlib 1.5.3: https://github.com/giampaolo/pyftpdlib About ===== Python FTP server library provides a high-level portable interface to easily write very efficient, scalable and asynchronous FTP servers with Python. What's new ========== **Enhancements** - #201: implemented SITE MFMT command which changes file modification time. (patch by Tahir Ijaz) - #327: add username and password command line options - #433: documentation moved to readthedocs: http://pyftpdlib.readthedocs.io **Bug fixes** - #403: fix duplicated output log. (path by PonyPC) - #414: Respond successfully to STOR only after closing file handle. Links ===== - Home page: https://github.com/giampaolo/pyftpdlib - Download: https://pypi.python.org/pypi/pyftpdlib - Documentation: http://pyftpdlib.readthedocs.io - What's new: https://github.com/giampaolo/pyftpdlib/blob/master/HISTORY.rst -- Giampaolo - http://grodola.blogspot.com From paul.l.kehrer at gmail.com Thu Nov 2 15:05:29 2017 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Thu, 2 Nov 2017 12:05:29 -0700 Subject: PyCA cryptography 2.1.3 released Message-ID: PyCA cryptography 2.1.3 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, message digests, and key derivation functions. We support Python 2.7, Python 3.4+, and PyPy. Changelog: * Updated Windows, macOS, and manylinux1 wheels to be compiled with OpenSSL 1.1.0g. -Paul Kehrer (reaperhulk) From phd at phdru.name Thu Nov 2 19:46:45 2017 From: phd at phdru.name (Oleg Broytman) Date: Fri, 3 Nov 2017 00:46:45 +0100 Subject: mimedecode 2.8.0 Message-ID: <20171102234645.GA4593@phdru.name> Hello! mimedecode.py WHAT IS IT Mail users, especially in non-English countries, often find that mail messages arrived in different formats, with different content types, in different encodings and charsets. Usually this is good because it allows us to use appropriate format/encoding/whatever. Sometimes, though, some unification is desirable. For example, one may want to put mail messages into an archive, make HTML indices, run search indexer, etc. In such situations converting messages to text in one character set and skipping some binary attachments is much desirable. Here is the solution - mimedecode.py. This is a program to decode MIME messages. The program expects one input file (either on command line or on stdin) which is treated as an RFC822 message, and decodes to stdout or an output file. If the file is not an RFC822 message it is just copied to the output one-to-one. If the file is a simple RFC822 message it is decoded as one part. If it is a MIME message with multiple parts ("attachments") all parts are decoded. Decoding can be controlled by command-line options. Version 2.8.0 (2017-11-03) Python 3. Stop supporting Python 2.6. Code cleanup: fixed flake8 errors and warnings. Pushed to GitHub. Tests at Travis. WHERE TO GET Home page: http://phdru.name/Software/Python/#mimedecode git clone https://github.com/phdru/mimedecode.git git clone http://git.phdru.name/mimedecode.git git clone git://git.phdru.name/mimedecode.git Requires: Python 2.7 or Python 3.4+, m_lib.defenc 1.0+. Tests require: tox, m_lib 3.1+. Recommends: configured mailcap database. Documentation: http://phdru.name/Software/Python/mimedecode.html (also included in the package in html, man and txt formats). AUTHOR Oleg Broytman COPYRIGHT Copyright (C) 2001-2017 PhiloSoft Design. LICENSE GPL Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From raj.pritvi.kumar at gmail.com Fri Nov 3 22:22:37 2017 From: raj.pritvi.kumar at gmail.com (Raj Kumar) Date: Fri, 3 Nov 2017 19:22:37 -0700 Subject: Uplink v0.2 Released Message-ID: <6d365c52-cdfa-4f66-bba8-df24a3ea6e95@Spark> Hi everyone, I am excited to officially announce Uplink v0.2, an MIT-licensed library for building HTTP API clients, to the Python community: https://github.com/prkumar/uplink/ What is Uplink? ============== In essence, Uplink delivers reusable and self-sufficient objects for consuming HTTP webservices, with minimal code and user pain. It generates consumers from the classes and methods you define (loosely analogous to Django's ORM) and supports both synchronous and asynchronous requests. Links ===== - GitHub: https://github.com/prkumar/uplink - Download: https://pypi.python.org/pypi/uplink - Documentation: https://uplink.readthedocs.io/en/latest/ -- Raj Kumar - raj.pritvi.kumar at gmail.com

Pyo 0.8.8 Python DSP library. (08-Nov-17) From mmanns at gmx.net Wed Nov 8 16:47:14 2017 From: mmanns at gmx.net (Martin Manns) Date: Wed, 8 Nov 2017 22:47:14 +0100 Subject: pyspread 1.1.1 released Message-ID: <20171108224714.10211705@Fuddel.mynet> ================ pyspread 1.1.1 ================ Pyspread 1.1.1 has been released. About pyspread ============== Pyspread is a non-traditional spreadsheet that is based on and written in the programming language Python. The goal of pyspread is to be the most pythonic spreadsheet application. Pyspread is free software. It is released under the GPL v3. Project website: https://manns.github.io/pyspread/ Download page: https://pypi.python.org/pypi/pyspread Source code: https://github.com/manns/pyspread Release 1.1.1 is a bugfix release. Major changes to 1.1: ===================== * Pyspread color scheme now adapts better to most dark themes * Shift-scroll now scrolls the grid sideways * Undo and redo functionality made robust (now based on David Townshend's functional undo framework) * Table choice panel is now shown and hidden with F3 * Macro dialog changed to AUI panel (shown and hidden with F4) * The entry line is now correctly updated * Undo and redo buttons are now disabled if undo / redo is unavailable * Current grid label highlights changed for better visibility on high resolution displays * The grid is now prevented from scrolling on focusing a cell editor * Merged cells are now correctly drawn if the top left cell is invisible * Copy and paste format now ignores merged cell information * If a merged area is shifted outside the grid via insert rows etc. this is now correctly handled * Chart dialog switched to AUI panel for better resizeability of sub panels * GPG key choice now only allows choosing private keys without passwords Enjoy Martin From george at fischhof.hu Sat Nov 11 19:15:23 2017 From: george at fischhof.hu (George Fischhof) Date: Sun, 12 Nov 2017 01:15:23 +0100 Subject: [ANN] pluggable-info-monitor 0.2.0 released! Message-ID: Hi everyone, I?m very excited to announce the release of pluggable-info-monitor 0.2.0. First public release. You can download it form bitbucket: https://bitbucket.org/GeorgeFischhof/pluggable_info_monitor package index page: https://pypi.python.org/pypi/pluggable-info-monitor What is pluggable-info-monitor? A web application that shows the information you gathered with your plugin. It can be anything ;-) examples: - in a development environment, bug statistics, build and test results - in education, some education material - in an office it can show the weather foreast, namedays, daily quotes - it can be used as a dashboard for system administrators - etc There are example plugins to help developing your own plugins. Please note: The full feature set requires Python 3.4 and later. Have fun using pluggable-info-monitor George From kq1quick at gmail.com Thu Nov 9 13:11:58 2017 From: kq1quick at gmail.com (Kevin Quick) Date: Thu, 9 Nov 2017 10:11:58 -0800 (PST) Subject: Thespian 3.8.3 released Message-ID: <724c6843-87f2-4f29-93f1-231901c9abd1@googlegroups.com> Release 3.8.3 of Thespian is now available on pypi, with additional information at htttp://thespianpy.com including release notes, documentation, and repository references. ----- Thespian is a Python library providing a framework for developing concurrent, distributed, fault tolerant applications. Thespian is built on the Actor Model which allows applications to be written as a group of independently executing but cooperating "Actors" which communicate via messages. These Actors run within the Actor System provided by the Thespian library. Concurrent All Actors run independently within the Actor System. The Actor System may run the Actors as threads, processes, or even sequential operations within the current process?all with no change to the Actors themselves. Distributed Actors run independently?anywhere. Multiple servers can each be running Thespian and an Actor can be run on any of these systems?all with no change to the Actors themselves. Thespian handles the communication between the Actors and the management process of distributing the Actors across the systems. Location Independent Because Actors run independently anywhere, they run independently of their actual location. A distributed Actor application may have part of it running on a local server, part running on a server in Amsterdam, and part running on a server in Singapore? or not, with no change or awareness of this by the Actors themselves. Fault Tolerant Individual Actors can fail and be restarted?automatically?without impact to the rest of the system. Scalable The number of Actors in the system can be dynamically extended based on factors such as work volume, and systems added to the Distributed Actor System environment are automatically utilized. One of the key aspects of the Actor Model is that it represents a higher level of abstraction than is provided by most frameworks. When writing an Actor-based application, the concurrency and transport layers are completely abstracted, which both simplifies the design and allows the concurrency or transport to be changed in the future without requiring changes in the Actor-based application. The above qualities of Actor programming make it ideally suited for Cloud-based applications as well, where compute nodes are added and removed from the environment dynamically. From bnsn.babu at gmail.com Tue Nov 14 05:48:58 2017 From: bnsn.babu at gmail.com (binson babu) Date: Tue, 14 Nov 2017 16:18:58 +0530 Subject: Invitation to SciPy India 2017 Message-ID: Dear All, SciPy is near!! To know more continue reading. [image: scipy 2017] [image: FOSSEE] View this email in your browser *Dear Sir / Madam,* The FOSSEE project based at IIT Bombay invites the faculty, students and members of your institution/organization to SciPy India 2017 . [image: scipy 2017] SciPy India 2017 ------------------------------ NOVEMBER 29 & 30 SciPy India is an annual conference that is currently in its ninth year and provides an opportunity to learn and use Python in education and research. The conference will have basic and advanced workshops on Python and also some interesting talks. For further information about SciPy India 2017, visit http://scipy.in/2017. We look forward to your participation in SciPy India 2017. *Registration* for the conference is now open. Register Now Lite ?600 (Till 20th Nov 2017) Regular ?1400 (26th Oct - 25th Nov 2017) *Group Registration Discount:* For 5 or more registrations done together, a 20% discount shall be provided. The same will be applied automatically at the time of registration. [image: scipy poster 2017] We request you to share the event details through this poster with faculty members, students and others who might be interested. You may display the poster on notice boards. View Poster Connect with Us: Facebook Twitter Google+ Contact Us: scipy(at)fossee(dot)in info(at)fossee(dot)in Schedule | Invited Speakers | Sponsors | Venue | Unsubscribe [image: IIT Bombay] [image: Valid XHTML 1.0 Transitional] Regards, Binson Babu From bill at baddogconsulting.com Tue Nov 14 18:00:15 2017 From: bill at baddogconsulting.com (Bill Deegan) Date: Tue, 14 Nov 2017 18:00:15 -0500 Subject: SCons 3.0.1 released Message-ID: SCons - a software construction tool Release Notes This is SCons, a tool for building software (and other files). SCons is implemented in Python, and its "configuration files" are actually Python scripts, allowing you to use the full power of a real scripting language to solve build problems. You do not, however, need to know Python to use SCons effectively. Please go to http://scons.org/pages/download.html to get the latest production release of SCons. So that everyone using SCons can help each other learn how to use it more effectively, please go to http://scons.org/lists.html#users to sign up for the scons-users mailing list. RELEASE 3.0.1 - Mon, 12 Nov 2017 15:31:33 -0700 Please consult the RELEASE.txt file for a summary of changes since the last release and consult the CHANGES.txt file for complete a list of changes since last release. This announcement highlights only the important changes. Please note the following important changes since release 2.5.1: This is the initial release supporting both python 3.5+ and 2.7.x and pypy There are some important changes: - Any print statements must now use python 3 syntax of "print()" - All node content should be in bytes. This is the default in python 2.7.x, in Python 3 all strings are by default unicode. byte and/or bytearray should be used if you construct content for return by a custom node type's get_content() method. - There are some (as yet unresolved issue) using Literal()'s in some context with Python 3 - pypy should be supported, please report any issues to the user's mailing list. - Currently if you switch back and forth between python 2.7.x and 3.5+ you will need to remove your sconsign file. This should be resolves shortly, but regardless switching between python 2.7.x and 3.5+ will not use compatible sconsigns and as such incremental builds should be expected to rebuild anything changed since the previous scons run with the same version of python. - It is likely that migrating from 2.5.1 -> 3.0.0 alpha will cause rebuilds due to the significant number of changes in the codebase. - Removed deprecated tools CVS, Perforce, BitKeeper, RCS, SCCS, Subversion. - Removed deprecated module SCons.Sig - See CHANGES.txt for more details on other changes - 3.0.0 should be slightly faster than 2.5.1. Changes yielded a 15% speed up for null incremental builds. - Updated D language scanner support to latest: 2.071.1. - python -m SCons should now run SCons if it's installed PYTHONPATH Please note the following important changes since release 2.4.1: We're enhancing implicit language scanning functionality to improve correctness. SCons now honors scanner keys for implicit dependencies and correctly changes scanner type (if necessary) when traversing implicit dependency trees. This enhancement resolves missing dependencies with built-in scanners including SWIG (#2264) and QT: * http://scons.tigris.org/issues/show_bug.cgi?id=2264 - This enhancement broadens the horizon for handling heterogeneous data flow environments (E.G. software builds): - http://article.gmane.org/gmane.comp.programming.tools.scons.user/26596 - SCons may find new (and correct) dependencies in cross-langauge contexts. - Update may cause rebuilds, especially in heterogeneous data environments. - Update may find previously missed dependencies errors (E.G. cycles). - Discovered in some QT test cases. - SCons handles the SCANNERS variable differently. - Previously, the Install builder would scan implicit dependencies for a scanner found in SCANNERS (but not for built-in scanners), but now the Install builder will not scan recursively regardless in order to optimize Install behaviour and bring orthogonality to previous behaviour. - SCons handles cache directories a bit differently/ - Cache files are now stored in 256 subdirectories in the cache directory by default (this stresses NFS less). Existing cache directories will remain as current, but SCons will prompt you to run scons-configure-cache which will allow you to migrate to the new layout, or confirm you want to use the existing layout. - New external tool scons-configurecache which allows some configuration of how files in the cache are controlled. Please note the following important changes since release 2.4.0: - Fix to swig tool - pick-up 'swig', 'swig3.0' and 'swig2.0' (in order). - Fix to swig tool - respect env['SWIG'] provided by user. - Fix for Bug # 2791 - Setup.py fails unnecessarily under Jython. - Fixed license of SVG titlepage files in the context of Debian packaging, such that they allow for commercial use too (#2985). - InstallVersionedLib now available in the DefaultEnvironment context. - Improves orthogonality of use cases between different Install functions. - Added new configure check, CheckProg, to check for existence of a program. - Fix for issue #2840 - Fix for two environments specifying same target with different actions not throwing hard error. Instead SCons was incorrectly issuing a warning and continuing. - Add support `Microsoft Visual C++ Compiler for Python 2.7' Compiler can be obtained at: https://www.microsoft.com/en-us/download/details.aspx?id=44266 - Fixed tigris issue #3011: Glob() excludes didn't work when used with VariantDir(duplicate=0) - Fix bug 2831 and allow Help() text to be appended to AddOption() help. - Reimplemented versioning for shared libraries, with the following effects - Fixed tigris issues #3001, #3006. - Fixed several other issues not reported to tigris, including: issues with versioned libraries in subdirectories with tricky names, issues with versioned libraries and variant directories, issue with soname not being injected to library when using D linkers, - Switched to direct symlinks instead of daisy-chained ones -- soname and development symlinks point directly to the versioned shared library now), for rationale see: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages https://bitbucket.org/scons/scons/pull-requests/247/new-versioned-libraries-gnulink-cyglink/diff#comment-10063929 - New construction variables to allow override default behavior: SONAME, SHLIBVERSIONFLAGS, _SHLIBVERSIONFLAGS, SHLIBNOVERSIONSYMLINKS, LDMODULEVERSION, LDMODULEVERSIONFLAGS, _LDMODULEVERSIONFLAGS, LDMODULENOVERSIONSYMLINKS. - Changed logic used to configure the versioning machinery from platform-centric to linker-oriented. - The SHLIBVERSION/LDMODULEVERSION variables are no longer validated by SCons (more freedom to users). - InstallVersionedLib() doesn't use SHLIBVERSION anymore. - Enchanced docs for the library versioning stuff. - New tests for versioned libraries. - Library versioning is currently implemented for the following linker tools: 'cyglink', 'gnulink', 'sunlink'. Please note the following important changes since release 2.3.6: - Switch several core classes to use "slots" to reduce memory usage. (PR #2180, #2178, #2198) Please note the following important changes since release 2.3.5: - Support for Visual Studio 2015 Please note the following important changes since release 2.3.4: - Documentation fixes for libraries.xml and builders-writing.xml (#2989 and #2990) - Extended docs for InstallVersionedLib/SharedLibrary, and added SKIP_WIN_PACKAGES argument to build script bootstrap.py (PR #230, #3002). - Fixed symlink support (PR #227, #2395). - Updated debug-count test case (PR #229). - Fixed incomplete LIBS flattening and substitution in Program scanner(PR #205, #2954). - Added new method rentry_exists_on_disk to Node.FS (PR #193). - Fixed several D tests under the different OS. - Add support for f08 file extensions for Fortran 2008 code. - Show --config choices if no argument is specified (PR #202). - Fixed build crash when XML toolchain isn't installed, and activated compression for ZIP archives. - Fix for VersionedSharedLibrary under 'sunos' platform. - Fixed dll link with precompiled headers on MSVC 2012 - Added an 'exclude' parameter to Glob() - Support for multiple cmdargs (one per variant) in VS project files. - Various improvements for TempFileMunge class. - Added an implementation for Visual Studio users files (PR #209). - Added support for the 'PlatformToolset' tag in VS project files (#2978). - Added support for '-isystem' to ParseFlags. Please note the following important changes since release 2.3.3: -- Fix for EnsureSConsVersion regression in 2.3.3. -- Fix for interactive mode with Configure contexts Please note the following important changes since release 2.3.2: -- On Windows, .def files did not work as sources to shared libraries or executables, due to a regression which is corrected in 2.3.3. Please note the following important changes since release 2.3.0: -- BitKeeper, CVS, Perforce, RCS, SCCS are deprecated from the default toolset and will be removed from the default toolset in future SCons versions to speed up SCons initialization. The tools themselves continue to be supported. -- Support for Visual Studio 12.0Exp and 2013 -- Revamp of D language support, focusing on D v2. D v1 is now deprecated. -- Fixed NoClean() for multi-target builders. -- RPM and m4 are no longer in the default toolset on Windows. Should improve startup speed. -- TeX fixes: -synctex=1 and cleaning auxiliary files. -- Fixes to the Docbook tool. Please note the following important changes since release 2.3.0: -- Fix failure to relink when LINKCOM or libs change, introduced in 2.3.0. -- Fix MSVC defaulting TARGET_ARCH to HOST_ARCH and other MSVC issues. -- Reduced memory consumption in large builds, which should speed them up as well. -- Add new cyglink linker for use with cygwin. -- Fix leaking file handles to subprocesses -- Support read-only cache (--cache-readonly) -- Add Pseudo command to mark targets that shouldn't exist after building Please note the following important changes since release 2.2.0: -- SUPPORT FOR PYTHON VERSIONS BEFORE 2.7 IS NOW DEPRECATED ***IMPORTANT***: This release is the last version of SCons to support Python versions older than 2.7. This release will warn if you are running on Python 2.6 or older; future releases will probably not work at all, as we are moving toward supporting Python 3. Use --warn=no-python-version to suppress the warning if needed. -- A lot of python pre-2.4 compatibility code was removed in this release. 2.4 is the official floor for SCons, but this release will likely enforce it more rigidly. -- Spawning subprocesses on Windows should now be more reliable with -jN -- MSVC10 and MSVC11 support improved, and fixed MSVS11 solution generation. -- Various TeX/LaTeX builder improvements -- Support for versioned shared libs on Linux and Mac, via SHLIBVERSION and InstallVersionedLib. -- WiX builder updates Please note the following important changes since release 2.1.0: -- New gettext toolset for internationalization -- Support for Visual Studio 11 -- Support for Intel C/C++ compiler v12 on Linux and Mac -- LaTeX support for multibib, biblatex and biber Please note the following important changes since release 2.0.0: -- Support for Windows manifest generation -- SCons now searches sitewide dirs for site_scons -- Support for Latex bibunits package has been added along with support for tex files generated by other builders Please note the following important changes since release 1.3.0: -- SUPPORT FOR PYTHON VERSIONS PRIOR TO 2.4 HAS BEEN REMOVED Although SCons is still tested with Python 2.3, use of Python versions prior to 2.4 is deprecated. -- DEPRECATED FEATURES WILL GENERATE MANDATORY WARNINGS IN 2.0.0 In keeping with our deprecation cycle, the following deprecated features will still be supported in 2.0.0 but will generate mandatory, non-disableable warnings: -- The overrides= keyword argument to the Builder() call. -- The scanner= keyword argument to the Builder() call. -- The BuildDir() function and env.BuildDir() method. -- The env.Copy() method. -- The SourceSignatures() function and env.SourceSignatures() method. -- The TargetSignatures() function and env.TargetSignatures() method. -- The Sig module (now an unnused stub). -- The --debug=dtree, --debug=stree and --debug=tree options. -- The --debug=nomemoizer option. -- The Options object and the related BoolOption(), EnumOption(), ListOption(), PackageOption() and PathOption() functions. The mandatory warnings will be issued in order to make sure users of 1.3.0 notice *prior* to the release of SCons 2.0.0, that these features will be removed. In SCons 2.0.0 these features will no longer work at all, and will instead generate specific fatal errors when anyone tries to use them. Please note the following important changes since release 1.2.0: -- MICROSOFT VISUAL STUDIO VERSION/ARCH DETECTION HAS CHANGED The way SCons detects Visual Studio on Windows has changed in 1.3. By default, it should now use the latest installed Visual Studio version on your machine, and compile for 32 or 64 bits according to whether your OS is 32 or 64 bits (32/64 bit Python makes no difference). Two new variables control Visual Studio: MSVC_VERSION and TARGET_ARCH. These variables ONLY take effect when passed to the Environment() constructor; setting them later has no effect. To use a non-default Visual Studio version, set MSVC_VERSION to e.g. "8.0" or "7.1". Setting it to "xxx" (or any nonexistent value) will make it print out the valid versions on your system. To use a non-default architecture, set TARGET_ARCH to "x86" or "x86_64" (various synonyms are accepted). Note that if you use MSVS_VERSION to build Visual Studio projects from your SConstructs, MSVS_VERSION must be set to the same version as MSVC_VERSION. Support for HOST_OS,HOST_ARCH,TARGET_OS, TARGET_ARCH has been added to allow specifying different target arch than the host system. This is only supported for Visual Studio/Visual C++ at this time. -- Support for Latex glossaries and acronyms has been added -- VISUAL C/C++ PRECOMPILED HEADERS WILL BE REBUILT Precompiled header files built with Visual C/C++ will be rebuilt after upgrading from 1.2.0 to a later release. This rebuild is normal and will occur because the command line defined by the $PCHCOM construction variable has had the $CCFLAGS variable added, and has been rearranged to put the "/Fo" output flag towards the beginning of the line, consistent with the related command lines for $CCCOM, $CXXCOM, etc. -- CHANGES TO SOME LINKER COMMAND LINES WILL CAUSE RELINKING Changes to the command line definitions for the Microsoft link.exe linker, the OS/2 ilink linker and the Phar Lap linkloc linker will cause targets built with those tools be to be rebuilt after upgrading from 1.2.0 to a later release. This relink is normal and will occur because the command lines for these tools have been redefined to remove unnecessary nested $( and $) character strings. -- MSVS_USE_MFC_DIRS and MSVS_IGNORE_IDE_PATHS are obsoleted and have no effect. Please note the following important changes since release 1.1.0: -- THE $CHANGED_SOURCES, $CHANGED_TARGETS, $UNCHANGED_SOURCES AND $UNCHANGED_TARGETS VARIABLES WILL BECOME RESERVED A future release (probably 1.3.0) will make the construction variable names $CHANGED_SOURCES, $CHANGED_TARGETS, $UNCHANGED_SOURCES and $UNCHANGED_TARGETS into reserved construction variable names controlled by SCons itself (like the current $SOURCE, $TARGETS, etc.). Setting these variable names in the current release will generate a warning but still set the variables. When they become reserved variable names, they will generate a different warning message and attempts to set these variables will be ignored. SCons configurations that happen to use these variable names should be changed to use different variable names, in order to ensure that the configuration continues to work with future versions of SCons. -- THE Options OBJECT AND RELATED FUNCTIONS NOW GENERATE WARNINGS Use of the Options object, and related functions BoolOption(), EnumOption(), ListOption(), PackageOption() and PathOption() were announced as deprecated in release 0.98.1. Since then, however, no warning messages were ever implemented for the use of these deprecated functions. By default, release 1.2.0 prints warning messages when these deprecated features are used. Warnings about all deprecated features may be suppressed by using the --warn=no-deprecated command-line option: $ scons --warn=no-deprecated Or by using the appropriate SetOption() call in any SConscript file: SetOption('warn', 'no-deprecated') You may optionally disable just warnings about the deprecation of the Options object and its related functions as follows: SetOption('warn', 'no-deprecated-options') The current plan is for these warnings to become mandatory (non-suppressible) in release 1.3.0, and for the use of Options and its related functions to generate errors in release 2.0. Please note the following important changes since release 0.98.4: -- scons.bat NOW RETURNS THE REAL SCONS EXIT STATUS The scons.bat script shipped with SCons used to exit with a status of 1 when it detected any failed (non-zero) exit status from the underlying Python execution of SCons itself. The scons.bat script now exits with the actual status returned by SCons. -- SCONS NOW WARNS WHEN TRYING TO LINK C++ AND FORTRAN OBJECT FILES Some C++ toolchains do not understand Fortran runtimes and create unpredictable executables when linking C++ and Fortran object files together. SCons now issues a warning if you try to link C++ and Fortran object files into the same executable: scons: warning: Using $CXX to link Fortran and C++ code together. This may generate a buggy executable if the '/usr/bin/gcc' compiler does not know how to deal with Fortran runtimes. The warning may be suppressed with either the --warning=no-link or --warning=no-fortran-cxx-mix command line options, or by adding either of the following lines to a SConscript file: SetOption('warn', 'no-link') SetOption('warn', 'no-fortran-cxx-mix') Please note the following important changes since release 0.98: -- SCONS NO LONGER SETS THE GNU TOOLCHAIN -fPIC FLAG IN $SHCXXFLAGS The GNU toolchain support in previous versions of SCons would add the -fPIC flag to the $SHCXXFLAGS construction variable. The -fPIC flag has now been removed from the default $SHCXXFLAGS setting. Instead, the $SHCXXCOM construction variable (the default SCons command line for compiling shared objects from C++ source files) has been changed to add the $SHCCFLAGS variable, which contains the -fPIC flag. This change was made in order to make the behavior of the default C++ compilation line including $SHCCFLAGS consistent with the default C compilation line including $CCFLAGS. This change should have no impact on configurations that use the default $SHCXXCOM command line. It may have an impact on configurations that were using the default $SHCXXFLAGS value *without* the $SHCCFLAGS variable to get the -fPIC flag into a custom command line. You can fix these by adding the $SHCCFLAGS to the custom command line. Adding $SHCCFLAGS is backwards compatible with older SCons releases, although it might cause the -fPIC flag to be repeated on the command line if you execute it on an older version of SCons that sets -fPIC in both the $SHCCLAFGS and $SHCXXFLAGS variables. Duplicating the -fPIC flag on the g++ command line will not cause any compilation problems, but the change to the command line may cause SCons to rebuild object files. -- FORTRAN NOW COMPILES .f FILES WITH gfortran BY DEFAULT The Fortran Tool modules have had a major overhaul with the intent of making them work as-is for most configurations. In general, most configurations that use default settings should not see any noticeable difference. One configuration that has changed is if you have both a gfortran and g77 compiler installed. In this case, previous versions of SCons would, by default, use g77 by default to compile files with a .f suffix, while SCons 0.98.1 will use the gfortran compiler by default. The old behavior may be preserved by explicitly initializing construction environments with the 'g77' Tool module: env = Environment(tools = ['g77', 'default']) The above code is backwards compatible to older versions of SCons. If you notice any other changes in the behavior of default Fortran support, please let us know so we can document them in these release notes for other users. Please note the following important changes since release 0.97.0d20071212: -- SUPPORT FOR PYTHON VERSIONS BEFORE 2.2 IS NOW DEPRECATED SCons now prints the following warning when it is run by any Python 1.5, 2.0 or 2.1 release or sub-release: scons: warning: Support for pre-2.2 Python (VERSION) is deprecated. If this will cause hardship, contact scons-dev at scons.org You may disable all warnings about deprecated features by adding the option "--warn=no-deprecated" to the command line or to the $SCONSFLAGS environment variable: $ scons --warn=no-deprecated Using '--warn=no-deprecated' is compatible with earlier versions of SCons. You may also, as of this version of SCons, disable all warnings about deprecated features by adding the following to any SConscript file: SetOption('warn', 'no-deprecated') You may disable only the specific warning about running under a deprecated Python version by adding the following to any SConscript file: SetOption('warn', 'no-python-version') The warning may also be suppressed on the command line: $ scons --warn=no-python-version Or by specifying the --warn=no-python-version option in the $SCONSFLAGS environment variable. Using SetOption('warn', ...), and the 'no-python-version' command-line option for suppressing this specific warning, are *not* backwards-compatible to earlier versions of SCons. -- THE env.Copy() METHOD IS NOW OFFICIALLY DEPRECATED The env.Copy() method is now officially deprecated and will be removed in a future release. Using the env.Copy() method now generates the following message: scons: warning: The env.Copy() method is deprecated; use the env.Clone() method instead. You may disable all warnings about deprecated features by adding the option "--warn=no-deprecated" to the command line or to the $SCONSFLAGS environment variable: $ scons --warn=no-deprecated Using '--warn=no-deprecated' is compatible with earlier versions of SCons. You may also, as of this version of SCons, disable all warnings about deprecated features by adding the following to any SConscript file: SetOption('warn', 'no-deprecated') You may disable only the specific warning about the deprecated env.Copy() method by adding the following to any SConscript file: SetOption('warn', 'no-deprecated-copy') The warning may also be suppressed on the command line: $ scons --warn=no-deprecated-copy Or by specifying the --warn=no-deprecated-copy option in the $SCONSFLAGS environment variable. Using SetOption('warn', ...), and the 'no-deprecated-copy' command-line option for suppressing this specific warning, are *not* backwards-compatible to earlier versions of SCons. -- THE --debug=dtree, --debug=stree AND --debug=tree OPTIONS ARE DEPRECATED The --debug=dtree, --debug=stree and --debug=tree methods are now officially deprecated and will be removed in a future release. Using these options now generate a warning message recommending use of the --tree=derived, --tree=all,status and --tree=all options, respectively. You may disable these warnings, and all warnings about deprecated features, by adding the option "--warn=no-deprecated" to the command line or to the $SCONSFLAGS environment variable: $ scons --warn=no-deprecated Using '--warn=no-deprecated' is compatible with earlier versions of SCons. -- THE TargetSignatures() AND SourceSignatures() FUNCTIONS ARE DEPRECATED The TargetSignatures() and SourceSignatures() functions, and their corresponding env.TargetSignatures() and env.SourceSignatures() methods, are now officially deprecated and will be be removed in a future release. Using ahy of these functions or methods now generates a message similar to the following: scons: warning: The env.TargetSignatures() method is deprecated; convert your build to use the env.Decider() method instead. You may disable all warnings about deprecated features by adding the option "--warn=no-deprecated" to the command line or to the $SCONSFLAGS environment variable: $ scons --warn=no-deprecated Using '--warn=no-deprecated' is compatible with earlier versions of SCons. You may also, as of this version of SCons, disable all warnings about deprecated features by adding the following to any SConscript file: SetOption('warn', 'no-deprecated') You may disable only the specific warning about the use of TargetSignatures() or SourceSignatures() by adding the following to any SConscript file: SetOption('warn', 'no-deprecated-target-signatures') SetOption('warn', 'no-deprecated-source-signatures') The warnings may also be suppressed on the command line: $ scons --warn=no-deprecated-target-signatures --warn=no-deprecated-source-signatures Or by specifying these options in the $SCONSFLAGS environment variable. Using SetOption('warn', ...), or the command-line options for suppressing these warnings, is *not* backwards-compatible to earlier versions of SCons. -- File(), Dir() and Entry() NOW RETURN A LIST WHEN THE INPUT IS A SEQUENCE Previously, if these methods were passed a list, the list was substituted and stringified, then passed as a single string to create a File/Dir/Entry Node. This rarely if ever worked with more than one element in the list. They now return a list of Nodes when passed a list. One case that works differently now is a passing in a single-element sequence; that formerly was stringified (returning its only element) and then a single Node would be returned. Now a single-element list containing the Node will be returned, for consistency. -- THE env.subst() METHOD NOW RETURNS A LIST WHEN THE INPUT IS A SEQUENCE The env.subst() method now returns a list with the elements expanded when given a list as input. Previously, the env.subst() method would always turn its result into a string. This behavior was changed because it interfered with being able to include things like lists within the expansion of variables like $CPPPATH and then have SCons understand that the elements of the "internal" lists still needed to be treated separately. This would cause a $CPPPATH list like ['subdir1', 'subdir'] to show up in a command line as "-Isubdir1 subdir". -- THE Jar() BUILDER NOW USES THE Java() BUILDER CLASSDIR BY DEFAULT By default, the Jar() Builder will now use the class directory specified when the Java() builder is called. So the following input: classes = env.Java('classes', 'src') env.Jar('out.jar', classes) Will cause "-C classes" to be passed the "jar" command invocation, and the Java classes in the "out.jar" file will not be prefixed "classes/". Explicitly setting the $JARCHDIR variable overrides this default behavior. The old behavior of not passing any -C option to the "jar" command can be preserved by explicitly setting $JARCHDIR to None: env = Environment(JARCHDIR = None) The above setting is compatible with older versions of SCons. Please note the following important changes since release 0.97.0d20070918: -- SCons REDEFINES PYTHON open() AND file() ON Windows TO NOT PASS ON OPEN FILE HANDLES TO CREATED PROCESSES On Windows systems, SCons now redefines the Python open() and file() functions so that, if the Python Win32 extensions are available, the file handles for any opened files will *not* be inherited by subprocesses, such as the spawned compilers and other tools invoked to build the software. This prevents certain race conditions where a file handle for a file opened by Python (either in a Python function action, or directly in a SConscript file) could be inherited and help open by a subprocess, interfering with the ability of other processes to create or modify the file. In general, this should not cause problems for the vast majority of configurations. The only time this would be a problem would be in the unlikely event that a process spawned by SCons specifically *expected* to use an inherited file handle opened by SCons. If the Python Win32 extensions are not installed or are an earlier version that does not have the ability to disable file handle inheritance, SCons will print a warning message when the -j option is used. The warning message may be suppressed by specifying --warn=no-parallel-support. Please note the following important changes since release 0.97.0d20070809: -- "content" SIGNATURES ARE NOW THE DEFAULT BEHAVIOR The default behavior of SCons is now to use the MD5 checksum of all file contents to decide if any files have changed and should cause rebuilds of their source files. This means that SCons may decide not to rebuild "downstream" targets if a a given input file is rebuilt to the exact same contents as the last time. The old behavior may preserved by explicity specifying: TargetSignatures("build") In any of your SConscript files. -- TARGETS NOW IMPLICITLY DEPEND ON THE COMMAND THAT BUILDS THEM For all targets built by calling external commands (such as a compiler or other utility), SCons now adds an implicit dependency on the command(s) used to build the target. This will cause rebuilds of all targets built by external commands when running SCons in a tree built by previous version of SCons, in order to update the recorded signatures. The old behavior of not having targets depend on the external commands that build them can be preserved by setting a new $IMPLICIT_COMMAND_DEPENDENCIES construction variable to a non-True value: env = Environment(IMPLICIT_COMMAND_DEPENDENCIES = 0) or by adding Ignore() calls for any targets where the behavior is desired: Ignore('/usr/bin/gcc', 'foo.o') Both of these settings are compatible with older versions of SCons. -- CHANGING SourceSignature() MAY CAUSE "UNECESSARY" REBUILDS If you change the SourceSignature() value from 'timestamp' to 'MD5', SCons will now rebuild targets that were already up-to-date with respect to their source files. This will happen because SCons did not record the content signatures of the input source files when the target was last built--it only recorded the timestamps--and it must record them to make sure the signature information is correct. However, the content of source files may have changed since the last timestamp build was performed, and SCons would not have any way to verify that. (It would have had to open up the file and record a content signature, which is one of the things you're trying to avoid by specifying use of timestamps....) So in order to make sure the built targets reflect the contents of the source files, the targets must be rebuilt. Change the SourceSignature() value from 'MD5' to 'timestamp' should correctly not rebuild target files, because the timestamp of the files is always recorded. In previous versions of SCons, changing the SourceSignature() value would lead to unpredictable behavior, usually including rebuilding targets. -- THE Return() FUNCTION NOW ACTUALLY RETURNS IMMEDIATELY The Return() function now immediately stops processing the SConscript file in which it appears and returns the values of the variables named in its arguments. It used to continue processing the rest of the SConscript file, and then return the values of the specified variables at the point the Return() function was called. The old behavior may be requested by adding a "stop=False" keyword argument to the Return() call: Return('value', stop=False) The "stop=" keyword argument is *not* compatible with SCons versions 0.97.0d20070809 or earlier. Please note the following important changes since release 0.97: -- env.CacheDir() NOW ONLY AFFECTS CONSTRUCTION ENVIRONMENT TARGETS The env.CacheDir() method now only causes derived files to be retrieved from the specified cache directory for targets built with the specified specified construction environment ("env"). Previously, any call to env.CacheDir() or CacheDir() would modify a global setting and cause all built targets to be retrieved from the specified cache directory. This behavior was changed so that env.CacheDir() would be consistent with other construction environment methods, which only affect targets built with the specified construction environment. The old behavior of changing the global behavior may be preserved by changing any env.CacheDir() calls to: CacheDir('/path/to/cache/directory') The above change is backwards-compatible and works in all earlier versions of SCons that support CacheDir(). -- INTERPRETATION OF SUFFIX-LESS SOURCE ARGUMENTS HAS CHANGED The interpretation of source arguments (files) without suffixes has changed in one specific configuration. Previously, if a Builder had a src_suffix specified (indicating that source files without suffixes should have that suffix appended), the suffix would only be applied to suffix-less source arguments if the Builder did *not* have one or more attached source Builders (that is, the Builder was not a "multi-stage" Builder). So in the following configuration: build_foo = Builder(src_suffix = '.foo') build_bar = Builder(src_suffix = '.bar', src_builder = build_bar) env = Environment(BUILDERS = { 'Foo' : build_foo, 'Boo' : build_bar, }) env.Foo('tgt1', 'src1') env.Bar('tgt2', 'src2') SCons would have expected to find a source file 'src1.foo' for the env.Foo() call, but a source file 'src2' for the env.Bar() call. This behavior has now been made consistent, so that the two above calls would expect source files named 'src1.foo' and 'src2.bar', respectively. Note that, if genuinely desired, the old behavior of building from a source file without a suffix at all (when the Builder has a src_suffix *and* a src_builder) can be specified explicity by turning the string into a File Node directly: env.Bar('tgt2', File('src2')) The above use of File() is backwards-compatible and will work on earlier versions of SCons. -- THE DEFAULT EXECUTION PATH FOR Solaris HAS CHANGED On Solaris systems, SCons now adds the "/opt/SUNWspro/bin" directory to the default execution $PATH variable before the "/usr/ccs/bin" directory. This was done to reflect the fact that /opt/SUNWspro/ is the default for SUN tools, but it may cause a different compiler to be used if you have compilers installed in both directories. -- GENERATED config.h FILES NOW SAY "#define HAVE_{FEATURE} 1" When generating a "config.h" file, SCons now defines values that record the existence of a feature with a "1" value: #define HAVE_FEATURE 1 Instead of printing the line without a "1", as it used to: #define HAVE_FEATURE This should not cause any problems in the normal use of "#ifdef HAVE_{FEATURE}" statements interpreted by a C preprocessor, but might cause a compatibility issue if a script or other utility looks for an exact match of the previous text. Please note the following planned, future changes: -- THE Options OBJECT AND RELATED FUNCTIONS WILL BE DEPRECATED The Options object is being replaced by a new Variables object, which uses a new Variables.AddVariable() method where the previous interface used Options.AddOptions(). Similarly, the following utility functions are being replaced by the following similarly-named functions: BoolOption() BoolVariable() EnumOption() EnumVariable() ListOption() ListVariable() PackageOption() PackageVariable() PathOption() PathVariable() And also related, the options= keyword argument when creating construction environments with the Environment() functions is being replaced with a variables= keyword argument. In some future release a deprecation warning will be added to existing uses of the Options object, its methods, the above utility functions, and the options= keyword argument of the Environment() function. At some point after the deprecation warning is added, the Options object, related functions and options= keyword argument will be removed entirely. You can prepare for this by changing all your uses of the Options object and related functions to the Variables object and the new function names, and changing any uses of the options= keyword argument to variables=. NOTE: CONVERTING TO USING THE NEW Variables OBJECT OR THE RELATED *Variable() FUNCTIONS, OR USING THE NEW variable= KEYWORD ARGUMENT, IS NOT BACKWARDS COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING THIS CHANGE. If you change SConscript files in software that you make available for download or otherwise distribute, other users may try to build your software with an earlier version of SCons that does not have the Variables object or related *Variable() functions. We recommend preparing for this in one of two ways: -- Make your SConscript files backwards-compatible by modifying your calls with Python try:-except: blocks as follows: try: vars = Variables('custom.py', ARGUMENTS) vars.AddVariables( BoolVariable('WARNINGS', 'cmopile with -Wall', 1), EnumVariable('DEBUG', 'debug version', 'no' allowed_values=('yes', 'no', 'full'), map={}, ignorecase=0), ListVariable('SHAREDLIBS', 'libraries to build shared', 'all', names = list_of_libs), PackageVariable('X11', 'use X11 from here', '/usr/bin/X11'), PathVariable('QTDIR', 'root of Qt', qtdir), ) except NameError: vars = Options('custom.py', ARGUMENTS) vars.AddOptions( BoolOption('WARNINGS', 'cmopile with -Wall', 1), EnumOption('DEBUG', 'debug version', 'no' allowed_values=('yes', 'no', 'full'), map={}, ignorecase=0), ListOption('SHAREDLIBS', 'libraries to build shared', 'all', names = list_of_libs), PackageOption('X11', 'use X11 from here', '/usr/bin/X11'), PathOption('QTDIR', 'root of Qt', qtdir), ) Additionally, you can check for availability of the new variables= keyword argument as follows: try: env = Environment(variables=vars) except TypeError: env = Environment(options=vars) (Note that we plan to maintain the existing Options object name for some time, to ensure backwards compatibility, so in practice it may be easier to just continue to use the old name until you're reasonably sure you won't have people trying to build your software with versions of SCons earlier than 0.98.1.) -- Use the EnsureSConsVersion() function to provide a descriptive error message if your SConscript files are executed by an earlier version of SCons: EnsureSConsVersion(0, 98, 1) -- THE BuildDir() METHOD AND FUNCTION WILL BE DEPRECATED The env.BuildDir() method and BuildDir() function are being replaced by the new env.VariantDir() method and VariantDir() function. In some future release a deprecation warning will be added to existing uses of the env.BuildDir() method and BuildDir() function. At some point after the deprecation warning, the env.Builder() method and BuildDir() function will either be removed entirely or have their behavior changed. You can prepare for this by changing all your uses of the env.BuildDir() method to env.VariantDir() and uses of the global BuildDir() function to VariantDir(). If you use a named keyword argument of "build_dir" when calling env.BuildDir() or BuildDir(): env.BuildDir(build_dir='opt', src_dir='src') The keyword must be changed to "variant_dir": env.VariantDir(variant_dir='opt', src_dir='src') NOTE: CHANGING USES OF env.BuildDir() AND BuildDir() to env.VariantDir() AND VariantDir() IS NOT BACKWARDS COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING THIS CHANGE. If you change SConscript files in software that you make available for download or otherwise distribute, other users may try to build your software with an earlier version of SCons that does not have the env.VariantDir() method or VariantDir() fnction. We recommend preparing for this in one of two ways: -- Make your SConscript files backwards-compatible by including the following code near the beginning of your top-level SConstruct file: import SCons.Environment try: SCons.Environment.Environment.VariantDir except AttributeError: SCons.Environment.Environment.VariantDir = \ SCons.Environment.Environment.BuildDir -- Use the EnsureSConsVersion() function to provide a descriptive error message if your SConscript files are executed by an earlier version of SCons: EnsureSConsVersion(0, 98) -- THE SConscript() "build_dir" KEYWORD ARGUMENT WILL BE DEPRECATED The "build_dir" keyword argument of the SConscript function and env.SConscript() method are being replaced by a new "variant_dir" keyword argument. In some future release a deprecation warning will be added to existing uses of the SConscript()/env.SConscript() "build_dir" keyword argument. At some point after the deprecation warning, support for this keyword argument will be removed entirely. You can prepare for this by changing all your uses of the SConscript()/env.SConscript() 'build_dir" keyword argument: SConscript('src/SConscript', build_dir='opt') To use the new "variant_dir" keyword argument: SConscript('src/SConscript', variant_dir='opt') NOTE: USING THE NEW "variant_dir" KEYWORD IS NOT BACKWARDS COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING THIS CHANGE. If you change SConscript files in software that you make available for download or otherwise distribute, other users may try to build your software with an earlier version of SCons that does not support the "variant_dir" keyword. If you can insist that users use a recent version of SCons that supports "variant_dir", we recommend using the EnsureSConsVersion() function to provide a descriptive error message if your SConscript files are executed by an earlier version of SCons: EnsureSConsVersion(0, 98) If you want to make sure that your SConscript files will still work with earlier versions of SCons, then your best bet is to continue to use the "build_dir" keyword until the support is removed (which, in all likelihood, won't happen for quite some time). -- SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED Several internal variable names in SCons.Defaults for various pre-made default Scanner objects have been deprecated and will be removed in a future revision. In their place are several new global variable names that are now part of the publicly-supported interface: NEW NAME DEPRECATED NAME -------- ---------------------------- CScanner SCons.Defaults.CScan DSCanner SCons.Defaults.DScan SourceFileScanner SCons.Defaults.ObjSourceScan ProgramScanner SCons.Defaults.ProgScan Of these, only ObjSourceScan was probably used at all, to add new mappings of file suffixes to other scanners for use by the Object() Builder. This should now be done as follows: SourceFileScanner.add_scanner('.x', XScanner) -- THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY The env.Copy() method (to make a copy of a construction environment) is being replaced by the env.Clone() method. As of SCons 0.98, a deprecation warning has been added to current uses of the env.Copy() method. At some point in the future, the env.Copy() method will either be removed entirely or have its behavior changed. You can prepare for this by changing all your uses of env.Copy() to env.Clone(), which has the exact same calling arguments. NOTE: CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE YOUR SConscript FILES NOT WORK ON VERSIONS OF SCons BEFORE 0.96.93. If you change SConscript files in software that you make available for download or otherwise distribute, other users may try to build your software with an earlier version of SCons that does not have the env.Clone() method. We recommend preparing for this in one of two ways: -- Make your SConscript files backwards-compatible by including the following code near the beginning of your top-level SConstruct file: import SCons.Environment try: SCons.Environment.Environment.Clone except AttributeError: SCons.Environment.Environment.Clone = \ SCons.Environment.Environment.Copy -- Use the EnsureSConsVersion() function to provide a descriptive error message if your SConscript files are executed by an earlier version of SCons: EnsureSConsVersion(0, 96, 93) -- THE CheckLib Configure TEST WILL CHANGE BEHAVIOR The CheckLib() Configure test appends the lib(s) to the Environment's LIBS list in 1.3 and earlier. In 1.3 there is a new CheckLib argument, append, which defaults to True to preserve the old behavior. In a future release, append will be changed to default to False, to conform with autoconf and user expectations, since it is usually used to build up library lists in a right-to-left way. SCons is developed with an extensive regression test suite, and a rigorous development methodology for continually improving that suite. Because of this, SCons is of sufficient quality that you can use it for real work. The interfaces in release 1.0 will *not* be knowingly changed in any new, future 1.x release. If an interface change should ever become necessary due to extraordinary circumstances, the change and an appropriate transition strategy will be documented in these RELEASE notes. As you use SCons, please heed the following: - Please report any bugs or other problems that you find to our bug tracker at our SourceForge project page: http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971 We have a reliable bug-fixing methodology already in place and strive to respond to problems relatively quickly. - Documentation is spottier than we'd like. You may need to dive into the source code to figure out how to do something. Asking questions on the scons-users mailing list is also welcome. We will be addressing the documentation in upcoming releases, but would be more than glad to have your assistance in correcting this problem... :-) - The "SCons Design" documentation on the SCons web site is very out of date, as we made significant changes to portions of the interface as we figured out what worked and what didn't during the extensive beta implementation. The "SCons Design" document should be used only for historical purposes, or for just an extremely general understanding of SCons' architectural goals. - There may be performance issues. Improving SCons performance is an ongoing priority. If you still find the performance unacceptable, we would very much like to hear from you and learn more about your configuration so we can optimize the right things. - Error messages don't always exist where they'd be helpful. Please let us know about any errors you ran into that would have benefitted from a (more) descriptive message. KNOWN PROBLEMS IN THIS RELEASE: For a complete list of known problems, consult the SCons Issue Tracker at tigris.org: http://scons.tigris.org/project_issues.html - Support for parallel builds (-j) does not work on WIN32 systems prior to *official* Python release 2.2 (not 2.2 pre-releases). Prior to Python 2.2, there is a bug in Python's Win32 implementation such that when a thread spawns an external command, it blocks all threads from running. This breaks the SCons multithreading architecture used to support -j builds. We have included a patch file, os_spawnv_fix.diff, that you can use if you you want to fix your version of Python to support parallel builds in SCons. - Again, the "SCons Design" documentation on the SCons web site is out of date. Take what you read there with a grain of salt. - On Win32 systems, you must put a space between the redirection characters < and >, and the specified files (or construction variable expansions): command < $SOURCE > $TARGET If you don't supply a space (for example, "<$SOURCE"), SCons will not recognize the redirection. - MSVC .res files are not rebuilt when icons change. - The -c option does not clean up .sconsign files or directories created as part of the build, and also does not clean up SideEffect files (for example, Visual Studio .pdb files). - When using multiple Repositories, changing the name of an include file can cause an old version of the file to be used. - There is currently no way to force use of a relative path (../*) for directories outside the top-level SConstruct file. - The Jar() Builder will, on its second or subsequent invocation, package up the .sconsign files that SCons uses to track signatures. You can work around this by using the SConsignFile() function to collect all of the .sconsign information into a single file outside of the directory being packaged by Jar(). - SCons does not currently have a way to detect that an intermediate file has been corrupted from outside and should be rebuilt. - Unicode characters in path names do not work in all circumstances. - SCons does not currently automatically check out SConstruct or SConscript files from SCCS, RCS or BitKeeper. - No support yet for the following planned command-line options: -d -e -l --list-actions --list-derived --list-where -o --override -p -r -R -w --write-filenames -W --warn-undefined-variables Thank you for your interest, and please let us know how we can help improve SCons for your needs. -- The SCons Development Team Gary Oberbrunner and Bill Deegan, maintainers Thanks to all the contributors for all your help! From nicoddemus at gmail.com Tue Nov 14 15:35:52 2017 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 14 Nov 2017 20:35:52 +0000 Subject: pytest 3.2.4 released! Message-ID: pytest 3.2.4 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at http://doc.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Bruno Oliveira * Christian Boelsen * Christoph Buchner * Daw-Ran Liou * Florian Bruhin * Franck Michea * Leonard Lausen * Matty G * Owen Tuz * Pavel Karateev * Pierre GIRAUD * Ronny Pfannschmidt * Stephen Finucane * Sviatoslav Abakumov * Thomas Hisch * Tom Dalton * Xuan Luong * Yorgos Pagles * ????? ???????? Happy testing, The pytest Development Team From nicoddemus at gmail.com Wed Nov 15 06:29:03 2017 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Wed, 15 Nov 2017 11:29:03 +0000 Subject: pytest 3.2.5 hot-fix released Message-ID: pytest 3.2.5 has just been released to PyPI. This is a hot-fix release: pytest-3.2.4 imposed a restriction of "py<1.5" because py-1.5.0 has dropped py26 and py33 support, but this can cause problems on some installations due to pip's dependency resolver. For more details see this issue: https://github.com/pytest-dev/pytest/issues/2926 To update: pip install --upgrade pytest The pytest Development Team is sorry for the inconvenience this might have caused, apologies. Thanks to the user @uSpike which quickly reported the issue. Happy testing, The pytest Development Team From peter.allen.hamilton at gmail.com Tue Nov 14 16:43:16 2017 From: peter.allen.hamilton at gmail.com (Peter Hamilton) Date: Tue, 14 Nov 2017 16:43:16 -0500 Subject: PyKMIP 0.7.0 Message-ID: I am pleased to announce the release of PyKMIP 0.7.0. PyKMIP is a Python implementation of the Key Management Interoperability Protocol (KMIP), a communications protocol for the storage and maintenance of keys, certificates, and other secret objects. PyKMIP provides clients for conducting key management operations against KMIP appliances and a software server application for testing and demonstration. The library is licensed under Apache 2.0 and supports Python 2.7, 3.3-3.6. Changelog: * Add support for Python 3.6 * Add support for the InitialDate attribute * Add server support for the GetAttributeList operation * Add server support for the Locate operation * Add client and server support for the MAC operation * Add client and server support for the Revoke operation * Add client and server support for the Encrypt operation * Add client and server support for the Decrypt operation * Add client and server support for the DeriveKey operation * Add client and server support for the Sign operation * Add client and server support for the SignatureVerify operation * Add client and server support for retrieving wrapped keys * Add client and server support for storing wrapped keys * Add KMIP 1.4 enumerations * Add server config option enabling certificate extension checks * Add server config option defining set of usable TLS ciphers * Add server config option setting the server log level * Update the server to enforce checking object state and usage masks * Update server Locate support to allow object name filtering * Remove support for Python 2.6 * Fix bug with multithreading support with the SQLite backend * Fix bug with how open() is mocked in the server test suite * Fix bug with mismapped polymorphic identity for certificate objects * Fix bug with socket interrupt handling under Python 3.5 * Fix bug with detached instance errors in the server test suite GitHub: https://github.com/OpenKMIP/PyKMIP PyPI: https://pypi.python.org/pypi/PyKMIP/0.7.0 IRC: #pykmip on freenode.net Thanks to all of the contributors for their time and effort. Cheers, Peter Hamilton From phd at phdru.name Wed Nov 15 09:13:20 2017 From: phd at phdru.name (Oleg Broytman) Date: Wed, 15 Nov 2017 15:13:20 +0100 Subject: SQLObject 3.5.0 Message-ID: <20171115141320.GA28654@phdru.name> Hello! I'm pleased to announce version 3.5.0, the first stable release of branch 3.5 of SQLObject. What's new in SQLObject ======================= Contributors for this release are Shailesh Mungikar and Michael S. Root. Minor features -------------- * Add Python3 special methods for division to SQLExpression. Pull request by Michael S. Root. Drivers ------- * Add support for `pg8000 `_ PostgreSQL driver. * Fix autoreconnect with pymysql driver. Contributed by Shailesh Mungikar. Documentation ------------- * Remove generated HTML from eggs/wheels (docs are installed into wrong place). Generated docs are still included in the source distribution. Tests ----- * Add tests for PyGreSQL, py-postgresql and pg8000 at AppVeyor. * Fixed bugs in py-postgresql at AppVeyor. SQLObject requires the latest version of the driver from our fork. For a more complete list, please see the news: http://sqlobject.org/News.html What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Python 2.7 or 3.4+ is required. Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Download: https://pypi.python.org/pypi/SQLObject/3.5.0 News and changes: http://sqlobject.org/News.html StackOverflow: https://stackoverflow.com/questions/tagged/sqlobject Example ======= Create a simple class that wraps a table:: >>> from sqlobject import * >>> >>> sqlhub.processConnection = connectionForURI('sqlite:/:memory:') >>> >>> class Person(SQLObject): ... fname = StringCol() ... mi = StringCol(length=1, default=None) ... lname = StringCol() ... >>> Person.createTable() Use the object:: >>> p = Person(fname="John", lname="Doe") >>> p >>> p.fname 'John' >>> p.mi = 'Q' >>> p2 = Person.get(1) >>> p2 >>> p is p2 True Queries:: >>> p3 = Person.selectBy(lname="Doe")[0] >>> p3 >>> pc = Person.select(Person.q.lname=="Doe").count() >>> pc 1 Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From mal at europython.eu Wed Nov 15 10:51:05 2017 From: mal at europython.eu (M.-A. Lemburg) Date: Wed, 15 Nov 2017 16:51:05 +0100 Subject: EuroPython 2018: Location and Dates Message-ID: <667c23bd-b27f-c06e-220b-61ac87f1f69b@europython.eu> After a two month RFP bidding process with 19 venues from all over Europe, we are pleased to announce our selection of the location and venue for EuroPython 2018: * Location: Edinburgh, UK * Venue: Edinburgh International Conference Center (EICC) http://www.eicc.co.uk/ * Dates: July 23 - 29 2018 ... yes, this is just one week before the famous Edinburgh Festival Fringe, so you can extend your stay a little longer if you like: https://www.edfringe.com/ Based on the feedback we collected in the last few years, we have switched to a more compact conference layout for 2018: * Monday, Tuesday: Workshops and Trainings * Wednesday, Thursday, Friday: Main conference with talks, keynotes, exhibition * Saturday, Sunday: Sprints More information will be available as we progress with the organization. PS: We are now entering contract negotiations, so the above dates are highly likely, but we cannot confirm 100% yet. Enjoy, -- EuroPython Society http://www.europython-society.org/ PS: Please forward or retweet to help us reach all interested parties: https://twitter.com/europythons/status/930823621202898945 Thanks. From juanlu001 at gmail.com Sun Nov 19 13:08:58 2017 From: juanlu001 at gmail.com (Juan Luis Cano) Date: Sun, 19 Nov 2017 19:08:58 +0100 Subject: =?UTF-8?B?QU5OOiBwb2xpYXN0cm8gMC44IHJlbGVhc2VkIPCfmoA=?= Message-ID: Hi all, It fills us with astronomical joy to announce the release of *poliastro 0.8.0*! ? poliastro is a pure Python library that allows you to simulate and analyze interplanetary orbits in a Jupyter notebook in an interactive and easy way, used by people from all around the world. This release brought a feature that has been in the making for several years: an easy 3D plotting interface! Thanks to the new sampling methods and the integration of Plotly and the Jupyter notebook, you can now plot orbits in three dimensions and interactively rotate the view. Make sure to check out the new notebook example here: http://docs.poliastro.space/en/latest/examples/Plotting%20in%203D.html On the other hand, we are proud to announce that we have been accepted as an affiliated Astropy package, and that this work will be presented during the first Open Source Cubesat Workshop at the European Space Operations Centre in Darmstadt, Germany. As usual, you can read the full release notes here: http://docs.poliastro.space/en/v0.8.0/changelog.html#poliastro-0-8-0-2017-11-18 If you want to know more, don't miss my talk on EuroPython 2016: https://youtu.be/VCpTgU1pb5k We encourage you to join our chat on Matrix: https://riot.im/app/#/room/#poliastro:matrix.org Per Python ad astra! -- Juan Luis Cano From Stefan.Richthofer at gmx.de Mon Nov 20 13:02:36 2017 From: Stefan.Richthofer at gmx.de (Stefan Richthofer) Date: Mon, 20 Nov 2017 19:02:36 +0100 Subject: pytypes 1.0 beta 3 released References: Message-ID: pytypes 1.0 beta 3 has been released. https://github.com/Stewori/pytypes The most notable new feature is enhanced support for TypeVars. Besides this it is mainly a bugfix release. pytypes is a toolbox for PEP-484 style typing, explicitly supporting Python >= 3.3, Python 2.7, Jython >= 2.7.1, PyPy 3. Its main features include: - Runtime typechecking - Auto-annotating code from runtime observations in form of stubfiles - Utility functions: * PEP 484 aware subtype and instance checking: is_of_type(obj, tp) and is_subtype(subtype, supertype) * get_type_hints that takes stubfiles and type comments into account - Typesafe method overriding - Pull type information from stubfiles or type comments into __annotations__ for use by other tools - support for all versions of typing module - support for Python 2.7, 3.3, 3.4, 3.5, 3.6, Jython 2.7.1, PyPy - all features smoothly work with OOP, i.e. methods, static methods, class methods, properties pytypes is still in beta phase. File issues as the occur. Help is welcome! Github: https://github.com/Stewori/pytypes/releases PyPI: https://pypi.python.org/pypi/pytypes License: Apache 2.0 Enjoy! -Stefan From info at egenix.com Thu Nov 23 05:31:47 2017 From: info at egenix.com (eGenix Team: M.-A. Lemburg) Date: Thu, 23 Nov 2017 11:31:47 +0100 Subject: ANN: PyDDF Python Herbst Sprint 2017 Message-ID: <534684ef-ec39-2e96-969f-877dda8a9c4c@egenix.com> [This announcement is in German since it targets a Python sprint in D?sseldorf, Germany] ________________________________________________________________________ ANK?NDIGUNG PyDDF Python Herbst Sprint 2017 in D?sseldorf Samstag, 25.11.2017, 10:00-18:00 Uhr Sonntag, 26.11.2017, 10:00-18:00 Uhr trivago GmbH, Karl-Arnold-Platz 1A, 40474 D?sseldorf Python Meeting D?sseldorf https://www.pyddf.de/sprint2017-11/ ________________________________________________________________________ INFORMATION Das Python Meeting D?sseldorf (PyDDF) veranstaltet mit freundlicher Unterst?tzung der *trivago GmbH* ein Python Sprint Wochenende im September. Der Sprint findet am Wochenende 25./26.11.2017 in der trivago Niederlassung am Karl-Arnold-Platz 1A statt (nicht am Bennigsen-Platz 1). Folgende Themengebiete haben wir als Anregung angedacht: * Willkommens-Chatbot f?r D?sseldorf mir RasaHQ * PyEditor oder django-reversion-compare * Django Autotask oder FirtzConnection * YouTube Video Manager CLI * Kivy * Formula Pi (Roboter Rennen) * Jython Nat?rlich kann jeder Teilnehmer weitere Themen vorschlagen. Alles weitere und die Anmeldung findet Ihr auf der Sprint Seite: https://www.pyddf.de/sprint2017-11/ Teilnehmer sollten sich zudem auf der PyDDF Liste anmelden, da wir uns dort koordinieren: https://www.egenix.com/mailman/listinfo/pyddf ________________________________________________________________________ ?BER UNS Das Python Meeting D?sseldorf (PyDDF) ist eine regelm??ige Veranstaltung in D?sseldorf, die sich an Python Begeisterte aus der Region wendet: * https://pyddf.de/ Einen guten ?berblick ?ber die Vortr?ge bietet unser YouTube-Kanal, auf dem wir die Vortr?ge nach den Meetings ver?ffentlichen: * http://www.youtube.com/pyddf/ Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, D?sseldorf: * http://www.egenix.com/ * http://www.clark-consulting.eu/ Mit freundlichen Gr??en, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 23 2017) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From apalala at gmail.com Sun Nov 26 17:35:50 2017 From: apalala at gmail.com (=?UTF-8?Q?Juancarlo_A=C3=B1ez?=) Date: Sun, 26 Nov 2017 18:35:50 -0400 Subject: TatSu v4.2.5 released Message-ID: ? TatSu (the successor to Grako) is a tool that takes grammars in a variation of EBNF as input, and outputs memoizing (Packrat) PEG parsers in Python. ? TatSu can compile a grammar stored in a string into a tatsu.grammars.Grammar object that can be used to parse any given input, much like the re module does with regular expressions, or it can generate a Python module that implements the parser. ? TatSu fully supports left-recursive rules in PEG grammars using the algorithm by Laurent and Mens. The generated AST has the expected left associativity. https://github.com/neogeny/TatSu http://tatsu.readthedocs.io/en/stable/ v4.2.5 -------- * #42 Rename vim files from grako.vim to tatsu.vim (@fcoelho ) * #51 Fix inconsistent code generation for whitespace (@fpom ) * #54 Only care about case of first letter of rule name for determining advance over whitespace (@acw1251 ) v4.2.4 --------- * #40 Make the start rule default to the first rule defined in the grammar (@hariedo) * #43 Import re from tatsu.util to support optional regex-only features (@azazel75) * #47 Fix incorrect sample code in documentation v4.2.3 -------- * #37 Regression: The #include pragma works by using the EBNFBuffer from grammars.py. Somehow the default EBNFBootstrapBuffer from bootstrap.py has been used instead (@gegenschall). * #38 Documentation: Use of json.dumps() requires ast.asjson() (@davidchen). -- Juancarlo *A?ez* From apalala at gmail.com Sun Nov 26 01:35:00 2017 From: apalala at gmail.com (nospam.=?UTF-8?Q?Juancarlo_A=C3=B1ez?=) Date: Sun, 26 Nov 2017 18:35:00 +1200 Subject: TatSu v4.2.5 released Message-ID: <1660907850@f38.n261.z1.binkp.net> ??? TatSu (the successor to Grako) is a tool that takes grammars in a variation of EBNF as input, and outputs memoizing (Packrat) PEG parsers in Python. ??? TatSu can compile a grammar stored in a string into a tatsu.grammars.Grammar object that can be used to parse any given input, much like the re module does with regular expressions, or it can generate a Python module that implements the parser. ??? TatSu fully supports left-recursive rules in PEG grammars using the algorithm by Laurent and Mens. The generated AST has the expected left associativity. https://github.com/neogeny/TatSu http://tatsu.readthedocs.io/en/stable/ v4.2.5 -------- * #42 Rename vim files from grako.vim to tatsu.vim (@fcoelho ) * #51 Fix inconsistent code generation for whitespace (@fpom ) * #54 Only care about case of first letter of rule name for determining advance over whitespace (@acw1251 ) v4.2.4 --------- * #40 Make the start rule default to the first rule defined in the grammar (@hariedo) * #43 Import re from tatsu.util to support optional regex-only features (@azazel75) * #47 Fix incorrect sample code in documentation v4.2.3 -------- * #37 Regression: The #include pragma works by using the EBNFBuffer from grammars.py. Somehow the default EBNFBootstrapBuffer from bootstrap.py has been used instead (@gegenschall). * #38 Documentation: Use of json.dumps() requires ast.asjson() (@davidchen). -- Juancarlo *A??ez* From nicoddemus at gmail.com Mon Nov 27 16:36:16 2017 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 27 Nov 2017 21:36:16 +0000 Subject: pytest 3.3.0 Message-ID: The pytest team is proud to announce the 3.3.0 release! pytest is a mature Python testing tool with more than a 1600 tests against itself, passing on many different interpreters and platforms. This release contains a number of bugs fixes and improvements, so users are encouraged to take a look at the CHANGELOG: http://doc.pytest.org/en/latest/changelog.html For complete documentation, please visit: http://docs.pytest.org As usual, you can upgrade from pypi via: pip install -U pytest Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira * Ceridwen * Daniel Hahler * Dirk Thomas * Dmitry Malinovsky * Florian Bruhin * George Y. Kussumoto * Hugo * Jes?s Espino * Joan Massich * Ofir * OfirOshir * Ronny Pfannschmidt * Samuel Dion-Girardeau * Srinivas Reddy Thatiparthy * Sviatoslav Abakumov * Tarcisio Fischer * Thomas Hisch * Tyler Goodlet * hugovk * je * prokaktus Happy testing, The Pytest Development Team From rt.van.der.ham at gmail.com Tue Nov 28 12:13:13 2017 From: rt.van.der.ham at gmail.com (Ruud van der Ham) Date: Tue, 28 Nov 2017 18:13:13 +0100 Subject: Salabim 2.2.7 released Message-ID: This is to announce salabim version 2.2.7 . Salabim is a discrete event event simulation (DES) package with a very powerful animation engine. With this release, queues and 'states' can be animated with just a couple of lines of code. See several examples for a demonstration of these new features, This release also contains some minor improvements and bug fixes. Please refer to the changelog at GitHub, accessible via www.salabim.org. Upgrading to the latest version can be done with *pip install -U salabim* . Happy simulating! From bryanv at anaconda.com Tue Nov 28 13:19:13 2017 From: bryanv at anaconda.com (Bryan Van de ven) Date: Tue, 28 Nov 2017 12:19:13 -0600 Subject: ANN: Bokeh 0.12.11 Released Message-ID: On behalf of the Bokeh team, I am pleased to announce the release of version 0.12.11 of Bokeh! For more information and details, please see the announcement post at: https://bokeh.github.io/blog/2017/11/28/release-0-12-11/ If you are using Anaconda/miniconda, you can install it with conda: conda install -c bokeh bokeh Alternatively, you can also install it with pip: pip install bokeh Full information including details about how to use and obtain BokehJS are at: https://bokeh.pydata.org/en/0.12.11/docs/installation.html Issues, enhancement requests, and pull requests can be made on the Bokeh Github page: https://github.com/bokeh/bokeh Documentation is available at: https://bokeh.pydata.org/en/0.12.11 There are over 268 total contributors to Bokeh and their time and effort help make Bokeh such an amazing project and community. Thank you again for your contributions. Finally, for questions or technical assistance we recommend starting with detailed posts on Stack Overflow. Or if you are interested in contributing, come by the Bokeh dev chat room: https://gitter.im/bokeh/bokeh-dev Thanks, Bryan Van de Ven From fabiofz at gmail.com Wed Nov 29 19:41:48 2017 From: fabiofz at gmail.com (Fabio Zadrozny) Date: Wed, 29 Nov 2017 22:41:48 -0200 Subject: PyDev 6.2.0 released Message-ID: PyDev 6.2.0 Release Highlights - *Interactive Console* - It's possible to use word-wrapping in the PyDev interactive console ( *#PyDev-862*). - *Code Completion* - Checking list unpacking with user specified types. - Code completion aware of variable typing from Python 3.6 ( *#PyDev-866*). - *Others* - Properly terminating child processes of launched python processes on Linux with Java 9 (*#PyDev-871*). - Comments with 3 dashes properly appear in outline in all cases ( *#PyDev-868*). - Properly hyperlinking pytest output. - Accepting *noqa* as a way to skip errors (*#PyDev-814*). - If there's a *flake8: noqa* in the first 3 lines of the file, don't analyze it (*#PyDev-814*). - Fixed issue where a closing peer character was skiped when it was actually not a matching closing peer (*#PyDev-869*). - Fixed issue where line indentation was not correct on a new line with multiple open parenthesis. What is PyDev? PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. Details on PyDev: http://pydev.org Details on its development: http://pydev.blogspot.com What is LiClipse? LiClipse is a PyDev standalone with goodies such as support for Multiple cursors, theming, TextMate bundles and a number of other languages such as Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript, etc. It's also a commercial counterpart which helps supporting the development of PyDev. Details on LiClipse: http://www.liclipse.com/ Cheers, -- Fabio Zadrozny ------------------------------ Software Developer LiClipse http://www.liclipse.com PyDev - Python Development Environment for Eclipse http://pydev.org http://pydev.blogspot.com PyVmMonitor - Python Profiler http://www.pyvmmonitor.com/? From paul.l.kehrer at gmail.com Wed Nov 29 21:27:33 2017 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 29 Nov 2017 21:27:33 -0500 Subject: PyCA cryptography 2.1.4 released Message-ID: PyCA cryptography 2.1.4 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, message digests, and key derivation functions. We support Python 2.7, Python 3.4+, and PyPy. Changelog: * Added X509_up_ref for an upcoming pyOpenSSL release. -Paul Kehrer (reaperhulk) From fabiofz at gmail.com Wed Nov 29 05:41:48 2017 From: fabiofz at gmail.com (Fabio Zadrozny) Date: Wed, 29 Nov 2017 22:41:48 +1200 Subject: PyDev 6.2.0 released Message-ID: <2791910052@f38.n261.z1.binkp.net> PyDev 6.2.0 Release Highlights - *Interactive Console* - It's possible to use word-wrapping in the PyDev interactive console ( *#PyDev-862*). - *Code Completion* - Checking list unpacking with user specified types. - Code completion aware of variable typing from Python 3.6 ( *#PyDev-866*). - *Others* - Properly terminating child processes of launched python processes on Linux with Java 9 (*#PyDev-871*). - Comments with 3 dashes properly appear in outline in all cases ( *#PyDev-868*). - Properly hyperlinking pytest output. - Accepting *noqa* as a way to skip errors (*#PyDev-814*). - If there's a *flake8: noqa* in the first 3 lines of the file, don't analyze it (*#PyDev-814*). - Fixed issue where a closing peer character was skiped when it was actually not a matching closing peer (*#PyDev-869*). - Fixed issue where line indentation was not correct on a new line with multiple open parenthesis. What is PyDev? PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. Details on PyDev: http://pydev.org Details on its development: http://pydev.blogspot.com What is LiClipse? LiClipse is a PyDev standalone with goodies such as support for Multiple cursors, theming, TextMate bundles and a number of other languages such as Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript, etc. It's also a commercial counterpart which helps supporting the development of PyDev. Details on LiClipse: http://www.liclipse.com/ Cheers, -- Fabio Zadrozny ------------------------------ Software Developer LiClipse http://www.liclipse.com PyDev - Python Development Environment for Eclipse http://pydev.org http://pydev.blogspot.com PyVmMonitor - Python Profiler http://www.pyvmmonitor.com/? ? From paul.l.kehrer at gmail.com Wed Nov 29 04:27:32 2017 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 29 Nov 2017 21:27:32 +1200 Subject: PyCA cryptography 2.1.4 released Message-ID: <964285594@f38.n261.z1.binkp.net> PyCA cryptography 2.1.4 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, message digests, and key derivation functions. We support Python 2.7, Python 3.4+, and PyPy. Changelog: * Added X509_up_ref for an upcoming pyOpenSSL release. -Paul Kehrer (reaperhulk)