Re: Issues regarding running of application.

[Barry Scott]

> On 26 May 2020, at 15:45, Meet Agrawal  wrote:
> 
> I have tried and installed the python application a lot of times but after
> the installation get completed and I try to run the application, it say
> that api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer.


That DLL is part of modern Windows.

Which version of Windows are you using?

Barry


> 
> Please tell me a way out.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Barry Scott]

> On 26 May 2020, at 17:46, MRAB  wrote:
> 
> On 2020-05-26 16:48, BlindAnagram wrote:
>> On 26/05/2020 16:22, Ben Bacarisse wrote:
>>> BlindAnagram  writes:
 I came across an issue that I am wondering whether I should report as an
 issue.  If I have a directory, say:
 
  base='C:\\Documents'
 
 and I use os.path.join() as follows:
 
  join(base, '..\\..\\', 'build', '')
>>> It rather defeats the purpose of os.sep if you include it in a part of
>>> the path.  What you mean is better expressed as
>>>  join(base, '..', '..', 'build', '')
>>> (and base includes it too, but I can't suggest an alternative because I
>>> don't know your intent is far as defaults go.)
>> Thanks for your input but while that part of my path may not be to your
>> liking, it works fine and does not seem to be relevant to my concern,
>> which is that join appears to treat os.sep as an absolute path, which it
>> is not.
> If it starts with the path separator, then it's absolute (well, absolute on 
> that drive).
> 
> Open a Command Prompt window and it'll open in the %HOME% folder. Then type 
> "cd \" and it'll put you in the root folder.

HOME is not defined by windows.

I have theses:

HOMEDRIVE=C:
HOMEPATH=\Users\barry
USERPROFILE=C:\Users\barry

I have always use USERPROFILE in place of HOME on Windows.

Barry


> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Issues regarding running of application.

[Souvik Dutta]

Do have the latest version of DirectX installed? If not then do that or you
can google out the dll file you need (or is missing) and download it and
cut - paste it wherever needed. Missing dll files is a very common issue in
windows and thus Microsoft made DirectX.

On Tue, 26 May, 2020, 11:14 pm Meet Agrawal,  wrote:

> I have tried and installed the python application a lot of times but after
> the installation get completed and I try to run the application, it say
> that api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer.
>
> Please tell me a way out.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Barry Scott]

> On 26 May 2020, at 18:01, BlindAnagram  wrote:
> 
> On 26/05/2020 17:09, Stefan Ram wrote:
>> Mats Wichmann  writes:
>>> an absolute path is one that starts with the pathname separator.
>> 
>>  The Python Library Reference does not use the term
>>  "pathname separator". It uses "directory separator"
>>  (os.sep) and "filename separator" ('/' on Unix).
>> 
>>  On Windows:
>> 
>> |>>> import pathlib
>> |>>> import os
>> |>>> pathlib.PureWindowsPath('\\').is_absolute()
>> |False
>> |>>> pathlib.PureWindowsPath(os.sep).is_absolute()
>> |False
>> |>>> pathlib.PureWindowsPath('/').is_absolute()
>> |False
> 
> Thanks, that seems to suggest that there is an issue and that I should
> hence submit this as an issue.

Can you post the a link to the issue please?

I note that

>>> pathlib.Path('/').is_absolute()
False
>>> pathlib.Path('/').resolve().is_absolute()
True
>>>

The resolve() is required and I think should not be required.

Barry

> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Chris Angelico]

On Wed, May 27, 2020 at 6:50 PM Barry Scott  wrote:
>
>
>
> > On 26 May 2020, at 18:01, BlindAnagram  wrote:
> >
> > On 26/05/2020 17:09, Stefan Ram wrote:
> >> Mats Wichmann  writes:
> >>> an absolute path is one that starts with the pathname separator.
> >>
> >>  The Python Library Reference does not use the term
> >>  "pathname separator". It uses "directory separator"
> >>  (os.sep) and "filename separator" ('/' on Unix).
> >>
> >>  On Windows:
> >>
> >> |>>> import pathlib
> >> |>>> import os
> >> |>>> pathlib.PureWindowsPath('\\').is_absolute()
> >> |False
> >> |>>> pathlib.PureWindowsPath(os.sep).is_absolute()
> >> |False
> >> |>>> pathlib.PureWindowsPath('/').is_absolute()
> >> |False
> >
> > Thanks, that seems to suggest that there is an issue and that I should
> > hence submit this as an issue.
>
> Can you post the a link to the issue please?
>
> I note that
>
> >>> pathlib.Path('/').is_absolute()
> False
> >>> pathlib.Path('/').resolve().is_absolute()
> True
> >>>
>
> The resolve() is required and I think should not be required.
>

Have a look at the difference between the original Path and the
resolved one, and see if there's a difference there. I suspect that
resolve() is adding the current drive onto that path and thus making
it fully absolute.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[BlindAnagram]

On 27/05/2020 09:13, Barry Scott wrote:
> 
> 
>> On 26 May 2020, at 18:01, BlindAnagram  wrote:
>>
>> On 26/05/2020 17:09, Stefan Ram wrote:
>>> Mats Wichmann  writes:
 an absolute path is one that starts with the pathname separator.
>>>
>>>  The Python Library Reference does not use the term
>>>  "pathname separator". It uses "directory separator"
>>>  (os.sep) and "filename separator" ('/' on Unix).
>>>
>>>  On Windows:
>>>
>>> |>>> import pathlib
>>> |>>> import os
>>> |>>> pathlib.PureWindowsPath('\\').is_absolute()
>>> |False
>>> |>>> pathlib.PureWindowsPath(os.sep).is_absolute()
>>> |False
>>> |>>> pathlib.PureWindowsPath('/').is_absolute()
>>> |False
>>
>> Thanks, that seems to suggest that there is an issue and that I should
>> hence submit this as an issue.
> 
> Can you post the a link to the issue please?

The issue that I raised here was whether the behaviour of os.path.join()
in treating the Windows directory separator '\\' as an absolute path
should be considered a bug.

The behaviour of join came up for me when I tried to use the os.path
functions to create a path that could only ever be used as a directory
and never a file.  The only way that I found to designate a path as a
directory path was to add '\\' at the end.  But this doesn't work in
using os.path becaause the other os.path functions just strip it off and
turn the directories back into files.  I had hoped that join's
documented use of an empty final parameter to add '\\' might behave
differently but it gets stripped off as well :-(

I thought that the description of pathlib behaviour above suported the
view that the os.path.joing behaviour is a bug, and in a sense it does,
but more importantly it an indication that pathib, not os.path, should
be the module of choice for anyone who spends a lot of time manipulating
paths on Windows.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Ben Bacarisse]

BlindAnagram  writes:

> The issue that I raised here was whether the behaviour of os.path.join()
> in treating the Windows directory separator '\\' as an absolute path
> should be considered a bug.

You think it should be considered to be a relative path?  The only
meaning that would give you want you wanted from

  os.path.join(, '\\')

would be to treat it as being relative to the drive and to the
directory.  In other words you want '\\' to be a synonym for '.'  The
usual meaning of '\\' (outside of this specific function) is "root on
the current drive" but that can't sensibly be appended to any path.

> The behaviour of join came up for me when I tried to use the os.path
> functions to create a path that could only ever be used as a directory
> and never a file.  The only way that I found to designate a path as a
> directory path was to add '\\' at the end.  But this doesn't work in
> using os.path becaause the other os.path functions just strip it off and
> turn the directories back into files.

Nothing about the name can turn a directory into a file (or vice versa).
If c:\x\y is a file, calling it c:\x\y\ won't change that, but it might
give you an error when you try to access it.  That may be what you want.
If so, appending '.' is likely to be more portable.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[BlindAnagram]

On 27/05/2020 13:30, Ben Bacarisse wrote:
> BlindAnagram  writes:
> 
>> The issue that I raised here was whether the behaviour of os.path.join()
>> in treating the Windows directory separator '\\' as an absolute path
>> should be considered a bug.
> 
> You think it should be considered to be a relative path?  The only
> meaning that would give you want you wanted from
> 
>   os.path.join(, '\\')
> 
> would be to treat it as being relative to the drive and to the
> directory.  In other words you want '\\' to be a synonym for '.'  The
> usual meaning of '\\' (outside of this specific function) is "root on
> the current drive" but that can't sensibly be appended to any path.
> 
>> The behaviour of join came up for me when I tried to use the os.path
>> functions to create a path that could only ever be used as a directory
>> and never a file.  The only way that I found to designate a path as a
>> directory path was to add '\\' at the end.  But this doesn't work in
>> using os.path becaause the other os.path functions just strip it off and
>> turn the directories back into files.
> 
> Nothing about the name can turn a directory into a file (or vice versa).
> If c:\x\y is a file, calling it c:\x\y\ won't change that, but it might
> give you an error when you try to access it.  That may be what you want.
> If so, appending '.' is likely to be more portable.

That is true if you know for sure how your path will be used.

But if you don't, there is a world of difference between passing the
paths 'name' and 'name\\' on for others to use. And in this situation it
doesn't help when os.path functions strip the directory separator off.

