date:20190918



Change by miss-islington :


--
pull_requests: +15863
pull_request: https://github.com/python/cpython/pull/16274

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions



Change by miss-islington :


--
pull_requests: +15864
pull_request: https://github.com/python/cpython/pull/16275

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

2019-09-18 Thread Eryk Sun


Eryk Sun  added the comment:

The result from strftime is platform dependent. In Windows, the result has a 
trailing "." for the abbreviated names that are less than four characters, but 
no "de" in either form:

>>> months = [(2019, m) + (0,)*7 for m in range(1,13)]
>>> locale.setlocale(locale.LC_ALL, 'ca_ES.utf8')
'ca_ES.utf8'
>>> print(*(time.strftime('%b|%B', m) for m in months), sep='\n')
gen.|gener
febr.|febrer
març|març
abr.|abril
maig|maig
juny|juny
jul.|juliol
ag.|agost
set.|setembre
oct.|octubre
nov.|novembre
des.|desembre

In Linux, the result uses the same base abbreviations as in Windows, including 
the trailing ".", but it also includes "de" or "d'" in both forms:

>>> months = [(2019, m) + (0,)*7 for m in range(1,13)]
>>> locale.setlocale(locale.LC_ALL, 'ca_ES.utf8')
'ca_ES.utf8'
>>> print(*(time.strftime('%b|%B', m) for m in months), sep='\n')
de gen.|de gener
de febr.|de febrer
de març|de març
d’abr.|d’abril
de maig|de maig
de juny|de juny
de jul.|de juliol
d’ag.|d’agost
de set.|de setembre
d’oct.|d’octubre
de nov.|de novembre
de des.|de desembre

--
nosy: +eryksun
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions



Change by miss-islington :


--
pull_requests: +15862
pull_request: https://github.com/python/cpython/pull/16273

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions



Change by miss-islington :


--
pull_requests: +15861
pull_request: https://github.com/python/cpython/pull/16272

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: exec and globals and locals ...

2019-09-18 Thread dieter

Eko palypse  writes:
> Why does f1 work? I've expected an exception as no global dict has been 
> provided
> ...
>def f1(...):
>  exec("...")
>...

The documentation ("https://docs.python.org/3/library/functions.html#exec;)
tells you:

exec(object[, globals[, locals]])
...
In all cases, if the optional parts are omitted, the code is executed in the 
current scope. ...

You can see from it that "globals" is optional.
And that, if "globals" is missing, then
"exec" is executed in the current scope ("f1" in your case).

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

Re: Spread a statement over various lines

2019-09-18 Thread Manfred Lotz

On Wed, 18 Sep 2019 22:01:34 +0200
"Ralf M."  wrote:

> Am 17.09.2019 um 20:59 schrieb Manfred Lotz:
> > I have a function like follows
> > 
> > def regex_from_filepat(fpat):
> >  rfpat = fpat.replace('.', '\\.') \
> >.replace('%', '.')  \
> >.replace('*', '.*')
> > 
> >  return '^' + rfpat + '$'
> > 
> > 
> > As I don't want to have the replace() functions in one line my
> > question is if it is ok to spread the statement over various lines
> > as shown above, or if there is a better way?
> > 
> > Thanks.
> >   
> 
> Not related to your question, but:
> You seem to try to convert a Windows wildcard pattern to a regex 
> pattern. 

No, I'm on Linux.

Shortly, after I had posted the question I discovered fnmatch() in the
standard library, and I changed my code accordingly.

Nevertheless, I was happy to have asked the question as the
following discussion was very interesting for me.

-- 
Manfred

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

[issue38116] Make select module PEP-384 compatible

2019-09-18 Thread Paulo Henrique Silva



Change by Paulo Henrique Silva :


--
nosy: +phsilva

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38221] Enhancement to pydoc for Python 3.6 to allow full backgrounding as a server

2019-09-18 Thread Lindsay Haisley



New submission from Lindsay Haisley :

This patch extends the functionality of pydoc3 to allow it to run purely as a 
server, as is the case with pydoc for python 2.7. If the -d option is 
specified, pydoc as a server (-p  option) may be backgrounded to a 
subshell with "&".

--
assignee: docs@python
components: Documentation
files: pydoc3.diff
keywords: patch
messages: 352766
nosy: docs@python, fmouse
priority: normal
severity: normal
status: open
title: Enhancement to pydoc for Python 3.6 to allow full backgrounding as a 
server
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file48613/pydoc3.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Ammar Askar



Ammar Askar  added the comment:

For the control path warning, that can be fixed by just hinting to the compiler 
that the function doesn't return like so:

  # ifdef __GNUC__
  __attribute__ ((noreturn))
  # elif defined(_MSC_VER)
  __declspec(noreturn)
  # endif
  static inline void
  _Py_UNREACHABLE()
  {


(https://godbolt.org/z/AG9tx_)

--
nosy: +ammar2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Ma Lin



Ma Lin  added the comment:

PR 16270 use Py_UNREACHABLE() in a single line.
It solves this particular issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Ma Lin



Change by Ma Lin :


--
keywords: +patch
pull_requests: +15860
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16270

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Ma Lin



Ma Lin  added the comment:

If use static inline function, and Py_UNREACHABLE() inside an if-else branch 
that should return a value, compiler may emit warning:
https://godbolt.org/z/YtcNSf

MSVC v19.14:
warning C4715: 'test': not all control paths return a value

clang 8.0.0:
warning: control may reach end of non-void function [-Wreturn-type]

Other compilers (gcc, icc) don't emit this warning.

This situation in real code:
https://github.com/python/cpython/blob/v3.8.0b4/Include/object.h#L600
https://github.com/python/cpython/blob/v3.8.0b4/Objects/longobject.c#L3088

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17822] Save on Close windows (IDLE)

2019-09-18 Thread Terry J. Reedy



Terry J. Reedy  added the comment:

AttributeErrors on closing were a separate issue.  They are now caught on 
closing.  #35379.

Save on Close is now modal on Windows also, in that one cannot do anything with 
the Window being closed.

One can try to close a second dirty window.  Saying 'no' in either dialog no 
longer crashes.  The only oddity is that if one switched from the 2nd dialog to 
the 1st and say 'no' on the first first, it does not immediately close until 
one answers on the second.  It seems normal to me that the 2nd call that raises 
the 2nd dialog blocks the 1st from receiving and responding to the 1st click 
until the 2nd call returns.  

Thus the bugs reported here have been otherwise fixed.

--
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29258] init.py required for pkgutil.walk_packages in python3

2019-09-18 Thread Eric Wieser



Change by Eric Wieser :


--
nosy: +Eric Wieser

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35379] IDLE's close fails io is set to None on Mac

2019-09-18 Thread Terry J. Reedy



Terry J. Reedy  added the comment:

#17822 is not what I was thinking of, nor are #17614 or #22614, so I considered 
this issue done for now.

--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Spread a statement over various lines

2019-09-18 Thread codewizard

