You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+27-27Lines changed: 27 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,9 +38,9 @@
38
38
39
39
Python# (Python sharp) module was created with the intention of adding EOP (event oriented programming) into Python in the most native feeling, easy syntax way possible.
40
40
41
-
EOP is a programming paradigm that allows execute actions (code) based on "occurrences" or events, this is really useful when you have to execute specific actions when something happens but you do not have the certainty when or how many times is going to happen.
41
+
EOP is a programming paradigm that allows execute actions (code) based on "occurrences" or events, this is really useful when you have to execute specific actions when something happens but you do not have the certainty when or how many times is going to occur.
42
42
43
-
This module was thought to accomplish EOP with 2 objectives in mind:
43
+
This module was designed to accomplish EOP with 2 objectives in mind:
44
44
45
45
1. Features should look and feel like native Python features.
46
46
2. Implementation should be based in another famous EOP language to reduce the learning curve and improve user experience.
@@ -70,9 +70,9 @@ For objective 2, the module was architected thinking in how another EOP language
70
70
71
71
1. C# implements events as a collection of callbacks that will be executed in some point of time, this collection of functions are called **Delegates**, invoking(executing) the delegate will cause the execution of all functions(callables) in its collection.
72
72
73
-
2. delegates are not commonly exposed publicly, for security reasons. As the fields/attributes in a class have to be encapsulated, delegates as well, and the way to encapsulate them is with events. Fields/attributes are to properties as delegates are to events.
73
+
2. delegates are not commonly exposed publicly, for security reasons. Just as fields/attributes in a class have to be encapsulated, so do delegates. The way to encapsulate them is with events. Fields/attributes are to properties as delegates are to events.
74
74
75
-
3. Properties encapsulate fields/attributes with 2 functions/methods called "get" and "set", which define the logic of how data should be GET and SET out of the object, in C# events encapsulate delegates with 2 functions as well called "add" and "remove", which define the logic of how functions/subscribers should be added or removed out of the delegate.
75
+
3. Properties encapsulate fields/attributes using two methods: "get" and "set", which define the logic of how data should be GET and SET out of the object, in C# events encapsulate delegates with 2 methods as well called "add" and "remove", which define the logic of how functions/subscribers should be added or removed out of the delegate.
76
76
77
77
78
78
## Installation
@@ -82,7 +82,7 @@ For objective 2, the module was architected thinking in how another EOP language
82
82
-**Python**: Version 3.6 or higher
83
83
-**pip**: Python package manager
84
84
85
-
To install `Python_sharp` you can follow either of the options listed:
85
+
To install `python_sharp` you can follow either of the options listed:
86
86
87
87
### Disclaimer
88
88
@@ -91,55 +91,55 @@ version 1.0.0 is only available through GitHub PyPI does not contain that versio
91
91
### 1. Clone the Repository
92
92
If you want to explore the source code, you can clone the repository:
Currently there is an upcoming effort to create a VS code extension to deliver a better experience while using Python sharp, an example of this is a custom OUTLINE to visualize *@property* and *@event* with its corresponding icons as the next image shows:
and so much more!, if you want to see it come true you can show interest using and spreading the use of Python sharp, this will help to add more support to the project.
154
154
155
-
To create an enhancement request, report a bug, raise a question etc. you can use the [issues](https://github.com/juanclopgar97/Python_sharp/issues) section of this repository with the corresponding labels **enhancement**, **bug**, **question** etc. in this way collaborators can check for the request and attend it.
155
+
To create an enhancement request, report a bug, raise a question etc. you can use the [issues](https://github.com/juanclopgar97/python_sharp/issues) section of this repository with the corresponding labels **enhancement**, **bug**, **question** etc. in this way collaborators can check for the request and attend it.
156
156
157
157
## Important disclaimer
158
158
@@ -165,7 +165,7 @@ For this reason always **FOLLOW THE CONVENTIONS** since this is necessary to kee
165
165
166
166
## Use cases and examples:
167
167
168
-
In this repository there are 2 main files "Python_sharp.py" (which is the module file) and "test.py". This last file contains all the features applied into one single script, this could be really useful if you want to do a quick check about how something is implemented, however, since it is a "testing" script and not a "walk through" it could be confusing if you do not know what is going on, so it is **Highly recommended** read the documentation below which explains step by step how to implement every single feature in the module.
168
+
In this repository there are 2 main files "python_sharp.py" (which is the module file) and "test.py". This last file contains all the features applied into one single script, this could be really useful if you want to do a quick check about how something is implemented, however, since it is a "testing" script and not a "walk through" it could be confusing if you do not know what is going on, so it is **Highly recommended** read the documentation below which explains step by step how to implement every single feature in the module.
169
169
170
170
### Delegates
171
171
@@ -175,7 +175,7 @@ Python sharp Delegates are a list of callables with the same signature, when a d
175
175
It is really important to keep the callables added into the delegate with consistent signatures because parameters passed to the delegate when is being executed are the same ones passed to every single callable in the collection, so if one callable signature is expecting only 2 parameters and the next callable 3 parameters this is going to cause a TypeError that might look like this:
176
176
177
177
```Python
178
-
fromPython_sharpimport*
178
+
frompython_sharpimport*
179
179
180
180
deffunction_1(parameter_1:int): # defining a function with 1 parameter (int type)
@@ -211,7 +211,7 @@ Here *function_1* was executed correctly due the signature of the function match
211
211
Once the delegate is executed you can get the returned values (if Any) as a tuple returned by the delegate, this tuple represents the values returned by every callable in the delegate's callable collection:
212
212
213
213
```Python
214
-
fromPython_sharpimport*
214
+
frompython_sharpimport*
215
215
216
216
deffunction(text:str):
217
217
print("%s, Function is being executed!"% text)
@@ -352,7 +352,7 @@ Below this text, the use cases and explanation about the events are shown, pleas
352
352
##### Simple events
353
353
354
354
```Python
355
-
fromPython_sharpimport*
355
+
frompython_sharpimport*
356
356
357
357
class Person:
358
358
@@ -526,7 +526,7 @@ person.name = "Something" # change the name again to prove 'person_name_changed'
526
526
##### Events with arguments
527
527
528
528
```Python
529
-
fromPython_sharpimport*
529
+
frompython_sharpimport*
530
530
from typing import Callable
531
531
532
532
class MovedEventArgs(EventArgs):
@@ -721,7 +721,7 @@ Second difference is when *location* settter is calling *\_on\_moved* method, no
721
721
##### Events with modifiable arguments
722
722
723
723
```Python
724
-
fromPython_sharpimport*
724
+
frompython_sharpimport*
725
725
from typing import Callable
726
726
727
727
class LocationChangingEventArgs(CancellableEventArgs):
@@ -794,7 +794,7 @@ On this example an event named "location_changing" is implemented to notify when
794
794
Key difference is the way the custom *EventArgs*is defined:
795
795
796
796
```Python
797
-
class CancellableEventArgs(EventArgs): #Defined already on Python_sharp module
797
+
class CancellableEventArgs(EventArgs): #Defined already on python_sharp module
798
798
799
799
_cancel:bool
800
800
@@ -875,7 +875,7 @@ Imagine a class that provides the number of instances that it creates, this vari
875
875
Now imagine we want to notify when an instance is created, in other words when the *static variable* changes its value, as this event is going to notify something is going on with a static variable, we need a static event:
876
876
877
877
```Python
878
-
fromPython_sharpimport*
878
+
frompython_sharpimport*
879
879
880
880
class Person:
881
881
@@ -930,4 +930,4 @@ Key differences:
930
930
- All members used (variable, methods and event) are static (use of @staticevent instead of @event)
931
931
- Get/Set methods to encapsulate the static variable are implemented as static methods due to the lack of static properties implementation in Python
932
932
933
-
And that is it, those are all differences, so if you have questions about how this code works, it is**HIGHLYRECOMMENDED** go back to [Events](#Events) section or raise a question on the [issues](https://github.com/juanclopgar97/Python_sharp/issues) section of this repository.
933
+
And that is it, those are all differences, so if you have questions about how this code works, it is**HIGHLYRECOMMENDED** go back to [Events](#Events) section or raise a question on the [issues](https://github.com/juanclopgar97/python_sharp/issues) section of this repository.
0 commit comments