Re: Python27.dll module error from Python 2.7.15/PCbuild/get_externals.bat

[Amit Kumar Singh]

Yes pylauncher was installed when I installed 3.6.4.
Moreover, the python in externals\pythonx86 is supposed to be able to parse 
it's own code but it errors out in my case.

Can you provide me the list of all the external modules with it's dependencies 
if possible ?
I will pull those separately and avoid executing get_externals.bat.

I pulled out a few external packages individually using git command and that 
was just fine.
I believe if I have the full externals downloaded on my machine then the build 
should g just fine.

Earlier with 2.7.14 the "svn co" command used to get all the external modules 
at once and that way the build was good but here in 2.7.15 the mechanism is 
changed a bit and now get_externals.py is used which errors out in my case.


On Friday, June 29, 2018 at 10:11:16 PM UTC+5:30, Terry Reedy wrote:
> On 6/29/2018 3:42 AM, amit.singh2...@gmail.com wrote:
> > I am trying to compile the freshly downloaded Python 2.7.15.
> > When the PCBuild/build.bat goes to pull-in the external modules along with 
> > their dependencies it encounters this error for each of the external 
> > modules.
> > 
> > F:\Dev\depot\tools\source\python\Python-2.7.15>.\PCbuild\get_externals.bat
> > Using 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\PCbuild\\..\externals\pyth
> > onx86\tools\python.exe" (found in externals directory)
> > Fetching external libraries...
> > e is e
> > Fetching bzip2-1.0.6...
> > Traceback (most recent call last):
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\PCbuild\\get_external.py"
> > , line 7, in 
> >  from urllib.request import urlretrieve
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\externals\pythonx86\tools
> > \lib\urllib\request.py", line 88, in 
> >  import http.client
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\externals\pythonx86\tools
> > \lib\http\client.py", line 71, in 
> >  import email.parser
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\externals\pythonx86\tools
> > \lib\email\parser.py", line 12, in 
> >  from email.feedparser import FeedParser, BytesFeedParser
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\externals\pythonx86\tools
> > \lib\email\feedparser.py", line 27, in 
> >  from email._policybase import compat32
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\externals\pythonx86\tools
> > \lib\email\_policybase.py", line 9, in 
> >  from email.utils import _has_surrogates
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\externals\pythonx86\tools
> > \lib\email\utils.py", line 29, in 
> >  import socket
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\externals\pythonx86\tools
> > \lib\socket.py", line 49, in 
> >  import _socket
> > ImportError: Module use of python27.dll conflicts with this version of 
> > Python.
> > Fetching bsddb-4.7.25.0...
> > Traceback (most recent call last):
> >File 
> > "F:\Dev\depot\tools\source\python\Python-2.7.15\PCbuild\\get_external.py"
> > 
> > I tried installing python versions 3.6.4 and 2.7.15 to see if it works 
> > because I read in the build script that if python is already installed then 
> > it will use that else it will install it's own python in externals and use 
> > it.
> > But no luck! It keeps giving me the same error again and again. Even if I 
> > execute "builds.bat -e" it gets into the same trap though it goes ahead and 
> > compiles but then compiler throws error due to half-baked external modules.
> > 
> > Any help will be highly appreciated !
> 
> I updated my repository, including the 2.7 branch and ran
> PCbuild\build.bat -e -d
> Everything built fine, but no external fetches were done.
> I renamed the bz dir and built again.
> 
> Using py -3.6 (found with py.exe)
> Fetching external libraries...
> Fetching bzip2-1.0.6...
> ...
> blocksort.c
>bzlib.c
>compress.c
>crctable.c
>decompress.c
>huffman.c
>randtable.c
>Generating Code...
>bz2.vcxproj -> f:\dev\27\PCBuild\bz2_d.pyd
> as expected.  So the .bat files are ok.
> 
> You had
>  > Using 
> "F:\Dev\depot\tools\source\python\Python-2.7.15\PCbuild\\..\externals\pyth
>  > onx86\tools\python.exe" (found in externals directory)
> and got
>  > ImportError: Module use of python27.dll conflicts with this version 
> of Python.
> 
> I don't understand that at all, but I would remove the python.exe within 
> external, as it did not work, so it cannot be used.  Did you install the 
> py launcher when you installed 3.6 (3.6.6 was just released).
> 
> Here is the list of what you need.
> Fetching bzip2-1.0.6...
> bsddb-4.7.25.0 already exists, skipping.
> openssl-1.0.2o already exists, skipping.
> sqlite-3.14.2.0 already exists, skipping.
> tcl-8.5.19.0 already exists, skipping.
> tk-8.5.19.0 already exists, skipping.
> tix-8.4.3.5 already exists, skipping.
> Fetching external binaries...
> nasm-2.11.06 already exists, skipping.
> 
> I would dele

Re: Python 3.7 Windows Help Behaviour

[BlindAnagram]

On 29/06/2018 17:53, Terry Reedy wrote:
> On 6/29/2018 6:14 AM, BlindAnagram wrote:
>> In Python 3.7.0 on Windows the help file (python370.chm) displays with a
>> fixed line length and does not adjust its line length when the user
>> expands the help window horizontally.  This behaviour is different to
>> that of the Python 3.6 help file (python360.chm) which adjusts its text
>> to fit the horizontal width of the help window.
>>
>> Is this a deliberate change or one that can be turned on or off in some
>> way (I prefer the Python 3.6 behaviour)?
> 
> I believe that this is a deliberate regression imposed by 'experts' who
> believe in form over function and 'controlling the user experience'.
> 3.6.6 has been 'fixated' also.

