[issue34254] Include type annotations in error messages for better errors

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks for the feedback on this. Brett also gave feedback on the python-ideas 
mailing list as below : 

> Two things to quickly mention: one is that type hints have no run-time 
> semantics, so adding them to such a critical exception would be escalating 
> their meaning a bit. The other point is this TypeError has nothing to do with 
> the cause of the exception, so I would say that it's slightly distracting 
> from the cause of the issue.

I am closing this.

Thanks

--
resolution:  -> rejected
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

[issue26515] Update extending/embedding docs to new way to build modules in C

[Berker Peksag]

Change by Berker Peksag :


--
nosy: +berker.peksag
type:  -> enhancement
versions: +Python 3.7, Python 3.8 -Python 3.5

___
Python tracker 

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

[issue26515] Update extending/embedding docs to new way to build modules in C

[Berker Peksag]

Change by Berker Peksag :


--
keywords: +patch
pull_requests: +8177
stage: needs patch -> patch review

___
Python tracker 

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

[issue34254] Include type annotations in error messages for better errors

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

FWIW I am rather -1 on this. More detailed errors messages are always good, but 
in the proposed form it looks more like a distraction. I think just showing a 
fully qualified name of the function would be both more concise and more 
informative, since the user would likely need to look at the function 
code/docstring anyway in order to write a correct call.

--
nosy: +levkivskyi

___
Python tracker 

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

[issue34236] Test6012 in test_capi is not run as part of make test

[Zackery Spytz]

Change by Zackery Spytz :


--
components: +Tests -Build
nosy: +ZackerySpytz

___
Python tracker 

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

[issue34236] Test6012 in test_capi is not run as part of make test

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +8176
stage:  -> patch review

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

I think I could make linecache use the ResourceReader API to find the source 
file instead of looking in the sys.path entries. However, that's orthogonal to 
PR 6653: we still need PR 6653 to continue looking for the source file in the 
first place.

--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

Check the commands below and the results to see why the problem with the mouse 
wheel appeared:

>>> a = 1
>>> a >= 0 == True
False
>>> (a >= 0) == True
True
>>> a >= (0 == True)
True
>>> a >= 0 == False
True
>>> (a >= 0) == False
False
>>> a >= (0 == False)
True
>>> (a >= 0) == True
True

--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Stefan Behnel]

Stefan Behnel  added the comment:

> SageMath is the only project that I know which actually installs .pyx sources.

Ah, right. I wrongly remembered that they are automatically included in binary 
packages, but that only applies to .py source of Cython compiled Python modules 
(which are obviously included), not for .pyx sources. Those still need to be 
explicitly included, which suggests that most projects wouldn't do that 
(especially because it doesn't help, given this very issue).


> The one possible fly in the ointment is if there are use cases that we
> need to support where a single .so/.pyd file is built from *multiple*
> source files, as get_source doesn't allow for that.

That probably applies to many, if not most, extension modules. For Cython it's 
.pyx, .pxi and .pxd files, plus any external C/C++ source files, for C it's 
.c/.cpp and .h files, other code generators have their own (set of) source 
files, many wrapper extension modules out there consist of more than one source 
file that would be relevant, …

I would consider .py files the exceptional case here.

--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

I just realized the existence of 
https://docs.python.org/3/library/importlib.html#importlib.abc.ResourceReader

Isn't this *exactly* what we need here?

--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> If you're OK with that, I don't see the problem.

I recall that we already agreed several months ago, when I submitted 
https://github.com/python/cpython/pull/6653

--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Paul Moore]

Paul Moore  added the comment:

If you're OK with that, I don't see the problem. My objection was with the 
claims that ExtensionLoader.get_source shouldn't return None or shouldn't 
exist. PEP 302 mandates that loaders have a get_source, and that get_source 
should return None if the loader can't supply source. And that's precisely what 
ExtensionLoader is doing.

So if we're agreed that there's no changes needed to PEP 302 (more accurately, 
the loader protocol as it exists now) or to ExtensionLoader, then I'm happy to 
let others work out a solution on that basis.

--

