[PATCH] gnu: Rename python-hy to hy.

OpenSubmitted by Jesse Gibbons.
Details
3 participants
  • Brett Gilio
  • Jesse Gibbons
  • zimoun
Owner
unassigned
Severity
normal
J
J
Jesse Gibbons wrote on 21 Jul 2020 08:09
(name . Guix Patches)(address . guix-patches@gnu.org)
b02f8a5b-a047-6062-2396-c15f49fd21cd@gmail.com
* gnu/packages/python-xyz.scm: (python-hy): Rename to hy.
---
gnu/packages/python-xyz.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

Toggle diff (15 lines)
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 748f48f229..e1b16f9c23 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -9961,9 +9961,9 @@ with a new public API, and RPython support.")
(define-public python2-rply
(package-with-python2 python-rply))
-(define-public python-hy
+(define-public hy
(package
- (name "python-hy")
+ (name "hy")
(version "0.18.0")
(source (origin
(method url-fetch)
J
J
Jesse Gibbons wrote on 21 Jul 2020 21:26
(address . 42456@debbugs.gnu.org)
1dc02d59-c67b-2002-6a99-ceb0cdc24645@gmail.com
I initially created this patch thinking hy is primarily an application.
I brought this up in the IRC, and was told to send it and discuss it here.
B
B
Brett Gilio wrote on 25 Jul 2020 03:13
Re: [bug#42456] [PATCH] gnu: Rename python-hy to hy.
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)(address . 42456@debbugs.gnu.org)
87a6zo5rdq.fsf@gnu.org
Jesse Gibbons <jgibbons2357@gmail.com> writes:

Toggle quote (4 lines)
> I initially created this patch thinking hy is primarily an
> application. I brought this up in the IRC, and was told to send it and
> discuss it here.

Hi Jesse,

I think if we rename Hy (and subsequently break the python-* naming
convention) we should justify moving Hy perhaps to its own module. I am
not overly familiar with Hy, I know that it uses and is compatible with
Python libraries (as Hy is mostly just sugar on-top of the Python
runtime) but do Hy-specific libraries exist? If so, I think that would
make the case for moving Hy to its own module even stronger.

Brett Gilio
J
J
Jesse Gibbons wrote on 25 Jul 2020 17:44
(name . Brett Gilio)(address . brettg@gnu.org)(address . 42456@debbugs.gnu.org)
08f72489-fb0b-c367-ff9e-6cb3beb4e127@gmail.com
Though I do not know much about hy, I do know the following:

- There are some libraries written in hy[0].

- There are tools written in hy specifically designed to handle hy.[1]

- Some hy libraries contain macros that I don't think compile into
python. It looks at first glance like hyclib[2] and hyiter[3] are
examples of such packages, though I have not confirmed.

- The libraries and programs I have found written in hy look like they
would use python-build-system. If we see patterns in defining these
packages, we can always provide a hy-build-system for convenience.





On 7/24/20 7:13 PM, Brett Gilio wrote:
Toggle quote (5 lines)
> we should justify moving Hy perhaps to its own module. I am
> not overly familiar with Hy, I know that it uses and is compatible with
> Python libraries (as Hy is mostly just sugar on-top of the Python
> runtime) but do Hy-specific libraries exist? If so, I think that would
> make the case for moving Hy to its own module even stronger.
Z
Z
zimoun wrote on 27 Jul 2020 16:40
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)
CAJ3okZ12ycS30TNoCN6hUemRoj+SG4pZqkZzW9EMDzCS9GW-hQ@mail.gmail.com
Dear,

On Sat, 25 Jul 2020 at 17:45, Jesse Gibbons <jgibbons2357@gmail.com> wrote:
Toggle quote (11 lines)
>
> Though I do not know much about hy, I do know the following:
>
> - There are some libraries written in hy[0].
>
> - There are tools written in hy specifically designed to handle hy.[1]
>
> - Some hy libraries contain macros that I don't think compile into
> python. It looks at first glance like hyclib[2] and hyiter[3] are
> examples of such packages, though I have not confirmed.

Hy uses the Python VM. Basically, the Hy Lisp is transformed into an
AST (from ast import *) i.e. Python internals then evaluated using the
Python VM (CPython or PyPy).
Other said, any Hy code compiles to Python (and vice versa :-)).

Toggle quote (4 lines)
> - The libraries and programs I have found written in hy look like they
> would use python-build-system. If we see patterns in defining these
> packages, we can always provide a hy-build-system for convenience.

I do not think it makes sense having 'hy-build-system' because Hy uses
all the Python machinery, not to say Hy is simply Python with
parenthensis. ;-)
Other said, Python code can import Hy code, and vice versa, and not
because there is "bindings" but because it is the same AST
representation.

Last, I am not convinced that Hy deserves a rename since it is another
Python flavor. Well, similarly than python-on-guile which is in
gnu/packages/guile-xyz.scm


Cheers,
simon
J
J
Jesse Gibbons wrote on 28 Jul 2020 01:05
(name . zimoun)(address . zimon.toutoune@gmail.com)
d6d5bf12-7bbf-c5e0-ffb2-56c7da89bc7f@gmail.com
It seems you understand a lot more about Hy than I do (I've never
actually built a Hy app in my life, and I despise python (hence the
interest in Hy)), so I have some questions. I'm trying to clear up some
of my confusion.

On 7/27/20 8:40 AM, zimoun wrote:
Toggle quote (5 lines)
> Hy uses the Python VM. Basically, the Hy Lisp is transformed into an
> AST (from ast import *) i.e. Python internals then evaluated using the
> Python VM (CPython or PyPy).
> Other said, any Hy code compiles to Python (and vice versa :-)).

What about Hy macros? According to
changes to the program when imported with require. If I write a Hy
library with nothing but useful macros, will python be able to use that?

When I call Hy2py on a Hy file with nothing but the sample macro at
error. Is this expected, or is this a guix-related bug? If this is
expected, then I think Hy macros are significantly more useful to Hy
than to python without the ast library, and if you want to use Hy macros
for parts of a python app you might as well use Hy.

Toggle quote (3 lines)
> I do not think it makes sense having 'hy-build-system' because Hy uses
> all the Python machinery, not to say Hy is simply Python with
> parenthensis. ;-)
As I mentioned, hy-build-system would just make things a little more
convenient. Programs written even partially in Hy will require the Hy
package, but I wouldn't bother hacking a new build system together
unless there are other things required for all Hy packages. Do such
things exist? If not, I will let it go.
Toggle quote (12 lines)
> Other said, Python code can import Hy code, and vice versa, and not
> because there is "bindings" but because it is the same AST
> representation.
>
> Last, I am not convinced that Hy deserves a rename since it is another
> Python flavor. Well, similarly than python-on-guile which is in
> gnu/packages/guile-xyz.scm
>
>
> Cheers,
> simon