Thank you for your response.  If you are right it is a pity that the
user choice of width has been removed since it now looks stupidly narrow
on my high resolution display.  It looks like I will have to use the
Python 3.6 file even in Python 3.7 :-(
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.7 Windows Help Behaviour

[Steven D'Aprano]

On Fri, 29 Jun 2018 12:53:15 -0400, Terry Reedy wrote:

> On 6/29/2018 6:14 AM, BlindAnagram wrote:
>> In Python 3.7.0 on Windows the help file (python370.chm) displays with
>> a fixed line length and does not adjust its line length when the user
>> expands the help window horizontally.  This behaviour is different to
>> that of the Python 3.6 help file (python360.chm) which adjusts its text
>> to fit the horizontal width of the help window.
>> 
>> Is this a deliberate change or one that can be turned on or off in some
>> way (I prefer the Python 3.6 behaviour)?
> 
> I believe that this is a deliberate regression imposed by 'experts' who
> believe in form over function and 'controlling the user experience'.
> 3.6.6 has been 'fixated' also.

Sounds like somebody should raise a bug report.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

error in os.chdir

[Sharan Basappa]

0
down vote
favorite

I need to change directory to my local working directory in windows and then 
open a file for processing.
Its just a 3 lines code, as below:
import csv
import os
os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
The error is as follows:
WindowsError: [Error 123] The filename, directory name, or volume label syntax 
is incorrect: 'D:\Projects\Initiatives\machine learning\programs\x07ssertion'
Notice x07 character that has replaced character x07.
I have a similar code but that goes through fine:
import csv
import os
os.chdir('D:\Projects\Initiatives\machine learning\programs')

with open('example.csv') as csvfile:
readCSV = csv.reader(csvfile, delimiter=',')
The only difference is directory assertion in the problematic code.
I have tried single quoting, double quoting etc. for the chdir directive but 
nothing helps. I have also tried escaping as \assertion but that is not the 
issue
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: error in os.chdir

[Karsten Hilbert]

On Sat, Jun 30, 2018 at 04:05:22AM -0700, Sharan Basappa wrote:

> I need to change directory to my local working directory in windows and then 
> open a file for processing.
> Its just a 3 lines code, as below:
> import csv
> import os
> os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
> The error is as follows:
> WindowsError: [Error 123] The filename, directory name, or volume label 
> syntax is incorrect: 'D:\Projects\Initiatives\machine 
> learning\programs\x07ssertion'
> Notice x07 character that has replaced character x07.
> I have a similar code but that goes through fine:
> import csv
> import os
> os.chdir('D:\Projects\Initiatives\machine learning\programs')
> 
> with open('example.csv') as csvfile:
> readCSV = csv.reader(csvfile, delimiter=',')
> The only difference is directory assertion in the problematic code.
> I have tried single quoting, double quoting etc. for the chdir directive but 
> nothing helps. I have also tried escaping as \assertion but that is not the 
> issue

The quick fix:

put an r in front of the directory string: r'...'

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

naming methods in python (std lib)

[Abdur-Rahmaan Janhangeer]

normally, naming methods in python is given by

method_name

but i see some cases where this is not followed in the std lib

ex :  dict.fromkeys

should it not have been

from_keys?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: error in os.chdir

[Chris Angelico]

On Sat, Jun 30, 2018 at 9:05 PM, Sharan Basappa
 wrote:
>
> 0
> down vote
> favorite
>
> I need to change directory to my local working directory in windows and then 
> open a file for processing.
> Its just a 3 lines code, as below:
> import csv
> import os
> os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
> The error is as follows:
> WindowsError: [Error 123] The filename, directory name, or volume label 
> syntax is incorrect: 'D:\Projects\Initiatives\machine 
> learning\programs\x07ssertion'
> Notice x07 character that has replaced character x07.
> I have a similar code but that goes through fine:
> import csv
> import os
> os.chdir('D:\Projects\Initiatives\machine learning\programs')

Use forward slashes instead of backslashes for all paths.

os.chdir('D:/Projects/Initiatives/machine learning/programs')

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

Re: error in os.chdir

[Sharan Basappa]

On Saturday, 30 June 2018 16:51:53 UTC+5:30, Karsten Hilbert  wrote:
> On Sat, Jun 30, 2018 at 04:05:22AM -0700, Sharan Basappa wrote:
> 
> > I need to change directory to my local working directory in windows and 
> > then open a file for processing.
> > Its just a 3 lines code, as below:
> > import csv
> > import os
> > os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
> > The error is as follows:
> > WindowsError: [Error 123] The filename, directory name, or volume label 
> > syntax is incorrect: 'D:\Projects\Initiatives\machine 
> > learning\programs\x07ssertion'
> > Notice x07 character that has replaced character x07.
> > I have a similar code but that goes through fine:
> > import csv
> > import os
> > os.chdir('D:\Projects\Initiatives\machine learning\programs')
> > 
> > with open('example.csv') as csvfile:
> > readCSV = csv.reader(csvfile, delimiter=',')
> > The only difference is directory assertion in the problematic code.
> > I have tried single quoting, double quoting etc. for the chdir directive 
> > but nothing helps. I have also tried escaping as \assertion but that is not 
> > the issue
> 
> The quick fix:
> 
> put an r in front of the directory string: r'...'
> 
> Karsten
> -- 
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

thanks. That works
-- 
https://mail.python.org/mailman/listinfo/python-list

list initialize with ?

[Sharan Basappa]

Can anyone explain to me what the ? does here:

ignore_words = ['?']
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: error in os.chdir

[Abdur-Rahmaan Janhangeer]

for user input, a replace might be the solution, using / in internal code

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

Use forward slashes instead of backslashes for all paths.
>
> os.chdir('D:/Projects/Initiatives/machine learning/programs')
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: list initialize with ?

[Steven D'Aprano]

On Sat, 30 Jun 2018 04:50:10 -0700, Sharan Basappa wrote:

> Can anyone explain to me what the ? does here:
> 
> ignore_words = ['?']

Its a question mark inside a string, which is inside a list. You can put 
anything you like in strings:

'a'

'abcde'

even punctuation like '?'. Then you can put the string inside a list.

What you do with it, I have no idea -- presumably its your code.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: naming methods in python (std lib)

[Steven D'Aprano]

On Sat, 30 Jun 2018 15:27:35 +0400, Abdur-Rahmaan Janhangeer wrote:

> normally, naming methods in python is given by
> 
> method_name
> 
> but i see some cases where this is not followed in the std lib
> 
> ex :  dict.fromkeys
> 
> should it not have been
> 
> from_keys?

Python is about 25 years old (1993 I think it was first released) and not 
all the names follow the same convention.

Sometimes that's because the names pre-date the convention. Sometimes its 
because the name follows some other convention, e.g. most of the "is" 
names look like isinstance, issubclass, string.islower etc rather than 
is_instance, is_subclass, is_lower.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: error in os.chdir

[Steven D'Aprano]

On Sat, 30 Jun 2018 04:47:44 -0700, Sharan Basappa wrote:

>> The quick fix:
>> 
>> put an r in front of the directory string: r'...'
>
> thanks. That works

Please don't do that. It's the wrong solution -- all you are doing is 
postponing failure. It will *seem* to work, until one day you will write 
something like this:

directory = r'D:\directory\'

and you will get a mysterious failure. Chris gave you the right solution: 
use forward slashes instead of backslashes for all paths.

os.chdir('D:/Projects/Initiatives/machine learning/programs')




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: error in os.chdir

[Sharan Basappa]

On Saturday, 30 June 2018 18:05:02 UTC+5:30, Steven D'Aprano  wrote:
> On Sat, 30 Jun 2018 04:47:44 -0700, Sharan Basappa wrote:
> 
> >> The quick fix:
> >> 
> >> put an r in front of the directory string: r'...'
> >
> > thanks. That works
> 
> Please don't do that. It's the wrong solution -- all you are doing is 
> postponing failure. It will *seem* to work, until one day you will write 
> something like this:
> 
> directory = r'D:\directory\'
> 
> and you will get a mysterious failure. Chris gave you the right solution: 
> use forward slashes instead of backslashes for all paths.
> 
> os.chdir('D:/Projects/Initiatives/machine learning/programs')
> 
> 
> 
> 
> -- 
> Steven D'Aprano
> "Ever since I learned about confirmation bias, I've been seeing
> it everywhere." -- Jon Ronson

alright. I will do that but still I don't have an answer why I got the error in 
the first place.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: list initialize with ?

[Sharan Basappa]

On Saturday, 30 June 2018 17:48:05 UTC+5:30, Steven D'Aprano  wrote:
> On Sat, 30 Jun 2018 04:50:10 -0700, Sharan Basappa wrote:
> 
> > Can anyone explain to me what the ? does here:
> > 
> > ignore_words = ['?']
> 
> Its a question mark inside a string, which is inside a list. You can put 
> anything you like in strings:
> 
> 'a'
> 
> 'abcde'
> 
> even punctuation like '?'. Then you can put the string inside a list.
> 
> What you do with it, I have no idea -- presumably its your code.
> 
> 
> -- 
> Steven D'Aprano
> "Ever since I learned about confirmation bias, I've been seeing
> it everywhere." -- Jon Ronson

oh, ok. I assumed that ? has some special meaning.
I should be able to find out more. 

PS: Actually, its not my code. I am using an online code as reference for my 
research.
-- 
https://mail.python.org/mailman/listinfo/python-list

is my interpreation correct

[Sharan Basappa]

A code I am using as reference has the following line:
from nltk.stem.lancaster import LancasterStemmer

I am inferring the following based on above:
1) nltk is a package
2) nltk itself may have module because I see - 
nltk.word_tokenize(pattern['sentence']) in the code
3) nltk has a package named stem which has another package named Lancaster that 
has LancasterStemmer package

Somehow, I get confused with what is the package, module and function in third 
party packages like above.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: error in os.chdir

[Karsten Hilbert]

On Sat, Jun 30, 2018 at 05:46:59AM -0700, Sharan Basappa wrote:

> > >> The quick fix:
> > >> 
> > >> put an r in front of the directory string: r'...'
> > 
> > Please don't do that. It's the wrong solution -- all you are doing is 
> > postponing failure. It will *seem* to work, until one day you will write 
> > something like this:
> > 
> > directory = r'D:\directory\'
> > 
> > and you will get a mysterious failure. Chris gave you the right solution: 
> > use forward slashes instead of backslashes for all paths.
> 
> alright. I will do that but still I don't have an answer why I got the error 
> in the first place.

For that you'll have to read up on strings and escaping.

https://docs.python.org/2/tutorial/introduction.html#strings

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.7 Windows Help Behaviour

[BlindAnagram]

On 30/06/2018 10:43, Steven D'Aprano wrote:
> On Fri, 29 Jun 2018 12:53:15 -0400, Terry Reedy wrote:
> 
>> On 6/29/2018 6:14 AM, BlindAnagram wrote:
>>> In Python 3.7.0 on Windows the help file (python370.chm) displays with
>>> a fixed line length and does not adjust its line length when the user
>>> expands the help window horizontally.  This behaviour is different to
>>> that of the Python 3.6 help file (python360.chm) which adjusts its text
>>> to fit the horizontal width of the help window.
>>>
>>> Is this a deliberate change or one that can be turned on or off in some
>>> way (I prefer the Python 3.6 behaviour)?
>>
>> I believe that this is a deliberate regression imposed by 'experts' who
>> believe in form over function and 'controlling the user experience'.
>> 3.6.6 has been 'fixated' also.
> 
> Sounds like somebody should raise a bug report.

I see that this has been done:

  https://bugs.python.org/issue34006

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

Re: error in os.chdir

[Sharan Basappa]

On Saturday, 30 June 2018 18:55:53 UTC+5:30, Karsten Hilbert  wrote:
> On Sat, Jun 30, 2018 at 05:46:59AM -0700, Sharan Basappa wrote:
> 
> > > >> The quick fix:
> > > >> 
> > > >> put an r in front of the directory string: r'...'
> > > 
> > > Please don't do that. It's the wrong solution -- all you are doing is 
> > > postponing failure. It will *seem* to work, until one day you will write 
> > > something like this:
> > > 
> > > directory = r'D:\directory\'
> > > 
> > > and you will get a mysterious failure. Chris gave you the right solution: 
> > > use forward slashes instead of backslashes for all paths.
> > 
> > alright. I will do that but still I don't have an answer why I got the 
> > error in the first place.
> 
> For that you'll have to read up on strings and escaping.
> 
>   https://docs.python.org/2/tutorial/introduction.html#strings
> 
> Karsten
> -- 
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

sorry. I mean why my code worked in one case but did not in the other one.

This worked - os.chdir('D:\Projects\Initiatives\machine learning\programs') 

This did not work - os.chdir('D:\Projects\Initiatives\machine 
learning\programs\assertion')

only difference is, I added an additional directory in the problematic case.

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

Re: error in os.chdir

[Karsten Hilbert]

On Sat, Jun 30, 2018 at 07:34:46AM -0700, Sharan Basappa wrote:

> sorry. I mean why my code worked in one case but did not in the other one.
> 
> This worked - os.chdir('D:\Projects\Initiatives\machine learning\programs') 
> 
> This did not work - os.chdir('D:\Projects\Initiatives\machine 
> learning\programs\assertion')
> 
> only difference is, I added an additional directory in the problematic case.

The answer lies in the (inadvertant) use of escaping.

Which is the very reason _why_ forward slashes were favoured
over backward ones.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

using trace module in enthought

[Sharan Basappa]

I am using enthought for python. Trace module seems to be very useful for my 
work but somehow I am unable to make it work.

When I use the following option, I get the following error:
%run -m trace  --trace "D:/Projects/Initiatives/machine 
learning/programs/debug_1.py"
UsageError: option --trace not recognized ( allowed: "nidtN:b:pD:l:rs:T:em:G" )

%run -m trace  --trace "D:/Projects/Initiatives/machine 
learning/programs/debug_1.py" --trace
UsageError: option --trace not recognized ( allowed: "nidtN:b:pD:l:rs:T:em:G" )


 %run -m trace "D:/Projects/Initiatives/machine learning/programs/debug_1.py" 
--trace
D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\trace.py: 
must specify one of --trace, --count, --report, --listfuncs, or --trackcalls

SystemExitTraceback (most recent call last)
D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\runpy.pyc in 
run_module(mod_name, init_globals, run_name, alter_sys)
186 if alter_sys:
187 return _run_module_code(code, init_globals, run_name,
--> 188 fname, loader, pkg_name)
189 else:
190 # Leave the sys module alone

D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\runpy.pyc in 
_run_module_code(code, init_globals, mod_name, mod_fname, mod_loader, pkg_name)
 80 mod_globals = temp_module.module.__dict__
 81 _run_code(code, mod_globals, init_globals,
---> 82   mod_name, mod_fname, mod_loader, pkg_name)
 83 # Copy the globals of the temporary module, as they
 84 # may be cleared when the temporary module goes away

D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\runpy.pyc in 
_run_code(code, run_globals, init_globals, mod_name, mod_fname, mod_loader, 
pkg_name)
 70__loader__ = mod_loader,
 71__package__ = pkg_name)
---> 72 exec code in run_globals
 73 return run_globals
 74 

D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\trace.py in 
()
817 
818 if __name__=='__main__':
--> 819 main()

D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\trace.py in 
main(argv)
770 
771 if not (count or trace or report or listfuncs or countcallers):
--> 772 _err_exit("must specify one of --trace, --count, --report, "
773   "--listfuncs, or --trackcalls")
774 

D:\Users\sharanb\AppData\Local\Enthought\Canopy\edm\envs\User\lib\trace.py in 
_err_exit(msg)
655 def _err_exit(msg):
656 sys.stderr.write("%s: %s\n" % (sys.argv[0], msg))
--> 657 sys.exit(1)
658 
659 def main(argv=None):

SystemExit: 1

I don't know where I am going wrong.
-- 
https://mail.python.org/mailman/listinfo/python-list

Logger option

[Sharan Basappa]

Can anyone tell me if there are some good logger modules in Python.
I have tried both logging and trace in Canopy and both are not working.

Any help is appreciated.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Logger option

[Karsten Hilbert]

On Sat, Jun 30, 2018 at 10:02:13AM -0700, Sharan Basappa wrote:

> I have tried both logging and trace in Canopy and both are not working.

You will have to be more specific.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I lost nearly all my modules installing 3.7

[Elliott Roper]

On 30 Jun 2018, dieter wrote
(in article):

> Elliott Roper  writes:
> > ...
> > install scipy wrote an error message longer than War and Peace that finished
> > with:-
> > 
> > error: library dfftpack has Fortran sources but no Fortran compiler found
>
> An error message of the type I like: precise:
> Install a "Fortran compiler" and try again.
>
> > ...
> > and matplotlib produced a beautifully formatted report that started with:
> > __
> > Complete output from command python setup.py egg_info:
> > IMPORTANT WARNING:
>
> This is a warning only (even though it is marked as important).
>
> > pkg-config is not installed.
> > matplotlib may not be able to find some of its dependencies
>
> And the warning message is precise again: install "pkg-config"
> to get rid of it.
>
> I do not know "pkg-config". The name seems to indicate an
> operating system package; but, it might also be a Python extension
> package (less likely).
> I would start with the "matplotlib"
> installation instructions to look for information about it.

Thanks Jim and dieter.

I should have mentioned that none of this went wrong in 3.6. All I'm after 
are packages I can install with pip3. I really don't need to go down all the 
twisty passages installing Fortran

I DID have pkg-config installed in ~/Library . site-packages. I 
uninstalled it and re-installed with an Admin account, where it appeared in 
/Library ... site-packages
but that made no difference, pip3 install -- user matplotlib still 
complaining about pkg-config not being installed and not being able to find 
png

I was wrong about
Both look like not having write access to
/private/var/folders/v2/gj68t3zx3bd6764zxc332ctcgr/T/pip-install-
np76k73m/

I do have write access. It looks like a Mac specific per user directory tree 
for temporary stuff and installation records.

I really am out of my depth here.

I have found a post with a very similar problem on Stack Exchange
https://stackoverflow.com/questions/51082934/matplotlib-2-2-2-installation-
error-on-high-sierra
sadly without an answer

-- 
To de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 
637F 896B C810 E199 7E5C A9E4 8E59 E248

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

Re: error in os.chdir

[Jim Lee]

On 06/30/18 07:34, Sharan Basappa wrote:


sorry. I mean why my code worked in one case but did not in the other one.

This worked - os.chdir('D:\Projects\Initiatives\machine learning\programs')

This did not work - os.chdir('D:\Projects\Initiatives\machine 
learning\programs\assertion')

only difference is, I added an additional directory in the problematic case.

In Python (and many other languages), certain non-printable characters 
are represented in strings by "escape sequences".  Those escape 
sequences begin with a backslash "\".  In your particular case, there 
are five (possible) escape sequences: "\P", "\I", "\m", "\p", and "\a".  
All but the last one have no meaning to Python, so they are treated 
literally.  The last one, however, translates to "BEL", or 0x07, which 
is a non-printable code that was once sent to teletypes to ring the 
bell, alerting the operator to an incoming message, or to signal the 
completion of a long-running job.


There are three ways to fix your code.  One is to replace the 
backslashes with forward slashes.  Python will translate them internally 
to the correct path separators for your operating system.


Another way is to replace the backslashes with os.sep, which is a 
portable representation of the native path separator.


A third way is to escape all literal backslashes by doubling them - "\\" 
instead of "\".  However, this will make your code Windows-only (but it 
already is, so that may not matter to you).


-Jim


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

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[Peter J. Holzer]

On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> On Thu, Jun 28, 2018 at 1:27 PM, Marko Rauhamaa  wrote:
> > Dan Stromberg :
> > > On Wed, Jun 27, 2018 at 10:31 PM, Marko Rauhamaa 
> > > wrote:
> > >> Dan Stromberg :
> > >> >> > The problem can be solved by turning on the SO_REUSEADDR flag of
> > >> >> > the socket.
> > >> > BTW, it's a security feature you're turning off. If you're on a
> > >> > multiuser box, it prevents a second user from stealing lingering
> > >> > connections from a first user on the same port.
[...]
> Start an echo server process P that listens on tcp/.
> 
> Initiate a connection from a client machine to process P at tcp/. It
> works as expected.
> 
> Kill P.
> 
> Initiate a connection from a client machine to process P at tcp/.  It
> gives a connection refused as expected.
> 
> If someone else comes along soon after and starts a different echo server
> process Q at tcp/ on the same server, it starts up immediately if P
> used SO_REUSEADDR.
> 
> Then initiate a connection from the same (or different) client machine to
> process P (which no longer exists).  Q gets the data intended for P.

I don't think this is the issue TIME_WAIT is intended to prevent.
Firstly, why would this security issue stop to be a security issue after
two minutes? Secondly, it depends on the attacker not knowing about
SO_REUSEADDR, which seems overly optimistic.

What TIME_WAIT is IMHO intended to prevent is mixing up two TCP
connections:

You have just killed P, but some packets from a connection are still in
transit. 

Now you start P again and one of the clients starts another connection.
While this connection is active, a packet from the previous connection
arrives. If its sequence number is in the right range, it will be
accepted as part of the current connection.

This can be prevented by not restarting the server until all packets for
old connections are guarantueed to have expired.

In practice this scenario is pretty unlikely: Not only has the client
have to get the same client port, it also needs to get the sequence
numbers (which are 32 bit numbers chosen at random at connection time)
just right.

OTOH, having to wait 2 minutes before you can restart your server is a
nuisance. Therefore, everybody uses SO_REUSEADDR.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[Jim Lee]

On 06/28/18 18:04, Dan Stromberg wrote:

[snip]
Start an echo server process P that listens on tcp/.

Initiate a connection from a client machine to process P at tcp/. It
works as expected.

Kill P.

Initiate a connection from a client machine to process P at tcp/.  It
gives a connection refused as expected.

If someone else comes along soon after and starts a different echo server
process Q at tcp/ on the same server, it starts up immediately if P
used SO_REUSEADDR.

Then initiate a connection from the same (or different) client machine to
process P (which no longer exists).  Q gets the data intended for P.




There are all sorts of theoretical vulnerabilities that simply don't 
manifest in real life.  I think this is one of them.


Me: "It hurts when I do this."  Doctor: "Well, don't do that."

-Jim

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

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[Dan Stromberg]

On Sat, Jun 30, 2018 at 11:19 AM, Peter J. Holzer  wrote:

> On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> > On Thu, Jun 28, 2018 at 1:27 PM, Marko Rauhamaa 
> wrote:
> > Start an echo server process P that listens on tcp/.
> >
> > Initiate a connection from a client machine to process P at tcp/. It
> > works as expected.
> >
> > Kill P.
> >
> > Initiate a connection from a client machine to process P at tcp/.  It
> > gives a connection refused as expected.
> >
> > If someone else comes along soon after and starts a different echo server
> > process Q at tcp/ on the same server, it starts up immediately if P
> > used SO_REUSEADDR.
> >
> > Then initiate a connection from the same (or different) client machine to
> > process P (which no longer exists).  Q gets the data intended for P.
>
> I don't think this is the issue TIME_WAIT is intended to prevent.
>

It handles more than one thing.

Firstly, why would this security issue stop to be a security issue after
> two minutes?


It's a mitigation of both problems we've discussed.


> Secondly, it depends on the attacker not knowing about
> SO_REUSEADDR, which seems overly optimistic.
>
Not really, no.  People on remote machines know little about process
bounces.  And it's pretty easy to write a script that will check if a
process is up repeatedly, starting a daemon when its not.  And you don't
have to know about SO_REUSEADDR to write that script.

What TIME_WAIT is IMHO intended to prevent is mixing up two TCP
> connections:
>
Yes, it does this too.

This can be prevented by not restarting the server until all packets for
> old connections are guarantueed to have expired.
>

Yes, and not using SO_REUSEADDR helps this happen.


> In practice this scenario is pretty unlikely: Not only has the client
> have to get the same client port, it also needs to get the sequence
> numbers (which are 32 bit numbers chosen at random at connection time)
> just right.
>

Right, it's a mitigation.

OTOH, having to wait 2 minutes before you can restart your server is a
> nuisance. Therefore, everybody uses SO_REUSEADDR.
>
During development, it's a good practice to setsockopt SO_REUSEADDR.

In production, different rules may or may not apply.  On multiuser systems,
it's more important than on most of today's single-purpose virtual machines.

Some people feel that "security issues" must all be religiously 100%
avoided completely, or they'll offend the computer gods.  This evidences a
lack of understanding about the practical aspects of security issues.
Security is very much a spectrum - multidimensional even.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[Peter J. Holzer]

On 2018-06-30 14:01:56 -0700, Dan Stromberg wrote:
> On Sat, Jun 30, 2018 at 11:19 AM, Peter J. Holzer  wrote:
> > On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> > > If someone else comes along soon after and starts a different echo server
 ^^
> > > process Q at tcp/ on the same server, it starts up immediately if P
> > > used SO_REUSEADDR.
> > >
> > > Then initiate a connection from the same (or different) client machine to
> > > process P (which no longer exists).  Q gets the data intended for P.
> >
> > I don't think this is the issue TIME_WAIT is intended to prevent.
[...]
> > Secondly, it depends on the attacker not knowing about
> > SO_REUSEADDR, which seems overly optimistic.
> >
> Not really, no.  People on remote machines know little about process
> bounces.

But the attack you described isn't remote. It is performed by another
user on the same machine.

> And it's pretty easy to write a script that will check if a process is
> up repeatedly, starting a daemon when its not.

Right. This is something the attacker can do (and I would assume they
do).

> And you don't have to know about SO_REUSEADDR to write that script.

No. But if the attacker does know about SO_REUSEADDR they can start
their own server as soon as the notice that the server is down.
Otherwise they have to wait for two minutes.

Actually, I overlooked something: If you don't use SO_REUSEADDR, but the
attacker does, you have to wait, but the attacker doesn't - so this
gives a huge advantage to the attacker. If you do use SO_REUSEADDR, at
least you are an equal footing.


> OTOH, having to wait 2 minutes before you can restart your server is a
> > nuisance. Therefore, everybody uses SO_REUSEADDR.
> >
> During development, it's a good practice to setsockopt SO_REUSEADDR.
> 
> In production, different rules may or may not apply.  On multiuser systems,

In production, being able to restart a failed server quickly is usually
more important than to prevent a very low probability mixup on the TCP
level. Especially as you can't rely on TCP for integrity and
confidentiality anyway and have to put an extra layer (typically TLS)
for that on top.

> it's more important than on most of today's single-purpose virtual machines.
> 
> Some people feel that "security issues" must all be religiously 100%
> avoided completely, or they'll offend the computer gods.  This evidences a
> lack of understanding about the practical aspects of security issues.
> Security is very much a spectrum - multidimensional even.

I agree fully. The old adage that "security is binary" is utter
balderdash. However, I do feel that we should only call something a
"security feature" if it actually increases security. Not using
SO_REUSEADDR doesn't - quite the opposite.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: naming methods in python (std lib)

[Terry Reedy]

On 6/30/2018 7:27 AM, Abdur-Rahmaan Janhangeer wrote:

normally, naming methods in python is given by

method_name

but i see some cases where this is not followed in the std lib

ex :  dict.fromkeys

should it not have been

from_keys?


No.  _ is an option, not a requirement and usually not used for short names.


--
Terry Jan Reedy

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

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[T Berger]

On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:

> The key point here from Jim is "simultaneously". Are you properly shutting 
> down 
> the Flask instance in IDLE before running from Terminal, and vice versa?

Cameron, I try every option to quit either program, but they don't work. Or I 
should say, they mostly don't work. Once in a while they do. The one option 
which works (which is not a feasible option) is rebooting my Mac (actually that 
might not work either. I think I got the error message again this morning when 
I rebooted).
 
> Otherwise both will try to use the same local port and There Can Be Only One.
> 
> Do you need to run from both environments at the same time? I'd have thought 
> not, which also leads me to: why are you flicking from IDLE to Terminal? I 
> would have imagined using one or the other normally, not both. It isn't wrong 
> to use both, just surprising.

I'm working from a Python manual. I created the webapp in IDLE, and test it in 
Terminal, per the instructions in the manual. I use IDLE to edit my program, 
and then test it in terminal. When I go from one to the other, I get the error 
message. IDLE has a keyboard shortcut for quitting the shell—Cntl + C—but it 
doesn't work. Neither does restarting the shell. Neither does entering the kill 
command line, not in IDLE or terminal.

Do you have any other suggestions? I'm going to email the writer. He doesn't 
mention how to deal with problems that might arise from working with two 
programs at the same time. Maybe Cntl+C should do it, but in my case it doesn't.

Tamara 

> Cheers,
> Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: is my interpreation correct

[Terry Reedy]

On 6/30/2018 8:57 AM, Sharan Basappa wrote:

A code I am using as reference has the following line:
from nltk.stem.lancaster import LancasterStemmer


The CapitalName indicates a class.


I am inferring the following based on above:
1) nltk is a package
2) nltk itself may have module because I see - 
nltk.word_tokenize(pattern['sentence']) in the code


word_tokenize is a function.


3) nltk has a package named stem which has another package named Lancaster that 
has LancasterStemmer package


Sometimes one should read the docs instead of guessing.

--
Terry Jan Reedy

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

Re: using trace module in enthought

[Terry Reedy]

On 6/30/2018 12:46 PM, Sharan Basappa wrote:

I am using enthought for python. Trace module seems to be very useful for my 
work but somehow I am unable to make it work.

When I use the following option, I get the following error:
%run


What is 'run' and what does it do?  Does not exist on Windows.
And why use it instead of 'python'?  What OS? What Python version?

 -m trace  --trace "D:/Projects/Initiatives/machine 
learning/programs/debug_1.py"

UsageError: option --trace not recognized ( allowed: "nidtN:b:pD:l:rs:T:em:G" )


This does not look error message from current trace module.

f:\dev\3x>python -m trace -x
Running Debug|Win32 interpreter...
usage: trace.py [-h] [--version] [-c] [-t] [-l] [-T] [-r | -R] [-f FILE]
[-C COVERDIR] [-m] [-s] [-g] [--ignore-module 
IGNORE_MODULE]

[--ignore-dir IGNORE_DIR]
[filename] ...
trace.py: error: unrecognized arguments: -x

--
Terry Jan Reedy

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

$s and %d in python

[Sharan Basappa]

Is there any difference in %d and %s below. I get the same result:

my_name = 'Zed A. Shaw'
my_age = 35 # not a lie
my_height = 74 # inches

print "Let's talk about %s." % my_name
print "He's %d inches tall." % my_height
print "He's %s inches tall." % my_height

Let's talk about Zed A. Shaw.
He's 74 inches tall.
He's 74 inches tall.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[MRAB]

On 2018-06-30 23:01, T Berger wrote:

On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:

The key point here from Jim is "simultaneously". Are you properly shutting down 
the Flask instance in IDLE before running from Terminal, and vice versa?


Cameron, I try every option to quit either program, but they don't work. Or I 
should say, they mostly don't work. Once in a while they do. The one option 
which works (which is not a feasible option) is rebooting my Mac (actually that 
might not work either. I think I got the error message again this morning when 
I rebooted).
  

Otherwise both will try to use the same local port and There Can Be Only One.

Do you need to run from both environments at the same time? I'd have thought 
not, which also leads me to: why are you flicking from IDLE to Terminal? I 
would have imagined using one or the other normally, not both. It isn't wrong 
to use both, just surprising.


I'm working from a Python manual. I created the webapp in IDLE, and test it in 
Terminal, per the instructions in the manual. I use IDLE to edit my program, 
and then test it in terminal. When I go from one to the other, I get the error 
message. IDLE has a keyboard shortcut for quitting the shell—Cntl + C—but it 
doesn't work. Neither does restarting the shell. Neither does entering the kill 
command line, not in IDLE or terminal.


