ANN: ETS 4.0 released

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

ANN: ETS 4.0 released

Ilan Schnell
Hello,

I am happy to announce the release of ETS 4.0.  This is the
first major release of the Enthought Tool Suite in almost
three years.  This release removes the 'enthought' namespace
from all projects.  For example:

    from enthought.traits.api import HasTraits

is now simply::

    from traits.api import HasTraits

For backwards compatibility, a proxy package 'etsproxy' has
been added, which should permit existing code to work.  For
convenience this package also contains a refactor tool 'ets3to4'
to convert projects to the new namespace (so that they don't
rely on the 'etsproxy' package).

If you want to download the source code of all ETS projects, you
can download http://www.enthought.com/repo/ets/ALLETS-4.0.0.tar (41MB).
The projects themselves are now hosted on: https://github.com/enthought

We understand that the namespace refactor (which prompted this
major release in the first place) is a big change, and even
though we have tested examples and some of our own code against
this ETS version, we expect there to be little glitches.  We are
therefore already planning a 4.0.1 bug-fix release in about 2-3
weeks.

We are looking forward to your feedback (the development mailing list
is [hidden email]), and hope you enjoy ETS 4.

- Ilan
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Brad Buran
Apologies if this qualifies as a "corner case", but ets3to4 doesn't capture
the following change:

enthought.enable.savage.traits changed to enable.savage.trait_defs

Brad

On Tue, Jun 21, 2011 at 9:15 PM, Ilan Schnell <[hidden email]>wrote:

> For backwards compatibility, a proxy package 'etsproxy' has
> been added, which should permit existing code to work.  For
> convenience this package also contains a refactor tool 'ets3to4'
> to convert projects to the new namespace (so that they don't
> rely on the 'etsproxy' package).
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Ilan Schnell
Hello Brad,