On Wednesday, September 18, 2019 at 9:01:21 AM UTC-4, Manfred Lotz wrote:
> On Wed, 18 Sep 2019 08:30:08 +0200
> Peter Otten <__pete...@web.de> wrote:
> 
> > Manfred Lotz wrote:
> > 
> > > I have a function like follows
> > > 
> > > def regex_from_filepat(fpat):
> > > rfpat = fpat.replace('.', '\\.') \
> > >   .replace('%', '.')  \
> > >   .replace('*', '.*')
> > > 
> > > return '^' + rfpat + '$'
> > > 
> > > 
> > > As I don't want to have the replace() functions in one line my
> > > question is if it is ok to spread the statement over various lines
> > > as shown above, or if there is a better way?  
> > 
> > Sometimes you can avoid method-chaining:
> > 
> > >>> REP = str.maketrans({".": "\\.", "%": ".", "*": ".*"})
> > >>> def regex_from_filepat(fpat):  
> > ... return fpat.translate(REP)
> > ... 
> > >>> regex_from_filepat("*foo.%")  
> > '.*foo\\..'
> > 
> 
> Very interesting. Thanks for this.

While I think that str.translate() is the right tool for this job,
here's another way to avoid line continuations (not necessarily better):

def regex_from_filepat(fpat):
replacements = [
('.', '\\.'),
('%', '.'),
('*', '.*'),
]

rfpat = fpat
for old, new in replacements:
rfpat = rfpat.replace(old, new)

return '^' + rfpat + '$'
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38216] Fix for issue30458 prevents crafting invalid requests

2019-09-18 Thread Tim Burke



Change by Tim Burke :


--
nosy: +tburke

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)

2019-09-18 Thread Ned Deily



Ned Deily  added the comment:

With the breaking out of the portential and/or actual regression (e.g. invalid 
requests can no longer be crafted) into Issue38216, itself a potential release 
blocker, we are still left here with the as-yet unresolved issue identified 
above in msg34728 (e.g. not checking for control characters in the "host" part 
of the URL, only the "path" part).  Since this also affects so many 
branches/releases and has external components (CVE's, third-party impacts), it 
probably would have made sense to break it out into a separate issue (and maybe 
it still does).  But since this problem has been present for many releases 
(apparently), I would rather not further hold the 3.7.5 release for a 
resolution (though that would be a good thing) so I'm going to change the 
priority for the moment to "deferred blocker".

But we need someone (preferably a core dev already involved) to take charge of 
this and push it to a resolution.  Thanks for everyone's help so far!

--
priority: release blocker -> deferred blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38216] Fix for issue30458 prevents crafting invalid requests

2019-09-18 Thread Ned Deily



Ned Deily  added the comment:

Thanks for identifying this issue and breaking it out into a separate bpo, 
Jason.  If I understand correctly, the problematic fix for Issue30458 has 
already been released in maintenance release 3.7.4 and security release 3.6.9, 
is in the current security release candidate 3.5.8rc1, as well as 3.8.0b4, and, 
without further action, will be in 2.7.17rc1 and continue to be in 3.7.5rc1.  
In other words, this issue potentially affects all currently maintained Python 
branches and/or releases.  (In addition, there appear to be still unresolved 
questions about the original Issue30458 and the CVE's associated with it.  But 
let's ignore those here. My brain hurts enough already.)

The immediate question for me is what to do about 3.7.5.  We could:
1. hold 3.7.5rc1 for a mitigation fix
2. release 3.7.5rc1 and accept a fix for 3.7.5final or for an unplanned 3.7.5rc2
3. fix in 3.7.6
4. do nothing other than possibly a doc change

Since 3.5.8rc1 is already released for testing, a similar decision needs to be 
made for it.

And 3.8.0rc1 and 2.7.17rc1 are schedulded for tagging om the coming weeks.

Since the problem. as best I understand, is most likely to impact tests rather 
than legitimate user cases (is that correct?) and, since at least some projects 
and users of 3.7.4 impacted by the change have developed workarounds, and since 
3.7.5rc1 is being delayed pending a resolution of this, I think the best 
options for 3.7.5 at this point are either 2 or 3 above.  So, unless someone 
expresses a major objection in the next few hours, I am going to proceed with 
3.7.5rc1 as is with the hope that we will have final resolution prior to 3.7.5 
final.

Decisions will still have to be made by the other RMs for their branches.

--
nosy: +benjamin.peterson, larry, lukasz.langa, ned.deily
priority: normal -> release blocker
versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

exec and globals and locals ...

2019-09-18 Thread Eko palypse

Why does f1 work? I've expected an exception as no global dict has been 
provided, and why does throw f3 an exception if it does, more or less, the same 
as f1?

x += 5
def f1():
exec("x += 1; print('f1 in:', x)")
return x
print('f1 out', f1())

# result => f1 in: 6
# result => f1 out 5


x = 5
def f2():
exec("x += 1; print('f2 in:', x)", globals())
return x
print('f2 out', f2())

# result => f2 in: 6
# result => f2 out 6


exec('import test01', globals())
print('f3 out', x)

# result exception, expected but because f1 didn't throw an exception 
# I'm confused. module test01 has only this two lines
x += 1
print('f3 in:', x)

Thank you
Eren
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Zachary Ware



Zachary Ware  added the comment:

I have poked at this a bit and have an implementation that defines a `static 
inline void _Py_Unreachable()` in pymacro.h, see 
https://github.com/zware/cpython/commit/d07b4255dc1170155e18db0fea99ec1cb29c2f0a

This works on at least macOS and Windows, and we also have prior art for 
defining static inline functions in headers in GH-10079.  If we agree that 
that's an acceptable solution, I'll open a PR for that change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Spread a statement over various lines

2019-09-18 Thread Alexandre Brault


On 2019-09-18 4:01 p.m., Ralf M. wrote:
> Am 17.09.2019 um 20:59 schrieb Manfred Lotz:
>> I have a function like follows
>>
>> def regex_from_filepat(fpat):
>>  rfpat = fpat.replace('.', '\\.') \
>>    .replace('%', '.')  \
>>    .replace('*', '.*')
>>
>>  return '^' + rfpat + '$'
>>
>>
>> As I don't want to have the replace() functions in one line my
>> question is if it is ok to spread the statement over various lines as
>> shown above, or if there is a better way?
>>
>> Thanks.
>>
>
> Not related to your question, but:
> You seem to try to convert a Windows wildcard pattern to a regex
> pattern. However, wildcards sometimes behave a bit different than what
> you assume. I know for instance that *.* matches any filename, even if
> the filename doesn't contain a dot.
>
> Out of curiosity I played around a bit, details below.
> As you can see, there are other wildcard strangenesses, e.g.
> - ? does not match a dot
> -  between letters etc. matches exactly 4 characters, but
>    at the end or directly before a dot matches at most 4 characters
>
> I don't know the exact rules of Windows wildcards, so there may be
> even more cases of unexpected behavior.
> If anyone knows where to find the complete rules (or a python module
> that implements them), I would be interested.
>

fnmatch in the standard library has a translate function that transforms
a glob pattern to a regex

https://docs.python.org/3.7/library/fnmatch.html#fnmatch.translate

Alex

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

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Gregory P. Smith



Gregory P. Smith  added the comment:

While I don't like how that get_small_int macro is defined...
and I don't like that Py_UNREACHABLE() was usable as an expression in the 
past...

it is probably best to just revert 3ab61473ba7f3dca32d779ec2766a4faa0657923.

The choice to use a macro for this when it was created and the way the macro 
was defined means it is an expression forever unless we want to bother forcing 
code cleanups for uses of it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

2019-09-18 Thread Ned Deily



Change by Ned Deily :


--
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

2019-09-18 Thread Joan



Joan  added the comment:

Issue can be reproduced with this snippet:
---
import locale
from datetime import datetime
locale.setlocale(locale.LC_ALL, 'ca_AD.utf8')
locale.setlocale(locale.LC_ALL, 'ca_ES.utf8')
#locale.setlocale(locale.LC_ALL, 'es_ES.utf8')
now = datetime.now() # current date and time
date_time = now.strftime("|%b|%B|")
print("date and time:",date_time)   
---

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

2019-09-18 Thread Joan


New submission from Joan :

There's an incorrect behaviour in the output for the strftime values when in 
catalan.
On the documentation at 
https://docs.python.org/3.7/library/datetime.html#strftime-strptime-behavior:

- %b Month as locale’s abbreviated name. Jan, Feb, …, Dec (en_US)
- %B Month as locale’s full name. January, February, …, December (en_US);

It works also in es_ES an others, while in catalan there's an extra article on 
the month name (and a point in the abbreviated version) that shouldn't be there 
de "set." and "de setembre".

Where should I go to fix this and get the documented behaviour? I haven't been 
able to find a translation section on python site.

--
components: Library (Lib)
messages: 352755
nosy: aseques
priority: normal
severity: normal
status: open
title: Wrong values for %b and %B in ca_ES and ca_AD locales
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

2019-09-18 Thread David Cuthbert



Change by David Cuthbert :


--
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

2019-09-18 Thread David Cuthbert



David Cuthbert  added the comment:

I'm seeing this on a rebuild now of Python 3.7.4 on Ubuntu 18.04 (in my case 
against _ssl.c).

