Yes, the interface is absolutely jammed pack with options that make little to no sense unless you read all the document from the website. However, for our purpose, all we have to worry about is the box labeled Extension (11) down at the bottom right. Change it from Same to Fixed and then type in the new extension you want. You’ll see that the list box will show you the new name of the file instantly before you even commit the changes. Click the Rename button and that’s it.

I mentioned this tool even though it’s overkill for our purpose because it’s a really great utility and one that some might be interested in learning if they want to rename thousands of photos with names likes DSC00x, IMG00x, etc.

Advanced Renamer

Another good program that also requires a bit of reading to figure out is Advanced Renamer. Thankfully, both sites have user guides and tutorials. Also, I’ll explain the process for changing the file extension here. Once you install it, go ahead and click the Add button to add their files or to add a folder, which will add all the files in that folder to the list.
Now in order to perform any actions on that list, you have to add methods in the left hand pane. You can add multiple methods to perform complex renaming of files and folders. We want to click Add Method and then choose New Name.
Now go ahead and type in the new extension you would like into the box at the top and then change the Apply to box at the bottom to Extension instead of Name.
In the list of files, you should see the updated New Filename field updated with the changes to the file name or extension. When you have gotten it right the way you like, go ahead and click on the Start Batch button.
Again, I’m giving the simplest example with these programs, but you can create far more complex renaming schemes if you like. If you really don’t care about all the extra functionality, then check out the last program that does nothing but change the file extension.

Bulk Extension Changer

If you want simple, Bulk Extension Changer is the program for you. All you have to do is three things: first, pick the folder where the files are located, then set the current and replacement extension and then just press the Go button.
The only option is if you want to include sub-directories or not. In the 2nd step, you can add multiple replacement rules in case your folder has files of many different types and you want to check several at once.
Hopefully, those are enough options for any need you might have for renaming file extensions. If you have any questions, feel free to post a comment. Enjoy!
The setup script is the centre of all activity in building, distributing, andinstalling modules using the Distutils. The main purpose of the setup script isto describe your module distribution to the Distutils, so that the variouscommands that operate on your modules do the right thing. As we saw in sectionA Simple Example above, the setup script consists mainly of a call tosetup(), and most information supplied to the Distutils by the moduledeveloper is supplied as keyword arguments to setup().
Here’s a slightly more involved example, which we’ll follow for the next coupleof sections: the Distutils’ own setup script. (Keep in mind that although theDistutils are included with Python 1.6 and later, they also have an independentexistence so that Python 1.5.2 users can use them to install other moduledistributions. The Distutils’ own setup script, shown here, is used to installthe package into Python 1.5.2.)
There are only two differences between this and the trivial one-filedistribution presented in section A Simple Example: more metadata, and thespecification of pure Python modules by package, rather than by module. This isimportant since the Distutils consist of a couple of dozen modules split into(so far) two packages; an explicit list of every module would be tedious togenerate and difficult to maintain. For more information on the additionalmeta-data, see section Additional meta-data.
Note that any pathnames (files or directories) supplied in the setup scriptshould be written using the Unix convention, i.e. slash-separated. TheDistutils will take care of converting this platform-neutral representation intowhatever is appropriate on your current platform before actually using thepathname. This makes your setup script portable across operating systems, whichof course is one of the major goals of the Distutils. In this spirit, allpathnames in this document are slash-separated.
Change File Extension For All Files Os X Command Line
This, of course, only applies to pathnames given to Distutils functions. Ifyou, for example, use standard Python functions such as glob.glob() oros.listdir() to specify files, you should be careful to write portablecode instead of hardcoding path separators:

2.1. Listing whole packages¶