thanks for reporting this problem.  You're right, the tool is missing this
case (and probably a new others involving "traits" -> "trat_defs".  The
change was necessary to avoid ambiguities regarding "import traits"
inside directories which contain "traits" sub packages.  In the past, this
was OK because one would never "import traits" directly.

- Ilan


On Fri, Jun 24, 2011 at 10:20 AM, Brad Buran <[hidden email]> wrote:

> Apologies if this qualifies as a "corner case", but ets3to4 doesn't capture
> the following change:
>
> enthought.enable.savage.traits changed to enable.savage.trait_defs
>
> Brad
>
> On Tue, Jun 21, 2011 at 9:15 PM, Ilan Schnell <[hidden email]>wrote:
>
>> For backwards compatibility, a proxy package 'etsproxy' has
>> been added, which should permit existing code to work.  For
>> convenience this package also contains a refactor tool 'ets3to4'
>> to convert projects to the new namespace (so that they don't
>> rely on the 'etsproxy' package).
>>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Ilan Schnell
Just fixed:
https://github.com/enthought/etsproxy/commit/c590b70dc9bb9a687814ddf4f0c1e53ca054b785

Brad, apart from this problem, did you run into any others?
Does your application work with the new ETS 4.0?
We haven't received a lot of feedback about ETS 4.0 yet.

- Ilan


On Fri, Jun 24, 2011 at 10:28 AM, Ilan Schnell <[hidden email]> wrote:

> Hello Brad,
>
> thanks for reporting this problem.  You're right, the tool is missing this
> case (and probably a new others involving "traits" -> "trat_defs".  The
> change was necessary to avoid ambiguities regarding "import traits"
> inside directories which contain "traits" sub packages.  In the past, this
> was OK because one would never "import traits" directly.
>
> - Ilan
>
>
> On Fri, Jun 24, 2011 at 10:20 AM, Brad Buran <[hidden email]> wrote:
>> Apologies if this qualifies as a "corner case", but ets3to4 doesn't capture
>> the following change:
>>
>> enthought.enable.savage.traits changed to enable.savage.trait_defs
>>
>> Brad
>>
>> On Tue, Jun 21, 2011 at 9:15 PM, Ilan Schnell <[hidden email]>wrote:
>>
>>> For backwards compatibility, a proxy package 'etsproxy' has
>>> been added, which should permit existing code to work.  For
>>> convenience this package also contains a refactor tool 'ets3to4'
>>> to convert projects to the new namespace (so that they don't
>>> rely on the 'etsproxy' package).
>>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Brad Buran
I had "traits" and "chaco" sub packages defined in some of my code and was
using "import traits" and "import chaco".  I had to change them to
"trait_defs" and "chaco_exts" to get the code working properly.  Other than
that, everything seems to be working smoothly.

The only packages I use (and tested) are chaco, enable, traits and traitsui.


Other than the enable.savage.trait_defs issue, ets3to4 worked perfectly.

Brad


On Fri, Jun 24, 2011 at 11:47 AM, Ilan Schnell <[hidden email]>wrote:

> Just fixed:
>
> https://github.com/enthought/etsproxy/commit/c590b70dc9bb9a687814ddf4f0c1e53ca054b785
>
> Brad, apart from this problem, did you run into any others?
> Does your application work with the new ETS 4.0?
> We haven't received a lot of feedback about ETS 4.0 yet.
>
> - Ilan
>
>
> On Fri, Jun 24, 2011 at 10:28 AM, Ilan Schnell <[hidden email]>
> wrote:
> > Hello Brad,
> >
> > thanks for reporting this problem.  You're right, the tool is missing
> this
> > case (and probably a new others involving "traits" -> "trat_defs".  The
> > change was necessary to avoid ambiguities regarding "import traits"
> > inside directories which contain "traits" sub packages.  In the past,
> this
> > was OK because one would never "import traits" directly.
> >
> > - Ilan
> >
> >
> > On Fri, Jun 24, 2011 at 10:20 AM, Brad Buran <[hidden email]> wrote:
> >> Apologies if this qualifies as a "corner case", but ets3to4 doesn't
> capture
> >> the following change:
> >>
> >> enthought.enable.savage.traits changed to enable.savage.trait_defs
> >>
> >> Brad
> >>
> >> On Tue, Jun 21, 2011 at 9:15 PM, Ilan Schnell <[hidden email]
> >wrote:
> >>
> >>> For backwards compatibility, a proxy package 'etsproxy' has
> >>> been added, which should permit existing code to work.  For
> >>> convenience this package also contains a refactor tool 'ets3to4'
> >>> to convert projects to the new namespace (so that they don't
> >>> rely on the 'etsproxy' package).
> >>>
> >> _______________________________________________
> >> Enthought-Dev mailing list
> >> [hidden email]
> >> https://mail.enthought.com/mailman/listinfo/enthought-dev
> >>
> >
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Ilan Schnell
Thank you for the feedback, Brad.  The namespace
refactor is a big deal, and we ran into problems we didn't
except, so I'm glad to head that the transition went so
smoothly for you.

- Ilan


On Fri, Jun 24, 2011 at 2:15 PM, Brad Buran <[hidden email]> wrote:

> I had "traits" and "chaco" sub packages defined in some of my code and was
> using "import traits" and "import chaco".  I had to change them to
> "trait_defs" and "chaco_exts" to get the code working properly.  Other than
> that, everything seems to be working smoothly.
>
> The only packages I use (and tested) are chaco, enable, traits and traitsui.
>
>
> Other than the enable.savage.trait_defs issue, ets3to4 worked perfectly.
>
> Brad
>
>
> On Fri, Jun 24, 2011 at 11:47 AM, Ilan Schnell <[hidden email]>wrote:
>
>> Just fixed:
>>
>> https://github.com/enthought/etsproxy/commit/c590b70dc9bb9a687814ddf4f0c1e53ca054b785
>>
>> Brad, apart from this problem, did you run into any others?
>> Does your application work with the new ETS 4.0?
>> We haven't received a lot of feedback about ETS 4.0 yet.
>>
>> - Ilan
>>
>>
>> On Fri, Jun 24, 2011 at 10:28 AM, Ilan Schnell <[hidden email]>
>> wrote:
>> > Hello Brad,
>> >
>> > thanks for reporting this problem.  You're right, the tool is missing
>> this
>> > case (and probably a new others involving "traits" -> "trat_defs".  The
>> > change was necessary to avoid ambiguities regarding "import traits"
>> > inside directories which contain "traits" sub packages.  In the past,
>> this
>> > was OK because one would never "import traits" directly.
>> >
>> > - Ilan
>> >
>> >
>> > On Fri, Jun 24, 2011 at 10:20 AM, Brad Buran <[hidden email]> wrote:
>> >> Apologies if this qualifies as a "corner case", but ets3to4 doesn't
>> capture
>> >> the following change:
>> >>
>> >> enthought.enable.savage.traits changed to enable.savage.trait_defs
>> >>
>> >> Brad
>> >>
>> >> On Tue, Jun 21, 2011 at 9:15 PM, Ilan Schnell <[hidden email]
>> >wrote:
>> >>
>> >>> For backwards compatibility, a proxy package 'etsproxy' has
>> >>> been added, which should permit existing code to work.  For
>> >>> convenience this package also contains a refactor tool 'ets3to4'
>> >>> to convert projects to the new namespace (so that they don't
>> >>> rely on the 'etsproxy' package).
>> >>>
>> >> _______________________________________________
>> >> Enthought-Dev mailing list
>> >> [hidden email]
>> >> https://mail.enthought.com/mailman/listinfo/enthought-dev
>> >>
>> >
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Robert Kern
In reply to this post by Ilan Schnell
On Fri, Jun 24, 2011 at 2:15 PM, Brad Buran <[hidden email]> wrote:
> I had "traits" and "chaco" sub packages defined in some of my code and was
> using "import traits" and "import chaco".  I had to change them to
> "trait_defs" and "chaco_exts" to get the code working properly.  Other
than
> that, everything seems to be working smoothly.
>
> The only packages I use (and tested) are chaco, enable, traits and
traitsui.

With Python 2.6+, you can use explicit relative imports (without any
__future__ nonsense):

from . import traits

--
Robert Kern
Enthought
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Problem with TreeNode icons

Christophe Grimault
Hello,

I struugle to obtain the right behavior with TreeNode icons. I supposed
that using :

TreeNode( node_for  = [ RadioNetwork ],
                  auto_open = True,
                  children  = 'rx_nodes',
                  label     = '=Rx nodes',
                  view      = no_view,
                  add       = [ RxNode ],
                  menu      = Menu(),
                  icon_path=search_path,
                  icon_item='record.gif',
                  icon_open='open_record.gif',
                  icon_group='record.gif',
                  ),

The icon displayed would change, depending on wether the node is
detailed or closed. But it's always 'open_record.gif' that is displayed,
as soon as there is one sub-node to the node. What am i doing wrong ?

Thanks in advance

Chris


--
Christophe Grimault
NovaGrid SAS
Les jardins de la Teillais
3, allée de la grande égalonne
35740 Pacé
France

tel : (33)2 23 41 37 97
web : www.novagrid.com

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Richard Lincoln
In reply to this post by Ilan Schnell
On 22/06/11 02:15, Ilan Schnell wrote:

> Hello,
>
> I am happy to announce the release of ETS 4.0.  This is the
> first major release of the Enthought Tool Suite in almost
> three years.  This release removes the 'enthought' namespace
> from all projects.  For example:
>
>      from enthought.traits.api import HasTraits
>
> is now simply::
>
>      from traits.api import HasTraits


Now that there is no longer the root 'enthought' namespace package is
there still a reason for not using the __init__.py files in the way the
api.py files are currently used. My understanding is that this was
originally something to do with setuptools handling of namespace
packages. To be able to do:

     from traits import HasTraits

might be nice.

Regards,

Richard
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Ilan Schnell
We thought about that, but the reason for keeping the api modules
is that otherwise every traits import would import the whole thing, i.e.
you might only want to import traits.xzy, without importing everything
else.  This is also the reason the api modules were added in the first
place.  They were not added because of setuptools namespace problems,
at least not in the first place.

- Ilan


On Tue, Jun 28, 2011 at 4:06 PM, Richard Lincoln <[hidden email]> wrote:

> On 22/06/11 02:15, Ilan Schnell wrote:
>> Hello,
>>
>> I am happy to announce the release of ETS 4.0.  This is the
>> first major release of the Enthought Tool Suite in almost
>> three years.  This release removes the 'enthought' namespace
>> from all projects.  For example:
>>
>>      from enthought.traits.api import HasTraits
>>
>> is now simply::
>>
>>      from traits.api import HasTraits
>
>
> Now that there is no longer the root 'enthought' namespace package is
> there still a reason for not using the __init__.py files in the way the
> api.py files are currently used. My understanding is that this was
> originally something to do with setuptools handling of namespace
> packages. To be able to do:
>
>     from traits import HasTraits
>
> might be nice.
>
> Regards,
>
> Richard
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

bryce hendrix-2
As the person who did all the grunt work adding the api.py files, the
original reason was primarily to reduce the chance of a circular import. The
secondary reason was to improve startup times somewhat.

Bryce

On Tue, Jun 28, 2011 at 4:13 PM, Ilan Schnell <[hidden email]>wrote:

> We thought about that, but the reason for keeping the api modules
> is that otherwise every traits import would import the whole thing, i.e.
> you might only want to import traits.xzy, without importing everything
> else.  This is also the reason the api modules were added in the first
> place.  They were not added because of setuptools namespace problems,
> at least not in the first place.
>
> - Ilan
>
>
> On Tue, Jun 28, 2011 at 4:06 PM, Richard Lincoln <[hidden email]>
> wrote:
> > On 22/06/11 02:15, Ilan Schnell wrote:
> >> Hello,
> >>
> >> I am happy to announce the release of ETS 4.0.  This is the
> >> first major release of the Enthought Tool Suite in almost
> >> three years.  This release removes the 'enthought' namespace
> >> from all projects.  For example:
> >>
> >>      from enthought.traits.api import HasTraits
> >>
> >> is now simply::
> >>
> >>      from traits.api import HasTraits
> >
> >
> > Now that there is no longer the root 'enthought' namespace package is
> > there still a reason for not using the __init__.py files in the way the
> > api.py files are currently used. My understanding is that this was
> > originally something to do with setuptools handling of namespace
> > packages. To be able to do:
> >
> >     from traits import HasTraits
> >
> > might be nice.
> >
> > Regards,
> >
> > Richard
> > _______________________________________________
> > Enthought-Dev mailing list
> > [hidden email]
> > https://mail.enthought.com/mailman/listinfo/enthought-dev
> >
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Richard Lincoln
In reply to this post by Ilan Schnell
Presumably the same could be said for numpy or scipy. That one might
wish to just do:

     from numpy import array

without importing everything else. What's good for a goose is good for
the gander.

Richard

On 28/06/11 22:13, Ilan Schnell wrote:

> We thought about that, but the reason for keeping the api modules
> is that otherwise every traits import would import the whole thing, i.e.
> you might only want to import traits.xzy, without importing everything
> else.  This is also the reason the api modules were added in the first
> place.  They were not added because of setuptools namespace problems,
> at least not in the first place.
>
> - Ilan
>
>
> On Tue, Jun 28, 2011 at 4:06 PM, Richard Lincoln<[hidden email]>  wrote:
>> On 22/06/11 02:15, Ilan Schnell wrote:
>>> Hello,
>>>
>>> I am happy to announce the release of ETS 4.0.  This is the
>>> first major release of the Enthought Tool Suite in almost
>>> three years.  This release removes the 'enthought' namespace
>>> from all projects.  For example:
>>>
>>>       from enthought.traits.api import HasTraits
>>>
>>> is now simply::
>>>
>>>       from traits.api import HasTraits
>>
>>
>> Now that there is no longer the root 'enthought' namespace package is
>> there still a reason for not using the __init__.py files in the way the
>> api.py files are currently used. My understanding is that this was
>> originally something to do with setuptools handling of namespace
>> packages. To be able to do:
>>
>>      from traits import HasTraits
>>
>> might be nice.
>>
>> Regards,
>>
>> Richard
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ETS 4.0 released

Eric Jones
The issue is that, the __init__.py file is run whenever traits is imported.  Any file that it imports will also be imported.  Even if you want a single symbol from traits in your namespace, the entire __init__.py file executes.  For example in this code:

        from traits import HasTraits

if the traits/__init__.py imports 40 modules, then all 40 modules have to be imported before you get HasTraits into your namespace.  That costs startup time that you may want to avoid in some situations.  The api.py approach allows a convenience for those willing to pay the cost while still allowing those who want to tune for start-up time to do that.

By the way, start-up time is a big big deal in many situations.  Reasonably sized Python apps are notoriously bad for this normally.  Minimizing imports (which have to stat files on disk and then read them) is one of the things that can help with this -- especially in places where the file system is remote (NFS mounts, etc.).

eric



On Jun 29, 2011, at 6:37 AM, Richard Lincoln wrote:

> Presumably the same could be said for numpy or scipy. That one might
> wish to just do:
>
>     from numpy import array
>
> without importing everything else. What's good for a goose is good for
> the gander.
>
> Richard
>
> On 28/06/11 22:13, Ilan Schnell wrote:
>> We thought about that, but the reason for keeping the api modules
>> is that otherwise every traits import would import the whole thing, i.e.
>> you might only want to import traits.xzy, without importing everything
>> else.  This is also the reason the api modules were added in the first
>> place.  They were not added because of setuptools namespace problems,
>> at least not in the first place.
>>
>> - Ilan
>>
>>
>> On Tue, Jun 28, 2011 at 4:06 PM, Richard Lincoln<[hidden email]>  wrote:
>>> On 22/06/11 02:15, Ilan Schnell wrote:
>>>> Hello,
>>>>
>>>> I am happy to announce the release of ETS 4.0.  This is the
>>>> first major release of the Enthought Tool Suite in almost
>>>> three years.  This release removes the 'enthought' namespace
>>>> from all projects.  For example:
>>>>
>>>>      from enthought.traits.api import HasTraits
>>>>
>>>> is now simply::
>>>>
>>>>      from traits.api import HasTraits
>>>
>>>
>>> Now that there is no longer the root 'enthought' namespace package is
>>> there still a reason for not using the __init__.py files in the way the
>>> api.py files are currently used. My understanding is that this was
>>> originally something to do with setuptools handling of namespace
>>> packages. To be able to do:
>>>
>>>     from traits import HasTraits
>>>
>>> might be nice.
>>>
>>> Regards,
>>>
>>> Richard
>>> _______________________________________________
>>> Enthought-Dev mailing list
>>> [hidden email]
>>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev