Re: define variables in the txt file using python

[dieter]

Xristos Xristoou  writes:
> i have one .txt file and i want to create python script with sys.argv or 
> argparse or other package to define some variables in the txt file and i take 
> some result.
>
> txt file maybe like this :
>
> input number 1= %var1%
> input number 2= %var2%
> result = %vresult(var1-var2)%
>
> how can i write a python script to update dynamic variables in the txt file ?
> i dont want with replace i thing so arguments is the better.

You read the file in; you look for things in the resulting string
with features you find in the "re" (= "Regular Expression") module
and maybe replace them; you write the result out.

Things like "%vresult(var1-var2)%" may be a bit more difficult.
You might need to use a parser library to get the expressions parsed
and then evaluate it with your own Python code. Python by itself
does not include a general parser library (only one for Python source code),
but there are a few available for Pytin in third party packages.

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

Re: SyntaxError: multiple statements found while compiling a single statement

[Cai Gengyang]

Unfortunately, in this case, it is 100% of the information I am giving you. You 
can try it yourself. The code is in the first section (8.1) of 

http://programarcadegames.com/index.php?chapter=introduction_to_animation&lang=en#section_8

Just copy and paste it into your Python IDLE and let me know what you get ...


On Saturday, October 8, 2016 at 2:19:26 PM UTC+8, Steve D'Aprano wrote:
> On Sat, 8 Oct 2016 05:02 pm, Cai Gengyang wrote:
> 
> > Any idea how to correct this error ? Looks fine to me 
> 
> As usual, the first and most important rule of debugging is to use ALL the
> information the compiler gives you. Where is the rest of the traceback? At
> the very least, even if nothing else, the compiler will print its best
> guess at the failed line with a caret ^ pointing at the place it realised
> there was an error.
> 
> Asking us to debug your problem without giving us ALL the information is
> like that old joke:
> 
> 
>   A man makes an appointment at the doctor because he isn't feeling
>   well. He goes in to see the doctor, who says "So, Mr Smith, what 
>   seems to be the problem?"
> 
>   The man says "You're the medical expert, you tell me."
> 
> 
> I do not think it is possible to get the error message you claim from
> running the code you show. I think there is more code that you haven't
> shown us, and that the error is there.
> 
> The only way I can reproduce the error message you give is by using the
> compile() function:
> 
> py> compile("a=1\nb=2", "", "single")
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 1
> a=1
>   ^
> SyntaxError: multiple statements found while compiling a single statement
> 
> 
> Notice how the compiler shows the offending line and puts a caret ^ at the
> end?
> 
> Unless you show us what code actually causes this error message, I don't
> think it is possible to help you. We're not mind-readers.
> 
> 
> 
> 
> 
> -- 
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.

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

Re: SyntaxError: multiple statements found while compiling a single statement

[Steve D'Aprano]

On Sat, 8 Oct 2016 05:02 pm, Cai Gengyang wrote:

> Any idea how to correct this error ? Looks fine to me 

As usual, the first and most important rule of debugging is to use ALL the
information the compiler gives you. Where is the rest of the traceback? At
the very least, even if nothing else, the compiler will print its best
guess at the failed line with a caret ^ pointing at the place it realised
there was an error.

Asking us to debug your problem without giving us ALL the information is
like that old joke:


  A man makes an appointment at the doctor because he isn't feeling
  well. He goes in to see the doctor, who says "So, Mr Smith, what 
  seems to be the problem?"

  The man says "You're the medical expert, you tell me."


I do not think it is possible to get the error message you claim from
running the code you show. I think there is more code that you haven't
shown us, and that the error is there.

The only way I can reproduce the error message you give is by using the
compile() function:

py> compile("a=1\nb=2", "", "single")
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
a=1
  ^
SyntaxError: multiple statements found while compiling a single statement


Notice how the compiler shows the offending line and puts a caret ^ at the
end?

Unless you show us what code actually causes this error message, I don't
think it is possible to help you. We're not mind-readers.





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

SyntaxError: multiple statements found while compiling a single statement

[Cai Gengyang]

Any idea how to correct this error ? Looks fine to me 

>>> rect_x = 50
 
#  Main Program Loop ---
while not done:
for event in pygame.event.get(): # User did something
if event.type == pygame.QUIT: # If user clicked close
done = True # Flag that we are done so we exit this loop

SyntaxError: multiple statements found while compiling a single statement

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

Re: Doubled backslashes in Windows paths [Resolved]

[BartC]

On 07/10/2016 18:41, Oz-in-DFW wrote:

On 10/7/2016 12:30 AM, Oz-in-DFW wrote:

I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
v.1900 32 bit (Intel)] on Windows 7

I'm trying to write some file processing that looks at file size,
extensions, and several other things and I'm having trouble getting a
reliably usable path to files.

Thanks to all who have replied.  It looks like I have this part fixed.

I had it fixed sooner than I realized because of cranial-anal-retention
- the os.path.getsize() call was not using the variable into which I was
placing the corrected path.  D'oh!

The root problem was that the path did not have a trailing slash when
concatenated with the filename.  This was handled properly by an
os.path.join() call as recommended by Dennis Lee Bieber.


But the error message in your OP showed what looked like a correctly 
formed path (apart from the quotes). Without a / or \ between dirpath 
and filename, the error message would have been different (probably 
about not being able to find the file).



So what now works is

path = os.path.join(dirpath,name)
if os.path.getsize(path)>1:
print("Path: ",path," Size: ",os.path.getsize(path))

Raw strings didn't apply because the content of /dirpath /and /name /are
the result of an os.walk() call.


When I was creating such path-handling routines, anything returning the 
name of a path /always/ ended with \ or / for that reason: so that you 
could just stick a file at the end without needing to check whether the 
path had the right ending or not.


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

Re: Question on multiple Python users in one application

[Gregory Ewing]

Dennis Lee Bieber wrote:

normally the main file of a Python program is still the plain text,


It doesn't have to be, though -- you can do 'python somefile.pyc'
and it will happily run it.


and imported
modules are retrieved from the file system as (if found) PYC pre-compiled,
otherwise the text PY file is loaded. They don't exist as a part of a
monolithic executable program.


I don't think that would be a problem for Loren, but if it is,
the .pyc files can be wrapped up in a zip file, and Python
can import them directly from there.

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

Re: Question on multiple Python users in one application

[Gregory Ewing]

Dennis Lee Bieber wrote:

What is it... A Burroughs mainframe running a version of FORTH?


The Burroughs architecture is a stack architecture, so
the machine code looks like a version of Forth in some ways.

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

define variables in the txt file using python

[Xristos Xristoou]

hello


