[issue37934] Docs: Clarify NotImplemented use cases

[Kyle Stanley]

Kyle Stanley  added the comment:

> Would it be viable to rephrase the existing section in a manner that explains 
> the functional purpose of NotImplemented without revolving around its use 
> case in binary special methods?

To expand further upon this, here's an initial idea for improving the first 
sentence:

A special value used to indicate that an operation is not supported between 
specific types.

The section regarding it's usage in binary special methods could potentially 
remain. I'm thinking the main issue here (if there is one) is that the 
NotImplemented constant is defined _exclusively_ from a specific use case, 
rather than its general purpose.

--

___
Python tracker 

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

[issue37934] Docs: Clarify NotImplemented use cases

[Kyle Stanley]

Kyle Stanley  added the comment:

Thanks for the feedback Vedran and Raymond.

> It is not the purpose of the docs to list use cases.  Mostly we say what 
> something does or how it is defined. As Vedran says, how people use it is 
> their own business.

The underlying issue here seems to be that I misunderstood the existing section 
to suggest to suggest binary special methods are the only use case, which is 
probably a good argument in favor of not listing additional use cases. This can 
be misinterpreted as suggesting that others are not recommended, and lead to 
further confusion.


First sentence of the NotImplemented documentation:

> Special value which should be returned by the binary special methods (e.g. 
> __eq__(), __lt__(), __add__(), __rsub__(), etc.) to indicate that the 
> operation is not implemented with respect to the other type; may be returned 
> by the in-place binary special methods (e.g. __imul__(), __iand__(), etc.) 
> for the same purpose. 

Would it be viable to rephrase the existing section in a manner that explains 
the functional purpose of NotImplemented without revolving around its use case 
in binary special methods?

> Also, please be careful expanded the docs.  They quickly become a promise.

Good point, I may not have adequately considered that mentioning a use case 
turns into a promise for that functionality. This could easily result in a 
significant long-term maintenance cost.

--

___
Python tracker 

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

[issue37995] Multiline ast.dump()

[Raymond Hettinger]

Change by Raymond Hettinger :


Added file: https://bugs.python.org/file48580/ast_bloop.py

___
Python tracker 

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

[issue37995] Multiline ast.dump()

[Raymond Hettinger]

Change by Raymond Hettinger :


Removed file: https://bugs.python.org/file48579/ast_bloop.py

___
Python tracker 

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

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:

> Dong-hee Na, if you want to make a fresh PR for this and bring it to 
> fruition, I would be happy to review and apply it.

It seems premature to say that you will accept a PR for this when there's no 
consensus for actually adding the feature, and it would be good to probably 
work out if it's even desirable before asking contributors to do more work on 
it.

It seems like it would be better to argue the point of *why* you think a 
structseq actually solves the problem here. Is a struct sequence more backwards 
compatible than a namedtuple? Less? Is it as performant? Will it make it easier 
or harder to maintain compatibility between the C and pure Python 
implementations of the datetime module?

--

___
Python tracker 

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

[issue38003] Incorrect "fixing" of isinstance tests for basestring

[Bob Kline]

Bob Kline  added the comment:

> Use str instead.

Sure. I understand the advantages of the new approach to strings. Which, by the 
way, weren't available when this project began. I don't disagree with anything 
you say in the context of writing new code. I was, however, surprised and 
dismayed to learn of the cavalier approach the upgrade tool has taken to 
silently breaking existing code which it is claiming to "fix."

Here's my favorite so far.

--- cdr.py  (original)
+++ cdr.py  (refactored)
@@ -36,15 +36,15 @@
 # ==
 from six import itervalues
 try:
-basestring
+str
 is_python3 = False
 base64encode = base64.encodestring
 base64decode = base64.decodestring
 except:
 base64encode = base64.encodebytes
 base64decode = base64.decodebytes
-basestring = (str, bytes)
-unicode = str
+str = (str, bytes)
+str = str
 is_python3 = True

