Re: Any marginally usable programming language approaches an ill defined barely usable re-implementation of half of Common-Lisp
On 2024-05-29 at 11:39:14 -0700, HenHanna via Python-list wrote: > On 5/27/2024 1:59 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: > > https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule [...] > Are the Rules 1--9 by Greenspun good too? I don't know; let me look it up. Oh, there it is: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule says that Greenspun said he "was just trying to give the rule a memorable name." Sadly, the citation link is failing for me right now. -- https://mail.python.org/mailman/listinfo/python-list
Re: Serializing pydantic enums
On 5/29/24 13:27, Larry Martell via Python-list wrote: On Tue, May 28, 2024 at 11:46 AM Left Right via Python-list wrote: Most Python objects aren't serializable into JSON. Pydantic isn't special in this sense. What can you do about this? -- Well, if this is a one-of situation, then, maybe just do it by hand? If this is a recurring problem: json.dumps() takes a cls argument that will be used to do the serialization. Extend json.JSONEncoder and implement the encode() method for the encoder class you are passing. I believe that the official docs have some information about this too. Yeah, I know I can do this, but I seem to recall reading that pydantic handled serialization. Guess not. Pydantic devotes some of its documentation to serialization. https://docs.pydantic.dev/latest/concepts/serialization/ As noted elsewhere, some Python objects are easy to serialize, some you need to provide some help. Consider pickling: if you write a class that isn't obviously pickleable, the getstate dunder method can be defined to help out. For Pydantic, there's a couple of ways... aliases in particular seem designed to help: there's a serialization_alias argument to the Field function. -- https://mail.python.org/mailman/listinfo/python-list
Re: Serializing pydantic enums
On Wed, May 29, 2024 at 12:27 PM Larry Martell wrote: > > On Tue, May 28, 2024 at 11:46 AM Left Right via Python-list > wrote: > > > > Most Python objects aren't serializable into JSON. Pydantic isn't > > special in this sense. > > > > What can you do about this? -- Well, if this is a one-of situation, > > then, maybe just do it by hand? > > > > If this is a recurring problem: json.dumps() takes a cls argument that > > will be used to do the serialization. Extend json.JSONEncoder and > > implement the encode() method for the encoder class you are passing. I > > believe that the official docs have some information about this too. > > Yeah, I know I can do this, but I seem to recall reading that pydantic > handled serialization. Guess not. Actually it's as simple as adding this to any model that uses an enum model: class Config: use_enum_values = True > > On Tue, May 28, 2024 at 2:50 PM Larry Martell via Python-list > > wrote: > > > > > > Just getting started with pydantic. I have this example code: > > > > > > class FinishReason(Enum): > > > stop = 'stop' > > > > > > class Choice(BaseModel): > > > finish_reason: FinishReason = Field(...) > > > > > > > > > But I cannot serialize this: > > > > > > json.dumps(Choice(finish_reason=FinishReason.stop).dict()) > > > *** TypeError: Object of type FinishReason is not JSON serializable > > > > > > > > > I get the object not the value: > > > > > > (Pdb) Choice(finish_reason=FinishReason.stop) > > > Choice(finish_reason=) > > > > > > > > > Also tried it with .value, same result. > > > > > > What am I missing here? -- https://mail.python.org/mailman/listinfo/python-list
Re: SOLVED! Re: Weird Stuff (Markdown, syntax highlighting and Python)
On 29/05/24 06:49, Gilmeh Serda via Python-list wrote: Solved by using a different method. Hedonist for hire... no job too easy! This combination of sig-file and content seems sadly ironic. How about CONTRIBUTING to the community by explaining 'the solution' to people who may find a similar problem - in the similar manner to the various members who have helped YOU, voluntarily (and despite the paucity of source-information and response)? -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Any marginally usable programming language approaches an ill defined barely usable re-implementation of half of Common-Lisp
On 2024-05-29, HenHanna wrote: > On 5/27/2024 1:59 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: >> https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule > > > interesting!!! > > Are the Rules 1--9 by Greenspun good too? I don't think they exist; it's a joke. However, Greenspun's resume of accomplishments is a marvel and an inspiration, including many in Lisp. A few highlights: https://philip.greenspun.com/personal/resume "Helped architect, simulate and design prototype of HP's Precision Architecture RISC computer. The prototype took two man-years to complete and ran at VAX 11/780 speed in June 1983. This architecture became the basis of HP's computer product line for 15 years and then became the basis for the 64-bit generation of Intel processors." https://philip.greenspun.com/personal/resume-list "Automatic Layout tools for VLSI, with an emphasis on bus cells and automatic implementation of finite state machines (1984 for Symbolics)" "Design tools on Symbolics Lisp Machine for RISC CPU implemented in TTL (1982-3 for Hewlett Packard)" (in reference to the PA-RISC work). "ConSolve system for automating earthmoving, entirely implemented in Lisp (1986-1989 for ConSolve), including: * Delaunay Triangulation-based terrain model, with C0 and C1 surface models. * complete environment for earthworks and road design, including software to specify design surfaces, calculate costs of realizing design surfaces and automatic design tools * tree-structured database of zoning laws and automatic testing of design compliance * hydrology modelling to calculate drainage basins, streams and ridges * simulation of earthmoving vehicles * automated surveying using vehicles and location systems * radio interface to Caterpillar vehicle, including CRCC error detection * automatically generated user interface" -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @kazina...@mstdn.ca -- https://mail.python.org/mailman/listinfo/python-list
Re: Any marginally usable programming language approaches an ill defined barely usable re-implementation of half of Common-Lisp
On 5/27/2024 1:59 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: On 2024-05-27 at 12:37:01 -0700, HenHanna via Python-list wrote: On 5/27/2024 7:18 AM, Cor wrote: Some entity, AKA "B. Pym" , wrote this mindboggling stuff: (selectively-snipped-or-not-p) On 12/16/2023, c...@clsnet.nl wrote: Any marginally usable programming language approaches an ill defined barely usable re-implementation of half of common-lisp The good news is, it's not Lisp that sucks, but Common Lisp. --- Paul Graham Just to set the record straight; This is not My line. I quoted it but don't know who the originator of that remark is. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule interesting!!! Are the Rules 1--9 by Greenspun good too? does Greenspun pun ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Serializing pydantic enums
On Tue, May 28, 2024 at 11:46 AM Left Right via Python-list wrote: > > Most Python objects aren't serializable into JSON. Pydantic isn't > special in this sense. > > What can you do about this? -- Well, if this is a one-of situation, > then, maybe just do it by hand? > > If this is a recurring problem: json.dumps() takes a cls argument that > will be used to do the serialization. Extend json.JSONEncoder and > implement the encode() method for the encoder class you are passing. I > believe that the official docs have some information about this too. Yeah, I know I can do this, but I seem to recall reading that pydantic handled serialization. Guess not. > On Tue, May 28, 2024 at 2:50 PM Larry Martell via Python-list > wrote: > > > > Just getting started with pydantic. I have this example code: > > > > class FinishReason(Enum): > > stop = 'stop' > > > > class Choice(BaseModel): > > finish_reason: FinishReason = Field(...) > > > > > > But I cannot serialize this: > > > > json.dumps(Choice(finish_reason=FinishReason.stop).dict()) > > *** TypeError: Object of type FinishReason is not JSON serializable > > > > > > I get the object not the value: > > > > (Pdb) Choice(finish_reason=FinishReason.stop) > > Choice(finish_reason=) > > > > > > Also tried it with .value, same result. > > > > What am I missing here? -- https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On 5/29/2024 10:59 AM, MRAB via Python-list wrote: On 2024-05-29 15:32, Thomas Passin via Python-list wrote: On 5/29/2024 8:55 AM, Kevin M. Wilson wrote: Please recall, I said the format for the email failed to retain the proper indents. I'll attach a picture of the code! Purpose; to uppercase every other letter in a string. Thanks all, KMW Simpler is good, and readability is good. For a simple conversion that has a little touch of generality: s1 = 'this is a test' def convert(i, ch): return ch.upper() if i % 2 else ch result = ''.join([convert(i, ch) for i, ch in enumerate(s1)]) print(result) # tHiS Is a tEsT [snip] Small mistake there. The original code converted to uppercase on even indexes, whereas your code does it on odd ones. I wondered if anyone would catch that :) Anyway, I don't think the original question was whether to start with even or odd but ways to iterate character by character and do something, right? However, this has a weakness: what to do about spaces. Should they be counted among the characters to be uppercased? or should they not be included in the count of the alternation? If you want to uppercase every other letter that is not a space, things become a little more complicated. And then do you want this to apply to all whitespace or only spaces? If you want to skip changing spaces, then you need to track the state of converted characters in some way. It would probably be easier (and more readable) to use a "for x in t:" construction: Actually, I did mess up the action for a space. It should be: def convert(convert_this, ch): """Convert character ch if convert_this is True. Don't convert spaces. """ if ch == ' ': return (convert_this, ch) if convert_this: return (False, ch.upper()) return (True, ch) We should never get two printable uppercased characters in a row, even if there is a space between them, but my original convert(convert_this, ch) did. def convert(convert_this, ch): """Convert character ch if convert_this is True. Don't convert spaces. """ if convert_this: if ch == ' ': return (convert_this, ch) elif convert_this: return (False, ch.upper()) return (True, ch) convert_next = False result = '' for ch in s1: convert_next, ch = convert(convert_next, ch) result += ch print(result) # tHiS Is A TeSt There could be even more complications if you allow non-ascii characters but you were asking about processing character by character so I won't get into that. (You haven't specified the problem in enough detail to answer questions like those). [snip] -- https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On 2024-05-29, Mats Wichmann via Python-list wrote:
> On 5/29/24 08:02, Grant Edwards via Python-list wrote:
>> On 2024-05-29, Chris Angelico via Python-list wrote:
>>
>>> print(f"if block {name[index]=} {index=}")
>>
>> Holy cow! How did I not know about the f-string {=} thing?
>
> It's more recent than f-strings in general, so it's not that hard to miss.
I really should make a habit of reading through the "what's new" pages
when new releases come out...
--
Grant
--
https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On 2024-05-29 15:32, Thomas Passin via Python-list wrote: On 5/29/2024 8:55 AM, Kevin M. Wilson wrote: Please recall, I said the format for the email failed to retain the proper indents. I'll attach a picture of the code! Purpose; to uppercase every other letter in a string. Thanks all, KMW Simpler is good, and readability is good. For a simple conversion that has a little touch of generality: s1 = 'this is a test' def convert(i, ch): return ch.upper() if i % 2 else ch result = ''.join([convert(i, ch) for i, ch in enumerate(s1)]) print(result) # tHiS Is a tEsT [snip] Small mistake there. The original code converted to uppercase on even indexes, whereas your code does it on odd ones. However, this has a weakness: what to do about spaces. Should they be counted among the characters to be uppercased? or should they not be included in the count of the alternation? If you want to uppercase every other letter that is not a space, things become a little more complicated. And then do you want this to apply to all whitespace or only spaces? If you want to skip changing spaces, then you need to track the state of converted characters in some way. It would probably be easier (and more readable) to use a "for x in t:" construction: def convert(convert_this, ch): """Convert character ch if convert_this is True. Don't convert spaces. """ if convert_this: if ch == ' ': return (convert_this, ch) elif convert_this: return (False, ch.upper()) return (True, ch) convert_next = False result = '' for ch in s1: convert_next, ch = convert(convert_next, ch) result += ch print(result) # tHiS Is A TeSt There could be even more complications if you allow non-ascii characters but you were asking about processing character by character so I won't get into that. (You haven't specified the problem in enough detail to answer questions like those). [snip] -- https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
> On 29 May 2024, at 05:38, Kevin M. Wilson via Python-list > wrote: > > The format in this email is not of my making, should someone know, how to do > this so that it's a readable script do tell! > KMW Your mail program may have a plain-text mode to compose messages in try using that. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On 5/29/2024 8:55 AM, Kevin M. Wilson wrote:
Please recall, I said the format for the email failed to retain the
proper indents.
I'll attach a picture of the code!
Purpose; to uppercase every other letter in a string.
Thanks all, KMW
Simpler is good, and readability is good. For a simple conversion that
has a little touch of generality:
s1 = 'this is a test'
def convert(i, ch):
return ch.upper() if i % 2 else ch
result = ''.join([convert(i, ch) for i, ch in enumerate(s1)])
print(result) # tHiS Is a tEsT
However, this has a weakness: what to do about spaces. Should they be
counted among the characters to be uppercased? or should they not be
included in the count of the alternation? If you want to uppercase
every other letter that is not a space, things become a little more
complicated. And then do you want this to apply to all whitespace or
only spaces?
If you want to skip changing spaces, then you need to track the state of
converted characters in some way. It would probably be easier (and more
readable) to use a "for x in t:" construction:
def convert(convert_this, ch):
"""Convert character ch if convert_this is True.
Don't convert spaces.
"""
if convert_this:
if ch == ' ':
return (convert_this, ch)
elif convert_this:
return (False, ch.upper())
return (True, ch)
convert_next = False
result = ''
for ch in s1:
convert_next, ch = convert(convert_next, ch)
result += ch
print(result) # tHiS Is A TeSt
There could be even more complications if you allow non-ascii characters
but you were asking about processing character by character so I won't
get into that.
(You haven't specified the problem in enough detail to answer questions
like those).
***
"When you pass through the waters, I will be with you: and when you pass
through the rivers, they will not sweep over you. When you walk through
the fire, you will not be burned: the flames will not set you ablaze."
*Isaiah 43:2
*
On Wednesday, May 29, 2024 at 06:19:56 AM MDT, Thomas Passin via
Python-list wrote:
On 5/29/2024 3:14 AM, Chris Angelico via Python-list wrote:
> On Wed, 29 May 2024 at 16:03, Cameron Simpson via Python-list
> mailto:python-list@python.org>> wrote:
>> By which Thomas means stuff like this:
>>
>> print(f'if block {name[index]} and index {index}')
>>
>> Notice the leading "f'". Personally I wouldn't even go that far, just:
>>
>> print('if block', name[index], 'and index', index)
>>
>> But there are plenty of places where f-strings are very useful.
>
> I wouldn't replace str.format() everywhere, nor would I replace
> percent encoding everywhere - but in this case, I think Thomas is
> correct. Not because it's 2024 (f-strings were brought in back in
> 2015, so they're hardly chronologically special),
I only meant that they have been around for 9 years and are usually more
readable, so just change over already. I had some inertia over them
myself (imagine sticking with % formatting!) so I understand.
> but because most of
> this looks like debugging output that can take advantage of this
> feature:
>
> print(f"if block {name[index]=} {index=}")
>
> ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On 5/29/24 08:02, Grant Edwards via Python-list wrote:
On 2024-05-29, Chris Angelico via Python-list wrote:
print(f"if block {name[index]=} {index=}")
Holy cow! How did I not know about the f-string {=} thing?
It's more recent than f-strings in general, so it's not that hard to miss.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On 2024-05-29, Chris Angelico via Python-list wrote:
> print(f"if block {name[index]=} {index=}")
Holy cow! How did I not know about the f-string {=} thing?
--
Grant
--
https://mail.python.org/mailman/listinfo/python-list
Re: Formatted Output and Argument Parsing (was: Re: Flubbed it in the second interation through the string: range error... HOW?)
On Wed, 29 May 2024 at 23:06, Dan Sommers via Python-list wrote: > (For the history-impaired, getopt existed long before Python and will > likely exist long after it, but getopt's "replacement" optparse lasted > only from 2003 until 2011.) Depends on your definition of "lasted". It's not getting developed further, but it's still there. If you started using it, you're welcome to keep going. https://docs.python.org/3/library/optparse.html ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Formatted Output and Argument Parsing (was: Re: Flubbed it in the second interation through the string: range error... HOW?)
On 2024-05-29 at 17:14:51 +1000,
Chris Angelico via Python-list wrote:
> I wouldn't replace str.format() everywhere, nor would I replace
> percent encoding everywhere - but in this case, I think Thomas is
> correct. Not because it's 2024 (f-strings were brought in back in
> 2015, so they're hardly chronologically special), but because most of
> this looks like debugging output that can take advantage of this
> feature:
>
> print(f"if block {name[index]=} {index=}")
defsnark:
After years of getopt (and even more, if you include non-Python
experience), I'm glad I decided to wait a decade before chugging the
optparse koolaid.
(For the history-impaired, getopt existed long before Python and will
likely exist long after it, but getopt's "replacement" optparse lasted
only from 2003 until 2011.)
That said, I agree that the = thing makes f-strings eminently useful for
debugging, and I wholeheartedly agree with not fixing things that aren't
broken.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On 5/29/2024 3:14 AM, Chris Angelico via Python-list wrote:
On Wed, 29 May 2024 at 16:03, Cameron Simpson via Python-list
wrote:
By which Thomas means stuff like this:
print(f'if block {name[index]} and index {index}')
Notice the leading "f'". Personally I wouldn't even go that far, just:
print('if block', name[index], 'and index', index)
But there are plenty of places where f-strings are very useful.
I wouldn't replace str.format() everywhere, nor would I replace
percent encoding everywhere - but in this case, I think Thomas is
correct. Not because it's 2024 (f-strings were brought in back in
2015, so they're hardly chronologically special),
I only meant that they have been around for 9 years and are usually more
readable, so just change over already. I had some inertia over them
myself (imagine sticking with % formatting!) so I understand.
but because most of
this looks like debugging output that can take advantage of this
feature:
print(f"if block {name[index]=} {index=}")
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On 2024-05-29 05:33, Kevin M. Wilson via Python-list wrote:
The following is my effort to understand how to process a string, letter, by
letter:
def myfunc(name): index = 0 howmax = len(name) # while (index <=
howmax): while (index < howmax): if (index % 2 == 0):
print('letter to upper = {}, index {}!'.format(name[index], index)) name =
name[index].upper() print('if block {} and index {}'.format(name[index],
index)) elif (index % 2 > 0): print(index) print('Start:
elseif block, index is {}, letter is {}'.format(index, name)) # print('letter
to lower = {}'.format(name[index])) # print('Already lowercase do noting:
name = {}'.format(name[index])) index += 1 # index = name.upper()
return name
myfunc('capitalism')
Error message: Not making sense, index is 1, letter s/b
'a'letter to upper = c, index 0!
if block C and index 0
1
Start: elseif block, index is 1, letter is C
---
IndexErrorTraceback (most recent call last)
Cell In[27], line 21
17 # index = name.upper()
19 return name
---> 21 myfunc('capitalism')
Cell In[27], line 8, in myfunc(name)
6 while (index < howmax):
7 if (index % 2 == 0):
> 8 print('letter to upper = {}, index {}!'.format(name[index],
index))
9 name = name[index].upper()
10 print('if block {} and index {}'.format(name[index], index))
IndexError: string index out of
range***
So, I'm doing something... Stupid!!
***
"When you pass through the waters, I will be with you: and when you pass through the
rivers, they will not sweep over you. When you walk through the fire, you will not be
burned: the flames will not set you ablaze."
Isaiah 43:2
I think the code is this:
def myfunc(name):
index = 0
howmax = len(name)
# while (index <= howmax):
while (index < howmax):
if (index % 2 == 0):
print('letter to upper = {}, index {}!'.format(name[index],
index))
name = name[index].upper()
print('if block {} and index {}'.format(name[index], index))
elif (index % 2 > 0):
print(index)
print('Start: elseif block, index is {}, letter is
{}'.format(index, name))
# print('letter to lower = {}'.format(name[index]))
# print('Already lowercase do noting: name =
{}'.format(name[index]))
index += 1
# index = name.upper()
return name
myfunc('capitalism')
What is:
name = name[index].upper()
meant to be doing?
What it's _actually_ doing is getting the character at a given index,
converting it to uppercase, and then assigning it to `name`, so `name`
is now 1 character long.
It doesn't this when 'index' is 0, so after the first iteration, `name`
is a single-character string.
On the second iteration it raises IndexError because the string is only
1 character long and you're asking for `name[1]`.
--
https://mail.python.org/mailman/listinfo/python-list
Re: SOLVED! Re: Weird Stuff (Markdown, syntax highlighting and Python)
On Tue, May 28, 2024 at 9:48 PM Gilmeh Serda via Python-list < python-list@python.org> wrote: > > Solved by using a different method. > > - - - And that was how? TIA -- https://mail.python.org/mailman/listinfo/python-list
Re: Flubbed it in the second interation through the string: range error... HOW?
On Wed, 29 May 2024 at 16:03, Cameron Simpson via Python-list
wrote:
> By which Thomas means stuff like this:
>
> print(f'if block {name[index]} and index {index}')
>
> Notice the leading "f'". Personally I wouldn't even go that far, just:
>
> print('if block', name[index], 'and index', index)
>
> But there are plenty of places where f-strings are very useful.
I wouldn't replace str.format() everywhere, nor would I replace
percent encoding everywhere - but in this case, I think Thomas is
correct. Not because it's 2024 (f-strings were brought in back in
2015, so they're hardly chronologically special), but because most of
this looks like debugging output that can take advantage of this
feature:
print(f"if block {name[index]=} {index=}")
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