This situation resulted in a bug that was surprisingly hard to track
down because it created hidden files instead of directories as intended.
After finding and correcting the '\\' that had been stripped off, the
desired directories couldn't then be creaated on the target because
hidden files were present with these names.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Rhodri James]

On 27/05/2020 14:41, BlindAnagram wrote:

That is true if you know for sure how your path will be used.

But if you don't, there is a world of difference between passing the
paths 'name' and 'name\\' on for others to use. And in this situation it
doesn't help when os.path functions strip the directory separator off.


Only if you impose meaning externally, which implies you do know how 
your path will be used after all.  If you want to know whether a given 
path corresponds to a file or a directory on a filing system, there's no 
real substitute for looking on the filing system.  Anything else is, as 
you have discovered, error-prone.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Write tables from Word (.docx) to Excel (.xlsx) using xlsxwriter

[BBT]

I am trying to parse a word (.docx) for tables, then copy these tables over to 
excel using xlsxwriter. This is my code:

from docx.api import Document
import xlsxwriter
 
document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1 - for 
merge.docx')
tables = document.tables
 
wb = xlsxwriter.Workbook('C:/Users/xxx/Documents/xxx/test clause 
retrieval.xlsx')
Sheet1 = wb.add_worksheet("Compliance")
index_row = 0
 
print(len(tables))
 
for table in document.tables:
data = []
keys = None
for i, row in enumerate(table.rows):
text = (cell.text for cell in row.cells)
 
if i == 0:
keys = tuple(text)
continue
row_data = dict(zip(keys, text))
data.append(row_data)
#print (data)
#big_data.append(data)
Sheet1.write(index_row,0, str(row_data))  
index_row = index_row + 1
 
print(row_data)
 
wb.close()


This is my desired output: https://i.stack.imgur.com/9qnbw.png

However, here is my actual output: https://i.stack.imgur.com/vpXej.png

I am aware that my current output produces a list of string instead.

Is there anyway that I can get my desired output using xlsxwriter?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[BlindAnagram]

On 27/05/2020 14:53, Rhodri James wrote:
> On 27/05/2020 14:41, BlindAnagram wrote:
>> That is true if you know for sure how your path will be used.
>>
>> But if you don't, there is a world of difference between passing the
>> paths 'name' and 'name\\' on for others to use. And in this situation it
>> doesn't help when os.path functions strip the directory separator off.
> 
> Only if you impose meaning externally, which implies you do know how
> your path will be used after all.  If you want to know whether a given
> path corresponds to a file or a directory on a filing system, there's no
> real substitute for looking on the filing system.  Anything else is, as
> you have discovered, error-prone.

I'm sorry that you don't believe me but all I know is how I intend the
path to be used.  And the os.path functions aren't helpful here when
they actually _change_ the meanings of paths on Windows:

>> fp= "C:\\Documents\finance\\"
>> abspath(fp)
'C:\\Documents\\finance'

If you believe these 'before' and 'after' paths are the same I can only
assume that you don't work on Windows (where one refers to a directory
and the other a file without an extension).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Rhodri James]

On 27/05/2020 16:12, BlindAnagram wrote:

I'm sorry that you don't believe me but all I know is how I intend the
path to be used.  And the os.path functions aren't helpful here when
they actually_change_  the meanings of paths on Windows:


fp= "C:\\Documents\finance\\"
abspath(fp)

'C:\\Documents\\finance'

If you believe these 'before' and 'after' paths are the same I can only
assume that you don't work on Windows (where one refers to a directory
and the other a file without an extension).


More accurately, one is not a legal filename but both are legal 
directory names.


I entirely believe that you have a problem, but I'm inclined to think 
it's of your own making.  You seem to have decided how paths work 
without checking whether the language agrees with you.  It doesn't, and 
hasn't for over a decade without a significant number of complaints (as 
in I can't remember the last one, and I've been around here for a while 
-- it's too hot for me to want to go hunt in the archives :-).


How are these unexpected extensionless files getting created?

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Ben Bacarisse]

BlindAnagram  writes:

> On 27/05/2020 13:30, Ben Bacarisse wrote:
>> BlindAnagram  writes:
>> 
>>> The issue that I raised here was whether the behaviour of os.path.join()
>>> in treating the Windows directory separator '\\' as an absolute path
>>> should be considered a bug.
>> 
>> You think it should be considered to be a relative path?  The only
>> meaning that would give you want you wanted from
>> 
>>   os.path.join(, '\\')
>> 
>> would be to treat it as being relative to the drive and to the
>> directory.  In other words you want '\\' to be a synonym for '.'  The
>> usual meaning of '\\' (outside of this specific function) is "root on
>> the current drive" but that can't sensibly be appended to any path.
>> 
>>> The behaviour of join came up for me when I tried to use the os.path
>>> functions to create a path that could only ever be used as a directory
>>> and never a file.  The only way that I found to designate a path as a
>>> directory path was to add '\\' at the end.  But this doesn't work in
>>> using os.path becaause the other os.path functions just strip it off and
>>> turn the directories back into files.
>> 
>> Nothing about the name can turn a directory into a file (or vice versa).
>> If c:\x\y is a file, calling it c:\x\y\ won't change that, but it might
>> give you an error when you try to access it.  That may be what you want.
>> If so, appending '.' is likely to be more portable.
>
> That is true if you know for sure how your path will be used.
>
> But if you don't, there is a world of difference between passing the
> paths 'name' and 'name\\' on for others to use. And in this situation it
> doesn't help when os.path functions strip the directory separator off.

As it should.  Relying on a trailing \ having the right effect is
brittle to say the least.

> This situation resulted in a bug that was surprisingly hard to track
> down because it created hidden files instead of directories as
> intended.

If so, the bug is not in os.path.join and trying to fix it by insisting
that a path have trailing \ may well just stacking up more problems for
later.

> After finding and correcting the '\\' that had been stripped off, the
> desired directories couldn't then be creaated on the target because
> hidden files were present with these names.

As I said, that's a dodgy thing to rely on.  It may be that you can't
fix the bug any other way (some aspect of the overall design may be
broken), but I would urge you to try.

There is well-known (*nix) software that relies on a/b/c/ meaning
something different to a/b/c but I don't know anyone who thinks this is
a good idea.  It causes no end of confusion.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[BlindAnagram]

On 27/05/2020 16:49, Rhodri James wrote:
> On 27/05/2020 16:12, BlindAnagram wrote:
>> I'm sorry that you don't believe me but all I know is how I intend the
>> path to be used.  And the os.path functions aren't helpful here when
>> they actually_change_  the meanings of paths on Windows:
>>
 fp= "C:\\Documents\finance\\"
 abspath(fp)
>> 'C:\\Documents\\finance'
>>
>> If you believe these 'before' and 'after' paths are the same I can only
>> assume that you don't work on Windows (where one refers to a directory
>> and the other a file without an extension).
> 
> More accurately, one is not a legal filename but both are legal
> directory names.

If they are to be created, which is my situation, the result will be a
diretory and a file.

> I entirely believe that you have a problem, but I'm inclined to think
> it's of your own making.  You seem to have decided how paths work
> without checking whether the language agrees with you.  It doesn't, and
> hasn't for over a decade without a significant number of complaints (as
> in I can't remember the last one, and I've been around here for a while
> -- it's too hot for me to want to go hunt in the archives :-).

Why do you believe my understanding of Python is lacking?  It seems to
me that I have tried to avoid this very issue by explicitly sending a
directory and I have been thwarted by a combination of poor knowledge
elsewhere and a poorly designed function that changes the semantics of
what it is offered.

I would be surprised if issues such as these were not, at least in
significant part, the reason why we now have pathlib.

> How are these unexpected extensionless files getting created?

I believe by attempting to make the directory I send absolute with
abspath() and then copying a file to this path.  They expected this to
copy the file into the directory with its original name but instead it
copies it to the file that abspath 'kindly' converts my directory into.

I did complain about their lack of knowledge but I also have a right to
complain about a function that converts an explicitly specified
directory into a file :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[BlindAnagram]

On 27/05/2020 16:53, Ben Bacarisse wrote:
> BlindAnagram  writes:
> 
>> On 27/05/2020 13:30, Ben Bacarisse wrote:
>>> BlindAnagram  writes:
>>>
 The issue that I raised here was whether the behaviour of os.path.join()
 in treating the Windows directory separator '\\' as an absolute path
 should be considered a bug.
>>>
>>> You think it should be considered to be a relative path?  The only
>>> meaning that would give you want you wanted from
>>>
>>>   os.path.join(, '\\')
>>>
>>> would be to treat it as being relative to the drive and to the
>>> directory.  In other words you want '\\' to be a synonym for '.'  The
>>> usual meaning of '\\' (outside of this specific function) is "root on
>>> the current drive" but that can't sensibly be appended to any path.
>>>
 The behaviour of join came up for me when I tried to use the os.path
 functions to create a path that could only ever be used as a directory
 and never a file.  The only way that I found to designate a path as a
 directory path was to add '\\' at the end.  But this doesn't work in
 using os.path becaause the other os.path functions just strip it off and
 turn the directories back into files.
