On Wed, Jul 25, 2012 at 5:48 PM, Maarten Sneep <maarten.sn...@xs4all.nl>wrote:
> On 24 jul. 2012, at 18:39, Anthony Scopatz wrote:
>
> > The next version of PyTables that will be released will be v3.0 and will
> be Python 3 compliant. I thought that this would be an excellent (if not
> the only) chance to bring the PyTables API into full PEP8 compliance [1].
> This would mean changing function and attribute names like:
> >
> > tb.openFile() -> tb.open_file()
> >
> > For the next couple of releases BOTH the new and old API would be
> available to facilitate this transition (ie tb.openFile() and
> tb.open_file() would both work). To ease migration, we would also
> provide a 2to3-like utility for you to use on your code base that would
> update the API for you automatically. At some fixed point in the future
> (v3.2?), the old API would go away, but you would have had ample time to
> run this script. The developers either feel positively or neutral to these
> changes.
> >
> > The question for you the user is then, would this be something that you
> would like to see? How valuable would you find this change? Is bundling
> this with the Python 3 change too much overhead?
>
> +1
>
> Although for the example you give here I would prefer to change to
> tb.open(). Namespaces exist for a reason, I think.
>
This is a good point, and I would be in favor of this rename if other
people were as well...
If you do a "from tables import *" and the tb.open() overwrites the builtin
open(), you can always regain the builtin by doing "del open". That said,
I agree with you that we shouldn't be 'import *'ing. It sets a bad example
;)
> And yes, that would mean that a significant part of the examples and
> documentation would need to be written with 'import tables as tb' instead
> of 'from tables import *'. I find the former much better for learning.
> Since most of the functionality is accessed through instance methods
> anyway, the namespace isn't too big anyway.
>
> This change will require careful thought, but I think it is worth it.
>
> About the timing. Since many of the packages I need aren't on py3, I
> haven't given much thought to py3. I have of course followed the
> recommended practices (use the print function, not the statement, ...) for
> py 2.7, but other than that I have yet to figure out 2to3. Since this
> change will require attention to older code anyway, we might as well fold
> this PEP8 change into the Python 3 one.
>
To be clear as well, the Python 2 version of PyTables would probably also
include both new & old APIs to facilitate the transition.
Be Well
Anthony
>
> Best,
>
> Maarten
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Pytables-users mailing list
> Pytables-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pytables-users
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Pytables-users mailing list
Pytables-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytables-users