What's happening is there's coverage/profiling data being generated in the 
build chain (somewhere), which spits out files named *.gcda. Interestingly, 
make clean does *not* clean these files up.

gcc is attempting to use this data in its optimization, but discovers that it's 
now bogus -- likely due to system library headers (like OpenSSL) being updated 
in the meantime, with some inline code causing the coverage data to become 
invalid.

The fix should be to have 'make clean' clean up these *.gcda files. In the 
meantime, the workaround is to run "find . -name \*.gcda -exec rm '{}' \;"

--
nosy: +dacut
versions: +Python 3.7 -Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38219] Optimize dict.init and dict.update for dict argument



Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +15859
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16268

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38219] Optimize dict.init and dict.update for dict argument



New submission from Serhiy Storchaka :

dict.__init__() and dict.update() with a positional argument look up the "keys" 
attribute of the argument to distinguish a mapping from a sequence of 
item-value pairs. It has a non-trivial cost. Merging dicts is optimized for 
exact dicts in PyDict_Merge(), so it would be worth to optimize also this check.

$ ./python -m pyperf timeit -s "d = {}; D = dict" -- "D(d)"
Unpatched:  Mean +- std dev: 154 ns +- 4 ns
Patched:Mean +- std dev: 110 ns +- 4 ns

$ ./python -m pyperf timeit -s "d = {}" -- "d.update(d)"
Unpatched:  Mean +- std dev: 112 ns +- 3 ns
Patched:Mean +- std dev: 70.4 ns +- 1.5 ns

The cost of the check is about 40 ns, and it is a significant part of the total 
time of creating/updating a small dict.

--
components: Interpreter Core
messages: 352753
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize dict.__init__ and dict.update for dict argument
type: performance
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Spread a statement over various lines

2019-09-18 Thread Chris Angelico

On Thu, Sep 19, 2019 at 6:20 AM Ralf M.  wrote:
>
> Am 17.09.2019 um 20:59 schrieb Manfred Lotz:
> > I have a function like follows
> >
> > def regex_from_filepat(fpat):
> >  rfpat = fpat.replace('.', '\\.') \
> >.replace('%', '.')  \
> >.replace('*', '.*')
> >
> >  return '^' + rfpat + '$'
> >
> >
> > As I don't want to have the replace() functions in one line my
> > question is if it is ok to spread the statement over various lines as
> > shown above, or if there is a better way?
> >
> > Thanks.
> >
>
> Not related to your question, but:
> You seem to try to convert a Windows wildcard pattern to a regex
> pattern. However, wildcards sometimes behave a bit different than what
> you assume. I know for instance that *.* matches any filename, even if
> the filename doesn't contain a dot.

Hmm, why do you assume it's a Windows wildcard pattern specifically?

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

Re: Spread a statement over various lines

2019-09-18 Thread Ralf M.


Am 17.09.2019 um 20:59 schrieb Manfred Lotz:

I have a function like follows

def regex_from_filepat(fpat):
 rfpat = fpat.replace('.', '\\.') \
   .replace('%', '.')  \
   .replace('*', '.*')

 return '^' + rfpat + '$'


As I don't want to have the replace() functions in one line my
question is if it is ok to spread the statement over various lines as
shown above, or if there is a better way?

Thanks.



Not related to your question, but:
You seem to try to convert a Windows wildcard pattern to a regex 
pattern. However, wildcards sometimes behave a bit different than what 
you assume. I know for instance that *.* matches any filename, even if 
the filename doesn't contain a dot.


Out of curiosity I played around a bit, details below.
As you can see, there are other wildcard strangenesses, e.g.
- ? does not match a dot
-  between letters etc. matches exactly 4 characters, but
   at the end or directly before a dot matches at most 4 characters

I don't know the exact rules of Windows wildcards, so there may be even 
more cases of unexpected behavior.
If anyone knows where to find the complete rules (or a python module 
that implements them), I would be interested.


Regards,
Ralf

- Details (Win 7 home SP1) -

C:\tmp>more pydirb.py
#!/usr/bin/env python3

import os, re, sys

def regex_from_filepat(fpat):
rfpat = fpat.replace('.', '\\.') \
.replace('?', '.')   \
.replace('*', '.*')
return '^' + rfpat + '$'

regexfilepat = re.compile(regex_from_filepat(sys.argv[1]))

for name in os.listdir():
if regexfilepat.match(name):
print(name)

C:\tmp>dir /b *
foo
foo.bar
foo.bar.c
foo.c
pydirb.py

C:\tmp>pydirb *
foo
foo.bar
foo.bar.c
foo.c
pydirb.py