i have one .txt file and i want to create python script with sys.argv or 
argparse or other package to define some variables in the txt file and i take 
some result.



txt file maybe like this :

input number 1= %var1%
input number 2= %var2%
result = %vresult(var1-var2)%

how can i write a python script to update dynamic variables in the txt file ?
i dont want with replace i thing so arguments is the better.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Doubled backslashes in Windows paths [Resolved]

[Oz-in-DFW]

On 10/7/2016 12:30 AM, Oz-in-DFW wrote:
> I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
> v.1900 32 bit (Intel)] on Windows 7
>
> I'm trying to write some file processing that looks at file size,
> extensions, and several other things and I'm having trouble getting a
> reliably usable path to files.
Thanks to all who have replied.  It looks like I have this part fixed.

I had it fixed sooner than I realized because of cranial-anal-retention
- the os.path.getsize() call was not using the variable into which I was
placing the corrected path.  D'oh!

The root problem was that the path did not have a trailing slash when
concatenated with the filename.  This was handled properly by an
os.path.join() call as recommended by Dennis Lee Bieber.

So what now works is

path = os.path.join(dirpath,name)
if os.path.getsize(path)>1:
print("Path: ",path," Size: ",os.path.getsize(path))

Raw strings didn't apply because the content of /dirpath /and /name /are
the result of an os.walk() call.

As Dennis Lee Bieber also observed, the call to

   path = os.path.normpath(path)

wasn't needed. It does no harm as it changes the slash directions to
keep the Windows command line happy, but the Python functions are just
as happy without the changes.

Thanks to all who replied.

-- 
mailto:o...@ozindfw.net
Oz
POB 93167 
Southlake, TX 76092 (Near DFW Airport) 



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

Re: xml parsing with lxml

[Doug OLeary]

On Friday, October 7, 2016 at 3:21:43 PM UTC-5, John Gordon wrote:
> root = doc.getroot()
> for child in root:
> print(child.tag)
> 

Excellent!  thank, you sir!  that'll get me started.  

Appreciate the reply.

Doug O'Leary
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xml parsing with lxml

[John Gordon]

In <622ea3b0-88b4-420b-89e0-9e7c6e866...@googlegroups.com> Doug OLeary 
 writes:

> >>> from lxml import etree
> >>> doc =3D etree.parse('config.xml')

> Now what?  For instance, how do I list the top level children of
> ?

root = doc.getroot()
for child in root:
print(child.tag)

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: BeautifulSoup help !!

[Navneet Siddhant]

i was able to almost get the results i require but only half of the info is 
showing up. i.e suppose there are 20 coupons showing on the page but when i 
print them using the container they are in only 5 are printed on the screen.

Also figured out how to write to csv file , but even here only 1 row is being 
written , how do I iterate through all the info which is printed on the screen 
and export them to a csv ? im using 
writerows([object which contains the data])
on the screen only 5 rows are printed and in the csv only 1 row is exported.
-- 
https://mail.python.org/mailman/listinfo/python-list

xml parsing with lxml

[Doug OLeary]

Hey;

I'm trying to gather information from a number of weblogic configuration xml 
files using lxml.  I've found any number of tutorials on the web but they all 
seem to assume a knowledge that I apparently don't have... that, or I'm just 
being rock stupid today - that's distinct possibility too.

The xml looks like:



  Domain1
  10.3.5.0
  
[[snipp]]

[[realm children snipped]

myrealm
  
  [[snip]]

[[snip]]

   [[snip]]


  [[snip]]
   [[snip]]
  byTime
  14
  02:00
  Info

[[snip]]
40024
true
snip]]

  [[children snipped]]

