| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
This is required to be able to include the generated AC code from clinic/itertoolsmodule.c.h, which must appear before these definitions but after all typedefs and type declarations.
|
Note that I purposefully made this in two commits to make the steps clearer. Consider reviewing each commit individually. |
Sorry, something went wrong.
|
Also note: While moving around and re-formatting doc-strings (required for AC), I also improved some of them. Reviewers, please make sure to review doc-string changes. |
Sorry, something went wrong.
There was a problem hiding this comment.
I left reviewing the docstrings on to @rhettinger.
Sorry, something went wrong.
| all have the same key. The common key for the group is the first item in the | ||
| pair. | ||
|
|
||
| Example: |
There was a problem hiding this comment.
Currently examples are not included in docstrings. I think it is better to keep examples in the module documentation and keep docstrings brief and clear.
Sorry, something went wrong.
There was a problem hiding this comment.
There were already examples in some of the doc-strings, e.g. for product() and combinations(), so I added some to doc-strings where there were no examples based on examples I found in the docs.
@rhettinger, should I remove all examples from doc-strings, keep only those which were already in the doc-strings, or keep the new examples as well?
Sorry, something went wrong.
There was a problem hiding this comment.
Before adding an example, I would try adding a clear summary of the class. Why did you remove the original summary, “an iterator that returns consecutive keys and groups”?
Sorry, something went wrong.
There was a problem hiding this comment.
I actually don't remember, this is from a patch I wrote a long time ago... We can just leave the current doc-string (though it doesn't follow the "start with one short line" principle):
Make an iterator that returns consecutive keys and groups from the iterable. If the key function is not specified or is None, the element itself is used for grouping.
Sorry, something went wrong.
There was a problem hiding this comment.
I agree, this summary line is not very informative.
Sorry, something went wrong.
There was a problem hiding this comment.
I definitely agree that "returns consecutive keys and groups" isn't informative without more context.
Sorry, something went wrong.
There was a problem hiding this comment.
Suggestion (sans example):
Return an iterator of groups of values as (key, group) pairs.
This groups together consecutive values from the given iterator. For each group, a (key, group) 2-tuple is yielded, where ``key'' is the common key value for the group, and ``group'' is an iterator of the values in the group.
Sorry, something went wrong.
There was a problem hiding this comment.
Revised suggestion:
Return an iterator of groups of items as (key, group) pairs.
This groups together consecutive items from the given iterator. Each group contains items for which the key gives the same result.
For each group, a (key, group) 2-tuple is yielded, where "key" is the common key value for the group and "group" is an iterator of the items in the group.
Sorry, something went wrong.
There was a problem hiding this comment.
This looks better to me. But I'm not an English expert, and in any case the last word on to @rhettinger.
Sorry, something went wrong.
There was a problem hiding this comment.
I've changed the doc-string to match my latest suggestion. Will await review by @rhettinger.
Sorry, something went wrong.
| /*[clinic input] | ||
| itertools.groupby.__reduce__ as groupby_reduce | ||
|
|
||
| lz: self(type="groupbyobject *") |
There was a problem hiding this comment.
I think that it is better to rename the parameter than use the self converter. This increases the size of the patch, but in long term it makes the code clearer.
The same for other methods below.
But ask @rhettinger first. His can have different preferences.
Sorry, something went wrong.
There was a problem hiding this comment.
I'll wait for @rhettinger's input on this.
Sorry, something went wrong.
| @@ -137,8 +185,17 @@ groupby_next(groupbyobject *gbo) | |||
| return r; | |||
| } | |||
|
|
|||
| /*[clinic input] | |||
| itertools.groupby.__reduce__ as groupby_reduce | |||
There was a problem hiding this comment.
Is groupby_reduce used anywhere in non-generated code? If no, it is better to keep the name generated by Argument Clinic.
The same for other methods below.
Sorry, something went wrong.
There was a problem hiding this comment.
Do you think we should also remove the as for the new functions, e.g. itertools.groupby.new as groupby_new?
Sorry, something went wrong.
There was a problem hiding this comment.
groupby_new and groupby_new__doc__ are used in the initializer of groupby_type.
Sorry, something went wrong.
| @classmethod | ||
| itertools.starmap.__new__ as starmap_new | ||
|
|
||
| function: object |
There was a problem hiding this comment.
Parameters should be positional-only.
Sorry, something went wrong.
| @classmethod | ||
| itertools.count.__new__ as count_new | ||
|
|
||
| start: object = NULL |
There was a problem hiding this comment.
start as long_cnt: object(c_default="NULL") = 0
step as long_step: object(c_default="NULL") = 1
Sorry, something went wrong.
* drop all "as" clauses for function names, renaming the relevant C functions instead * count.__new__: add missing default values for arguments and rename the argument variables back to those in the pre-AC code * starmap.__new__: properly define the arguments as positional-only
| all have the same key. The common key for the group is the first item in the | ||
| pair. | ||
|
|
||
| Example: |
There was a problem hiding this comment.
Before adding an example, I would try adding a clear summary of the class. Why did you remove the original summary, “an iterator that returns consecutive keys and groups”?
Sorry, something went wrong.
| reduce_doc}, | ||
| {NULL, NULL} /* sentinel */ | ||
| }; | ||
|
|
||
| PyDoc_STRVAR(starmap_doc, |
There was a problem hiding this comment.
Seems no longer used
Sorry, something went wrong.
| Create a starmap object. | ||
|
|
||
| Return an iterator whose values are returned from the function evaluated | ||
| with a argument tuple taken from the given iterable. |
There was a problem hiding this comment.
with argument tuples
Sorry, something went wrong.
|
|
||
| Create a chain object. | ||
|
|
||
| Alternate chain() contructor taking a single iterable argument |
There was a problem hiding this comment.
Spelling: constructor
(Also, alternative is more correct than alternate outside the US.)
Sorry, something went wrong.
|
|
||
| ro: self(type="repeatobject *") | ||
|
|
||
| Private method returning an estimate of len(list(it)). |
There was a problem hiding this comment.
Aren’t ro and it the same parameter?
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, but ro isn't included in the doc-string and would be unclear to users IMO. Suggestions for something more informative than it are welcome! (self?)
Currently this gives:
>>> help(itertools.repeat.__length_hint__)
Help on method_descriptor:
__length_hint__(self, /)
Private method returning an estimate of len(list(it)).
Sorry, something went wrong.
There was a problem hiding this comment.
Why not use self?
Sorry, something went wrong.
| @@ -4541,6 +4045,990 @@ are exhausted, the fillvalue is substituted in their place. The fillvalue\n\ | |||
| defaults to None or can be specified by a keyword argument.\n\ | |||
| "); | |||
|
|
|||
|
|
|||
| /* including clinic output must come after typdefs and PyObject type | |||
There was a problem hiding this comment.
typedefs?
Sorry, something went wrong.
|
Wow, this is a stunningly massive diff (+2,890 −1,274) to a file that was only 4,684 lines to begin with. I didn't expect so much code to be moved into a .h file (which seems unwise to me and will complicate my ability to understand the code). Also, I only expected the constructor calls to be given to AC, not all of the internal reduce/setstate methods and whatnot. That said, thank you for the effort. I start working the diffs and it may take a while. |
Sorry, something went wrong.
|
I've created another PR, #4170, with a small subset of these changes (just itertools.groupby). I suggest starting with getting that sorted out, and then deciding if and how to continue with the rest of the module. |
Sorry, something went wrong.
There was a problem hiding this comment.
I've reviewed, fixed, and applied pr #4170. Please use that as a model for improving this patch.
In particular, please don't move the PyTypeObject struct definitions to the bottom. This will greatly minimize the code churn and will keep the type structs right by beside the related code (which helps maintainability).
Also, just convert the primary documented interfaces. No need for setstate, reduce, etc. Please respect the existing docstrings as much as possible. The goal is to make signatures visible, not to rewrite the documentation. That said, if you find something that is unclear or incorrect, please point it out and I will take a look.
Sorry, something went wrong.
|
When you're done making the requested changes, leave the comment: I have made the requested changes; please review again. |
Sorry, something went wrong.
|
@rhettinger, will do. If you prefer, I will gladly continue to split this out into small PRs rather than one large one. Just let me know your preference. |
Sorry, something went wrong.
|
One big patch will be fine. Following the pattern of PR #4170 will give a much more compact and reviewable single patch. |
Sorry, something went wrong.
Some things will have to be moved to the top/bottom due to needing to appear before/after the line #include "clinic/itertoolsmodule.c.h". This includes, for example, the PyTypeObject declarations, which must come before that line. If this is a deal-breaker, please let me know ASAP. |
Sorry, something went wrong.
|
Can forward declarations help? |
Sorry, something went wrong.
I'm working on this now and so far it seems that only the static PyTypeObject declarations need to appear at the top. If @rhettinger prefers, we can duplicate them, keeping them in their current positions as well as at the top of the file before the #include. |
Sorry, something went wrong.
|
See new PR #9164 which is a complete reworking of this as per @rhettinger's directions. |
Sorry, something went wrong.
|
This PR was superseded by PR 9164. Marking as closed. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
I applied my old patch for itertools from the old "AC Derby" days, fixed all that needed to be fixed and made a few minor AC-related fixes as suggested by @serhiy-storchaka on the issue tracker.
To get this working with the separate clinic/itertoolsmodule.c.h file, I also moved all of the method definition arrays and static object definitions to the end of the file, so that the #include statement could come before them.
Many thanks @serhiy-storchaka for reviewing the patch and providing guidance!
https://bugs.python.org/issue20180