AttributeError: 'NoneType' object has no attribute 'enum_types_by_name'

[alfaro28]

What version of protobuf and what language are you using? Version: 4.21.1 Language: Python

What operating system (Linux, Windows, ...) and version? Linux

What runtime / compiler are you using (e.g., python version or gcc version) Docker python:3.8-slim

What did you do? I have an enum on a proto file

syntax = "proto3";

package commons;

enum OPTIONAL_BOOL {
  UNDEFINED = 0;
  TRUE = 1;
  FALSE = 2;
}

after upgrading to protobuf 4.21.1 (and upgrading the pb2 files) when the pb2 file is loaded, an error is shown

What did you expect to see Code runs normally

What did you see instead?

File "/usr/local/lib/python3.8/site-packages/myproject/commons/grpc/pb2/commons_pb2.py", line 20, in <module>
myproject_1  |     _OPTIONAL_BOOL = DESCRIPTOR.enum_types_by_name['OPTIONAL_BOOL']
myproject_1  | AttributeError: 'NoneType' object has no attribute 'enum_types_by_name'

Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).

Anything else we should know about your project / environment This worked with protobuf 3.20.1

[alfaro28]

seems like my issue was not specific to the "enums" but rather to importing the same file twice, for reasons specific to my project I was using the same file in different packages, and the seconds time it was imported it gave the error mentioned above. I managed to fix the issue importing the file only once, I don't know if it would be worth mentioning in the docs since this behavior is different on 3.20

[steve-gray]

Hi @alfaro28,

We're seeing this issue too - the code runs perfectly locally, but inside docker-ized version with the same code:

    _SOMEENUMTYPE = DESCRIPTOR.enum_types_by_name['SomeEnumType']
AttributeError: 'NoneType' object has no attribute 'enum_types_by_name'

When you say importing twice, I have two different packages in the project that need to use the proto contracts - and so I'm unable to avoid the double import. We're struggling to work around this at present.

EDIT: Understand now what people are on about. In essence you need to check your entire project for any places where the protogen'd files are being imported with different aliasing. We'd done this in some places, but when having the GRPC server side code, it references the contracts so that:

• Rest of code, loads the model as import contracts.something_pb2
• something_grpc_pb2 however was doing import something_pb2 locally.

We adjusted our sys.path manipulation to enable a consistent alias to be used across all import sites, and this seems to have appeased the Python gods.

[junchuanwang]

+1.

in my case I did double import. But interesetingly it works on my Mac and Linux. Failed on WIn10.

I have to downgrade to 3.20.x to make it work

[lujinke]

I also encounter this issue when importing phoneixdb:

>>> import phoenixdb
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dbops/dbtools/venv/lib/python2.7/site-packages/phoenixdb/__init__.py", line 19, in <module>
    from phoenixdb import errors, types
  File "/home/dbops/dbtools/venv/lib/python2.7/site-packages/phoenixdb/types.py", line 21, in <module>
    from phoenixdb.avatica.proto import common_pb2
  File "/home/dbops/dbtools/venv/lib/python2.7/site-packages/phoenixdb/avatica/__init__.py", line 16, in <module>
    from .client import AvaticaClient  # noqa: F401
  File "/home/dbops/dbtools/venv/lib/python2.7/site-packages/phoenixdb/avatica/client.py", line 27, in <module>
    from phoenixdb.avatica.proto import common_pb2, requests_pb2, responses_pb2
  File "/home/dbops/dbtools/venv/lib/python2.7/site-packages/phoenixdb/avatica/proto/common_pb2.py", line 36, in <module>
    _STATEMENTTYPE = DESCRIPTOR.enum_types_by_name['StatementType']
AttributeError: 'NoneType' object has no attribute 'enum_types_by_name'

Verion info: phoenixdb==1.2.1 protobuf==3.17.3

But it works on python 2.7.5(centos) and 2.7.16(mac) but throws this error on 2.7.18(centos). It's strange it works on the old python versions but not the new one.

[haberman]

The most recent release of protobuf Python (4.12.11) has fixed this bug, so I'm closing this issue.

Protobuf 3.17.3 is quite old at this point.

[stoty]

The 3.17.3 behaviour seems to be dependent on the implementation. I also had the phoenixdb problem above on a system that used the "python" implementation. Switching to the "cpp" implementation by installing the protobuf C library, and reinstalling protobuf from pip has fixed the issue.

see https://issues.apache.org/jira/browse/PHOENIX-6863 for more details.