${hostname}
${hostname}
40022
javac

   [[children snipped]

   [[rest snipped]
  


The tutorials all start out well enough with:

$ python 
Python 3.5.2 (default, Aug 22 2016, 09:04:07) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from lxml import etree
>>> doc = etree.parse('config.xml')

Now what?  For instance, how do I list the top level children of 
.*??  In that partial list, it'd be name, domain-version, 
security-configuration, log, and server.  

For some reason, I'm not able to make the conceptual leap to get to the first 
step of those tutorials.

The end goal of this exercise is to programatically identify weblogic clusters 
and their hosts.  

thanks

Doug O'Leary
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Passing Variable to Function

[John McKenzie]

 Brendan and Alister, thank you both for responding.

 I am very inexperienced with python, but not new to computers so on my 
own I realized the strings vs number mistake. (I seem to work with and 
learn about Python for a few weeks at a time with 6 to 12 months in 
between. Need to change that and focus on it for awhile.) After my first 
error I removed the quotation marks from my variables knowing that 
strings vs numbers was involved. I copied and pasted from my original 
script when I showed it to you. Opps. Anyway, I had no idea how to expand 
tuples nor that it was not done automatically.

 Thank you you both for sharing that info. After making variables numbers 
by removing the quotes and putting an asterisk in front of my colour1, 
colour2, etc variables whenever I passed them to a function in order to 
expand them, the error messages disappeared. It appears to work just fine 
now.

 Thanks.

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

Re: default argument value is mutable

[Marko Rauhamaa]

"D'Arcy J.M. Cain" :

> On Fri, 07 Oct 2016 16:09:19 +0200
> jmp  wrote:
>> What about
>> 
>> def test():
>>if not hasattr(test, '_store'): test._store={'x':0}
>>test._store['x'] += 1
>
> Why is everyone working so hard to avoid creating a class?

Hear, hear!


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

Re: bugreport os.path.dirname and os.path.basename

[Chris Angelico]

On Sat, Oct 8, 2016 at 4:34 AM, h2m2  wrote:
> os.path.dirname('G:\Programmierung\Python\Portugal
> Training\Python-for-Algorithms--Data-Structures--and--Life\Algorithm
> Analysis and Big O\testFile.ipynb')
>
> result and bug is:
> 'G:\\Programmierung\\Python\\Portugal
> Training\\Python-for-Algorithms--Data-Structures--and--Life'
>
> if I am not mistaken: correct result  would be
> 'G:\\Programmierung\\Python\\Portugal
> Training\\Python-for-Algorithms--Data-Structures--and--Life\\Algorithm
> Analysis and Big O'

Not a bug. You have something that you perhaps don't understand:
backslash escapes. When you have "Big O\testfile", that string does
*not* have a backslash in it.

Use raw string literals, forward slashes, or doubled backslashes, to avoid this.

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

bugreport os.path.dirname and os.path.basename

[h2m2]

in the meantime, I am subscribed and confirmed - the bug below as
requested

- Original message -
From: h2m2 
To: python-list@python.org
Subject: bugreport   os.path.dirname and os.path.basename
Date: Wed, 05 Oct 2016 16:49:17 +0200

bug: 

os.path.dirname('G:\Programmierung\Python\Portugal
Training\Python-for-Algorithms--Data-Structures--and--Life\Algorithm
Analysis and Big O\testFile.ipynb')

result and bug is: 
'G:\\Programmierung\\Python\\Portugal
Training\\Python-for-Algorithms--Data-Structures--and--Life'

if I am not mistaken: correct result  would be
'G:\\Programmierung\\Python\\Portugal
Training\\Python-for-Algorithms--Data-Structures--and--Life\\Algorithm
Analysis and Big O'


analog with basename
'Algorithm Analysis and Big O\testFile.ipynb'

again, I was expecting 'testFile.ipynb' only


With less complex constructs , the function works well. 
Only that is doubtfull when the names start getting more kind of theses
days 


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

Re: segfault using shutil.make_archive

[Michael Torrie]

On 10/06/2016 10:46 AM, Tim wrote:
> I need to zip up a directory that's about 400mb.
> I'm using shutil.make_archive and I'm getting this response:
> 
> Segmentation fault: 11 (core dumped)
> 
> The code is straightforward (and works on other, smaller dirs):
> 
> shutil.make_archive(os.path.join(zip_dir, zname), 'zip', tgt_dir)
> 
> I guess I could drop the convenience of make_archive and use zipfile but that 
> seems to be exactly what make_archive does.
> 
> I'm on FreeBSD, python2.7.
> 
> Anyone seen this before?

Does normal the normal zip utility crash also when trying to zip up this
large directory?  I'm not familiar with how shutils.make_archive works,
but since it's part of shutils, I suspect it's calling the zip command
as a subprocess, rather than using the Python zip module.  Given the
size of your directory I doubt the zip module would work anyway.

If the zip command works, you could just execute it using popen from
within Python.

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

Re: BeautifulSoup help !!

[Pierre-Alain Dorange]

Navneet Siddhant  wrote:

> I guess I will have to extract data from multiple divs as only extracting
> data from the parent div which has other divs in it with the different
> data is coming up all messed up. Will play around and see if I could get
> through it. Let me clarify once again I dont need complete code , a
> resource where I could find more info about using Beautifulsoup will be
> appreciated.  Also do I need some kind of plugin etc to extract data to
> csv ? or it is built in python and I could simply import csv and write
> other commands needed ??

BeautifulSoup was a good tool to do the task.
But it would require a bit more code to accomplish this.
I don't have enough time to look at the (coupon) data but i work on
similar task and often data are clustered throught many dov and html
tag. You need to understand (reverse ingeneering) the data structure and
extract piece of data (Beautifulsoup and lot of tools for that) then
aggregate the data in an internal structure (you design this according
to your needs : a class), the you sipmply export this aggregated data to
CSV using the csv module.
The main task is to extract data with BeautifulSoup.
BS provide tool to extract from div, or any html tag, just play with it
a little, and read docs.

Don't know if it could help but here a sample code i used sometime as an
example and also in real life to extract data (river level in real time)
from a french web site (vigiecrue) : retrieve the page, extract data,
extract last river level and mean the 24h last levels.


 
Note : it was probably not beautiful python code, but it works for the
purpose it was written.

-- 
Pierre-Alain Dorange   Moof 

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

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

Re: Doubled backslashes in Windows paths

[BartC]

On 07/10/2016 13:39, BartC wrote:

On 07/10/2016 06:30, Oz-in-DFW wrote:



I'm getting an error message on an os.path.getsize call;



But the main error appears to be due to the presence of quotes, whether
at each end, or inside the path, enclosing an element with spaces for
example. Try using len(path)>1 instead; it might be near enough (the
1 sounds arbitrary anyway).


Forget that. Apparently .getsize returns the size of the file not the 
length of the path! (That os.path. bit misled me.)


In that case just leave out the quotes. I don't think you need them even 
if the file-path contains embedded spaces. That would be an issue on a 
command-line (as spaces separate parameters), not inside a string.


But if quotes are present in user-input that represents a file-name, 
then they might need to be removed.


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

Re: segfault using shutil.make_archive

[Tim]

On Friday, October 7, 2016 at 5:18:11 AM UTC-4, Chris Angelico wrote:
> On Fri, Oct 7, 2016 at 5:24 PM, dieter wrote:
> > Memory allocations are frequent (in many places) and they fail rarely.
> > Therefore, there is quite a high probability that some of those
> > allocations fail to check that the allocation has been successful.
> > If this happens (and the allocation fails), then a "SIGSEGV" is
> > almost certain.
> 
> Which, BTW, doesn't stop them from being bugs. If this can be pinned
> down, it definitely warrants a bugs.python.org issue.
> 
> ChrisA

Thanks. I can make a test case. It doesn't look like it has been reported 
before; I'll add an issue once I can reproduce.

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

Re: default argument value is mutable

[ast]

"jmp"  a écrit dans le message de 
news:mailman.213.1475849391.30834.python-l...@python.org...

On 10/07/2016 03:45 PM, ast wrote:


"jmp"  a écrit dans le message de
news:mailman.210.1475844513.30834.python-l...@python.org...

On 10/07/2016 02:07 PM, ast wrote:


"jmp"  a écrit dans le message de
news:mailman.209.1475841371.30834.python-l...@python.org...

On 10/07/2016 01:38 PM, Daiyue Weng wrote:




So the rule of thumb for default argument value is "No mutable"

Cheers,



It can be used to store some variables from one call of
a function to an other one.

def test( _store={'x':0}):

x = _store['x']
. do some stuff
   _store['x'] = x


For personal dirty scripts, possibly, for all other situations, never.


not so dirty in my opinion


You made a point, it's not that dirty, it's an "advanced technique" that is often actually an 
error when you don't know what you're doing. See the OP's code.


I'm in an environment where people use python as a tool more than an effective powerful language 
to write complex applications. That's probably why I'm bias on this issue and prefer the cautious 
approach.



Especially since there's nothing in the code above that cannot be
solved using standard idioms .


Yes, putting _store dictionnary outside

_store={'x':0}

def test( ):

x = _store['x']
. do some stuff
_store['x'] = x


or using a global variable, but you pollute in both case
the global scope unnecessary.


What about

def test():
  if not hasattr(test, '_store'): test._store={'x':0}
  test._store['x'] += 1

Neither you pollute the global namespace, nor you pollute the function signature with 
implementation specifics.


jm



OK

There is this solution too we often see:


def test(x):
 x = some stuff
 return(x)

x=0
x = test(x)


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

Re: default argument value is mutable

[D'Arcy J.M. Cain]

On Fri, 07 Oct 2016 16:09:19 +0200
jmp  wrote:
> What about
> 
> def test():
>if not hasattr(test, '_store'): test._store={'x':0}
>test._store['x'] += 1

Why is everyone working so hard to avoid creating a class?

-- 
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: default argument value is mutable

[jmp]

On 10/07/2016 03:45 PM, ast wrote:


"jmp"  a écrit dans le message de
news:mailman.210.1475844513.30834.python-l...@python.org...

On 10/07/2016 02:07 PM, ast wrote:


"jmp"  a écrit dans le message de
news:mailman.209.1475841371.30834.python-l...@python.org...

On 10/07/2016 01:38 PM, Daiyue Weng wrote:




So the rule of thumb for default argument value is "No mutable"

Cheers,



It can be used to store some variables from one call of
a function to an other one.

def test( _store={'x':0}):

x = _store['x']
. do some stuff
   _store['x'] = x


For personal dirty scripts, possibly, for all other situations, never.


not so dirty in my opinion


You made a point, it's not that dirty, it's an "advanced technique" that 
is often actually an error when you don't know what you're doing. See 
the OP's code.


I'm in an environment where people use python as a tool more than an 
effective powerful language to write complex applications. That's 
probably why I'm bias on this issue and prefer the cautious approach.



Especially since there's nothing in the code above that cannot be
solved using standard idioms .


Yes, putting _store dictionnary outside

_store={'x':0}

def test( ):

x = _store['x']
. do some stuff
_store['x'] = x


or using a global variable, but you pollute in both case
the global scope unnecessary.


What about

def test():
  if not hasattr(test, '_store'): test._store={'x':0}
  test._store['x'] += 1

Neither you pollute the global namespace, nor you pollute the function 
signature with implementation specifics.


jm

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

Re: Doubled backslashes in Windows paths

[eryk sun]

On Fri, Oct 7, 2016 at 10:46 AM, Steve D'Aprano
 wrote:
> That's because
>
> "C:
>
> is an illegal volume label (disk name? I'm not really a Windows user, and
> I'm not quite sure what the correct terminology here would be).

It's not an illegal device name, per se. A DOS device can be defined
with the name '"C:'. For example:

>>> kernel32.DefineDosDeviceW(0, '"C:', 'C:')
1
>>> os.path.getsize(r'\\.\"C:\Windows\py.exe')
889504

However, without the DOS device prefix (either \\.\ or \\?\), Windows
has to normalize the path as a classic DOS path before passing it to
the kernel. Let's see how Windows 10 normalizes this path by setting a
breakpoint on the NtCreateFile system call:

>>> os.path.getsize(r'"C:\Windows\py.exe"')
Breakpoint 0 hit
ntdll!NtCreateFile:
7ffb`a6c858e0 4c8bd1  mov r10,rcx

A kernel path is stored in an OBJECT_ATTRIBUTES structure, which has
the path, a handle (for opening relative to another object), and flags
such as whether or not the path is case insensitive. The debugger's
!obja extension command shows the contents of this structure:

0:000> !obja @r8
Obja +00a6c8bef038 at 00a6c8bef038:
Name is "C:\Windows\py.exe"
OBJ_CASE_INSENSITIVE

We see that the user-mode path normalization code doesn't know what to
make of a path starting with '"', so it just punts the path to the
kernel object manager. In turn the object manager rejects this path
because it's not rooted in the object namespace (i.e. it's not of the
form "\??\..." or "\Device\...", etc):

0:000> pt; r rax
rax=c033

The kernel status code 0xC033 is STATUS_OBJECT_NAME_INVALID.

Note that a path ending in '"' is still illegal even if we explicitly
use the r'\\.\"C:' DOS device. For example:

>>> os.path.getsize(r'\\.\"C:\Windows\py.exe"')
Breakpoint 0 hit
ntdll!NtCreateFile:
7ffb`a6c858e0 4c8bd1  mov r10,rcx

0:000> !obja @r8
Obja +00a6c8bef038 at 00a6c8bef038:
Name is \??\"C:\Windows\py.exe"
OBJ_CASE_INSENSITIVE

0:000> pt; r rax
rax=c033

In this case it fails because the final '"' in the name (after .exe)
is reserved by the I/O manager, along with '<' and '>', respectively
as DOS_DOT, DOS_STAR, and DOS_QM. These characters aren't allowed in
filesystem names. They get used to implement the semantics of DOS
wildcards in NT system calls (the regular '*' and '?' wildcards are
also reserved). See FsRtlIsNameInExpression [1], which, for example, a
filesystem may use in its implementation of the NtQueryDirectoryFile
[2] system call to handle the optional FileName parameter with
wildcard matching.

[1]: https://msdn.microsoft.com/en-us/library/ff546850
[2]: https://msdn.microsoft.com/en-us/library/ff567047
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Doubled backslashes in Windows paths

[Ned Batchelder]

On Friday, October 7, 2016 at 8:39:55 AM UTC-4, BartC wrote:
> On 07/10/2016 06:30, Oz-in-DFW wrote:
> > I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
> > v.1900 32 bit (Intel)] on Windows 7
> >
> > I'm trying to write some file processing that looks at file size,
> > extensions, and several other things and I'm having trouble getting a
> > reliably usable path to files.
> >
> > The problem *seems* to be doubled backslashes in the path, but I've read
> > elsewhere that this is just an artifact of the way the interpreter
> > displays the strings.
> >
> > I'm getting an error message on an os.path.getsize call;
> >
> > Path: -
> > "C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg" -
> > Traceback (most recent call last):
> >   File "C:\Users\Rich\workspace\PyTest\test.py", line 19, in 
> > if os.path.getsize(path)>1:
> >   File "C:\Python32\lib\genericpath.py", line 49, in getsize
> > return os.stat(filename).st_size
> > WindowsError: [Error 123] The filename, directory name, or volume
> > label syntax is incorrect:
> > 
> > '"C:\\Users\\Rich\\Desktop\\2B_Proc\\2307e60da6451986dd8d23635b845386.jpg"'
> 
> I tried to recreate this error and it seems the getsize function doesn't 
> like quotes in the path.
> 
> Whether \ is correctly written as \\ in a string literal, or a raw 
> string is used with the r prefix and a single \, or a \ has been put 
> into path by any other means, then these will still be displayed as \\ 
> in the error message, which is strange. The error handler is expanding \ 
> characters to \\.

For error messages destined for developers, it is good practice to use
%r or {!r} to get the repr() of a string.  This will show quotes around
the string, and use backslash escapes to present the contents
unambiguously.  That's what's expanding \ to \\, and adding the single
quotes you see in the message.

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

Re: default argument value is mutable

[ast]

"jmp"  a écrit dans le message de 
news:mailman.210.1475844513.30834.python-l...@python.org...

On 10/07/2016 02:07 PM, ast wrote:


"jmp"  a écrit dans le message de
news:mailman.209.1475841371.30834.python-l...@python.org...

On 10/07/2016 01:38 PM, Daiyue Weng wrote:




So the rule of thumb for default argument value is "No mutable"

Cheers,



It can be used to store some variables from one call of
a function to an other one.

def test( _store={'x':0}):

x = _store['x']
. do some stuff
   _store['x'] = x


For personal dirty scripts, possibly, for all other situations, never.


not so dirty in my opinion


Especially since there's nothing in the code above that cannot be solved using 
standard idioms .


Yes, putting _store dictionnary outside

_store={'x':0}

def test( ):

   x = _store['x']
   . do some stuff
   _store['x'] = x


or using a global variable, but you pollute in both case
the global scope unnecessary.



That is if you care about anyone reading your code ;)

jm








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

Re: default argument value is mutable

[Steve D'Aprano]

On Fri, 7 Oct 2016 11:48 pm, jmp wrote:

> On 10/07/2016 02:07 PM, ast wrote:

>> It can be used to store some variables from one call of
>> a function to an other one.
>>
>> def test( _store={'x':0}):
>>
>> x = _store['x']
>> . do some stuff
>>_store['x'] = x
> 
> For personal dirty scripts, possibly, for all other situations, never.
> Especially since there's nothing in the code above that cannot be solved
> using standard idioms .


Using a default list as static storage *is* a standard idiom.



> That is if you care about anyone reading your code ;)

Here's another example of a mutable default argument:

https://www.python.org/doc/essays/graphs/

Although it isn't actually being mutated. Nevertheless, if it is good enough
for Guido, then it should be good enough for anyone.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: default argument value is mutable

[Steve D'Aprano]

On Fri, 7 Oct 2016 10:38 pm, Daiyue Weng wrote:

> Hi, I declare two parameters for a function with default values [],
> 
> def one_function(arg, arg1=[], arg2=[]):
> 
> PyCharm warns me:
> 
> Default argument value is mutable,
> 
> what does it mean? and how to fix it?


The usual way to avoid that is:


def one_function(arg, arg1=None, arg2=None):
if arg1 is None:
arg1 = []  # gets a new list each call
if arg2 is None:
arg2 = []  # gets a new list each call



Otherwise, arg1 and arg2 will get the same list each time, not a fresh empty
list. Here is a simple example:

def example(arg=[]):
print(id(arg), arg)
arg.append(1)


py> def example(arg=[]):
... print(id(arg), arg)
... arg.append(1)
...
py> x = []
py> example(x)
3081877196 []


But with the default argument, you get the same list each time:

py> example()
3081877100 []
py> example()
3081877100 [1]
py> example()
3081877100 [1, 1]
py> example()
3081877100 [1, 1, 1]


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Doubled backslashes in Windows paths

[eryk sun]

On Fri, Oct 7, 2016 at 9:27 AM, Peter Otten <__pete...@web.de> wrote:
> To fix the problem either use forward slashes (which are understood by
> Windows, too)

Using forward slash in place of backslash is generally fine, but you
need to be aware of common exceptions, such as the following:

(1) Paths with forward slashes aren't generally accepted in command lines.

(2) Forward slash is just another name character in the kernel object
namespace. Thus "Global/Spam" is a local name with a slash in it,
while r"Global\Spam" is a "Spam" object created in the global
r"\BaseNamedObjects" directory because "Global" is a local object
symbolic link to the global r"\BaseNamedObjects".

(3) Extended paths (i.e. paths prefixed by \\?\) bypass the user-mode
path normalization that replaces slash with backslash. Such paths
cannot use forward slashes to delimit filesystem path components.
Given (2), forward slash potentially could be parsed as part of a
filename. Fortunately, slash is a reserved character in all Microsoft
filesystems. Thus "dir1/dir2" is an invalid 9-character name.

You may ask why Windows doesn't hard-code replacing slash with
backslash, even for extended paths. Some filesystems may allow slash
in names, or for some other purpose (no that I know of any). Also,
device names may contain slashes, just like any other Windows object
name. For example, let's define a DOS pseudo-device (really an object
symbolic link) named "Eggs/Spam" to reference Python's installation
directory:

import os, sys, ctypes
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

device_name = 'Eggs/Spam'
target_path = os.path.dirname(sys.executable)
kernel32.DefineDosDeviceW(0, device_name, target_path)

>>> os.listdir(r'\\?\Eggs/Spam\Doc')
['python352.chm']

Note that the final component, "Doc", must be delimited by a
backslash. If it instead used slash, Windows would look for a device
named "Eggs/Spam/Doc". For example:

>>> os.listdir(r'\\?\Eggs/Spam/Doc')
Traceback (most recent call last):
  File "", line 1, in 
FileNotFoundError: [WinError 3] The system cannot find the
path specified: '?\\Eggs/Spam/Doc'

For the case of r"\\?\Eggs/Spam\Doc/python352.chm", parsing the path
succeeds up to the last component, "Doc/python352.chm", which is an
invalid name:

>>> os.stat(r'\\?\Eggs/Spam\Doc/python352.chm')
Traceback (most recent call last):
  File "", line 1, in 
OSError: [WinError 123] The filename, directory name, or volume
label syntax is incorrect: '?\\Eggs/Spam\\Doc/python352.chm'

Windows reparses the object symbolic link "Eggs/Spam" to its target
path. In my case that's r"\??\C:\Program Files\Python35". The "C:"
drive in my case is an object symbolic link to
r"\Device\HarddiskVolume2" (typical for Windows 10), so the path gets
reparsed as r"\Device\HarddiskVolume2\Program
Files\Python35\Doc/python352.chm". The volume device "HarddiskVolume2"
contains an NTFS filesystem, so the NTFS driver parses the remaining
path, r"\Program Files\Python35\Doc/python352.chm", and rejects
"Doc/python352.chm" as an invalid name.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: default argument value is mutable

[jmp]

On 10/07/2016 02:07 PM, ast wrote:


"jmp"  a écrit dans le message de
news:mailman.209.1475841371.30834.python-l...@python.org...

On 10/07/2016 01:38 PM, Daiyue Weng wrote:




So the rule of thumb for default argument value is "No mutable"

Cheers,



It can be used to store some variables from one call of
a function to an other one.

def test( _store={'x':0}):

x = _store['x']
. do some stuff
   _store['x'] = x


For personal dirty scripts, possibly, for all other situations, never. 
Especially since there's nothing in the code above that cannot be solved 
using standard idioms .


That is if you care about anyone reading your code ;)

jm






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

Re: Doubled backslashes in Windows paths

[BartC]

On 07/10/2016 06:30, Oz-in-DFW wrote:

I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
v.1900 32 bit (Intel)] on Windows 7

I'm trying to write some file processing that looks at file size,
extensions, and several other things and I'm having trouble getting a
reliably usable path to files.

The problem *seems* to be doubled backslashes in the path, but I've read
elsewhere that this is just an artifact of the way the interpreter
displays the strings.

I'm getting an error message on an os.path.getsize call;

Path: -
"C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg" -
Traceback (most recent call last):
  File "C:\Users\Rich\workspace\PyTest\test.py", line 19, in 
if os.path.getsize(path)>1:
  File "C:\Python32\lib\genericpath.py", line 49, in getsize
return os.stat(filename).st_size
WindowsError: [Error 123] The filename, directory name, or volume
label syntax is incorrect:
'"C:\\Users\\Rich\\Desktop\\2B_Proc\\2307e60da6451986dd8d23635b845386.jpg"'


I tried to recreate this error and it seems the getsize function doesn't 
like quotes in the path.


Whether \ is correctly written as \\ in a string literal, or a raw 
string is used with the r prefix and a single \, or a \ has been put 
into path by any other means, then these will still be displayed as \\ 
in the error message, which is strange. The error handler is expanding \ 
characters to \\.


But the main error appears to be due to the presence of quotes, whether 
at each end, or inside the path, enclosing an element with spaces for 
example. Try using len(path)>1 instead; it might be near enough (the 
1 sounds arbitrary anyway).


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

Re: default argument value is mutable

[ast]

"jmp"  a écrit dans le message de 
news:mailman.209.1475841371.30834.python-l...@python.org...

On 10/07/2016 01:38 PM, Daiyue Weng wrote:




So the rule of thumb for default argument value is "No mutable"

Cheers,



It can be used to store some variables from one call of
a function to an other one.

def test( _store={'x':0}):

   x = _store['x']
   . do some stuff
  _store['x'] = x






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

Re: default argument value is mutable

[ast]

"Daiyue Weng"  a écrit dans le message de 
news:mailman.208.1475840291.30834.python-l...@python.org...

Hi, I declare two parameters for a function with default values [],

def one_function(arg, arg1=[], arg2=[]):

PyCharm warns me:

Default argument value is mutable,

what does it mean? and how to fix it?

cheers


You could ignore this warning if you know what you
are doing, imho.
The default value being mutable it is possible to change
it inside the function. eg:

def test(x=[0]):
... print(x)
... x[0] += 1


test()

[0]


test()

[1]




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

Re: default argument value is mutable

[jmp]

On 10/07/2016 01:38 PM, Daiyue Weng wrote:

Hi, I declare two parameters for a function with default values [],

def one_function(arg, arg1=[], arg2=[]):

PyCharm warns me:

Default argument value is mutable,

what does it mean? and how to fix it?

cheers



You'll run into this bug

def foo(a=[]):
a.append('item')
print a

foo()
foo()

['item']
['item', 'item'] #what ?? 2 'item' ??

default argument are evaluated when defining the function, meaning the 
list you bound to the default argument is shared by all the function calls.


Easily fixed:

def foo(a=None):
  a = [] if a is None else a
  print a

foo()
foo()

['item']
['item']

So the rule of thumb for default argument value is "No mutable"

Cheers,

Jm

note : python 2.7 code

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

default argument value is mutable

[Daiyue Weng]

Hi, I declare two parameters for a function with default values [],

def one_function(arg, arg1=[], arg2=[]):

PyCharm warns me:

Default argument value is mutable,

what does it mean? and how to fix it?

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

Re: Doubled backslashes in Windows paths

[Steve D'Aprano]

On Fri, 7 Oct 2016 04:30 pm, Oz-in-DFW wrote:

> I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
> v.1900 32 bit (Intel)] on Windows 7
> 
> I'm trying to write some file processing that looks at file size,
> extensions, and several other things and I'm having trouble getting a
> reliably usable path to files.
> 
> The problem *seems* to be doubled backslashes in the path, but I've read
> elsewhere that this is just an artifact of the way the interpreter
> displays the strings.

Indeed.

Why don't you show us the actual path you use? You show us this snippet:

> path = '"'+dirpath+name+'"'
> path = os.path.normpath(path)
> print("Path: -",path,"-")
> if os.path.getsize(path)>1:
> print("Path: ",path," Size:
> ",os.path.getsize(dirpath+name))


but apparently dirpath and name are secrets, because you don't show us what
they are *wink*

However, using my awesome powers of observation *grin* I see that your
filename (whatever it is) begins and ends with quotation marks. So instead
of having a file name like:

C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg


you actually have a file name like:

"C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg"


In this example, the quotation marks " at the beginning and end are *NOT*
the string delimiters, they are the first and last characters in the
string. Which might explain why Windows complains about the label:

> WindowsError: [Error 123] The filename, directory name, or volume
> label syntax is incorrect:


That's because

"C:

is an illegal volume label (disk name? I'm not really a Windows user, and
I'm not quite sure what the correct terminology here would be).


So I suggest you change your code from this:

> path = '"'+dirpath+name+'"'
> path = os.path.normpath(path)

to this instead:

path = dirpath + name
path = os.path.normpath(path)


> So the file is there and the path is correct. I'm adding quotes to the
> path to deal with directories and filenames that have spaces in them.

The os.path and os functions do not need you to escape the file name with
quotes to handle spaces.

It is very likely that if you call out to another Windows program using the
os.system() call you will need to worry about escaping the spaces, but
otherwise, you don't need them.

> If I drop the quotes, everything works as I expect 

Indeed.

> *until* I encounter the first file/path with spaces.

And what happens then? My guess is that you get a different error, probably
in a different place.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Doubled backslashes in Windows paths

[Peter Otten]

Oz-in-DFW wrote:

> I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
> v.1900 32 bit (Intel)] on Windows 7
> 
> I'm trying to write some file processing that looks at file size,
> extensions, and several other things and I'm having trouble getting a
> reliably usable path to files.
> 
> The problem *seems* to be doubled backslashes in the path, but I've read
> elsewhere that this is just an artifact of the way the interpreter
> displays the strings.
> 
> I'm getting an error message on an os.path.getsize call;
> 
> Path: -
> "C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg" -
> Traceback (most recent call last):
>   File "C:\Users\Rich\workspace\PyTest\test.py", line 19, in 
> if os.path.getsize(path)>1:
>   File "C:\Python32\lib\genericpath.py", line 49, in getsize
> return os.stat(filename).st_size
> WindowsError: [Error 123] The filename, directory name, or volume
> label syntax is incorrect:
> '"C:
\\Users\\Rich\\Desktop\\2B_Proc\\2307e60da6451986dd8d23635b845386.jpg"'
> 
> From (snippet)
> 
> path = '"'+dirpath+name+'"'
> path = os.path.normpath(path)
> print("Path: -",path,"-")
> if os.path.getsize(path)>1:
> print("Path: ",path," Size:
> ",os.path.getsize(dirpath+name))
> 
> but if I manually use a console window and cut and paste the path I
> print, it works;
> 
> C:\>dir
> "C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg"
>  Volume in drive C is Windows7_OS
> 
>  Directory of C:\Users\Rich\Desktop\2B_Proc
> 
> 10/03/2016  08:35 AM59,200
> 2307e60da6451986dd8d23635b845386.jpg
>1 File(s) 59,200 bytes
>0 Dir(s)  115,857,260,544 bytes free
> 
> So the file is there and the path is correct. I'm adding quotes to the
> path to deal with directories and filenames that have spaces in them.
> If I drop the quotes, everything works as I expect *until* I encounter
> the first file/path with spaces.

You have to omit the extra quotes. That the non-working path has spaces in 
it is probably not the cause of the problem. If a string *literal* is used, 
e. g. "C:\Path\test file.txt" there may be combinations of the backslash and 
the character that follows that are interpreted specially -- in the example 
\P is just \ followed by a P whereas \t is a TAB (chr(9)):

>>> print("C:\Path\test file.txt")
C:\Path est file.txt

To fix the problem either use forward slashes (which are understood by 
Windows, too) or or duplicate all backslashes, 

>>> print("C:\\Path\\test file.txt")
C:\Path\test file.txt

or try the r (for "raw string") prefix:

>>> print(r"C:\Path\test file.txt")
C:\Path\test file.txt

This applies only to string literals in Python source code; if you read a 
filename from a file or get it as user input there is no need to process the 
string:

>>> input("Enter a file name: ")
Enter a file name: C:\Path\test file.txt
'C:\\Path\\test file.txt'

> I'll happily RTFM, but I need some hints as to which FM to R
> 

https://docs.python.org/3.5/tutorial/introduction.html#strings
https://docs.python.org/3.5/reference/lexical_analysis.html#string-and-bytes-literals

PS: Unrelated, but a portable way to combine paths is os.path.join() which 
will also insert the platform specific directory separator if necessary:

>>> print(os.path.join("foo", "bar\\", "baz"))
foo\bar\baz


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

Re: Doubled backslashes in Windows paths

[Stephen Tucker]

Hi Oz,

This might only be tangential to your actual issue, but, there again, it
might be the tiny clue that you actually need.

In Python, I use raw strings and single backslashes in folder hierarchy
strings to save the problem of the backslash in ordinary strings. Even with
this policy, however, there is a slight "gotcha": Although it is claimed
that r" ... " suspends the escape interpretation of the backslash in the
string, a raw string cannot end with a backslash:

   myraw = "\a\b\"

provokes the error message:

   SyntaxError: EOL while scanning string literal

To see how well this approach deals with folder hierarchies with spaces in
their names, I created the following file:

c:\Python27\ArcGIS10.4\Lib\idlelib\sjt\sp in\test.txt

Note the space in the folder name  sp in .

In IDLE, I then issued the following statement:

infile= open (r"c:\Python27\ArcGIS10.4\Lib\idlelib\sjt\sp in\test.txt", "r")

Note that I didn't need to get enclosing quotes into my folder hierarchy
string. It begins with  c  and ends with  t .

The statement worked as you might expect, and granted me access to the
lines in the file.

It seems that it is only necessary to enclose a folder hierarchy string in
quotes when defining the string in a situation in which spaces would
otherwise be interpreted as terminators. The classis case of this is in a
command with parameters in a batch file. If the string has been defined
before it is presented to the Windows Command interpreter, the spaces are
accepted as part of it without the need then of enclosing quotes.

Hope this helps.

Yours,

Stephen Tucker.


On Fri, Oct 7, 2016 at 6:30 AM, Oz-in-DFW  wrote:

> I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
> v.1900 32 bit (Intel)] on Windows 7
>
> I'm trying to write some file processing that looks at file size,
> extensions, and several other things and I'm having trouble getting a
> reliably usable path to files.
>
> The problem *seems* to be doubled backslashes in the path, but I've read
> elsewhere that this is just an artifact of the way the interpreter
> displays the strings.
>
> I'm getting an error message on an os.path.getsize call;
>
> Path: -
> "C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg" -
> Traceback (most recent call last):
>   File "C:\Users\Rich\workspace\PyTest\test.py", line 19, in 
> if os.path.getsize(path)>1:
>   File "C:\Python32\lib\genericpath.py", line 49, in getsize
> return os.stat(filename).st_size
> WindowsError: [Error 123] The filename, directory name, or volume
> label syntax is incorrect:
> '"C:\\Users\\Rich\\Desktop\\2B_Proc\\2307e60da6451986dd8d23635b8453
> 86.jpg"'
>
> From (snippet)
>
> path = '"'+dirpath+name+'"'
> path = os.path.normpath(path)
> print("Path: -",path,"-")
> if os.path.getsize(path)>1:
> print("Path: ",path," Size:
> ",os.path.getsize(dirpath+name))
>
> but if I manually use a console window and cut and paste the path I
> print, it works;
>
> C:\>dir
> "C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg"
>  Volume in drive C is Windows7_OS
>
>  Directory of C:\Users\Rich\Desktop\2B_Proc
>
> 10/03/2016  08:35 AM59,200
> 2307e60da6451986dd8d23635b845386.jpg
>1 File(s) 59,200 bytes
>0 Dir(s)  115,857,260,544 bytes free
>
> So the file is there and the path is correct. I'm adding quotes to the
> path to deal with directories and filenames that have spaces in them.
> If I drop the quotes, everything works as I expect *until* I encounter
> the first file/path with spaces.
>
> I'll happily RTFM, but I need some hints as to which FM to R
>
> --
> mailto:o...@ozindfw.net
> Oz
> POB 93167
> Southlake, TX 76092 (Near DFW Airport)
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: segfault using shutil.make_archive

[Chris Angelico]

On Fri, Oct 7, 2016 at 5:24 PM, dieter  wrote:
> Memory allocations are frequent (in many places) and they fail rarely.
> Therefore, there is quite a high probability that some of those
> allocations fail to check that the allocation has been successful.
> If this happens (and the allocation fails), then a "SIGSEGV" is
> almost certain.

Which, BTW, doesn't stop them from being bugs. If this can be pinned
down, it definitely warrants a bugs.python.org issue.

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

Re: static, class and instance methods

[Steve D'Aprano]

On Fri, 7 Oct 2016 04:01 pm, ast wrote:

> 
> "Gregory Ewing"  a écrit dans le message de
> news:e5mgi9fp1b...@mid.individual.net...
>> Lawrence D’Oliveiro wrote:
>>>
>>> Every function is already a descriptor.
>>
>> Which you can see with a simple experiment:
>>
>> >>> def f(self):
>> ...  print("self =", self)
>> ...
> 
> I thought yesterday that every thing was clear. But I have
> a doubt now with the following line:
> 
>> >>> g = f.__get__(17, None)
> 
> The signature of  __get__ method is  __get__ (self, inst, owner)  so
> once again the first parameter is filled automatically.
> Is method __get__ itself a descriptor with an attribute __get__ to perform
> the operation ? Hum, it would be endless ...

No it is not:

py> def f(): pass
...
py> hasattr(f.__get__, '__get__')
False


So what kind of thing is f.__get__? f itself is a function, which looks like
this:

py> f



but f.__get__ is something different:

py> f.__get__



"Method-wrapper" is an undocumented internal implementation detail. It isn't
part of the Python language, just part of the runtime implementation. If we
use Jython instead, we see something different:

steve@orac:~$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
[OpenJDK Server VM (Sun Microsystems Inc.)] on java1.6.0_31
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(): pass
...
>>> f

>>> f.__get__



So the Python language doesn't make any promises about what sort of thing
__get__ will be, only that it exists and is callable. Anything I say here
is an implementation detail: it may change in the future, it may have
already changed, and different Python implementations may do things
differently.

Back to CPython: f.__get__ is a method-wrapper. That gives us a hint that
although __get__ itself isn't a descriptor, it is a thing returned by
something which is a descriptor.

Remember that all functions are instances of a built-in class, FunctionType:

py> from types import FunctionType
py> assert type(f) is FunctionType
py> vars(FunctionType)['__get__']


It is *that* "slot wrapper" thing which is itself a descriptor:

py> vars(FunctionType)['__get__'].__get__


and it returns f.__get__:

py> vars(FunctionType)['__get__'].__get__(f)


which returns a method:

py> class X(object): pass
...
py> x = X()
py> vars(FunctionType)['__get__'].__get__(f)(x, X)
>




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Question on multiple Python users in one application

[Gregory Ewing]

Loren Wilton wrote:

One concern I have is if two users both "import widget". Are they now sharing
the widget namespace? I suspect they are, and that is probably undesirable.


Yes, they will be, unless you use sub-interpreters.

I've just been looking at the current docs for sub-interpreters,
and assuming they're not lying too wildly, sub-interpreters
might be what you're after.

https://docs.python.org/3/c-api/init.html

An excerpt:

 PyThreadState* Py_NewInterpreter()

Create a new sub-interpreter. This is an (almost) totally separate
environment for the execution of Python code. In particular, the new interpreter
has separate, independent versions of all imported modules, including the
fundamental modules builtins, __main__ and sys. The table of loaded modules
(sys.modules) and the module search path (sys.path) are also separate. The new
environment has no sys.argv variable. It has new standard I/O stream file
objects sys.stdin, sys.stdout and sys.stderr (however these refer to the same
underlying file descriptors).

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

Doubled backslashes in Windows paths

[Oz-in-DFW]

I'm using Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC
v.1900 32 bit (Intel)] on Windows 7

I'm trying to write some file processing that looks at file size,
extensions, and several other things and I'm having trouble getting a
reliably usable path to files.

The problem *seems* to be doubled backslashes in the path, but I've read
elsewhere that this is just an artifact of the way the interpreter
displays the strings.

I'm getting an error message on an os.path.getsize call;

Path: -
"C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg" -
Traceback (most recent call last):
  File "C:\Users\Rich\workspace\PyTest\test.py", line 19, in 
if os.path.getsize(path)>1:
  File "C:\Python32\lib\genericpath.py", line 49, in getsize
return os.stat(filename).st_size
WindowsError: [Error 123] The filename, directory name, or volume
label syntax is incorrect:
'"C:\\Users\\Rich\\Desktop\\2B_Proc\\2307e60da6451986dd8d23635b845386.jpg"'

>From (snippet)

path = '"'+dirpath+name+'"'
path = os.path.normpath(path)
print("Path: -",path,"-")
if os.path.getsize(path)>1:
print("Path: ",path," Size:
",os.path.getsize(dirpath+name))

but if I manually use a console window and cut and paste the path I
print, it works;

C:\>dir
"C:\Users\Rich\Desktop\2B_Proc\2307e60da6451986dd8d23635b845386.jpg"
 Volume in drive C is Windows7_OS

 Directory of C:\Users\Rich\Desktop\2B_Proc

10/03/2016  08:35 AM59,200
2307e60da6451986dd8d23635b845386.jpg
   1 File(s) 59,200 bytes
   0 Dir(s)  115,857,260,544 bytes free

So the file is there and the path is correct. I'm adding quotes to the
path to deal with directories and filenames that have spaces in them. 
If I drop the quotes, everything works as I expect *until* I encounter
the first file/path with spaces.

I'll happily RTFM, but I need some hints as to which FM to R

-- 
mailto:o...@ozindfw.net
Oz
POB 93167 
Southlake, TX 76092 (Near DFW Airport) 



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

Re: Question on multiple Python users in one application

[Gregory Ewing]

Loren Wilton wrote:
I've read that Python supports 'threads', and I'd assumed (maybe 
incorrectly) that these were somewhat separate environments that could 
be operating concurrently (modulo the GC lock).


Not really. Python threads are just a thin wrapper around
OS threads, and don't provide any more isolation than the
OS's native threads do. All the threads in a Python process
share one set of imported modules, and therefore one set
of global data.

For example, there will only be one sys module, and thus
things like sys.stdin and sys.stdout will be shared between
threads. If one user pointed his sys.stdin somewhere else,
it would affect all the others.

There is *some* support in CPython for multiple interpeters
within a process, but I don't know how much isolation that
provides, or whether it has even kept up enough with all the
changes over the years to still be usable. I know that
subinterpreters are not fully isolated, e.g. built-in
constants and type objects are shared.

There is also the GIL to consider, which will prevent more
than one thread from running Python code at the same time.

Does Python really need access to data in the VM's memory,
or just to data in its disk files, etc? If the latter,
you might not need to run Python in the same process as
the VM as long as you can arrange some kind of I/O bridge.

Does the OS running on the VM have any notion of a remote
file access protocol a la NFS that an external Python
process could use to access data?

--
Greg

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