Re: How to install your personal module/package on site.
Sorry, didn't read well, Apart the other suggestion, you (or your sysop) can create a private Pypi: https://pypi.org/project/private-pypi/ -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install your personal module/package on site.
Does the word "public" mean world-wide, or perhaps only amongst your work-colleagues? Only among work-colleagues. We only want that anyone writing and running python scripts on particular hosts, can easily import these modules/packages. Of possible interest:- Private Python package management https://stackoverflow.com/questions/63320653/private-python-package-management -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Whitespace not/required
On 15/08/2020 08:01, Dennis Lee Bieber wrote:
On Fri, 14 Aug 2020 16:29:18 +1200, dn via Python-list
declaimed the following:
it is ignored by Python. (yes, this discussion disdains comments!) For
example, whitespace is no problem when it comes to defining a list:
month_names = ['Januari', 'Februari', 'Maart', # These are the
'April', 'Mei', 'Juni', # Dutch names...
Concepts: First, you have an open [ though ( and { behave the same.
Python takes anything in intervening lines to be included until the closing
]/)/} is reached.
Exactly! (BTW this taken from 'the manual')
Second, for things like lists, the only important (parsed content) are
the "words" [in your example] separated by commas.
Agreed - and IMHO a positive attribute when coding in Python making a
solid contribution to readability.
Whitespace in Python controls /scope/ of logic structures (function
definition, loop bodies, conditional bodies).
Hence my surprise/how do we explain:
>>> f'{ one:03 }'
Traceback (most recent call last):
File "", line 1, in
ValueError: Unknown format code '\x20' for object of type 'int'
where the final space does not act as a separator by terminating the
format-specification. The err.msg is in itself confusing, because the
format-specification 03 is NOT a (valid) Python integer:
>>> i = 3
>>> i
3
>>> i = 03
File "", line 1
i = 03
^
SyntaxError: leading zeros in decimal integer literals are not
permitted; use an 0o prefix for octal integers
Perhaps I'm mis-interpreting the err.msg?
Otherwise let's march on City Hall: "white space just wants to be free!"...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: print the output of my code in Markdown using variable (not the value)
On 8/15/20 11:00 AM, Michio Suginoo wrote: > Hi, > > I am still at an early stage of my personal Python evolution. > > I am coding Python3 in Jupyter Notebook (Anaconda environment). > > I want to print the output of my code in a 'markdown'. > I want to use the variable in the 'markdown' rather than typing the output. > This would save my time every time the value changes for whatever the > reason might be. > > Please advise me how to do it. Just a gentle suggestion... show a sample of what you're trying to achieve, and if possible some code that you've tried. This might be a place to look: https://ipython.readthedocs.io/en/stable/api/generated/IPython.display.html#IPython.display.Markdown -- https://mail.python.org/mailman/listinfo/python-list
print the output of my code in Markdown using variable (not the value)
Hi, I am still at an early stage of my personal Python evolution. I am coding Python3 in Jupyter Notebook (Anaconda environment). I want to print the output of my code in a 'markdown'. I want to use the variable in the 'markdown' rather than typing the output. This would save my time every time the value changes for whatever the reason might be. Please advise me how to do it. Thanks Best . -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
A few comments come to mind about this discussion about TCO. First, TCO, Tail Call Optimization, is talking about something that is an optimization. Optimizations, are generally some OPTIONAL improvement in the method of executing the code that doesn't alter its DEFINED meaning. First big point, they are optional. Yes, some languages may define certain circumstances where where there is a promise that a given optimization will be done, but this is unusual. Some things that might seem like optimizations, really aren't but are defined behaviors, like the short cutting operators 'and' and 'or' where the fact that the second operand isn't always evaluated could be though of as an optimization. Second, optimizations are generally only allow to be performed if it doesn't change any defined behavior of the program. I am not so sure that is possible for TCO to be done in python based on that. for example, given: def foo(x): if x == 0: return 1 else return foo(x-1) def bar(x) if x == 0: return 2 else return bar(x-1) t = foo foo = bar bar = t foo(1) By the twiddling done at the end, we have changed the self tail-recursive functions into mutually tail-recursive functions. The fact we can do this says that when compiling foo and bar into byte-code, the recursive call to foo can't just automatically go to the beginning of the current function, but needs to look up the name and enter with a possibly need operation, something like a tail-call which becomes more of a jump as it doesn't create a new stack frame but somehow replaces the current frame with what will be the new frame while binding the 'new x' with the old 'x-1' Second, because Python has defined things like traceback, the presence of TCO is observable, and thus violates one of the basic guidelines of an optimization, that it shouldn't change defined behavior. In my mid, this says that for Python to proper support TCO, it may need to do something to make it an explicit request, or at least defined specifically when it will do it and when not. Perhaps it could be defined that a return statement whose top level of the expression is a function call, becomes an optimized tail call, ALWAYS (at least with that version of Python), or maybe some sort of flag needs to also be on the statement to avoid making it a backwards breaking change. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
Op 15/08/20 om 15:02 schreef Chris Angelico: > On Sat, Aug 15, 2020 at 10:45 PM Antoon Pardon > wrote: >> >> >> I don't understand this argument. The trace back information that is >> destroyed with this optimization, is information that isn't available >> anyway if you write the code in an iterative fashion. > > Your counter-argument applies only to recursion, but TCO applies to > *any* tail call. Consider this: > > @some_deco > def spam(n): > ... > return spam(n // 2) > > Not a recursive tail call and cannot be rewritten as a loop, unless > you know for sure that some_deco returns the original function. But > TCO can still optimize this - by collapsing the stack frames. Which > loses traceback info, unless you deliberately preserve it. And how often does this kind of situation come up and destroy important trace back information? Sure you can come up with artificial examples like the above, but if the above code gets into trouble because you run into the recursion limit, you still will have to transform it into a loop somehow. >> I think writing code that is at heart a state machine would be a lot more >> easy if python would have TCO. Then each state could be implemented by >> a function and transitioning from one state to the next would be just >> calling the next function. > > I'm honestly not sure how much you'd gain by writing the transitions > as additional calls. But then, I don't tend to write pure state > machines in Python. If anything, they're "state machines with > resumption" or something, and the additional wrinkles mean it's best > to maintain state in a data structure and maintain code in a function, > instead of trying to do both on the call stack. Why are you talking about a stack? I don't know what best suits your code but my code often enough doesn't have enough wrinkles to bother with extra data structures. > > ISTM that everyone who begs for tail recursion optimization is trying > to write loops as recursion. Maybe that's why Python has never > bothered - because it's an optimization for an inferior way to write > the same logic. Prove me wrong. Show me something where it actually > couldn't be better written iteratively, yet it still benefits from the > optimization. What standard do you use to measure what is inferior of superior? Sometimes a state machines is easiest defined as a number of mutual recursive functions that just tail call each other. So with TCO I could just write it like the following. def state1(...): ... if ready_for_2: return state2(...) elif ready_for_7: return state7(...) elif finished: return result def state2(...): ... and you just call it like: result = state1(...) Without TCO I am forced to write it as follow: def state1(...): ... if ready_for_2: return state2, (...) # notice the comma between function and args. elif ready_for_7: return state7, (...) elif finished: return None, result def state2(...): ... and then call it like: state = state0 args = ... while state is not None: state, args = state(*args) result = args I realy don't see what I gain by having this loop or what I could gain by some extra data structure. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
@Chris: you're very right, but, I repeat, you can't have a real TCO (asyncio apart): (venv_3_10) marco@buzz:~$ python Python 3.10.0a0 (heads/master-dirty:ba18c0b13b, Aug 14 2020, 17:52:45) [GCC 10.1.1 20200718] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def factorial(n): ... if n in (1, 2): ... return n ... return n * factorial(n-1) ... >>> factorial(6) 720 >>> factorial(1000) Traceback (most recent call last): File "", line 1, in File "", line 4, in factorial File "", line 4, in factorial File "", line 4, in factorial [Previous line repeated 995 more times] File "", line 2, in factorial RecursionError: maximum recursion depth exceeded in comparison Anyway, tail call is introduced in Python, but only for asyncio: "If a Future.set_exception() is called but the Future object is never awaited on, the exception would never be propagated to the user code. Enable the debug mode to get the traceback where the task was created" https://docs.python.org/3.10/library/asyncio-dev.html#detect-never-retrieved-exceptions So, in theory, nothing prevents Python from having a Tail Call Optimization... because it already has it! The only problem is that it's applied to asyncio only. IMHO it's not a big problem to support generic TCO, and disable it for debugging purposes enabling the Python dev mode. -- https://mail.python.org/mailman/listinfo/python-list
Re: try..except or type() or isinstance()?
On Sat, 15 Aug 2020 11:47:03 +0200 Sibylle Koczian wrote: > Am 15.08.2020 um 10:14 schrieb Manfred Lotz: > > Hi Chris, > > Thanks a lot for you advice. > > > > On Sat, 15 Aug 2020 16:15:29 +1000 > > Chris Angelico wrote: > > > >> On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz > >> wrote: > >>> > >>> I have an object which I could initialize providind an int or a > >>> str. > ... > > > > For my use case I don't like this solution as I get the value which > > could be an int or str from a file. Means I would have to check the > > type beforehand in order to know if I have to do O4(val) or > > O4.from_name(val). > > > > Otherwise, it is admittedly a very good pattern. > > > > > Possibly silly question: No silly questions. There are at most stupid answers. :-) > if the value comes from a file, isn't it a > string in any case? A string that may be convertible to int or not? Or > what sort of file do I overlook? > In this case it is a TOML file. -- Manfred -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, Aug 15, 2020 at 10:45 PM Antoon Pardon wrote: > > Op 7/08/20 om 18:45 schreef Chris Angelico: > > On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote: > >> > >> On 2020-08-07 at 17:55:45 +0200, > >> Marco Sulla wrote: > >>> @Chris: note that "real" recursion in Python is not possible, since > >>> there's no support for tail recursion. Maybe something similar can be > >>> done using async functions. > >> > >> Python has real recursion. Whether or not there's tail recursion on the > >> inside is an implementation detail. > > > > More specifically: Python has real recursion. Whether or not tail > > recursion is optimized away is an implementation detail. > > > > Tail call optimization (there's no reason to restrict it to recursion > > alone) is something a Python implementation could choose to do, but > > the trouble is that full optimization tends to destroy traceback > > information, so it's often not worth doing. > > I don't understand this argument. The trace back information that is > destroyed with this optimization, is information that isn't available > anyway if you write the code in an iterative fashion. Your counter-argument applies only to recursion, but TCO applies to *any* tail call. Consider this: @some_deco def spam(n): ... return spam(n // 2) Not a recursive tail call and cannot be rewritten as a loop, unless you know for sure that some_deco returns the original function. But TCO can still optimize this - by collapsing the stack frames. Which loses traceback info, unless you deliberately preserve it. > And the cases where > > partial optimization is of value just aren't compelling enough for > > anyone to implement it into CPython, nor any other major > > implementation (to my knowledge). The biggest uses for TCO tend to be > > the situations where recursion is the wrong solution to the problem. > > I think writing code that is at heart a state machine would be a lot more > easy if python would have TCO. Then each state could be implemented by > a function and transitioning from one state to the next would be just > calling the next function. I'm honestly not sure how much you'd gain by writing the transitions as additional calls. But then, I don't tend to write pure state machines in Python. If anything, they're "state machines with resumption" or something, and the additional wrinkles mean it's best to maintain state in a data structure and maintain code in a function, instead of trying to do both on the call stack. ISTM that everyone who begs for tail recursion optimization is trying to write loops as recursion. Maybe that's why Python has never bothered - because it's an optimization for an inferior way to write the same logic. Prove me wrong. Show me something where it actually couldn't be better written iteratively, yet it still benefits from the optimization. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
Op 7/08/20 om 18:45 schreef Chris Angelico: > On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote: >> >> On 2020-08-07 at 17:55:45 +0200, >> Marco Sulla wrote: >>> @Chris: note that "real" recursion in Python is not possible, since >>> there's no support for tail recursion. Maybe something similar can be >>> done using async functions. >> >> Python has real recursion. Whether or not there's tail recursion on the >> inside is an implementation detail. > > More specifically: Python has real recursion. Whether or not tail > recursion is optimized away is an implementation detail. > > Tail call optimization (there's no reason to restrict it to recursion > alone) is something a Python implementation could choose to do, but > the trouble is that full optimization tends to destroy traceback > information, so it's often not worth doing. I don't understand this argument. The trace back information that is destroyed with this optimization, is information that isn't available anyway if you write the code in an iterative fashion. So people are advised to rewrite tail recursive code in an iterative fashion, which results in less trace back information and the reason for not doing tail call optimization is, that it destroy the trace back information they don't have anyway by transforming the code to an iterative version. And the cases where > partial optimization is of value just aren't compelling enough for > anyone to implement it into CPython, nor any other major > implementation (to my knowledge). The biggest uses for TCO tend to be > the situations where recursion is the wrong solution to the problem. I think writing code that is at heart a state machine would be a lot more easy if python would have TCO. Then each state could be implemented by a function and transitioning from one state to the next would be just calling the next function. Sure you can resolve this by writing your state function trampoline style but it forces you into writing some boiler plate that otherwise wouldn't be necessary. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: try..except or type() or isinstance()?
Am 15.08.2020 um 10:14 schrieb Manfred Lotz: Hi Chris, Thanks a lot for you advice. On Sat, 15 Aug 2020 16:15:29 +1000 Chris Angelico wrote: On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz wrote: I have an object which I could initialize providind an int or a str. ... For my use case I don't like this solution as I get the value which could be an int or str from a file. Means I would have to check the type beforehand in order to know if I have to do O4(val) or O4.from_name(val). Otherwise, it is admittedly a very good pattern. Possibly silly question: if the value comes from a file, isn't it a string in any case? A string that may be convertible to int or not? Or what sort of file do I overlook? Curious, Sibylle -- https://mail.python.org/mailman/listinfo/python-list
Re: How to install your personal module/package on site.
Op 15/08/20 om 07:33 schreef dn via Python-list: > On 14/08/2020 22:32, Antoon Pardon wrote: >> Well the question is in the subject. >> >> I have a number of modules/packages which were until recently >> personal use only. However python is getting more popular >> at work and some of my work was considered useful enough to >> install in a public available spot. >> >> How should I approach this? > > > Does the word "public" mean world-wide, or perhaps only amongst your > work-colleagues? Only among work-colleagues. We only want that anyone writing and running python scripts on particular hosts, can easily import these modules/packages. -- Antoon -- https://mail.python.org/mailman/listinfo/python-list
Re: try..except or type() or isinstance()?
On Sat, 15 Aug 2020 08:33:58 +0200 Peter Otten <__pete...@web.de> wrote: > Chris Angelico wrote: > > > On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz > > wrote: > >> > >> I have an object which I could initialize providind an int or a > >> str. > >> > >> I am not sure which of the following is best to use > >> - try/except > >> - if type(int)... > >> - if isinstance(v, int) > >> > >> Here a minimal example > >> > >> def get_id(fromname): > >> # do something with `fromname` > >> return 0 > >> > >> def get_name(fromid): > >> # do something with `fromid` > >> return "something" > >> > >> """ For O1, O2, O3: self.myid is int > >> self.name is str > >> """ > >> class O1: > >> def __init__(self, val): > >> try: > >> self.myid = int(val) > >> self.name = get_name(self.myid) > >> except: > >> self.myid = get_id(val) > >> self.name = val > > > > Don't use a bare "except" - use "except ValueError" instead. But > > otherwise, this is a perfectly reasonable way to say "anything that > > can be interpreted as an integer will be". > > > >> class O2: > >> def __init__(self, val): > >> if type(val) == int: > >> self.myid = val > >> self.name = get_name(self.myid) > >> else: > >> self.myid = get_id(val) > >> self.name = val > > > > Nope, don't do this. It's strictly worse than O3. > > > >> class O3: > >> def __init__(self, val): > >> if isinstance(val, int): > >> self.myid = val > >> self.name = get_name(self.myid) > >> else: > >> self.myid = get_id(val) > >> self.name = val > > > > This is a perfectly reasonable way to say "integers will be treated > > as IDs". Note that O1 and O3 are very different semantically; O1 > > will treat the string "7" as an ID, but O3 will treat it as a name. > > > > Here's an even better way: > > > > class O4: > > def __init__(self, id): > > self.myid = id > > self.name = get_name(id) > > @classmethod > > def from_name(cls, name): > > return cls(get_id(name)) > > > > This makes the ID the main way you'd do things, and a name lookup as > > an alternate constructor. Very good pattern, reliable, easy to use. > > > > Yet another way: keyword arguments: > > class O5: > def __init__(self, *, id=None, name=None): > if name is None: > assert id is not None > name = get_name(id) > else: > assert id is None > id = get_id(name) > self.id = id > self.name = name > Thanks. Also a nice method. As said in my other reply it doesn't fit to my use case. -- Manfred -- https://mail.python.org/mailman/listinfo/python-list
Re: try..except or type() or isinstance()?
Hi Chris, Thanks a lot for you advice. On Sat, 15 Aug 2020 16:15:29 +1000 Chris Angelico wrote: > On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz > wrote: > > > > I have an object which I could initialize providind an int or a str. > > > > I am not sure which of the following is best to use > > - try/except > > - if type(int)... > > - if isinstance(v, int) > > > > Here a minimal example > > > > def get_id(fromname): > > # do something with `fromname` > > return 0 > > > > def get_name(fromid): > > # do something with `fromid` > > return "something" > > > > """ For O1, O2, O3: self.myid is int > > self.name is str > > """ > > class O1: > > def __init__(self, val): > > try: > > self.myid = int(val) > > self.name = get_name(self.myid) > > except: > > self.myid = get_id(val) > > self.name = val > > Don't use a bare "except" - use "except ValueError" instead. Oops, yes. You are right, of course. > But > otherwise, this is a perfectly reasonable way to say "anything that > can be interpreted as an integer will be". > > > class O2: > > def __init__(self, val): > > if type(val) == int: > > self.myid = val > > self.name = get_name(self.myid) > > else: > > self.myid = get_id(val) > > self.name = val > > Nope, don't do this. It's strictly worse than O3. > Aaa ok. I think in this particular case it would be ok but in general it might be bad if val would be a class object. So, I take your advice to avoid this in general as then I avoid errors in more complicated situations when using type(..). > > class O3: > > def __init__(self, val): > > if isinstance(val, int): > > self.myid = val > > self.name = get_name(self.myid) > > else: > > self.myid = get_id(val) > > self.name = val > > This is a perfectly reasonable way to say "integers will be treated as > IDs". Note that O1 and O3 are very different semantically; O1 will > treat the string "7" as an ID, but O3 will treat it as a name. > > Here's an even better way: > > class O4: > def __init__(self, id): > self.myid = id > self.name = get_name(id) > @classmethod > def from_name(cls, name): > return cls(get_id(name)) > > This makes the ID the main way you'd do things, and a name lookup as > an alternate constructor. Very good pattern, reliable, easy to use. > For my use case I don't like this solution as I get the value which could be an int or str from a file. Means I would have to check the type beforehand in order to know if I have to do O4(val) or O4.from_name(val). Otherwise, it is admittedly a very good pattern. -- Manfred -- https://mail.python.org/mailman/listinfo/python-list
