[issue41617] __builtin_bswap16 is used without checking it is supported

[Joshua Root]

Change by Joshua Root :


--
pull_requests: +21053
pull_request: https://github.com/python/cpython/pull/21943

___
Python tracker 

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

[issue41617] __builtin_bswap16 is used without checking it is supported

[Joshua Root]

Change by Joshua Root :


--
versions: +Python 3.10

___
Python tracker 

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

[issue41617] __builtin_bswap16 is used without checking it is supported

[Joshua Root]

Change by Joshua Root :


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

___
Python tracker 

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

[issue41617] __builtin_bswap16 is used without checking it is supported

[Joshua Root]

New submission from Joshua Root :

Older clang versions don't have __builtin_bswap16, but it's always used when 
compiling with clang, which means the build fails with those older versions. 
The code should use __has_builtin to check.

--
components: Build
messages: 375806
nosy: jmr
priority: normal
severity: normal
status: open
title: __builtin_bswap16 is used without checking it is supported
type: compile error
versions: Python 3.9

___
Python tracker 

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

[issue41609] pdb's whatis command reports method as function

[Irit Katriel]

Change by Irit Katriel :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue34798] pprint ignores the compact parameter for dicts

[Irit Katriel]

Irit Katriel  added the comment:

> At the very least it should be made clear in the documentation that dicts are 
> not compacted.

According to https://docs.python.org/3/library/pprint.html compact impacts the 
way that sequences are displayed, and a dict is not a sequence.
So I'm not sure a documentation change is required.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue41598] rnd() + rndup() in math

[Vedran Čačić]

Vedran Čačić  added the comment:

> use more digits to manage rounding in decimal base, not only one but more (i 
> should think better and experiment on how many)

You don't have to. It's infinitely many. :-P Think, how many decimal digits 
would you need to accurately round numbers to a closest third (one trinary 
digit)? Here are some decimal digits: 2.1. If the next digit is 5, then 
it rounds to 2.0. If it is 7, it rounds to 2.1 (base 3). If it is 6, you still 
don't know anything. It can go arbitrarily far. Of course, the probability is 
lower with every digit, and at some point it becomes acceptable (you said for 
yourself it's acceptable even with one extra digit), but it's not 
mathematically correct.

And that one bit was just an illustration. In real life, 64-bit machines 
usually use at least 80-bit precision, so 16 extra bits. But it doesn't help 
your case, for the above reasons: this is simply not decimal rounding.

--

___
Python tracker 

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

[issue41598] rnd() + rndup() in math

[marco_ocram]

marco_ocram  added the comment:

i think in your long post you have underlined among others:
1. in binary implementation of floats one bit was reserved to rounding;
2. this one bit is not enough to manage a correct rounding in a converted 
decimal base;
my considerations:
3. someone i think had evaluated deciding rounding didn't worth more 
significative digits;
4. the only solution in general can be use more digits to manage rounding in 
decimal base, not only one but more (i should think better and experiment on 
how many);
5. the problem in general cannot be solved by an implementation of rounding but 
from a revision of the implementation of floats (i have solved pretty well my 
personal need but i'm speaking in general);
6. this is not really a weak impact i think, despite it's not impossible;
7. and last, i think the current implementation could derive from historical 
reasons when we worked on 8 bits machines, not 64 bits, and one bit was of 
worth, but i may be wrong.

--

___
Python tracker 

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

[issue41613] get_type_hints regression for 3.9 and 3.10

[Guido van Rossum]

Guido van Rossum  added the comment:

Not nice to snip the traceback.

--

___
Python tracker 

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

[issue10486] http.server doesn't set all CGI environment variables

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Hello Maarten,

> Using cgitb, I found out that the webdriver expects the environment variable 
> `HTTP_X_URWID_METHOD` to be set. The javascript sets the "X-Urwid-Method" 
> header (using XmlHttpRequest), but these are not visible by the CGI python 
> script.

> So some scripts extra Meta-Variables neet to be set

Thanks for your comment on this old issue. The topic under discussion was about 
some existing "more standard" CGI variables than special meta variables. 

Even if the first standard CGI variables issue get exposed, I doubt the meta 
variables will get added. I will think about considering the minimal change 
required to accomplish the task and close the issue.

--
stage:  -> needs patch

___
Python tracker 

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

[issue41616] Global variable in whole project and Relative imports problem

[Steven D'Aprano]

Steven D'Aprano  added the comment:

One issue per ticket please.

Versions 3.9 and older are all in feature freeze, they will not get new 
features.

Combining a global declaration with an assignment has been requested before, 
and rejected. If you want to discuss that feature again, you should raise it on 
the Python-Ideas mailing list first, but unless you have a stronger reason than 
just saving a line of code, it probably won't be accepted.

Project-wide globals has not, as far as I can remember, been requested before, 
but again it needs to be discussed on Python-Ideas first.

Your comments about relative imports don't seem to be either a feature request 
or a bug report, but just a vague complaint that it often causes problems. 
Please be more precise.

Problems with global variables are nearly always problems with global 
variables, not bugs with Python. Global variables are very easy to misuse and 
often cause problems.

https://weblogs.asp.net/wallen/6750

http://wiki.c2.com/?GlobalVariablesAreBad

--
nosy: +steven.daprano
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue41616] Global variable in whole project and Relative imports problem

[ManPython]

New submission from ManPython :

1. Curently we have easy option to declare global variable (GV) 
a) like this:
global var1
var1 = 'whatever'

b) with some improved version like this:
global var1 'whatever'
or:
global var1,var2, 'whatever1','whatever2'

c) The Python is in way to produce small lines of code but this philosophy 
around GV not offering this.


2. Can we have easy option to delclare global variable for whole project 
including MVC?
a) By this is requiments to call GV in any place like in Model, View or 
Controler and change thits var globaly.

b) I noticed that programers many often calling module in main to operate with, 
where this way made many problems withs Relative imports
https://stackoverflow.com/questions/30669474/beyond-top-level-package-error-in-relative-import
https://stackoverflow.com/questions/14132789/relative-imports-in-python-2-7/
https://stackoverflow.com/questions/35166821/valueerror-attempted-relative-import-beyond-top-level-package
https://stackoverflow.com/questions/4000/attempted-relative-import-beyond-toplevel-package

b) In my test the Relative imports made often problems (As imposible to load - 
most often Django, but similar with Pyside2) and I noticed that exist some 
relation with global var. In some of P36 version most often due to libs. Wan't 
checking this, expecting other way (more easy) to solve typical problems with 
GV.
1) in Django most often is meeting in config.py
2) in Pyside2 most often is meeting in main.py where we calling 
model,view,controler (or other liek utils) and we trying working in some core 
variables that limitig projects to easy manage GV

--
components: Interpreter Core
messages: 375799
nosy: ManPython
priority: normal
severity: normal
status: open
title: Global variable in whole project and Relative imports problem
type: enhancement
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

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

[issue23832] pdb's `longlist` shows only decorator if that one contains a lambda

[Irit Katriel]

Irit Katriel  added the comment:

pdb uses inspect.findsource for this, where this problem was fixed in issue 
1764286.

I believe this ticket can be closed.

--

___
Python tracker 

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

[issue26794] curframe can be None in pdb.py

[Jacek Pliszka]

Jacek Pliszka  added the comment:

Haven't seen it since then.

Stopped using 2.7 - using 3.6 in production and 3.7 in development now.

I believe it can be closed.

--

___
Python tracker 

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

[issue41615] sys.argv may be None or an empty list

[Jason R. Coombs]

New submission from Jason R. Coombs :

In [pypa/keyring#445](https://github.com/pypa/keyring/445) and issue839151, we 
learned that there are Python interpreters in which `sys.argv` is an empty 
list, is not a list, or is not initialized at all. Through use of 
`sys.argv[0]`, the documentation strongly implies that `sys.argv` is always a 
list of at least one element. The documentation makes no mention of these other 
cases. It would be nice if the documentation would describe what values (or 
absence thereof) are valid for `sys.argv`.

--
assignee: docs@python
components: Documentation
messages: 375796
nosy: docs@python, jaraco
priority: normal
severity: normal
status: open
title: sys.argv may be None or an empty list

___
Python tracker 

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

[issue41614] Items put on Queue in thread in child process sometimes not seen by parent process

[Alex Hall]

New submission from Alex Hall :

See attached file. The summary is that I start a Process, which starts a 
Thread, which puts some values on a Queue which was originally created by the 
parent process and passed down. Usually this works but occasionally the parent 
process doesn't see the items on the queue: queue.get() times out and 
queue.empty() is True, although queue.qsize() is accurate.

I can reproduce this on master:

Python 3.10.0a0 (heads/master:802726a, Aug 22 2020, 12:56:09) 
[GCC 7.5.0] on linux

as well as other versions I have installed which I've selected. On 3.6 it seems 
like the problem is even worse and some of my comments don't apply.

I've tested the script on Ubuntu 18.04.4, but the general problem seems to also 
happen on OSX although I can't confirm that now.

--
files: queue_bug.py
messages: 375795
nosy: alexmojaki
priority: normal
severity: normal
status: open
title: Items put on Queue in thread in child process sometimes not seen by 
parent process
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49422/queue_bug.py

___
Python tracker 

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

[issue37943] mimetypes.guess_extension() doesn’t get JPG right

[Felipe Rodrigues]

Felipe Rodrigues  added the comment:

@_savage, on the commit @xtreak referred, there's a note that "image/jpg" and 
some other non-standard mimetypes are only supported if `strict=False`[1]

So, this:

>>> mimetypes.guess_extension("image/jpg")

Gives no return. But this works:

>>> mimetypes.guess_extension("image/jpg", strict=False)
'.jpg'


-

I guess we could improve the current documentation [2]. It currently specifies 
correctly the `strict` behavior:


> The optional strict argument is a flag specifying whether the list of known 
> MIME types is limited to
> only the official types registered with IANA. When strict is True (the 
> default), only the IANA types
> are supported; when strict is False, some additional non-standard but 
> commonly used MIME types are 
> also recognized.

But I think it would be nice to have a table specifying what are those 
"non-standard but commonly used MIME types". Personally, I'd have a hard time 
guessing on a regular day of my life which of 'image/jpeg' and 'image/jpg' is 
standard or not. We could even add a nice note pointing out that the 
`common_types` property [3] is a list of those supported non-standard type .

Given the fact that the `strict` flag is used by different methods with the 
same behavior, maybe we could add a note on the top of the doc explaining the 
general meaning of that flag.



[1]: 
https://github.com/python/cpython/commit/2a99fd911ebeecedbb250a05667cd46eca4735b9#diff-fc65388a9cdf41980b2c31de5de67758R547

[2]: https://docs.python.org/3.10/library/mimetypes.html#mimetypes.guess_type

[3]: https://docs.python.org/3.10/library/mimetypes.html#mimetypes.common_types

--
nosy: +fbidu

___
Python tracker 

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

[issue41576] document BaseException in favour of bare except in error tutorial

[Thomas Grainger]

Thomas Grainger  added the comment:

The purpose of this tutorial section is to document how to catch all types of 
exceptions and extract the type and value. When this is required, 
`BaseException as err:` is the preferred approach.

This document still mentions the alternative approach so that readers will know 
what it means when they encounter it, and know to upgrade it to the py2.4+ 
syntax

--

___
Python tracker 

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

[issue41613] get_type_hints regression for 3.9 and 3.10

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

This looks like a problem with the __globals__ of the NamedTuple.__new__

--

___
Python tracker 

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

[issue41613] get_type_hints regression for 3.9 and 3.10

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
components: +Library (Lib)
versions: +Python 3.10, Python 3.9

___
Python tracker 

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

[issue41613] get_type_hints regression for 3.9 and 3.10

[Batuhan Taskaya]

New submission from Batuhan Taskaya :

The attached script works perfectly fine under Python 3.8, but it crashes in 
3.9/3.10.

$ ./py38/python typing_fail.py (3.8.5+)
{'a': , 'b': }
$ ./py39/python typing_fail.py (3.9.0rc1+)
[SNIP]
TypeError: 'NoneType' object is not subscriptable
$ ./cpython/python typing_fail.py (3.10.0a0)
[SNIP]
TypeError: 'NoneType' object is not subscriptable

--
files: typing_fail.py
messages: 375791
nosy: BTaskaya, gvanrossum, levkivskyi, lukasz.langa
priority: normal
severity: normal
status: open
title: get_type_hints regression for 3.9 and 3.10
Added file: https://bugs.python.org/file49421/typing_fail.py

___
Python tracker 

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

[issue40994] Very confusing documenation for abc.Collections

[Cheryl Sabella]

Cheryl Sabella  added the comment:


New changeset 0694b82381ff27e10bb15172da0832a7e65aaa2d by Miss Islington (bot) 
in branch '3.8':
bpo-40994: Ungroup items in collections.abc documentation for improved clarity 
(GH-21880) (#21927)
https://github.com/python/cpython/commit/0694b82381ff27e10bb15172da0832a7e65aaa2d


--

___
Python tracker 

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

[issue40994] Very confusing documenation for abc.Collections

[Cheryl Sabella]

Cheryl Sabella  added the comment:


New changeset f497bbeed08e5a7f83adecf330b61fb88e9c3fa6 by Miss Islington (bot) 
in branch '3.9':
bpo-40994: Ungroup items in collections.abc documentation for improved clarity 
(GH-21880) (#21926)
https://github.com/python/cpython/commit/f497bbeed08e5a7f83adecf330b61fb88e9c3fa6


--

___
Python tracker 

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

[issue21041] pathlib.PurePath.parents rejects negative indexes

[Yaroslav Pankovych]

Yaroslav Pankovych  added the comment:

Any thoughts about that folks? It's a pretty old bug, let's decide smth for it.

--

___
Python tracker 

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

[issue41598] rnd() + rndup() in math

[Vedran Čačić]

Vedran Čačić  added the comment:

I think you don't know what paraphrasing means. Or maybe I don't know it, but 
in any case, I'm well aware what Von Neumann said, and how it is usually 
misunderstood in today's society. "Living in the state of sin" is simply an 
emotionally powerful metaphor, and it pertains to the philosophical 
impossibility of something, whether or not there are strong reasons to "do it 
anyway" and even good methods of faking/approximating it. Same as "detecting 
infinite loops programmatically", "passing objects by value", or "having side 
effects in a referentially transparent language". :-)

I agree that Python is a language where practicality beats purity, and as I 
said, there is a sensible interface for the implementation about which we agree 
(except for a detail: I'd actually _force_ people to import the rounding modes 
from decimal module, to at least hint to them what exactly they are doing and 
what the preferred approach is). But I still think that arguments for that are 
very weak.

First, yes, there is a very small probability of calculations _randomly_ ending 
with abc.de5...0 (in the Platonic sense) [so it actually manifests as a 
problem], but there is much greater probability (though still small) that 
calculations _theoretically_ ending with abc.de5 actually end with 
abc.de4...7 [and thus are rounded down anyway, despite your insistence on 
modes]. People _will_ think "hey, I did the right thing by specifying the 
mode--why does it still acts funny?"

"there are reasonable use-cases for different rounding modes even when using 
floats.": absolutely. But they are _binary_ rounding modes! I think you should 
read the standard. It is actually two standards, one for binary and one for 
decimal arithmetic. (The second one is implemented fairly faithfully in the 
decimal module; the first one is, through libc, the one that Python floats are 
based upon).

The [binary] standard says, more or less, that the result should be as if the 
value was calculated with the infinite number or extra [binary] digits (of 
course, in practice it should just be some extra precision, but again, of 
_binary_ digits), and then, when fitting that value into a smaller [binary] 
register with smaller available number of [binary] digis, all extra [binary] 
digits are discarded (not stored) and some ending [binary] digits retained are 
modified according to the value of some of the discarded [binary] digits and 
the rounding mode. For example:

"""
The 24-bit significand will stop at position 23, shown as the underlined bit 0 
above. The next bit, at position 24, is called the round bit or rounding bit. 
It is used to round the 33-bit approximation to the nearest 24-bit number 
(there are specific rules for halfway values, which is not the case here). This 
bit, which is 1 in this example, is added to the integer formed by the leftmost 
24 bits.
"""

You see it speaks about _bits_, not decimal digits. In the same way, _decimal_ 
rounding would take a value calculated with some extra precision of _decimal_ 
digits, and when storing them with the smaller number of _decimal_ digits, 
discard extra... blah blah as above. But you cannot round binary numbers to 
decimal digits. It's as if you tried to round 0.45 to one trinary digit after 
the integer point. The answer is 0.1 in base 3, but it isn't expressible in 
decimals. And it doesn't work:

>>> Decimal('0.45').quantize(Decimal(1/3))
decimal.InvalidOperation: []

because the authors of quantize have thought about that. The documentation says 
"""Unlike other operations, if the length of the coefficient after the quantize 
operation would be greater than precision, then an InvalidOperation is 
signaled.""" In effect, rounding cannot increase the number of significant 
digits. And it would do that if you're rounding to an incompatible base, 
whether 2 to 10 or 10 to 3.

--

___
Python tracker 

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

[issue41598] rnd() + rndup() in math

[marco_ocram]

marco_ocram  added the comment:

@Vedran:
I'm sorry about my "quick-and-dirty implementations". As i've already stated 
the problem's more deep i expect, despite the second half up rounding for my 
needs now (after your observation) work well. I've verified other languages 
have the same problem with floats operations and roundings.

@Steven:
"Are you satisfied that adding a rounding mode to the built-in `round` function 
is a better solution than a series of functions in the math module? If so, I 
will change the title to reflect that."
I fully agree with the sentence and with all the content of your writings. I 
think the decimal module is excellent and can do an extraordinary work (as 
extraordinary i suppose was the work of its coders) but floats also are fine 
for common people use, i see only the rounding as main them problem. It's very 
unpleasant to round 2.8-1.3 half up and without tricks obtain a misleading 
results.
I think working on the last decimal digit if all are used the problem could be 
solved, but with a lot of study (at least for me if i have) cause one purpose 
have to be maintain good performances in addition to results always corrects.

This is only a possibility to improve the core language, i think one function 
with more common rounding ways, as in wikipedia (in gnu c i don't see just "to 
nearest, ties away from zero" or half up we discuss) or in decimals module, can 
be useful to reduce the need of individual coders implementation on a not so 
simple question cause them needs not satisfied by the round() as banking 
rounding.

--

___
Python tracker 

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

[issue41573] Correct wrong sentences in General FAQ

[Terry J. Reedy]

Change by Terry J. Reedy :


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

[issue41573] Correct wrong sentences in General FAQ

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 429a86a12016ae42ea32d754e0725cbee8e99808 by Miss Islington (bot) 
in branch '3.9':
bpo-41573: Update release versions in General FAQ (GH-21915) (#21938)
https://github.com/python/cpython/commit/429a86a12016ae42ea32d754e0725cbee8e99808


--

___
Python tracker 

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