[issue38996] introduction of default values for collection.namedtuple

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez :

Hello,
I had the requirement to make excessive use of named tuples in an extended way. 
The applications are variable data sets with optional items. Typical in 
protocol dat a units, or e.g. mixed abstract filesystem types for heterogeneous 
file system types including URL and UNC.

As I saw the required changes are a couple of lines which I see as harmless. 
The implementation is available for Python2.7 and Python3.5+ in the project 
namedtupledefs, which is the patched code extracted from the *collections*.

The detailed descriptions for both versions are available at:
Python3: https://namedtupledefs3.sourceforge.io/
Python3: https://namedtupledefs.sourceforge.io/
Python2: https://namedtupledefs2.sourceforge.io/

Checked in PyPi + Sourceforge + github - the links are in the documents.

https://github.com/ArnoCan/namedtupledefs3/
https://github.com/ArnoCan/namedtupledefs2/
https://github.com/ArnoCan/namedtupledefs/

https://pypi.org/project/namedtupledefs[23]/

My proposal is to introduce the changes. It would be great for Python2.7 too, 
before the EOL.

WKR

WKR

--
components: Library (Lib)
files: namedtupled-uml-patches.jpg
messages: 358002
nosy: acue
priority: normal
severity: normal
status: open
title: introduction of default values for collection.namedtuple
type: enhancement
versions: Python 2.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48765/namedtupled-uml-patches.jpg

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

[issue38718] query of global metadata options delivers error messages even when successful

[Arno-Can Uestuensoez]

Change by Arno-Can Uestuensoez :


--
title: query of global options delivers error messages even when successful -> 
query of global metadata options delivers error messages even when successful

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

[issue38718] query of global options delivers error messages even when successful

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez :

The 'setup.py' interface offers some global options, which could be queried. 
For example among numerous others the 'classifiers'.

The current implementation displays for example for the following call::

   python setup.py --description

The result::

  (3.8.0) $ python setup.py --description
   
   usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
  or: setup.py --help [cmd1 cmd2 ...]
  or: setup.py --help-commands
  or: setup.py cmd --help

   error: no commands supplied
   (3.8.0) $ echo $?
   1
   (3.8.0) $


I would like to propose some minor enhancements here.

1. The error message is here an error itself, because the
   query was flawless successful.

   This is due to the implementation by relying on an
   exception for the termination condition, when no
   command was given. This is for the global query options
   for the global metadata perfectly allright.

   Thus the error message must not occur.

2. The resulting exit code of '1' is due to the same execption
   for the missing command.

   Thus the exit code must be '0' on Posix based and alike
   systems.

3. The usage message, which is also based on a private method,
   is basically an error itself. This is due to the fact, that
   actually nothing has failed.

   Thus the usage message must not be displayed here.

4. I also would like to propose some layout enhancements at
   this occasion.

   The  value of the queried attribute - here the description,
   should be separated by a .
   E.g. by 'USAGE', or 'global_+usage()' within 'distutils.core'.

   The resulting layout and exit value  would be:

  (3.8.0) $ python setup.py --description

  

  (3.8.0) $ echo $?
  0
  (3.8.0) $

--
components: Distutils
messages: 356122
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: query of global options delivers error messages even when successful
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

[issue38709] distutils - setuptools - alias command removes comments from setup.cfg

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

Current related issues are:

issue 38714
issue 38711
issue 38709

--

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

[issue38711] setup parameter 'distclass' ignored for configuration files

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

Current related issues are:

issue 38714
issue 38711
issue 38709

--

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

[issue38714] setup command alias erroneous for names with hyphens

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

Current related issues are:

issue 38714
issue 38711
issue 38709

--

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

[issue38714] setup command alias erroneous for names with hyphens

[Arno-Can Uestuensoez]

Change by Arno-Can Uestuensoez :


--
type:  -> behavior

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

[issue38714] setup command alias erroneous for names with hyphens

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez :

Even though this involves 'setuptools', I write this issue here because of the 
tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' 
parameter.

The aliases as represented by the command 'setup.py alias' are internally 
treated by 'setuptools' as options.

See code:

   setuptools.dist._parse_config_files()
   in Python-3.8.0:  line 604 - line 608

The consequence is the processing of the standard replacement of hyphens by 
underscores for alias names.

The resulting behaviour is here three folded.


1. The technical behaviour of the alias replacement for valid
   aliases id flawless.

2. The technical behaviour of the display representation for alias
   names containing a hyphen is erroneous.

   For example:

  python setup.py alias my-alias alias

   Results flawless in:

  [aliases]
  my-alias = alias

   The display:

  python setup.py alias

   is erroneous:

  (3.8.0)$ python setup.py alias
  running alias
  Command Aliases
  ---
  setup.py alias my_alias alias

   because the modified internal values are displayed - with replaced
   hyphens in alias names.