The packages option tells the Distutils to process (build, distribute,install, etc.) all pure Python modules found in each package mentioned in thepackages list. In order to do this, of course, there has to be acorrespondence between package names and directories in the filesystem. Thedefault correspondence is the most obvious one, i.e. package distutils isfound in the directory distutils relative to the distribution root.Thus, when you say packages=['foo'] in your setup script, you arepromising that the Distutils will find a file foo/__init__.py (whichmight be spelled differently on your system, but you get the idea) relative tothe directory where your setup script lives. If you break this promise, theDistutils will issue a warning but still process the broken package anyway.
If you use a different convention to lay out your source directory, that’s noproblem: you just have to supply the package_dir option to tell theDistutils about your convention. For example, say you keep all Python sourceunder lib, so that modules in the “root package” (i.e., not in anypackage at all) are in lib, modules in the foo package are inlib/foo, and so forth. Then you would put
in your setup script. The keys to this dictionary are package names, and anempty package name stands for the root package. The values are directory namesrelative to your distribution root. In this case, when you say packages=['foo'], you are promising that the file lib/foo/__init__.py exists.
Another possible convention is to put the foo package right inlib, the foo.bar package in lib/bar, etc. This would bewritten in the setup script as
A package:dir entry in the package_dir dictionary implicitlyapplies to all packages below package, so the foo.bar case isautomatically handled here. In this example, having packages=['foo','foo.bar'] tells the Distutils to look for lib/__init__.py andlib/bar/__init__.py. (Keep in mind that although package_dirapplies recursively, you must explicitly list all packages inpackages: the Distutils will not recursively scan your source treelooking for any directory with an __init__.py file.)

2.2. Listing individual modules¶

For a small module distribution, you might prefer to list all modules ratherthan listing packages—especially the case of a single module that goes in the“root package” (i.e., no package at all). This simplest case was shown insection A Simple Example; here is a slightly more involved example:
This describes two modules, one of them in the “root” package, the other in thepkg package. Again, the default package/directory layout implies thatthese two modules can be found in mod1.py and pkg/mod2.py, andthat pkg/__init__.py exists as well. And again, you can override thepackage/directory correspondence using the package_dir option.

2.3. Describing extension modules¶

Just as writing Python extension modules is a bit more complicated than writingpure Python modules, describing them to the Distutils is a bit more complicated.Unlike pure modules, it’s not enough just to list modules or packages and expectthe Distutils to go out and find the right files; you have to specify theextension name, source file(s), and any compile/link requirements (includedirectories, libraries to link with, etc.).
All of this is done through another keyword argument to setup(), theext_modules option. ext_modules is just a list ofExtension instances, each of which describes asingle extension module.Suppose your distribution includes a single extension, called foo andimplemented by foo.c. If no additional instructions to thecompiler/linker are needed, describing this extension is quite simple:
The Extension class can be imported from distutils.core alongwith setup(). Thus, the setup script for a module distribution thatcontains only this one extension and nothing else might be:
The Extension class (actually, the underlying extension-buildingmachinery implemented by the build_ext command) supports a great dealof flexibility in describing Python extensions, which is explained in thefollowing sections.

2.3.1. Extension names and packages¶

The first argument to the Extension constructor isalways the name of the extension, including any package names. For example,
describes an extension that lives in the root package, while
describes the same extension in the pkg package. The source files andresulting object code are identical in both cases; the only difference is wherein the filesystem (and therefore where in Python’s namespace hierarchy) theresulting extension lives.
If you have a number of extensions all in the same package (or all under thesame base package), use the ext_package keyword argument tosetup(). For example,
will compile foo.c to the extension pkg.foo, and bar.c topkg.subpkg.bar.

2.3.2. Extension source files¶

The second argument to the Extension constructor isa list of sourcefiles. Since the Distutils currently only support C, C++, and Objective-Cextensions, these are normally C/C++/Objective-C source files. (Be sure to useappropriate extensions to distinguish C++ source files: .cc and.cpp seem to be recognized by both Unix and Windows compilers.)
However, you can also include SWIG interface (.i) files in the list; thebuild_ext command knows how to deal with SWIG extensions: it will runSWIG on the interface file and compile the resulting C/C++ file into yourextension.
This warning notwithstanding, options to SWIG can be currently passed likethis:
Or on the commandline like this:
On some platforms, you can include non-source files that are processed by thecompiler and included in your extension. Currently, this just means Windowsmessage text (.mc) files and resource definition (.rc) files forVisual C++. These will be compiled to binary resource (.res) files andlinked into the executable.