C:\tmp>dir /b *.*
foo
foo.bar
foo.bar.c
foo.c
pydirb.py

C:\tmp>pydirb *.*
foo.bar
foo.bar.c
foo.c
pydirb.py

C:\tmp>dir /b *.*.*.*.*
foo
foo.bar
foo.bar.c
foo.c
pydirb.py

C:\tmp>pydirb *.*.*.*.*

C:\tmp>dir /b foo.?
foo
foo.c

C:\tmp>pydirb foo.?
foo.c

C:\tmp>dir /b foo.
foo
foo.bar
foo.c

C:\tmp>pydirb foo.

C:\tmp>dir /b foo?bar
Datei nicht gefunden

C:\tmp>pydirb foo?bar
foo.bar

C:\tmp>dir /b f?o.bar
foo.bar

C:\tmp>pydirb f?o.bar
foo.bar

C:\tmp>dir /b f??o.bar
Datei nicht gefunden

C:\tmp>pydirb f??o.bar

C:\tmp>dir /b fo?.bar
foo.bar

C:\tmp>pydirb fo?.bar
foo.bar

C:\tmp>dir /b fo??.bar
foo.bar

C:\tmp>pydirb fo??.bar

C:\tmp>dir /b foo??.bar
foo.bar

C:\tmp>pydirb foo??.bar
--
https://mail.python.org/mailman/listinfo/python-list

[issue38200] Adding itertools.pairwise to the standard library?

2019-09-18 Thread Tim Peters



Tim Peters  added the comment:

There's an eternal culture clash here:  functional languages have a long 
history of building in just about everything of plausible use, regardless of 
how trivial to build on other stuff.  This started when LISP was barely 
released before (cadr x) was introduced as a shorthand for (car (cdr x)), and 
(caddr x) for (car (cdr (cdr x))), and so on.  Which more modern functional 
languages also supply (second x) and (third x) spellings for (_and_ nth(2, x) 
and nth(3, x) spellings).

This one is harder to get right than those, but not hard at all.  But it's not 
coincidence that itertoolz[1] (note the trailing 'z') also supplies it, spelled 
`sliding_window(width, iterable)` there.  Working with finite difference 
algorithms is probably "the most obvious" use case for a width of 2.

More esoterically, one of my favorite "technical indicators" for stock analysis 
is a dead simple 20-period simple moving average, which can be built very 
conveniently (although not very efficiently - but I don't usually care) by 
mapping a mean function over a sliding window of width 20.

BTW, if you want padding on each end, you can apply pairwise to `chain([first], 
iterable, [last])`.

A related function is breaking an iterable into _non_-overlapping chunks of a 
given width.  itertoolz spells that "partition".  For me that comes up more 
often than overlapping windows.

I like having these things around, but it's not a big deal.  Perhaps it would 
be an easier decision in Python if we gave up on believing that everything in 
itertools _must_ be coded in C.  In functional idioms sometimes speed isn't the 
point at all, but rather using conventional names for simple but compound 
functionality.  Like that "sliding window" is a concept in its own right.  If 
I'm _picturing_ an algorithm in terms of a sliding window, then - of course - 
the shortest distance to working code is to use a facility that already 
implements that concept.

Which is a long way of saying +0.

[1] https://toolz.readthedocs.io/en/latest/api.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)



Jason R. Coombs  added the comment:

I've created issue38216 to address the (perceived) regression.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38216] Fix for issue30458 prevents crafting invalid requests



Change by Jason R. Coombs :


--
keywords: +3.6regression, 3.7regression

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36274] http.client cannot send non-ASCII request lines



Jason R. Coombs  added the comment:

That's right - no longer a 3.7 regression here.

--
keywords:  -3.7regression

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38200] Adding itertools.pairwise to the standard library?

2019-09-18 Thread Vedran Čačić


Vedran Čačić  added the comment:

I also use it all the time. Most recently in some numerical calculation for 
successive differences. My main problem is that I'm too often tempted to just 
zip l with l[1:], thereby restricting the code to sequences, when it would work 
perfectly well for any iterable. (Just as I sometimes write range(lots of 
nines) instead of itertools.count() *shame*;)

--
nosy: +veky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38215] Do not import modules in star-import when all is not defined.

2019-09-18 Thread Ethan Furman



Ethan Furman  added the comment:

It's the casual users' code that will break.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38215] Do not import modules in star-import when all is not defined.



Serhiy Storchaka  added the comment:

I believe that significant part or even most of code is writing without using 
linters and type checkers. Python is too convenient for non-professional 
programmers. You do not need to declare all variables with their types to use 
Python and do not need to run a compiler/linker/checker after editing sources.

There was such mistake (using a module implicitly imported by star-import) even 
in the Python stdlib (fixed now).

This change would increase the quality of code if you do not use __all__ and do 
not have habits to write "import sys as _sys". It will not affect professional 
code. It is just a small step in the direction of been casual user friendly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions

2019-09-18 Thread Roundup Robot



Change by Roundup Robot :


--
keywords: +patch
pull_requests: +15858
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16265

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38215] Do not import modules in star-import when all is not defined.



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38218] SyntaxError in Tutorial 8.6 Defining Clean-up Actions

2019-09-18 Thread Jason Plurad



New submission from Jason Plurad :

The second code example in Tutorial section 8.6 defines the function:

def bool_return(): -> bool:

which throws a SyntaxError: invalid syntax

If the function wants to use a return annotation, there should not be a colon 
after the function name. I have a pull request ready for this.

--
assignee: docs@python
components: Documentation
messages: 352746
nosy: Jason Plurad, docs@python
priority: normal
severity: normal
status: open
title: SyntaxError in Tutorial 8.6 Defining Clean-up Actions

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38215] Do not import modules in star-import when all is not defined.

2019-09-18 Thread Brett Cannon



Change by Brett Cannon :


--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38215] Do not import modules in star-import when all is not defined.

2019-09-18 Thread Ethan Furman



Ethan Furman  added the comment:

I don't think this is worth the code breakage.

The advice already given is not to use `import *` unless:

- the module was designed for that usage; or
- you know what you are doing.

--
nosy: +ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38217] argparse should support multiple types when nargs > 1

2019-09-18 Thread paul j3



paul j3  added the comment:

Which is more valuable to you, the string conversion, or the checking?

What's wrong with doing the 'type check' in post parsing code?  (MarSoft's 
answer in the SO link).

To make a better case for this, I'd suggest writing your own fix.  It doesn't 
need to be a polished push, but enough code to show that the change is 
relatively simple (preferably occurring in only one or two functions).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38217] argparse should support multiple types when nargs > 1



Change by Karthikeyan Singaravelan :


--
nosy: +paul.j3, rhettinger
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36274] http.client cannot send non-ASCII request lines



Karthikeyan Singaravelan  added the comment:

> @xtreak the encoded null-byte test would be an extra test case to consider. 
> It is reasonable to test as many known invalid sequences as possible. 
> Changing that byte to encoded notation would just replace one test with 
> another effectively changing the semantics of it.