3. The call of the alias as command replacement is erroneous in general:

  3.0. the original call is flawless:

 (3.8.0)$ python setup.py alias

running alias
Command Aliases
---
setup.py alias my_alias alias


  3.1. the call by defined literal alias is erroneous:

(3.8.0)$ python setup.py my-alias

invalid command name 'my-alias'

  3.2. the call by modified alias is also erroneous,
 as though the alias is not detected, resulting here in the
 display of an empty list:

(3.8.0)$ python setup.py my_alias

running alias
Command Aliases
---


Another example to mention here is the acceptance of alias names including 
spaces, which prbably should be suppressed, because as far as I can see command 
name could not contain spaces at all.

E.g. the alias 'ls -l' is handeled erroneous in accordance to the previous 
remarks, but is basically not valid at all.

   (3.8.0)$ python setup.py 'ls -l' alias

Results in the flawless configuration entry:

   [aliases]
   ls -l = alias

The erroneous display:

(3.8.0)$ python setup.py alias

running alias
Command Aliases
---
setup.py alias ls _l alias

The behaviour should be fixed to be consistent to allow valid names and reject 
others. The accepted names should be fully functional, and displayed and made 
available for custom representation literally as provided by the user. A simple 
reverse-replacement is here not reliable.

The alternative of the caching of the original input is currently not possible 
for a simple public command API due to the lack of fully customization of the 
'distclass' see issue Issue38711. Thus this seems currently to require a 
complete second scan including eventually selected user files as eventually 
selected by the provided call parameters.

--
components: Distutils
messages: 356094
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: setup command alias erroneous for names with hyphens
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

[issue38711] setup parameter 'distclass' ignored for configuration files

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez :

Even though this involves 'setuptools', I write this issue here because of the 
tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' 
parameter.

The central API 'setup()' - 'setuptools.init.setup()' - provides the parameter 
'distclass='. This allows to define a custom 'Distribution' 
class to be used as a replacement of the 'Distribution' class.

First of all for an ordinary user it is not clear whether 
'distutils.dist.Distribution', and/or 'setuptools.dist.Distribution' is 
replaced. Even more confusing, the 'self' parameter is cross-passed between the 
classes by using a derived instance provided by:

   _Distribution = get_unpatched(distutils.core.Distribution)

The second is the integration of the initialization bootstrap, which completely 
ignores the user defined custom class. The main API 'setup()' defined in 
'setuptools.init.setup()' calls first the local private function 
'_install_setup_requires' - 'setuptools.init._install_setup_requires()', which 
calls the instanciates the hardcoded 'distutils.core.Distribution()', and 
therein calls the methods 'dist.parse_config_files()', and 
'dist.fetch_build_eggs()', which - as far as I can see - finally prohibits the 
use of a custom version of these, or easily add another one.

The consequence is that the configuration file parameters could basically not 
be fully customized by the custom class.

The association with the parameter 'distclass' for me - and I guess for others 
too - is that the 'complete' 'Distribution' class could be customized by this 
API. But this is currently not possible. So, even though I see the problems 
that can arise from the use of the modified 'self' parameter - I would propose 
the application of the 'distclass' for the initial bootstrap by the read of the 
configuration file too. In case this prooves too risky - due to 'distutils' 
coupling with 'setuptools', at least a parameter for the initial read of the 
configuration files should be offered.


The best of course would be the fusion of both parts, probably in a future 
release.

I have tested 3.8.0, but as far as I can see this is the case for all releases.

PS: I am writing now another issue for the 'alias' command and going add the 
number as an possible example for the required custom class.

--
components: Distutils
messages: 356090
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: setup parameter 'distclass' ignored for configuration files
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

[issue38709] distutils - setuptools - alias command removes comments from setup.cfg

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez :

The command 'alias' rewrites the configuration file completely when a new alias 
is added. The default file is 'setup.cfg'. All comments of the original file 
are stripped off before, though the new 'setup.cfg' does not contain any 
comments.

The comments should be kept literally, just the section '[aliases]' should be 
modified.

The comments in the section '[aliases]' should be basically kept, even though a 
manual modification by the user could cause problems e.g. in case of deleting 
an alias by the 'setup.py alias' command.

Anyhow, at least the only section modified should - must - be the '[aliases]' 
section.

Even though this involves 'setuptools', I write this issue here because of the 
tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' 
parameter.

I have tested 3.8.0, but as far as I can see this is the case for all releases.

--
components: Distutils
messages: 356088
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils - setuptools - alias command removes comments from setup.cfg
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

[issue38262] Mixins - super calls in bases of multiple-inheritance with different parameters

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

Fix two typos in my previous post:

#>>>
This basic diamond structure represents the call signatures:

   I:   for D
   II:  for B and C
   III: for A
#<<<

and 