___
Python tracker 

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

[issue34339] Argument unpacking syntax for lambdas

[danijar]

danijar  added the comment:

Thank you! Closing this.

--
resolution:  -> wont fix
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

[issue33954] float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error for locales with non-ascii thousands separator

[ppperry]

Change by ppperry :


--
title: float.__format__('n') fails with _PyUnicode_CheckConsistency assertion 
error -> float.__format__('n') fails with _PyUnicode_CheckConsistency assertion 
error for locales with non-ascii thousands separator

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> One other thing I will say is that the PEP 302 APIs were seemingly designed 
> for working with Python source and were not necessarily oriented towards 
> alternative code representations that were executed

That's also my impression. I'm perfectly fine with saying that the get_source() 
method defined in PEP 302 only applies to Python sources.

That, together with the fact that we are really looking for *filenames* not 
*modules* is why the fix should involve the linecache module and not PEP 302. 
In https://bugs.python.org/issue32797#msg323106 Nick seemed to agree with that.

--

___
Python tracker 

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> Now, though, we need a way for SageMath to get it working on releases up to 
> and including 3.7, *without* any help from Cython or CPython

That's not really what I need. We already have a work-around in SageMath:

try:
from importlib.machinery import ExtensionFileLoader
except ImportError:
pass  # Python 2
else:
del ExtensionFileLoader.get_source

So this issue is about finding a proper solution, which doesn't require a 
monkey-patch like the above. And I want it to work without any special support 
from the package, installing .pyx sources should "just work". This issue is not 
specific to SageMath, it's just that SageMath is the only project that I know 
which actually installs .pyx sources.

> Define a subclass of ExtensionModuleLoader [1] that overrides get_source() to 
> also look for a ".pyx" file adjacent to the extension module.

As I mentioned before, get_source() cannot work because a single Cython module 
can have multiple sources. So whatever method is used to retrieve the Cython 
sources must know the filename; the module is not sufficient.

As you can see from the monkey-patch, not implementing get_source() at all 
works, but that's probably more or less by accident. I'm not sure to what 
extent that could be documented as the official way to look up a filename 
relative to sys.path entries.

--

___
Python tracker 

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

[miss-islington]

miss-islington  added the comment:


New changeset e610c4f9984d50b45eb00e04c73c4208c0542a3b by Miss Islington (bot) 
in branch '3.7':
bpo-34336: Don't promote possibility to leave out typing.Optional (GH-8677)
https://github.com/python/cpython/commit/e610c4f9984d50b45eb00e04c73c4208c0542a3b


--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> So, where is the filename coming from?

Python 3.7.0 (default, Jul 23 2018, 10:07:21)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sage.all import Integer
>>> try:
... Integer(1)/Integer(0)
... except Exception as e:
... E = e
>>> E.__traceback__.tb_next.tb_frame.f_code.co_filename
'sage/structure/element.pyx'

So this is the correct filename, relative to site-packages.

--

___
Python tracker 

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

[miss-islington]

miss-islington  added the comment:


New changeset 02c4eae35cd24ab71c12b5e61ec22e993ac4839b by Miss Islington (bot) 
in branch '3.6':
bpo-34336: Don't promote possibility to leave out typing.Optional (GH-8677)
https://github.com/python/cpython/commit/02c4eae35cd24ab71c12b5e61ec22e993ac4839b


--
nosy: +miss-islington

___
Python tracker 

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

[issue34339] Argument unpacking syntax for lambdas

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I think this is an explicit decision to remove it in Python 3 unless I am 
mistaking the syntax you are referring to. Please refer : 
https://www.python.org/dev/peps/pep-3113/ . A note on 2to3 to fix this : 
https://www.python.org/dev/peps/pep-3113/#transition-plan

➜  cpython git:(master) python2
Python 2.7.14 (default, Mar 12 2018, 13:54:56)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> (lambda x, (y, z): [x, y])(1, (2, 3))
[1, 2]
>>> (lambda x, (y, z): [x, y, z])(1, (2, 3))
[1, 2, 3]


