Vyper: Can't pass a literal to a `bytes32` variable?

Created on 19 Nov 2018  路  2Comments  路  Source: vyperlang/vyper

Version Information

  • vyper Version: 0.1.0b4

What's your issue about?

I could pass literals to bytes[n] types but couldn't to bytes32 .

@public
def test():
    # Compiled!
    # l: bytes[32] = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\xac\x58\xcd"

    # Compiled!
    # l: bytes[4] = "\x00\x00\x00\x00"

    # Failed    
    l: bytes32 = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\xac\x58\xcd"

Error message (with vyper-serve ) is the below.

----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 51879)
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/socketserver.py", line 647, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/socketserver.py", line 357, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/socketserver.py", line 717, in __init__
    self.handle()
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/server.py", line 426, in handle
    self.handle_one_request()
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/server.py", line 414, in handle_one_request
    method()
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/EGG-INFO/scripts/vyper-serve", line 66, in do_POST
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/EGG-INFO/scripts/vyper-serve", line 89, in _compile
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/compiler.py", line 44, in mk_full_signature
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/compiler.py", line 27, in gas_estimate
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/parser.py", line 794, in parse_to_lll
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/parser.py", line 224, in parse_tree_to_lll
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/parser.py", line 172, in parse_other_functions
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/parser.py", line 530, in parse_func
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/parser.py", line 530, in <listcomp>
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/parser.py", line 547, in parse_body
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/parser.py", line 601, in parse_stmt
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/stmt.py", line 76, in __init__
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/stmt.py", line 150, in ann_assign
  File "/Users/ryuya.nakamura/work/vyper/venv/lib/python3.7/site-packages/vyper-0.1.0b4-py3.7.egg/vyper/parser/stmt.py", line 105, in _check_valid_assign
AttributeError: 'ByteArrayType' object has no attribute 'typ'
----------------------------------------

Cute Animal Picture

image

bug

Most helpful comment

Starting on this. I think support for string & non-string notation literals should be allowed. As both are equally readable. However I will force the string to be 32 byte size in all scenarios, because of left/right padding it can be confusing if we don't enforce 32 byte size.

All 2 comments

@nrryuya To add to this I'm not which parts of this are a bug with language implementation vs. bug in the language documentation.

Passing the same byte32 as a literal this way compiles fine:

@public
def test():
    # Compiled!
    foo: bytes[32] = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\xac\x58\xcd"

    # Compiled!
    bar: bytes[4] = "\x00\x00\x00\x00"

    # Failed (though this may be expected)
    # l: bytes32 = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\xac\x58\xcd"

    # Compiled!
    foobar: bytes32 = 0x0000000000000000000000000000000000000000000000000000000080ac58cd

However, the docs do list the default bytes32 value as being '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', which makes it seem like one should use the syntax you used.

Also, my intuition would be to expect the syntax to be the same for bytes and bytes32. It would seem to me that for byte literals of both bytes and bytes32 types we may actually want to use the syntax of b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\xac\x58\xcd" with the b prepended, as it is more Pythonic?

Starting on this. I think support for string & non-string notation literals should be allowed. As both are equally readable. However I will force the string to be 32 byte size in all scenarios, because of left/right padding it can be confusing if we don't enforce 32 byte size.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

vici0 picture vici0  路  3Comments

lsaether picture lsaether  路  4Comments

denis-bogdanas picture denis-bogdanas  路  3Comments

ben-kaufman picture ben-kaufman  路  4Comments

jacqueswww picture jacqueswww  路  3Comments