>>>
>>> Nothing about the name can turn a directory into a file (or vice versa).
>>> If c:\x\y is a file, calling it c:\x\y\ won't change that, but it might
>>> give you an error when you try to access it.  That may be what you want.
>>> If so, appending '.' is likely to be more portable.
>>
>> That is true if you know for sure how your path will be used.
>>
>> But if you don't, there is a world of difference between passing the
>> paths 'name' and 'name\\' on for others to use. And in this situation it
>> doesn't help when os.path functions strip the directory separator off.
> 
> As it should.  Relying on a trailing \ having the right effect is
> brittle to say the least.

In my case less brittle than leaving it out.  I don't want to bore
people with the details but the convention on the target system is that
directory paths must always end with '\\' into order to be interpreted
as directories.  Its not my choice but I see this as a perfectly
reasonable convention. Obviously others may disagree.

>> This situation resulted in a bug that was surprisingly hard to track
>> down because it created hidden files instead of directories as
>> intended.
> 
> If so, the bug is not in os.path.join and trying to fix it by insisting
> that a path have trailing \ may well just stacking up more problems for
> later.
> 
>> After finding and correcting the '\\' that had been stripped off, the
>> desired directories couldn't then be creaated on the target because
>> hidden files were present with these names.
> 
> As I said, that's a dodgy thing to rely on.  It may be that you can't
> fix the bug any other way (some aspect of the overall design may be
> broken), but I would urge you to try.

Its not my bug to fix - the semantics of what I send is very clear on
any Windows system.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Rhodri James]

On 27/05/2020 17:39, BlindAnagram wrote:

I believe by attempting to make the directory I send absolute with
abspath() and then copying a file to this path.  They expected this to
copy the file into the directory with its original name but instead it
copies it to the file that abspath 'kindly' converts my directory into.

I did complain about their lack of knowledge but I also have a right to
complain about a function that converts an explicitly specified
directory into a file:-)


Well, they're getting exactly the behaviour I'd expect them to get (and 
not getting what they expect).  I'm faintly gobsmacked that anyone 
expects something like that to work.  If you want a directory, create 
it.  That's what os.mkdir (and the pathlib equivalent) is for.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Write tables from Word (.docx) to Excel (.xlsx) using xlsxwriter

[Peter Otten]

BBT wrote:

> I am trying to parse a word (.docx) for tables, then copy these tables
> over to excel using xlsxwriter. This is my code:
> 
> from docx.api import Document
> import xlsxwriter
>  
> document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1 -
> for merge.docx') tables = document.tables
>  
> wb = xlsxwriter.Workbook('C:/Users/xxx/Documents/xxx/test clause
> retrieval.xlsx') Sheet1 = wb.add_worksheet("Compliance")
> index_row = 0
>  
> print(len(tables))
>  
> for table in document.tables:
> data = []
> keys = None
> for i, row in enumerate(table.rows):
> text = (cell.text for cell in row.cells)
>  
> if i == 0:
> keys = tuple(text)
> continue
> row_data = dict(zip(keys, text))
> data.append(row_data)
> #print (data)
> #big_data.append(data)
> Sheet1.write(index_row,0, str(row_data))
> index_row = index_row + 1
>  
> print(row_data)
>  
> wb.close()
> 
> 
> This is my desired output: https://i.stack.imgur.com/9qnbw.png
> 
> However, here is my actual output: https://i.stack.imgur.com/vpXej.png
> 
> I am aware that my current output produces a list of string instead.
> 
> Is there anyway that I can get my desired output using xlsxwriter?

I had to simulate docx.api. With that caveat the following seems to work:

import xlsxwriter
 
# begin simulation of
# from docx.api import Document

class Cell:
def __init__(self, text):
self.text = text

class Row:
def __init__(self, cells):
self.cells = [Cell(c) for c in cells]

class Table:
def __init__(self, data):
self.rows = [
Row(row) for row in data
]

class Document:
def __init__(self):
self.tables = [
Table([
["Hello", "Test"],
["est", "ing"],
["gg", "ff"]
]),
Table([
["Foo", "Bar", "Baz"],
["ham", "spam", "jam"]
])
]

document = Document()

# end simulation

wb = xlsxwriter.Workbook("tmp.xlsx")
sheet = wb.add_worksheet("Compliance")
 
offset = 0
for table in document.tables:
for y, row in enumerate(table.rows):
for x, cell in enumerate(row.cells):
sheet.write(y + offset, x, cell.text)
offset +=  len(table.rows) + 1  # one empty row between tables

wb.close()


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Write tables from Word (.docx) to Excel (.xlsx) using xlsxwriter

[BBT]

On Thursday, 28 May 2020 01:36:26 UTC+8, Peter Otten  wrote:
> BBT wrote:
> 
> > I am trying to parse a word (.docx) for tables, then copy these tables
> > over to excel using xlsxwriter. This is my code:
> > 
> > from docx.api import Document
> > import xlsxwriter
> >  
> > document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1 -
> > for merge.docx') tables = document.tables
> >  
> > wb = xlsxwriter.Workbook('C:/Users/xxx/Documents/xxx/test clause
> > retrieval.xlsx') Sheet1 = wb.add_worksheet("Compliance")
> > index_row = 0
> >  
> > print(len(tables))
> >  
> > for table in document.tables:
> > data = []
> > keys = None
> > for i, row in enumerate(table.rows):
> > text = (cell.text for cell in row.cells)
> >  
> > if i == 0:
> > keys = tuple(text)
> > continue
> > row_data = dict(zip(keys, text))
> > data.append(row_data)
> > #print (data)
> > #big_data.append(data)
> > Sheet1.write(index_row,0, str(row_data))
> > index_row = index_row + 1
> >  
> > print(row_data)
> >  
> > wb.close()
> > 
> > 
> > This is my desired output: https://i.stack.imgur.com/9qnbw.png
> > 
> > However, here is my actual output: https://i.stack.imgur.com/vpXej.png
> > 
> > I am aware that my current output produces a list of string instead.
> > 
> > Is there anyway that I can get my desired output using xlsxwriter?
> 
> I had to simulate docx.api. With that caveat the following seems to work:
> 
> import xlsxwriter
>  
> # begin simulation of
> # from docx.api import Document
> 
> class Cell:
> def __init__(self, text):
> self.text = text
> 
> class Row:
> def __init__(self, cells):
> self.cells = [Cell(c) for c in cells]
> 
> class Table:
> def __init__(self, data):
> self.rows = [
> Row(row) for row in data
> ]
> 
> class Document:
> def __init__(self):
> self.tables = [
> Table([
> ["Hello", "Test"],
> ["est", "ing"],
> ["gg", "ff"]
> ]),
> Table([
> ["Foo", "Bar", "Baz"],
> ["ham", "spam", "jam"]
> ])
> ]
> 
> document = Document()
> 
> # end simulation
> 
> wb = xlsxwriter.Workbook("tmp.xlsx")
> sheet = wb.add_worksheet("Compliance")
>  
> offset = 0
> for table in document.tables:
> for y, row in enumerate(table.rows):
> for x, cell in enumerate(row.cells):
> sheet.write(y + offset, x, cell.text)
> offset +=  len(table.rows) + 1  # one empty row between tables
> 
> wb.close()


Hi Peter, thank you for your efforts :) 

However, what if there are many tables in the word document, it would be 
tedious to have to code the texts in the tables one by one. Can I instead, call 
on the word document and let Python do the parsing for tables and its contents? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Write tables from Word (.docx) to Excel (.xlsx) using xlsxwriter

[Peter Otten]

BBT wrote:

> On Thursday, 28 May 2020 01:36:26 UTC+8, Peter Otten  wrote:
>> BBT wrote:
>> 
>> > I am trying to parse a word (.docx) for tables, then copy these tables
>> > over to excel using xlsxwriter. This is my code:
>> > 
>> > from docx.api import Document
>> > import xlsxwriter
>> >  
>> > document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1
>> > - for merge.docx') tables = document.tables
>> >  
>> > wb = xlsxwriter.Workbook('C:/Users/xxx/Documents/xxx/test clause
>> > retrieval.xlsx') Sheet1 = wb.add_worksheet("Compliance")
>> > index_row = 0
>> >  
>> > print(len(tables))
>> >  
>> > for table in document.tables:
>> > data = []
>> > keys = None
>> > for i, row in enumerate(table.rows):
>> > text = (cell.text for cell in row.cells)
>> >  
>> > if i == 0:
>> > keys = tuple(text)
>> > continue
>> > row_data = dict(zip(keys, text))
>> > data.append(row_data)
>> > #print (data)
>> > #big_data.append(data)
>> > Sheet1.write(index_row,0, str(row_data))
>> > index_row = index_row + 1
>> >  
>> > print(row_data)
>> >  
>> > wb.close()
>> > 
>> > 
>> > This is my desired output: https://i.stack.imgur.com/9qnbw.png
>> > 
>> > However, here is my actual output: https://i.stack.imgur.com/vpXej.png
>> > 
>> > I am aware that my current output produces a list of string instead.
>> > 
>> > Is there anyway that I can get my desired output using xlsxwriter?
>> 
>> I had to simulate docx.api. With that caveat the following seems to work:
>> 
>> import xlsxwriter
>>  
>> # begin simulation of
>> # from docx.api import Document
>> 
>> class Cell:
>> def __init__(self, text):
>> self.text = text
>> 
>> class Row:
>> def __init__(self, cells):
>> self.cells = [Cell(c) for c in cells]
>> 
>> class Table:
>> def __init__(self, data):
>> self.rows = [
>> Row(row) for row in data
>> ]
>> 
>> class Document:
>> def __init__(self):
>> self.tables = [
>> Table([
>> ["Hello", "Test"],
>> ["est", "ing"],
>> ["gg", "ff"]
>> ]),
>> Table([
>> ["Foo", "Bar", "Baz"],
>> ["ham", "spam", "jam"]
>> ])
>> ]
>> 
>> document = Document()
>> 
>> # end simulation
>> 
>> wb = xlsxwriter.Workbook("tmp.xlsx")
>> sheet = wb.add_worksheet("Compliance")
>>  
>> offset = 0
>> for table in document.tables:
>> for y, row in enumerate(table.rows):
>> for x, cell in enumerate(row.cells):
>> sheet.write(y + offset, x, cell.text)
>> offset +=  len(table.rows) + 1  # one empty row between tables
>> 
>> wb.close()
> 
> 
> Hi Peter, thank you for your efforts :)
> 
> However, what if there are many tables in the word document, it would be
> tedious to have to code the texts in the tables one by one. Can I instead,
> call on the word document and let Python do the parsing for tables and its
> contents?

I don't understand. You have docx.api available, so you can replace

the "simulation" part of my example with just these two lines: 

from docx.api import Document
document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1 - for 
merge.docx')

I should work -- it's just that I cannot be sure it will work because I could
not test it.



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Write tables from Word (.docx) to Excel (.xlsx) using xlsxwriter

[BBT]

On Thursday, 28 May 2020 02:40:49 UTC+8, Peter Otten  wrote:
> BBT wrote:
> 
> > On Thursday, 28 May 2020 01:36:26 UTC+8, Peter Otten  wrote:
> >> BBT wrote:
> >> 
> >> > I am trying to parse a word (.docx) for tables, then copy these tables
> >> > over to excel using xlsxwriter. This is my code:
> >> > 
> >> > from docx.api import Document
> >> > import xlsxwriter
> >> >  
> >> > document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1
> >> > - for merge.docx') tables = document.tables
> >> >  
> >> > wb = xlsxwriter.Workbook('C:/Users/xxx/Documents/xxx/test clause
> >> > retrieval.xlsx') Sheet1 = wb.add_worksheet("Compliance")
> >> > index_row = 0
> >> >  
> >> > print(len(tables))
> >> >  
> >> > for table in document.tables:
> >> > data = []
> >> > keys = None
> >> > for i, row in enumerate(table.rows):
> >> > text = (cell.text for cell in row.cells)
> >> >  
> >> > if i == 0:
> >> > keys = tuple(text)
> >> > continue
> >> > row_data = dict(zip(keys, text))
> >> > data.append(row_data)
> >> > #print (data)
> >> > #big_data.append(data)
> >> > Sheet1.write(index_row,0, str(row_data))
> >> > index_row = index_row + 1
> >> >  
> >> > print(row_data)
> >> >  
> >> > wb.close()
> >> > 
> >> > 
> >> > This is my desired output: https://i.stack.imgur.com/9qnbw.png
> >> > 
> >> > However, here is my actual output: https://i.stack.imgur.com/vpXej.png
> >> > 
> >> > I am aware that my current output produces a list of string instead.
> >> > 
> >> > Is there anyway that I can get my desired output using xlsxwriter?
> >> 
> >> I had to simulate docx.api. With that caveat the following seems to work:
> >> 
> >> import xlsxwriter
> >>  
> >> # begin simulation of
> >> # from docx.api import Document
> >> 
> >> class Cell:
> >> def __init__(self, text):
> >> self.text = text
> >> 
> >> class Row:
> >> def __init__(self, cells):
> >> self.cells = [Cell(c) for c in cells]
> >> 
> >> class Table:
> >> def __init__(self, data):
> >> self.rows = [
> >> Row(row) for row in data
> >> ]
> >> 
> >> class Document:
> >> def __init__(self):
> >> self.tables = [
> >> Table([
> >> ["Hello", "Test"],
> >> ["est", "ing"],
> >> ["gg", "ff"]
> >> ]),
> >> Table([
> >> ["Foo", "Bar", "Baz"],
> >> ["ham", "spam", "jam"]
> >> ])
> >> ]
> >> 
> >> document = Document()
> >> 
> >> # end simulation
> >> 
> >> wb = xlsxwriter.Workbook("tmp.xlsx")
> >> sheet = wb.add_worksheet("Compliance")
> >>  
> >> offset = 0
> >> for table in document.tables:
> >> for y, row in enumerate(table.rows):
> >> for x, cell in enumerate(row.cells):
> >> sheet.write(y + offset, x, cell.text)
> >> offset +=  len(table.rows) + 1  # one empty row between tables
> >> 
> >> wb.close()
> > 
> > 
> > Hi Peter, thank you for your efforts :)
> > 
> > However, what if there are many tables in the word document, it would be
> > tedious to have to code the texts in the tables one by one. Can I instead,
> > call on the word document and let Python do the parsing for tables and its
> > contents?
> 
> I don't understand. You have docx.api available, so you can replace
> 
> the "simulation" part of my example with just these two lines: 
> 
> from docx.api import Document
> document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1 - for 
> merge.docx')
> 
> I should work -- it's just that I cannot be sure it will work because I could
> not test it.

I tried your code by replacing the Document portion:

import xlsxwriter

# begin simulation of
# from docx.api import Document

class Cell:
def __init__(self, text):
self.text = text

class Row:
def __init__(self, cells):
self.cells = [Cell(c) for c in cells]

class Table:
def __init__(self, data):
self.rows = [
Row(row) for row in data
]

class Document:
def __init__(self):
self.tables = [
Table([
["Hello", "Test"],
["est", "ing"],
["gg", "ff"]
]),
Table([
["Foo", "Bar", "Baz"],
["ham", "spam", "jam"]
])
]

#document = Document()

# end simulation

document = Document('/Users/xxx/Documents/xx/Clauses Sample - Copy v1 - for 
merge.docx')
wb = xlsxwriter.Workbook('C:/Users/xxx/Documents/xx/test clause retrieval.xlsx')
Sheet1 = wb.add_worksheet("Compliance")

offset = 0
for table in document.tables:
for y, row in enumerate(table.rows):
for x, cell in enumerate(row.cells):
sheet.write(y + offset, x, cell.text)
offset +=  len(table.rows) + 1  # one empty row between tables

wb.close()

But I received an error:
TypeError: __init__() takes 1 positional argument but 2 were given
-- 
https://mail.python.org/mail

Re: Behaviour of os.path.join

[Beverly Pope]

I wasn’t going to say anything because I haven’t used MS Windows for years.  
The OP wants to add a path separator at the end of a path.  Why the OP wants to 
do that doesn’t concern me.

OTOH, as others have already mentioned, the documentation explicitly says, "If 
a component is an absolute path, all previous components are thrown away and 
joining continues from the absolute path component.”  While I may not 
understand WHY anyone would want that to occur, this was the way it was 
designed; it is not a bug.

The documentation also says, “The return value is the concatenation of path and 
any members of *paths with exactly one directory separator (os.sep) following 
each non-empty part except the last, meaning that the result will only end in a 
separator if the last part is empty.”  So, the module does allow one to add a 
path separator at the end of the path by simply adding an empty string as the 
last part of the path.  The following is on macOS (I don’t have a MS Windows 
machine):

>>> import os.path
>>> os.path.join('/Users/myID/a', 'b','c')
'/Users/myID/a/b/c'
>>> os.path.join('/Users/myID/a', 'b','c', '')
'/Users/myID/a/b/c/‘

So, it does work as advertised on Python 3.8 and all the OP should need to do 
is add that empty string to get the OP’s desired result.

Bev in TX




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Write tables from Word (.docx) to Excel (.xlsx) using xlsxwriter

[BBT]

On Thursday, 28 May 2020 02:40:49 UTC+8, Peter Otten  wrote:
> BBT wrote:
> 
> > On Thursday, 28 May 2020 01:36:26 UTC+8, Peter Otten  wrote:
> >> BBT wrote:
> >> 
> >> > I am trying to parse a word (.docx) for tables, then copy these tables
> >> > over to excel using xlsxwriter. This is my code:
> >> > 
> >> > from docx.api import Document
> >> > import xlsxwriter
> >> >  
> >> > document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1
> >> > - for merge.docx') tables = document.tables
> >> >  
> >> > wb = xlsxwriter.Workbook('C:/Users/xxx/Documents/xxx/test clause
> >> > retrieval.xlsx') Sheet1 = wb.add_worksheet("Compliance")
> >> > index_row = 0
> >> >  
> >> > print(len(tables))
> >> >  
> >> > for table in document.tables:
> >> > data = []
> >> > keys = None
> >> > for i, row in enumerate(table.rows):
> >> > text = (cell.text for cell in row.cells)
> >> >  
> >> > if i == 0:
> >> > keys = tuple(text)
> >> > continue
> >> > row_data = dict(zip(keys, text))
> >> > data.append(row_data)
> >> > #print (data)
> >> > #big_data.append(data)
> >> > Sheet1.write(index_row,0, str(row_data))
> >> > index_row = index_row + 1
> >> >  
> >> > print(row_data)
> >> >  
> >> > wb.close()
> >> > 
> >> > 
> >> > This is my desired output: https://i.stack.imgur.com/9qnbw.png
> >> > 
> >> > However, here is my actual output: https://i.stack.imgur.com/vpXej.png
> >> > 
> >> > I am aware that my current output produces a list of string instead.
> >> > 
> >> > Is there anyway that I can get my desired output using xlsxwriter?
> >> 
> >> I had to simulate docx.api. With that caveat the following seems to work:
> >> 
> >> import xlsxwriter
> >>  
> >> # begin simulation of
> >> # from docx.api import Document
> >> 
> >> class Cell:
> >> def __init__(self, text):
> >> self.text = text
> >> 
> >> class Row:
> >> def __init__(self, cells):
> >> self.cells = [Cell(c) for c in cells]
> >> 
> >> class Table:
> >> def __init__(self, data):
> >> self.rows = [
> >> Row(row) for row in data
> >> ]
> >> 
> >> class Document:
> >> def __init__(self):
> >> self.tables = [
> >> Table([
> >> ["Hello", "Test"],
> >> ["est", "ing"],
> >> ["gg", "ff"]
> >> ]),
> >> Table([
> >> ["Foo", "Bar", "Baz"],
> >> ["ham", "spam", "jam"]
> >> ])
> >> ]
> >> 
> >> document = Document()
> >> 
> >> # end simulation
> >> 
> >> wb = xlsxwriter.Workbook("tmp.xlsx")
> >> sheet = wb.add_worksheet("Compliance")
> >>  
> >> offset = 0
> >> for table in document.tables:
> >> for y, row in enumerate(table.rows):
> >> for x, cell in enumerate(row.cells):
> >> sheet.write(y + offset, x, cell.text)
> >> offset +=  len(table.rows) + 1  # one empty row between tables
> >> 
> >> wb.close()
> > 
> > 
> > Hi Peter, thank you for your efforts :)
> > 
> > However, what if there are many tables in the word document, it would be
> > tedious to have to code the texts in the tables one by one. Can I instead,
> > call on the word document and let Python do the parsing for tables and its
> > contents?
> 
> I don't understand. You have docx.api available, so you can replace
> 
> the "simulation" part of my example with just these two lines: 
> 
> from docx.api import Document
> document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1 - for 
> merge.docx')
> 
> I should work -- it's just that I cannot be sure it will work because I could
> not test it.

I tried your code by replacing the Document portion:

import xlsxwriter

# begin simulation of
# from docx.api import Document

class Cell:
def __init__(self, text):
self.text = text

class Row:
def __init__(self, cells):
self.cells = [Cell(c) for c in cells]

class Table:
def __init__(self, data):
self.rows = [
Row(row) for row in data
]

class Document:
def __init__(self):
self.tables = [
Table([
["Hello", "Test"],
["est", "ing"],
["gg", "ff"]
]),
Table([
["Foo", "Bar", "Baz"],
["ham", "spam", "jam"]
])
]

#document = Document()

# end simulation

document = Document('/Users/Ai Shan/Documents/CPFB Work/Clauses Sample - Copy 
v1 - for merge.docx')
wb = xlsxwriter.Workbook('C:/Users/Ai Shan/Documents/CPFB Work/test clause 
retrieval.xlsx')
Sheet1 = wb.add_worksheet("Compliance")

offset = 0
for table in document.tables:
for y, row in enumerate(table.rows):
for x, cell in enumerate(row.cells):
sheet.write(y + offset, x, cell.text)
offset +=  len(table.rows) + 1  # one empty row between tables

wb.close()


But I received an error:
TypeError: __init__() takes 1 positional argument but 2 were given
-- 
http

Re: Write tables from Word (.docx) to Excel (.xlsx) using xlsxwriter

[Peter Otten]

BBT wrote:

> I tried your code by replacing the Document portion:

> But I received an error:
> TypeError: __init__() takes 1 positional argument but 2 were given

We seem to have different ideas of what replacing means. 
Here is the suggested script spelt out:

import xlsxwriter
 
from docx.api import Document
document = Document('/Users/xxx/Documents/xxx/Clauses Sample - Copy v1 - for 
merge.docx')

wb = xlsxwriter.Workbook('C:/Users/xxx/Documents/xx/test clause retrieval.xlsx')
sheet = wb.add_worksheet("Compliance")
 
offset = 0
for table in document.tables:
for y, row in enumerate(table.rows):
for x, cell in enumerate(row.cells):
sheet.write(y + offset, x, cell.text)
offset +=  len(table.rows) + 1  # one empty row between tables

wb.close()


-- 
https://mail.python.org/mailman/listinfo/python-list

Access an object to which being bound

[Abdur-Rahmaan Janhangeer]

Greetings,

Lets say i have

class A:
  ...

class B:
   self.x = A

then used

b = B()
z = b.x()

now how in A i get a reference to B when z is assigned to b.x?

Thanks

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Managing plug-ins

[George Fischhof]

DL Neil via Python-list  ezt írta (időpont: 2020.
máj. 26., K, 3:10):

> On 26/05/20 11:35 AM, Benjamin Schollnick wrote:
> > Did you ever find anything that met your requirements?
> >
> > If not, I have a prototype that I need to build out some more…
> >
> > https://github.com/bschollnick/PyPlugInMgr
> >
> > I use it for some home grown utilities, but it needs to be fleshed out
> > some more…
> > If you’re interested feel free to take a look.
>
> Thanks.
> Am on-the-road at present, but will take a look...
> --
> Regards =dn
> --
> https://mail.python.org/mailman/listinfo/python-list


HI,

I do not understand your requirements fully, but two easy come to mind:
registering function as plugin - you can find metaclass or functional
programing examples in google; keywords: register plugin

And the second one, is to put files to a given place and import them in
runtime, I created a pluggable info monitor which does this: in every
cycles imports the given files as plugins.
https://pypi.org/project/pluggable-info-monitor/

BR,
George
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Phyton 32 or 64 bit?

[Bischoop]

On 2020-05-26, Alex Kaye  wrote:
> To all:
>
> The only stupid question is one that wasn't asked !
>
> Alex
>

Well, visit FB and you'll change your mind.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Andrew Jaffe]

Dear all,

\On 26/05/2020 15:56, BlindAnagram wrote:

I came across an issue that I am wondering whether I should report as an
issue.  If I have a directory, say:

   base='C:\\Documents'

and I use os.path.join() as follows:

   join(base, '..\\..\\', 'build', '')

I obtain as expected from the documentation:

'C:\\Documents\\..\\..\\build\\'

But if I try to make the directory myself (as I tried first):

   join(base, '..\\..\\', 'build', '\\')

I obtain:

'C:\\'

The documentation says that an absolute path in the parameter list for
join will discard all previous parameters but '\\' is not an absoute path!

Moreover, if I use

   join(base, '..\\..\\', 'build', os.sep)

I get the same result.

This seems to me to be a bug that I should report but to avoid wasting
developer time I wanted to hear what others feel about this.


Maybe I am being obtuse (and apologies for not quoting any of the 
subsequent voluminous messages in this thread), but I think perhaps 
there is confusion at a somewhat more basic level.


It seems that there is never (rarely?) any reason to explicitly pass a 
string which already contains an explicit separator to `os.path.join` -- 
the whole point of the function is to be os-agnostic.


If you already know what the separator is, and you also don't like the 
behaviour of restarting the path if any of the items are (by the 
function's definition) absolute, then is there any reason to prefer 
`os.path.join` to `string.join`?


A



--
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Roel Schroeven]

BlindAnagram schreef op 27/05/2020 om 18:39:

On 27/05/2020 16:49, Rhodri James wrote:

On 27/05/2020 16:12, BlindAnagram wrote:

I'm sorry that you don't believe me but all I know is how I intend the
path to be used.  And the os.path functions aren't helpful here when
they actually_change_  the meanings of paths on Windows:


fp= "C:\\Documents\finance\\"
abspath(fp)

'C:\\Documents\\finance'

If you believe these 'before' and 'after' paths are the same I can only
assume that you don't work on Windows (where one refers to a directory
and the other a file without an extension).


More accurately, one is not a legal filename but both are legal
directory names.


If they are to be created, which is my situation, the result will be a
diretory and a file.


os.mkdir('C:\\Documents\\finance') creates a directory.
open('C:\\Documents\\finance', 'w') creates a file.

The difference is in the operation, not in the name.

'C:\\Documents\\finance' is a pathname, which can refer to either a 
directory or a file.
'C:\\Documents\\finance\\' could refer to a directory, but to me looks 
more like a partial pathname, not a complete one.


I can't think of any reason for ending pathnames with (back)slashes. 
Just use os.path.join(directory, filename) when you need to refer to a 
file in the directory.



I would be surprised if issues such as these were not, at least in
significant part, the reason why we now have pathlib.


That should be easy to verify: the reasons are listed in the PEP: 
https://www.python.org/dev/peps/pep-0428
I don't see your issue there. I don't think anyone has ever considered 
it an issue at all really.



How are these unexpected extensionless files getting created?


I believe by attempting to make the directory I send absolute with
abspath() and then copying a file to this path.  They expected this to
copy the file into the directory with its original name but instead it
copies it to the file that abspath 'kindly' converts my directory into.


We're getting closer to the real issue here. What functions were used 
copy these files? With which parameters?

Were the destination directories created before copying the files to them?


I did complain about their lack of knowledge but I also have a right to
complain about a function that converts an explicitly specified
directory into a file :-)


Again, a pathname is never inherently a directory or a file.


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Roel Schroeven]

BlindAnagram schreef op 27/05/2020 om 18:53:

Its not my bug to fix - the semantics of what I send is very clear on
any Windows system.


That's the first time I see any mention of those semantics, and I've 
been using Windows since the Windows 3.1 days (and MS-DOS before that, 
since 3.2 IIRC).


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Roel Schroeven]

Ben Bacarisse schreef op 27/05/2020 om 17:53:

There is well-known (*nix) software that relies on a/b/c/ meaning
something different to a/b/c but I don't know anyone who thinks this is
a good idea.  It causes no end of confusion.


rsync? I always have to look up whether or not I need to use a trailing 
/ on the source directory. It's confusing indeed.


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Access an object to which being bound

[Chris Angelico]

On Thu, May 28, 2020 at 5:48 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> Greetings,
>
> Lets say i have
>
> class A:
>   ...
>
> class B:
>self.x = A
>
> then used
>
> b = B()
> z = b.x()
>
> now how in A i get a reference to B when z is assigned to b.x?
>

Things are very tangled here. What exactly are you doing? Your code is
incomplete at the moment, and I'm not sure what you're trying to
achieve. As it currently stands, class A is completely stand-alone and
will not have any way of knowing about B.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Ben Bacarisse]