#>>>
The current implementation changes the routed method calls to the following 
call signatures:

   I:   for D
   II:  for B
   III: for C and A
#<<<

--

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

[issue38262] Mixins - super calls in bases of multiple-inheritance with different parameters

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

Hi,
first of all thank you both for the fast reply.

The point is here, that the call routing and the parameter passing are 
intermixed. The MRO defines the call order, but does not define a signature 
change for the call within one inheritance layer.

All articles I found including the mentioned 
blog-post(https://rhettinger.wordpress.com/2011/05/26/super-considered-super/) 
deal with the call order. But as far as I can see all imply silently the 
correctness of the call signatures defined by the derived classes - see also 
https://en.wikipedia.org/wiki/Object-oriented_programming#Polymorphism.

Well, this is so common for me since about 1990, that I even have to think 
about how to explain.

The simple diagram of the basic 4-class diamond depicts the call routing and 
the call signatures - see
https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem.

The class hierarchy is

A
|
+---+---+
|   |
B   C
|   |
+---+---+
|
D

with the classes

   A or more precise A(object)
   B(A)
   C(A)   
   D(B, C)
   
The resulting call routing MRO/C3 linearization - 
https://en.wikipedia.org/wiki/C3_linearization - is:

   D -> B -> C -> A

See https://en.wikipedia.org/wiki/Multiple_inheritance#Mitigation, and 
https://www.python.org/download/releases/2.2.3/descrintro/#mro.

This basic diamond structure represents the call signatures:

   I:   for D
   II:  for B and C
   III: for D

The call signature of a given method interface for the implementation of class 
D has to be equally defined by the classes B *AND* C! Which means has to be the 
same - ignoring defaults here. This is how OO works. Though the called 
signatures of the classes B *AND* C has to be identical too! Which is 
completely independent from the dynamic call order - but defined by the static 
inheritance graph.

This is in particular true due to the fact, that the single inheritance call 
signatures has to be identical too

   D(B).mthX() == D(C).mthX()

or in general - related to the call signatures the following interface calls 
are defined to have equal call parameters(ignoring defaults here):

   D(B,C).mthX() == D(C,D).mthX() == D(B).mthX() == D(C).mthX()

Anything else is an error.

The current implementation changes the routed method calls to the following 
call signatures:

   I:   for D
   II:  for B
   III: for C and D

So this is not just an inconvenience as you mentioned. It is simply a bug.

--
resolution: not a bug -> postponed
Added file: https://bugs.python.org/file48625/mixin_C_is_B0A1.py

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

[issue38262] Mixins - super calls in bases of multiple-inheritance with different parameters

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

Hey,
first of all thank you for the fast reply.

Your examples reinforce exactly my issue. I prefer the KISS principle in 
providing isolated use-cases for transparency without extras. Which is 
seperated reduced flat calls only.

The other point is, I develop and test shared code for  Python2.7(which will be 
out there for a while...) and Python3.5+, thus prefer shared syntax whenever 
possible. The "super()" interface has changed, using the shared syntax from 
2.7.16:

- Python2.7.16:  super(type[, object-or-type])
- Python3.7.4:   super([type[, object-or-type]])

The test of your code with Python 2.7.16 requires modification.


You are right with the case 4, this is the actual issue related to the MRO and 
the parameter passing. I did not ask for the number of calls of the common base 
classes, but the passing of the parameters. The call order/MRO is OK, but I 
doubt the passed parameter signatures. My basic assumption here is that the 
call routing by MRO should or even must not be intermixed with the actually 
passed call parameters.

So I added the output of your example for "mixin_tests2.py" for Python3.6.5, 
tested for Python3.7.0 too.

#--
(3.6.5) [acue@lap001 test-modified]$ python mixin_tests2.py 

==
C MRO: ['C', 'A_With_Arg', 'B_With_Arg', 'MyBase', 'object']
C:C True
A_With_Arg:C True
call super().__init__ with argument
B_With_Arg:C True
call super().__init__ with argument
MyBase received 1 arguments
TypeError('object.__init__() takes no parameters',)
==
C MRO: ['C', 'B_With_Arg', 'A_With_Arg', 'MyBase', 'object']
C:C True
B_With_Arg:C True
call super().__init__ with argument
A_With_Arg:C True
call super().__init__ with argument
MyBase received 1 arguments
TypeError('object.__init__() takes no parameters',)
==
C MRO: ['C', 'A_With_Arg', 'B_Without_Arg', 'MyBase', 'object']
C:C True
A_With_Arg:C True
call super().__init__ with argument
B_Without_Arg:C True
call super().__init__ without argument
MyBase received 0 arguments
success
==
C MRO: ['C', 'B_Without_Arg', 'A_With_Arg', 'MyBase', 'object']
C:C True
B_Without_Arg:C True
call super().__init__ without argument
A_With_Arg:C False
success
(3.6.5) [acue@lap001 test-modified]$ 

#---

Or reduced to the focus of the actual issue and depicted the actual passed 
parameters. See the following "Case 4 - same as mixin_C_is_B0A1" for the 
essential question.

==

Case 0 - same as mixin_C_is_A1B1

   A_With_Arg:C True
   B_With_Arg:C True

   TypeError('object.__init__() takes no parameters',)

  Resulting in:
 C.__init__(True)
A_With_Arg.__init__(True)
   B_With_Arg.__init__(True)
  MyBase.__init__(True)
 object.__init__(True)

Comment:
  The TypeError is expected and OK.

==

Case 1 - same as mixin_C_is_B1A1

  B_With_Arg:C True
  A_With_Arg:C True

  TypeError('object.__init__() takes no parameters',)

  Resulting in:
 C.__init__(True)
B_With_Arg.__init__(True)
   A_With_Arg.__init__(True)
  MyBase.__init__(True)
 object.__init__(True)

Comment:
  The TypeError is expected and OK.

==

Case 2 - same as mixin_C_is_A1B0

  A_With_Arg:C True
  B_Without_Arg:C True

  MyBase received 0 arguments
  success

Comment:
  The success is expected and OK.

  The actual call due to MRO is:

 C(A_With_Arg(), B_Without_Arg())

  Resulting in:
 C.__init__(True)
A_With_Arg.__init__(True)
   B_Without_Arg.__init__(True)
  MyBase.__init__(False)
 object.__init__()

  Remark: I assume, that the single call of "object.__init__()" is here 
intentional.
  
==

Case 4 - same as mixin_C_is_B0A1

  B_Without_Arg:C True
  A_With_Arg:C False

  success

Comment:
  The success is NOT expected and as far as I can see should be treated as an 
Error so NOK.

  The actual call is:

 C(B_Without_Arg(), A_With_Arg())

  Resulting in:
 Seemingly the behaviour is:

 C.__init__(True)
B_Without_Arg.__init__(True)
   A_With_Arg.__init__(False)

 This means the call of "super(B, self).__init__()" within 
 "B.__init__()" defines the call parameters of "A.__init__()". 
 Even though I expect the call order as routed by the MRO, 
 I did not expected the parameters of A to be passed from the
 sibling class B, but as defined by the base class C. Thus the
 following:

 C.__init__(True)
B_Without_Arg()
   A_With_Arg.__init__(True)
  object.__init__(True)# this is the behav

[issue38262] Mixins - super calls in bases of multiple-inheritance with different parameters

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez :

The attached examples evaluate inheritance by mixins with different
arameters and in different orders.

The 'super()' call propagates the call resolution by definition
to the next level, and cares about multiple inheritance as well
as mixins. Where mixins are the superior case as they represent multiple 
inheritance in any case due to the common top class 'object'.
So far perfect.

The oddity I came around is the simple case of mixins with different
parameters, where both are derived from 'object'. It is obvious, that such a 
class has to comply to the parents call interface - here object - when to be 
used standalone. BUT when I ignore this and set intentionally a parameter - for 
test-purposes of mixins only - the resolution algorithm seems to normalize both 
for the final call without parameters -  as soon as one of the mixins is a 
non-parameter call. This is independent from the inheritance order for the 
derived class.

I expect for the rightmost of the inherited classes to pass the parameters 
literally.

When both classes have parameters, the parameter is passed to 'object' and 
correctly raises an exception.

#--

[acue@lap001 mixin-order-with-different-params]$ ./call.sh 



different parameters for mixin classes at diffeent positions

  0: super() method signature has no param
  1: super() method signature has param

final top-class is 'object()' which does not know the 
parameter - here 'propagate'



#---
#
# CALL: mixin_C_is_A1B0.py
#
B:C
A:C
C:C

#---
#
# CALL: mixin_C_is_A1B1.py
#
Traceback (most recent call last):
  File "mixin_C_is_A1B1.py", line 24, in 
c=C(True)
  File "mixin_C_is_A1B1.py", line 20, in __init__
super(C, self).__init__(propagate)
  File "mixin_C_is_A1B1.py", line 4, in __init__
super(A, self).__init__(propagate)
  File "mixin_C_is_A1B1.py", line 12, in __init__
super(B, self).__init__(propagate)
TypeError: object.__init__() takes no parameters

#---
#
# CALL: mixin_C_is_B0A1.py
#
A:C
B:C
C:C

#---
#
# CALL: mixin_C_is_B1A1.py
#
Traceback (most recent call last):
  File "mixin_C_is_B1A1.py", line 25, in 
c=C(True)
  File "mixin_C_is_B1A1.py", line 20, in __init__
super(C, self).__init__(propagate)
  File "mixin_C_is_B1A1.py", line 12, in __init__
super(B, self).__init__(propagate)
  File "mixin_C_is_B1A1.py", line 4, in __init__
super(A, self).__init__(propagate)
TypeError: object.__init__() takes no parameters

[acue@lap001 mixin-order-with-different-params]$ 


#--


Is this intentional?

If so, what is the explanation? - Because it potentially hides bugs for later 
debugging...

--
files: tests.tar.gz
messages: 353062
nosy: acue
priority: normal
severity: normal
status: open
title: Mixins - super calls in bases of multiple-inheritance with different 
parameters
type: compile error
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file48621/tests.tar.gz

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

[issue35334] urllib3 fails with type error exception, when cannot reach PyPI - urllib3.util.retry

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

In order to avoid further confusion (github:  #1486):
 
> This is the wrong bug tracker for urllib3. The urllib3 package is not part of 
> Python's standard library. 
=> OK.

# As xtreak pointed out, it's not even a bug in urllib3 or pip. Debian ships a 
modified and patched version of pip that uses an incompatible version of 
urllib3. Please follow up on the Debian bug tracker,
=> not the issue as I posted it. The file is: urllib3.util.retry, So NOK, see 
issue-text:
> My proposal is to add the inplace operator to the class *Reply* with the 
> default assignment in case of an type error and display an error message.
> This is still not really the correct solution, but resolves a lot of 
> confusion by required interpretation of the exception.

Anyhow, going to issue a bug report to debian.

--
pull_requests: +10033

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

[issue35334] urllib3 fails with type error exception, when cannot reach PyPI - urllib3.util.retry

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

@christian.heimes , @xtreak

Thanks, just for documentation, hope this is the right place - putting one to 
debian later:

See: issue - 1486: https://github.com/urllib3/urllib3/issues/1486

for file: 
https://github.com/urllib3/urllib3/blob/master/src/urllib3/util/retry.py

Rem.: The issue is about the originator of the exception - which is not 
necessarily the original cause.

--

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

[issue35334] urllib3 fails with type error exception, when cannot reach PyPI - urllib3.util.retry

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez  added the comment:

@xtreak
I didn't checked the source of the assignment of the instance of *Retry* to 
*self.total*. For me it was important to get the display of the actual source 
of the failure, which is the failed access to PyPI. Thus my proposal, just to 
intercept the error, display a bug-report, and display the quite good error 
message for the failed PyPI access already contained in the code. 

Thus the intention to replace:

>  File 
> "/usr/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/util/retry.py",
>  line 315, in increment
>
>total -= 1
>
> TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'

by:

> Retrying (Retry(total=1, connect=None, read=None, redirect=None)) after 
> connection broken by 
> 'ConnectTimeoutError(requests.packages.urllib3.connection.VerifiedHTTPSConnection
>  object at/
>
>  Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after 
> connection broken by 
'ConnectTimeoutError(requests.packages.urllib3.connection.VerifiedHTTPSConnection
 object at/
>
>  Could not find a version that satisfies the requirement evdev (from 
> versions: )
>
> No matching distribution found for evdev
>
> WARNING : Pip failed to install software!

Optionally with an additional error message for the faulty assignment to  the 
member *total*. But this is actually just a repetition counter, so even the 
integer replacement(>=1) should be OK. If an application uses it - wrongly - as 
a reference pointer, this will fail than immediately and the app recognises 
it's error straight away.

--

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

[issue35334] urllib3 fails with type error exception, when cannot reach PyPI - urllib3.util.retry

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez :

Hi,
I am using the installation script *adafruit-pitft.sh* which tries to apply 
*urllib3* which itself tries to install nested dependencies,
here *evdev* from PyPI.

When the installation is offline - e.g. by internal mirror of debian/raspbian - 
PyPI is not accessible. The code fails than by an type error
exception:

> adafruit-pitft.sh # or pitft.sh 
> https://github.com/adafruit/Raspberry-Pi-Installer-Scripts/blob/master/adafruit-pitft.sh
>
> ...
> 
>   _stacktrace=sys.exc_info()[2])
>  File "/usr/share/python-wheels/urllib3-1.13.1-py2.py3 
> none-any.whl/urllib3/util/retry.py", line 228, in increment
>
>total -= 1
>
> TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'

For the current distribution(based on debian-9.6.0/stretch):

>  File 
> "/usr/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/util/retry.py",
>  line 315, in increment
>
>total -= 1
>
> TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'

See also: 
https://stackoverflow.com/questions/37495375/python-pip-install-throws-typeerror-unsupported-operand-types-for-retry


The following - dirty *:) - patch enables a sounding error trace:

# File: retry.py - in *def increment(self, ..* about line 315
# original: total = self.total

# patch: quick-and-dirty-fix
# START:
if isinstance(self.total, Retry):
self.total = self.total.total

if type(self.total) is not int:
self.total = 2 # default is 10
# END:

# continue with original:
total = self.total

if total is not None:
total -= 1

connect = self.connect
read = self.read
redirect = self.redirect
cause = 'unknown'
status = None
redirect_location = None

if error and self._is_connection_error(error):
# Connect retry?
if connect is False:
raise six.reraise(type(error), error, _stacktrace)
elif connect is not None:
connect -= 1


The sounding output with the temporary patch is(twice...):

> Retrying (Retry(total=1, connect=None, read=None, redirect=None)) after 
> connection broken by 
> 'ConnectTimeoutError(requests.packages.urllib3.connection.VerifiedHTTPSConnection
>  object at/
>
>  Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after 
> connection broken by 
'ConnectTimeoutError(requests.packages.urllib3.connection.VerifiedHTTPSConnection
 object at/
>
>  Could not find a version that satisfies the requirement evdev (from 
> versions: )
>
> No matching distribution found for evdev
>
> WARNING : Pip failed to install software!

In this case I did not thoroughly analysed the actual error source, thus did a 
quick and dirty patch only.

