pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On Feb 1, 2008, at 9:32 AM, Alexander Limi wrote: You probably see where I'm going with this, but: I'd like to ship 3.1 with a set of .po files that do not contain the strings from Plone 2.5. Hanno said it would take him a couple of hours to weed out the stuff that is 2.5-specific, and agrees that it would be a good thing to do. sounds like something to do on the plane... :) It will make Plone easier to translate, and increase our participation and success rate with the upcoming translation push. Comments? +1 from me as well. 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. the plone code base, however, is still loaded with unused imports and other stuff producing warnings and error when checked with these, which once again became very obvious while doing reviews for plone 3.1. hmm, to avoid misunderstandings i should inject that the new code i've reviewed was perfectly fine in this regard and it was pretty evident from the changesets that george for example uses either of those (or a similar tool) as well. so this is more about the existing code base, and i was repeatedly wondering when would be the best time to start cleaning up these issues. i reckon doing it for minor releases would sort of require a PLIP, and bugfix releases are probably out of the question, too, but deferring it to the next major release would imply waiting another long while. and besides, this would also mean that all affected packages[3] would need branches for their stable line of bugfix releases, which would result in a lot of additional maintenance efforts. so, what would be a sensible way to approach this? cheers, andi [1] http://www.logilab.org/project/name/pylint [2] http://divmod.org/trac/wiki/DivmodPyflakes [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... :) /opt/zope/sprint/pristine-3.0- find products/ src/ -mindepth 1 -maxdepth 1 -type d -not -name .svn | xargs pyflakes | cut -d/ -f-2 | uniq -c 334 products/ATContentTypes 42 products/ATReferenceBrowserWidget 23 products/AdvancedQuery 283 products/Archetypes 5 products/CMFActionIcons 110 products/CMFCalendar 79 products/CMFCore 860 products/CMFDefault 38 products/CMFDiffTool 6 products/CMFDynamicViewFTI 75 products/CMFEditions 12 products/CMFFormController 49 products/CMFPlacefulWorkflow 770 products/CMFPlone 8 products/CMFQuickInstallerTool 93 products/CMFTestCase 62 products/CMFTopic 9 products/CMFUid 25 products/DCWorkflow 43 products/ExtendedPathIndex 47 products/ExternalEditor 53 products/GenericSetup 290 products/GroupUserFolder 107 products/Marshall 31 products/MimetypesRegistry 47 products/NuPlone 3 products/PasswordResetTool 15 products/PlacelessTranslationService 10 products/PloneLanguageTool 32 products/PlonePAS 95 products/PloneTestCase 43 products/PloneTranslations 82 products/PluggableAuthService 15 products/PluginRegistry 76 products/PortalTransforms 24 products/ResourceRegistries 45 products/SecureMailHost 21 products/ZopeVersionControl 43 products/i18ntestcase 151 products/kupu 42 products/validation 3 src/archetypes.kss 4 src/five.customerize 6 src/five.localsitemanager 90 src/kss.core 9 src/plone.app.content 14 src/plone.app.contentmenu 53 src/plone.app.contentrules 8 src/plone.app.controlpanel 2 src/plone.app.customerize 11 src/plone.app.form 4 src/plone.app.i18n 16 src/plone.app.iterate 6 src/plone.app.kss 10 src/plone.app.layout 2 src/plone.app.linkintegrity 2 src/plone.app.openid 67 src/plone.app.portlets 5 src/plone.app.redirector 5 src/plone.app.viewletmanager 6 src/plone.app.vocabularies 12 src/plone.app.workflow 8 src/plone.contentrules 3 src/plone.fieldsets 21 src/plone.i18n 3 src/plone.intelligenttext 7 src/plone.locking 19 src/plone.memoize 7 src/plone.openid 12 src/plone.portlets 3 src/plone.session 4 src/plone.theme 29 src/txtfilter 138 src/wicked -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp -
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 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 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 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
