sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Python 2.7.12 + tox + PostgreSQL

[Oleg B. <ph...@ph...>]

On Thu, Oct 27, 2016 at 09:10:49PM +0200, Neil Muller <drn...@gm...> wrote:
> On 23 September 2016 at 00:03, Oleg Broytman <ph...@ph...> wrote:
> > Hi, all!
> >
> > On Thu, Aug 25, 2016 at 11:18:45PM +0200, Oleg Broytman <ph...@ph...> wrote:
> >>    Recently tests started to fail both at Travis and Circle, but only
> >> with Postgres. Initially I couldn't reproduce the problem locally but
> >> after a dozen of experiments I got it: the problem manifests itself
> >> only with Python 2.7.12 + tox + PostgreSQL. I have to install Python
> >> 2.7.12 and tox to reproduce it locally (I have Debian with Python 2.7.9
> >> and I usually don't use tox - I run py.test directly).
> >>
> >>    Somehow I managed to fix tests by changing test order - I explicitly
> >> listed tests directories with 'tests' at the top of the other dirs.
> >
> >    After a few hundreds successful and failed test runs I narrowed the
> > problem a bit and reproduced it with any python version and without tox.
> > So the problem is clearly in SQLObject tests.
> >    The problem is manifested if tests from sqlobject/tests are run after
> > sqlobject/inheritance/tests:
> >
> > createdb test
> > py.test sqlobject/inheritance/tests tests/test_schema.py
> > dropdb test
> >
> 
> I spent some time today poking at this. While I haven't isolated the
> cause, I have some more information on what's happening.
> 
> When the test fails, the connection pool has two entries. Because of
> how getConnection & releaseConnection are implemented, the connection
> returned by getConnection will cycle between these two entries. In
> this case, the call to CREATE TABLE and the query end up happening in
> different connections, which have different values for search_path
> (since that's local to the underlying connection), which causes the
> failure.
> 
> I haven't worked out where the extra connection in the pool gets
> created or why this only happens some of the time.

   Food for thoughts. Thanks!

> -- 
> Neil Muller
> drn...@gm...

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 2.7.12 + tox + PostgreSQL

[Neil M. <drn...@gm...>]

On 23 September 2016 at 00:03, Oleg Broytman <ph...@ph...> wrote:
> Hi, all!
>
> On Thu, Aug 25, 2016 at 11:18:45PM +0200, Oleg Broytman <ph...@ph...> wrote:
>>    Recently tests started to fail both at Travis and Circle, but only
>> with Postgres. Initially I couldn't reproduce the problem locally but
>> after a dozen of experiments I got it: the problem manifests itself
>> only with Python 2.7.12 + tox + PostgreSQL. I have to install Python
>> 2.7.12 and tox to reproduce it locally (I have Debian with Python 2.7.9
>> and I usually don't use tox - I run py.test directly).
>>
>>    Somehow I managed to fix tests by changing test order - I explicitly
>> listed tests directories with 'tests' at the top of the other dirs.
>
>    After a few hundreds successful and failed test runs I narrowed the
> problem a bit and reproduced it with any python version and without tox.
> So the problem is clearly in SQLObject tests.
>    The problem is manifested if tests from sqlobject/tests are run after
> sqlobject/inheritance/tests:
>
> createdb test
> py.test sqlobject/inheritance/tests tests/test_schema.py
> dropdb test
>

I spent some time today poking at this. While I haven't isolated the
cause, I have some more information on what's happening.

When the test fails, the connection pool has two entries. Because of
how getConnection & releaseConnection are implemented, the connection
returned by getConnection will cycle between these two entries. In
this case, the call to CREATE TABLE and the query end up happening in
different connections, which have different values for search_path
(since that's local to the underlying connection), which causes the
failure.

I haven't worked out where the extra connection in the pool gets
created or why this only happens some of the time.

-- 
Neil Muller
drn...@gm...

I've got a gmail account. Why haven't I become cool?

[SQLObject] Development news

[Oleg B. <ph...@ph...>]

Testing news, to be precise. I fixed a number of warnings from py.test:

* I renamed classes TestXXX to SOTestXXX so that py.test doesn't
  recognize them as test classes;
* I converted yield tests that py.test declared obsolete to direct
  calls.

Now py.test doesn't produce any warnings.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 2.7.12 + tox + PostgreSQL

[Oleg B. <ph...@ph...>]

Hi, all!

On Thu, Aug 25, 2016 at 11:18:45PM +0200, Oleg Broytman <ph...@ph...> wrote:
>    Recently tests started to fail both at Travis and Circle, but only
> with Postgres. Initially I couldn't reproduce the problem locally but
> after a dozen of experiments I got it: the problem manifests itself
> only with Python 2.7.12 + tox + PostgreSQL. I have to install Python
> 2.7.12 and tox to reproduce it locally (I have Debian with Python 2.7.9
> and I usually don't use tox - I run py.test directly).
> 
>    Somehow I managed to fix tests by changing test order - I explicitly
> listed tests directories with 'tests' at the top of the other dirs.

   After a few hundreds successful and failed test runs I narrowed the
problem a bit and reproduced it with any python version and without tox.
So the problem is clearly in SQLObject tests.
   The problem is manifested if tests from sqlobject/tests are run after
sqlobject/inheritance/tests:

createdb test
py.test sqlobject/inheritance/tests tests/test_schema.py
dropdb test

   Output:

sqlobject/inheritance/tests/test_aggregates.py .
sqlobject/inheritance/tests/test_asdict.py ..
sqlobject/inheritance/tests/test_deep_inheritance.py ...
sqlobject/inheritance/tests/test_foreignKey.py ..
sqlobject/inheritance/tests/test_indexes.py .
sqlobject/inheritance/tests/test_inheritance.py ....
sqlobject/inheritance/tests/test_inheritance_tree.py .
sqlobject/tests/test_schema.py F

    def test_connection_schema():
        if not supports('schema'):
            py.test.skip("schemas aren't supported")
        conn = getConnection()
        conn.schema = None
        conn.query('CREATE SCHEMA test')
        conn.schema = 'test'
        conn.query('SET search_path TO test')
        setupClass(SOTestSchema)
        assert SOTestSchema._connection is conn
>       SOTestSchema(foo='bar')

    def _executeRetry(self, conn, cursor, query):
        if self.debug:
            self.printDebug(conn, query, 'QueryR')
        try:
            return cursor.execute(query)
        except self.module.OperationalError as e:
            raise dberrors.OperationalError(ErrorMessage(e))
        except self.module.IntegrityError as e:
            msg = ErrorMessage(e)
            if e.pgcode == '23505':
                raise dberrors.DuplicateEntryError(msg)
            else:
                raise dberrors.IntegrityError(msg)
        except self.module.InternalError as e:
            raise dberrors.InternalError(ErrorMessage(e))
        except self.module.ProgrammingError as e:
>           raise dberrors.ProgrammingError(ErrorMessage(e))
E           ProgrammingError: relation "so_test_schema" does not exist
E           LINE 1: INSERT INTO so_test_schema (foo) VALUES ('bar') RETURNING id
E                               ^


Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 3.5

[Oleg B. <ph...@ph...>]

Hi!

On Sun, Sep 11, 2016 at 04:16:48PM +0200, Lutz Steinborn <lu...@gm...> wrote:
> Well done.
> 
> Am 11.09.2016 2:38 vorm. schrieb "Oleg Broytman" <ph...@ph...>:
> 
> > Hi, all! Tests are now run at CIs with python3.5.

   Thanks!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 3.5

[Lutz S. <lu...@gm...>]

Well done.

Am 11.09.2016 2:38 vorm. schrieb "Oleg Broytman" <ph...@ph...>:

> Hi, all! Tests are now run at CIs with python3.5.
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

Re: [SQLObject] Python 3.5

[Simon C. <hod...@gm...>]

Awesome!

[SQLObject] Python 3.5

[Oleg B. <ph...@ph...>]

Hi, all! Tests are now run at CIs with python3.5.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Sphinx docs

[Oleg B. <ph...@ph...>]

Hello, All!

   I merged branch sphinx-docs into master. The devel docs are now
generated with Sphinx: http://sqlobject.org/devel/
   The transition will be finished with the next stable release (3.2.0).

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 2.7.12 + tox + PostgreSQL

[Oleg B. <ph...@ph...>]

On Fri, Aug 26, 2016 at 05:49:00PM +0200, Oleg Broytman <ph...@ph...> wrote:
> On Fri, Aug 26, 2016 at 10:42:04AM -0500, Ian Cordasco <gra...@gm...> wrote:
> > tox will install sqlobject first and then run the tests against that
> > installed version (ideally). If you just run py.test directly, it might not
> > be installed and will be running against the local copy in git. Something
> > could be wrong about how sqlobject is being packaged.
> 
>    Could be, but why only with Postgres then?

   And only with Python 2.7.12. With 2.7.9 everything is fine.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 2.7.12 + tox + PostgreSQL

[Oleg B. <ph...@ph...>]

Hi!

On Fri, Aug 26, 2016 at 10:42:04AM -0500, Ian Cordasco <gra...@gm...> wrote:
> On Aug 25, 2016 4:19 PM, "Oleg Broytman" <ph...@ph...> wrote:
> 
> > Hi, All!
> >
> >    Recently tests started to fail both at Travis and Circle, but only
> > with Postgres. Initially I couldn't reproduce the problem locally but
> > after a dozen of experiments I got it: the problem manifests itself
> > only with Python 2.7.12 + tox + PostgreSQL. I have to install Python
> > 2.7.12 and tox to reproduce it locally (I have Debian with Python 2.7.9
> > and I usually don't use tox - I run py.test directly).
> >
> >    Somehow I managed to fix tests by changing test order - I explicitly
> > listed tests directories with 'tests' at the top of the other dirs. Now
> > tests passed locally and at both CIs.
> >
> >    I understand neither the problem nor the solution. :-( Any idea?
> 
> Can you share a link to the reordering that fixed this? I won't pretend to
> understand it either, but there is typically a difference between how tox
> runs tests and how you might be running them.

https://github.com/sqlobject/sqlobject/commit/c0737d14122550cfe965d193d899c8ab0801999d

   Usually py.test lists tests directories in alphabetical order:
"include/tests inheritance/tests tests versioning/test". I put "tests"
at the front: "tests include/tests inheritance/tests versioning/test"
and that fixes the problem both locally and at CIs.

> tox will install sqlobject first and then run the tests against that
> installed version (ideally). If you just run py.test directly, it might not
> be installed and will be running against the local copy in git. Something
> could be wrong about how sqlobject is being packaged.

   Could be, but why only with Postgres then?

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 2.7.12 + tox + PostgreSQL

[Ian C. <gra...@gm...>]

On Aug 25, 2016 4:19 PM, "Oleg Broytman" <ph...@ph...> wrote:

> Hi, All!
>
>    Recently tests started to fail both at Travis and Circle, but only
> with Postgres. Initially I couldn't reproduce the problem locally but
> after a dozen of experiments I got it: the problem manifests itself
> only with Python 2.7.12 + tox + PostgreSQL. I have to install Python
> 2.7.12 and tox to reproduce it locally (I have Debian with Python 2.7.9
> and I usually don't use tox - I run py.test directly).
>
>    Somehow I managed to fix tests by changing test order - I explicitly
> listed tests directories with 'tests' at the top of the other dirs. Now
> tests passed locally and at both CIs.
>
>    I understand neither the problem nor the solution. :-( Any idea?
>

Can you share a link to the reordering that fixed this? I won't pretend to
understand it either, but there is typically a difference between how tox
runs tests and how you might be running them.

tox will install sqlobject first and then run the tests against that
installed version (ideally). If you just run py.test directly, it might not
be installed and will be running against the local copy in git. Something
could be wrong about how sqlobject is being packaged.

[SQLObject] Python 2.7.12 + tox + PostgreSQL

[Oleg B. <ph...@ph...>]

Hi, All!

   Recently tests started to fail both at Travis and Circle, but only
with Postgres. Initially I couldn't reproduce the problem locally but
after a dozen of experiments I got it: the problem manifests itself
only with Python 2.7.12 + tox + PostgreSQL. I have to install Python
2.7.12 and tox to reproduce it locally (I have Debian with Python 2.7.9
and I usually don't use tox - I run py.test directly).

   Somehow I managed to fix tests by changing test order - I explicitly
listed tests directories with 'tests' at the top of the other dirs. Now
tests passed locally and at both CIs.

   I understand neither the problem nor the solution. :-( Any idea?

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 3.1.0

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 3.1.0, the first stable release of branch
3.1 of SQLObject.


What's new in SQLObject
=======================

Features
--------

* Add UuidCol.

* Add JsonbCol. Only for PostgreSQL.
  Requires psycopg2 >= 2.5.4 and PostgreSQL >= 9.2.

* Add JSONCol, a universal json column.

* For Python >= 3.4 minimal FormEncode version is now 1.3.1.

* If mxDateTime is in use, convert timedelta (returned by MySQL) to
  mxDateTime.Time.

Documentation
-------------

* Developer's Guide extended to explain SQLObject architecture and how
  to create a new column type.

* Fix URLs that can be found; remove missing links.

* Rename reStructuredText files from *.txt to *.rst.

Source code
-----------

* Fix all `import *` using https://github.com/zestyping/star-destroyer.

Tests
-----

* Tests are now run at Circle CI.

* Use pytest-cov for test coverage. Report test coverage
  via coveralls.io and codecov.io.

* Install mxDateTime to run date/time tests with it.

Contributor for this release is Lutz Steinborn.

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.6, 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

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/3.1.0

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 3.1.0b3

[Oleg B. <ph...@ph...>]

Hi, all! SQLObject 3.1.0b3:

   https://pypi.python.org/pypi/SQLObject/3.1.0b3

   Changes since the second beta: a lot of minor documentation tweaks,
paving the way for switching doc generator from pudge to Sphinx (gonna
do the switch after 3.1); fixes in sdist. Some details:

-- Add Codecov badge to Developer's Guide.
-- Include circle.yml and .coveragerc into source distribution.
   Include forgotten sqlobject/include/tests.
-- Install mxDateTime via apt-get instead of pip during tests
   (egenix.com was down so pip had got problems installing mxDateTime).
-- Add missing Tables of Contents in docs. Add a link to TODO.html.
-- Mask errors in tests during documentation building: doc builders
   (both pudge and Sphinx) import modules looking for docstrings, and
   our tests don't like to be imported outside of test environments
   without configured database.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] SQLObject 3.1.0b2

[Oleg B. <ph...@ph...>]

Changes since the first beta:

> * For Python >= 3.4 minimal FormEncode version is now 1.3.1.
> 
> * If mxDateTime is in use, convert timedelta (returned by MySQL) to
>   mxDateTime.Time.
> 
> * Rename reStructuredText file from \*.txt to \*.rst.
> 
> * Test are now run at Circle CI.
> 
> * Use pytest-cov for test coverage. Report test coverage
>   via coveralls.io and codecov.io.
> 
> * Install mxDateTime to run date/time tests with it.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 3.1.0b2

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 3.1.0b2, the second beta of the upcoming
release of branch 3.1 of SQLObject.


What's new in SQLObject
=======================

Features
--------

* Add UuidCol.

* Add JsonbCol. Only for PostgreSQL.
  Requires psycopg2 >= 2.5.4 and PostgreSQL >= 9.2.

* Add JSONCol, a universal json column.

* For Python >= 3.4 minimal FormEncode version is now 1.3.1.

* If mxDateTime is in use, convert timedelta (returned by MySQL) to
  mxDateTime.Time.

Documentation
-------------

* Developer's Guide extended to explain SQLObject architecture and how
  to create a new column type.

* Fix URLs that can be found; remove missing links.

* Rename reStructuredText file from \*.txt to \*.rst.

Source code
-----------

* Fix all `import *` using https://github.com/zestyping/star-destroyer.

Tests
-----

* Test are now run at Circle CI.

* Use pytest-cov for test coverage. Report test coverage
  via coveralls.io and codecov.io.

* Install mxDateTime to run date/time tests with it.

Contributor for this release is Lutz Steinborn.

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.6, 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

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/3.1.0b2

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Take some reST

[Oleg B. <ph...@ph...>]

Hello, dear all! This is the time when one of my small dreams came true!
I always wanted to rename all reStructuredtext files to *.rst but always
was afraid to touch too mush, to create problems with merging and so on.
Today, when I only have one active branch covered with test and having
good doc builders, I finally decided to make that bold step. The front
page of the repositories and docs subdirectory now look much better:

https://github.com/sqlobject/sqlobject#readme

In other good news:

   -- I installed mxDateTime for tests, found and fixed a bug with MySQL;
   -- Omitted some rarely used not tested modules in .coveragerc;

Test coverage is now 86.8%!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] FormEncode 1.3.1

[Oleg B. <ph...@ph...>]

FormEncode developers has just released version 1.3.1 so it's the
minimal requirement now with python >= 3.4.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Circle CI

[Oleg B. <ph...@ph...>]

Tests are now run at Circle CI:
   https://circleci.com/gh/sqlobject/sqlobject

   Took a lot of failed experiments. The worst problem was to remove
that broken FormEncode wheel before reinstalling dependencies.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Test coverage

[Oleg B. <ph...@ph...>]

Hello, all! Test coverage in SQLObject code is 85.49%. Quite good, IMO!
See https://coveralls.io/github/sqlobject/sqlobject and
https://codecov.io/gh/sqlobject/sqlobject/commits

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 3.1.0b1

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 3.1.0b1, the first beta of the upcoming
release of branch 3.1 of SQLObject.


What's new in SQLObject
=======================

Features
--------

* Add UuidCol.

* Add JsonbCol. Only for PostgreSQL.
  Requires psycopg2 >= 2.5.4 and PostgreSQL >= 9.2.

* Add JSONCol, a universal json column.

Source code
-----------

* Fix all `import *` using https://github.com/zestyping/star-destroyer.

Documentation
-------------

* Developer's Guide extended to explain SQLObject architecture and how
  to create a new column type.

* Fix URLs that can be found; remove missing links.

Contributor for this release is Lutz Steinborn.

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.6, 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

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/3.1.0b1.dev20160731

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Development news

[Oleg B. <ph...@ph...>]

Hello! With the recent activity in master I'm going to release version
3.1. I declare older branches unsupported.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 3 and FormEncode

[Oleg B. <ph...@ph...>]

On Mon, Jul 25, 2016 at 07:55:48AM -0500, Ian Cordasco <gra...@gm...> wrote:
> On Mon, Jul 25, 2016 at 7:51 AM, Christoph Zwerschke <ci...@on...> wrote:
> > Am 25.07.2016 um 13:18 schrieb Oleg Broytman:
> >  >   File "<stdin>", line 1, in <module>
> >  > NameError: name 'unicode' is not defined
> >
> > Hi Oleg,
> >
> > FormEncode 1.3 should run with Python 3, it uses 2to3. This error
> > indicates that during installation the 2to3 tool did not run properly.
> > Some have reported that this problem can be caused by cached wheels.
> >
> > In FormEncode 2, 2to3 is not used any more because of such issues, but I
> > think there is no official release of FormEncode 2 yet.
> >
> > Anyway, if FormEncode 1.3 is installed properly, it should work.
> 
> So this is because FormEncode 1.3 claims it can provide a universal
> wheel (https://github.com/formencode/formencode/blob/1.3.0/setup.cfg#L29)
> but it cannot. A 1.3.1 release should be provided with universal = 0.
> This way when pip caches the wheel it produces, it tags it with py2 or
> py3 as appropriate.

   I see you reported the problem at
https://github.com/formencode/formencode/issues/117
   Thanks!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Python 3 and FormEncode

[Ian C. <gra...@gm...>]

On Mon, Jul 25, 2016 at 7:55 AM, Ian Cordasco
<gra...@gm...> wrote:
> On Mon, Jul 25, 2016 at 7:51 AM, Christoph Zwerschke <ci...@on...> wrote:
>> Am 25.07.2016 um 13:18 schrieb Oleg Broytman:
>>  >   File "<stdin>", line 1, in <module>
>>  > NameError: name 'unicode' is not defined
>>
>> Hi Oleg,
>>
>> FormEncode 1.3 should run with Python 3, it uses 2to3. This error
>> indicates that during installation the 2to3 tool did not run properly.
>> Some have reported that this problem can be caused by cached wheels.
>>
>> In FormEncode 2, 2to3 is not used any more because of such issues, but I
>> think there is no official release of FormEncode 2 yet.
>>
>> Anyway, if FormEncode 1.3 is installed properly, it should work.
>
> So this is because FormEncode 1.3 claims it can provide a universal
> wheel (https://github.com/formencode/formencode/blob/1.3.0/setup.cfg#L29)
> but it cannot. A 1.3.1 release should be provided with universal = 0.
> This way when pip caches the wheel it produces, it tags it with py2 or
> py3 as appropriate.

I submitted https://github.com/formencode/formencode/issues/117 to see
if we can alleviate this.