Ctrl+C is the shortcut for interrupting a Python program running on 
IDLE's or Windows command line. In IDLE's editor, Ctrl+C is the shortcut 
for copying text the clipboard.


The keyboard shortcut for quitting IDLE completely is Ctrl+Q.



Do you have any other suggestions? I'm going to email the writer. He doesn't 
mention how to deal with problems that might arise from working with two 
programs at the same time. Maybe Cntl+C should do it, but in my case it doesn't.


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

Re: $s and %d in python

[Cameron Simpson]

On 30Jun2018 05:01, Sharan Basappa  wrote:

Is there any difference in %d and %s below. I get the same result:

my_name = 'Zed A. Shaw'
my_age = 35 # not a lie
my_height = 74 # inches

print "Let's talk about %s." % my_name
print "He's %d inches tall." % my_height
print "He's %s inches tall." % my_height

Let's talk about Zed A. Shaw.
He's 74 inches tall.
He's 74 inches tall.


%d interpolates a decimal string repesentation of a numeric value.
%s interpolates the default "str" representation of an arbitrary value.

The variable my_height is an int, and for an int both these things are the 
same.


Try:

 my_height = 7.3

and see what you get.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: error in os.chdir

[eryk sun]

On Sat, Jun 30, 2018 at 11:21 AM, Chris Angelico  wrote:
> On Sat, Jun 30, 2018 at 9:05 PM, Sharan Basappa
>  wrote:
>>
>> 0
>> down vote
>> favorite
>>
>> I need to change directory to my local working directory in windows and then 
>> open a file for processing.
>> Its just a 3 lines code, as below:
>> import csv
>> import os
>> os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
>> The error is as follows:
>> WindowsError: [Error 123] The filename, directory name, or volume label 
>> syntax is incorrect: 'D:\Projects\Initiatives\machine 
>> learning\programs\x07ssertion'
>> Notice x07 character that has replaced character x07.
>> I have a similar code but that goes through fine:
>> import csv
>> import os
>> os.chdir('D:\Projects\Initiatives\machine learning\programs')
>
> Use forward slashes instead of backslashes for all paths.
>
> os.chdir('D:/Projects/Initiatives/machine learning/programs')

Only use forward slashes for legacy DOS paths passed to Windows API
functions. Do not use forward slashes for paths in command line
arguments, \\?\ prefixed paths, or registry paths.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: error in os.chdir

[Chris Angelico]

On Sun, Jul 1, 2018 at 9:36 AM, eryk sun  wrote:
> On Sat, Jun 30, 2018 at 11:21 AM, Chris Angelico  wrote:
>> On Sat, Jun 30, 2018 at 9:05 PM, Sharan Basappa
>>  wrote:
>>>
>>> 0
>>> down vote
>>> favorite
>>>
>>> I need to change directory to my local working directory in windows and 
>>> then open a file for processing.
>>> Its just a 3 lines code, as below:
>>> import csv
>>> import os
>>> os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
>>> The error is as follows:
>>> WindowsError: [Error 123] The filename, directory name, or volume label 
>>> syntax is incorrect: 'D:\Projects\Initiatives\machine 
>>> learning\programs\x07ssertion'
>>> Notice x07 character that has replaced character x07.
>>> I have a similar code but that goes through fine:
>>> import csv
>>> import os
>>> os.chdir('D:\Projects\Initiatives\machine learning\programs')
>>
>> Use forward slashes instead of backslashes for all paths.
>>
>> os.chdir('D:/Projects/Initiatives/machine learning/programs')
>
> Only use forward slashes for legacy DOS paths passed to Windows API
> functions. Do not use forward slashes for paths in command line
> arguments, \\?\ prefixed paths, or registry paths.

"Legacy" implies that it's the old standard that is now deprecated,
but the truth is that MOST path names are going to work fine with
forward slashes. Registry paths aren't file paths, command line
arguments are interpreted by the target program (and in many MANY
cases, forward slashes are absolutely fine), and so it's just the \\?\
paths that will need to be special. So, let me rephrase what you said:

Forward slashes work for all Windows file paths, except those that are
prefixed with \\?\.

Is that correct?

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

Re: $s and %d in python

[Terry Reedy]

On 6/30/2018 7:04 PM, Cameron Simpson wrote:

On 30Jun2018 05:01, Sharan Basappa  wrote:

Is there any difference in %d and %s below. I get the same result:

my_name = 'Zed A. Shaw'
my_age = 35 # not a lie
my_height = 74 # inches

print "Let's talk about %s." % my_name
print "He's %d inches tall." % my_height
print "He's %s inches tall." % my_height

Let's talk about Zed A. Shaw.
He's 74 inches tall.
He's 74 inches tall.


%d interpolates a decimal string repesentation of a numeric value > %s interpolates the 
default "str" representation of an arbitrary value.

The variable my_height is an int, and for an int both these things are 
the same.


Try:

  my_height = 7.3

and see what you get.


or my_height = '74'

--
Terry Jan Reedy


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

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[Gregory Ewing]

Dan Stromberg wrote:

On Thu, Jun 28, 2018 at 10:30 PM, Marko Rauhamaa  wrote:


Well, the same security issue can be demonstrated without SO_REUSEADDR:

The security issue can be real but is not directly related with
SO_REUSEADDR.


Yes, it can.  It just takes longer.


I don't see how the address-reuse timeout can be a security
measure, because the process trying to take over the address
can easily circumvent it by setting SO_REUSEADDR.

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

Re: error in os.chdir

[Terry Reedy]

On 6/30/2018 7:36 PM, eryk sun wrote:

On Sat, Jun 30, 2018 at 11:21 AM, Chris Angelico  wrote:

On Sat, Jun 30, 2018 at 9:05 PM, Sharan Basappa
 wrote:


0
down vote
favorite

I need to change directory to my local working directory in windows and then 
open a file for processing.
Its just a 3 lines code, as below:
import csv
import os
os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
The error is as follows:
WindowsError: [Error 123] The filename, directory name, or volume label syntax 
is incorrect: 'D:\Projects\Initiatives\machine learning\programs\x07ssertion'
Notice x07 character that has replaced character x07.
I have a similar code but that goes through fine:
import csv
import os
os.chdir('D:\Projects\Initiatives\machine learning\programs')


Use forward slashes instead of backslashes for all paths.

os.chdir('D:/Projects/Initiatives/machine learning/programs')


Only use forward slashes for legacy DOS paths passed to Windows API
functions. Do not use forward slashes for paths in command line
arguments, \\?\ prefixed paths, or registry paths.


To the best of my memeory, forward slashes work in arguments.
They do not work in paths to an executable.

F:\>cd dev/3x works

f:\dev\3x> ../pull  prints
'..' is not recognized as an internal or external command,
operable program or batch file.
because /pull is seen as an option switch.  ..\pull does (because 
..\pull.bat exists).





