bean names and get/set

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bean names and get/set

Sommers, Roger

Hi Jython developers,

 

First off, thanks for your hard work developing Jython! I’m particularly impressed with how easy it is to get working with an existing jar.

 

I was wondering if you would consider a feature request or two:

 

1.     to optionally preserve the case of bean names (eg getShape() -> property/bean “Shape” instead of “shape”). Something like python.options.preserveBeanNames = true (default false of course).

2.     To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

 

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won’t run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

 

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can’t stop them using the get/set methods without enhancement #2.

 

Many thanks for your time

-Roger.

 

(C++, Java, C# and python developer)

 


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bean names and get/set

Sommers, Roger

Hi again,

 

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

 

Eg:

 

PyPreservePropertyCaseTag                 - getShape() generates readable property “Shape” instead of “shape”

PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called “orCreateWidget”

PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

 

Thanks again

 

-Roger.

 

 

From: Sommers, Roger
Sent: 07 March 2017 11:47
To: [hidden email]
Subject: [Jython-dev] bean names and get/set

 

Hi Jython developers,

 

First off, thanks for your hard work developing Jython! I’m particularly impressed with how easy it is to get working with an existing jar.

 

I was wondering if you would consider a feature request or two:

 

1.     to optionally preserve the case of bean names (eg getShape() -> property/bean “Shape” instead of “shape”). Something like python.options.preserveBeanNames = true (default false of course).

2.     To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

 

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won’t run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

 

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can’t stop them using the get/set methods without enhancement #2.

 

Many thanks for your time

-Roger.

 

(C++, Java, C# and python developer)

 


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bean names and get/set

Jeff Allen-2

Roger:

I gave this a pause to see if anyone with longer history in Jython would chip in.

Under JavaBeans conventions, property names start with a lower case letter (see https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), and that tends to be the case in Python. Sure, the getter and setters are getLength and setLength, but the property is called "length". So making it "x.Length" is not a question of preserving the case, but of using a non-Java convention while exposing them to Python.

I don't know C#, but you've explained that C# names its properties with an initial upper case, and the default exposure in IronPython of a C# class leaves that as it is. You have code you want to run in both interpreters that gives an interpretation to x.Length when x is a C# object of class X, and you want the same interpretation to be given y.length when y is a JavaBean of type Y (or maybe any Java object of class Y with visible member "length").

A language purist might ask "how do you know X.Length and Y.length mean compatible things?". (He would ask the same about X.a and Y.a if the identically named member 'a' were not the attribute of a common base or interface.) And the Pythonist would probably reply something about duck typing. Duck-typing always poses risks to correctness: it's an assumption that length (or write, etc.) means the same thing on several unrelated classes. But the motivation for Jython to take the risk with the well-established JavaBeans convention is clear.

I think what you're asking is: please provide a way to interpret in Jython, the interface offered by Java objects, that makes them name-similar to C# objects wrapped by IronPython, assuming similar names mean the same thing.

If that's a fair summary, I'm doubtful that's a thing one ought to bake into the Jython interpreter. I can see practical difficulties too, since exposure gets done once after installation, and the cached exposure is used globally, affecting the names seen by code you didn't write. If this has to be done by tagging-up (the wrapped version of) those Java classes and methods, more or less individually crafted, could the same not be achieved by wrappers (probably decorators) at the Python level, in a distinct library/utility, used just where needed?

Jeff Allen
On 07/03/2017 12:12, Sommers, Roger wrote:

Hi again,

 

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

 

Eg:

 

PyPreservePropertyCaseTag                 - getShape() generates readable property “Shape” instead of “shape”

PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called “orCreateWidget”

PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

 

Thanks again

 

-Roger.

 

 

From: Sommers, Roger
Sent: 07 March 2017 11:47
To: [hidden email]
Subject: [Jython-dev] bean names and get/set

 

Hi Jython developers,

 

First off, thanks for your hard work developing Jython! I’m particularly impressed with how easy it is to get working with an existing jar.

 

I was wondering if you would consider a feature request or two:

 

1.     to optionally preserve the case of bean names (eg getShape() -> property/bean “Shape” instead of “shape”). Something like python.options.preserveBeanNames = true (default false of course).

2.     To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

 

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won’t run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

 

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can’t stop them using the get/set methods without enhancement #2.

 

Many thanks for your time

-Roger.

 

(C++, Java, C# and python developer)

 



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford


_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bean names and get/set

Sommers, Roger

Hi Jeff, thanks for the reply. Some comments are inline.

 

From: Jeff Allen [mailto:[hidden email]]
Sent: 09 March 2017 08:26
To: Sommers, Roger
Cc: [hidden email]
Subject: Re: [Jython-dev] bean names and get/set

 

Roger:

I gave this a pause to see if anyone with longer history in Jython would chip in.

Under JavaBeans conventions, property names start with a lower case letter (see https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), and that tends to be the case in Python. Sure, the getter and setters are getLength and setLength, but the property is called "length". So making it "x.Length" is not a question of preserving the case, but of using a non-Java convention while exposing them to Python.

Sure. I used the word preserving because I wanted to distinguish between “use the name as-is without the get/set” and “force uppercase letter”. I appreciate the reasons why it is done the way it is, and following the bean convention is a perfectly sensible choice. I am merely suggesting an option to allow Java developers more control over what the Jython interface to their library looks like. For example, they might decide to use lower-case properties for read-only values, who knows. The use case for me happens to be closer alignment with C# conventions.

I don't know C#, but you've explained that C# names its properties with an initial upper case, and the default exposure in IronPython of a C# class leaves that as it is. You have code you want to run in both interpreters that gives an interpretation to x.Length when x is a C# object of class X, and you want the same interpretation to be given y.length when y is a JavaBean of type Y (or maybe any Java object of class Y with visible member "length").

A language purist might ask "how do you know X.Length and Y.length mean compatible things?". (He would ask the same about X.a and Y.a if the identically named member 'a' were not the attribute of a common base or interface.) And the Pythonist would probably reply something about duck typing. Duck-typing always poses risks to correctness: it's an assumption that length (or write, etc.) means the same thing on several unrelated classes. But the motivation for Jython to take the risk with the well-established JavaBeans convention is clear.

Understood. I used “length” as an example, but in my particular instance I do in fact generate the jar and assembly (it is our own code), and I know the properties mean the same thing in both. In theory I could just add the lower case version to the C# (ie, have both upper and lower), in fact this would be easy because it’s generated code. But I would rather not have two setters and getters for each property.

I think what you're asking is: please provide a way to interpret in Jython, the interface offered by Java objects, that makes them name-similar to C# objects wrapped by IronPython, assuming similar names mean the same thing.

 

That is precisely it. Perhaps my case is a little unusual in that I am using both IronPython and Jython to (conceptually) wrap the same library. You might ask why; the answer is that there is some demand for Excel integration, which IronPython is good at, but we also want to provide python support for linux and unix-based users. We are at the early stages of python adoption, and not much python code has been written yet. Before people go off and write loads of scripts using one implementation, I am trying to take steps to ensure that what they write can (largely) be used in the other. Where the language semantics differ (eg Streams vs Readers), I have provided a utils module that hides such differences, but the object library, which forms the vast bulk of the interface, can be brought into close alignment with these enhancements.

 

If that's a fair summary, I'm doubtful that's a thing one ought to bake into the Jython interpreter. I can see practical difficulties too, since exposure gets done once after installation, and the cached exposure is used globally, affecting the names seen by code you didn't write.

 

I’m not sure I understand this point. I am not suggesting we change the default behaviour, the only thing I am looking to bake in is more flexibility :-).

 

If this has to be done by tagging-up (the wrapped version of) those Java classes and methods, more or less individually crafted, could the same not be achieved by wrappers (probably decorators) at the Python level, in a distinct library/utility, used just where needed?

 

Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.

 

The tagged exception idea in Jython works well and is a clever idea, but there is only one example of its use at the moment – to completely ignore a method. I am suggesting more uses of it to give those deploying Jython to users more flexibility over the Jython interface to their libraries.

 

Thanks again for your time and for your considered reply, much appreciated!

 

-Roger.




Jeff Allen

On 07/03/2017 12:12, Sommers, Roger wrote:

Hi again,

 

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

 

Eg:

 

PyPreservePropertyCaseTag                 - getShape() generates readable property “Shape” instead of “shape”

PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called “orCreateWidget”

PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

 

Thanks again

 

-Roger.

 

 

From: Sommers, Roger
Sent: 07 March 2017 11:47
To: [hidden email]
Subject: [Jython-dev] bean names and get/set

 

Hi Jython developers,

 

First off, thanks for your hard work developing Jython! I’m particularly impressed with how easy it is to get working with an existing jar.

 

I was wondering if you would consider a feature request or two:

 

1.       to optionally preserve the case of bean names (eg getShape() -> property/bean “Shape” instead of “shape”). Something like python.options.preserveBeanNames = true (default false of course).

2.       To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

 

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won’t run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

 

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can’t stop them using the get/set methods without enhancement #2.

 

Many thanks for your time

-Roger.

 

(C++, Java, C# and python developer)

 




------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford




_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

 


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bean names and get/set

Adam Burke-2

Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.


If I'm following correctly, you should be able to write a short decorator utility in pure Python that does this by adding aliases to the ___dict___, or similar? Something extending the basic idea here:


You wouldn't need to hand craft decorators for all your Java API, just make the entry point to your API a python module that knows the name of your Java package and calls this aliasing utility once on each class at import time.

If that turns out fairly clean it might be a useful utility to add, as being able to have the same script in IronPython and Jython does sound good.

Adam

在 2017年3月9日,上午4:53,Sommers, Roger <[hidden email]> 写道:

Hi Jeff, thanks for the reply. Some comments are inline.

 

From: Jeff Allen [[hidden email]]
Sent: 09 March 2017 08:26
To: Sommers, Roger
Cc: [hidden email]
Subject: Re: [Jython-dev] bean names and get/set

 

Roger:

I gave this a pause to see if anyone with longer history in Jython would chip in.

Under JavaBeans conventions, property names start with a lower case letter (see https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), and that tends to be the case in Python. Sure, the getter and setters are getLength and setLength, but the property is called "length". So making it "x.Length" is not a question of preserving the case, but of using a non-Java convention while exposing them to Python.

Sure. I used the word preserving because I wanted to distinguish between “use the name as-is without the get/set” and “force uppercase letter”. I appreciate the reasons why it is done the way it is, and following the bean convention is a perfectly sensible choice. I am merely suggesting an option to allow Java developers more control over what the Jython interface to their library looks like. For example, they might decide to use lower-case properties for read-only values, who knows. The use case for me happens to be closer alignment with C# conventions.

I don't know C#, but you've explained that C# names its properties with an initial upper case, and the default exposure in IronPython of a C# class leaves that as it is. You have code you want to run in both interpreters that gives an interpretation to x.Length when x is a C# object of class X, and you want the same interpretation to be given y.length when y is a JavaBean of type Y (or maybe any Java object of class Y with visible member "length").

A language purist might ask "how do you know X.Length and Y.length mean compatible things?". (He would ask the same about X.a and Y.a if the identically named member 'a' were not the attribute of a common base or interface.) And the Pythonist would probably reply something about duck typing. Duck-typing always poses risks to correctness: it's an assumption that length (or write, etc.) means the same thing on several unrelated classes. But the motivation for Jython to take the risk with the well-established JavaBeans convention is clear.

Understood. I used “length” as an example, but in my particular instance I do in fact generate the jar and assembly (it is our own code), and I know the properties mean the same thing in both. In theory I could just add the lower case version to the C# (ie, have both upper and lower), in fact this would be easy because it’s generated code. But I would rather not have two setters and getters for each property.

I think what you're asking is: please provide a way to interpret in Jython, the interface offered by Java objects, that makes them name-similar to C# objects wrapped by IronPython, assuming similar names mean the same thing.

 

That is precisely it. Perhaps my case is a little unusual in that I am using both IronPython and Jython to (conceptually) wrap the same library. You might ask why; the answer is that there is some demand for Excel integration, which IronPython is good at, but we also want to provide python support for linux and unix-based users. We are at the early stages of python adoption, and not much python code has been written yet. Before people go off and write loads of scripts using one implementation, I am trying to take steps to ensure that what they write can (largely) be used in the other. Where the language semantics differ (eg Streams vs Readers), I have provided a utils module that hides such differences, but the object library, which forms the vast bulk of the interface, can be brought into close alignment with these enhancements.

 

If that's a fair summary, I'm doubtful that's a thing one ought to bake into the Jython interpreter. I can see practical difficulties too, since exposure gets done once after installation, and the cached exposure is used globally, affecting the names seen by code you didn't write.

 

I’m not sure I understand this point. I am not suggesting we change the default behaviour, the only thing I am looking to bake in is more flexibility :-).

 

If this has to be done by tagging-up (the wrapped version of) those Java classes and methods, more or less individually crafted, could the same not be achieved by wrappers (probably decorators) at the Python level, in a distinct library/utility, used just where needed?

 

Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.

 

The tagged exception idea in Jython works well and is a clever idea, but there is only one example of its use at the moment – to completely ignore a method. I am suggesting more uses of it to give those deploying Jython to users more flexibility over the Jython interface to their libraries.

 

Thanks again for your time and for your considered reply, much appreciated!

 

-Roger.




Jeff Allen

On 07/03/2017 12:12, Sommers, Roger wrote:

Hi again,

 

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

 

Eg:

 

PyPreservePropertyCaseTag                 - getShape() generates readable property “Shape” instead of “shape”

PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called “orCreateWidget”

PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

 

Thanks again

 

-Roger.

 

 

From: Sommers, Roger
Sent: 07 March 2017 11:47
To: [hidden email]
Subject: [Jython-dev] bean names and get/set

 

Hi Jython developers,

 

First off, thanks for your hard work developing Jython! I’m particularly impressed with how easy it is to get working with an existing jar.

 

I was wondering if you would consider a feature request or two:

 

1.       to optionally preserve the case of bean names (eg getShape() -> property/bean “Shape” instead of “shape”). Something like python.options.preserveBeanNames = true (default false of course).

2.       To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

 

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won’t run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

 

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can’t stop them using the get/set methods without enhancement #2.

 

Many thanks for your time

-Roger.

 

(C++, Java, C# and python developer)

 




------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford




_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

 

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bean names and get/set

Sommers, Roger

Hi Adam,

 

This sounds like it could be an option, thanks. I’ll have a look when I get the time. It might increase the startup time, though (already nearly 20s to load and initialise our libraries).

 

Cheers

-Roger.

 

 

 

From: Adam Burke [mailto:[hidden email]]
Sent: 09 March 2017 10:45
To: Sommers, Roger
Cc: Jeff Allen; [hidden email]
Subject: Re: [Jython-dev] bean names and get/set

 

 

Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.

 

If I'm following correctly, you should be able to write a short decorator utility in pure Python that does this by adding aliases to the ___dict___, or similar? Something extending the basic idea here:

 

 

You wouldn't need to hand craft decorators for all your Java API, just make the entry point to your API a python module that knows the name of your Java package and calls this aliasing utility once on each class at import time.

 

If that turns out fairly clean it might be a useful utility to add, as being able to have the same script in IronPython and Jython does sound good.

Adam


201739日,上午4:53Sommers, Roger <[hidden email]> 写道:

Hi Jeff, thanks for the reply. Some comments are inline.

 

From: Jeff Allen [[hidden email]]
Sent: 09 March 2017 08:26
To: Sommers, Roger
Cc: [hidden email]
Subject: Re: [Jython-dev] bean names and get/set

 

Roger:

I gave this a pause to see if anyone with longer history in Jython would chip in.

Under JavaBeans conventions, property names start with a lower case letter (see https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), and that tends to be the case in Python. Sure, the getter and setters are getLength and setLength, but the property is called "length". So making it "x.Length" is not a question of preserving the case, but of using a non-Java convention while exposing them to Python.

Sure. I used the word preserving because I wanted to distinguish between “use the name as-is without the get/set” and “force uppercase letter”. I appreciate the reasons why it is done the way it is, and following the bean convention is a perfectly sensible choice. I am merely suggesting an option to allow Java developers more control over what the Jython interface to their library looks like. For example, they might decide to use lower-case properties for read-only values, who knows. The use case for me happens to be closer alignment with C# conventions.

I don't know C#, but you've explained that C# names its properties with an initial upper case, and the default exposure in IronPython of a C# class leaves that as it is. You have code you want to run in both interpreters that gives an interpretation to x.Length when x is a C# object of class X, and you want the same interpretation to be given y.length when y is a JavaBean of type Y (or maybe any Java object of class Y with visible member "length").

A language purist might ask "how do you know X.Length and Y.length mean compatible things?". (He would ask the same about X.a and Y.a if the identically named member 'a' were not the attribute of a common base or interface.) And the Pythonist would probably reply something about duck typing. Duck-typing always poses risks to correctness: it's an assumption that length (or write, etc.) means the same thing on several unrelated classes. But the motivation for Jython to take the risk with the well-established JavaBeans convention is clear.

Understood. I used “length” as an example, but in my particular instance I do in fact generate the jar and assembly (it is our own code), and I know the properties mean the same thing in both. In theory I could just add the lower case version to the C# (ie, have both upper and lower), in fact this would be easy because it’s generated code. But I would rather not have two setters and getters for each property.

I think what you're asking is: please provide a way to interpret in Jython, the interface offered by Java objects, that makes them name-similar to C# objects wrapped by IronPython, assuming similar names mean the same thing.

 

That is precisely it. Perhaps my case is a little unusual in that I am using both IronPython and Jython to (conceptually) wrap the same library. You might ask why; the answer is that there is some demand for Excel integration, which IronPython is good at, but we also want to provide python support for linux and unix-based users. We are at the early stages of python adoption, and not much python code has been written yet. Before people go off and write loads of scripts using one implementation, I am trying to take steps to ensure that what they write can (largely) be used in the other. Where the language semantics differ (eg Streams vs Readers), I have provided a utils module that hides such differences, but the object library, which forms the vast bulk of the interface, can be brought into close alignment with these enhancements.

 

If that's a fair summary, I'm doubtful that's a thing one ought to bake into the Jython interpreter. I can see practical difficulties too, since exposure gets done once after installation, and the cached exposure is used globally, affecting the names seen by code you didn't write.

 

I’m not sure I understand this point. I am not suggesting we change the default behaviour, the only thing I am looking to bake in is more flexibility :-).

 

If this has to be done by tagging-up (the wrapped version of) those Java classes and methods, more or less individually crafted, could the same not be achieved by wrappers (probably decorators) at the Python level, in a distinct library/utility, used just where needed?

 

Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.

 

The tagged exception idea in Jython works well and is a clever idea, but there is only one example of its use at the moment – to completely ignore a method. I am suggesting more uses of it to give those deploying Jython to users more flexibility over the Jython interface to their libraries.

 

Thanks again for your time and for your considered reply, much appreciated!

 

-Roger.





Jeff Allen

On 07/03/2017 12:12, Sommers, Roger wrote:

Hi again,

 

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

 

Eg:

 

PyPreservePropertyCaseTag                 - getShape() generates readable property “Shape” instead of “shape”

PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called “orCreateWidget”

PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

 

Thanks again

 

-Roger.

 

 

From: Sommers, Roger
Sent: 07 March 2017 11:47
To: [hidden email]
Subject: [Jython-dev] bean names and get/set

 

Hi Jython developers,

 

First off, thanks for your hard work developing Jython! I’m particularly impressed with how easy it is to get working with an existing jar.

 

I was wondering if you would consider a feature request or two:

 

1.       to optionally preserve the case of bean names (eg getShape() -> property/bean “Shape” instead of “shape”). Something like python.options.preserveBeanNames = true (default false of course).

2.       To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

 

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won’t run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

 

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can’t stop them using the get/set methods without enhancement #2.

 

Many thanks for your time

-Roger.

 

(C++, Java, C# and python developer)

 





------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford





_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

 

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Loading...