Re: name 'sys' is not defined
[email protected] writes: > Deal all, > Could you please help me how can I avoid this problem > my Jupyter Notebook code was > help pls > > > > # init a treemix analysis object with some param arguments > tmx = ipa.treemix( > data=data, > imap=imap, > minmap=minmap, > seed=123456, > root="Petronia_petronia", > m=2, > ) > > error > > NameError Traceback (most recent call last) > in > 6 seed=123456, > 7 root="Petronia_petronia", > > 8 m=2, > 9 ) > > ~/opt/miniconda3/envs/py3/lib/python3.6/site-packages/ipyrad/analysis/treemix.py > in __init__(self, data, name, workdir, imap, minmap, seed, quiet, > raise_root_error, binary, *args, **kwargs) > 118 > 119 # others > --> 120 self.binary = os.path.join(sys.prefix, "bin", "treemix") > 121 self.binary = (binary if binary else self.binary) > 122 self.raise_root_error = raise_root_error > > NameError: name 'sys' is not defined As the name sys is used in the imported module, that module has to import sys. Importing it in the calling code doesn't help. So I would say this is a bug in the module. You should report the bug to its author. In the meantime you can correct your own copy at ~/opt/miniconda3/envs/py3/lib/python3.6/site-packages/ipyrad/analysis/treemix.py by adding import sys for example around line 10 -- Pieter van Oostrum www: http://pieter.vanoostrum.org/ PGP key: [8DAE142BE17999C4] -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Finking: Source code organisation
> On 28 Dec 2019, at 22:49, Chris Angelico wrote: > > On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list > wrote: >> >> Is it helpful to, and thus, do you have a style/convention for ordering >> the methods within each class in your code? >> >> A major difference however, is that if our mythical collection of >> module-functions has an internal-reference, eg b() requires a(), then >> function a() MUST exist, ie be defined, 'before' function b(). Whereas a >> class's methods may be defined in any (complete) sequence. >> >> So, do you have an orderly method [hah!] for presenting/locating >> class-methods (and module-functions) within your code? >> >> - why bother, the editor does 'the heavy lifting' >> - dunders to the fore >> - alphanumeric sequence by name >> - order of appearance/use in 'mainline code' >> - as they sprang to mind during TDD-creation >> - most-used first, least-used last >> - my code 'at the top', their stuff later... >> - names of Monty Python characters by TV appearance date >> or, >> - some combination of ideas >> and, >> - how do you vary the above when dependencies intrude? >> > > "Define before use" is a broad principle that I try to follow, even > when the code itself doesn't mandate this. This generally means that > "if name is main" is the very last thing in the file, and if there's a > main() function or equivalent, that's usually just before that. Any > metaprogramming goes right at the top; sometimes this is mandated (if > I write a decorator function, it has to be above the functions it's > decorating), but even if it's not, metaprogramming goes before the > mainline. "define before use" is basically email top-posting for code isn't it? It means that the first things that you read in a module are the least interesting. I prefer to follow the a top-down design approach. Start with what is important and put what that depends on further down the file/class. With classes, __init__, __new__ then the public API and last the supporting code. Barry > > Other than that, I don't have any consistent logic other than a loose > idea of trying to keep related things together. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Finking: Source code organisation
On Tue, Dec 31, 2019 at 1:47 AM Barry Scott wrote: > > > > > On 28 Dec 2019, at 22:49, Chris Angelico wrote: > > > > On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list > > wrote: > >> > >> Is it helpful to, and thus, do you have a style/convention for ordering > >> the methods within each class in your code? > >> > >> A major difference however, is that if our mythical collection of > >> module-functions has an internal-reference, eg b() requires a(), then > >> function a() MUST exist, ie be defined, 'before' function b(). Whereas a > >> class's methods may be defined in any (complete) sequence. > >> > >> So, do you have an orderly method [hah!] for presenting/locating > >> class-methods (and module-functions) within your code? > >> > >> - why bother, the editor does 'the heavy lifting' > >> - dunders to the fore > >> - alphanumeric sequence by name > >> - order of appearance/use in 'mainline code' > >> - as they sprang to mind during TDD-creation > >> - most-used first, least-used last > >> - my code 'at the top', their stuff later... > >> - names of Monty Python characters by TV appearance date > >> or, > >> - some combination of ideas > >> and, > >> - how do you vary the above when dependencies intrude? > >> > > > > "Define before use" is a broad principle that I try to follow, even > > when the code itself doesn't mandate this. This generally means that > > "if name is main" is the very last thing in the file, and if there's a > > main() function or equivalent, that's usually just before that. Any > > metaprogramming goes right at the top; sometimes this is mandated (if > > I write a decorator function, it has to be above the functions it's > > decorating), but even if it's not, metaprogramming goes before the > > mainline. > > > > "define before use" is basically email top-posting for code isn't it? Kinda the opposite - it means that you get the context before you get something that refers to it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Finking: Source code organisation
On Tue, Dec 31, 2019 at 3:08 AM Barry Scott wrote: > > > > > On 30 Dec 2019, at 15:35, Chris Angelico wrote: > > > > On Tue, Dec 31, 2019 at 1:47 AM Barry Scott wrote: > >> > >> > >> > >>> On 28 Dec 2019, at 22:49, Chris Angelico wrote: > >>> > >>> On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list > >>> wrote: > > Is it helpful to, and thus, do you have a style/convention for ordering > the methods within each class in your code? > > A major difference however, is that if our mythical collection of > module-functions has an internal-reference, eg b() requires a(), then > function a() MUST exist, ie be defined, 'before' function b(). Whereas a > class's methods may be defined in any (complete) sequence. > > So, do you have an orderly method [hah!] for presenting/locating > class-methods (and module-functions) within your code? > > - why bother, the editor does 'the heavy lifting' > - dunders to the fore > - alphanumeric sequence by name > - order of appearance/use in 'mainline code' > - as they sprang to mind during TDD-creation > - most-used first, least-used last > - my code 'at the top', their stuff later... > - names of Monty Python characters by TV appearance date > or, > - some combination of ideas > and, > - how do you vary the above when dependencies intrude? > > >>> > >>> "Define before use" is a broad principle that I try to follow, even > >>> when the code itself doesn't mandate this. This generally means that > >>> "if name is main" is the very last thing in the file, and if there's a > >>> main() function or equivalent, that's usually just before that. Any > >>> metaprogramming goes right at the top; sometimes this is mandated (if > >>> I write a decorator function, it has to be above the functions it's > >>> decorating), but even if it's not, metaprogramming goes before the > >>> mainline. > >> > >> > >> > >> "define before use" is basically email top-posting for code isn't it? > > > > Kinda the opposite - it means that you get the context before you get > > something that refers to it. > > But its not context its the low level detail that I should be able to ignore > when trying to understand the goals of the code. I'll only need to know > about the lower level detail if I have a need to change the code. > > Another analogy would ne how a journalist writes a story. You can take > a well written article and stop reading at any point, but still know what > the story is about. The more paragraphs you read the more informed > you are about the story. (Editors exploit this property of a story to shorten > it if it does not fit on the page). > Sure, but that's not what top-posting in emails is like. With a top-posted reply, truncation means you lack context; with the journalistic style of "front-load the important info", truncation means you lack detail. So in coding, I would say the journalistic style corresponds to a broad notion of "first docstring, then main function, then support code", which is an absolutely legit way to do things (but not my preferred way). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Finking: Source code organisation
> On 30 Dec 2019, at 15:35, Chris Angelico wrote: > > On Tue, Dec 31, 2019 at 1:47 AM Barry Scott wrote: >> >> >> >>> On 28 Dec 2019, at 22:49, Chris Angelico wrote: >>> >>> On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list >>> wrote: Is it helpful to, and thus, do you have a style/convention for ordering the methods within each class in your code? A major difference however, is that if our mythical collection of module-functions has an internal-reference, eg b() requires a(), then function a() MUST exist, ie be defined, 'before' function b(). Whereas a class's methods may be defined in any (complete) sequence. So, do you have an orderly method [hah!] for presenting/locating class-methods (and module-functions) within your code? - why bother, the editor does 'the heavy lifting' - dunders to the fore - alphanumeric sequence by name - order of appearance/use in 'mainline code' - as they sprang to mind during TDD-creation - most-used first, least-used last - my code 'at the top', their stuff later... - names of Monty Python characters by TV appearance date or, - some combination of ideas and, - how do you vary the above when dependencies intrude? >>> >>> "Define before use" is a broad principle that I try to follow, even >>> when the code itself doesn't mandate this. This generally means that >>> "if name is main" is the very last thing in the file, and if there's a >>> main() function or equivalent, that's usually just before that. Any >>> metaprogramming goes right at the top; sometimes this is mandated (if >>> I write a decorator function, it has to be above the functions it's >>> decorating), but even if it's not, metaprogramming goes before the >>> mainline. >> >> >> >> "define before use" is basically email top-posting for code isn't it? > > Kinda the opposite - it means that you get the context before you get > something that refers to it. But its not context its the low level detail that I should be able to ignore when trying to understand the goals of the code. I'll only need to know about the lower level detail if I have a need to change the code. Another analogy would ne how a journalist writes a story. You can take a well written article and stop reading at any point, but still know what the story is about. The more paragraphs you read the more informed you are about the story. (Editors exploit this property of a story to shorten it if it does not fit on the page). Barry > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Segmentation violation with python installation under Tumbleweed
Hello, My full Python installation doesn't seem to work due to a segmentation violation issue with libc-2.30: Dec 30 23:54:14 craylinux1 Kernel: Python [8467]: Segfault at 100013483 ip 7f6594c896b6 sp 7ffe1570d188 error 4 in libc-2.30.so [7f6594c1 + 14d000] 30.12. 23:54:14 craylinux1 kernel: Code: 0f 1f 40 00 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83 I think this is just a bug of mismatched binaries and libraries in my Python installation. I want to reinstall the full Python installation including the libraries now, but how can you do it with Zypper to get a clean Python environment again? Any help with the detailed command lines would be greatly appreciated. Regards, Andreas -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Finking: Source code organisation
On 31/12/19 3:47 am, Barry Scott wrote: "define before use" is basically email top-posting for code isn't it? It means that the first things that you read in a module are the least interesting. That's not a big problem for top-level code, since you can easily scroll down to the bottom of the file and work backwards. But it's not so easy for classes if you have more than one class in a file. That might be part of the reason I do things the opposite way in classes. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
