Updates the reserved_name list.

WARNING. This has the potential to break a lot of existing code if there is code using existing members with reserved names, e.g. see the tests that were modified using input and type.

Not sure what to do about it...

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

Codecov Report

Merging #208 into master will not change coverage. The diff coverage is 100%.

@@          Coverage Diff           @@
##           master    #208   +/-   ##
======================================
  Coverage    70.2%   70.2%           
======================================
  Files           7       7           
  Lines        1658    1658           
  Branches      457     457           
======================================
  Hits         1164    1164           
  Misses        369     369           
  Partials      125     125

Impacted Files	Coverage Δ
pyangbind/lib/yangtypes.py	83.33% <100%> (ø)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update bcb1d86...ad7fa36. Read the comment docs.

To be fair, I think the reserved names really only matter for top-level (e.g. when you are importing a yang module that happens to be called input or long) so perhaps we could be more permissive by changing the implementation. However, I thought I'd create this patch anyway as a talking point as I encountered this issue with a yang I was working with.

Thanks for the contribution!

I don't think all the entries in this are equally syntactically problematic. For example:

class test(object):
  as  = 1

will always throw an error, as is reserved. import falls into the same category.

However, a number of other entries all, abs, basestring etc, don't throw the same error, i.e.:

class test(object):
    abs = ""
    all = ""
    any = ""
    apply = ""
    ascii = ""
    bin = ""
    basestring  = ""

works just fine. Equally, I can call a module abs and not have an issue (yes, there is a name collision, but it is not a interpreter error).

To your second comment, I think that there is an issue if we have a module called import, but not an issue if we have one called long. Can you provide a bit more colour on what the problem is here before we make a change that is going to affect multiple consumers please?

Thanks! r.

An example of long causing an issue:

if six.PY3:
  long = int

from . import long

class timeout(PybindBase):
  def __init__(self, *args, **kwargs):
    self.__long = YANGDynClass(base=long.long, is_container='container', yang_name="long", ..., is_config=True)

Here the base=long.long throws an error because we have long as a built-in type.

This yang is from a vendor for some timeout (LACP perhaps?).. this is literally the first yang I have tried :D lucky.. but I wonder how many more potential conflicts I'll find.. (hence I've created this issue)

CLAs look good, thanks!

Ah, I see.

I think the key thing to deal with here would be where it might become a module name -- this means any container or list, and probably only impacts split-class-dir output. The reserved_name is generically used everywhere right now, so I think we would want to split that function out and have these used in different contexts.

Thoughts?

Hi,

Could you please rebase to a recent versions of pyangbind ?

So far, pyangbind has been running the current list of reserved words... I think the discussion about splitting the reserved-words check must be in an issue and not a PR.

Closing old issue.