We wrote this following the example of comparable techniques in 
http://python-future.org/compatible_idioms.html and similar guides to an 
upgrade path. Seems we're being punished for taking the trouble to make our 
code work with Python 2 and 3 during the transition period. :-(

It's hard to see how this conversion resulted in something better than what we 
already had.

--

___
Python tracker 

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

[issue38001] Unexpected behaviour of 'is' operator

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Further to Karthikeyan Singaravelan comment, the behaviour you see is 
absolutely correct. The operator isn't behaving differently, it is reporting 
precisely the truth.

The ``is`` operator tests for object identity, not equality. Python makes no 
promises about object identity of literals. If you use an immutable literal in 
two places:

a = 1234
b = 1234

the interpreter is free to use the same object for both a and b, or different 
objects. The only promise made is that ``a == b``.

The Python interpreter currently caches some small integers for re-use, but 
that's not a language guarantee, and is subject to change without warning. It 
has changed in the past, and could change again in the future.

The bottom line is that you shouldn't use ``is`` except to test for object 
identity, e.g. ``if obj is None``.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue38003] Incorrect "fixing" of isinstance tests for basestring

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

https://docs.python.org/3.0/whatsnew/3.0.html

> The builtin basestring abstract type was removed. Use str instead. The str 
> and bytes types don’t have functionality enough in common to warrant a shared 
> base class. The 2to3 tool (see below) replaces every occurrence of basestring 
> with str.

For a longer explanation of this and other changes you might find below link 
useful. In Python 2 str is used to represent both text and bytes. Hence to 
check the type is str in python 2 you have to check it to be basestring and 
then check it to be unicode. In python 3 all strings are unicode with str and 
bytes being two different types. Hence there is no basestring and unicode 
string since they are both unified to be str itself in Python 3.

https://portingguide.readthedocs.io/en/latest/strings.html

Hope this helps.

--
nosy: +xtreak

___
Python tracker 

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

[issue38003] Incorrect "fixing" of isinstance tests for basestring

[Bob Kline]

New submission from Bob Kline :