2.3.3. Preprocessor options¶

Three optional arguments to Extension will help ifyou need to specify include directories to search or preprocessor macros todefine/undefine: include_dirs, define_macros, and undef_macros.
For example, if your extension requires header files in the includedirectory under your distribution root, use the include_dirs option:
You can specify absolute directories there; if you know that your extension willonly be built on Unix systems with X11R6 installed to /usr, you can getaway with
You should avoid this sort of non-portable usage if you plan to distribute yourcode: it’s probably better to write C code like
If you need to include header files from some other Python extension, you cantake advantage of the fact that header files are installed in a consistent wayby the Distutils install_headers command. For example, the NumericalPython header files are installed (on a standard Unix installation) to/usr/local/include/python1.5/Numerical. (The exact location will differaccording to your platform and Python installation.) Since the Python includedirectory--/usr/local/include/python1.5 in this case—is alwaysincluded in the search path when building Python extensions, the best approachis to write C code like
If you must put the Numerical include directory right into your headersearch path, though, you can find that directory using the Distutilsdistutils.sysconfig module:
Even though this is quite portable—it will work on any Python installation,regardless of platform—it’s probably easier to just write your C code in thesensible way.
You can define and undefine pre-processor macros with the define_macros andundef_macros options. define_macros takes a list of (name,value)tuples, where name is the name of the macro to define (a string) andvalue is its value: either a string or None. (Defining a macro FOOto None is the equivalent of a bare #defineFOO in your C source: withmost compilers, this sets FOO to the string 1.) undef_macros isjust a list of macros to undefine.
For example:
is the equivalent of having this at the top of every C source file:

2.3.4. Library options¶

You can also specify the libraries to link against when building your extension,and the directories to search for those libraries. The libraries option isa list of libraries to link against, library_dirs is a list of directoriesto search for libraries at link-time, and runtime_library_dirs is a list ofdirectories to search for shared (dynamically loaded) libraries at run-time.
For example, if you need to link against libraries known to be in the standardlibrary search path on target systems
If you need to link with libraries in a non-standard location, you’ll have toinclude the location in library_dirs:
(Again, this sort of non-portable construct should be avoided if you intend todistribute your code.)

2.3.5. Other options¶

There are still some other options which can be used to handle special cases.
The extra_objects option is a list of object files to be passed to thelinker. These files must not have extensions, as the default extension for thecompiler is used.
extra_compile_args and extra_link_args can be used tospecify additional command line options for the respective compiler and linkercommand lines.
export_symbols is only useful on Windows. It can contain a list ofsymbols (functions or variables) to be exported. This option is not needed whenbuilding compiled extensions: Distutils will automatically add initmoduleto the list of exported symbols.
The depends option is a list of files that the extension depends on(for example header files). The build command will call the compiler on thesources to rebuild extension if any on this files has been modified since theprevious build.

2.4. Relationships between Distributions and Packages¶

A distribution may relate to packages in three specific ways:
  1. It can require packages or modules.
  2. It can provide packages or modules.
  3. It can obsolete packages or modules.
These relationships can be specified using keyword arguments to thedistutils.core.setup() function.
Dependencies on other Python modules and packages can be specified by supplyingthe requires keyword argument to setup(). The value must be a list ofstrings. Each string specifies a package that is required, and optionally whatversions are sufficient.
To specify that any version of a module or package is required, the stringshould consist entirely of the module or package name. Examples include'mymodule' and 'xml.parsers.expat'.
If specific versions are required, a sequence of qualifiers can be supplied inparentheses. Each qualifier may consist of a comparison operator and a versionnumber. The accepted comparison operators are:
These can be combined by using multiple qualifiers separated by commas (andoptional whitespace). In this case, all of the qualifiers must be matched; alogical AND is used to combine the evaluations.
Let’s look at a bunch of examples:
Requires Expression
Explanation
1.0
Only version 1.0 is compatible
>1.0,!=1.5.1,<2.0
Any version after 1.0 and before 2.0is compatible, except 1.5.1
Now that we can specify dependencies, we also need to be able to specify what weprovide that other distributions can require. This is done using the provideskeyword argument to setup(). The value for this keyword is a list ofstrings, each of which names a Python module or package, and optionallyidentifies the version. If the version is not specified, it is assumed to matchthat of the distribution.
Some examples:
Provides Expression
Explanation
mypkg
Provide mypkg, using the distributionversion
mypkg(1.1)
Provide mypkg version 1.1, regardless ofthe distribution version
A package can declare that it obsoletes other packages using the obsoleteskeyword argument. The value for this is similar to that of the requireskeyword: a list of strings giving module or package specifiers. Each specifierconsists of a module or package name optionally followed by one or more versionqualifiers. Version qualifiers are given in parentheses after the module orpackage name.
The versions identified by the qualifiers are those that are obsoleted by thedistribution being described. If no qualifiers are given, all versions of thenamed module or package are understood to be obsoleted.

2.5. Installing Scripts¶

So far we have been dealing with pure and non-pure Python modules, which areusually not run by themselves but imported by scripts.
Scripts are files containing Python source code, intended to be started from thecommand line. Scripts don’t require Distutils to do anything very complicated.The only clever feature is that if the first line of the script starts with#! and contains the word “python”, the Distutils will adjust the first lineto refer to the current interpreter location. By default, it is replaced withthe current interpreter location. The --executable (or -e)option will allow the interpreter path to be explicitly overridden.
The scripts option simply is a list of files to be handled in thisway. Camino browser for mac os x 10.6 8. From the PyXML setup script:
Changed in version 2.7: All the scripts will also be added to the MANIFESTfile if no template is provided. See Specifying the files to distribute.

2.6. Installing Package Data¶

Often, additional files need to be installed into a package. These files areoften data that’s closely related to the package’s implementation, or text filescontaining documentation that might be of interest to programmers using thepackage. These files are called package data.

Change File Extension For All Files Os X Command Line Tools

Package data can be added to packages using the package_data keywordargument to the setup() function. The value must be a mapping frompackage name to a list of relative path names that should be copied into thepackage. The paths are interpreted as relative to the directory containing thepackage (information from the package_dir mapping is used if appropriate);that is, the files are expected to be part of the package in the sourcedirectories. They may contain glob patterns as well.
The path names may contain directory portions; any necessary directories will becreated in the installation.
For example, if a package should contain a subdirectory with several data files,the files can be arranged like this in the source tree:
The corresponding call to setup() might be:
New in version 2.4.
Changed in version 2.7: All the files that match package_data will be added to the MANIFESTfile if no template is provided. See Specifying the files to distribute.

2.7. Installing Additional Files¶

The data_files option can be used to specify additional files neededby the module distribution: configuration files, message catalogs, data files,anything which doesn’t fit in the previous categories.
data_files specifies a sequence of (directory, files) pairs in thefollowing way:
Line
Each (directory, files) pair in the sequence specifies the installationdirectory and the files to install there.
Each file name in files is interpreted relative to the setup.pyscript at the top of the package source distribution. Note that you canspecify the directory where the data files will be installed, but you cannotrename the data files themselves.
The directory should be a relative path. It is interpreted relative to theinstallation prefix (Python’s sys.prefix for system installations;site.USER_BASE for user installations). Distutils allows directory to bean absolute installation path, but this is discouraged since it isincompatible with the wheel packaging format. No directory information fromfiles is used to determine the final location of the installed file; onlythe name of the file is used.
You can specify the data_files options as a simple sequence of fileswithout specifying a target directory, but this is not recommended, and theinstall command will print a warning in this case. To install datafiles directly in the target directory, an empty string should be given as thedirectory.
Changed in version 2.7: All the files that match data_files will be added to the MANIFESTfile if no template is provided. See Specifying the files to distribute.

2.8. Additional meta-data¶

The setup script may include additional meta-data beyond the name and version.This information includes:

Change File Extension For All Files Os X Command Lines

Meta-Data
Description
Value
Notes
name
name of the package
short string
(1)
version
version of this release
short string
(1)(2)
author
package author’s name
short string
(3)
author_email
email address of thepackage author
email address
(3)
maintainer
package maintainer’s name
short string
(3)
maintainer_email
email address of thepackage maintainer
email address
(3)
url
home page for the package
URL
(1)
description
short, summarydescription of thepackage
short string
long_description
longer description of thepackage
long string
(5)
download_url
location where thepackage may be downloaded
URL
(4)
classifiers
a list of classifiers
list of strings
(4)
platforms
a list of platforms
list of strings
license
license for the package
short string
(6)
Notes:
  1. These fields are required.
  2. It is recommended that versions take the form major.minor[.patch[.sub]].
  3. Either the author or the maintainer must be identified. If maintainer isprovided, distutils lists it as the author in PKG-INFO.
  4. These fields should not be used if your package is to be compatible with Pythonversions prior to 2.2.3 or 2.3. The list is available from the PyPI website.
  5. The long_description field is used by PyPI when you publish a package,to build its project page.
  6. The license field is a text indicating the license covering thepackage where the license is not a selection from the “License” Troveclassifiers. See the Classifier field. Notice thatthere’s a licence distribution option which is deprecated but stillacts as an alias for license.
‘short string’
A single line of text, not more than 200 characters.
‘long string’

Change File Extension For All Files Os X Command Line Basics

Multiple lines of plain text in reStructuredText format (seehttp://docutils.sourceforge.net/).
‘list of strings’
See below.

Change File Extension For All Files Os X Command Line Download

None of the string values may be Unicode.
Encoding the version information is an art in itself. Python packages generallyadhere to the version format major.minor[.patch][sub]. The major number is 0for initial, experimental releases of software. It is incremented for releasesthat represent major milestones in a package. The minor number is incrementedwhen important new features are added to the package. The patch numberincrements when bug-fix releases are made. Additional trailing versioninformation is sometimes used to indicate sub-releases. These are“a1,a2,…,aN” (for alpha releases, where functionality and API may change),“b1,b2,…,bN” (for beta releases, which only fix bugs) and “pr1,pr2,…,prN”(for final pre-release release testing). Some examples:
0.1.0

Change File Extension For All Files Os X Command Line 5

the first, experimental release of a package
1.0.1a2
the second alpha release of the first patch version of 1.0

Change File Extension For All Files Os X Command Line Cheat Sheet

classifiers are specified in a Python list:
If you wish to include classifiers in your setup.py file and also wishto remain backwards-compatible with Python releases prior to 2.2.3, then you caninclude the following code fragment in your setup.py before thesetup() call.

2.9. Debugging the setup script¶

Sometimes things go wrong, and the setup script doesn’t do what the developerwants.
Distutils catches any exceptions when running the setup script, and print asimple error message before the script is terminated. The motivation for thisbehaviour is to not confuse administrators who don’t know much about Python andare trying to install a package. If they get a big long traceback from deepinside the guts of Distutils, they may think the package or the Pythoninstallation is broken because they don’t read all the way down to the bottomand see that it’s a permission problem.
On the other hand, this doesn’t help the developer to find the cause of thefailure. For this purpose, the DISTUTILS_DEBUG environment variable can be setto anything except an empty string, and distutils will now print detailedinformation about what it is doing, dump the full traceback when an exceptionoccurs, and print the whole command line when an external program (like a Ccompiler) fails.