➜  cpython git:(master) python3
Python 3.6.4 (default, Mar 12 2018, 13:42:53)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> (lambda x, (y, z): [x, y, z])(1, (2, 3))
  File "", line 1
(lambda x, (y, z): [x, y, z])(1, (2, 3))
   ^
SyntaxError: invalid syntax


Thanks

--
nosy: +xtreak

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Paul Moore]

Paul Moore  added the comment:

On Sun, 5 Aug 2018 at 18:10, Brett Cannon  wrote:

> One other thing I will say is that the PEP 302 APIs were seemingly designed
> for working with Python source and were not necessarily oriented towards
> alternative code representations that were executed, e.g. Quixote was
> supported because it transpiled to Python source (although Paul is a
> co-author on the PEP and could more definitively answer ). IOW the APIs
> are oriented towards the Python programming language, not the CPython
> interpreter. This is why, for instance, I'm suggesting that if a more
> general solution is desired to be made official, then trying to force
> everything into the current APIs might not turn out well

That's how I recall it. The only cases we really considered were Python
modules (source code plus pyc) and extension modules (no source, loader
should return None).

Paul

--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Brett Cannon]

Brett Cannon  added the comment:

On Sun, Aug 5, 2018, 08:55 Nick Coghlan,  wrote:

>
> Nick Coghlan  added the comment:
>
> While I'd be inclined to agree with Paul's analysis if CPython were a
> greenfield project, I also think if SageMath had already been ported to
> Python 3.2, we would have considered this change a behavioural regression
> between 3.2 and 3.3 resulting from the importlib migration and worked out a
> way to get it to work implicitly again.
>

Perhaps, but no point on dwelling on 4 releases ago. 

One other thing I will say is that the PEP 302 APIs were seemingly designed
for working with Python source and were not necessarily oriented towards
alternative code representations that were executed, e.g. Quixote was
supported because it transpiled to Python source (although Paul is a
co-author on the PEP and could more definitively answer ). IOW the APIs
are oriented towards the Python programming language, not the CPython
interpreter. This is why, for instance, I'm suggesting that if a more
general solution is desired to be made official, then trying to force
everything into the current APIs might not turn out well.