BlindAnagram  writes:

> On 27/05/2020 16:53, Ben Bacarisse wrote:

>> As it should.  Relying on a trailing \ having the right effect is
>> brittle to say the least.
>
> In my case less brittle than leaving it out.

Brittle does not mean broken.  I know you can fix it by making sure the
trailing \ is there.  It's that solution that is brittle.

> Its not my bug to fix - the semantics of what I send is very clear on
> any Windows system.

Then there is no bug.  You just constructed the path using a method that
did not behave as you expected.  That happens all the time.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Chris Angelico]

On Thu, May 28, 2020 at 6:14 AM Roel Schroeven  wrote:
>
> Ben Bacarisse schreef op 27/05/2020 om 17:53:
> > There is well-known (*nix) software that relies on a/b/c/ meaning
> > something different to a/b/c but I don't know anyone who thinks this is
> > a good idea.  It causes no end of confusion.
>
> rsync? I always have to look up whether or not I need to use a trailing
> / on the source directory. It's confusing indeed.
>

Possibly, but only as a means of forcing the interpretation. Plain
vanilla cp has the same thing with its destination. If you say "cp a b
c d" and d doesn't exist, cp will create it as a single file; but if
you say "cp a b c d/" then cp will error out if d isn't a directory
(including if it doesn't exist). But if d is a directory, then it
makes no difference which way you do it.

Similarly, a .gitignore file can reference a path name and include a
trailing slash; this forces it to be interpreted as a directory, but
otherwise has the same effect.

A path is a path is a path. Whether it refers to a file, a directory,
a symlink, a named pipe, a socket, or whatever, it's still a path.
Windows does some weird things with drive letters, but the rest of it
is still just a path.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Access an object to which being bound

[Abdur-Rahmaan Janhangeer]

Thanks,

Actually i want to keep a reference from B to all A
instantiated like in the case of z

I have class A and i want to call class B via A

You can have

def x(self, *args, **kwargs):
return A(*args, **kwargs)

but was wondering if we could keep track while
doing it via z = ...

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius


On Thu, May 28, 2020 at 12:15 AM Chris Angelico  wrote:

> On Thu, May 28, 2020 at 5:48 AM Abdur-Rahmaan Janhangeer
>  wrote:
> >
> > Greetings,
> >
> > Lets say i have
> >
> > class A:
> >   ...
> >
> > class B:
> >self.x = A
> >
> > then used
> >
> > b = B()
> > z = b.x()
> >
> > now how in A i get a reference to B when z is assigned to b.x?
> >
>
> Things are very tangled here. What exactly are you doing? Your code is
> incomplete at the moment, and I'm not sure what you're trying to
> achieve. As it currently stands, class A is completely stand-alone and
> will not have any way of knowing about B.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Access an object to which being bound

[Abdur-Rahmaan Janhangeer]

i have this:
https://github.com/Abdur-rahmaanJ/hooman/blob/master/hooman/hooman.py

someone PRed a Button class

i want the class button to be available to the class Hooman via
Human.button

self.button = Button

but button has update() which must be called individually

one way to update all buttons is to keep track of buttons instantiated
and calling update on each one. Wrap in a update_all () method

And please close your eyes to the wonderful mess

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius


On Thu, May 28, 2020 at 12:15 AM Chris Angelico  wrote:

> On Thu, May 28, 2020 at 5:48 AM Abdur-Rahmaan Janhangeer
>  wrote:
> >
> > Greetings,
> >
> > Lets say i have
> >
> > class A:
> >   ...
> >
> > class B:
> >self.x = A
> >
> > then used
> >
> > b = B()
> > z = b.x()
> >
> > now how in A i get a reference to B when z is assigned to b.x?
> >
>
> Things are very tangled here. What exactly are you doing? Your code is
> incomplete at the moment, and I'm not sure what you're trying to
> achieve. As it currently stands, class A is completely stand-alone and
> will not have any way of knowing about B.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Access an object to which being bound

[Chris Angelico]

On Thu, May 28, 2020 at 6:27 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> Thanks,
>
> Actually i want to keep a reference from B to all A
> instantiated like in the case of z
>
> I have class A and i want to call class B via A
>
> You can have
>
> def x(self, *args, **kwargs):
> return A(*args, **kwargs)
>
> but was wondering if we could keep track while
> doing it via z = ...
>

Okay, now I think I get what you're after. Let's simplify and clarify
things. Let me know if I'm misinterpreting.

1) You have a container class that can instantiate objects of a thing class
2a) You wish for the container to be aware of all things it has created - OR -
2b) You wish for the Thing to be aware of all containers that have created them
3) You want this to happen automatically.