My proposal is to add the inplace operator to the class *Reply* with the 
default assignment in case of an type error and display an error message.
This is still not really the correct solution, but resolves a lot of confusion 
by required interpretation of the exception.

Arno-Can Uestuensoez

--
components: Library (Lib)
messages: 330574
nosy: Quentin.Pradet, acue, deivid, martin.panter
priority: normal
severity: normal
status: open
title: urllib3 fails with type error exception, when cannot reach PyPI - 
urllib3.util.retry
type: crash
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

[issue33154] subprocess.Popen ResourceWarning should have activation-deactivation flags

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez <acue.opensou...@gmail.com> added the comment:

See also 
issue26741 - subprocess.Popen should emit a ResourceWarning in destructor if ...

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33154>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33154] subprocess.Popen ResourceWarning should have activation-deactivation flags

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez <acue.opensou...@gmail.com>:

The subprocess call *subprocess.Popen* in Python3.6 was added a number of 
resource warnings, including subprocess run-state and open files. This is a 
very good facility for debugging, but causes a lot of trouble for programs 
relying on subprocesses via the STDIO/STDERR interface. The STDIO/STDERR 
interfaces are very common when shell utilities are incorporated into high 
level Python programs.

The other issue is the unit testing of command line tools as black-box tests, 
these solely rely on the STDOUT and STDERR interface. I am currently finishing 
a subprocess test package with common code for Python2.7 and Python3.5+, so 
facing some trouble with IO filtering. Examples are attached.

