[Soap-Python] Pulling my branch

[burak.arslan at arskom.com.tr]

 On Thu, 9 Dec 2010 15:05:01 -0600, Brad Allen <bradallen137 at gmail.com> 
 wrote:
> Folks, this is the time for changes that break backward 
> compatibility.
> Since we have not yet released 2.0 beta, there is still time to get 
> in
> those kinds of changes. After the 2.0 beta release, changes that 
> break
> backward compatibility should be deferred to the next major release
> (3.0).
>
> I'm all in favor of getting rid of the unnecessary underscores in
> parameter names; those are supposed to be used for private methods, 
> so
> I don't see how they make sense for keyword parameters. Maybe someone
> with greater historical perspective could chime in an explain the
> thinking?
>

 _returns and its ilk have an underscore because they are considered to 
 be keywords with special meanings. i think the plan was to have

 @rpc(some_param=String, some_other=Double, _returns=SomeClass)
 def my_function(**kwargs):

 in an effort to avoid duplication in definitions. you can still do it, 
 i think it looks nice.

 burak



> Also, for the __attributes__, those are generally reserved for Python
> itself, right? A lot of framework developers use them but I don't
> think it's a good idea, and not in keeping with PEP 8.
>
>>From PEP 8, the Python Style Guide at 
>> http://www.python.org/dev/peps/pep-0008/
>
> - __double_leading_and_trailing_underscore__: "magic" objects or
>       attributes that live in user-controlled namespaces.  E.g. 
> __init__,
>       __import__ or __file__.  Never invent such names; only use them
>       as documented.
>
> On Thu, Dec 9, 2010 at 2:48 PM, Chris Austin <chris at sydneysys.com> 
> wrote:
>> On Thu, Dec 9, 2010 at 2:14 PM, Tres Seaver <tseaver at palladion.com> 
>> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 12/09/2010 12:18 PM, Chris Austin wrote:
>>>
>>> > For some reason I didn't get an email for the pull request.  Give 
>>> me a
>>> > little bit and I'll take a look at it.
>>>
>>> Thanks for merging it!  I've got more changes coming, some of which 
>>> need
>>> some discussion:
>>>
>>> 1. I want method descriptors to keep the list of faults passed to 
>>> the
>>>   'rpc' decorator.  I have this one working already.
>>>
>>
>> This would be fine with me.  While we are at it, is everybody fine 
>> with
>> dropping the single underscore from the decorator for items like 
>> _returns?
>> I am asking because I am in the mist of a huge overhaul for the wsdl 
>> engine
>> along with some supporting changes to the rpc decorator.
>>
>>>
>>> 2. I want to emit the WSDL for faults of operations:  types, 
>>> messages,
>>>   and parts.  I'm part way hacking through this.  AFAICT, 
>>> application-
>>>   defined faults are effectively unused:  for instance, calling
>>>   'fault.add_to_schema(schema_entries)' blows up because the 
>>> emitted
>>>   WSDL is broken.  Can anyone contradict me, here?  I.e., is anyone
>>>   using application-defined faults at all?
>>
>>  This sounds right with the new tests I have been writing around the 
>> wsdl
>> engine.  There are lots of other little issues like it  currently 
>> stuffing
>> all of the services into a single service named after the App .
>>
>>>
>>> 3. I want some way to suppress the wrapping of returned objects in
>>>   sequences (see issue 4,
>>>   https://github.com/soaplib/soaplib/issues#issue/4).  I'm thinking
>>>   of maybe spelling that as a '_returns_direct' argument to 
>>> 'rpc()'.
>>>
>>>   For my enlightenment:  does anybody know the rationale for adding 
>>> the
>>>   sequence wrapper?
>>
>> I can't comment on the historical decisions however; I just don't 
>> know but I
>> can make up stuff if needed :)
>> This  sounds fine with me.  Let's think about dropping the 
>> underscore on
>> the parameter however.  Does anybody have an objection for altering 
>> the
>> syntax in the rpc decorator slightly
>> currently -> @rpc(String, Integer, Double, ..., _returns=String)
>> proposed -> @rpc(String, Integer, Double, ..., _returns=String)
>>
>> Also, I'd like to modify the way the instances of ClassSerializer 
>> declare
>> class attributes by dropping the double underscore.
>> for example currently things look like this:
>> class MyModel(ClassSerializer):
>>     __namespace__ = 'foo'
>> I'd like to make it cleaner like so:
>> class MyModel(ClassSerializer):
>>     namespace = 'foo'
>>
>> Also, to properly support ports and separate services I am
>> currently finishing tests for adding  'ports' and 
>> 'service_interface'
>> attributes to DefinitionBase along with a 'port' attribute for the
>> 'rpc' decorator.
>> If no one objects I'll drop the (in my 
>> opinion) superfluous underscores.
>> Cheers
>>
>>
>>>
>>> Tres.
>>> - --
>>> ===================================================================
>>> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
>>> Palladion Software   "Excellence by Design"    http://palladion.com
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk0BOJcACgkQ+gerLs4ltQ7dRwCghFeR3QxWHU0Q37bzzuPd7kao
>>> PBsAn2UEl204jYfghXHEmfM4z5LTxHK5
>>> =YuNZ
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> Soap mailing list
>>> Soap at python.org
>>> http://mail.python.org/mailman/listinfo/soap
>>
>>
>> _______________________________________________
>> Soap mailing list
>> Soap at python.org
>> http://mail.python.org/mailman/listinfo/soap
>>
>>
> _______________________________________________
> Soap mailing list
> Soap at python.org
> http://mail.python.org/mailman/listinfo/soap