Re: questions re: calendar module
On 31/07/2020 02:52, o1bigtenor wrote: I regularly work in planning through multiple years at once. This means that I like to have a lot of stuff available in a calendar function. Python seems to be locked when I need to display more than 1 year at a time. I don't see a way to display something like 3 years worth of calendar starting at a point 23 months from now. (I see how to display 1 year at a time but not multiple years.) This question seems a little vague. How are you creating this "calendar function"? Are you using the Python Standard Library calendar, or perhaps talking about datetime calculations? Please copy-paste code showing this "lock". -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Issue with Python installation for a beginner Python coder.
On Thu, Jul 30, 2020 at 9:24 AM Sarvesh Poddar via Python-list wrote: > I re-installed Python in my Windows system as the earlier one was not able to > import modules... You do not provide much detail to diagnose what your problem(s) is(are). By the "earlier one" is it the same version as the one you re-installed? Were you able to run IDLE with the "earlier one"? By not being able to import modules do you mean modules from Python's standard library? Or do you mean installing third party libraries using pip? > ...But now I am not able to open IDLE after multiple tries. Have you looked in your start menu in the list of installed programs for Python? If it is there did you expand it and see if there is an entry for IDLE? How have you been trying (unsuccessfully) to open IDLE? -- boB -- https://mail.python.org/mailman/listinfo/python-list
Re: Winreg
On 31/07/2020 16:48, R Pasco wrote: Thanks for your extensive info. Its too bad this isn't published in the python winreg/_winreg modules' info. Ray Pasco Welcome to the world of documentation! Perhaps you have 'discovered' something, or maybe you're using the tool in an unusual way, or maybe the docs are too sketchy (I'm not a user of MS-Win, so can't comment). Regardless, the documentation team would welcome a contribution based upon this discussion and your learning... The best way to ensure you have learned something thoroughly is to explain it to others! -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Downloading Python
Hello to whoever this may concern, After downloading Python 3.8.5 IDLE, an error message popped up, saying the code execution cannot proceed because python38.dll was not found. What should I do in order to use the Python interpreter? Thank you! -- https://mail.python.org/mailman/listinfo/python-list
Re: "1,+2,", but not "(1,)+2,"
On Sat, Aug 1, 2020 at 4:31 AM Jon Ribbens via Python-list wrote: > > On 2020-07-31, Bart wrote: > > Not sure about the trailing commas on each. It seems Python ignores > > trailing commas on tuple constructors, so that the A,B, would be a > > 2-tuple, and A+B, would have been a 1-tuple if A+B had been legal. > > It's not just tuples, it's lists, sets, dictionaries, etc. And function parameters and basically anything that permits a comma-separated sequence. Or any other sort of sequence. You can have multiple simple statements on one line, separated by semicolons - and it's legal to have a spare semi at the end. It's REALLY annoying to run into those few cases where that doesn't work (JSON, and the SQL "create table" statement, and a handful of others). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: "1,+2,", but not "(1,)+2,"
On 2020-07-31, Bart wrote:
> Not sure about the trailing commas on each. It seems Python ignores
> trailing commas on tuple constructors, so that the A,B, would be a
> 2-tuple, and A+B, would have been a 1-tuple if A+B had been legal.
It's not just tuples, it's lists, sets, dictionaries, etc. It's very
useful because it means that when editing source code to add new items
or to rearrange items you don't need to worry about the commas. e.g.:
animals = {
'cow': 'mammal',
'spider': 'arachnid',
'turtle': 'reptile',
}
If you want to add a new item to or remove an existing item from the
dictionary, you only need to edit one line, and it doesn't matter if
that line is in the middle or at the end of the existing entries.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Winreg
My code was just experimental and will be much refined in the future which will include specific exception catches. Connecting to the local registry is to 'go the last yard' for a full-blown implementation. I had a hard time grasping the Windows registry concept of having to first get a key handle for the parent keypath and then specifying an already existing fina/'leaf' key as a string in order to simply read the key's valuename/value data. Who can tell what they were thinking at the time! It seems like a good idea to "abstract" this out since it seems overly complicated and needlessly confusing. Thanks for your extensive info. Its too bad this isn't published in the python winreg/_winreg modules' info. Ray Pasco On Fri, Jul 31, 2020 at 12:43 AM R Pasco wrote: > My code was simply experimental and will be much refined in the future > which will include specific exception catches. Connecting to the local > registry is to go the 'last yard' for a full implementation. > > I had a hard time grasping the Windows registry concept of having to first > get a key handle for the parent keypath and then specifying an already > existing final or 'leaf' key as a string in order to simply read the key's > valuename/value data. Who can tell what they were thinking at the time! It > seems like a good idea to "abstract" this out since it seems overly > complicated and needlessly confusing. > > Thanks for your extensive info. Its too bad this isn't published in the > python winreg/_winreg modules' info. > Ray Pasco > > > > On Thu, Jul 30, 2020 at 11:53 PM Eryk Sun wrote: > >> On 7/30/20, R Pasco wrote: >> >> > access rights must be set to [winreg.KEY_ALL_ACCESS | >> winreg.KEY_WOW64_64KEY >> >> It's a bad practice to request more access than you require, at the >> very least because the request may fail with access denied for no good >> reason. >> >> KEY_ALL_ACCESS includes all applicable standard rights (WRITE_OWNER, >> WRITE_DAC, READ_CONTROL, DELETE) and all key rights (KEY_QUERY_VALUE, >> KEY_SET_VALUE, KEY_CREATE_SUB_KEY, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY, >> KEY_CREATE_LINK). For an existing key, do you need to change the >> owner, read and modify the security, delete the key, set a symlink, >> etc? It looks like you just need to set a value, i.e. KEY_SET_VALUE. >> >> > winreg.KEY_WOW64_32KEY] (??? Why does this also work ?) >> >> By default a 64-bit process doesn't see redirected keys, but if you >> need to access them, use KEY_WOW64_32KEY in the desired access. >> Normally a 32-bit process under WOW64 sees redirected keys, and if you >> need to access the non-redirected keys, use KEY_WOW64_64KEY. >> >> Note that KEY_WOW64_64KEY and KEY_WOW64_32KEY access modes only affect >> runtime redirection. As with the standard MAXIMUM_ALLOWED access mode, >> they're not assignable rights that can be granted or denied in a key >> object's access control list. >> >> > with winreg.ConnectRegistry( None, hive ) as hivehndl >> >> There is no need to call ConnectRegistry here. By default, predefined >> handles are resolved to local key handles. Also, if you actually need >> to access a remote machine, note that it's nonsensical to try to >> connect to HKEY_CURRENT_USER. The API allows it, but why would one >> assume that the remote machine will have a profile for the current >> user's SID? The remote system will most likely just connect to a >> handle for the default user profile. >> >> > The key HKEY_LOCAL_MACHINE:SOFTWARE requires KEY_WOW64_64KEY >> > to be 'OR'ed. Winreg gives no indication of this requirement, but the >> > Windows doc "Redirected, Shared, and Reflected Keys Under WOW64" does >> > specifically mention HKEY_CURRENT_USER :SOFTWARE as needing this added >> > access. >> >> At the machine level, the software hive is stored on disk at >> "%SystemRoot%\System32\config\SOFTWARE" and mounted at >> "\REGISTRY\MACHINE\SOFTWARE". For a WOW64 process, by default there is >> extensive runtime redirection of keys in this hive to the subkeys >> "WOW6432Node" and "Classes\WOW6432Node". >> >> At the user level, there are two hives mounted. The user profile is >> stored on disk at "%USERPROFILE%\NTUSER.DAT" and mounted at >> "\REGISTRY\USER\", where "" is the string form of the user's >> security identifier (e.g. "S-1-5-21"). For >> a WOW64 process, there is no redirection of subkeys that are >> physically stored in this hive. >> >> The user's software classes hive is stored on disk at >> "%LOCALAPPDATA%\Microsoft\Windows\UsrClass.dat" and mounted at >> "\REGISTRY\USER\_Classes". In the user profile, the >> "Software\Classes" key is a symbolic link to the latter. For a WOW64 >> process, some subkeys in the classes hive are redirected to subkeys in >> "WOW6432Node" (i.e. "Software\Classes\WOW6432Node"). It's just a >> limited subset, including "CLSID", "DirectShow", "Interface", "Media >> Type", and "MediaFoundation". >> >> --- >> >> One never sees "\REGISTRY\MACHINE" and "\REGISTRY\USER" in the >> registry API b
Re: "1,+2,", but not "(1,)+2,"
Stefan Ram wrote: Jon Ribbens writes: On 2020-07-31, Stefan Ram wrote: You can write |>>> 1,+2, |(1, 2) , but not |>>> (1,)+2, |TypeError: can only concatenate tuple (not "int") to tuple . Why? (Python 3.9) For the obvious reason, as indicated by the error message? What are you expecting these expressions to mean? In »1,+2,«, the right operand »2,« obviously is interpreted to be a 1-tuple. Nope. The right operant is 2 not 2, and is interpreted as an int. -- https://mail.python.org/mailman/listinfo/python-list
Re: "1,+2,", but not "(1,)+2,"
On 2020-07-31 14:15, Jon Ribbens via Python-list wrote: On 2020-07-31, Stefan Ram wrote: You can write |>>> 1,+2, |(1, 2) , but not |>>> (1,)+2, |TypeError: can only concatenate tuple (not "int") to tuple . Why? (Python 3.9) For the obvious reason, as indicated by the error message? What are you expecting these expressions to mean? (For some reason, I haven't received Stefan's original post.) It's all to do with operator precedence. The '+' has a higher precedence than the ',', so: 1,+2, is parsed as: (1),(+2), NOT as: (1,)+(2,) although they happen to give the same answer. On the other hand: (1,)+2, is parsed as: ((1,)+2), which results in a TypeError. -- https://mail.python.org/mailman/listinfo/python-list
Re: "1,+2,", but not "(1,)+2,"
On 2020-07-31, Stefan Ram wrote: > You can write > >|>>> 1,+2, >|(1, 2) > > , but not > >|>>> (1,)+2, >|TypeError: can only concatenate tuple (not "int") to tuple > > . Why? (Python 3.9) For the obvious reason, as indicated by the error message? What are you expecting these expressions to mean? -- https://mail.python.org/mailman/listinfo/python-list
