release 0.6 of RedBaron, high level parser/modifier of python source file
Hello,
One year later I've finally made a new release for RedBaron. For those of you that don't know RedBaron, it's a library that allows you to modify you python *source* file with a high level API pretty much like BeautifulSoup with a lot of helper to make this way-harder-than-expected task doable.
Life being life, I don't have the same time that I used to have to work on this project, therefor this release mark my decision to now focus on brigging a 1.0 without adding any new big feature but instead focusing on stability, bugfixing and fully support the python 3 grammar (if they stop adding new things all the time). This release also mark the decision of being backward compatible from now one until 2.0.
I know that this mailing list is full of "without any free time" people and that this project is quite complicated but I wouldn't be against new contributors :)
I'm adding the release notes at the end of this email.
Have a nice day,
0.6 (2016-03-28)
This release is guaranteed to have a retro-compatible public documented API from now on until maybe 2.0. There might be the only exception that if you directly call specific nodes constructors with FST that this API change, but this is not documented and simply horribly unpracticable, so I'm expecting no one to do that.
From now on the focus will be on moving to a stable 1.0 meaning: bugs fixes and API additions for missing needed features and no more big modifications, this will be for other releases, the workload is already big enough.
- BIG improvement on the proxy list merging algorithm, it is not perfect yet (comments aren't handled yet) but it's really a big move forward
- possible retrocompatibility breaking change: from now on the node.find("name") to node.name shortcut ONLY works with possible nodes identifiers. For example node.i_dont_exist_as_an_identifier will raise AttributeError
- new helper method .to_python that wrap ast.literal_eval on compatibile nodes https://redbaron.readthedocs.org/en/latest/other.html#to-python
- breaking: IntNode no longer return an int on .value but a .string instead, use .to_python to have an evaluated version
- fix node.decrease_indentation (that was simply not working)
- fix code_block_node.value was broken on node with no parent
- add string representation for Path object
- now redbaron Path() class can be compared directly to baron paths without using to_baron_path() helper.
- fix by novocaine: 'function' was used as a function type detector instead of 'def'
- add getitem() method with same api on NodeList and ProxyList
- fix: inconsistencies when inserting lines around code blocks
- inserting a blank lines inserts effectively a \n in a LineProxyList
- new helper methods: .next_recursive and .previous_recursive https://redbaron.readthedocs.org/en/latest/other.html
- fix: doc is tested in CI now, it shouldn't break anymore
- more rendering test for python3, it shouldn't break anymore
- pygments is now an optional dependancy, "pip install redbaron" won't install it, "pip install redbaron[pygments"] will
- new node.next_intuitive and node.previous_intuitive methods for situations where .next/previous doesn't behave the way the user expect it http://redbaron.readthedocs.org/en/latest/other.html#next-intuitive-previous...
On Mon, Mar 28, 2016 at 10:30 AM, Laurent Peuch cortex@worlddomination.be wrote:
Hello,
One year later I've finally made a new release for RedBaron. For those of you that don't know RedBaron, it's a library that allows you to modify you python *source* file with a high level API pretty much like BeautifulSoup with a lot of helper to make this way-harder-than-expected task doable.
Life being life, I don't have the same time that I used to have to work on this project, therefor this release mark my decision to now focus on brigging a 1.0 without adding any new big feature but instead focusing on stability, bugfixing and fully support the python 3 grammar (if they stop adding new things all the time). This release also mark the decision of being backward compatible from now one until 2.0.
I know that this mailing list is full of "without any free time" people and that this project is quite complicated but I wouldn't be against new contributors :)
I'm adding the release notes at the end of this email.
Have a nice day,
0.6 (2016-03-28)
This release is guaranteed to have a retro-compatible public documented API from now on until maybe 2.0. There might be the only exception that if you directly call specific nodes constructors with FST that this API change, but this is not documented and simply horribly unpracticable, so I'm expecting no one to do that.
From now on the focus will be on moving to a stable 1.0 meaning: bugs fixes and API additions for missing needed features and no more big modifications, this will be for other releases, the workload is already big enough.
- BIG improvement on the proxy list merging algorithm, it is not perfect yet (comments aren't handled yet) but it's really a big move forward
- possible retrocompatibility breaking change: from now on the node.find("name") to node.name shortcut ONLY works with possible nodes identifiers. For example node.i_dont_exist_as_an_identifier will raise AttributeError
- new helper method .to_python that wrap ast.literal_eval on compatibile nodes https://redbaron.readthedocs.org/en/latest/other.html#to-python
- breaking: IntNode no longer return an int on .value but a .string instead, use .to_python to have an evaluated version
- fix node.decrease_indentation (that was simply not working)
- fix code_block_node.value was broken on node with no parent
- add string representation for Path object
- now redbaron Path() class can be compared directly to baron paths without using to_baron_path() helper.
- fix by novocaine: 'function' was used as a function type detector instead of 'def'
- add getitem() method with same api on NodeList and ProxyList
- fix: inconsistencies when inserting lines around code blocks
- inserting a blank lines inserts effectively a \n in a LineProxyList
- new helper methods: .next_recursive and .previous_recursive https://redbaron.readthedocs.org/en/latest/other.html
- fix: doc is tested in CI now, it shouldn't break anymore
- more rendering test for python3, it shouldn't break anymore
- pygments is now an optional dependancy, "pip install redbaron" won't install it, "pip install redbaron[pygments"] will
- new node.next_intuitive and node.previous_intuitive methods for situations where .next/previous doesn't behave the way the user expect it http://redbaron.readthedocs.org/en/latest/other.html#next-intuitive-previous...
--
Laurent Peuch -- Bram _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
I'm really happy you sent this. I had forgotten about RedBaron and was going to start looking for a project exactly like it. Would you be interested in moving the project under the umbrella of the PyCQA? We could probably more easily integrate new contributors in an organization. I'll start taking a look at how I could help out with RedBaron since Flake8 will probably start depending on it or something like it.
Cheers, Ian
On Mon, Mar 28, 2016 at 11:13 AM, Ian Cordasco graffatcolmingov@gmail.com wrote:
I'm really happy you sent this. I had forgotten about RedBaron and was going to start looking for a project exactly like it. Would you be interested in moving the project under the umbrella of the PyCQA? We could probably more easily integrate new contributors in an organization. I'll start taking a look at how I could help out with RedBaron since Flake8 will probably start depending on it or something like it.
Of course Baron is also welcome in addition to RedBaron. In particular, I'd love to firm up the Python 3 support (since Flake8 would need that).
If you need more PyCQA information, we have some documentation on http://meta.pycqa.org
Hello,
On Mon, Mar 28, 2016 at 11:15:59AM -0500, Ian Cordasco wrote:
On Mon, Mar 28, 2016 at 11:13 AM, Ian Cordasco graffatcolmingov@gmail.com wrote:
I'm really happy you sent this. I had forgotten about RedBaron and was going to start looking for a project exactly like it. Would you be interested in moving the project under the umbrella of the PyCQA? We could probably more easily integrate new contributors in an organization. I'll start taking a look at how I could help out with RedBaron since Flake8 will probably start depending on it or something like it.
Of course Baron is also welcome in addition to RedBaron. In particular, I'd love to firm up the Python 3 support (since Flake8 would need that).
If you need more PyCQA information, we have some documentation on http://meta.pycqa.org
Thanks a lot for this proposition :)
After reading the documentation, I am very tempted to say yes, but I have one small hesitation (not about the CoC, I'm actually quite happy that you have one): PyCQA define itself as "a loose organization of people who maintain projects in roughly the same domain: automatic style and quality reporting" but that's not exactly (red)baron is doing. While it's not very far away (like a low level more general tool that can be used to build those kind of tools), it's still a bit different, won't that be a problem?
On Wed, Mar 30, 2016 at 5:02 PM, Laurent Peuch cortex@worlddomination.be wrote:
Hello,
On Mon, Mar 28, 2016 at 11:15:59AM -0500, Ian Cordasco wrote:
On Mon, Mar 28, 2016 at 11:13 AM, Ian Cordasco graffatcolmingov@gmail.com wrote:
I'm really happy you sent this. I had forgotten about RedBaron and was going to start looking for a project exactly like it. Would you be interested in moving the project under the umbrella of the PyCQA? We could probably more easily integrate new contributors in an organization. I'll start taking a look at how I could help out with RedBaron since Flake8 will probably start depending on it or something like it.
Of course Baron is also welcome in addition to RedBaron. In particular, I'd love to firm up the Python 3 support (since Flake8 would need that).
If you need more PyCQA information, we have some documentation on http://meta.pycqa.org
Thanks a lot for this proposition :)
After reading the documentation, I am very tempted to say yes, but I have one small hesitation (not about the CoC, I'm actually quite happy that you have one): PyCQA define itself as "a loose organization of people who maintain projects in roughly the same domain: automatic style and quality reporting" but that's not exactly (red)baron is doing. While it's not very far away (like a low level more general tool that can be used to build those kind of tools), it's still a bit different, won't that be a problem?
Not really. That's a living document and we can amend it to use language that would make (Red)Baron feel more comfortable joining. When I wrote that, I was mostly describing the state of things rather than the future which was a bit silly of me. I feel like RedBaron would be a good fit, especially since I'm not exactly sure astroid on its own can be squeezed into that statement. Maybe we should just remove the "automatic style and reporting" bit to keep it a bit more general?
On Wed, Mar 30, 2016 at 05:12:00PM -0500, Ian Cordasco wrote:
On Wed, Mar 30, 2016 at 5:02 PM, Laurent Peuch cortex@worlddomination.be wrote:
Hello,
On Mon, Mar 28, 2016 at 11:15:59AM -0500, Ian Cordasco wrote:
On Mon, Mar 28, 2016 at 11:13 AM, Ian Cordasco graffatcolmingov@gmail.com wrote:
I'm really happy you sent this. I had forgotten about RedBaron and was going to start looking for a project exactly like it. Would you be interested in moving the project under the umbrella of the PyCQA? We could probably more easily integrate new contributors in an organization. I'll start taking a look at how I could help out with RedBaron since Flake8 will probably start depending on it or something like it.
Of course Baron is also welcome in addition to RedBaron. In particular, I'd love to firm up the Python 3 support (since Flake8 would need that).
If you need more PyCQA information, we have some documentation on http://meta.pycqa.org
Thanks a lot for this proposition :)
After reading the documentation, I am very tempted to say yes, but I have one small hesitation (not about the CoC, I'm actually quite happy that you have one): PyCQA define itself as "a loose organization of people who maintain projects in roughly the same domain: automatic style and quality reporting" but that's not exactly (red)baron is doing. While it's not very far away (like a low level more general tool that can be used to build those kind of tools), it's still a bit different, won't that be a problem?
Not really. That's a living document and we can amend it to use language that would make (Red)Baron feel more comfortable joining. When I wrote that, I was mostly describing the state of things rather than the future which was a bit silly of me. I feel like RedBaron would be a good fit, especially since I'm not exactly sure astroid on its own can be squeezed into that statement. Maybe we should just remove the "automatic style and reporting" bit to keep it a bit more general?
Oh, I don't have strong feelings regarding a modification of this document, it was more about the existing group, but if you think it's ok then it's a "yes" from me :)
I'll take a look tomorrow about migrating the repositories to the organisation.
(ps: I won't be there at pyconUS, too far away, not enough money and time)
participants (2)
-
Ian Cordasco -
Laurent Peuch