A system call should process the common IO interfaces of the called 
subprocesses by default without any additional output. So a call flag and/or an 
environment variable should be introduced in addition, which allows the 
activation and deactivation of these messages.
The default should be *deactive*.

--
components: Library (Lib)
files: python3-output.txt
messages: 314511
nosy: acue, martin.panter, pitrou, python-dev, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: subprocess.Popen ResourceWarning should have activation-deactivation 
flags
type: resource usage
versions: Python 3.6
Added file: https://bugs.python.org/file47502/python3-output.txt

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33154>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33150] Signature error for methods of class configparser.Interpolation

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez <acue.opensou...@gmail.com>:

I am not sure whether this is already covered by an issue, it is present in 
3.6.2 and 3.6.4.

The class Interpolation in the configparser module causes an exception:

  File "/opt/python/python-3.6.4/lib/python3.6/configparser.py", line 1123, in 
_join_multiline_values
name, val)
TypeError: before_read() missing 1 required positional argument: 'value'


This is due to the missing 'parser' parameter at the call of 
'Interploation.xyz()' methods, also the case for several other method calls.


class Interpolation:
"""Dummy interpolation that passes the value through with no changes."""

def before_read(self, parser, section, option, value):
return value

   ...

Same for derived classes see e.g.

   class BasicInterpolation(Interpolation):
   ...

   class ExtendedInterpolation(Interpolation):
   ...

A work around seems to be:

- defining a dummy with changed signatures as parameter 'interpolation'

--
components: Argument Clinic, Build, asyncio
messages: 314493
nosy: acue, asvetlov, larry, yselivanov
priority: normal
severity: normal
status: open
title: Signature error for methods of class configparser.Interpolation
type: compile error
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33150>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32078] string result of str(bytes()) in Python3

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez <acue.opensou...@gmail.com> added the comment:

I got your point, missed it before, sorry.
So just for completeness.

My issue was basically about the ambiguity of the str()-constructor
and the str()-built-in-function. Therefore the len/type prints.

It works with parameters:

(3.6.2) [acue@lap001 Desktop]$ python -bb
Python 3.6.2 (default, Jul 29 2017, 14:24:56) 
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> str(b"abc")
Traceback (most recent call last):
  File "", line 1, in 