--
Terry Jan Reedy

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

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[Grant Edwards]

On 2018-06-30, Gregory Ewing  wrote:
> Dan Stromberg wrote:
>> On Thu, Jun 28, 2018 at 10:30 PM, Marko Rauhamaa  wrote:
>> 
>>>Well, the same security issue can be demonstrated without SO_REUSEADDR:
>>>
>>>The security issue can be real but is not directly related with
>>>SO_REUSEADDR.
>>
>> Yes, it can.  It just takes longer.
>
> I don't see how the address-reuse timeout can be a security
> measure, because the process trying to take over the address
> can easily circumvent it by setting SO_REUSEADDR.

I've been thinking the same thing.  One _might_ be able to argue
against the OS providing the SO_REUSEADDR option on security grounds.
But given that it _does_ exist, I don't see how using it can be
claimed to decrease security.

-- 
Grant


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

Re: error in os.chdir

[eryk sun]

On Sat, Jun 30, 2018 at 11:42 PM, Chris Angelico  wrote:
> On Sun, Jul 1, 2018 at 9:36 AM, eryk sun  wrote:
>> On Sat, Jun 30, 2018 at 11:21 AM, Chris Angelico  wrote:
>>> On Sat, Jun 30, 2018 at 9:05 PM, Sharan Basappa
>>>  wrote:

 0
 down vote
 favorite

 I need to change directory to my local working directory in windows and 
 then open a file for processing.
 Its just a 3 lines code, as below:
 import csv
 import os
 os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
 The error is as follows:
 WindowsError: [Error 123] The filename, directory name, or volume label 
 syntax is incorrect: 'D:\Projects\Initiatives\machine 
 learning\programs\x07ssertion'
 Notice x07 character that has replaced character x07.
 I have a similar code but that goes through fine:
 import csv
 import os
 os.chdir('D:\Projects\Initiatives\machine learning\programs')
>>>
>>> Use forward slashes instead of backslashes for all paths.
>>>
>>> os.chdir('D:/Projects/Initiatives/machine learning/programs')
>>
>> Only use forward slashes for legacy DOS paths passed to Windows API
>> functions. Do not use forward slashes for paths in command line
>> arguments, \\?\ prefixed paths, or registry paths.
>
> "Legacy" implies that it's the old standard that is now deprecated,

I did not mean to imply that DOS paths are deprecated. That's not what
legacy means to me. I only meant that they're inherited from an old
system. The native API does not use forward slash as a path separator.
It's just a name character in NT (except in most file-system
implementations, which reserve forward slash as an invalid filename
character to avoid confusion). This doesn't affect device names. You
can call DefineDosDevice or native NtCreateSymbolicLinkObject to
create a device name with a slash in it.

The Windows file API supports forward slash as a path separator, which
it implements by rewriting the path via ntdll library functions such
as RtlDosPathNameToNtPathName_U_WithStatus. Paths prefixed with \\?\
bypass this normalization step, so they cannot use forward slash as
the path separator.

> Registry paths aren't file paths,

You said to use forward slash for "all paths".

Also, from the POV of the NT API, registry paths and file paths are
all just paths, such as "\Registry\Machine\Software" and
"\Device\HarddiskVolume2\Program Files". The executive's Object
Manager parses the path up to an object with a ParseProcedure (e.g.
"Registry" or "HarddiskVolume2"), which in turn parses the rest of the
path. Registry paths in the Windows API are closer to native NT paths,
since they don't support forward slash as a path separator and
implement relative paths NT style, i.e. relative to a Key handle. The
Windows API doesn't expose handle-relative paths for file paths, but
it uses this feature implicitly by keeping a handle open for the
process working directory.

> command line arguments are interpreted by the target program (and in many
> MANY cases, forward slashes are absolutely fine),

You can't generalize this. In many cases it's not ok. Most
command-line utilities that use ulib make a simply assumption when
parsing the command line that forward slash is used for options
(switches). It's best to normalize paths in a command line via
os.path.normpath.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: error in os.chdir