I'm not sure which way round you're trying to do this, so I'll try to
answer both. Your Container (Hooman) can construct multiple Things
(Button), and other classes could also construct Things. So you need
some way to automatically register the Thing as you create it.

The easiest way to do this would, I think, be to have your Container
subclass a utility class, and then use self.Button() instead of
Button(). That can take care of registering the button in some sort of
list, and then it can still return the button in case you need it for
something else.

Would that work? Or am I completely off on my analysis?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Access an object to which being bound

[Abdur-Rahmaan Janhangeer]

Hum yes a third class is a nice option!

btw managed to do it with those in Hooman

self._all_widgets = []

def button(self, *args, **kwargs):
b = Button(*args, **kwargs)
self._all_widgets.append(b)
return b

def update_all(self):
for widget in self._all_widgets:
widget.update()

Just in the drawing loop i have (hapi is a Hooman object)

for i in range(5):
x = hapi.button(
# params
)
hapi.update_all()

the update all adds a button in the array each frame, that's beyond the
question
but for creating buttons on the fly each frame was never a good option
(better define
before then update x and y in loop)

that's the only caveat to watch out if people create objects on the fly

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius


On Thu, May 28, 2020 at 12:41 AM Chris Angelico  wrote:

> On Thu, May 28, 2020 at 6:27 AM Abdur-Rahmaan Janhangeer
>  wrote:
> >
> > Thanks,
> >
> > Actually i want to keep a reference from B to all A
> > instantiated like in the case of z
> >
> > I have class A and i want to call class B via A
> >
> > You can have
> >
> > def x(self, *args, **kwargs):
> > return A(*args, **kwargs)
> >
> > but was wondering if we could keep track while
> > doing it via z = ...
> >
>
> Okay, now I think I get what you're after. Let's simplify and clarify
> things. Let me know if I'm misinterpreting.
>
> 1) You have a container class that can instantiate objects of a thing class
> 2a) You wish for the container to be aware of all things it has created -
> OR -
> 2b) You wish for the Thing to be aware of all containers that have created
> them
> 3) You want this to happen automatically.
>
> I'm not sure which way round you're trying to do this, so I'll try to
> answer both. Your Container (Hooman) can construct multiple Things
> (Button), and other classes could also construct Things. So you need
> some way to automatically register the Thing as you create it.
>
> The easiest way to do this would, I think, be to have your Container
> subclass a utility class, and then use self.Button() instead of
> Button(). That can take care of registering the button in some sort of
> list, and then it can still return the button in case you need it for
> something else.
>
> Would that work? Or am I completely off on my analysis?
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Ben Bacarisse]

Roel Schroeven  writes:

> Ben Bacarisse schreef op 27/05/2020 om 17:53:
>> There is well-known (*nix) software that relies on a/b/c/ meaning
>> something different to a/b/c but I don't know anyone who thinks this is
>> a good idea.  It causes no end of confusion.
>
> rsync? I always have to look up whether or not I need to use a
> trailing / on the source directory. It's confusing indeed.