BytesWarning: str() on a bytes instance
>>> 
>>> 
>>> str(b"abc", "utf-8")
'abc'
>>> 
>>> type(str(b"abc",'utf-8'))

>>> 

Is there a common approach to force the use of the str()-constructor instead of
the str()-built-in function and/or the __str__()-method?

This would make the shared code of Python2/Python3 much easier, 
at least for unicode()->str().

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32078>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32078] string result of str(bytes()) in Python3

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez <acue.opensou...@gmail.com> added the comment:

Sorry for the typo.

--
Added file: https://bugs.python.org/file47276/howto_bytes_005typo.py

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32078>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32078] string result of str(bytes()) in Python3

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez <acue.opensou...@gmail.com> added the comment:

Hello,
the following reduced example probably shows the issue a
little better.

I have currently not yet the 3.7+ environment, but guess
the same behavior.


Regards
Arno

--
versions: +Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47275/howto_bytes_005.py

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32078>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32078] string result of str(bytes()) in Python3

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez <acue.opensou...@gmail.com>:

Hello,
I am currently writing some dual-version libraries and have
to deal with str/unicode.
The attached code example contains the str/unicode handling.

The Python3.6.2 release behaves as I did not expected for
all of the following the conversions:

  unicode = str  # @ReservedAssignment # it is intentional


  mystring = "abc"
  u0 = unicode(bytes(mystring.encode()))  # == str(mystring)

  mystring = "abc"
  u0 = unicode(bytes(mystring.encode('utf-8')))  # == str(mystring)

  mystring = "abc"
  u0 = unicode(bytes(mystring.encode('ascii')))  # == str(mystring)

  mystring = b"abc"
  u0 = unicode(mystring)  # == str(mystring)

results for Python3 in:

  type: 
  len:  6
  b'abc'

while in Python2:

  type: 
  len:  3
  abc

I am  not sure whether this is the intended behavior because the manual
could eventually be misinterpreted:


  4.8.1. Bytes Objects

  Bytes objects are immutable sequences of single bytes. 
  Since many major binary protocols are based on the ASCII text 
  encoding, bytes objects offer several methods that are only 
  valid when working with ASCII compatible data and are closely
  related to string objects in a variety of other ways.

class bytes([source[, encoding[, errors]]])

  Firstly, the syntax for bytes literals is largely the same as 
  that for string literals, except that a b prefix is added:

I expected the 'b'-prefix to be added to the input only, but I
expect the output without a type-prefix, because it is just an
attribute/property.

The result for Python3 should be similar to Python2:

  type: 
  len:  3
  abc

Regards
Arno

--
components: Unicode
files: source_and_output.tar.gz
messages: 306521
nosy: acue, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: string result of str(bytes()) in Python3
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47274/source_and_output.tar.gz

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32078>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28392] shlex - non-posix-mode: error in Multiple occurances of quotes substrings/words

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez:

See also 28391: Multiple occurances of: Closing quotes separate words

The issue 28391 is accepted, as it is defined:
 Quotes *within* words are ignored, only a leading quoted string will result in 
a separate word.  (That's recursive: try '"Do""This""Separate).

So I implement for compatibility mode your proposal.

But the example does not seem to work as expected, so seems to hint to a bug. 
Thus openning a seperate issue:

snip-->
import shlex

sopts = """-a "Do""This""Separate" """
resx = ["-a", '"Do"', 'ThisSeparate', ]
res=shlex.split(sopts,posix=False)

print "sopts  ="+str(sopts)
print "resx   ="+str(resx)
print "res="+str(res)
assert res == resx 

"""
Results in:

sopts  =-a "Do""This""Separate" 
resx   =['-a', '"Do"', 'ThisSeparate']
res=['-a', '"Do"', '"This"', '"Separate"']
Traceback (most recent call last):
  File "shlex_demo.py", line 52, in 
assert res == resx 
AssertionError

"""

<--snip

I also checked the variant with a trailing quoted word for completeness, which 
is not enclosed. Does not split at all:

sopts  =-a Do"SeparateThis" 
resx   =['-a', 'Do', '"SeparateThis"']
res=['-a', 'Do"SeparateThis"']

--
components: Library (Lib)
messages: 278351
nosy: Andrey.Kislyuk, acue, cvrebert, eric.araujo, eric.smith, ezio.melotti, 
python-dev, r.david.murray, robodan, vinay.sajip
priority: normal
severity: normal
status: open
title: shlex - non-posix-mode: error in Multiple occurances of quotes 
substrings/words
type: behavior
versions: Python 2.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28392>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28391] Multiple occurances of: Closing quotes separate words

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez:

I am currently writing an extended options scanner including 
shlex-compatibility mode. So including numerous extended unittests for 
compatibility verification.

I am not sure whether the following behaviour of shlex.split() is correct:

Quote from manual: 
  Parsing Rules: Closing quotes separate words ("Do"Separate is parsed as "Do" 
and Separate);

Case-0: Works
 sopts = """-a "Do"Separate """
 resx = ["-a", '"Do"', 'Separate', ]
 shlex.split(sopts,posix=False)
 assert res == resx 

Case-1: Fails - should work?
 sopts = """-a "Do"Separate"this" """
 resx = ["-a", '"Do"', 'Separate', '"this"', ]
 shlex.split(sopts,posix=False)
 assert res == resx 

Case-2: Works - should fail?
 sopts = """-a "Do"Separate"this" """ #@UnusedVariable
 resx = ["-a", '"Do"', 'Separate"this"', ]
 shlex.split(sopts,posix=False)
 assert res == resx 

The Case-0 is as defined in the manuals.

Is Case-1 or Case-2 the correct behaviour?
Which of Case-1, Case-2 is an error?

REMARK: I haven't found an eralier issue, so filing this here.

--
components: Library (Lib)
messages: 278329
nosy: Andrey.Kislyuk, acue, cvrebert, eric.araujo, eric.smith, ezio.melotti, 
python-dev, r.david.murray, robodan, vinay.sajip
priority: normal
severity: normal
status: open
title: Multiple occurances of: Closing quotes separate words
type: behavior
versions: Python 2.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28391>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26329] os.path.normpath("//") returns //

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez added the comment:

Hi Serhiy,
I am currently still investigating it for my own project. 

  
https://stackoverflow.com/questions/37646103/posix-path-1003-1-examples-and-behaviour-for-foo-bar

Currently I do not have the build environment, so I can provide the text, but 
because I am a bit under pressure with finishing a larger pack of OpenSource 
projects currently I cannot manage to setup the environment.

So can do this eventually in 2-3Weeks.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26329>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27234] tuple - single value with comma is assigned as type tuple

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez:

A single value terminated by a comma is assigned to be a tuple, even when 
missing parenthesis.

a=(1)  =>  a=1OK/defined as
a=(1,) =>  a=(1,) OK
a=1,   =>  a=(1,) ???

Is the latter intended?

--
In [4]: a=1,

In [5]: print a
(1,)

In [6]: type(a)
Out[6]: tuple
---

--
components: Interpreter Core
messages: 267434
nosy: acue
priority: normal
severity: normal
status: open
title: tuple - single value with comma is assigned as type tuple
type: behavior
versions: Python 2.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27234>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27228] just for clearing: os.path.normpath("file://a") returns "file:/a"

[Arno-Can Uestuensoez]

New submission from Arno-Can Uestuensoez:

I am currently finishing a file system library and use 'os.path.normpath' for 
canonical input into match-operations.

So already found Issue26329 - IEEE-1003.1-Chap 4.2 and written a comment. But I 
guess this issue should be handled seperately.

Now have to deal by myself with the eventual prefix 'file://' for input, and 
guess it should be supported. I did not found a statement on this case, so 
issue this for clarification. The 'os.path.normpath' call simply replaces 
subsequent os.sep, when they are not leading as 1003.1 states. But how should 
the following examples be handled:

  file:a   => /a OR //a ???

  file:/a  => /a  OK
  file:///a=> /a  OK

--
assignee: docs@python
components: Documentation
messages: 267407
nosy: Fred Rolland, Winterflower, acue, docs@python, ebarry, lemburg, 
serhiy.storchaka
priority: normal
severity: normal
status: open
title: just for clearing: os.path.normpath("file://a") returns "file:/a"
type: behavior
versions: Python 2.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27228>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26329] os.path.normpath("//") returns //

[Arno-Can Uestuensoez]

Arno-Can Uestuensoez added the comment:

I propose to add at least a statement like e.g. "In conformance to IEEE Std 
1003.1™, 2013 Edition; 4.12 Pathname Resolution".

Because I had the same thought of a bug at first view, this because I did not 
find any hint in e.g. docs for 2.7.11. 

The reason to handle this thoroughly in my projects is the application of a 
path-matching library for generic unit tests, e.g. for bash scripts which 
require intensive PATH resolution. This has to be applied by the users of the 
library.

See "https://pypi.python.org/pypi/pyfilesysobjects;, and  
"https://pypi.python.org/pypi/epyunit; which requires intensive pattern 
matching of application provided pathnames, e.g. when it comes to automatic 
split of actual used PYTHONPATH items for a specific function/method, module, 
or package.

E.g. the user provides an 'intentional casual' pathname for drop-in unit 
tests(see epyunit),
  "os.sep + context.sys.path[x] + os.sep + 'rel-module-path'",
due to mixed relative and absolute paths resulting in leading 
  "os.sep + os.sep".  
The pattern match than fails, but it is not immediately clear for which reason.

--
nosy: +acue

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26329>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com