Agreed that it's slightly different but I also admit I was also relying on the 
fact that encoded request will also be decoded by the server as done in most 
web frameworks to act upon the decoded payload. There could be systems where 
raw null byte might need to be transferred where the receiving system might not 
decode the payload but it seemed to be a workaround to ensure the required 
exception of serving null byte included static file was handled properly by 
CherryPy and also seemed to be adopted by others like urllib3.

> To me, it's quite weird that it's considered a CVE at all: it's happening on 
> the client side and it doesn't prevent the user from just feeding the proper 
> bytes right into the socket so why overcomplicate things?

The impacted function in http is used by functions like urllib.urlopen which is 
often feeded with input from the user that is not validated properly with some 
expectation that the function itself might handle the URL parsing and is safe 
enough. In this case it could lead to things like SSRF where malicious input 
could end up executing arbitrary code in some of the systems like Redis as 
demonstrated in the report. As for the CVE in question it was originally 
reported to golang and the same attack was also found out to be vulnerable. The 
fix adopted also seemed to have address few other security reports of similar 
nature.

Thanks Jason, as issue38216 is now a separate issue we can discuss around 
there. I guess this issue then is not a 3.7 only regression anymore since the 
original issue reported predates 3.7.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38204] Cannot compile on RPi with optimizations

2019-09-18 Thread Thomas Knox



Thomas Knox  added the comment:

I updated binutils:

pi@pi4b:~/Downloads/Python-3.8.0b4 $ ld --version
GNU ld (GNU Binutils) 2.32

Same problem.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38215] Do not import modules in star-import when all is not defined.

2019-09-18 Thread Guido van Rossum



Guido van Rossum  added the comment:

I feel that this is a relatively minor issue, and not worth breaking "working" 
code over. Some more pedantic tool like a linter or type checker would be a 
better place to start diagnosing this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38217] argparse should support multiple types when nargs > 1

2019-09-18 Thread Ryan Govostes

New submission from Ryan Govostes :

argparse supports consuming multiple command-line arguments with nargs=2, etc.
It converts them to the type given in the argument's type parameter.

argparse does not provide a good solution when the input arguments should be
different data types. For an example, you cannot have an argument that expects
a str followed by an int, '--set-age Bob 34'.

Ordinarily, the suggestion would be to split it into two arguments, like
'--set-person Bob --set-age 34'.

However, this becomes awkward with an action such as 'append', where the
command line arguments become tedious, like '--set-person Bob --set-age 34
--set-person Alice --set-age 29', or confusing, as in '--set-person Bob
--set-person Alice --set-age 34 --set-age 29'.

My proposal is to allow the 'type' parameter to accept a tuple of types:

p.add_argument('--set-age', nargs=2, type=(str, int))

Since 'nargs' is redundant, this could even be simplified to just:

p.add_argument('--set-age', type=(str, int))

The resulting parsed argument would then be a tuple of (str, int), as opposed
to a list. If action='append', the result would be a list of such tuples.

This creates no backwards compatibility issue because tuple instances are not
callable, so this was never valid code that did something else.

A further enhancement could be that when nargs='+' or '*', and a tuple of types
is provided, the types are used round robin: '--set-ages Bob 34 Alice 29'. An
exception would be raised if it would create an incomplete tuple.

See here for other discussion and workarounds:
https://stackoverflow.com/questions/16959101/python-argparse-how-to-have-nargs-2-with-type-str-and-type-int

--
components: Library (Lib)
messages: 352741
nosy: rgov
priority: normal
severity: normal
status: open
title: argparse should support multiple types when nargs > 1
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38216] Fix for issue30458 prevents crafting invalid requests

2019-09-18 Thread Sviatoslav Sydorenko



Change by Sviatoslav Sydorenko :


--
nosy: +webknjaz

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38216] Fix for issue30458 prevents crafting invalid requests



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17258] multiprocessing.connection challenge implicitly uses MD5

2019-09-18 Thread Charalampos Stratakis



Change by Charalampos Stratakis :


--
pull_requests: +15857
pull_request: https://github.com/python/cpython/pull/16264

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36274] http.client cannot send non-ASCII request lines



Jason R. Coombs  added the comment:

I've created issue38216 to address the issue of sending invalid bytes in the 
request line, separate from the original intention and title issue about 
sending non-ASCII.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38216] Fix for issue30458 prevents crafting invalid requests



New submission from Jason R. Coombs :

The fix for issue30458 prevents any request line from transmitting non-ascii 
characters. In some cases, it's useful to transmit these illegal bytes in order 
to simulate a maliciously-crafted request (such as to ensure a web server 
responds correctly to such a request). This limitation is a regression from 
previous behavior that allowed transmission of such invalid requests.

For example, consider [this 
comment](https://github.com/cherrypy/cherrypy/issues/1781#issuecomment-507836873),
 where tests in CherryPy were disabled due to emergent failures against nightly 
builds.

Originally, I reported this issue in issue36274, but I believe this issue is 
distinct and has a different timeline from that issue.

In [this comment](https://bugs.python.org/issue36274#msg352711), xtreak 
suggests that the proper solution might be not to transmit raw invalid 
characters but to actually rely on URL quoting to "transmit" those bytes. While 
that does seem to exercise CherryPy's error detection properly, I believe it 
still fails to exercise the receipt and handling of raw invalid bytes, but it 
does provide a possible satisfactory mitigation to this issue.

--
messages: 352738
nosy: jaraco
priority: normal
severity: normal
status: open
title: Fix for issue30458 prevents crafting invalid requests

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38204] Cannot compile on RPi with optimizations

2019-09-18 Thread Ammar Askar



Ammar Askar  added the comment:

Hmm, I think this might be the following gcc/binutils bug: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847
https://sourceware.org/bugzilla/show_bug.cgi?id=20882

This might be a bit of a pain but could you try updating binutils and see if 
the problem persists.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38215] Do not import modules in star-import when all is not defined.



Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +15856
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16263

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38215] Do not import modules in star-import when all is not defined.



New submission from Serhiy Storchaka :

If __all__ is not defined in a module "from module import *" will import all 
keys from module.__dict__ which does not start with underscore. It can add 
undesired names to the current namespace. The common case is related to 
importing modules.

1. Importing modules which are imported in the original module for internal 
use. Every module usually imports several other modules, and since public 
module names are not underscored, they pollute the namespace of the module. To 
prevent leaking they names you need to import them under underscored name, like 
"import sys as _sys" (if you don't want to use __all__). This is cumbersome and 
makes the module code less readable.

2. Importing submodules. The problem is that the result depends on the history 
of imports. If you imported "module.submodule" before or if it was imported 
implicitly by other module, "from module import *" will import the "submodule" 
name. But if it was not imported before, "from module import *" will import the 
"submodule" name.

The proposed PR excludes modules from importing by star-import if __all__ is 
not defined.

Discussion on Python-ideas: 
https://mail.python.org/archives/list/python-id...@python.org/thread/AKWL7CRCCFACSITAH2NNFBL5BGRKLKJD/

--
components: Interpreter Core
messages: 352736
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Do not import modules in star-import when __all__ is not defined.
type: enhancement
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38205] Python no longer compiles without small integer singletons