We are attempting to convert a large Python 2 code base. Following the guidance 
of the official documentation 
(https://docs.python.org/2/library/functions.html#basestring) we created tests 
in many, many places that look like this:

if isinstance(value, basestring):
if not isinstance(value, unicode):
value = value.decode(encoding)
else:
some other code

It seems that the 2to3 tool is unaware that replacing basestring with str in 
such cases will break the software.

Here's an example.

$ 2to3 repro.py
...
--- repro.py(original)
+++ repro.py(refactored)
@@ -1,8 +1,8 @@
 from frobnitz import transform

 def foo(value, encoding=None):
-if isinstance(value, basestring):
-if not isinstance(value, unicode):
+if isinstance(value, str):
+if not isinstance(value, str):
 value = value.decode(encoding or "utf-8")
 return value
 else:

Help me understand how this "fix" results in the correct behavior.

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 350964
nosy: bkline
priority: normal
severity: normal
status: open
title: Incorrect "fixing" of isinstance tests for basestring
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

[issue37995] Multiline ast.dump()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

It would be great is the tool wasn't tightly bound to our particular AST and 
could be used for any hand-rolled AST.

--

___
Python tracker 

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

[issue37995] Multiline ast.dump()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

FWIW, I wrote a generic AST pretty printer for a personal compiler project (see 
attached file).  Perhaps it can be adapted to the Python AST.

## Example input ###

Program(procs=[Procedure(name='FACTORIAL', params=['N'], is_test=False, 
body=Block(blocknum=0, stmts=[Assign(name=Output(is_bool=False), 
value=Number(x=1)), Assign(name=Cell(i=0), value=Number(x=1)), 
Loop(times=Id(name='N'), fixed=False, body=Block(blocknum=1, 
stmts=[Assign(name=Output(is_bool=False), 
value=BinOp(value1=Output(is_bool=False), op='x', value2=Cell(i=0))), 
Assign(name=Cell(i=0), value=BinOp(value1=Cell(i=0), op='+', 
value2=Number(x=1)))]))]))], calls=[])

## Example output ###

Program(
   procs = [
  Procedure(
 name = 'FACTORIAL',
 params = [
'N'
 ],
 is_test = False,
 body = Block(
blocknum = 0,
stmts = [
   Assign(
  name = Output(is_bool=False),
  value = Number(x=1)
   ),
   Assign(
  name = Cell(i=0),
  value = Number(x=1)
   ),
   Loop(
  times = Id(name='N'),
  fixed = False,
  body = Block(
 blocknum = 1,
 stmts = [
Assign(
   name = Output(is_bool=False),
   value = BinOp(
  value1 = Output(is_bool=False),
  op = 'x',
  value2 = Cell(i=0)
   )
),
Assign(
   name = Cell(i=0),
   value = BinOp(
  value1 = Cell(i=0),
  op = '+',
  value2 = Number(x=1)
   )
)
 ]
  )
   )
]
 )
  )
   ],
   calls = []
)

--
Added file: https://bugs.python.org/file48579/ast_bloop.py

___
Python tracker 

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

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Why close this?  Having isocalendar() return a structseq instance would be a 
nice improvement.  It is what structseq was designed for.

Dong-hee Na, if you want to make a fresh PR for this and bring it to fruition, 
I would be happy to review and apply it.

I'm changing the title to structseq.  It was a distractor to mention 
collections.namedtuple() at all -- that would have been more appropriate for 
pure python code.

--
assignee: belopolsky -> rhettinger
title: Return a namedtuple from date.isocalendar() -> Have date.isocalendar() 
return a structseq instance

___
Python tracker 

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

[issue38002] 'ModifiedInterpreter' object has no attribute 'interp'

[Raymond Hettinger]

New submission from Raymond Hettinger :

Here's a new traceback I haven't seen before.  I only see these at the end of a 
session, so I don't know which steps triggered it.

$ python3.8 -m idlelib.idle tmp_pretty_fact_ast.py
Exception in Tkinter callback
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/tkinter/__init__.py",
 line 1883, in __call__
return self.func(*args)
  File 
"/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/runscript.py",
 line 173, in _run_module_event
interp.runcode(code)
  File 
"/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/pyshell.py",
 line 756, in runcode
self.interp.restart_subprocess()
AttributeError: 'ModifiedInterpreter' object has no attribute 'interp'

--
assignee: terry.reedy
components: IDLE
messages: 350961
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: 'ModifiedInterpreter' object has no attribute 'interp'
versions: 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

[issue24416] Return a namedtuple from date.isocalendar()

[Dong-hee Na]

Dong-hee Na  added the comment:

@taleinat @p-ganssle

I am okay with closing this issue without any change.
My initial purpose for this issue was also whether or not to close a long left 
issue.

I am +1 to closing this issue without any change.
Please leave a vote for this issue.
If @taleinat and @p-ganssle agree with closing this issue.
I am going to close this issue!

Thanks always!

--

___
Python tracker 

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

[issue24416] Return a namedtuple from date.isocalendar()

[Tal Einat]

Tal Einat  added the comment:

Paul, I'm also on the fence regarding the advantage of this.  It's not clear 
that the minor possible benefits outweigh the additional complexity and slight 
backwards-incompatibility (pickling).

Thinking about this further, yes, we'd probably avoid making this change.

--

___
Python tracker 

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

[issue24416] Return a namedtuple from date.isocalendar()

[Dong-hee Na]

Dong-hee Na  added the comment:

@pganssle @serhiy.storchaka

Sounds reasonable on the view of maintaining pure Python and C APIs at the time
Thank you for the explanation.

--

___
Python tracker 

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

[issue24416] Return a namedtuple from date.isocalendar()

[Paul Ganssle]

Paul Ganssle  added the comment:

> But I'm wondering how the `fromisocalendar` API relates to this patch.
> Rather, wouldn't this patch contribute to improving the usability of the 
> `fromisocalendar` API?

The `fromisocalendar` API relates to this patch only insofar as it is the 
inverse function of `isocalendar` and in some sense it allows specifying the 
parameters by keyword rather by position. I was merely bringing up that we 
didn't choose that API because we thought people would or should want or need 
to specify the individual components by keyword but because we didn't have an 
easy way to maintain the same API in the pure Python and C APIs at the time. By 
contrast, returning a plain tuple from `isocalendar()` is the easier *and* more 
performant thing to do, and given that any benefits seem marginal I'm against 
the switch.

I think that the usability of `fromisoformat` with the output of `isocalendar` 
will be largely unchanged if we were to switch to returning a namedtuple.

--

___
Python tracker 

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

[issue24416] Return a namedtuple from date.isocalendar()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

You can use datetime.date.fromisocalendar(*b).

--

___
Python tracker 

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

[issue24416] Return a namedtuple from date.isocalendar()

[Dong-hee Na]

Dong-hee Na  added the comment:

@p-ganssle @taleinat

I agree that there are penalties of this patch what you said.
But I'm wondering how the `fromisocalendar` API relates to this patch.
Rather, wouldn't this patch contribute to improving the usability of the 
`fromisocalendar` API?
I would appreciate it if you would generously understand that my background 
knowledge of this module is less than yours.

AS-IS:

>>> year, week, weekday = a.isocalendar()
>>> datetime.date.fromisocalendar(year, week, weekday)
datetime.date(2019, 9, 1)

TO-BE:
>>> b = a.isocalendar()
>>> datetime.date.fromisocalendar(b.year, b.week, b.weekday)
datetime.date(2019, 9, 1)

--

___
Python tracker 

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

[issue38001] Unexpected behaviour of 'is' operator

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
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

[issue38001] Unexpected behaviour of 'is' operator

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This will emit a SyntaxWarning in Python 3.8 to use == instead of using is for 
literals. This is not a bug but an implementation detail over caching a range 
of integers at 
https://github.com/python/cpython/blob/1f21eaa15e8a0d2b0f78d0e3f2b9e5b458eb0a70/Objects/longobject.c#L19

--
nosy: +xtreak

___
Python tracker 

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

[issue38001] Unexpected behaviour of 'is' operator

[Digin Antony]

New submission from Digin Antony :

The 'is' operator behave differently on two sets of values 
please find the attachment below

tested environment 
windows 7
python 3.7.3


Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
>>> a=256
>>> b=256
>>> a is b
True
>>> a=257
>>> b=257
>>> a is b
False

--
components: Interpreter Core
files: bug.png
messages: 350952
nosy: Digin Antony
priority: normal
severity: normal
status: open
title: Unexpected behaviour of  'is'  operator
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48578/bug.png

___
Python tracker 

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

[issue24416] Return a namedtuple from date.isocalendar()

[Paul Ganssle]

Paul Ganssle  added the comment:

Sorry for the late response after a patch, but I'm actually -1 on this patch. I 
don't think it buys us very much in terms of the API considering it only has 3 
parameters, and it adds some complexity to the code (in addition to the 
performance issue). Honestly, I think the main reason we didn't go with 
positional-only parameters in `fromisocalendar` was that the "/" syntax didn't 
exist yet.

--
nosy: +p-ganssle

___
Python tracker 

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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Thrlwiti]