Similar things can be said of Clojure. Clojure is compiled into Java
bytecode, then run on the Java VM. Java programs can run Clojure code,
and vice versa. And just like Clojure and Java, Hy and Python have very
different grammar and are therefore not the same language. Yet Clojure
is not packaged as java-clojure.

Though inconsistencies in naming conventions tend to bother me, I
personally am indifferent about what Hy is named. As the saying goes, "A
cactus by any other name would pop all the balloons you throw at it that
don't completely miss it." (Or something like that.) I only submitted
the patch because I had renamed python-hy to hy in my personal channel a
while ago, and the people on the IRC suggested I should send the change
as a patch when I mentioned it there recently. So if my patch is
accepted is up to those who are more familiar with Hy and Guix than I
am. I think the only time it will matter to me is if I am the first to
submit a package that requires Hy, since such a package will be written
for my channel and my channel won't be adjusted by then to build a
package dependent on hy.
Z
Z
zimoun wrote on 28 Jul 2020 04:17
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)
86k0yoz8m6.fsf@gmail.com
Dear,

On Mon, 27 Jul 2020 at 17:05, Jesse Gibbons <jgibbons2357@gmail.com> wrote:

Toggle quote (5 lines)
> What about Hy macros? According to
> https://docs.hylang.org/en/stable/language/api.html#require they make no
> changes to the program when imported with require. If I write a Hy
> library with nothing but useful macros, will python be able to use that?