> Now, though, we need a way for SageMath to get it working on releases up
> to and including 3.7, *without* any help from Cython or CPython, since it
> needs to work with existing Cython releases on existing CPython versions to
> avoid presenting itself to SageMath users as regression introduced by
> switching from Python 2 to Python 3.
>
> To do that, I believe it can be made to work in much the same way it did
> in Python 2 if SageMath were to do the following:
>
> 1. Define a subclass of ExtensionModuleLoader [1] that overrides
> get_source() to also look for a ".pyx" file adjacent to the extension
> module. This would also look for any of the file suffixes in
> SOURCE_SUFFIXES if a .pyx file isn't found.
> 2. Create an instance of FileFinder [3] that uses the custom loader
> subclass for any of the file suffixes in EXTENSION_SUFFIXES [4]
> 3. Replace the regular file finding hook in sys.path_hooks with  the
> path_hook method from that new FileFinder instance (by default, there's
> only one FileFinder hook installed, and it can currently be identified as
> "obj.__name__ == 'path_hook_for_FileFinder')
> 4. Invalidate importlib's caches, so any future extension module imports
> will use the custom extension module loader, rather than the default one
>

This sounds like it would work to me and doesn't require any special
changes on our part to function.

-Brett

> [1]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.ExtensionFileLoader
> [2]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.SOURCE_SUFFIXES
> [3]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.FileFinder
> [4]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.EXTENSION_SUFFIXES
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

[miss-islington]

Change by miss-islington :


--
pull_requests: +8174

___
Python tracker 

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

[miss-islington]

Change by miss-islington :


--
pull_requests: +8175

___
Python tracker 

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

[issue34340] mimetypes libmagic compatibility

[bpypy]

New submission from bpypy :

An obvious use case for mimetypes would be to check if file has correct 
mimetype, by getting the type with some of libmagic wrappers, and then 
comparing to guess_type result.

But it seems that they don't always match. One example:
applicattion/rar vs application/x-rar
https://github.com/file/file/blob/b9e60f088847f885b5c9fde61ff8fc9645843506/magic/Magdir/archive#L986

Kills half the usefullness of the module.

--
components: Extension Modules
messages: 323160
nosy: bpypy
priority: normal
severity: normal
status: open
title: mimetypes libmagic compatibility
type: enhancement

___
Python tracker 

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:


New changeset 336c945858055059a65134d4c501a85037d70d99 by Ivan Levkivskyi 
(Ville Skyttä) in branch 'master':
bpo-34336: Don't promote possibility to leave out typing.Optional (#8677)
https://github.com/python/cpython/commit/336c945858055059a65134d4c501a85037d70d99


--
nosy: +levkivskyi

___
Python tracker 

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

[issue34339] Argument unpacking syntax for lambdas

[danijar]

New submission from danijar :

It would be great to support argument unpacking for lambdas. Example:

  lambda x, (y, z): x + y + z

instead of

  lambda x, y_and_z: x + y_and_z[0] + y_and_z[1]

Similar unpacking syntax is available for normal functions:

  def foo(x, y_and_z):
y, z = y_and_z
return x + y + z

This would greatly increase readability in some cases.

--
components: Interpreter Core
messages: 323158
nosy: benjamin.peterson, brett.cannon, danijar, yselivanov
priority: normal
severity: normal
status: open
title: Argument unpacking syntax for lambdas

___
Python tracker 

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

[issue34338] abstractmethod can run on classes

[Michael Hooreman]

New submission from Michael Hooreman :

Hello,

When I decorate a class method with abc.abstractmethod, and I call it from the 
class (not the instance), the call is successful.

It looks like ID 5867 which was closed years ago.

See 
https://stackoverflow.com/questions/51669362/python-3-6-abc-abstracmethod-on-classmethod-no-check-on-class-level-call

Thanks!

--
components: Library (Lib)
messages: 323157
nosy: Michael Hooreman
priority: normal
severity: normal
status: open
title: abstractmethod can run on classes
type: behavior
versions: Python 3.6

___
Python tracker 

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

[issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom launcher

[Nick Coghlan]

Nick Coghlan  added the comment:

My comment wasn't about the 3.7.0 -> 3.7.1 fix, but rather about the fact that 
I suspect that 3.7.1 is now going to respect some environment variables in this 
case that 3.6.x ignored. I don't know for sure though, since we didn't have a 
test case for this until you wrote one.

So I was thinking we could include a porting note along the lines of:

===
- starting in 3.7.1, `Py_Initialize` now consistently reads and respects all of 
the same environment settings as `Py_Main` (in earlier Python versions, it 
respected an ill-defined subset of those environment variables, while in Python 
3.7.0 it didn't read any of them due to :issue:`34247`). If this behaviour is 
unwanted, set `Py_IgnoreEnvironmentFlag = 1` before calling `Py_Initialize`.
===

That note then serves two purposes:

- it lets embedders know that `Py_IgnoreEnvironmentFlag = 0` just plain doesn't 
work properly in 3.7.0 (without their needing to find this bug for themselves)
- it lets embedders know that they may want to set `Py_IgnoreEnvironmentFlag = 
1` if their embedded interpreter is now being affected by environmental 
settings that it ignored in previous versions

--
stage: patch review -> commit review

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Nick Coghlan]

Nick Coghlan  added the comment:

While I'd be inclined to agree with Paul's analysis if CPython were a 
greenfield project, I also think if SageMath had already been ported to Python 
3.2, we would have considered this change a behavioural regression between 3.2 
and 3.3 resulting from the importlib migration and worked out a way to get it 
to work implicitly again.

Now, though, we need a way for SageMath to get it working on releases up to and 
including 3.7, *without* any help from Cython or CPython, since it needs to 
work with existing Cython releases on existing CPython versions to avoid 
presenting itself to SageMath users as regression introduced by switching from 
Python 2 to Python 3.

To do that, I believe it can be made to work in much the same way it did in 
Python 2 if SageMath were to do the following:

1. Define a subclass of ExtensionModuleLoader [1] that overrides get_source() 
to also look for a ".pyx" file adjacent to the extension module. This would 
also look for any of the file suffixes in SOURCE_SUFFIXES if a .pyx file isn't 
found.
2. Create an instance of FileFinder [3] that uses the custom loader subclass 
for any of the file suffixes in EXTENSION_SUFFIXES [4]
3. Replace the regular file finding hook in sys.path_hooks with  the path_hook 
method from that new FileFinder instance (by default, there's only one 
FileFinder hook installed, and it can currently be identified as "obj.__name__ 
== 'path_hook_for_FileFinder')
4. Invalidate importlib's caches, so any future extension module imports will 
use the custom extension module loader, rather than the default one

[1] 
https://docs.python.org/3/library/importlib.html#importlib.machinery.ExtensionFileLoader
[2] 
https://docs.python.org/3/library/importlib.html#importlib.machinery.SOURCE_SUFFIXES
[3] 
https://docs.python.org/3/library/importlib.html#importlib.machinery.FileFinder
[4] 
https://docs.python.org/3/library/importlib.html#importlib.machinery.EXTENSION_SUFFIXES

--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

In fact, if the first click before dragging takes place in the upper half of 
the scrollbar slider, the click is not received nor the drag after. Is like the 
scroll slider is translated down with half of the slider length (that's why I 
can drag the slider even when I'm a little bit lower with the pointer). I'll 
check the click callback and the scrollbar setup functions. Can anybody check 
if clicking then starting to drag the slider in the inferior half of the 
slider, even at the top of a file, functions well?

--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

With:

up = {EventType.MouseWheel: (event.delta >= 0) == darwin,
  EventType.Button: (event.num == 4)}

in editor.py at 461-462 I don't see bugs #1 neither #3 on 3.7.0 but I'll try 
with other files.

--

___
Python tracker 

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

[issue34319] Clarify pathlib.Path("filepath").read_text()

[Sanyam Khurana]

Sanyam Khurana  added the comment:

+1 to Terry's suggestion.

I've reviewed xtreak's PR and it looks good to me.

--
nosy: +CuriousLearner

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Paul Moore]

Paul Moore  added the comment:

So, where is the filename coming from? Looking at exception and frame objects, 
I don't see a "source filename" attribute anywhere - have I missed something 
here?

--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> The one possible fly in the ointment is if there are use cases that we
need to support where a single .so/.pyd file is built from *multiple*
source files, as get_source doesn't allow for that.

Yes, we must support that. A cython module may have multiple sources. The 
simplest solution to solve that would be a new PEP 302 API, something like 
get_source_from_filename(self, filename)

--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Tal Einat]

Change by Tal Einat :


--
keywords: +patch
pull_requests: +8173
stage: test needed -> patch review

___
Python tracker 

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

[issue33954] float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error

[Karthikeyan Singaravelan]

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Tal Einat]