2019-09-18 Thread Zachary Ware



Zachary Ware  added the comment:

Whoops :(.  Fixing this is beyond my C skill.  I'd rather not lose the easter 
egg, but if it can't be fixed properly then 
3ab61473ba7f3dca32d779ec2766a4faa0657923 should just be reverted.

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38204] Cannot compile on RPi with optimizations

2019-09-18 Thread Thomas Knox



Thomas Knox  added the comment:

I'll be more than happy to buy you an RPi to do testing on.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38204] Cannot compile on RPi with optimizations

2019-09-18 Thread Thomas Knox



Thomas Knox  added the comment:

pi@pi4b:~ $ gcc --version
gcc (Raspbian 8.3.0-6+rpi1) 8.3.0

pi@pi4b:~ $ ld --version
GNU ld (GNU Binutils for Raspbian) 2.31.1

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35696] remove unnecessary operation in long_compare()

2019-09-18 Thread Inada Naoki



Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35696] remove unnecessary operation in long_compare()

2019-09-18 Thread Inada Naoki



Inada Naoki  added the comment:


New changeset 42acb7b8d29d078bc97b0cfd7c4911b2266b26b9 by Inada Naoki 
(HongWeipeng) in branch 'master':
bpo-35696: Simplify long_compare() (GH-16146)
https://github.com/python/cpython/commit/42acb7b8d29d078bc97b0cfd7c4911b2266b26b9


--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)



Jason R. Coombs  added the comment:

> Should we open a separate issue to track (fixing) the regression?

Yes, I think so. The ticket I referenced mainly addresses an incompatibility 
that was introduced with Python 3.0, so is much less urgent than the one 
introduced more recently, so I believe it deserves a proper, independent 
description and discussion. I'll gladly file that ticket, tonight most likely.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS



STINNER Victor  added the comment:

It seems like the new regrtest design doesn't work as I expected.

Calling popen.kill() + popen.stdout.close() + popen.stderr.close() from a 
thread B does not always interrupt popen.communicate() in thread A.

See https://bugs.python.org/issue38207#msg352729 for an example on Linux where 
communicate() still blocks until all child processes complete.

I see different options:

* Revert changes to restore regrtest old design which didn't have these new 
issues

* Find a way to fix bpo-38207 on all platforms: be able to interrupt 
communicate() as soon as the process is killed and/or when all pipes are closed.

* Call communicate() with shorter timeout to workaround the blocking 
communicate() issue (bpo-38207).

* Maybe experiment asyncio which supports asynchronous subprocess.

asyncio subprocess uses overlapped operations which can be cancelled. So maybe 
it isn't affected by bpo-38207.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38207] subprocess: On Windows, Popen.kill() + Popen.communicate() is blocking until all processes using the pipe close the pipe



STINNER Victor  added the comment:

Hum, I see a similar behavior on Linux. Try attached communicate_close.py (I 
added newlines for readability):
---
vstinner@apu$ python3 communicate_close.py
process 1: pid 13089
process 1: process 2 spawned (pid 13090)
process 1: stdout pipe os.stat_result(st_mode=4480, st_ino=3107861, st_dev=12, 
st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=1568816000, 
st_mtime=1568816000, st_ctime=1568816000)
process 1: communicate with process 2 (pid 13090) ...

process 2: pid 13090
process 2: stdout os.stat_result(st_mode=4480, st_ino=3107861, st_dev=12, 
st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=1568816000, 
st_mtime=1568816000, st_ctime=1568816000)

process 3: pid 13092
process 3: stdout os.stat_result(st_mode=4480, st_ino=3107861, st_dev=12, 
st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=1568816000, 
st_mtime=1568816000, st_ctime=1568816000)

process 1 (thread): kill process 2 (pid 13090)
process 1 (thread): close process 2 stdout pipe (fd 3)

process 3: exit
process 1: communicate with process 2 (pid 13090) ... done in 5.1 sec
---

In process 1, communicate() does not complete immediately when the 
process 1 thread kills process 2 and closes process 2 stdout pipe.

communicate() only completes once process 3 completes.

The stdout file of process 2 and process 3 are the same file.

--
Added file: https://bugs.python.org/file48612/communicate_close.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38214] reduce API specs for objects with slots

2019-09-18 Thread Guido Imperiale


New submission from Guido Imperiale :

The documentation for the pickle module states, about the 3rd element of the 
tuple returned by __reduce__:



Optionally, the object’s state, which will be passed to the object’s 
__setstate__() method as previously described. If the object has no such method 
then, the value must be a dictionary and it will be added to the object’s 
__dict__ attribute.



This doesn't seem correct to me. It should instead read:



Optionally, the object’s state, which will be passed to the object’s 
__setstate__() method as previously described. If the object has no such 
method, then the value must be:

- for objects with only __dict__, a dictionary which will be used to update the 
object’s __dict__ attribute.
- for objects with only __slots__, a tuple of (None, {<__slots__ key>: , 
...})
- for objects with both __dict__ and __slots__, a tuple of ({<__dict__ key>: 
, ...}, {<__slots__ key>: , ...})



--
assignee: docs@python
components: Documentation
messages: 352728
nosy: crusaderky, docs@python
priority: normal
severity: normal
status: open
title: __reduce__ API specs for objects with __slots__
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)

2019-09-18 Thread Larry Hastings



Larry Hastings  added the comment:

Should we open a separate issue to track fixing the regression?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS



STINNER Victor  added the comment:

Oh wait, test_regrtest.test_multiprocessing_timeout() now also hangs on 
FreeBSD? :-(

AMD64 FreeBSD CURRENT Shared 3.8:
https://buildbot.python.org/all/#/builders/212/builds/226

running: test_regrtest (24 min 52 sec)
0:32:54 load avg: 0.26 [423/423/1] test_regrtest crashed (Exit code 1)
Timeout (0:25:00)!
Thread 0x000800ac (most recent call first):
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/selectors.py", 
line 415 in select
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", 
line 1866 in _communicate
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", 
line 1024 in communicate
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", 
line 491 in run
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/test_regrtest.py",
 line 504 in run_command
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/test_regrtest.py",
 line 529 in run_python
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/test_regrtest.py",
 line 676 in run_tests
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/test_regrtest.py",
 line 1174 in test_multiprocessing_timeout
  File 
"/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/unittest/case.py",
 line 633 in _callTestMethod

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Spread a statement over various lines

2019-09-18 Thread Manfred Lotz

On Wed, 18 Sep 2019 08:30:08 +0200
Peter Otten <__pete...@web.de> wrote:

> Manfred Lotz wrote:
> 
> > I have a function like follows
> > 
> > def regex_from_filepat(fpat):
> > rfpat = fpat.replace('.', '\\.') \
> >   .replace('%', '.')  \
> >   .replace('*', '.*')
> > 
> > return '^' + rfpat + '$'
> > 
> > 
> > As I don't want to have the replace() functions in one line my
> > question is if it is ok to spread the statement over various lines
> > as shown above, or if there is a better way?  
> 
> Sometimes you can avoid method-chaining:
> 
> >>> REP = str.maketrans({".": "\\.", "%": ".", "*": ".*"})
> >>> def regex_from_filepat(fpat):  
> ... return fpat.translate(REP)
> ... 
> >>> regex_from_filepat("*foo.%")  
> '.*foo\\..'
> 

Very interesting. Thanks for this.

> Generally speaking a long statement may be a hint that there is an 
> alternative spelling.
> 
> 

I'll keep it in my mind.



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

[issue36274] http.client cannot send non-ASCII request lines

2019-09-18 Thread Sviatoslav Sydorenko



Sviatoslav Sydorenko  added the comment:

@xtreak the encoded null-byte test would be an extra test case to consider. It 
is reasonable to test as many known invalid sequences as possible. Changing 
that byte to encoded notation would just replace one test with another 
effectively changing the semantics of it.

To me, it's quite weird that it's considered a CVE at all: it's happening on 
the client side and it doesn't prevent the user from just feeding the proper 
bytes right into the socket so why overcomplicate things?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



miss-islington  added the comment:


New changeset 1a3a48ddaf41dff3c0fcedcfe7ec0940158c568d by Miss Islington (bot) 
in branch '3.7':
bpo-38203: faulthandler.dump_traceback_later() is always available (GH-16260)
https://github.com/python/cpython/commit/1a3a48ddaf41dff3c0fcedcfe7ec0940158c568d


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



STINNER Victor  added the comment:


New changeset 064e1e384120635330493abf300b1113eadd904c by Victor Stinner in 
branch '3.8':
bpo-38203: faulthandler.dump_traceback_later() is always available (GH-16260)
https://github.com/python/cpython/commit/064e1e384120635330493abf300b1113eadd904c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



Change by miss-islington :


--
pull_requests: +15855
pull_request: https://github.com/python/cpython/pull/16261

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



Change by STINNER Victor :


--
pull_requests: +15854
pull_request: https://github.com/python/cpython/pull/16260

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38203] regrtest fails to stop test_multiprocessing_spawn worker process



STINNER Victor  added the comment:


New changeset 0a963fbc9c4cf4569f1eadaa2aa1229bb0081256 by Victor Stinner in 
branch 'master':
bpo-38203: faulthandler.dump_traceback_later() is always available (GH-16249)
https://github.com/python/cpython/commit/0a963fbc9c4cf4569f1eadaa2aa1229bb0081256


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38070] visit_decref(): add an assertion to check that the object is not freed



STINNER Victor  added the comment:

Ok, I pushed the most important changes that I wanted to push. I close the 
issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38070] visit_decref(): add an assertion to check that the object is not freed



STINNER Victor  added the comment:


New changeset 47bbab9f76735acc1991e541d12fd18be6b13b16 by Victor Stinner in 
branch '3.8':
[3.8] bpo-38070: Py_FatalError() logs runtime state (GH-16258)
https://github.com/python/cpython/commit/47bbab9f76735acc1991e541d12fd18be6b13b16


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38213] sys.maxsize returns incorrect docstring.

2019-09-18 Thread Steven D'Aprano



Steven D'Aprano  added the comment:

This is not a bug. ``sys.maxsize`` is just an int instance, and it has no 
docstring itself. When you look up ``sys.maxsize.__doc__``, or call 
``help(sys.maxsize)``, the ordinary inheritance rules apply and you get the 
class docstring.

There is nothing magical about ``sys.maxsize``. You will get the same result 
for ``help(2147483647)`` or ``help(1234)`` or any other int. So you are getting 
the correct docstring, the one which belongs to the class.

I'm going to close this as "not a bug", but if you believe that you have a good 
reason to treat this as a bug, please reply. If your argument is convincing, we 
can re-open the ticket.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38213] sys.maxsize returns incorrect docstring.

2019-09-18 Thread Akash Shende



Akash Shende  added the comment:

Yes. I checked that. Same for sys.maxunicode

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38213] sys.maxsize returns incorrect docstring.



Karthikeyan Singaravelan  added the comment:

sys.maxsize returns an integer so essentially sys.maxsize.__doc__ is giving 
docs for int.__doc__. help(sys) to get to maxsize would help.

maxsize -- the largest supported length of containers.


python3
Python 3.8.0b4 (v3.8.0b4:d93605de72, Aug 29 2019, 21:47:47)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.maxsize)
9223372036854775807
>>> print(sys.maxsize.__doc__)
int([x]) -> integer
int(x, base=10) -> integer

Convert a number or string to an integer, or return 0 if no arguments
are given.  If x is a number, return x.__int__().  For floating point
numbers, this truncates towards zero.

If x is not a number or if base is given, then x must be a string,
bytes, or bytearray instance representing an integer literal in the
given base.  The literal can be preceded by '+' or '-' and be surrounded
by whitespace.  The base defaults to 10.  Valid bases are 0 and 2-36.
Base 0 means to interpret the base from the string as an integer literal.
>>> int('0b100', base=0)
4


>>> print(int.__doc__)
int([x]) -> integer
int(x, base=10) -> integer

Convert a number or string to an integer, or return 0 if no arguments
are given.  If x is a number, return x.__int__().  For floating point
numbers, this truncates towards zero.

If x is not a number or if base is given, then x must be a string,
bytes, or bytearray instance representing an integer literal in the
given base.  The literal can be preceded by '+' or '-' and be surrounded
by whitespace.  The base defaults to 10.  Valid bases are 0 and 2-36.
Base 0 means to interpret the base from the string as an integer literal.
>>> int('0b100', base=0)
4

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38213] sys.maxsize returns incorrect docstring.

2019-09-18 Thread Akash Shende



New submission from Akash Shende :

>>> import sys
>>> print(sys.maxsize.__doc__)
int([x]) -> integer
int(x, base=10) -> integer

Convert a number or string to an integer, or return 0 if no arguments
are given.  If x is a number, return x.__int__().  For floating point
numbers, this truncates towards zero.

If x is not a number or if base is given, then x must be a string,
bytes, or bytearray instance representing an integer literal in the
given base.  The literal can be preceded by '+' or '-' and be surrounded
by whitespace.  The base defaults to 10.  Valid bases are 0 and 2-36.
Base 0 means to interpret the base from the string as an integer literal.
>>> int('0b100', base=0)
4

--
components: Library (Lib)
messages: 352716
nosy: akash0x53
priority: normal
severity: normal
status: open
title: sys.maxsize returns incorrect docstring.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37904] Suggested edit to Python Tutorial - Section 4