Macros will be represented as HyExpression or something like that (I
have not checked now and I have not played with Hy since 2014 :-)). Say
an HyObject which then needs to be “compiled” into a Python AST, then
the Python AST is “compiled” to bytecode.


Or simply said:

What if you want to use a macro that’s defined in a different
module? import won’t help, because it merely translates to a
Python import statement that’s executed at run-time, and macros
are expanded at compile-time, that is, during the translation
from Hy to Python. Instead, use require, which imports the
module and makes macros available at compile-time. require uses
the same syntax as import.


Toggle snippet (16 lines)
$ hy --spy
=> (defmacro do-while [condition &rest body]
`(do
~body
(while ~condition
~body)))

from hy import HyExpression, HySymbol
import hy
hy.macros.macro('do-while')(lambda hyx_XampersandXname, condition, *body:
HyExpression([] + [HySymbol('do')] + [body] + [HyExpression([] + [
HySymbol('while')] + [condition] + [body])]))

<function do_while at 0x7f846ec80430>

Does it make sense?

Toggle quote (7 lines)
> When I call Hy2py on a Hy file with nothing but the sample macro at
> https://docs.hylang.org/en/stable/language/api.html#defmacro it gives an
> error. Is this expected, or is this a guix-related bug? If this is
> expected, then I think Hy macros are significantly more useful to Hy
> than to python without the ast library, and if you want to use Hy macros
> for parts of a python app you might as well use Hy.

Python and Hy are not one-to-one.

Hy also removes Python’s restrictions on mixing expressions and
statements, allowing for more direct and functional code. […]


So your problem hy2py seems expected. The macro is represented by a Hy
AST which cannot be compiled to Python AST.

However, note that “hy2py” is not bullet-proof because going from AST to
Python code is not straightforward.

Toggle snippet (24 lines)
$ echo "(defn f [n] (+ n 1))" | hy2py --with-ast -
Module(
body=[
FunctionDef(name='f',
args=arguments(posonlyargs=[],
args=[arg(arg='n', annotation=None)],
vararg=None,
kwonlyargs=[],
kw_defaults=[],
kwarg=None,
defaults=[]),
body=[Return(value=BinOp(left=Name(id='n'), op=Add, right=Constant(value=1)))],
decorator_list=[],
returns=None)

Traceback (most recent call last):
File "/gnu/store/b2cyhq822sywidaqnpg6kminvr34z9rq-python-hy-0.18.0/bin/.hy2py-real", line 12, in <module>
sys.exit(hy2py_main())
[...]
File "/gnu/store/i7bq751zql0vw1mb3x20k7fla9ilszwh-python-astor-0.7.1/lib/python3.8/site-packages/astor/op_util.py", line 102, in get_op_precedence
return precedence_data[type(obj)]
KeyError: <class '_ast.Constant'>

Well, it could also be a bug… :-)


Toggle quote (9 lines)
>> I do not think it makes sense having 'hy-build-system' because Hy uses
>> all the Python machinery, not to say Hy is simply Python with
>> parenthensis. ;-)
> As I mentioned, hy-build-system would just make things a little more
> convenient. Programs written even partially in Hy will require the Hy
> package, but I wouldn't bother hacking a new build system together
> unless there are other things required for all Hy packages. Do such
> things exist? If not, I will let it go.

From my point of point, Hy packages are just Python packages. For
instance, the 2 Hy libraries you mentioned are regular PyPI package,
installable with “pip”. Well, python-hy would be an implicit dependency
but AFAIK that’s all.


Toggle quote (6 lines)
> Similar things can be said of Clojure. Clojure is compiled into Java
> bytecode, then run on the Java VM. Java programs can run Clojure code,
> and vice versa. And just like Clojure and Java, Hy and Python have very
> different grammar and are therefore not the same language. Yet Clojure
> is not packaged as java-clojure.

I do not know well Clojure neither the Java ecosystem. But I think the
distribution of Clojure packages is a bit different than the
distribution of some other Java packages. The tools used to build are
not necessary the sames. Which is not the case for Hy: it uses “pip”
and/or the Python setuptools – it could have changed since I am not
following Hy very closely.


Toggle quote (13 lines)
> Though inconsistencies in naming conventions tend to bother me, I
> personally am indifferent about what Hy is named. As the saying goes, "A
> cactus by any other name would pop all the balloons you throw at it that
> don't completely miss it." (Or something like that.) I only submitted
> the patch because I had renamed python-hy to hy in my personal channel a
> while ago, and the people on the IRC suggested I should send the change
> as a patch when I mentioned it there recently. So if my patch is
> accepted is up to those who are more familiar with Hy and Guix than I
> am. I think the only time it will matter to me is if I am the first to
> submit a package that requires Hy, since such a package will be written
> for my channel and my channel won't be adjusted by then to build a
> package dependent on hy.

About the name, I am indifferent too. :-)
Well, it could be nice to split the big Python files. ;-)


All the best,
simon

ps:
Note that I said “Hy code compiles to Python (and vice versa :-))” which
is inaccurate; especially about the “vice versa”. ;-)
J
J
Jesse Gibbons wrote on 28 Jul 2020 06:50
(name . zimoun)(address . zimon.toutoune@gmail.com)
378c3b08-6311-8f33-5fb3-25266700b038@gmail.com
On 7/27/20 8:17 PM, zimoun wrote:
Toggle quote (45 lines)
> Dear,
>
> On Mon, 27 Jul 2020 at 17:05, Jesse Gibbons <jgibbons2357@gmail.com> wrote:
>
>> What about Hy macros? According to
>> https://docs.hylang.org/en/stable/language/api.html#require they make no
>> changes to the program when imported with require. If I write a Hy
>> library with nothing but useful macros, will python be able to use that?
> Macros will be represented as HyExpression or something like that (I
> have not checked now and I have not played with Hy since 2014 :-)). Say
> an HyObject which then needs to be “compiled” into a Python AST, then
> the Python AST is “compiled” to bytecode.
>
> https://docs.hylang.org/en/master/language/internals.html
>
> Or simply said:
>
> What if you want to use a macro that’s defined in a different
> module? import won’t help, because it merely translates to a
> Python import statement that’s executed at run-time, and macros
> are expanded at compile-time, that is, during the translation
> from Hy to Python. Instead, use require, which imports the
> module and makes macros available at compile-time. require uses
> the same syntax as import.
>
> https://docs.hylang.org/en/master/tutorial.html#macros
>
> --8<---------------cut here---------------start------------->8---
> $ hy --spy
> => (defmacro do-while [condition &rest body]
> `(do
> ~body
> (while ~condition
> ~body)))
>
> from hy import HyExpression, HySymbol
> import hy
> hy.macros.macro('do-while')(lambda hyx_XampersandXname, condition, *body:
> HyExpression([] + [HySymbol('do')] + [body] + [HyExpression([] + [
> HySymbol('while')] + [condition] + [body])]))
>
> <function do_while at 0x7f846ec80430>
> --8<---------------cut here---------------end--------------->8---
>
> Does it make sense?
Yes. Thank you for the explanation.
Toggle quote (60 lines)
>
>> When I call Hy2py on a Hy file with nothing but the sample macro at
>> https://docs.hylang.org/en/stable/language/api.html#defmacro it gives an
>> error. Is this expected, or is this a guix-related bug? If this is
>> expected, then I think Hy macros are significantly more useful to Hy
>> than to python without the ast library, and if you want to use Hy macros
>> for parts of a python app you might as well use Hy.
> Python and Hy are not one-to-one.
>
> Hy also removes Python’s restrictions on mixing expressions and
> statements, allowing for more direct and functional code. […]
>
> https://docs.hylang.org/en/master/whyhy.html
>
> So your problem hy2py seems expected. The macro is represented by a Hy
> AST which cannot be compiled to Python AST.
>
> However, note that “hy2py” is not bullet-proof because going from AST to
> Python code is not straightforward.
>
> --8<---------------cut here---------------start------------->8---
> $ echo "(defn f [n] (+ n 1))" | hy2py --with-ast -
> Module(
> body=[
> FunctionDef(name='f',
> args=arguments(posonlyargs=[],
> args=[arg(arg='n', annotation=None)],
> vararg=None,
> kwonlyargs=[],
> kw_defaults=[],
> kwarg=None,
> defaults=[]),
> body=[Return(value=BinOp(left=Name(id='n'), op=Add, right=Constant(value=1)))],
> decorator_list=[],
> returns=None)
>
> Traceback (most recent call last):
> File "/gnu/store/b2cyhq822sywidaqnpg6kminvr34z9rq-python-hy-0.18.0/bin/.hy2py-real", line 12, in <module>
> sys.exit(hy2py_main())
> [...]
> File "/gnu/store/i7bq751zql0vw1mb3x20k7fla9ilszwh-python-astor-0.7.1/lib/python3.8/site-packages/astor/op_util.py", line 102, in get_op_precedence
> return precedence_data[type(obj)]
> KeyError: <class '_ast.Constant'>
> --8<---------------cut here---------------end--------------->8---
>
> Well, it could also be a bug… :-)
>
>
>>> I do not think it makes sense having 'hy-build-system' because Hy uses
>>> all the Python machinery, not to say Hy is simply Python with
>>> parenthensis. ;-)
>> As I mentioned, hy-build-system would just make things a little more
>> convenient. Programs written even partially in Hy will require the Hy
>> package, but I wouldn't bother hacking a new build system together
>> unless there are other things required for all Hy packages. Do such
>> things exist? If not, I will let it go.
> >From my point of point, Hy packages are just Python packages. For
> instance, the 2 Hy libraries you mentioned are regular PyPI package,
> installable with “pip”. Well, python-hy would be an implicit dependency
> but AFAIK that’s all.
Ok. Then there's not enough difference to justify hy-build-system.
Toggle quote (13 lines)
>
>> Similar things can be said of Clojure. Clojure is compiled into Java
>> bytecode, then run on the Java VM. Java programs can run Clojure code,
>> and vice versa. And just like Clojure and Java, Hy and Python have very
>> different grammar and are therefore not the same language. Yet Clojure
>> is not packaged as java-clojure.
> I do not know well Clojure neither the Java ecosystem. But I think the
> distribution of Clojure packages is a bit different than the
> distribution of some other Java packages. The tools used to build are
> not necessary the sames. Which is not the case for Hy: it uses “pip”
> and/or the Python setuptools – it could have changed since I am not
> following Hy very closely.
>
I guess java isn't a good language to compare as far as build systems
go. There are several build systems commonly used for java, but there
are only one or two python build systems, and they all seem to work the
same way.
Toggle quote (23 lines)
>> Though inconsistencies in naming conventions tend to bother me, I
>> personally am indifferent about what Hy is named. As the saying goes, "A
>> cactus by any other name would pop all the balloons you throw at it that
>> don't completely miss it." (Or something like that.) I only submitted
>> the patch because I had renamed python-hy to hy in my personal channel a
>> while ago, and the people on the IRC suggested I should send the change
>> as a patch when I mentioned it there recently. So if my patch is
>> accepted is up to those who are more familiar with Hy and Guix than I
>> am. I think the only time it will matter to me is if I am the first to
>> submit a package that requires Hy, since such a package will be written
>> for my channel and my channel won't be adjusted by then to build a
>> package dependent on hy.
> About the name, I am indifferent too. :-)
> Well, it could be nice to split the big Python files. ;-)
>
>
> All the best,
> simon
>
> ps:
> Note that I said “Hy code compiles to Python (and vice versa :-))” which
> is inaccurate; especially about the “vice versa”. ;-)

You cleared up all my confusion. Thank you.

-Jesse
Z
Z
zimoun wrote on 28 Jul 2020 11:51
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)
867duoynl9.fsf@gmail.com
Dear,

Without going too far from the initial thread topic, Hy asks a good question.

Toggle quote (2 lines)
> Ok. Then there's not enough difference to justify hy-build-system.

The question is how to switch the Python VM and still keep consistent
packages. Well, related to this discussion:


And Hy could a nice test-case.


All the best,
simon
?