Change by Thrlwiti :


--
nosy:  -THRlWiTi

___
Python tracker 

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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Thrlwiti]

Change by Thrlwiti :


--
nosy: +THRlWiTi

___
Python tracker 

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

[issue38000] importlib can not handle module file names with periods

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +brett.cannon

___
Python tracker 

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

[issue38000] importlib can not handle module file names with periods

[Andrey]

New submission from Andrey :

```
import os, sys

def import_module(dir_path, module_name, ref_module_name = None):
  module_file_path = os.path.join(dir_path, module_name).replace('\\', '/')
  if sys.version_info[0] > 3 or sys.version_info[0] == 3 and 
sys.version_info[1] >= 4:
import importlib
import_spec = 
importlib.util.spec_from_file_location(os.path.splitext(module_name)[0] if 
ref_module_name is None else ref_module_name, os.path.join(dir_path, 
module_name).replace('\\', '/'))
import_module = importlib.util.module_from_spec(import_spec)
import_spec.loader.exec_module(import_module)
#globals()[module_name if ref_module_name is None else ref_module_name] = 
import_module # still does not accept modules with periods without this
  else:
# back compatability
import imp
module_file, module_file_name, module_desc = 
imp.find_module(os.path.splitext(module_name)[0], 
[os.path.dirname(module_file_path)])
globals()[module_name if ref_module_name is None else ref_module_name] = 
imp.load_module(module_file_path, module_file, module_file_name, module_desc)
```