Change by Eric V. Smith :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37904] Suggested edit to Python Tutorial - Section 4



Eric V. Smith  added the comment:


New changeset c47c8ba2969c9faf1c036b3dc4b0a5cf0d3aa0cc by Eric V. Smith (Miss 
Islington (bot)) in branch '2.7':
bpo-37904: Edition on python tutorial - section 4 (GH-16169) (GH-16236)
https://github.com/python/cpython/commit/c47c8ba2969c9faf1c036b3dc4b0a5cf0d3aa0cc


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37904] Suggested edit to Python Tutorial - Section 4



Eric V. Smith  added the comment:


New changeset 8b907a8875d1b22d8f060dee9430cc82d471e86b by Eric V. Smith (Miss 
Islington (bot)) in branch '3.7':
bpo-37904: Edition on python tutorial - section 4 (GH-16169) (GH-16235)
https://github.com/python/cpython/commit/8b907a8875d1b22d8f060dee9430cc82d471e86b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37904] Suggested edit to Python Tutorial - Section 4



Eric V. Smith  added the comment:


New changeset 7a2f68776a77c782c0abf40dc9e3fb687787e730 by Eric V. Smith (Miss 
Islington (bot)) in branch '3.8':
bpo-37904: Edition on python tutorial - section 4 (GH-16169) (GH-16234)
https://github.com/python/cpython/commit/7a2f68776a77c782c0abf40dc9e3fb687787e730


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Spread a statement over various lines

2019-09-18 Thread Manfred Lotz

On Wed, 18 Sep 2019 09:52:21 +0200
Wolfgang Maier  wrote:

> On 17.09.19 20:59, Manfred Lotz wrote:
> > I have a function like follows
> > 
> > def regex_from_filepat(fpat):
> > rfpat = fpat.replace('.', '\\.') \
> >   .replace('%', '.')  \
> >   .replace('*', '.*')
> > 
> > return '^' + rfpat + '$'
> > 
> > 
> > As I don't want to have the replace() functions in one line my
> > question is if it is ok to spread the statement over various lines
> > as shown above, or if there is a better way?
> >   
> 
> One problem with explicit line continuation using \ is that it is
> dependent on the backslash being the last character on the line, i.e.
> a single space at the end of the line will result in a SyntaxError.
> This is why implicit line continuation relying on opened parentheses,
> brackets or curly braces is often preferred, and recommended over
> backslash continuation in PEP8
> (https://www.python.org/dev/peps/pep-0008/#maximum-line-length).
> To use implicit line continuation you could either introduce extra
> surrounding parentheses as suggested by others, or you may make use
> of the parentheses you have already, like so:
> 
> def regex_from_filepat(fpat):
> rfpat = fpat.replace(
> '.', '\\.'
> ).replace(
> '%', '.'
> ).replace(
> '*', '.*'
> )
> 
> return '^' + rfpat + '$'
> 
> 

Thanks for showing. Good to be aware of this possiblity. So, it seems
it doesn't hurt to read PEP8.

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

[issue38070] visit_decref(): add an assertion to check that the object is not freed



Change by STINNER Victor :


--
pull_requests: +15853
pull_request: https://github.com/python/cpython/pull/16258

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Obtain the file's path.

2019-09-18 Thread Cameron Simpson

On 18Sep2019 03:36, eryk sun  wrote:

On 9/17/19, Cameron Simpson  wrote:

If you just want this for your running program's internals this may not
matter, but if you're recording the result somewhere then abspath might
get you a more "stable" path in the above scenario.

If a path has ".." components, the abspath() result may be wrong if it
resolves them by removing a parent symlink. The absolute() method of
pathlib.Path does this right by retaining ".." components.

   >>> os.path.abspath('/foo/symlink/../bar')
   '/foo/bar'

   >>> pathlib.Path('/foo/symlink/../bar').absolute()
   PosixPath('/foo/symlink/../bar')

abspath() is also the wrong choice if we're computing the target path
for a relative symlink via relpath(). A relative symlink is evaluated
from the parsed path of its parent directory.

For the record, I agree entirely with Eryk here.

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

[issue38212] test_multiprocessing_spawn: test_queue_feeder_donot_stop_onexc() failed on x86 Windows7 3.x



New submission from STINNER Victor :

x86 Windows7 3.x:
https://buildbot.python.org/all/#/builders/58/builds/3015

If I recall correctly, this buildbot is known to be slow.

It sounds like a race condition.

ERROR: test_queue_feeder_donot_stop_onexc 
(test.test_multiprocessing_spawn.WithProcessesTestQueue)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py",
 line 1132, in test_queue_feeder_donot_stop_onexc
self.assertTrue(q.get(timeout=1.0))
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\queues.py",
 line 108, in get
raise Empty
_queue.Empty


Extract of the test:

def test_queue_feeder_donot_stop_onexc(self):
# bpo-30414: verify feeder handles exceptions correctly
if self.TYPE != 'processes':
self.skipTest('test not appropriate for {}'.format(self.TYPE))

class NotSerializable(object):
def __reduce__(self):
raise AttributeError
with test.support.captured_stderr():
q = self.Queue()
q.put(NotSerializable())
q.put(True)
# bpo-30595: use a timeout of 1 second for slow buildbots
self.assertTrue(q.get(timeout=1.0))   # <= FAIL HERE =
close_queue(q)

...


Hum, "bpo-30595: use a timeout of 1 second for slow buildbots" sounds like this 
test depends on time which is bad for reliable tests. Would it be possible to 
use a more reliable synchronization primitive?

If no solution is found, the workaround is to use a timeout of 60 seconds 
instead of just 1 second...

--
components: Tests
messages: 352712
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn: test_queue_feeder_donot_stop_onexc() failed 
on x86 Windows7 3.x
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Obtain the file's path.

2019-09-18 Thread Pankaj Jangid

Cameron Simpson  writes:

> On 17Sep2019 15:09, Hongyi Zhao  wrote:
>>See the following two methods for obtaining the file's path:
>>
>>os.path.realpath(file)
>>or
>>os.path.abspath(os.path.expanduser(file))
>>
>>Which is more robust?
>
> My inclination is often to use abspath, because it may better express
> the "intent" of the filename by not "undoing" the effects of symlinks.
>
> So abspath(expanduser("~/media/foo.mp4")) might expand to
> "/home/cameron/media/foo.mp4".
>
> Conversely, realpath(expanduser("~/media/foo.mp4")) might expand to
> "/raid_volume/cameron/media/foo.mp4".
>
> You might ask yourself, why do you need to know the absolute path at
> all? A relative path is usually just fine; it isn't like it won't work
> unless you use it from another directory.
>
Somewhat related to the OP's question.

So what is a good strategy in an application? I am now inclined to use
relative path and working directory both. And when there is change of
runtime context just change the working directory and assemble the
absolute path at runtime.

And to save the working directory use "abspath" as suggested by Cameron.

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

[issue36274] http.client cannot send non-ASCII request lines