That was the one I was thinking of.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[BlindAnagram]

On 27/05/2020 18:37, Roel Schroeven wrote:

> BlindAnagram schreef op 27/05/2020 om 18:39:
>> On 27/05/2020 16:49, Rhodri James wrote:
>>> On 27/05/2020 16:12, BlindAnagram wrote:
 I'm sorry that you don't believe me but all I know is how I intend the
 path to be used.  And the os.path functions aren't helpful here when
 they actually_change_  the meanings of paths on Windows:

>> fp= "C:\\Documents\finance\\"
>> abspath(fp)
 'C:\\Documents\\finance'

 If you believe these 'before' and 'after' paths are the same I can only
 assume that you don't work on Windows (where one refers to a directory
 and the other a file without an extension).
>>>
>>> More accurately, one is not a legal filename but both are legal
>>> directory names.
>>
>> If they are to be created, which is my situation, the result will be a
>> diretory and a file.
> 
> os.mkdir('C:\\Documents\\finance') creates a directory.
> open('C:\\Documents\\finance', 'w') creates a file.
> 
> The difference is in the operation, not in the name.
> 
> 'C:\\Documents\\finance' is a pathname, which can refer to either a
> directory or a file.
> 'C:\\Documents\\finance\\' could refer to a directory, but to me looks
> more like a partial pathname, not a complete one.
> 
> I can't think of any reason for ending pathnames with (back)slashes.
> Just use os.path.join(directory, filename) when you need to refer to a
> file in the directory.
> 
>> I would be surprised if issues such as these were not, at least in
>> significant part, the reason why we now have pathlib.
> 
> That should be easy to verify: the reasons are listed in the PEP:
> https://www.python.org/dev/peps/pep-0428
> I don't see your issue there. I don't think anyone has ever considered
> it an issue at all really.
> 
>>> How are these unexpected extensionless files getting created?
>>
>> I believe by attempting to make the directory I send absolute with
>> abspath() and then copying a file to this path.  They expected this to
>> copy the file into the directory with its original name but instead it
>> copies it to the file that abspath 'kindly' converts my directory into.
> 
> We're getting closer to the real issue here. What functions were used
> copy these files? With which parameters?
> Were the destination directories created before copying the files to them?
> 
>> I did complain about their lack of knowledge but I also have a right to
>> complain about a function that converts an explicitly specified
>> directory into a file :-)
> 
> Again, a pathname is never inherently a directory or a file.

You can define a path however you want but it won't change the fact that
on Windows a path that ends in '\\' is inherently a path to a directory.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[BlindAnagram]

On 27/05/2020 18:42, Roel Schroeven wrote:
> BlindAnagram schreef op 27/05/2020 om 18:53:
>> Its not my bug to fix - the semantics of what I send is very clear on
>> any Windows system.
> 
> That's the first time I see any mention of those semantics, and I've
> been using Windows since the Windows 3.1 days (and MS-DOS before that,
> since 3.2 IIRC).

Well I can only say that I am surpised that anyone working on Windows
code development for as long as you have doesn't know that a path that
ends in '\\' is a path to a directory.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[DL Neil via Python-list]

...


Again, a pathname is never inherently a directory or a file.


See previous contribution: until YOU define YOUR arena of operations, it 
will be difficult to select the correct tool or library - or for others 
to assist you.


If dealing with strings (which happen to look as if they are 
file/directory names) then use str.join() plus build custom functions to 
suit yourself/your specification.


If dealing with strings which represent files/directories, use pathlib's 
abstraction.


If the above applies, but eventually are applied to a file-system, use 
pathlib's "concrete" classes, at that point.


If you are prepared to accept the os/os.path library's abstraction(s), 
then please go-ahead with that alternative.


If any of the provided libraries are insufficient, please search Pypi 
(etc) for a suitable alternative, or develop your own routines.




You can define a path however you want but it won't change the fact that
on Windows a path that ends in '\\' is inherently a path to a directory.


Referring to the first clause:
again, see previous contribution, and link to descriptions of paths 
(etc) and comparisons across OpSys. We can't define/re-define such terms 
to suit ourselves - nor does Python.


If your specification embraces only MS-Windows, then please ignore the 
Python facilities which attempt a more universal solution. If, however, 
you choose a more universal abstraction, then please accept that it will 
not (necessarily) offer solutions which are Windows-specific - by 
definition.



Referring to the final conclusion:
a solution already exists (again, please refer to docs/link in previous 
contribution, and repeated 'here' by @Beverley). She provides evidence 
for macOS, here is same from Linux:


>>> os.path.join( '/dir', 'dir', '' )
'/dir/dir/'

Personally, I find the final path (as empty string) to be both ugly and 
a little confusing, but by ignoring the inherent 'intelligence' we can 
direct:


>>> os.path.join( '/dir', 'dir/' )
'/dir/dir/'

What happens on MS-Windows?


Of course, given that this -join() doesn't care about content, but 
requires only "path(s)" as parameter(s), we can 'do our own thing':


>>> os.path.join( '/dir', 'file' )
'/dir/file'
>>> os.path.join( '/dir', 'file/' )
'/dir/file/'

???
With great power, comes great...
- and from this conversation it would appear many (like me) wouldn't 
want to contemplate such a thing. However, it *is* possible, and given 
that it satisfies your stated spec, you could "define...however you 
want" and make the decision without reference to 'the rest of us'.



Once you have coded your solution, which you could then use as 'sample 
code', please feel free to suggest a bug-fix which describes:-

- the problem-set,
- the scenario(s) in which it is a problem,
- the problems of your solution (as coded), and
- your idea for a more elegant, Pythonic, solution.
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Issues regarding running of application.

[Barry]

> On 27 May 2020, at 09:44, Souvik Dutta  wrote:
> 
> Do have the latest version of DirectX installed? If not then do that or you
> can google out the dll file you need (or is missing) and download it and
> cut - paste it wherever needed. Missing dll files is a very common issue in
> windows and thus Microsoft made DirectX.

Maybe the c runtime but not direct x that’s typically for games.

Barry

> 
>> On Tue, 26 May, 2020, 11:14 pm Meet Agrawal,  wrote:
>> 
>> I have tried and installed the python application a lot of times but after
>> the installation get completed and I try to run the application, it say
>> that api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer.
>> 
>> Please tell me a way out.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Access an object to which being bound

[DL Neil via Python-list]

@AR,


On 28/05/20 8:41 AM, Chris Angelico wrote:

On Thu, May 28, 2020 at 6:27 AM Abdur-Rahmaan Janhangeer
 wrote:


Thanks,

Actually i want to keep a reference from B to all A
instantiated like in the case of z

I have class A and i want to call class B via A

You can have

def x(self, *args, **kwargs):
 return A(*args, **kwargs)

but was wondering if we could keep track while
doing it via z = ...



Okay, now I think I get what you're after. Let's simplify and clarify
things. Let me know if I'm misinterpreting.

1) You have a container class that can instantiate objects of a thing class
2a) You wish for the container to be aware of all things it has created - OR -
2b) You wish for the Thing to be aware of all containers that have created them
3) You want this to happen automatically.

I'm not sure which way round you're trying to do this, so I'll try to
answer both. Your Container (Hooman) can construct multiple Things
(Button), and other classes could also construct Things. So you need
some way to automatically register the Thing as you create it.

The easiest way to do this would, I think, be to have your Container
subclass a utility class, and then use self.Button() instead of
Button(). That can take care of registering the button in some sort of
list, and then it can still return the button in case you need it for
something else.

Would that work? Or am I completely off on my analysis?


Here's some sample code, which may give you some ideas (intriguingly it 
comes from my playing-about with a project @Chris described (some time 
back), which includes the need to 'register' sub-components and to keep 
a count of them):



# PSL
import collections
from itertools import count


class Link():
'''Contain original link, manipulate for presentation,
and retain for later action.
'''

ID = count( 0 )
instances = []


def __init__( self, token:Token, )->None:
'''Instantiate.'''
self.token = token

self.linkNR:int = next( self.ID )   #linkNR
Link.instances.append( self )   #form a register of 
instances/links

self.URL:str = ""

...more methods here - likely irrelevant to your needs...


class LinksRegister( collections.UserList ):
'''Links available for use within application.'''

def __iter__( self ):
'''Generator.'''
for link in self.data:
yield link

def register_links( self, cls ):
'''Register all links.'''
self.data = cls.instances


Once all of the Link() objects have been ascertained, we can make use of 
the class-attributes:


links_register.register_links( Link )

NB in this scenario it is only necessary to register once - all of the 
links at-once, cf registering each link as it is itself instantiated. 
Also, that each Link() object is not aware that it is/will be 'registered'!



Later, when it is necessary to carry-out the same action on each of the 
objects, we can use the register's iterator/generator (as above).



Critique/other ideas welcome...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Roel Schroeven]

BlindAnagram schreef op 27/05/2020 om 22:55:

On 27/05/2020 18:42, Roel Schroeven wrote:

BlindAnagram schreef op 27/05/2020 om 18:53:

Its not my bug to fix - the semantics of what I send is very clear on
any Windows system.