I am trying to import my modules targeted by file path:

```
import_module(MYTOOLS_ROOT, 'cmdoplib.std.py', 'cmdoplib')
import_module(MYTOOLS_ROOT, 'cmdoplib.yaml.py', 'cmdoplib_yaml')
```

And got error:

```
Traceback (most recent call last):
  File "c:\python\x64\37\lib\site-packages\xonsh\proc.py", line 1411, in run
r = self.f(self.args, sp_stdin, sp_stdout, sp_stderr, spec, spec.stack)
  File "c:\python\x64\37\lib\site-packages\xonsh\proc.py", line 1204, in 
proxy_two
return f(args, stdin)
  File "c:\python\x64\37\lib\site-packages\xonsh\aliases.py", line 575, in 
source_alias
builtins.execx(src, "exec", ctx, filename=fpath)
  File "c:\python\x64\37\lib\site-packages\xonsh\built_ins.py", line 1497, in 
__call__
return self.obj.__call__(*args, **kwargs)
  File "c:\python\x64\37\lib\site-packages\xonsh\execer.py", line 190, in exec
return exec(code, glbs, locs)
  File 
"w:/Work/MyProjects/__scm_solutions/all-in-one/_common/tools/cmdoplib.yaml.xsh",
 line 11, in 
g_yaml_env = cmdoplib_yaml.YamlEnv()
NameError: name 'cmdoplib_yaml' is not defined
```

If try to uncomment this:

```
globals()[module_name if ref_module_name is None else ref_module_name] = 
import_module
```

All works fine.
Seems the latest version of the python still can not handle modules with the 
periods in a file name without constructions from the old and well known `imp` 
module.

It seems for me as a bug or at least as an incomplete (re)implementation.

--
components: Interpreter Core
messages: 350950
nosy: andry
priority: normal
severity: normal
status: open
title: importlib can not handle module file names with periods
type: enhancement
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

[issue37998] re.sub(r'\\', r'\\\\', s) reporting MemoryError

[Guruprasad Venkataramaiah]

Guruprasad Venkataramaiah  added the 
comment:

With more debug, observed the input string ('s') is getting assigned to a big 
string of '' resulting in Memory error

--
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

[issue37998] re.sub(r'\\', r'\\\\', s) reporting MemoryError

[Guruprasad Venkataramaiah]

Guruprasad Venkataramaiah  added the 
comment:

With more debug, observed the input string ('s') is getting assigned to a big 
string of '' resulting in Memory error

--
resolution:  -> not a bug

___
Python tracker 

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

[issue37999] No longer use implicit convertion to int with loss

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue37999] No longer use implicit convertion to int with loss

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Use only the __index__() method for implicit conversion to iteger, and not 
__int__().

This converts deprecation warnings added in issue36048 into TypeError.

--
components: Interpreter Core
messages: 350947
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: No longer use implicit convertion to int with loss
type: enhancement

___
Python tracker 

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

[issue37993] os.path.realpath on Windows resolves mapped network drives

[Eryk Sun]

Eryk Sun  added the comment:

>> Unix Python resolves the executable path with repeated _Py_wreadlink 
>> calls. Windows Python should do something similar to ensure the 
>> consistency of sys.executable with realpath(sys.executable).
>
> I don't think this necessarily follows. There's nowhere in the 
> documentation that says that sys.executable is even a valid path, 
> let alone the final path.

The reason is cross-platform parity for users who aren't language lawyers -- as 
long as it's not expensive and doesn't compromise reliability or safety. 

