Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On Feb 1, 2008, at 7:00 PM, Martijn Pieters wrote: On 1. feb.. 2008, at 12.28, Martin Aspeli wrote: Careful with weeding imports. I recently had to fix a migration issue for a customer, where a persistent tool had been moved into another module with an import at the old location. Someone else then ran pyflakes and removed said import, breaking the migration. That's what zope.deferredimport is for. :) Perhaps. But moved persistent classes also need to be migrated, really. of course they would, _if_ we wanted to take the "cleaning up" of import to that level. however, that wasn't my original intend at all. like i said, i'd consider it perfectly fine to have convenience imports in say `interfaces/__init__.py` and i think they should be left alone[*], unless the imported symbols actually belong to some other package, of course. i'll do some analysis when i find the time (or become too curious about it :)), but i'd suspect that this type of warnings will be the minority anyway. my suggestion, however, was to clean up unused imports and other stuff in regular, i.e. code modules, and imho these shouldn't contains convenience imports used by other modules anyway, right? andi [*] if we really want to get rid of pyflakes warnings regarding those, too, you can always insert some no-op code like: from moduleX import ClassA, ClassB # convenience imports enumerated again to make pyflakes happy... :) ClassA, ClassB that's what we (tomster and i) did in some bigger project a lot, and i worked quite nicely. it's probably not exactly the cleanest way to solve this, but imho the benefits of normally having zero pyflakes warnings (and therefore being able to quickly spot other problems) outweighed the "hackyness" of these workarounds, especially as they were only "allowed" in interface modules anyway... -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On 1. feb.. 2008, at 12.28, Martin Aspeli wrote: Careful with weeding imports. I recently had to fix a migration issue for a customer, where a persistent tool had been moved into another module with an import at the old location. Someone else then ran pyflakes and removed said import, breaking the migration. That's what zope.deferredimport is for. :) Perhaps. But moved persistent classes also need to be migrated, really. Any such class can be replaced by instantiating the new class and doing a __getstate__() on the old and a __setstate__ on the new class (acquisition unwrapped of course). Martijn ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On Feb 1, 2008, at 2:24 PM, Wichert Akkerman wrote: Previously Tom Lazar wrote: given the aforementioned possibility of 3rd party breakage i think it's plain that 'pyflakes sanity' is a no-go for 3.1 but perhaps for 4.0? since that will necessitate 3rd party rewrites/adaptions anyway, might as well throw in pyflakes sanity, as well. You may need to properly deprecate things before removing them. hmm, unused imports? that might be a bit too much, no? i mean, i'd go ahead and remove any import statements i'm not using anymore in my packages, and that should be okay. imho, the only trouble are interface packages, otherwise people shouldn't import package a from package b anyway, but import it from a directly. so, how about this? deprecating imports in interface packages, which are not used in plone core, is okay as well as removing unused import from any other package? that's talking 4.0, of course... hmm, or maybe this could be a 3.2 PLIP, too, so we can deprecate things earlier. i mean, this policy shouldn't break anything provided all tests are passing. thoughts? andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
Previously Tom Lazar wrote: > On 01.02.2008, at 12:07, Andreas Zeidler wrote: > > >On Feb 1, 2008, at 12:04 PM, Martijn Pieters wrote: > >>On Feb 1, 2008 11:51 AM, Andreas Zeidler <[EMAIL PROTECTED]> wrote: > >>>talking about "weeding out stuff" bring another thing to mind. not > >>>exactly related to translations, but i'll throw it in here anyway: > >>>tools like pylint[1] and pyflakes[2] have really grown on me ever > >>>since i started using them. imho they not only help with keeping > >>>code > >>>clean, but also with quickly catching typos and errors, effectively > >>>saving you a lot of time. > >> > >>Careful with weeding imports. I recently had to fix a migration issue > >>for a customer, where a persistent tool had been moved into another > >>module with an import at the old location. Someone else then ran > >>pyflakes and removed said import, breaking the migration. > > > >yes, i'm very much aware of these problems having used pyflakes > >myself for quite some time now. that's one of the reasons i'm > >bringing this up here (instead of starting to "weed" away on > >trunk :)). > > given the aforementioned possibility of 3rd party breakage i think > it's plain that 'pyflakes sanity' is a no-go for 3.1 but perhaps for > 4.0? since that will necessitate 3rd party rewrites/adaptions anyway, > might as well throw in pyflakes sanity, as well. You may need to properly deprecate things before removing them. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On Feb 1, 2008, at 1:02 PM, Tom Lazar wrote: On 01.02.2008, at 12:07, Andreas Zeidler wrote: yes, i'm very much aware of these problems having used pyflakes myself for quite some time now. that's one of the reasons i'm bringing this up here (instead of starting to "weed" away on trunk :)). given the aforementioned possibility of 3rd party breakage i think it's plain that 'pyflakes sanity' is a no-go for 3.1 but perhaps for 4.0? well, there's no PLIP for 3.1 regarding this anyway... ;) but as i said, even for 4.0 it's likely to cause extra maintenance work. i'll look into `zope.deferredimport` though, as martin suggested... ah, well, one can dream... ;-) :) andi p.s. i made statusmessages 'pyflakes-sane' when you introduced pyflakes to me at the labelfinder and right after hanno visited us there and helped me fix a bug in it ;-) ah, that was you!? cool. i thought it must have been hanno — just looked so much like him... :) -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On 01.02.2008, at 12:07, Andreas Zeidler wrote: On Feb 1, 2008, at 12:04 PM, Martijn Pieters wrote: On Feb 1, 2008 11:51 AM, Andreas Zeidler <[EMAIL PROTECTED]> wrote: talking about "weeding out stuff" bring another thing to mind. not exactly related to translations, but i'll throw it in here anyway: tools like pylint[1] and pyflakes[2] have really grown on me ever since i started using them. imho they not only help with keeping code clean, but also with quickly catching typos and errors, effectively saving you a lot of time. Careful with weeding imports. I recently had to fix a migration issue for a customer, where a persistent tool had been moved into another module with an import at the old location. Someone else then ran pyflakes and removed said import, breaking the migration. yes, i'm very much aware of these problems having used pyflakes myself for quite some time now. that's one of the reasons i'm bringing this up here (instead of starting to "weed" away on trunk :)). given the aforementioned possibility of 3rd party breakage i think it's plain that 'pyflakes sanity' is a no-go for 3.1 but perhaps for 4.0? since that will necessitate 3rd party rewrites/adaptions anyway, might as well throw in pyflakes sanity, as well. i envision a pyflakes wrapper that weeds out some of the stuff that pyflakes ist just not smart enough about (i.e. the warnings it generates for "undefined name '__path__'" etc.) and that a error and warning free run of that wrapper would be mandatory just as zero failures are mandatory already. ah, well, one can dream... ;-) cheers, tom p.s. i made statusmessages 'pyflakes-sane' when you introduced pyflakes to me at the labelfinder and right after hanno visited us there and helped me fix a bug in it ;-) andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On Feb 1, 2008, at 12:04 PM, Martijn Pieters wrote: On Feb 1, 2008 11:51 AM, Andreas Zeidler <[EMAIL PROTECTED]> wrote: talking about "weeding out stuff" bring another thing to mind. not exactly related to translations, but i'll throw it in here anyway: tools like pylint[1] and pyflakes[2] have really grown on me ever since i started using them. imho they not only help with keeping code clean, but also with quickly catching typos and errors, effectively saving you a lot of time. Careful with weeding imports. I recently had to fix a migration issue for a customer, where a persistent tool had been moved into another module with an import at the old location. Someone else then ran pyflakes and removed said import, breaking the migration. yes, i'm very much aware of these problems having used pyflakes myself for quite some time now. that's one of the reasons i'm bringing this up here (instead of starting to "weed" away on trunk :)). andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On Feb 1, 2008, at 11:51 AM, Andreas Zeidler wrote: [3] which basically means all packages except `statusmessages` (guess who owns that ;)) as you can see from the attached list counting the warnings; i should note that this list still contains warnings about namespace package `__init__.py`s and convenience imports in interfaces/ etc, so it's exaggerating things a little... :) heh, now that i was curious it turns out not counting the warnings from the namespace package `__init__.py`, i.e. stuff like: $ pyflakes plone.app.xyz plone.app.xyz/plone/__init__.py:6: undefined name '__path__' plone.app.xyz/plone/app/__init__.py:6: undefined name '__path__' makes it four "clean" packages: products/statusmessages src/plone.app.customerize src/plone.app.linkintegrity src/plone.app.openid sort of indicating to me that i'm probably part of a very small minority here... :) andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On Feb 1, 2008 11:51 AM, Andreas Zeidler <[EMAIL PROTECTED]> wrote: > talking about "weeding out stuff" bring another thing to mind. not > exactly related to translations, but i'll throw it in here anyway: > tools like pylint[1] and pyflakes[2] have really grown on me ever > since i started using them. imho they not only help with keeping code > clean, but also with quickly catching typos and errors, effectively > saving you a lot of time. Careful with weeding imports. I recently had to fix a migration issue for a customer, where a persistent tool had been moved into another module with an import at the old location. Someone else then ran pyflakes and removed said import, breaking the migration. -- Martijn Pieters ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