That's the first time I see any mention of those semantics, and I've
been using Windows since the Windows 3.1 days (and MS-DOS before that,
since 3.2 IIRC).


Well I can only say that I am surpised that anyone working on Windows
code development for as long as you have doesn't know that a path that
ends in '\\' is a path to a directory.


A path ending in a backslash cannot refer to a file, that much is true. 
So if you have such a path and you insist that path is not an incomplete 
path, than it must out of necessity be a directory. But a path not 
ending in a backslash can refer to a directory just as well.


If those semantics are as clear as you say, it shouldn't be too 
difficult to point us to a section in the Windows documentation that 
confirms that.


A quick search turns up "Naming Files, Paths, and Namespaces" 
(https://docs.microsoft.com/nl-be/windows/win32/fileio/naming-a-file) 
which seems to be relevant. I see some example directory names without 
backslashes at the end, and I see text like


"Note that a directory is simply a file with a special attribute 
designating it as a directory, but otherwise must follow all the same 
naming rules as a regular file. Because the term directory simply refers 
to a special type of file as far as the file system is concerned, some 
reference material will use the general term file to encompass both 
concepts of directories and data files as such. Because of this, unless 
otherwise specified, any naming or usage rules or examples for a file 
should also apply to a directory."


and

"Note that directory names are stored by the file system as a special 
type of file, but naming rules for files also apply to directory names. 
To summarize, a path is simply the string representation of the 
hierarchy between all of the directories that exist for a particular 
file or directory name."


I find no hints of adding a backslash at the end to indicate directories.

If you can point me to convincing evidence in the documentation I'll 
change my mind.


I'm sorry if my language seems abrasive; that is not my intention. I'm 
only trying to help you and clear up a misunderstanding (which could be 
mine, if it turns out you're right after all).


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Behaviour of os.path.join

[Chris Angelico]

On Thu, May 28, 2020 at 7:07 AM BlindAnagram  wrote:
> You can define a path however you want but it won't change the fact that
> on Windows a path that ends in '\\' is inherently a path to a directory.

Citation needed.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Elegant hack or gross hack? TextWrapper and escape codes

[Chris Angelico]

Situation: A terminal application. Requirement: Display nicely-wrapped
text. With colour codes in it. And that text might be indented to any
depth.

label = f"{indent}\U0010cc32{code}\U0010cc00 @{tweet['user']['screen_name']}: "
wrapper = textwrap.TextWrapper(
initial_indent=label,
subsequent_indent=indent + " " * 12,
width=shutil.get_terminal_size().columns,
break_long_words=False, break_on_hyphens=False, # Stop URLs from breaking
)
for line in tweet["full_text"].splitlines():
print(wrapper.fill(line)
.replace("\U0010cc32", "\x1b[32m\u2026")
.replace("\U0010cc00", "\u2026\x1b[0m")
)
wrapper.initial_indent = wrapper.subsequent_indent # For
subsequent lines, just indent them


The parameter "indent" is always some number of spaces (possibly
zero). If I simply include the escape codes in the label, their
characters will be counted, and the first line will be shorter. Rather
than mess with how textwrap defines text, I just replace the escape
codes *and one other character* with a placeholder. In the final
display, \U0010cc32 means "colour code 32 and an ellipsis", and
\U0010cc00 means "colour code 0 and an ellipsis", so textwrap
correctly counts them as one character each.

So what do you folks think? Is this a gloriously elegant way to
collapse nonprinting text, or is it a gross hacky mess that's going to
cause problems?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Access an object to which being bound

[Abdur-Rahmaan Janhangeer]

Greetings,

.append(self) is a hit idea

Updated the project with the button demo
https://github.com/Abdur-rahmaanJ/hooman/

Next i will be attempting to add a grid system.
I feel myself developing tkinter from scratch

Thanks for the help everybody ^^_

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius


On Thu, May 28, 2020 at 2:45 AM DL Neil via Python-list <
python-list@python.org> wrote:

> @AR,
>
>
> On 28/05/20 8:41 AM, Chris Angelico wrote:
> > On Thu, May 28, 2020 at 6:27 AM Abdur-Rahmaan Janhangeer
> >  wrote:
> >>
> >> Thanks,
> >>
> >> Actually i want to keep a reference from B to all A
> >> instantiated like in the case of z
> >>
> >> I have class A and i want to call class B via A
> >>
> >> You can have
> >>
> >> def x(self, *args, **kwargs):
> >>  return A(*args, **kwargs)
> >>
> >> but was wondering if we could keep track while
> >> doing it via z = ...
> >>
> >
> > Okay, now I think I get what you're after. Let's simplify and clarify
> > things. Let me know if I'm misinterpreting.
> >
> > 1) You have a container class that can instantiate objects of a thing
> class
> > 2a) You wish for the container to be aware of all things it has created
> - OR -
> > 2b) You wish for the Thing to be aware of all containers that have
> created them
> > 3) You want this to happen automatically.
> >
> > I'm not sure which way round you're trying to do this, so I'll try to
> > answer both. Your Container (Hooman) can construct multiple Things
> > (Button), and other classes could also construct Things. So you need
> > some way to automatically register the Thing as you create it.
> >
> > The easiest way to do this would, I think, be to have your Container
> > subclass a utility class, and then use self.Button() instead of
> > Button(). That can take care of registering the button in some sort of
> > list, and then it can still return the button in case you need it for
> > something else.
> >
> > Would that work? Or am I completely off on my analysis?
>
> Here's some sample code, which may give you some ideas (intriguingly it
> comes from my playing-about with a project @Chris described (some time
> back), which includes the need to 'register' sub-components and to keep
> a count of them):
>
>
> # PSL
> import collections
> from itertools import count
>
>
> class Link():
> '''Contain original link, manipulate for presentation,
> and retain for later action.
> '''
>
> ID = count( 0 )
> instances = []
>
>
> def __init__( self, token:Token, )->None:
> '''Instantiate.'''
> self.token = token
>
> self.linkNR:int = next( self.ID )   #linkNR
> Link.instances.append( self )   #form a register
> of instances/links
>
> self.URL:str = ""
>
> ...more methods here - likely irrelevant to your needs...
>
>
> class LinksRegister( collections.UserList ):
> '''Links available for use within application.'''
>
> def __iter__( self ):
> '''Generator.'''
> for link in self.data:
> yield link
>
> def register_links( self, cls ):
> '''Register all links.'''
> self.data = cls.instances
>
>
> Once all of the Link() objects have been ascertained, we can make use of
> the class-attributes:
>
> links_register.register_links( Link )
>
> NB in this scenario it is only necessary to register once - all of the
> links at-once, cf registering each link as it is itself instantiated.
> Also, that each Link() object is not aware that it is/will be 'registered'!
>
>
> Later, when it is necessary to carry-out the same action on each of the
> objects, we can use the register's iterator/generator (as above).
>
>
> Critique/other ideas welcome...
> --
> Regards =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Custom logging function

[zljubisic]

> You create two stream handlers that both log to stderr -- one with 
> basicConfig() and one explicitly in your code. That's probably not what you 
> want.

How can I just add terminator = '\r\n' to the code bellow?
Where should I put it?

import logging

LOG_LEVEL = logging.getLevelName('DEBUG')

logging.basicConfig(level=LOG_LEVEL,
format='%(asctime)s %(levelname)s %(name)s %(funcName)-20s 
%(message)s',
datefmt='%d.%m.%Y %H:%M:%S')

logging.info('Main script started')
-- 
https://mail.python.org/mailman/listinfo/python-list

Ram memory not freed after executing python script on ubuntu system

[Rahul Gupta]

I am having a Ubuntu system which has 125 Gb of RAM. I executed few python 
scripts on that system. Those scripts uses numpy arrays and pandas. Now 
execution was over but still 50 gb of RAM and 2 Gb cache and 8.4 Gb of swap is 
occupied. At this moment nothing is running on the system. I have googled it. 
Most of th result shows that python garbage collector is poor in performance. I 
want this memory to be cleaned and re claim. One of the easiest way is to 
restart the system but i dont want to restart i want a way to do this when the 
system is up and running. Kindly tell me how to do this. Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ram memory not freed after executing python script on ubuntu system

[Chris Angelico]

On Thu, May 28, 2020 at 3:51 PM Rahul Gupta  wrote:
>
>
> I am having a Ubuntu system which has 125 Gb of RAM. I executed few python 
> scripts on that system. Those scripts uses numpy arrays and pandas. Now 
> execution was over but still 50 gb of RAM and 2 Gb cache and 8.4 Gb of swap 
> is occupied. At this moment nothing is running on the system. I have googled 
> it. Most of th result shows that python garbage collector is poor in 
> performance. I want this memory to be cleaned and re claim. One of the 
> easiest way is to restart the system but i dont want to restart i want a way 
> to do this when the system is up and running. Kindly tell me how to do this. 
> Thanks
>

The Python garbage collector is irrelevant once you have terminated
Python. I suggest you look elsewhere in your system - if 50GB of RAM
is still in use after the Python process has ended, it's not being
used by Python.

Also, that's an awful lot of RAM, but a surprising amount. Are you
sure it's not 128GB?

I don't know where you got your information from regarding the "poor
performance" of the Python GC, but without citations, it's nothing but
FUD.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list