Trying to install pyttsx you get "Successfully installed pyttsx" despite the syntax errors and you can't actually do an import.

c:\Users\Mark\CrossCode>c:\Python34\Scripts\pip3.4.exe install pyttsx
Downloading/unpacking pyttsx
  Downloading pyttsx-1.1.tar.gz
  Running setup.py (path:C:\Users\Mark\AppData\Local\Temp\pip_build_Mark\pyttsx\setup.py) egg_info for package pyttsx

Installing collected packages: pyttsx
  Running setup.py install for pyttsx
      File "C:\Python34\Lib\site-packages\pyttsx\driver.py", line 105
        except Exception, e:
                        ^
    SyntaxError: invalid syntax

[other syntax errors snipped]

Successfully installed pyttsx
Cleaning up...

c:\Users\Mark\CrossCode>py -3.4
Python 3.4.0rc2 (v3.4.0rc2:a300712ed38c, Feb 23 2014, 10:49:04) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyttsx
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\site-packages\pyttsx\__init__.py", line 18, in <module>
    from engine import Engine

Running 2to3 sorts this out.  Can this be done automatically by pip?  If not, can we please have this documented?

I think I've observed other occasions when PIP claimed a successful install but the install had actually failed.  PIP is still an independent project, so this should be reported on the PIP tracker at https://github.com/pypa/pip/issues.

As for running 2to3 automatically, that is an issue with the pyttsx package, and should be reported to their tracker, wherever that is.

Just awesome, from my viewpoint PEP 453 and #19347 were a complete and utter waste of time.

Why?  Before the PEP and its implementation, you would have had to first install pip before you could have had the problems you reported.  So, at least one annoying step was eliminated.  Now we'll work on the other bugs and issues with python packaging.  

The pip folks are responsive when it comes to bug fixes.  More responsive than the stdlib can be.  When they fix it, you'll be able to use the existing pip to upgrade to the fixed version, instead of having to wait until the next version of Python is released to get the fix.

This should have been tested before it got into a release candidate, not left to users to find such a blatantly obvious bug.  I'll leave the PEP authors to sort this out, I've no intention of spending my time clearing up their mess.

It's not a bug and has nothing to do with pip per se. The PyPI entry of this package makes no claims that it is supported on Python 3 nor does its README.  PEP 453 does not make any claims to add new capabilities to pip to automatically try to transform packages written for Python 2.  If you installed pip with Python 3.3 and tried to install this package, you'd get exactly the same result.  If you downloaded the package source and manually installed it with "python3 setup.py" (e.g. no pip), you'd still get the same result.

Well, the fact that a syntax error can result in a "successful install" message is a bug *somewhere*, and like I said I've seen this before with pip (on linux, so this issue has nothing to do with windows).

I guess it's a distutils bug, and falls into that category I mentioned of packaging bugs "we" will work on in the future...

From PEP 453 "Abstract - This PEP proposes that the Installing Python Modules guide in Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of pip as the default installer for Python packages, and that appropriate technical changes be made in Python 3.4 to provide pip by default in support of that recommendation."  If this is the *RECOMMENDED* default installer what are the bad ones like?  Note the bit "appropriate technical changes be made in Python 3.4".  As this is an officially endorsed product quite specifically targetted at Python 3.4, slap bang in the middle of a release candidate I don't expect to see core devs waffling on about what we'll do the future, I expect to see fixes now or have this product officially withdrawn from 3.4.

Can you assume good faith from the people involved and stay civil in the discussion?

This is existing behavior.  The error messages are coming from Distutils doing a byte compile (producing .pyc) on .py files it is installing.  AFAIK, that has always been treated as a warning in all versions of Distutils; changing that behavior now could break the installation of existing packages (yes, I have seen packages, usually tests, that produce these messages).  As is the case with much of Distutils, its exact behavior with regard to byte-compiling has never been documented.   

Note that while pyttsx uses setuptools in its setup.py, even if you edit it to call distutils directly, you still get the same behavior (neither pip nor setuptools nor python3.4 is involved):

curl -O https://pypi.python.org/packages/source/p/pyttsx/pyttsx-1.1.tar.gz
tar -xfz ./pyttsx-1.1.tar.gz
cd ./pyttsx-1.1
python3.3 setup.py install -v
[...]
copying build/lib/pyttsx/voice.py -> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyttsx
byte-compiling /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyttsx/__init__.py to __init__.cpython-33.pyc
byte-compiling /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyttsx/driver.py to driver.cpython-33.pyc
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyttsx/driver.py", line 105
    except Exception, e:
                    ^
SyntaxError: invalid syntax
byte-compiling /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyttsx/voice.py to voice.cpython-33.pyc
running install_egg_info
Removing /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyttsx-1.1-py3.3.egg-info
Writing /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyttsx-1.1-py3.3.egg-info
$ echo $?
0

David, Mark: I agree that there is no bug in Python or pip here. The installation *does* complete successfully, and the engine module is installed. It just fails to work because of a syntax error (which would be a bug in pyttsx had it claimed to support Python 3). It's not the task of the installation process to verify that the code being installed actually works.

IMO, there is an independent bug in the import machinery, where importing pyttsx fails because of the syntax error in pyttsx.engine - yet the error displayed is not the SyntaxError, but an ImportError claiming that the module does not exist (when it actually exists, but fails to import).

Ah, I see.  I'm still not convinced from a usability standpoint that calling it a successful install when byte compilation failed is good, but I understand your point.  And yeah, the ImportError problem getting resolved would make it a lot clearer what was actually going on.

Alas, I don't think there is a bug in the import machinery, either.  Note that puttsx's __init__.py uses a pre-PEP 328 ambiguous relative import:

from engine import ...

Even if there were no syntax errors, in Python 3 that would have to be spelled:

from .engine import ...

and making that change, engine is now found, syntax errors and all:

>>> import pyttsx
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pyttsx/__init__.py", line 18, in <module>
    from .engine import Engine
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pyttsx/engine.py", line 64
    except Exception, e:
                    ^
SyntaxError: invalid syntax

Oh, right.  I forgot to look back at the original report.  It does show that pyttsx was installed, since the error is coming from its __init__.

All, and especially Ned, thank you for the detailed explanations, I do appreciate it.