Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

string_input_producer has no analogue for other dtypes #486

Closed
bschreck opened this issue Dec 12, 2015 · 4 comments
Closed

string_input_producer has no analogue for other dtypes #486

bschreck opened this issue Dec 12, 2015 · 4 comments
Assignees
@mrry
Labels
type:feature Feature requests

Comments

@bschreck
Copy link

It would be nice to a corresponding int_input_producer for producing a queue cycles through labels, for instance. This is a super easy fix by just adding another wrapper around _input_producer.
@girving
Copy link
Contributor

girving commented Dec 12, 2015

@josh11b: Why isn't this just input_producer? It doesn't seem to be at all string specific.

@bschreck
Copy link
Author

It seems like they wanted to make it convenient to loop through filenames for internal reasons, but for some reason didn't need it for any other file type. But it's just as easy to use _input_producer with another data type.

@girving
Copy link
Contributor

girving commented Dec 19, 2015

@bschreck: _input_producer is a fine solution for now, but it isn't part of the public API and will go away once we implement __all__. However, unless there's a reason we should probably remove the underscore and make it part of the public API.

@martinwicke
Copy link
Member

+1

On Fri, Dec 18, 2015 at 4:35 PM Geoffrey Irving notifications@github.com
wrote:

@bschreck https://github.com/bschreck: _input_producer is a fine
solution for now, but it isn't part of the public API and will go away once
we implement all. However, unless there's a reason we should probably
remove the underscore and make it part of the public API.

—
Reply to this email directly or view it on GitHub
#486 (comment)
.

@mrry mrry self-assigned this Mar 18, 2016
@vrv vrv closed this as completed in aba52f4 Mar 19, 2016
@aselle aselle added type:feature Feature requests and removed enhancement labels Feb 9, 2017
darkbuck pushed a commit to darkbuck/tensorflow that referenced this issue Jan 23, 2020
@whchung
Merge pull request tensorflow#486 from jeffdaily/cwise_op_mul_1_cc_re…
1cf84eb 
…sync

resync cwise_op_mul_1.cc with upstream
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mrry mrry

Labels
type:feature Feature requests
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@girving @mrry @aselle @martinwicke @bschreck