That said, resolving the real executable path is more of a practical concern in 
Unix. In Windows it's not generally useful since the loader does not resolve 
the real path of an executable. 

Unix Python also calls _Py_wrealpath on the script path, which I think is more 
relevant in Windows than the sys.executable case because it's at a higher level 
that we control. This allows running a script symlink at the command line (e.g. 
linked in a common bin directory in PATH) even if the script depends on modules 
in the real directory.

>> I think we want relpath(realpath('C:/Temp/foo'), realpath('S:/')) to 
>> succeed as r"..\foo". I don't think we want it to fail as a cross-
>> drive relative path.
>
> Cross-drive relative paths are fine though - they are just absolute 
> paths :)

relpath() fails if the target and start directories aren't on the same drive. 
Code that's creating a symlink in Windows has to handle this case by using an 
absolute symlink instead of a relative symlink, if that's what you mean. That's 
probably for the better. So I change my mind. Forcing scripts to create 
absolute symlinks is not an issue, even if it's unnecessary because the target 
and start directory can be resolved to the same drive. The mount point should 
take precedence. But that's an argument against using the final path. Mapped 
drives and subst drives will be resolved in the final path. Reverse mapping to 
the original drive, if possible, would be extra work.

For example, say we start with "\\??\\S:\\". The object manager reparses the 
r"\??\S:" SymbolicLink as r"\??\C:\Temp\Subst". Next it reparses r"\??\C:" to a 
device object, with a resolved path such as 
r"\Device\HarddiskVolume2\Temp\Subst". The Device object type has a parse 
routine that's implemented by the I/O manager. This sends an IRP_MJ_CREATE 
request to the mounted file-system device (NTFS in this case) with the 
remaining path to be parsed, e.g. r"\Temp\Subst". Note that at this stage, 
information about the original drive "S:" is long gone.

If the file system in turn finds a reparse point, such as a file-system symlink 
or mount point, then it stops there and returns STATUS_REPARSE with the 
contents of the reparse buffer. The I/O Manager itself handles symlink and 
mount-point reparsing, for which it implements behavior that's as close as 
possible to Unix symlinks and mount points. After setting up the new path to 
open, the I/O manager's parse routine returns STATUS_REPARSE to the object 
manager. Up to 63 reparse attempts are allowed, including within the object 
namespace itself. The limit of 63 reparse attempts is a simple way to handle 
reparse loops.

Assuming no file-system reparse points, we have as the final path 
r"\Device\HarddiskVolume2\Temp\Subst". To map this back to a DOS path, 
GetFinalPathNameByHandleW queries the mount-point manager for the canonical DOS 
device name for r"\Device\HarddiskVolume2". The mount-point manager knows about 
"C:" in this case, but it doesn't have a registry of subst drives. 
GetFinalPathNameByHandleW also doesn't enumerate DOS devices and map a path 
back to a matching subst drive. It supports only the canonical path. 

Reverse mapping a UNC path to a mapped drive would be even more difficult. We 
would have to doubly resolve, for example, from "M:" -> r"\Device\\;M:\server\share\path\to\directory" -> 
r"\Device\Mup\;\;M:\server\share\path\to\directory". Once we confirm that "M:" targets the 
MUP device, we can compare r"\server\share\path\to\directory" to check whether 
the final path contains this path. If so it can replace it with "M:". That's a 
lot of work to get a non-canonical path, and that's the simplest case. For 
example, we could have a subst drive for a mapped drive, and the shortest path 
would be the subst drive.

To avoid resolving drives altogether, realpath() would have to manually walk 
the path instead of relying on GetFinalPathNameByHandleW.

> If we can easily tell the difference between directory junctions and 
> mapped drives, given that they are both identical types of reparse 
> points

Mapped drives and subst drives are not file-system reparse points. They're 
"DOS" devices, which are implemented as SymbolicLink objects in the "\\??\\" 
device-alias directory. A SymbolicLink object can be read via 
NtQuerySymbolicLinkObject, or via WINAPI QueryDosDeviceW if the SymbolicLink is 
in "\\??\\".

--

__

