enum day{ mon,tue}
enum getday(){
return day;
}
I want to print the day, like "mon" or "tue".
Is it possible?
Just invoke the name method. For example:
>>> from java.lang import *
>>> s = Thread.currentThread().getState()
>>> s
RUNNABLE
>>> type(s)
<type 'java.lang.Thread$State'>
>>> s.name()
u'RUNNABLE'
Unless I'm mistaken, it's using the actual Java enum type, in which case you should be able to access the name attribute.
Something like day.getName() would be how you would typically do this in Java. In Java, it would return either "mon" or "tue" depending on the value of the enum instance being accessed.
Related
I am trying to use IronPython to interact with a program which exposes COM API for many functions. The COM object handle is instantiated using following.
from System import Activator, Type
com_obj = Activator.CreateInstance(Type.GetTypeFromProgID("Test.Application"))
Most functions fall into the three following common prototypes categories:
function1(BSTR inpstr, [out] VARIANT * outstr)
function2(BSTR inpstr, [out] VARIANT_BOOL * outbool)
function3(BSTR inpstr, [out] SAFEARRAY ** outlist)
When using com_obj.function1, I create a return pointer using following, and the output is as expected.
>>> outstr = clr.Reference[object]()
>>> com_obj.function1('Test String', outstr)
>>> print(oustr.Value)
For com_obj.function2, I am also able to create return pointers prototype using clr.Reference to get a return value for VARIANT_BOOL*.
>>> outbool = clr.Reference[bool]()
>>> com_obj.function2('Test String', outbool)
>>> outbool.Value
However, for com_obj.function3, and I am unable to construct a return pointer for SAFEARRAY** to access the return values. I tried the following, but it did not work. Also, I need to convert the SAFEARRAY** data to python list for further processing.
>>> mylist = clr.Reference[Array[object]]()
>>> com_obj.function3('Test String', mylist)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Could not convert argument 1 for call to com_obj.function3
I think the last function (com_obj.function3) will not work unless I give proper pointers in IronPython describing SAFEARRAY** (array of strings?). I have struggled for weeks with this issue - and researching the internet turned up very little information - as IronPython is sparsely documented.
Any inputs on how I can get past these errors will be greatly appreciated.
I'm new to Julia and trying out some code I copied from this article. It's supposed to be a way to do object-oriented programming (i.e. classes) in Julia:
using Lathe.stats: mean, std
struct NormalDistribution{P}
mu::Float64
sigma::Float64
pdf::P
end
function NormalDistribution(x::Array)
pdf(xt::Array) = [i = (i-μ) / σ for i in xt]
return new{typeof(pdf)}(mean(x), std(x), pdf)
end
x = [5, 10, 15, 20]
dist = NormalDistribution(x)
However, when I run this with Julia 1.1.1 in a Jupiter notebook I get this exception:
UndefVarError: new not defined
Stacktrace:
[1] NormalDistribution(::Array{Int64,1}) at ./In[1]:11
[2] top-level scope at In[1]:15
I found this documentation page on inner constructor methods which explains that they have
a special locally existent function called new that creates objects of the block's type.
(although the documentation for new linked above says it is a keyword).
It's possible I may have copied the code incorrectly but maybe someone could explain how to implement what the original author was proposing in the article. Also, I don't know how to debug in Julia yet so any pointers appreciated.
What the documentation page you linked to means to say is that the new keyword only exists within inner constructors (as opposed to outer constructors).
So either you go for an outer constructor, in which case you want to use the default constructor in order to actually create your new instance:
using Statistics
# First the type declaration, which comes with a default constructor
struct NormalDistribution{P}
mu::Float64
sigma::Float64
pdf::P
end
# Another outer constructor
function NormalDistribution(x::Array)
μ = mean(x)
σ = std(x)
pdf(xt::Array) = [(i-μ) / σ for i in xt]
# This is a call to the constructor that was created for you by default
return NormalDistribution(μ, σ, pdf)
end
julia> x = [5, 10, 15, 20]
4-element Array{Int64,1}:
5
10
15
20
julia> dist = NormalDistribution(x)
NormalDistribution{var"#pdf#2"{Float64,Float64}}(12.5, 6.454972243679028, var"#pdf#2"{Float64,Float64}(12.5, 6.454972243679028))
julia> dist.pdf([1, 2, 3])
3-element Array{Float64,1}:
-1.781572339255412
-1.626653005407115
-1.4717336715588185
Note that the definition of pdf in the original article is obviously problematic (if only because μ and σ are not defined). I tried to modify it so that it makes some sense
One possible issue with this is that anyone can define a NormalDistribution instance with an inconsistent state:
julia> NormalDistribution(0., 1., x->x+1)
NormalDistribution{var"#11#12"}(0.0, 1.0, var"#11#12"())
Which is why you might want to actually define an inner constructor, in which case Julia does not provide you with a default constructor but you get access to that special new function which creates objects of the type you're defining:
# A type declaration with an inner constructor
struct NormalDistribution2{P}
mu::Float64
sigma::Float64
pdf::P
# The inner constructor is defined inside the type declaration block
function NormalDistribution2(x::Array)
μ = mean(x)
σ = std(x)
pdf(xt::Array) = [(i-μ) / σ for i in xt]
# Use the `new` function to actually create the object
return new{typeof(pdf)}(μ, σ, pdf)
end
end
It behaves exactly in the same way as the struct with an outer constructor, except this time no default constructor is provided anymore:
julia> dist2 = NormalDistribution2(x)
NormalDistribution2{var"#pdf#5"{Float64,Float64}}(12.5, 6.454972243679028, var"#pdf#5"{Float64,Float64}(12.5, 6.454972243679028))
julia> dist2.pdf([1, 2, 3])
3-element Array{Float64,1}:
-1.781572339255412
-1.626653005407115
-1.4717336715588185
# No default constructor provided
julia> NormalDistribution2(0., 1., x->x+1)
ERROR: MethodError: no method matching NormalDistribution2(::Float64, ::Float64, ::var"#9#10")
Stacktrace:
[1] top-level scope at REPL[13]:1
An inner constructor has to be defined inside of the struct definition body; this is the only place where new has any special meaning. Your constructor method is outside of the struct definition where new is just a regular (undefined) name.
Ok. Looks like you were very confused. So that function is meant to be included as an inner constructor to the outer constructor before the end. The problem is the code is divided and built upon slowly across the article where only parts of the whole constructor are shown. If you are interested, and like my blog, I am about to post a video on outer constructors and inner constructors on my channel, https://youtube.com/playlist?list=PLCXbkShHt01seTlnlVg6O7f6jKGTguFi7 , it will be part 9 ( I am editing it now,) maybe watching this in video form will make it make more sense.
enter image description here
I understand that Python does not explicitly support private variables in a class. However, please consider the following program:
class AClass(object):
def __init__(self, x):
self.__x = x
class BClass(object):
def __init__(self, x):
self.__x = x
# _____________________________________________________________________________
aClass = AClass(10)
bClass = BClass(10)
aClass.__x = 15
print (aClass.__x)
##bClass.__x = 20
print (bClass.__x)
The program above, will produce following error:
AttributeError: 'BClass' object has no attribute '__x'
But, if the second last line of code is uncommented, it will execute without an error.
If someone can please clarify what appears to be an inconsistency and if there is a PEP that explains this behaviour, I would appreciate a pointer to it.
Best regards.
BD
It's because variables starting with a dunder are name mangled to "protect" them. If you examine the dictionary of bClass, you'll see:
>>> print(bClass.__dict__)
{'_BClass__x': 10, '__x': 20}
The _BClass__x (I'll call this the object variable) was created by the object itself, hence its mangled name. The __x was created outside of the class(a) which is why it has a non-mangled name, and therefore why you can access it with just __x.
To access the object variable for both types, you can use:
print (aClass._AClass__x)
print (bClass._BClass__x)
But I'm not sure how reliable that is. I am sure that it's something you probably shouldn't be doing however, since it breaks encapsulation :-)
In fact, though I said the mangling was done by the object, I want to make sure you understand it's not done when an object is instantiated. The actual mangling happens when the code is compiled, which you can see if you disassemble:
>>> import dis
>>> dis.dis(AClass)
Disassembly of __init__:
3 0 LOAD_FAST 1 (x)
2 LOAD_FAST 0 (self)
4 STORE_ATTR 0 (_AClass__x)
6 LOAD_CONST 0 (None)
8 RETURN_VALUE
The STORE_ATTR bytecode actually knows to use a mangled name.
(a) And it is very much distinct from the object variable, as you'll find to your distress when you later try to use __x within a member function and find it hasn't been changed by your code outside :-)
Before posting, I read more than a half dozen posts in a search from this site (python variables class static instance local)
https://stackoverflow.com/search?q=python+variables+class+static+instance+local
I bookmarked several of the results for future studying, but none of them seemed to clarify to me if my thinking is right or wrong, so I feel I may be missing something about the basics (see below)...
Are the terms 'class variable' and 'static variable' referring to the same thing? After about three Google searches, reading through ~6 articles per search that I could understand, I've reached a conclusion that class and static variables are the same thing. But, since I'm just learning the fundamentals of Python and OOP, this conclusion may be wrong so I want to find any flaws in my reasoning before I continue learning with the wrong mindset. In the code below:
class Variables():
scVar = 3
def __init__(self, a, b):
self.iVar1 = a
self.iVar2 = b
def getLocalVar3(self):
localVar1 = 17
localVar2 = 100
localVar3 = localVar1 + localVar2
return localVar3
Is 'scVar' both a class variable and a static variable ('class' and 'static' variables being synonymns)?
The second question is to clarify my understanding of differentiating class variables, instance variables, and local variables. In the code above, I'm thinking that scVar is a class variable; iVar1 and iVar2 are instance variables; and localVar1, localVar2, and localVar3 are local variables. Is that correct to say, or is there something that I'm missing?
Thanks cirosantilli, That article that you linked to is one I haven't seen yet. I'm going to look that over. I wonder a bit about Python's point of vew that there's not a distinction between class variables and instance variables. Is this point of view one that I should try to understand correctly right up front, as a beginner, or should I just keep the idea in mind and not worry too much about reconciling my current point of view with that one until I become more experienced? That question probably seems overly vague, and dependent upon my current level of understanding Python. Mostly, I've been running commands on class examples similar to what is in the original post; predicting the output before I press the [enter] key and then studying the output when it's not what I predicted. From that, I'm starting to get some grasp of how things work in Python. Basically, I've just recently started getting a glimpse of how OO works in Python - inching forward, slowly but surely.
"However the above are just conventions: from the language point of view there is no distinction between class variables and instance variables." -- Just to help me understand this better, does the part, 'from the language point of view ...' sort of imply that the Python documentation explains this point of view somewhere within it? If so, I'll re-read through the docs and look specifically for this part, and try to conform my thinking process to it. "... between class variables and instance variables." So, even though there's the difference in the way that class and instance variables can be seen and accessed by 'classobj's and 'instance's, Python's
point of view is that there is no distinction between them? I'm going to keep this idea in mind during future reading so that I can maybe get rid of some confusion on my part. After I run the *.py in the original post, I get the following outputs in IDLE, using Python 2.7.x (only the last line of the traceback error is included, for better readability):
>>> Variables.scVar
3
>>> Variables.iVar1
AttributeError: class Variables has no attribute 'iVar1'
>>> instance = Variables(5, 15)
>>> instance
<__main__.Variables instance at 0x02A0F4E0>
>>> Variables
<class __main__.Variables at 0x02A0D650>
>>> instance.scVar
3
>>> instance.iVar1
5
>>> instance2 = Variables(25, 35)
>>> instance2.scVar
3
>>> Variables.scVar = Variables.scVar * 100
>>> Variables.scVar
300
>>> instance.scVar
300
>>> instance2.scVar
300
>>> instance.scVar = 9999
>>> Variables.scVar
300
>>> instance.scVar
9999
>>> instance2.scVar
300
>>> type(Variables)
<type 'classobj'>
>>> type(instance)
<type 'instance'>
"However the above are just conventions: from the language point of view there is no distinction between class variables and instance variables." -- By using the code from the original post, is there maybe a sequence of commands that illustrates this point? I don't doubt that you know what you're talking about; I just find it difficult to reconcile my current way of thinking with the above statement. But I get the feeling that if I can start to see the difference between the two perspectives, that something important will 'click'.
As an afterthought to the last few sentences, I might be on to seeing things more along the same lines as your statement about 'no distinction between class variables and instance variables', but only if my following assumption is accurate... From the code in the original post (class Variables - 12 lines), are there just the two scopes of global and local involved in that program? Since I've just started to form conclusions about how it all fits together, I think that my limited understanding of scope might be what keeps me from fully grasping the idea that there's no distinction between class variables and instance variables. The only thing I can seem to make of it now is that (only maybe) - 'Python has no distinction between class variables and instance variables; but the differences between global and local scope might make it appear to a novice that there is a distinction between these two types of variables. I don't know, does that statement identify a potential 'hang up' that I could be having about it?
"Everything is an object, including classes and integers:" -- I've read this numerous times. So much so that I take it to be a core belief to understanding OO and Python, but it's not a concept in which I fully realize the implications of yet (I think).
class Foo():
integer = 10
float = 6.37
string = 'hello'
boolean = True
idkyet = None
def __init__(self):
self.a = 'iv_a'
self.b = 'iv_b'
self.c = 'iv_c'
def Func(self):
self.g = 'g'
h = 'h'
i = 'i'
return 'g' + 'h' + 'i'
>>> Foo
<class __main__.Foo at 0x02A1D650>
>>> type(Foo.integer)
<type 'int'>
>>> type(Foo.float)
<type 'float'>
>>> type(Foo.string)
<type 'str'>
>>> type(Foo.boolean)
<type 'bool'>
>>> type(Foo.idkyet)
<type 'NoneType'>
>>> type(Foo)
<type 'classobj'>
>>> import os
>>> type(os.getcwd() + '\\Test.py')
<type 'str'>
>>> type(os)
<type 'module'>
>>> f = Foo()
>>> type(f)
<type 'instance'>
>>> type(f.Func)
<type 'instancemethod'>
>>> type(f.Func())
<type 'str'>
>>> f.Func
<bound method Foo.Func of <__main__.Foo instance at 0x02A25AF8>>
>>> Foo.Func
<unbound method Foo.Func>
>>> type(f.a)
<type 'str'>
>>> type(Foo.a)
AttributeError: class Foo has no attribute 'a'
>>> type(Foo.self.a)
AttributeError: class Foo has no attribute 'self'
When I was about half way through this response, leaving off with the 'class Foo():' code above and the commands ran on it below that, I hit a snag and couldn't quite continue with the other follow-up question that I barely had in mind. So, I stepped away from the problem for awhile and started to read that 'cafepy...' link that you posted (by Shalabh Chaturvedi). That's really interesting. I had seen excerpts from that before but I hadn't read the whole thing, but it seems much more understandable now than it would have been just a week ago. I think I will read the whole thing. Don't mind the last half of this post (after the '***') because I still can't pinpoint exactly what I was trying to ask. ...everything is an object...mainly just a difference in object types???... < That is the note that I had jotted down when I almost had in mind how to frame the last question, but it never came to fruition. I'll have to wait until something else 'clicks' and I can see again what I had in mind.
I'll also keep in mind to stop and re-read if I glance across anything related to 'MRO', bound and unbound methods... I have been picking up just a bit of those three terms lately, in a way that it feels like they won't be too far in the future of my learning process.
I believe that static and class variables are commonly used as synonyms.
What you say about the variables is correct from the convention point of view: this is how you should think about them most of the time.
However the above are just conventions: from the language point of view there is no distinction between class variables and instance variables.
Python is not like C++ or Java.
Everything is an object, including classes and integers:
class C(object): pass
print id(C)
C.a = 1
assert C.__dict__['a'] == 1
There is no clear distinction between methods and instance variables: they are just attributes of an object.
Therefore, there is no language level distinction between instance variables and class variables: they are just attributes of different objects:
instance variables are attributes of the object (self)
class variables are attributes of the Class object.
The real magic happens on the order that the . operator searches for attributes:
__dict__ of the object
__dict__ of the class of the object
MRO up to parent classes
You should read this great article before you get confused in the future.
Also beware of bound vs unbound methods.
EDIT: attempt to address further questions by the OP made in his post.
Wow that was large! I'll try to read everything, but for the future you should try to keep questions more concice. More code, less talk =). You'll get better answers.
should I just keep the idea in mind and not worry too much about reconciling my current point of view with that one until I become more experienced?": I do things.
I do as I feel necessary. When necessity calls, or I can't take magic behaviour anymore, I learn.
sort of imply that the Python documentation explains this point of view somewhere within it?
I don't know about the docs, but the language itself works that way.
Of course, the language was designed to give the impression that syntax works just like in C++ in the common cases, and it adds a thin layer of magic to classes to make it look like so.
But, since that is not how it truly works, you cannot account for all (useful) behaviour by thinking only in terms of C++ class syntax.
By using the code from the original post, is there maybe a sequence of commands that illustrates this point?
I'm not sure it can be illustrated in sequence of commands. The point is: classes are objects, and their attributes are searched by the dot . MRO on the same order as attributes of objects:
class C(object):
i_static = 0
def __init__(self):
self.i = 1
# i is in the __dict__ of object c
c = C()
assert c.__dict__['i'] == 1
assert c.i == 1
# dot finds i_static because MRO looks at class
assert c.__class__.__dict__['i_static'] == 0
assert c.i_static == 0
# i_static is in the __dict__ of object C
assert C.__dict__['i_static'] == 0
assert C.i_static == 0
# __eq__ is in the dict of type, which is the __class__ of C
# By MRO, __eq__ is found. `C,C` because of bound vs unbound.
assert C.__class__.__dict__['__eq__'](C,C)
assert C == C
are there just the two scopes of global and local involved in that program?
This is a point I don't know very clearly.
There is a no global scope in Python, only module level.
Then there is a new local scope inside functions.
The rest is how the . looks for attributes.
can't pinpoint exactly what I was trying to ask
Ask: can I find a difference in syntax between classes, integers or functions?
If you think you have found one, ask: hmmm, how can I make an object with certain attributes that behaves just like that thing which does not look like an object?
You should find an answer every time.
Example:
def f(): pass
class C(object): pass
AHA: f is different than c = C() because I can do f() but notc()`!
But then, no, it is just that the f.__class__.__dict__['__call__'] attribute is defined for f, and can be found via MRO.
But we can do that for c too:
class C(object):
def __call__(self): pass
and now we can do c().
So they were not different in that aspect.
Scala's Option class has an orNull method, whose signature is shown below.
orNull [A1 >: A](implicit ev : <:<[Null, A1]) : A1
I'm bewildered by the implicit thing. Would somebody please explain how it can be used, ideally with an example?
scala> Some(1).orNull
<console>:10: error: could not find implicit value for parameter ev: <:<[Null,Int]
Some(1).orNull
^
scala> (None : Option[Int]).orNull
<console>:10: error: could not find implicit value for parameter ev: <:<[Null,Int]
(None : Option[Int]).orNull
scala> Some("hi").orNull
res21: java.lang.String = hi
scala> Some(null : String).orNull
res22: String = null
scala> (None : Option[String]).orNull
res23: String = null
To explain the implicit thing: orNull is a way of getting back from the Some|None idiom to Java's value|null idiom (which is, of course, bad). Now only AnyRef values (instances of classes) can accept a null value.
So what we would have liked is def orNull[A >: Null] = ..... But A is already set and we don't want to restrict it in the definition of the trait. Therefore, orNull expects an evidence that A is a nullable type. This evidence is in the form of an implicit variable (hence the name 'ev')
<:<[Null, A1] can be written as Null <:< A1 seeing it like this, it is similar to 'Null <: A1'. <:< is defined in Predef as well as the method that provides the implicit value named conforms.
I think the use of A1 is not strictly required here and is because orNull uses getOrElse (where the default given can be a super type of A)
scala> class Wrapper[A](option: Option[A]) {
| def orNull(implicit ev: Null <:< A): A = if(option.isEmpty) null else option.get
| }
defined class Wrapper
scala> new Wrapper(Some("hi")).orNull
res18: java.lang.String = hi
orNull purpose is first of all in ensuring compatibility of Option with Java. Though usage of null is discouraged in Scala, some interfaces may expect to get nullable references.
orNull has a straightforward implementation:
def orNull[A1 >: A](implicit ev: Null <:< A1): A1 = this getOrElse null
According to this, null will be returned not only for boxed nulls (Some(null)), but also for None (e.g., if you call None.get, exception will be thrown).
Implicit parameter checks, if the boxed value is nullable.
Good usage example can be found right in the comments to orNull:
val initialText: Option[String] = getInitialText
val textField = new JComponent(initialText.orNull,20)
Remember that in Scala primitive types and reference types are unified - but only reference types are nullable. The implicit simply allows the compiler to confirm that A1 is a reference type.
To understand why it is useful, IttayD provided a nice explanation:
So what we would have liked is def
orNull[A >: Null] = ..... But A is
already set and we don't want to
restrict it in the definition of the
trait. Therefore, orNull expects an
evidence that A is a nullable type.
This evidence is in the form of an
implicit variable (hence the name
'ev')
In summary, type constraints are useful when you want have methods (eg orNull) on a generic class (eg Option) with more specific constraints (eg Null <: A <: Any) than on the class itself (eg A <: Any).
This is another "feature" that is not built into the language but comes for free thanks to implicit parameters and variance annotations of type parameters. To understand this, look at the definition of <:<:
// from Predef
sealed abstract class <:<[-From, +To] extends (From => To)
implicit def conforms[A]: A <:< A = new (A <:< A) {def apply(x: A) = x}
For
scala> Some(1).orNull
<console>:10: error: could not find implicit value for parameter ev: <:<[Null,Int]
Some(1).orNull
the compiler looks for an implicit value of type <:<[Null, Int] and will find the method def conforms[A]: A <:< A. So there has to be an A for which <:<[A, A] conforms to <:<[Null, Int]. There is no A for which this holds and as a result the compiler will complain about the missing implicit value.
However, for
scala> Some("hi").orNull
res21: java.lang.String = hi
we are lucky. Now, the compiler tries to find an A for which <:<[A, A] conforms to <:<[Null, String]. This works for A = String, because Null is a subtype of String and the From type parameter of the class <:< is defined as contravariant).
As mentioned, the most intuitive way to think about type constraints is reading it like a type bound (i.e. reading it as Null <: Int). Null does not conform to Int and there is no implicit value for <:<[Null, Int]. On the other hand, Null does conform to String and the compiler will find the implicit parameter.
By the way, here is another related answer.
Re : 'how' is this used - one place we are finding this useful is when dealing with java api mappings where null is commonplace, e.g. on jdbc prepared statements to nullable sql columns. The Optional internal model fields can be mapped:
stmt.setDate("field", myModel.myDateField.orNull)
Instead of the more verbose:
stmt.setDate("field", myModel.myDateField.getOrElse(null))