Re: Is there a conflict of libraries here?
On 11/8/20 9:20 PM, Chris Angelico wrote: Perhaps, but certainly the confusion is far less when the module is always imported as itself, and then the class is "datetime.datetime" which nicely parallels "datetime.date" and "datetime.time". I find doubled names such as "datetime.datetime" both jarring and visual noise. Thankfully, we can rename modules on import: import datetime as dt import time as t import PIL.Image as im As for "from blablah import *" -- that should only be done with modules specifically designed for it; having said that, it looks like datetime.py was so designed. So, if I had a module making extensive use of the datetime contents, and wasn't using the time module, I would have no problem with "from datetime import *". On the other hand, if datetime was only a small portion of my module, I would "import datetime as dt". -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On Mon, Nov 9, 2020 at 3:32 PM Terry Reedy wrote: > > On 11/8/2020 9:56 AM, Chris Angelico wrote: > > On Mon, Nov 9, 2020 at 1:11 AM Terry Reedy wrote: > > >> A module containing an object with the same name as the module is a real > >> pain, a constant mental papercut. I consider datetime.datetime to be a > >> design mistake*. You are the 2nd person in about a month to post the > >> same resulting code problem. > >> > >> * Either the class should have been 'Datetime', capitalized like classes > >> in modules other that builtins generally should be, or the module should > >> have been given a different name. I personally would always rename the > >> module when imported. > >> > > > > Yes, it's annoying, but it's only annoying when code on the internet > > suggests "from datetime import *", > > I agree that the latter is annoying, but I disagree about 'only'. Names > pointing to two different objects (or people ;-) are ambiguous without > additional disambiguation. If I write 'datetime has an off-by-one bug' > or 'datetime is great', which datetime do I mean? Perhaps, but certainly the confusion is far less when the module is always imported as itself, and then the class is "datetime.datetime" which nicely parallels "datetime.date" and "datetime.time". If we could abuse Guido's time machine and have them as "datetime.DateTime" etc, I would definitely be in favour of it. I don't know that it'd be worth actually changing, though, and even adding aliases doesn't really seem worthwhile IMO. > idlelib once had multiple name.name pairs, such as Debugger.Debugger, > and to me, the nuisance of fixing them (as per PEP 434 and subsequent > decision by the BDFL-delegate) has now been outweighed by the continuing > benefit. Yes, but the nuisance of fixing internal idlelib details isn't nearly as strong as renaming a public class :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/8/2020 9:56 AM, Chris Angelico wrote: On Mon, Nov 9, 2020 at 1:11 AM Terry Reedy wrote: A module containing an object with the same name as the module is a real pain, a constant mental papercut. I consider datetime.datetime to be a design mistake*. You are the 2nd person in about a month to post the same resulting code problem. * Either the class should have been 'Datetime', capitalized like classes in modules other that builtins generally should be, or the module should have been given a different name. I personally would always rename the module when imported. Yes, it's annoying, but it's only annoying when code on the internet suggests "from datetime import *", I agree that the latter is annoying, but I disagree about 'only'. Names pointing to two different objects (or people ;-) are ambiguous without additional disambiguation. If I write 'datetime has an off-by-one bug' or 'datetime is great', which datetime do I mean? idlelib once had multiple name.name pairs, such as Debugger.Debugger, and to me, the nuisance of fixing them (as per PEP 434 and subsequent decision by the BDFL-delegate) has now been outweighed by the continuing benefit. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/7/20 9:26 PM, Terry Reedy wrote: > On 11/6/2020 5:05 PM, Steve wrote: >> "Right, because the name "datetime" points to the class datetime in the >> module datetime. > > A module containing an object with the same name as the module is a > real pain, a constant mental papercut. I consider datetime.datetime > to be a design mistake*. You are the 2nd person in about a month to > post the same resulting code problem. > > * Either the class should have been 'Datetime', capitalized like > classes in modules other that builtins generally should be, or the > module should have been given a different name. I personally would > always rename the module when imported. > Which says that if you do: import datetime from datetime import datatime as Datatime you get the class in your module as the more modern capitalized name, and avoid the name conflict. It just says that in your code, to use the class you either need to use Datatime or datetime.datetime -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On Mon, Nov 9, 2020 at 1:11 AM Terry Reedy wrote: > > On 11/6/2020 5:05 PM, Steve wrote: > > "Right, because the name "datetime" points to the class datetime in the > > module datetime. > > A module containing an object with the same name as the module is a real > pain, a constant mental papercut. I consider datetime.datetime to be a > design mistake*. You are the 2nd person in about a month to post the > same resulting code problem. > > * Either the class should have been 'Datetime', capitalized like classes > in modules other that builtins generally should be, or the module should > have been given a different name. I personally would always rename the > module when imported. > Yes, it's annoying, but it's only annoying when code on the internet suggests "from datetime import *", which IMO is the real mental papercut. If everything was written assuming "import datetime", there'd be only a very minor confusion. So, my suggestion to anyone who's struggling with datetime is: Don't ever write "from datetime import *" or "from datetime import datetime". Your code may break in the short term, but if it does, it's a solvable break. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
ha! ha! 2 empowering___ we make it. __ +44 1635 887711 On Sunday, November 8, 2020, 01:06:03 a.m. PST, Cameron Simpson wrote: On 07Nov2020 22:57, Steve wrote: >Ok, the light just went out. >I thought I was getting something, but no... > >I will keep on reading, maybe it will hatch. You're probably overthinking this. I'll address your new example below. First up: numbers are objects, strings are objects, classes are objects, modules are objects. A variable can refer to any of them. So when you do an import you're setting a name to refer to a module, or to refer to something from within a module. Consider this: x = 3 x = 4 What is x? It's 4, because that happened second. An import is just a special form of assignment statement, with an implicit module load behind the scenes. So consider this: import datetime from datetime import datetime Each of these assigns to the name "datetime". The former assigns the module named "datetime". The latter assigns the _class_ named 'datetime" from inside the module. One happens after the other, so after this the name "datetime" refers to the class. Alternatively: import datetime datetime = datetime.datetime "datetime" starts referring to the datetime module. Then we reassign it to the "datetime" class that is inside the module. The effect is the same as the previous pair of lines. It is unfortunate that the "datetime" module contains a "datetime" class. It makes for a lot of confusion. Modern classes start with uppercase letters (entirely by convention), which reduces this issue - you have a better idea of what you're looking at just from the name. It's been mentioned in this thread, but perhaps been as obvious as it could have been: if you need to refer to the module "datetime", and also the class "datetime" from within it, assign them to different variables: import datetime dt = datetime.datetime Now you have "datetime" referring to the module, and "dt" referring to the class. >Maybe a different approach. >What is happening here? >(Should this be a new thread?) No, keep the thread -it is the same discussion and really the same issue. It keeps it all together for us, too. >import tkinter as tk Equivalent to this: import sys tk = sys.modules['tkinter'] >from tkinter import * a = sys.modules['tkinter'].a b = sys.modules['tkinter'].b c = sys.modules['tkinter'].c ... for each name defined in the tkinter module. Try to avoid this incantation - it sucks in a large uncontrolled list of names into your script. Some small scripts do it for simple things where's they're really working against only one module. In most things it is unhelpful. >from tkinter import ttk ttk = sys.modules['tkinter'].ttk All of these 3 things set local variables/names in your script to some value. The "*" import sets a bunch of variables. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/6/2020 5:05 PM, Steve wrote: "Right, because the name "datetime" points to the class datetime in the module datetime. A module containing an object with the same name as the module is a real pain, a constant mental papercut. I consider datetime.datetime to be a design mistake*. You are the 2nd person in about a month to post the same resulting code problem. * Either the class should have been 'Datetime', capitalized like classes in modules other that builtins generally should be, or the module should have been given a different name. I personally would always rename the module when imported. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 07Nov2020 22:57, Steve wrote: >Ok, the light just went out. >I thought I was getting something, but no... > >I will keep on reading, maybe it will hatch. You're probably overthinking this. I'll address your new example below. First up: numbers are objects, strings are objects, classes are objects, modules are objects. A variable can refer to any of them. So when you do an import you're setting a name to refer to a module, or to refer to something from within a module. Consider this: x = 3 x = 4 What is x? It's 4, because that happened second. An import is just a special form of assignment statement, with an implicit module load behind the scenes. So consider this: import datetime from datetime import datetime Each of these assigns to the name "datetime". The former assigns the module named "datetime". The latter assigns the _class_ named 'datetime" from inside the module. One happens after the other, so after this the name "datetime" refers to the class. Alternatively: import datetime datetime = datetime.datetime "datetime" starts referring to the datetime module. Then we reassign it to the "datetime" class that is inside the module. The effect is the same as the previous pair of lines. It is unfortunate that the "datetime" module contains a "datetime" class. It makes for a lot of confusion. Modern classes start with uppercase letters (entirely by convention), which reduces this issue - you have a better idea of what you're looking at just from the name. It's been mentioned in this thread, but perhaps been as obvious as it could have been: if you need to refer to the module "datetime", and also the class "datetime" from within it, assign them to different variables: import datetime dt = datetime.datetime Now you have "datetime" referring to the module, and "dt" referring to the class. >Maybe a different approach. >What is happening here? >(Should this be a new thread?) No, keep the thread -it is the same discussion and really the same issue. It keeps it all together for us, too. >import tkinter as tk Equivalent to this: import sys tk = sys.modules['tkinter'] >from tkinter import * a = sys.modules['tkinter'].a b = sys.modules['tkinter'].b c = sys.modules['tkinter'].c ... for each name defined in the tkinter module. Try to avoid this incantation - it sucks in a large uncontrolled list of names into your script. Some small scripts do it for simple things where's they're really working against only one module. In most things it is unhelpful. >from tkinter import ttk ttk = sys.modules['tkinter'].ttk All of these 3 things set local variables/names in your script to some value. The "*" import sets a bunch of variables. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
RE: Is there a conflict of libraries here?
Ok, the light just went out. I thought I was getting something, but no... I will keep on reading, maybe it will hatch. Maybe a different approach. What is happening here? (Should this be a new thread?) import tkinter as tk from tkinter import * from tkinter import ttk -- Footnote: Mars is the only known planet in our solar system solely inhabited by functioning robots. -Original Message- From: Python-list On Behalf Of Peter J. Holzer Sent: Saturday, November 7, 2020 2:33 PM To: python-list@python.org Subject: Re: Is there a conflict of libraries here? On 2020-11-07 13:26:30 -0500, Steve wrote: > Ok, I think I see a light in the fog. > > It looks as if I can identify a variable to contain a library. > > Import datetime as dt1 > > I guess that I can have a second variable containing that same library: > > Import datetime as dt2 > > Should I presume that not doing this is what caused the interference > in my code? Not quite. The problem isn't that you imported the library twice, but that you have a library (package/module) and a class of the same name. When you try to import both with that name, only one of them will be visible, since you can't have one name refer to two different things at the same time. >>> import datetime The name datetime now refers to the module datetime: >>> datetime >>> id(datetime) 140407076788160 >>> from datetime import datetime Now the name datetime now refers to the class datetime: >>> datetime >>> id(datetime) 9612160 You can import one or both of them with different names: >>> import datetime as dt_module >>> dt_module >>> id(dt_module) 140407076788160 >>> from datetime import datetime as dt_class dt_class >>> id(dt_class) 9612160 hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/7/20 11:26 AM, Steve wrote:
Ok, I think I see a light in the fog.
It looks as if I can identify a variable to contain a library.
Import datetime as dt1
I guess that I can have a second variable containing that same library:
Import datetime as dt2
Should I presume that not doing this is what caused the interference in my
code?
In your example:
import datetime as dt
from datetime import datetime
globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': , 'dt': ,
'datetime': }
How does your line3 and line2 relate to line1?
It looks as if they relate to dt but it is not specifically stated. Is it
because they are consecutive lines?
In the list of globals, I see :{}, seems bizarre..
it was just to show that the symbol 'dt' refers to the module object for
datetime, and the symbol 'datetime' refers to the datetime class from
the datetime module - since they're different names they can coexist;
earlier when you imported both as datetime, the second one overwrote the
first one. Sorry, I'm probably confusing you more.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 2020-11-07 13:26:30 -0500, Steve wrote: > Ok, I think I see a light in the fog. > > It looks as if I can identify a variable to contain a library. > > Import datetime as dt1 > > I guess that I can have a second variable containing that same library: > > Import datetime as dt2 > > Should I presume that not doing this is what caused the interference in my > code? Not quite. The problem isn't that you imported the library twice, but that you have a library (package/module) and a class of the same name. When you try to import both with that name, only one of them will be visible, since you can't have one name refer to two different things at the same time. >>> import datetime The name datetime now refers to the module datetime: >>> datetime >>> id(datetime) 140407076788160 >>> from datetime import datetime Now the name datetime now refers to the class datetime: >>> datetime >>> id(datetime) 9612160 You can import one or both of them with different names: >>> import datetime as dt_module >>> dt_module >>> id(dt_module) 140407076788160 >>> from datetime import datetime as dt_class >>> dt_class >>> id(dt_class) 9612160 hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
RE: Is there a conflict of libraries here?
Ok, I think I see a light in the fog.
It looks as if I can identify a variable to contain a library.
Import datetime as dt1
I guess that I can have a second variable containing that same library:
Import datetime as dt2
Should I presume that not doing this is what caused the interference in my
code?
In your example:
>>> import datetime as dt
>>> from datetime import datetime
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': , 'dt': ,
'datetime': }
How does your line3 and line2 relate to line1?
It looks as if they relate to dt but it is not specifically stated. Is it
because they are consecutive lines?
In the list of globals, I see :{}, seems bizarre..
Is my dt1 now a variable containing the properties of datetime and they are
listed between { } and available globally.
Do I then have dt1.datetime and dt2.datetime as separate instances?
Is that how they are identified? How are they applied?
More questions will follow.
Step by step, slowly I turned..
Steve
98% of lawyers give the other 2% a bad name.
-Original Message-
From: Python-list On
Behalf Of Mats Wichmann
Sent: Friday, November 6, 2020 5:57 PM
To: python-list@python.org
Subject: Re: Is there a conflict of libraries here?
On 11/6/20 3:05 PM, Steve wrote:
> "Right, because the name "datetime" points to the class datetime in
> the module datetime.
> The class, unlike the module, has no "datetime" attribute."
>
>
>
> Ok, how do I unpoint/repoint a "datetime" to let the two locations work?
>
>
>
> "Apologies if you already knew this. I wasn't sure."
>
>
>
> Absolutely did not know any of this.
> Libraries are a slow learning process for me
>
The Python import command does some stuff behind the scenes, but from the
programmer viewpoint, you're just manipulating names in namespaces - making
a mapping of a name to the relevant object.
import boo
gives you a name 'boo' in the relevant namespace, which refers to the module
object made for boo when it was imported (that's some of the behind the
scenes stuff).
A quick interactive sample showing this in action:
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': }
>>> import sys
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': , 'sys': }
here's the case you are running into:
>>> import datetime
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': , 'datetime': }
>>> from datetime import datetime
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': , 'datetime': }
If you want to import the datetime class and still have the full datetime
module available, you can for example import as a different name - here's a
sample of that:
>>> import datetime as dt
>>> from datetime import datetime
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': , 'dt': , 'datetime': }
Does this make it clearer?
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 11/6/20 3:05 PM, Steve wrote:
"Right, because the name "datetime" points to the class datetime in the
module datetime.
The class, unlike the module, has no "datetime" attribute."
Ok, how do I unpoint/repoint a "datetime" to let the two locations work?
"Apologies if you already knew this. I wasn't sure."
Absolutely did not know any of this.
Libraries are a slow learning process for me
The Python import command does some stuff behind the scenes, but from
the programmer viewpoint, you're just manipulating names in namespaces -
making a mapping of a name to the relevant object.
import boo
gives you a name 'boo' in the relevant namespace, which refers to the
module object made for boo when it was imported (that's some of the
behind the scenes stuff).
A quick interactive sample showing this in action:
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': }
>>> import sys
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': (built-in)>, 'sys': }
here's the case you are running into:
>>> import datetime
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': (built-in)>, 'datetime': '/usr/lib64/python3.8/datetime.py'>}
>>> from datetime import datetime
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': (built-in)>, 'datetime': }
If you want to import the datetime class and still have the full
datetime module available, you can for example import as a different
name - here's a sample of that:
>>> import datetime as dt
>>> from datetime import datetime
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None,
'__loader__': , '__spec__':
None, '__annotations__': {}, '__builtins__': (built-in)>, 'dt': '/usr/lib64/python3.8/datetime.py'>, 'datetime': 'datetime.datetime'>}
Does this make it clearer?
--
https://mail.python.org/mailman/listinfo/python-list
RE: Is there a conflict of libraries here?
"Right, because the name "datetime" points to the class datetime in the module datetime. The class, unlike the module, has no "datetime" attribute." Ok, how do I unpoint/repoint a "datetime" to let the two locations work? "Apologies if you already knew this. I wasn't sure." Absolutely did not know any of this. Libraries are a slow learning process for me Footnote Patient in the hospital: "What happens after I die?" Doctor: "We clean up the bed and bring in a new patient." -Original Message- From: Python-list On Behalf Of Peter Pearson Sent: Friday, November 6, 2020 10:36 AM To: python-list@python.org Subject: Re: Is there a conflict of libraries here? On Fri, 6 Nov 2020 02:25:25 -0500, Steve wrote: > In my program, I have the following lines of code: > import random > import re > import time > import datetime At this point, the name "datetime" points to a module. > from datetime import timedelta > from time import gmtime, strftime > import winsound as ws > import sys > [snip] > > from datetime import datetime By that, you have reassigned the name "datetime" to point to a class defined in the datetime module. [snip] > > AttributeError: type object 'datetime.datetime' has no attribute > 'datetime' Right, because the name "datetime" points to the class datetime in the module datetime. The class, unlike the module, has no "datetime" attribute. Apologies if you already knew this. I wasn't sure. -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On Fri, 6 Nov 2020 02:25:25 -0500, Steve wrote: > In my program, I have the following lines of code: > import random > import re > import time > import datetime At this point, the name "datetime" points to a module. > from datetime import timedelta > from time import gmtime, strftime > import winsound as ws > import sys > [snip] > > from datetime import datetime By that, you have reassigned the name "datetime" to point to a class defined in the datetime module. [snip] > > AttributeError: type object 'datetime.datetime' has no attribute > 'datetime' Right, because the name "datetime" points to the class datetime in the module datetime. The class, unlike the module, has no "datetime" attribute. Apologies if you already knew this. I wasn't sure. -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 06Nov2020 09:36, Frank Millman wrote:
>On 2020-11-06 9:25 AM, Steve wrote:
>>In my program, I have the following lines of code:
>> import datetime
>> from datetime import timedelta
>>
>> from time import gmtime, strftime ##define strftime as time/date right
>>now
>>If I add the code:
>>
>> from datetime import datetime
>>
>>these new lines work:
>>
>>dt = datetime.fromisoformat(ItemDateTime)
>>
>>dt_string = dt.strftime(' at %H:%M on %A %d %B %Y')
>>
>>and will fail without that "datetime import datetime" line
Right, because you're using the datetime _class_ to get the
fromisoformat factory function.
>>however;
>>
>>
>>With that "datetime import datetime" line included,
>>
>>all of the lines of code throughout the program that contain
>>"datetime.datetime" fail.
>>These have been in use for over three years and there are at least a dozen
>>of them.
Yeah. because _those_ lines are using the name "datetime" as the module
name.
Just replace "datetime.datetime" throughout with "datetime". Your code
will be more readable anyway.
>>The error produced is:
>>
>> time1 = datetime.datetime.strptime(T1, date_format)
>>
>> AttributeError: type object 'datetime.datetime' has no attribute
>>'datetime'
That is because "datetime" is currently the class, not the module.
>1. Remove the line 'from datetime import datetime'.
>
>2. Change dt = datetime.fromisoformat(ItemDateTime) to
> dt = datetime.datetime.fromisoformat(ItemDateTime)
>
>Unless I have missed something, that should work.
That will work, but produces verbose code. I prefer to import things
_from_ the datetime module, letting me drop the 'datetime." module
prefix across the code.
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is there a conflict of libraries here?
On 2020-11-06 9:25 AM, Steve wrote:
In my program, I have the following lines of code:
import random
import re
import time
import datetime
from datetime import timedelta
from time import gmtime, strftime ##define strftime as time/date right
now
import winsound as ws
import sys
These may or may not affect my new program code but here is the issue:
If I add the code:
from datetime import datetime
these new lines work:
dt = datetime.fromisoformat(ItemDateTime)
dt_string = dt.strftime(' at %H:%M on %A %d %B %Y')
and will fail without that "datetime import datetime" line
however;
With that "datetime import datetime" line included,
all of the lines of code throughout the program that contain
"datetime.datetime" fail.
These have been in use for over three years and there are at least a dozen
of them.
The error produced is:
time1 = datetime.datetime.strptime(T1, date_format)
AttributeError: type object 'datetime.datetime' has no attribute
'datetime'
I think all you have to do is -
1. Remove the line 'from datetime import datetime'.
2. Change dt = datetime.fromisoformat(ItemDateTime) to
dt = datetime.datetime.fromisoformat(ItemDateTime)
Unless I have missed something, that should work.
Frank Millman
--
https://mail.python.org/mailman/listinfo/python-list
Is there a conflict of libraries here?
In my program, I have the following lines of code:
import random
import re
import time
import datetime
from datetime import timedelta
from time import gmtime, strftime ##define strftime as time/date right
now
import winsound as ws
import sys
These may or may not affect my new program code but here is the issue:
If I add the code:
from datetime import datetime
these new lines work:
dt = datetime.fromisoformat(ItemDateTime)
dt_string = dt.strftime(' at %H:%M on %A %d %B %Y')
and will fail without that "datetime import datetime" line
however;
With that "datetime import datetime" line included,
all of the lines of code throughout the program that contain
"datetime.datetime" fail.
These have been in use for over three years and there are at least a dozen
of them.
The error produced is:
time1 = datetime.datetime.strptime(T1, date_format)
AttributeError: type object 'datetime.datetime' has no attribute
'datetime'
How do I have my cake and eat it too?
Steve
Footnote:
Some mornings it just isn't worth chewing through the leather straps.
--
https://mail.python.org/mailman/listinfo/python-list