Tal Einat  added the comment:

Yes! Vlad's fix resolves the "sticks at bottom of file" bug for me on macOS.  
It also resolves #2 in my list of additional bugs, regarding scrolling 
direction.

With both 3.7.0 and current master, I still see additional bugs #1 and #3, i.e. 
issues dragging the scrollbar slider when it is at the top of the scrollbar and 
clicking slightly under the slider having no effect.  I'll open a separate 
issue about that as it seems like something separate.

--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

The solution was very simple on my Mac. In 
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/idlelib/editor.py,
 lines 461-462 should be:

up = {EventType.MouseWheel: (event.delta >= 0) == darwin,
  EventType.Button: event.num == 4}

instead of:
up = {EventType.MouseWheel: event.delta >= 0 == darwin,
  EventType.Button: event.num == 4}

Does this solve the scrollbar locked down issue for anyone else?

--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

Having 3.6.5 and 3.7.0 with Tcl/Tk 8.6.8, try to File->Open Module and open ssl 
module. On 3.6 everything is fine, on 3.7 the scroller sticks at the bottom. A 
Tk text widget with the same amount of lines shows no problem. Apple macOS 
17.7.0 with 64 bit Python and Tcl/Tk. IDLE problem probably.

--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Paul Moore]

Paul Moore  added the comment:

On Sun, 5 Aug 2018 at 06:51, Stefan Behnel  wrote:
> This whole idea looks backwards and complicated. As Brett noted, .pyc files 
> were moved out of the source tree, because they are build time artifacts and 
> not sources. With that analogy, it's the .so files that would have to move, 
> not the .pyx or .py source files, which are sources for the compiled .so 
> files.

I disagree. In *Python* terms:

* .py files are the executable units of Python code
* .so/.pyd files are the executable units of extension modules
* .pyc/.pyo files are runtime artifacts that cache the results of the
compilation step of loading .py code. There's no equivalent for
.so/.pyd files as there's no compilation step needed when loading
them.
* .c, .h., .pyx, ... files are the source code for .so/.pyd files.
There's no equivalent for .py files, because Python code is executable
from source.

Executable units of code go on sys.path. Cached runtime artifacts go
in __pycache__. There's no defined location for source code. Whether
you agree with the above or not, please accept that it's a consistent
view of things. Sourceless distributions of Python code are an oddball
corner case, but they do *not* demonstrate that Python is a compiled
language and the .pyc/.pyo is the "executable" and the .py file is the
"source". At least not in my opinion.

It's entirely reasonable that we want to ensure that an exception
object, whether raised from a Python file or a compiled extension
module, includes a reference to the source of the issue, and that the
traceback mechanism can, if at all possible, locate that source and
display it in the exception traceback. That's basically what the
loader "get_source" method is for - isn't the problem here simply that
get_source for .pyd/.so files returns None, which in turn is because
there's no obvious way to get to the source file for a general binary
(and so the current implementation takes the easy way out and gives
up[1])?

Note that Cython is *not* unique here. Any tool that generates
.so/.pyd files has the same problem, and we should be looking for a
general solution. C code is the obvious example, and while I doubt
anyone is going to ship C sources with a Python extension, it's still
a valid case. Doesn't CFFI have a mode where it compiles a .pyd at
wheel build time? Shouldn't that be able to locate the source? As a
separate example, consider Jython, which may want to be able to locate
the Java (or Groovy, or Scala, ...) source for a .class file on
sys.path, and would have the same problem with get_source that CPython
does with .so/.pyd files.

So basically what's needed here is a modification to
ExtensionFileLoader to return a more useful value from get_source. How
it *does* that is up for debate, and brings in questions around what
standards the packaging community want to establish for shipping
extension sources, etc. And because the resulting decisions will end
up implemented as stdlib code, they need to be properly thought
through, as the timescales to fix design mistakes are quite long.
"Bung stuff on sys.path" isn't really a well thought through solution
in that sense, at least IMO - regardless of the fact that it's in
effect what linecache supported prior to Python 3.3.

So as a way forward, how about this:

1. Agree that what we actually need a better get_source method on
ExtensionFileLoader
2. Adjourn to distutils-sig to agree a standard for where tools that
generate .pyd/.so files should put their sources, if they should
choose to ship their sources in the wheel with the final built
extension.
3. Come back here with the results of that discussion to produce a PR
that implements that change to ExtensionFileLoader

The one possible fly in the ointment is if there are use cases that we
need to support where a single .so/.pyd file is built from *multiple*
source files, as get_source doesn't allow for that. Then it's back to
the drawing board...

Paul

[1] I remember working on the original design of PEP 302 and "take the
easy way out and give up" is *precisely* the thinking behind this :-)

--

___
Python tracker 

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

[issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom launcher

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
title: PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher -> 
PYTHONOPTIMIZE ignored in 3.7.0 when using custom launcher

___
Python tracker 

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

[issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher

[STINNER Victor]

STINNER Victor  added the comment:

On my PR, Nick Coghlan wrote:

"We may want to tweak the porting note in What's New, as I believe this may 
read more environment variables at init time than the interpreter did 
previously, so embedding applications that want more complete control may now 
need to set Py_IgnoreEnvironmentFlag when they could previously get by without 
it."

https://github.com/python/cpython/pull/8659#pullrequestreview-143397378

I'm not sure about this, since it's really a bug of Python 3.7.0 and it's now 
fixed.

I let you decide if the issue should be closed or not, I leave it open.

--

___
Python tracker 

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

[issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 0c90d6f75931da4fec84d06c2efe9dd94bb96b77 by Victor Stinner in 
branch '3.7':
[3.7] bpo-34247: Fix Python 3.7 initialization (#8659)
https://github.com/python/cpython/commit/0c90d6f75931da4fec84d06c2efe9dd94bb96b77


--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> Keeping two identical package structures in different places, one for .py 
> files and generated .so files, and one for Cython source files (.pyx, .pxd, 
> .pxi), is not desirable from a user perspective, and would require namespace 
> packages for the lookup, where otherwise a simple single Python package 
> structure would suffice. That would complicate Cython's internal compile time 
> import lookup system quite a bit.

This is an important point. You shouldn't consider these Cython files as "extra 
stuff", they really should be considered as part of the package.

--

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Nick: do you agree that this "source-only metapath" should by default contain 
an entry to look in sys.path for source files?

--

___
Python tracker 

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

[issue34310] Build error with option "--with-pydebug" on Mac OS 10.13.6

[Xiang Zhang]

Change by Xiang Zhang :


--
resolution: rejected -> not a bug

___
Python tracker 

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

[issue34310] Build error with option "--with-pydebug" on Mac OS 10.13.6

[Stéphane Wirtel]

Stéphane Wirtel  added the comment:

Hi Yu,

I am going to close this issue because

1. there is no master-dirty branch
2. your hash commit: d17fe275a3 does not exist in the CPython repository
3. I just downloaded the last revision of CPython and compile it on a 10.13.4 
OSX and I don't have your issue.


Maybe you should clean your working directory with make distclean and restart 
with ./configure --with-debug && make

Thank you for your feedback, and re-open this issue if you have again the 
problem with the master branch.

--
resolution:  -> rejected
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

[issue34310] Build error with option "--with-pydebug" on Mac OS 10.13.6

[Stéphane Wirtel]

Stéphane Wirtel  added the comment:

Could you retry with a make distclean && ./configure --with-debug && make ?

To be sure.

--
nosy: +matrixise

___
Python tracker 

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

[issue32797] Tracebacks from Cython modules no longer work

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> In a subdirectory similar to __pycache__.

I thought about that, but I don't like the idea because then the directory 
structure of the actual sources would be different from the directory structure 
of the installed sources. So for example, how should "pip install -e" install 
the sources?

--

___
Python tracker 

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

[issue34310] Build error with option "--with-pydebug" on Mac OS 10.13.6

[Xiang Zhang]

Xiang Zhang  added the comment:

I could not find the specific commit you mentioned on master branch. Maybe you 
are on a customized branch(what is master-dirty)?

--
nosy: +xiang.zhang

___
Python tracker 

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

[issue34337] Fail to get a right answer for 1.2%0.2

[Mark Dickinson]

Mark Dickinson  added the comment:

This isn't a bug: in short, you're evaluating a discontinuous function very 
close to a discontinuity; the errors inherent in floating-point arithmetic put 
you the "wrong" side of the discontinuity.

Or more simply, with binary floating-point, What You See Is Not What You Get. 
When you type 1.2, the value actually stored is the closest values that's 
exactly representable as a float, which turns out to be 
1.1999555910790149937383830547332763671875. Similarly, the value 
actually stored for 0.2 is 
0.200011102230246251565404236316680908203125. And 
1.1999555910790149937383830547332763671875 % 
0.200011102230246251565404236316680908203125 is 
0.199900079927783735911361873149871826171875.

Some references:

https://docs.python.org/3/tutorial/floatingpoint.html
https://docs.python.org/3/reference/expressions.html#id17

--
nosy: +mark.dickinson
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

[issue34337] Fail to get a right answer for 1.2%0.2

[Yiwei Guo]

New submission from Yiwei Guo :

the answer of 1.2%0.2 should be zero

--

___
Python tracker 

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

[issue34337] Fail to get a right answer for 1.2%0.2

[Yiwei Guo]

Change by Yiwei Guo :


--
components: Tests
nosy: qq100460045
priority: normal
severity: normal
status: open
title: Fail to get a right answer for 1.2%0.2
type: compile error
versions: Python 3.6

___
Python tracker 

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

[issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The PR works for me as well, and looks ok to me.

--

___
Python tracker 

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

[issue34313] IDLE crashes with Tk-related error on macOS with ActiveTcl 8.6

[Tal Einat]

Tal Einat  added the comment:

I can confirm the these issues do *not* occur on my macOS setup when using 
tcl/tk 8.6.8 built from source.

--

___
Python tracker 

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

[issue33839] IDLE tooltips.py: refactor and add docstrings and tests

[Tal Einat]

Change by Tal Einat :


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

[issue33839] IDLE tooltips.py: refactor and add docstrings and tests

[Tal Einat]

Change by Tal Einat :


--
resolution:  -> fixed

___
Python tracker 

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

[issue33839] IDLE tooltips.py: refactor and add docstrings and tests

[miss-islington]

miss-islington  added the comment:


New changeset 2474cef34cd50e603c674c4856a17e3da4af71b3 by Miss Islington (bot) 
in branch '3.6':
bpo-33839: refactor IDLE's tooltips & calltips, add docstrings and tests 
(GH-7683)
https://github.com/python/cpython/commit/2474cef34cd50e603c674c4856a17e3da4af71b3


--

___
Python tracker 

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

[Ville Skyttä]

Change by Ville Skyttä :


--
keywords: +patch
pull_requests: +8172
stage:  -> patch review

___
Python tracker 

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

[issue34336] Don't promote possibility to omit Optional on optional/defaulted arguments

[Ville Skyttä]

New submission from Ville Skyttä :

The documentation of typing.Optional seems to promote practices for not 
specifying Optional that are recommended against in PEP 484:

https://www.python.org/dev/peps/pep-0484/#union-types -- end of chapter 
recommends against inferring Optional.

https://docs.python.org/3.8/library/typing.html#typing.Optional -- second 
paragraph promotes the possibility of leaving out Optional.

I'm not sure how to improve the typing.Optional doc wording, perhaps it would 
be better to just remove the second paragraph altogether.

--
assignee: docs@python
components: Documentation
messages: 323132
nosy: docs@python, scop
priority: normal
severity: normal
status: open
title: Don't promote possibility to omit Optional on optional/defaulted 
arguments
type: enhancement
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

[issue33839] IDLE tooltips.py: refactor and add docstrings and tests

[miss-islington]

miss-islington  added the comment:


New changeset e65ec491fbaa14db61a6559eb269733616b0e7f0 by Miss Islington (bot) 
in branch '3.7':
bpo-33839: refactor IDLE's tooltips & calltips, add docstrings and tests 
(GH-7683)
https://github.com/python/cpython/commit/e65ec491fbaa14db61a6559eb269733616b0e7f0


--
nosy: +miss-islington

___
Python tracker 

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

[issue33839] IDLE tooltips.py: refactor and add docstrings and tests

[miss-islington]

Change by miss-islington :


--
pull_requests: +8170

___
Python tracker 

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

[issue33839] IDLE tooltips.py: refactor and add docstrings and tests

[miss-islington]

Change by miss-islington :


--
pull_requests: +8171

___
Python tracker 

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

[issue33839] IDLE tooltips.py: refactor and add docstrings and tests

[Tal Einat]

Tal Einat  added the comment:


New changeset 87e59ac11ee074b0dc1bc864c74fac0660b27f6e by Tal Einat in branch 
'master':
bpo-33839: refactor IDLE's tooltips & calltips, add docstrings and tests 
(GH-7683)
https://github.com/python/cpython/commit/87e59ac11ee074b0dc1bc864c74fac0660b27f6e


--

___
Python tracker 

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