Open this-is-yaash opened 1 week ago
@this-is-yaash could you please assign this to me sir? i have a clear idea on how to implement this.
@yasheela-alla I noticed you were already requesting for documentation issue at #67. Multiple issues can't be assigned to a single contributor.
Please state which issue you are going to work and let me know!
Also, please explain how you are going to work on this issue, if you choose this issue!
I would love to work on both the issues (if you assign me :), once i am done with issue #67, I will start working on this.
@this-is-yaash Please assign this issue to me under the label Hacktoberfest
.
I would love to work on both the issues (if you assign me :), once i am done with issue #67, I will start working on this.
Complete existing issue, then request here again if it's available I'll assign it to you!
@this-is-yaash Please assign this issue to me under the label
Hacktoberfest
.
@aryanaarav can you explain how you are planning to work on this?
I have raised a PR, please check @this-is-yaash
Hey @this-is-yaash good evening. May I get assigned to this one? I've completed my previous one, thanks!!
Hi! I'd like to contribute to this issue. Could you please assign it to me ?
I have raised a PR, please check @this-is-yaash
@yasheela-alla i've already gave an overview about what to do!
Point out logically(programming-wise) how you are going to solve this?
@yasheela-alla I noticed you still have PR pending with review changes! Please make necessary updates, and raise PR. Until your PR get's approved, you won't be able to work on other issues.
@ManyashreeN @Probatio-Diabolica Please explain your ideas on how you are going to fix it!
Sure! I was busy with college works, I will look into this now.
Hey @this-is-yaash! This is my approach -
We can update display.py
to make function calls to the separate functions in the three files (models.py
, graph.py
, and piechart.py
) by creating a new function inside display.py
that combnes functionalities from
these files.
This is how structure of display.py
roughly looks for models.py
from package.models import display as model_display
# to call display from models.py
def display_model(data):
model_display(data)
# Main function\
def display(feature_name, data):
if feature_name == "model":
display_model(data)
# example
if __name__ == "__main__":
display("model", "test")
We can follow the same process for the rem two graph.py
and piechart.py
So far, we have 3 features (related to file I/O):
models.py
graph.py
piechart.py
We execute these three features like
from package.models import display display("test")
from package.graph import display display("test")
from package.piechart import plot display("test")
But we also have
display.py
which has all the 3 features combinesfrom package.display import models models("test")
This brings more flexibility, rather than importing different files everything is written in single file, but we just call the method name.
Requirement
Even though the above display.py feature is more flexible for execution, it's not ideal from a development perspective. I want everything to work the same, but instead of calling the methods from within the feature file, it should make a function call to one that is outside the function.
Hi @this-is-yaash !
I will implement a function in display.py which calls the functions from rest 3 libraries, models.py, graph.py and piechart.py. I will also take care of error handling inn the implementation.
I will import all three functions related to I/O in the three models and call them in one function in an if condition based on the feature type.
Please assign this issue to me under GSsocExt.
@ManyashreeN this issue is still up-for-grab, want to give a try?
Yes, I am interested in giving it a try.
yes @Wahid7852, I shared my approach, Please review and assign me if you'd want me to work on it.
hey @this-is-yaash can i work on this issue? i shared my approach
How will you be approaching it @ManyashreeN tell me your views on how you'd tackle it and make sure there isn't any GPT related content
To effectively integrate the functionalities from models.py, graph.py, and piechart.py into display.py, we will adopt an event-driven programming model.
Event Dispatcher Class: We’ll start by creating a class that will serve as the control center for managing user commands. This class will connect each display feature—like models, graphs, and pie charts—to its respective function.
Command Handlers: Inside this class, we’ll implement specific methods for handling the display of models, graphs, and pie charts. Each method will focus solely on its own task, ensuring clarity and ease of maintenance.
Dispatch Method: We’ll develop a method that listens for user input and checks it against our defined commands. This method will call the appropriate handler based on what the user wants to see.
User Interaction Loop: A continuous prompt will be established to engage with the user. They can specify which feature they wish to display, making the program interactive and responsive.
Error Handling: Finally, we’ll incorporate error management within each handler. This will allow us to provide clear and friendly feedback if something goes wrong, ensuring a smooth user experience.
Summary
By following this approach, we’ll create a display management system that is modular, easy to use, and flexible enough to accommodate future enhancements. The goal is to make the code clean and maintainable while also making it enjoyable for users to interact with the application. This event-driven structure not only improves the functionality but also enhances user engagement and satisfaction.
To effectively integrate the functionalities from models.py, graph.py, and piechart.py into display.py, we will adopt an event-driven programming model.
1. Event Dispatcher Class: We’ll start by creating a class that will serve as the control center for managing user commands. This class will connect each display feature—like models, graphs, and pie charts—to its respective function. 2. Command Handlers: Inside this class, we’ll implement specific methods for handling the display of models, graphs, and pie charts. Each method will focus solely on its own task, ensuring clarity and ease of maintenance. 3. Dispatch Method: We’ll develop a method that listens for user input and checks it against our defined commands. This method will call the appropriate handler based on what the user wants to see. 4. User Interaction Loop: A continuous prompt will be established to engage with the user. They can specify which feature they wish to display, making the program interactive and responsive. 5. Error Handling: Finally, we’ll incorporate error management within each handler. This will allow us to provide clear and friendly feedback if something goes wrong, ensuring a smooth user experience.
Summary
By following this approach, we’ll create a display management system that is modular, easy to use, and flexible enough to accommodate future enhancements. The goal is to make the code clean and maintainable while also making it enjoyable for users to interact with the application. This event-driven structure not only improves the functionality but also enhances user engagement and satisfaction.
We appreciate your enthusiasm but cannot move forward with this as it requires a discerning approach. Kindly provide one to proceed.
Thankyou for your feedback. I would be happy to refine my idea and focus on the aspects that align with your expectations
display.py should act like a controller or router that simply forwards calls to the respective feature files (models.py, graph.py, piechart.py).
By creating a centralized file (display.py) that acts as a dispatcher to forward function calls to the appropriate feature files (models.py, graph.py, piechart.py).
Function imports: import the relevant functions (like display and plot) from the individual feature files into display.py.
Function calls: In display.py, we can define wrapper functions (like models(), graph(), piechart()) that simply forward the function calls to their corresponding functions in the feature files.
i would like work in this
@121hemank Could you please explain, how you are planning to fix this issue?
By creating a centralized file (display.py) that acts as a dispatcher to forward function calls to the appropriate feature files (models.py, graph.py, piechart.py).
Function imports: import the relevant functions (like display and plot) from the individual feature files into display.py.
Function calls: In display.py, we can define wrapper functions (like models(), graph(), piechart()) that simply forward the function calls to their corresponding functions in the feature files.
So far, we have 3 features (related to file I/O):
models.py
graph.py
piechart.py
We execute these three features like
But we also have
display.py
which has all the 3 features combinesThis brings more flexibility, rather than importing different files everything is written in single file, but we just call the method name.
Requirement
Even though the above display.py feature is more flexible for execution, it's not ideal from a development perspective. I want everything to work the same, but instead of calling the methods from within the feature file, it should make a function call to one that is outside the function.