[Steven D'Aprano]

On Sat, 30 Jun 2018 23:36:40 +, eryk sun wrote:

> Only use forward slashes for legacy DOS paths passed to Windows API
> functions. Do not use forward slashes for paths in command line
> arguments, \\?\ prefixed paths, or registry paths.

I don't see why this is relevant, or at least not the "command line 
arguments" and "registry paths" parts.

We're talking about using file names in Python, not the Windows command 
line (Power Shell?), and not registry paths.

I guess that if the user is using a path beginning with \\?\ they may or 
may not need to use backslashes, but I have no way of testing it, and I 
would expect that Python will correctly replace //?/ with backslashes the 
same as it does for any other file system path.

I know that Chris said "for all paths" but in context that's to be 
understood as *file system paths*. We wouldn't interpret him as meaning 
this:

import package/subpackage/module

instead of using dots, so I think registry paths is irrelevant.

(Besides, Python doesn't have an API for interacting directly with the 
registry.)




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: list initialize with ?

[Steven D'Aprano]

On Sat, 30 Jun 2018 05:49:03 -0700, Sharan Basappa wrote:

> On Saturday, 30 June 2018 17:48:05 UTC+5:30, Steven D'Aprano  wrote:
>> On Sat, 30 Jun 2018 04:50:10 -0700, Sharan Basappa wrote:
>> 
>> > Can anyone explain to me what the ? does here:
>> > 
>> > ignore_words = ['?']
>> 
>> Its a question mark inside a string, which is inside a list. You can
>> put anything you like in strings:
[...]
> oh, ok. I assumed that ? has some special meaning. I should be able to
> find out more.

It could have whatever special meaning the creator of the code chooses to 
give it. Without knowing the context of what you are doing with it, what 
libraries you are using, what functions it gets passed to, it could mean 
anything.

Your question is like asking:

"I have a variable called x, what does it mean?"


Without more information, how could we tell?


> PS: Actually, its not my code. I am using an online code as reference
> for my research.

Then you should check the documentation for this online code.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[Steven D'Aprano]

On Sat, 30 Jun 2018 23:49:41 +0200, Peter J. Holzer wrote:

> The old adage that "security is binary" is utter balderdash.

I think that "old adage" is one of those ones that only people denying it 
actually use.

I've never seen anyone say "security is binary" except to disagree with 
it, "don't make the mistake of thinking security is binary".

I mean, we lock our front doors, even though burglars can break in 
through a window, right?



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: error in os.chdir

[Chris Angelico]

On Sun, Jul 1, 2018 at 10:20 AM, eryk sun  wrote:
> On Sat, Jun 30, 2018 at 11:42 PM, Chris Angelico  wrote:
>> "Legacy" implies that it's the old standard that is now deprecated,
>
> I did not mean to imply that DOS paths are deprecated. That's not what
> legacy means to me.

Unless you are Humpty Dumpty, you can't just say "that's not what it
means to me". Sorry. People WILL see "legacy" as an implication that
"only the old stuff goes that way". You are responding to a thread in
which someone used a perfectly ordinary file path, and you said that
only legacy paths can be done with slashes. At best, you are
technically correct and functionally deceptive.

>> Registry paths aren't file paths,
>
> You said to use forward slash for "all paths".

*facepalm* Okay. I said "all paths", but I did not refer to XPath
(although that also uses the slash character), nor registry paths, nor
the footpath that runs parallel to the road outside my house. You're
absolutely right, there are no forward slashes in the path that leads
to my door. My bad. I'm sorry that the word "all" has to be
interpreted within the context of the thread that it was used in.
Whoops.

>> command line arguments are interpreted by the target program (and in many
>> MANY cases, forward slashes are absolutely fine),
>
> You can't generalize this. In many cases it's not ok. Most
> command-line utilities that use ulib make a simply assumption when
> parsing the command line that forward slash is used for options
> (switches). It's best to normalize paths in a command line via
> os.path.normpath.

Ahh but I *can* generalize it. In many cases, forward slashes ARE
fine, and I can prove it by listing off large numbers of programs that
are perfectly happy to receive file paths with slashes in them.
Surprise surprise, most of those programs are going to be taking those
paths and handing them straight to the OS. In other words: THE OS
SUPPORTS SLASHES. Does this surprise anyone?

So what if, internally, that's done by converting them to backslashes?
No Python program needs to care. In fact, there are other conversions,
too - the underlying file system is most likely using UTF-16 paths,
but your Python program needn't use UTF-16. No, it simply uses a plain
old string literal - a Unicode string. The OP need not be concerned
about any of these fiddlinesses, unless in some way they actually
affect Python.

Congratulations on being technically correct (maybe) and utterly unhelpful.

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

Re: list initialize with ?

[Steven D'Aprano]

On Sat, 30 Jun 2018 05:49:03 -0700, Sharan Basappa wrote:

> On Saturday, 30 June 2018 17:48:05 UTC+5:30, Steven D'Aprano  wrote:
>> On Sat, 30 Jun 2018 04:50:10 -0700, Sharan Basappa wrote:
>> 
>> > Can anyone explain to me what the ? does here:
>> > 
>> > ignore_words = ['?']
>> 
>> Its a question mark inside a string, which is inside a list. You can
>> put anything you like in strings:
[...]
> oh, ok. I assumed that ? has some special meaning. I should be able to
> find out more.

It could have whatever special meaning the creator of the code chooses to 
give it. Without knowing the context of what you are doing with it, what 
libraries you are using, what functions it gets passed to, it could mean 
anything.

Your question is like asking:

"I have a variable called x, what does it mean?"


Without more information, how could we tell?


> PS: Actually, its not my code. I am using an online code as reference
> for my research.

Then you should check the documentation for this online code.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Logger option

[Steven D'Aprano]

On Sat, 30 Jun 2018 10:02:13 -0700, Sharan Basappa wrote:

> Can anyone tell me if there are some good logger modules in Python. I
> have tried both logging and trace in Canopy and both are not working.

When you are talking about a standard module used by hundreds of 
thousands or millions of programmers around the world, and it "doesn't 
work", the chances are 99.999% certain that you are using it wrong, 
not that everyone else is too stupid to have noticed that their code 
isn't working.

If you want help for using logging, start here:

https://docs.python.org/3/howto/logging.html

https://docs.python.org/2/howto/logging.html


https://pymotw.com/3/logging/

https://pymotw.com/2/logging/



https://www.google.com/search?q=logging+getting+started+python




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Logger option

[Chris Angelico]

On Sun, Jul 1, 2018 at 12:03 PM, Steven D'Aprano
 wrote:
> On Sat, 30 Jun 2018 10:02:13 -0700, Sharan Basappa wrote:
>
>> Can anyone tell me if there are some good logger modules in Python. I
>> have tried both logging and trace in Canopy and both are not working.
>
> When you are talking about a standard module used by hundreds of
> thousands or millions of programmers around the world, and it "doesn't
> work", the chances are 99.999% certain that you are using it wrong,
> not that everyone else is too stupid to have noticed that their code
> isn't working.

To be fair, the OP said that it isn't working *in Canopy*, so it could
be an interaction between the logging module and Canopy (which I have
no experience with). So what I'd recommend is something like:

https://www.google.com/search?q=python+logging+canopy

and seeing if that gives any useful information.

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

Re: error in os.chdir

[eryk sun]

On Sun, Jul 1, 2018 at 1:58 AM, Chris Angelico  wrote:
> On Sun, Jul 1, 2018 at 10:20 AM, eryk sun  wrote:
>> On Sat, Jun 30, 2018 at 11:42 PM, Chris Angelico  wrote:
>>> "Legacy" implies that it's the old standard that is now deprecated,
>>
>> I did not mean to imply that DOS paths are deprecated. That's not what
>> legacy means to me.
>
> Unless you are Humpty Dumpty, you can't just say "that's not what it
> means to me". Sorry. People WILL see "legacy" as an implication that
> "only the old stuff goes that way". You are responding to a thread in
> which someone used a perfectly ordinary file path, and you said that
> only legacy paths can be done with slashes. At best, you are
> technically correct and functionally deceptive.

That's fine, and I understand how I could have been misconstrued. I
clarified what I meant. I did not intend to be deceptive.

>>> Registry paths aren't file paths,
>>
>> You said to use forward slash for "all paths".
>
> *facepalm* Okay. I said "all paths", but I did not refer to XPath
> (although that also uses the slash character), nor registry paths, nor
> the footpath that runs parallel to the road outside my house. You're
> absolutely right, there are no forward slashes in the path that leads
> to my door. My bad. I'm sorry that the word "all" has to be
> interpreted within the context of the thread that it was used in.
> Whoops.

I also clarified why to me your "all paths" statement needs to be
qualified to the domain. I use the native API a lot, so for me
registry and file paths are just paths. It's only the Windows API that
separates the two and only the Windows API that allows forward slash
as a path separator in file paths.

>>> command line arguments are interpreted by the target program (and in many
>>> MANY cases, forward slashes are absolutely fine),
>>
>> You can't generalize this. In many cases it's not ok. Most
>> command-line utilities that use ulib make a simply assumption when
>> parsing the command line that forward slash is used for options
>> (switches). It's best to normalize paths in a command line via
>> os.path.normpath.
>
> Ahh but I *can* generalize it. In many cases, forward slashes ARE
> fine, and I can prove it by listing off large numbers of programs that
> are perfectly happy to receive file paths with slashes in them.
> Surprise surprise, most of those programs are going to be taking those
> paths and handing them straight to the OS. In other words: THE OS
> SUPPORTS SLASHES. Does this surprise anyone?

There are many cases for common command-line utilities that do not
support paths with forward slash -- even if you disambiguate by
putting the path in double quotes. In the following examples, I have a
file named "C:\Temp\test.txt" and an existing directory named
"C:\Temp\dest".

Internal CMD commands:

C:\>dir /b "C:/Temp/test.txt"
File Not Found

C:\>type "C:/Temp/test.txt"
The system cannot find the file specified.

C:\>copy "C:/Temp/test.txt" "C:/Temp/dest"
The system cannot find the file specified.
0 file(s) copied.

C:\>del "C:/Temp/test.txt"
The system cannot find the path specified.

External utility commands:

C:\>find "spam" "C:/Temp/*.txt"
File not found - C:TEST.TXT

C:\>findstr "spam" "C:/Temp/*.txt"
FINDSTR: Cannot open C:test.txt

C:\>fc "C:/Temp/test.txt" "C:/Temp/*.txt"
FC: cannot open C:/TEMP/TEST.TXT - No such file or folder

C:\>forfiles /p "C:/Temp" /m *.txt
ERROR: The directory name is invalid.

C:\>where /r "C:/Temp" test.txt
ERROR: Invalid directory specified.

C:\>icacls "C:/Temp/*.txt"
C:test.txt: The system cannot find the file specified.
Successfully processed 0 files; Failed processing 1 files

C:\>takeown /f "C:/Temp/test.txt"
ERROR: File or Directory not found.

C:\>xcopy.exe "C:/Temp/test.txt" "C:/Temp/dest"
0 File(s) copied

In the following case I create "C:\Temp\dest\test.txt" to be replaced
using replace.exe, which silently fails to replace the file:

C:\>replace "C:/Temp/test.txt" "C:/Temp/dest"

C:\>fc C:\Temp\test.txt C:\Temp\dest\test.txt
Comparing files C:\TEMP\test.txt and C:\TEMP\DEST\TEST.TXT
* C:\TEMP\test.txt
spam
* C:\TEMP\DEST\TEST.TXT
eggs
*

> So what if, internally, that's done by converting them to backslashes?
> No Python program needs to care. In fact, there are other conversions,
> too - the underlying file system is most likely using UTF-16 paths,
> but your Python program needn't use UTF-16. No, it simply uses a plain
> old string literal - a Unicode string. The OP need not be concerned
> about any of these fiddlinesses, unless in some way they actually
> affect Python.

A few minor changes in in wording are both technically correct and
don't make the text any more difficult to understand. You're the one
blowing this up beyond proportion and making a mountain out of a small
technical-correction mole hill. Please just let it pass.
-- 
htt

Re: error in os.chdir

[Chris Angelico]

On Sun, Jul 1, 2018 at 12:22 PM, eryk sun  wrote:
>> So what if, internally, that's done by converting them to backslashes?
>> No Python program needs to care. In fact, there are other conversions,
>> too - the underlying file system is most likely using UTF-16 paths,
>> but your Python program needn't use UTF-16. No, it simply uses a plain
>> old string literal - a Unicode string. The OP need not be concerned
>> about any of these fiddlinesses, unless in some way they actually
>> affect Python.
>
> A few minor changes in in wording are both technically correct and
> don't make the text any more difficult to understand. You're the one
> blowing this up beyond proportion and making a mountain out of a small
> technical-correction mole hill. Please just let it pass.

If you can show me a way in which a Python program actually needs to
care about any of these distinctions when dealing with files on
Windows, then I'll admit that the technical correction was needed. You
won't be shelling out to the "dir" command, for instance.

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

Re: $s and %d in python

[Gregory Ewing]

Cameron Simpson wrote:
The variable my_height is an int, and for an int both these things are 
the same.


But note that 'd' and 's' can give different results when
other formatting options are present, e.g.

>>> "%05d" % 42
'00042'
>>> "%05s" % 42
'   42'

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

Re: error in os.chdir

[eryk sun]

On Sun, Jul 1, 2018 at 2:28 AM, Chris Angelico  wrote:
> On Sun, Jul 1, 2018 at 12:22 PM, eryk sun  wrote:
>>> So what if, internally, that's done by converting them to backslashes?
>>> No Python program needs to care. In fact, there are other conversions,
>>> too - the underlying file system is most likely using UTF-16 paths,
>>> but your Python program needn't use UTF-16. No, it simply uses a plain
>>> old string literal - a Unicode string. The OP need not be concerned
>>> about any of these fiddlinesses, unless in some way they actually
>>> affect Python.
>>
>> A few minor changes in in wording are both technically correct and
>> don't make the text any more difficult to understand. You're the one
>> blowing this up beyond proportion and making a mountain out of a small
>> technical-correction mole hill. Please just let it pass.
>
> If you can show me a way in which a Python program actually needs to
> care about any of these distinctions when dealing with files on
> Windows, then I'll admit that the technical correction was needed. You
> won't be shelling out to the "dir" command, for instance.

Python has no built-in support for Windows file security, so a Python
program may decided to use icacls.exe, takeown.exe, or xcopy.exe (copy
owner/ACL). It's best in general to normalize paths when integrating
an external program -- unless you've already checked that the
program(s) you're running support forward slash without a problem.
Checking this in each case isn't worth the trouble when it's so simple
to call normpath(). Doing a quick test isn't sufficient. Programs that
fail in this case do so in different ways and not always consistently.
Using forward slash may work in some cases (e.g. passing a explicit
file vs passing a wildcard pattern), which may give someone a false
perception that the program intentionally supports forward slash as a
path separator, when it's only working by accident of implementation.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: error in os.chdir

[Chris Angelico]

On Sun, Jul 1, 2018 at 12:43 PM, eryk sun  wrote:
> On Sun, Jul 1, 2018 at 2:28 AM, Chris Angelico  wrote:
>> On Sun, Jul 1, 2018 at 12:22 PM, eryk sun  wrote:
 So what if, internally, that's done by converting them to backslashes?
 No Python program needs to care. In fact, there are other conversions,
 too - the underlying file system is most likely using UTF-16 paths,
 but your Python program needn't use UTF-16. No, it simply uses a plain
 old string literal - a Unicode string. The OP need not be concerned
 about any of these fiddlinesses, unless in some way they actually
 affect Python.
>>>
>>> A few minor changes in in wording are both technically correct and
>>> don't make the text any more difficult to understand. You're the one
>>> blowing this up beyond proportion and making a mountain out of a small
>>> technical-correction mole hill. Please just let it pass.
>>
>> If you can show me a way in which a Python program actually needs to
>> care about any of these distinctions when dealing with files on
>> Windows, then I'll admit that the technical correction was needed. You
>> won't be shelling out to the "dir" command, for instance.
>
> Python has no built-in support for Windows file security, so a Python
> program may decided to use icacls.exe, takeown.exe, or xcopy.exe (copy
> owner/ACL). It's best in general to normalize paths when integrating
> an external program -- unless you've already checked that the
> program(s) you're running support forward slash without a problem.
> Checking this in each case isn't worth the trouble when it's so simple
> to call normpath(). Doing a quick test isn't sufficient. Programs that
> fail in this case do so in different ways and not always consistently.
> Using forward slash may work in some cases (e.g. passing a explicit
> file vs passing a wildcard pattern), which may give someone a false
> perception that the program intentionally supports forward slash as a
> path separator, when it's only working by accident of implementation.

Cool. Okay, so for people who don't know about pywin32, it's important
to properly wrap up arguments to some of the external programs you
might need. I'll grant you that. Internally, use forward slashes; then
when you need to shell out to something, you process the arguments
into something that will be accepted.

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

Re: error in os.chdir

[eryk sun]

On Sun, Jul 1, 2018 at 1:44 AM, Steven D'Aprano
 wrote:
> On Sat, 30 Jun 2018 23:36:40 +, eryk sun wrote:
>
>> Only use forward slashes for legacy DOS paths passed to Windows API
>> functions. Do not use forward slashes for paths in command line
>> arguments, \\?\ prefixed paths, or registry paths.
>
> I don't see why this is relevant, or at least not the "command line
> arguments" and "registry paths" parts.

Command-line arguments are relevant to executing a child process, e.g.
via subprocess.Popen.

> I guess that if the user is using a path beginning with \\?\ they may or
> may not need to use backslashes, but I have no way of testing it, and I
> would expect that Python will correctly replace //?/ with backslashes the
> same as it does for any other file system path.

The Windows API handles this, but not for a path that begins with
\\?\. The intent of this prefix is to bypass DOS-path normalization --
allowing paths with length up to 32K characters that can use otherwise
reserved DOS-device names or names ending in spaces or dots.

> (Besides, Python doesn't have an API for interacting directly with the
> registry.)

The standard library has winreg -- or _winreg in 2.x.

Bear in mind that forward slash is just a  name character in NT. If a
coder assumes that Windows automatically replaces forward slash with
backslash for registry paths, it could lead to a mistake such as the
following:

>>> hkey = winreg.CreateKey(winreg.HKEY_CURRENT_USER, 'test')
>>> subkeya = winreg.CreateKey(hkey, 'test_a1/test_a2/test_a3')
>>> subkeyb = winreg.CreateKey(hkey, 'test_b1\\test_b2\\test_b3')
>>> winreg.EnumKey(hkey, 0)
'test_a1/test_a2/test_a3'
>>> winreg.EnumKey(hkey, 1)
'test_b1'

In the test_a case, instead of a tree of keys
"test_a1\test_a2\test_a3", we get a single key named
"test_a1/test_a2/test_a3". The test_b case creates the intended tree.

I grant that having to explicitly say that forward slash isn't
supported in registry paths is certainly beyond what's required, as is
having to state that forward slash isn't supported in the native API
(e.g. NtCreateFile, NtOpenFile). We only need to clearly state that
the Windows API allows using forward slash as the path separator in
file paths that do not begin with the \\?\ prefix. I prefer to also
add a warning about command-line arguments, since it isn't an
improbable or inconsequential problem, and it's so easy to state
upfront rather than letting someone waste hours unravelling a cryptic
failure, given the path separator isn't something one is likely to
consider as the source of the problem.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: EXTERNAL: OSError: [Errno 48] Address already in use

[T Berger]

On Saturday, June 30, 2018 at 6:39:36 PM UTC-4, MRAB wrote:
> On 2018-06-30 23:01, T Berger wrote:
> > On Friday, June 29, 2018 at 7:00:15 PM UTC-4, Cameron Simpson wrote:
> > 
> >> The key point here from Jim is "simultaneously". Are you properly shutting 
> >> down 
> >> the Flask instance in IDLE before running from Terminal, and vice versa?
> > 
> > Cameron, I try every option to quit either program, but they don't work. Or 
> > I should say, they mostly don't work. Once in a while they do. The one 
> > option which works (which is not a feasible option) is rebooting my Mac 
> > (actually that might not work either. I think I got the error message again 
> > this morning when I rebooted).
> >   
> >> Otherwise both will try to use the same local port and There Can Be Only 
> >> One.
> >> 
> >> Do you need to run from both environments at the same time? I'd have 
> >> thought 
> >> not, which also leads me to: why are you flicking from IDLE to Terminal? I 
> >> would have imagined using one or the other normally, not both. It isn't 
> >> wrong 
> >> to use both, just surprising.
> > 
> > I'm working from a Python manual. I created the webapp in IDLE, and test it 
> > in Terminal, per the instructions in the manual. I use IDLE to edit my 
> > program, and then test it in terminal. When I go from one to the other, I 
> > get the error message. IDLE has a keyboard shortcut for quitting the 
> > shell—Cntl + C—but it doesn't work. Neither does restarting the shell. 
> > Neither does entering the kill command line, not in IDLE or terminal.
> 
> Ctrl+C is the shortcut for interrupting a Python program running on 
> IDLE's or Windows command line. In IDLE's editor, Ctrl+C is the shortcut 
> for copying text the clipboard.
> 
> The keyboard shortcut for quitting IDLE completely is Ctrl+Q.
> 
> > 
> > Do you have any other suggestions? I'm going to email the writer. He 
> > doesn't mention how to deal with problems that might arise from working 
> > with two programs at the same time. Maybe Cntl+C should do it, but in my 
> > case it doesn't.
> >

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

Re: error in os.chdir

[Steven D'Aprano]

On Sun, 01 Jul 2018 02:22:41 +, eryk sun wrote:

> I use the native API a lot, so for me registry and file paths are just
> paths. It's only the Windows API that separates the two and only the
> Windows API that allows forward slash as a path separator in file paths.

Not being a Windows user, I don't actually understand how this works.

I gather that there's a low-level "native API" (DOS?) used by the Windows 
OS, and a higher level "Windows API" used by, er, another part of the API.

But I'm not sure how that interacts with Python.

The way I see it, when we say "always use forward slashes for file 
paths", we're talking about Python level file commands like open(), 
os.path.exists, etc.

If you're using Python to directly call Windows external programs, say 
"os.system('dir')", then of course you have to follow the Windows rules. 
(The same applies to Unix/Linux systems too, of course.) But while you're 
using Python to manipulate files, you should use Python rules, and that 
is "always use forward slashes".

Is that reasonable?

Under what circumstances would a user calling open(pathname) in Python 
need to care about backslashes?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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