[issue37994] Fix silencing all errors if an attribute lookup fails

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
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

[issue37994] Fix silencing all errors if an attribute lookup fails

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 353053d9ad08fea0e205e6c008b8a4350c0188e6 by Serhiy Storchaka in 
branch '3.8':
[3.8] bpo-37994: Fix silencing all errors if an attribute lookup fails. 
(GH-15630) (GH-15635)
https://github.com/python/cpython/commit/353053d9ad08fea0e205e6c008b8a4350c0188e6


--

___
Python tracker 

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

[issue37998] re.sub(r'\\', r'\\\\', s) reporting MemoryError

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What is s?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue37998] re.sub(r'\\', r'\\\\', s) reporting MemoryError

[Guruprasad Venkataramaiah]

New submission from Guruprasad Venkataramaiah 
:

On Python 3.5:
s = re.sub(r'\\', r'', s)
  File "/pyuniti/venvs/guruv/lib/python3.5/re.py", line 182, in sub
return _compile(pattern, flags).sub(repl, string, count)
MemoryError

On Python 3.7
s = re.sub(r'\\', r'', s)  
  File "C:\Python\Python37-32\lib\re.py", line 192, in sub
return _compile(pattern, flags).sub(repl, string, count)
MemoryError

--
components: Regular Expressions
messages: 350943
nosy: Guruprasad Venkataramaiah, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.sub(r'\\', r'', s) reporting MemoryError
type: resource usage
versions: Python 3.5, Python 3.7

___
Python tracker 

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

[issue15999] Using new 'bool' format character

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 1f21eaa15e8a0d2b0f78d0e3f2b9e5b458eb0a70 by Serhiy Storchaka in 
branch 'master':
bpo-15999: Clean up of handling boolean arguments. (GH-15610)
https://github.com/python/cpython/commit/1f21eaa15e8a0d2b0f78d0e3f2b9e5b458eb0a70


--

___
Python tracker 

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

[issue15999] Using new 'bool' format character

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 5eca7f3f3836cc734dfe8dc5ec669f3b4e9333fe by Serhiy Storchaka in 
branch 'master':
bpo-15999: Always pass bool instead of int to socket.setblocking(). (GH-15621)
https://github.com/python/cpython/commit/5eca7f3f3836cc734dfe8dc5ec669f3b4e9333fe


--

___
Python tracker 

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

[issue15999] Using new 'bool' format character

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset eb8974616bc58f44b2a3c3e4ca2326894ae42c8f by Serhiy Storchaka in 
branch 'master':
bpo-15999: Always pass bool instead of int to the expat parser. (GH-15622)
https://github.com/python/cpython/commit/eb8974616bc58f44b2a3c3e4ca2326894ae42c8f


--

___
Python tracker 

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

[issue37994] Fix silencing all errors if an attribute lookup fails

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +15303
pull_request: https://github.com/python/cpython/pull/15635

___
Python tracker 

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

[issue37994] Fix silencing all errors if an attribute lookup fails

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 41c57b335330ff48af098d47e379e0f9ba09d233 by Serhiy Storchaka in 
branch 'master':
bpo-37994: Fix silencing all errors if an attribute lookup fails. (GH-15630)
https://github.com/python/cpython/commit/41c57b335330ff48af098d47e379e0f9ba09d233


--

___
Python tracker 

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

[issue36543] Remove old-deprecated ElementTree features (part 2)

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
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

[issue36543] Remove old-deprecated ElementTree features (part 2)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset f02ea6225bc3b71bd5fe66224d199a6e3e23b14d by Serhiy Storchaka in 
branch 'master':
bpo-36543: Remove old-deprecated ElementTree features. (GH-12707)
https://github.com/python/cpython/commit/f02ea6225bc3b71bd5fe66224d199a6e3e23b14d


--

___
Python tracker 

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

[issue35771] IDLE: Fix tooltip Hovertiptest failure

[Tal Einat]

Change by Tal Einat :


--
pull_requests: +15302
pull_request: https://github.com/python/cpython/pull/15634

___
Python tracker 

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