[issue10915] Make the PyGILState API compatible with multiple interpreters

[Nick Coghlan]

Nick Coghlan  added the comment:

A more recent discussion of this on python-dev: 
https://mail.python.org/pipermail/python-dev/2019-January/156095.html

The situation there appears to be a case of "Hand off an OS level thread from 
the creating interpreter to a different subinterpreter. As far as I can tell, 
calling GILState_Ensure in such a thread will still acquire the GIL of the 
creating interpreter (or something equally nonsensical)."

It's a single-threaded application using subinterpreters, but all the callbacks 
from the NumPy code end up hitting the original interpreter that initialised 
the thread local state in the main thread.

--

___
Python tracker 

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

[issue35838] ConfigParser calls optionxform twice when assigning dict

[INADA Naoki]

INADA Naoki  added the comment:

I think it's easy to solve this particular case.
But there may be some other cases.

optionxform must be idempotent?  If so, this is document issue.

--
nosy: +inada.naoki

___
Python tracker 

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

[issue35840] Control flow inconsistency on closed asyncio stream

[Marc Schlaich]

Marc Schlaich  added the comment:

After having a closer look I fear that there isn't a correct implementation for 
half closed sockets and returning True from eof_received results in a 
fundamentally broken state machine.

I'm not sure if a selector implementation can handle half closed sockets, at 
least I'm pretty sure that this is not supported on Windows 
(https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-select).

--

___
Python tracker 

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

[issue35701] [uuid] 3.8 breaks weak references for UUIDs

[David Heiberg]

David Heiberg  added the comment:

I have submitted a PR for the documentation. Hopefully this is enough to 
resolve the issue and close.

--

___
Python tracker 

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

[issue35701] [uuid] 3.8 breaks weak references for UUIDs

[STINNER Victor]

STINNER Victor  added the comment:


New changeset ea446409cd5f1364beafd5e5255da673f285 by Victor Stinner (David 
H) in branch 'master':
bpo-35701: Update doc for UUID weak referencing (GH-11621)
https://github.com/python/cpython/commit/ea446409cd5f1364beafd5e5255da673f285


--

___
Python tracker 

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

[issue35701] [uuid] 3.8 breaks weak references for UUIDs

[STINNER Victor]

STINNER Victor  added the comment:

I merged the doc change. I understand that the issue can now be closed, thanks 
to everyone who helped here!

--
priority: release blocker -> 
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

[issue35431] Add a function for computing binomial coefficients to the math module

[kellerfuchs]

kellerfuchs  added the comment:

Hi everyone,

Sorry for the lack of reply, I severely underestimated how exhausting the 
holiday season would be.
Catching up with the comments right now.

--

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[kellerfuchs]

kellerfuchs  added the comment:

> Start with an initial patch that implements this simplest possible 
> implementation, accompanied by clean documentation and thorough testing.
>
> Once everyone has agreed on the API (i.e. calling it "comb()", how to handle 
> various input datatypes, and handling of corner cases), and the patch is 
> applied, only then turn to a second pass for optimizations

+1 from me on that.

@Yash: Thanks a bunch for starting on the implementation.  I will have a look 
shortly  :)

--

___
Python tracker 

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

[issue35822] _queue _queuemodule.c is missing inside the Setup file

[INADA Naoki]

INADA Naoki  added the comment:

_queue is normal extension module, not builtin module.
In my environment:

>>> import _queue
>>> _queue.__file__
'/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_queue.cpython-37m-darwin.so'

It seems your environment is somewhat broken.

--
nosy: +inada.naoki

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[kellerfuchs]

kellerfuchs  added the comment:

So, I rebased Yash's and my branches, and merged them together.  The result is 
still in PR#11018.

This involved a few changes, which seem to reflect the consensus here:
- raise ValueError if k>n ;
- rename the function to math.combinations.

--

___
Python tracker 

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

[issue35808] Let's retire pgen

[BTaskaya]

Change by BTaskaya :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue10915] Make the PyGILState API compatible with multiple interpreters

[Ronald Oussoren]

Change by Ronald Oussoren :


--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[kellerfuchs]

kellerfuchs  added the comment:

@Raymond Hettinger
> Let's name this comb() instead of binomial() please (as requested by me, 
> Mark, and Tim).

(Replying here to keep the discussion in a single place.)

As far as I can tell from the discussions here, Steven and you stated a 
preference for the shortened names, and that's it.
There was also no reply to my comment about `comb` being confusing (due to the 
collision with an English word).

Since there was, however, pretty clear agreement on calling it after 
combinations (shortened or not) rather than binomial(), I went with this.

--

___
Python tracker 

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

[issue35841] Datetime strftime() does not return correct week numbers for 2019

[Tommy Rowland]

New submission from Tommy Rowland :

This relates to the calculation of the week number from a given datetime, when 
calling the strftime method. If you call isocalendar() on the datetime.datetime 
object for the date ‘2018-12-31’, the week number returned is 1, which is 
correct. This is the same when checking the week attribute for the pandas 
timestamp equivalent. However, when you call strftime on this object (either 
datetime or timestamp), passing the ‘%W’ offset string, it returns 53, and then 
returns 00 for the remainder of the week. It seems that the rest of the weeks 
in 2019 are out by 1 when returned using this function. This issue seems to be 
present with the strptime function also.

--
components: Extension Modules, Windows
files: Python Datetime Issue.JPG
messages: 334462
nosy: paul.moore, steve.dower, tim.golden, tr12, zach.ware
priority: normal
severity: normal
status: open
title: Datetime strftime() does not return correct week numbers for 2019
type: behavior
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file48083/Python Datetime Issue.JPG

___
Python tracker 

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

[issue35841] Datetime strftime() does not return correct week numbers for 2019

[Paul Ganssle]

Paul Ganssle  added the comment:

Possibly related to 35535.

--
nosy: +p-ganssle

___
Python tracker 

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

[issue27749] multprocessing errors on Windows: WriteFile() argument 1 must be int, not None; OSError: handle is closed

[Michael Jacob]

Michael Jacob  added the comment:

Does this ticket track the issue in its title or the native crash? If it's the 
latter, is there a new ticket for the None _handle or shall I create one?

--
nosy: +Michael Jacob2
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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Cheryl Sabella]

Cheryl Sabella  added the comment:

@jcrmatos - Sounds like you're on the right track.  :-)

Based on the steps you've outlined, I just had one question.  Were you able to 
rebuild the docs locally in order to see how your changes looked?  Here's the 
direct link to building the docs:
https://devguide.python.org/documenting/#building-doc

In section 7.5.1, it mentions Windows, so you should be able to follow that.  
Although, I've had to use `./make html` in Powershell, so if `make html` 
doesn't work, then try that.

--

___
Python tracker 

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

[issue35842] A potential bug about use of uninitialised variable

[rongxin]

New submission from rongxin :

In the source file mmapmodule.c, the function mmap_subscript contains a 
potential bug about the use of uninitialised variable.


mmapmodule.c:

764 static PyObject *
765 mmap_subscript(mmap_object *self, PyObject *item)
766 {
...
else if (PySlice_Check(item)) {
782Py_ssize_t start, stop, step, slicelen;
783
784if (PySlice_Unpack(item, &start, &stop, &step) < 0) {
785return NULL;
786}
787slicelen = PySlice_AdjustIndices(self->size, &start, &stop, step);
 ...

In Line 782 of the file mmapmodule.c, the variable stop is not initialised and 
will be passed to the function PySlice_Unpack as the third parameter. Inside 
the function, it is likely that stop is not initialised. Please see the 
following code. 

sliceobject.c:
196 int
197 PySlice_Unpack(PyObject *_r,
198   Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t *step)
199 {
...
231if (r->stop == Py_None) {
232*stop = *step < 0 ? PY_SSIZE_T_MIN : PY_SSIZE_T_MAX;
233}
234else {
235if (!_PyEval_SliceIndex(r->stop, stop)) return -1;
236}


The third parameter **stop** may be changed at line 232 or 235. However, at 
Line 235, it is still likely that **stop** is not initialised at Line 235 where 
**stop** is passed as the second parameter. Note that, at Line 235, we only 
know r->stop!=Py_None. The following is the code snippet of the function 
_PyEval_SliceIndex.


ceval.c:
4718 int
4719 _PyEval_SliceIndex(PyObject *v, Py_ssize_t *pi)
4720 {
4721 if (v != Py_None) {
4722 Py_ssize_t x;
4723 if (PyIndex_Check(v)) {
4724 x = PyNumber_AsSsize_t(v, NULL);
4725 if (x == -1 && PyErr_Occurred())
4726 return 0;
4727 }
4728 else {
4729 PyErr_SetString(PyExc_TypeError,
4730 "slice indices must be integers or "
4731 "None or have an __index__ method");
4732 return 0;
4733 }
4734 *pi = x;
4735 }
4736return 1;
4737 }

As we can see, it is likely that when the third parameter v can be NULL, then 
the function _PyEval_SliceIndex will return 1. In the caller function 
PySlice_Unpack, at Line 235, the condition **if (!_PyEval_SliceIndex(r->stop, 
stop))** is not satisfied, and thus it will go to Line 238 which returns 0. In 
the caller function mmap_subscript in the file mmapmodule.c, at Line 784, since 
the return value is 0, and thus the path condition **PySlice_Unpack(item, 
&start, &stop, &step) < 0** is not satisfied. It will continue to execute the 
Line 787. The uninitialised variable **stop** again will be passed to the 
function PySlice_AdjustIndices as the third parameter. **stop** then will be 
dereferenced without initialisation. Please see the following.

sliceobject.c:
241 Py_ssize_t
242 PySlice_AdjustIndices(Py_ssize_t length,
243  Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t step)
...
260 if (*stop < 0) {
261*stop += length;
...

--
messages: 334466
nosy: wurongxin1987
priority: normal
severity: normal
status: open
title: A potential bug about use of uninitialised variable
type: security
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

[issue35815] Able to instantiate a subclass with abstract methods from __init_subclass__ of the ABC

[BTaskaya]

BTaskaya  added the comment:

I debugged object.__new__ and i saw the subclass you are trying to initalize 
doesn't have proper signature of abstract classes (it returns 0 from flags & 
Py_TPFLAGS_IS_ABSTRACT)

However it has __abstractmethods__ entry. Currently i'm trying to find why it 
is happening.

Type Name: Derived
Flags: 284161 
Abstract: 1048576 
Flags & Abstract: 0

--
nosy: +BTaskaya

___
Python tracker 

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

[issue35842] A potential bug about use of uninitialised variable

[rongxin]

rongxin  added the comment:

BTW, if this bug is true, there is a similar code snippet in the same file.
mmapmodule.c:
845 static int
846 mmap_ass_subscript(mmap_object *self, PyObject *item, PyObject *value)
847 {
...
888else if (PySlice_Check(item)) {
889Py_ssize_t start, stop, step, slicelen;
890Py_buffer vbuf;
891
892if (PySlice_Unpack(item, &start, &stop, &step) < 0) {
893return -1;
894}
895slicelen = PySlice_AdjustIndices(self->size, &start, &stop, step);

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

Hello,

I didn't do anything locally. I did the change and preview it on GitHub's web 
interface.

Has I said, I did a PR to my own fork and now I think I have to do a PR to the 
cpython master. Is that correct?
The PR to my own fork was required, or the commit was enough?

Now I have an option to delete the fix-issue-35835 branch.
Should I do it? I read some Git tutorials and I think I can, but can you 
confirm?


Thanks in advance,

JM

--

___
Python tracker 

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

[issue35838] ConfigParser calls optionxform twice when assigning dict

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This seems to be a bug with read_dict which is used internally when a 
dictionary is directly assigned. In read_dict optionxform is called with key 
[0] to check for duplicate and the transformed value is again passed to 
self.set which also calls optionxform [1] causing optionxform to be applied 
twice. A possible fix would be to assign the transformed key to a temporary 
variable to check for duplicate and then pass the original key to self.set ? My 
patch gives correct value and no tests fail on master. I can make a PR with 
test for this if my analysis is correct.

This fixes the below since the key is stored correctly now. 

print(ini['section A']['key 1'])# OK
print(ini['section A']['(key 1)'])  # Raises KeyError

I think for iterating over the section items [2] need to be used and the 
reported code can be written as below

for key, value in ini.items('section A'):
print(key + ', ' + value)

[0] 
https://github.com/python/cpython/blob/ea446409cd5f1364beafd5e5255da673f285/Lib/configparser.py#L748
[1] 
https://github.com/python/cpython/blob/ea446409cd5f1364beafd5e5255da673f285/Lib/configparser.py#L903
[2] 
https://docs.python.org/3.8/library/configparser.html#configparser.ConfigParser.items

# sample reproducer

import io
import configparser

ini = configparser.ConfigParser()
ini.optionxform = lambda x: '(' + x + ')'
ini.read_dict({'section A': {'key 1': 'value 1'}})

inifile = io.StringIO()
ini.write(inifile)
print(inifile.getvalue())

$ ./python.exe ../backups/bpo35838_1.py
[section A]
((key 1)) = value 1

# Possible patch

$ git diff -w | cat
diff --git a/Lib/configparser.py b/Lib/configparser.py
index 79a991084b..1389f4ac08 100644
--- a/Lib/configparser.py
+++ b/Lib/configparser.py
@@ -745,13 +745,13 @@ class RawConfigParser(MutableMapping):
 raise
 elements_added.add(section)
 for key, value in keys.items():
-key = self.optionxform(str(key))
+option_key = self.optionxform(str(key))
 if value is not None:
 value = str(value)
-if self._strict and (section, key) in elements_added:
-raise DuplicateOptionError(section, key, source)
-elements_added.add((section, key))
-self.set(section, key, value)
+if self._strict and (section, option_key) in elements_added:
+raise DuplicateOptionError(section, option_key, source)
+elements_added.add((section, option_key))
+self.set(section, str(key), value)

 def readfp(self, fp, filename=None):
 """Deprecated, use read_file instead."""


$ ./python.exe ../backups/bpo35838_1.py
[section A]
(key 1) = value 1

--
nosy: +xtreak
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

[issue31456] SimpleCookie fails to parse any cookie if an entry has whitespace in the name

[Rémi Lapeyre]

Change by Rémi Lapeyre :


--
nosy: +remi.lapeyre

___
Python tracker 

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

[issue35842] A potential bug about use of uninitialised variable

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Your analysis would be (almost) correct if a slice object could have a stop 
value of NULL. It's wrong in that the error would be a NULL deference, not a 
silent use of an uninitialized value, but it would be a bug. In your scenario 
where v == NULL, it would pass the test for v != Py_None, then call 
PyIndex_Check(v), and since the macro doesn't check for the passed value being 
NULL, it would perform a NULL deference.

But even that's not possible; PySlice_New (which is ultimately responsible for 
all slice construction) explicitly replaces any argument of NULL with Py_None, 
so there is no such thing as a slice with *any* value being NULL.

So since r->stop is definitely non-NULL, either:

1. It's None, PySlice_Unpack line 232 executes, and stop is initialized

or

2. It's non-None, _PyEval_SliceIndex is called with a v that is definitely not 
None and non-NULL, so it always enters the `if (v != Py_None) {` block, and 
either it received a value index integer, in which case it initializes *pi (aka 
stop) and returns 1 (success), or returns 0 (failure), which means stop is 
never used.

The only way you could trigger your bug is to make a slice with an actual NULL 
for its stop value (and as noted, the bug would be a NULL dereference in 
PyIndex_Check, not a use of an uninitialized value, because v != Py_None would 
return true for v == NULL), which is only possible through intentionally 
misusing PySliceObject (reaching in and tweaking values of the struct 
directly). And if you can do that, you're already a C extension (or ctypes 
code) and can crash the interpreter any number of ways without resorting to 
this level of complexity.

--
nosy: +josh.r
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

[issue31456] SimpleCookie fails to parse any cookie if an entry has whitespace in the name

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

It may be relevant: Ruby accept whitespaces in the name of the morsel:

➜  ~ irb
irb(main):002:0> require "cgi"
=> true
irb(main):003:0> CGI::Cookie::parse "ASDF=stuff; ASDF space=more stuff"
=> {"ASDF"=>##https://bugs.python.org/issue31456>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Cheryl Sabella]

Cheryl Sabella  added the comment:

As Karthikeyan said, you do need to open a PR against the CPython master.  I'm 
not a Git expert, but this page (section 3.3) discusses the steps to open that 
PR:
https://devguide.python.org/pullrequest/

Those are the steps I follow and it's a good write-up so there's not much I can 
add to it.  I don't think the PR on your own fork was required.  It doesn't 
usually ask to delete the branch until the PR against CPython master has been 
merged (which is the last step in section 3.3), but since you merged against 
your own fork, that's probably why it's asking now.  Do you still get an option 
to create a PR against CPython master using your branch as per this part of 
section 3.3?

> Finally go on https://github.com//cpython: you will see a box 
> with the branch you just pushed and a green button that allows you to create 
> a pull request against the official CPython repository.

--

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Steven: I'm assuming Brett rearranged the title to put emphasis on the new 
function and to place it earlier in the title. Especially important if you're 
reading e-mails with the old subject on an e-mail client with limited subject 
preview lengths, you end up seeing something like:

"The math module should provide a function for computing..."

rather than the more useful:

"Add a function for computing binomial coefficients to t..."

--
nosy: +josh.r

___
Python tracker 

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

[issue35842] A potential bug about use of uninitialised variable

[rongxin]

rongxin  added the comment:

Hi, Josh Rosenberg. As you mentioned PySlice_New (which is ultimately 
responsible for all slice construction) explicitly replaces any argument of 
NULL with Py_None, I am not sure whether this is always true r->stop cannot be 
NULL. I detected this bug using the code of Python 2.7.15. The implementation 
of _PyEval_SliceIndex is shown as followings. Please read the comments of this 
functions, and it is possible that v would be NULL. I wonder whether your 
assumption r->stop cannot be NULL will be broken in Python 2.7.15



/* Extract a slice index from a PyInt or PyLong or an object with the
   nb_index slot defined, and store in *pi.
   Silently reduce values larger than PY_SSIZE_T_MAX to PY_SSIZE_T_MAX,
   and silently boost values less than PY_SSIZE_T_MIN to PY_SSIZE_T_MIN.
   Return 0 on error, 1 on success.
*/
/* Note:  If v is NULL, return success without storing into *pi.  This
   is because_PyEval_SliceIndex() is called by apply_slice(), which can be
   called by the SLICE opcode with v and/or w equal to NULL.
*/
int
_PyEval_SliceIndex(PyObject *v, Py_ssize_t *pi)
{
if (v != NULL && v != Py_None) {
Py_ssize_t x;
if (PyInt_Check(v)) {
/* XXX(nnorwitz): I think PyInt_AS_LONG is correct,
   however, it looks like it should be AsSsize_t.
   There should be a comment here explaining why.
*/
x = PyInt_AS_LONG(v);
}
else if (PyIndex_Check(v)) {
x = PyNumber_AsSsize_t(v, NULL);
if (x == -1 && PyErr_Occurred())
return 0;
}
else {
PyErr_SetString(PyExc_TypeError,
"slice indices must be integers or "
"None or have an __index__ method");
return 0;
}
*pi = x;
}
return 1;
}

--

___
Python tracker 

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

[issue35842] A potential bug about use of uninitialised variable

[rongxin]

rongxin  added the comment:

I think this bug is valid at least in Python 2.7, as I mentioned the 
implementation of _PyEval_SliceIndex is different from the one in Python 3.8. 
The condition " if (v != NULL && v != Py_None) " will bypass the NULL pointer 
dereference. Would you please check this again? Thanks.

--
status: closed -> open
versions: +Python 2.7 -Python 3.8

___
Python tracker 

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

[issue35842] A potential bug about use of uninitialised variable

[rongxin]

Change by rongxin :


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

[issue35535] time.strptime() unexpectedly gives the same result for %U and %W for 2018

[Emmanuel Arias]

Emmanuel Arias  added the comment:

I try to reproduce and confirm the xtreak example, and how xtreak and p-ganssle 
explain, I think that the behavoir is correct according the documentation. 

I would like to know why there is difference between 2.3.4 (Paul Keating 
example) and cpython master

--
nosy: +eamanu
Added file: https://bugs.python.org/file48084/test.c

___
Python tracker 

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

[issue32834] test_gdb fails with Posix locale in 3.7

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This passes on my Ubuntu box and fails for the commit before issue34537 with 
the stack trace as per the original report.

karthi@ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ LC_ALL=C ./python -We -m test 
-vuall -m test_strings test_gdb
== CPython 3.8.0a0 (heads/master:ea446409cd, Jan 28 2019, 15:07:17) [GCC 5.4.0 
20160609]
== Linux-4.4.0-127-generic-x86_64-with-glibc2.17 little-endian
== cwd: /home/karthi/cpython/build/test_python_19425
== CPU count: 1
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.89 [1/1] test_gdb
GDB version 8.2:
GNU gdb (Ubuntu 8.2-0ubuntu1~16.04.1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings ... ok

--

Ran 1 test in 3.080s

OK

== Tests result: SUCCESS ==

1 test OK.

Total duration: 3 sec 571 ms
Tests result: SUCCESS
karthi@ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ git checkout 
7279b5125e7c5d84a473d250b27d353cb7f6628e~1 
[...]
karthi@ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ LC_ALL=C ./python -We -m test 
-vuall -m test_strings test_gdb
== CPython 3.8.0a0 (heads/master:ea446409cd, Jan 28 2019, 15:07:17) [GCC 5.4.0 
20160609]
== Linux-4.4.0-127-generic-x86_64-with-glibc2.17 little-endian
== cwd: /home/karthi/cpython/build/test_python_19484
== CPU count: 1
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.91 [1/1] test_gdb
GDB version 8.2:
GNU gdb (Ubuntu 8.2-0ubuntu1~16.04.1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings ... FAIL

==
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings
--
Traceback (most recent call last):
  File "/home/karthi/cpython/Lib/test/test_gdb.py", line 340, in test_strings
check_repr('\u2620')
  File "/home/karthi/cpython/Lib/test/test_gdb.py", line 332, in check_repr
self.assertGdbRepr(text)
  File "/home/karthi/cpython/Lib/test/test_gdb.py", line 278, in assertGdbRepr
self.assertEqual(gdb_repr, exp_repr,
AssertionError: "'\\u2620'" != "'☠'"
- '\u2620'
+ '☠'
 : "'\\u2620'" did not equal expected "'☠'"; full output was:
Breakpoint 1 at 0x5f9036: file Python/bltinmodule.c, line 1178.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, builtin_id (self=self@entry=, v='\u2620') at 
Python/bltinmodule.c:1178
1178
#0  builtin_id (self=, v='\u2620') at Python/bltinmodule.c:1178


--

Ran 1 test in 1.979s

FAILED (failures=1)
test test_gdb failed
test_gdb failed

== Tests result: FAILURE ==

1 test failed:
test_gdb

Total duration: 2 sec 576 ms
Tests result: FAILURE

--

___
Python tracker 

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

[issue35841] Datetime strftime() does not return correct week numbers for 2019

[Paul Ganssle]

Paul Ganssle  added the comment:

I think this is not a bug. bpo-35535 is probably also intended behavior, but 
that is less certain.

The misunderstanding here is that %W does not give you the ISO week number, 
from the documentation:

%W: Week number of the year (Monday as the first day of the week) as a 
decimal number.
All days in a new year preceding the first Monday are considered to be 
in week 0.


If you want the ISO week number, I think you need %V, which *is* the ISO week:

>>> datetime(2018, 12, 31).strftime("%V %W")

'01 53'

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

[issue35707] time.sleep() should support objects with __float__

[Josh Rosenberg]

Josh Rosenberg  added the comment:

You've got a reference leak in your __index__ based paths. PyNumber_Index is 
returning a new reference (either to the existing obj, or a new one, if the 
existing obj isn't already an int). You never release this reference. Simplest 
fix is to make intobj top level, initialized to NULL, and Py_XDECREF it along 
the convert_from_int code path (you can't DECREF it in the index specific path 
because it needs to survive past the goto, since it's replacing obj).

I'm also mildly concerned by how duplicative the code becomes post-patch. If 
it's not a major performance hit (don't think it is; not even sure the API is 
even used anymore), perhaps just implement _PyTime_ObjectToTime_t as a wrapper 
for _PyTime_ObjectToDenominator (with a denominator of 2, so rounding 
simplifies to just 0 == round down, 1 == round up)?

Example:

int
_PyTime_ObjectToTime_t(PyObject *obj, time_t *sec, _PyTime_round_t round)
{
long numerator;
if (_PyTime_ObjectToDenominator(obj, sec, &numerator, 2, round) == 0) {
   if (numerator) {
   if (*sec == _Py_IntegralTypeMax(time_t)) {
   error_time_t_overflow();
   return -1;
   }
   ++*sec;
   }
   return 0;
}
return -1;
}

Sorry for not commenting on GitHub, but my work computer has a broken Firefox 
that GitHub no longer supports properly.

--
nosy: +josh.r

___
Python tracker 

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

[issue35842] A potential bug about use of uninitialised variable

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Yes, the 2.7 version of _PyEval_SliceIndex would bypass the NULL pointer 
dereference, so *if* you could make a slice with a NULL stop value, you could 
trigger a read from uninitialized stack memory, rather than dying due to a NULL 
pointer dereference.

But just like Python 3, 2.7's PySlice_New explicitly replaces all NULLs with 
None ( https://github.com/python/cpython/blob/2.7/Objects/sliceobject.c#L60 ), 
so such a slice cannot exist.

Since you can't make a slice with a NULL value through any supported API, and 
any unsupported means of doing this means you already have the ability to 
execute arbitrary code (and do far worse things that just trigger a read from 
an uninitialized C stack value), the fact that _PyEval_SliceIndex returns 
success for v == NULL is irrelevant; v isn't NULL in any code path aside of the 
specific one documented (the SLICE opcode, gone in Py3, which can pass in NULL, 
but uses defaults of 0 and PY_SSIZE_T_MAX for low and high respectively, so the 
silent success just leaves the reasonable defaults set), because all other uses 
use slice objects as the source for v, and they cannot have NULL values.

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue35808] Let's retire pgen

[Emmanuel Arias]

Emmanuel Arias  added the comment:

Hello!

I can help if you consider it appropriate :-)

--
nosy: +eamanu

___
Python tracker 

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

[issue35842] A potential bug about use of uninitialised variable

[Josh Rosenberg]

Josh Rosenberg  added the comment:

One additional note, just in case you're wondering. slice explicitly does not 
set Py_TPFLAGS_BASETYPE (in either Py2 or Py3), so you can't make a subclass of 
slice with NULLable fields by accident (you'll get a TypeError the moment you 
try to define it). There is one, and only one, slice type, and its fields are 
never NULL.

--

___
Python tracker 

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

[issue35843] importlib.util docs for namespace packages innaccurate

[Anthony Sottile]

New submission from Anthony Sottile :

For instance:


# `a` is an empty directory, a PEP 420 namespace package

>>> import importlib.util
>>> importlib.util.find_spec('a')
ModuleSpec(name='a', loader=None, origin='namespace', 
submodule_search_locations=_NamespacePath(['/tmp/x/a']))


https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.origin

> ...  Normally “origin” should be set, but it may be None (the default) which 
> indicates it is unspecified (e.g. for namespace packages).

above the `origin` is `'namespace'`

https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.submodule_search_locations

> List of strings for where to find submodules, if a package (None otherwise).

However the `_NamespacePath` object above is not indexable:

>>> x = importlib.util.find_spec('a').submodule_search_locations
>>> x[0]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '_NamespacePath' object does not support indexing


I can work around however with:

>>> next(iter(x))
'/tmp/x/a'


==


so I guess a few things can/should come out of this:

- Document the `'namespace'` origin
- Document that `submodule_search_paths` is a Sized[str] instead
- Add `__getitem__` to `_NamespacePath` such that it implements the full 
`Sized` protocol

--
assignee: docs@python
components: Documentation
messages: 334484
nosy: Anthony Sottile, docs@python
priority: normal
severity: normal
status: open
title: importlib.util docs for namespace packages innaccurate
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue35843] importlib.util docs for namespace packages innaccurate

[Anthony Sottile]

Anthony Sottile  added the comment:

Hmmm, it appears this was changed in python3.7 to have `None` for the origin 
instead of `'namespace'` -- however the `submodule_search_locations` is still 
not indexable:



>>> importlib.util.find_spec('a')
ModuleSpec(name='a', loader=None, 
submodule_search_locations=_NamespacePath(['/tmp/x/a']))
>>> importlib.util.find_spec('a').origin
>>> spec = importlib.util.find_spec('a')
>>> spec.submodule_search_locations
_NamespacePath(['/tmp/x/a'])
>>> spec.submodule_search_locations[0]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '_NamespacePath' object does not support indexing

--

___
Python tracker 

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

[issue35707] time.sleep() should support objects with __float__

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> I'm also mildly concerned by how duplicative the code becomes post-patch.

I know, that's why I added that comment on GitHub.

> perhaps just implement _PyTime_ObjectToTime_t as a wrapper for 
> _PyTime_ObjectToDenominator

Sure, but will that increase the chances of PR 11636 being accepted? Unless a 
core developer who is willing to merge that PR asks me that, I'd rather not add 
extra complications to that PR. (to be clear: I mean no offense, it's just that 
getting a CPython PR accepted is hard)

--

___
Python tracker 

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

[issue35843] importlib.util docs for namespace packages innaccurate

[Anthony Sottile]

Change by Anthony Sottile :


--
keywords: +patch, patch, patch
pull_requests: +11529, 11530, 11531
stage:  -> patch review

___
Python tracker 

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

[issue35843] importlib.util docs for namespace packages innaccurate

[Anthony Sottile]

Change by Anthony Sottile :


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

___
Python tracker 

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

[issue35843] importlib.util docs for namespace packages innaccurate

[Anthony Sottile]

Change by Anthony Sottile :


--
keywords: +patch, patch
pull_requests: +11529, 11530
stage:  -> patch review

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

Change by jcrmatos :


--
keywords: +patch, patch
pull_requests: +11532, 11533
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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

Change by jcrmatos :


--
keywords: +patch
pull_requests: +11532
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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

Change by jcrmatos :


--
keywords: +patch, patch, patch
pull_requests: +11532, 11533, 11534
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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

Change by jcrmatos :


--
keywords: +patch, patch, patch, patch
pull_requests: +11532, 11533, 11534, 11535
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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

I deleted the fork and started again.
This time I didn't PR to my own fork but to cpython master.
It is now waiting for review, "skip news" labeling and CLA (I'm still waiting 
on my request).

--

___
Python tracker 

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

[issue35843] importlib.util docs for namespace packages innaccurate

[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

[issue35808] Let's retire pgen

[Guido van Rossum]

Guido van Rossum  added the comment:

@eamanu, feel free to submit a PR. I won't be available to guide you through 
the steps; there are other forums e.g. Zulip.

--

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Guido van Rossum]

Guido van Rossum  added the comment:

Thanks!

--

___
Python tracker 

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

[issue35844] Calling `Multiprocessing.Queue.close()` too quickly causes intermittent failure (BrokenPipeError)

[Samuel Grayson]

New submission from Samuel Grayson :

If all processes try to close the Queue immediately after someone has written 
to it, this causes [an error][1] (see the link for more details). Uncommenting 
any of the `time.sleep`s makes it work consistently again.

import multiprocessing
import time
import logging
import multiprocessing.util
multiprocessing.util.log_to_stderr(level=logging.DEBUG)

queue = multiprocessing.Queue(maxsize=10)

def worker(queue):
queue.put('abcdefghijklmnop')

# "Indicate that no more data will be put on this queue by the
# current process." --Documentation
# time.sleep(0.01)
queue.close()

proc = multiprocessing.Process(target=worker, args=(queue,))
proc.start()

# "Indicate that no more data will be put on this queue by the current
# process." --Documentation
# time.sleep(0.01)
queue.close()

proc.join()

Perhaps this is because I am not understanding the documentation correctly, but 
in that case I would contend this is a documentation bug.

Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/queues.py", line 242, in _feed
send_bytes(obj)
  File "/usr/lib/python3.7/multiprocessing/connection.py", line 200, in 
send_bytes
self._send_bytes(m[offset:offset + size])
  File "/usr/lib/python3.7/multiprocessing/connection.py", line 404, in 
_send_bytes
self._send(header + buf)
  File "/usr/lib/python3.7/multiprocessing/connection.py", line 368, in 
_send
n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe

[1]: https://stackoverflow.com/q/51680479/1078199

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 334490
nosy: charmonium, docs@python
priority: normal
severity: normal
status: open
title: Calling `Multiprocessing.Queue.close()` too quickly causes intermittent 
failure (BrokenPipeError)
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

[issue35845] Can't read a F-contiguous memoryview in physical order

[Antoine Pitrou]

New submission from Antoine Pitrou :

This request is motivated in detail here:
https://github.com/python/peps/pull/883#issuecomment-458290745

In short: in C, when you have a Py_buffer, you can directly read the memory in 
whatever order you want (including physical order).  It is not possible in pure 
Python, though.  Somewhat unintuitively, memoryview.tobytes() as well as 
bytes(memoryview) read bytes in *logical* order, even though it flattens the 
dimensions and doesn't keep the original type.  Logical order is different from 
physical order for Fortran-contiguous arrays.

One possible way of alleviating this would be to offer a memoryview.transpose() 
method, similar to the Numpy transpose() method (see 
https://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.transpose.html).

One could also imagine a memoryview.to_c_contiguous() method.

Or even: a memoryview.raw_memory() method, that would 1) flatten dimensions 2) 
cast to 'B' format 3) keep physical order.

--
components: Interpreter Core
messages: 334491
nosy: pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Can't read a F-contiguous memoryview in physical order
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

[issue25592] distutils docs: data_files always uses sys.prefix

[Antoine Pitrou]

Change by Antoine Pitrou :


--
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

___
Python tracker 

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

[issue25592] distutils docs: data_files always uses sys.prefix

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Though it's difficult to say for certain (distutils' option selection logic is 
obscure and difficult to follow), it seems that Jeroen's analysis is right.

--
nosy: +pitrou

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Sorry for the late reply, I missed Tim's comment when it first came 
through.

> Please resist pointless feature creep. The original report was about 
> comb(n, k) for integer n and k with 0 <= k <= n and that's all.  
> Everyone who commented appeared to agree they'd find that useful.
> 
> But nobody has said [...] that they'd find perm(n, k) USEFUL.

I'm not going to argue for binomial coefficients with negative n, but I 
find it hard to imagine anyone needing combinations without also needing 
permutations, and I didn't think it was necessary to explicitly say so.

But since you insist, I'll say so: I would find it useful to have a 
function to compute the number of permutations of n taking k at a time.

My perspective may be biased from my experience with secondary school 
maths, where they are taught together, but providing one without the 
other strikes me as weird as providing tan without sin and cos.

There are other functions from combinatorics which I personally use, 
like derangements, but I know when I'm pushing my luck :-)

--

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> This involved a few changes, which seem to reflect the consensus here:
> - raise ValueError if k>n ;
> - rename the function to math.combinations.

I see at least four people (myself, Raymond, Mark and Tim) giving comb 
as first choice, and I didn't see anyone give combinations as their 
first choice.

I don't object to you taking it upon yourself to go with the longer name 
(which is my second choice), but I do object to you claiming concensus 
for the change without evidence of such.

> There was also no reply to my comment about `comb` being confusing 
> (due to the collision with an English word).

To be honest, I didn't think that comment needed a reply.

Collisions between words in different knowledge domains are not unusual. 
I don't think people think that math.tan has anything to do with 
changing the colour of their skin, or math.sin is about being wicked. 
Due to their length, permutation, combination and factorial are 
frequently abbreviated to perm, comb, fact and anyone looking for those 
functions should recognise the abbreviations.

But given the precedent set by itertools and math.factorial, perhaps you 
are right and we ought to stick to the longer name.

--

___
Python tracker 

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

[issue35845] Can't read a F-contiguous memoryview in physical order

[Stefan Krah]

Stefan Krah  added the comment:

Yes, it's modeled after NumPy's tobytes():

>>> x = np.array(list(range(6)), dtype="int8").reshape(2,3)
>>> x.tobytes()
b'\x00\x01\x02\x03\x04\x05'
>>> x.T.tobytes()
b'\x00\x03\x01\x04\x02\x05'
>>> 
>>> 
>>> memoryview(x).tobytes()
b'\x00\x01\x02\x03\x04\x05'
>>> memoryview(x.T).tobytes()
b'\x00\x03\x01\x04\x02\x05'


I guess the reason is that without a type it's easier to serialize the logical 
array by default, so you can always assume C when you read back.



NumPy also has an 'F' parameter though that flips the order:

>>> x.tobytes('F')
b'\x00\x03\x01\x04\x02\x05'

It would be possible to add this to memoryview as well.

--

___
Python tracker 

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

[issue35845] Can't read a F-contiguous memoryview in physical order

[Stefan Krah]

Stefan Krah  added the comment:

raw_bytes() is also possible of course. I assume it would do nothing and just 
dump the memory.

Or tobytes('F') AND tobytes('raw').

--

___
Python tracker 

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

[issue35845] Can't read a F-contiguous memoryview in physical order

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, raw_memory() would avoid a copy, which is useful.

As for tobytes(), if we want to follow NumPy, we can have 'F' mean if 
F-contiguous, 'C' otherwise:

>>> a = np.arange(12, dtype='int8').reshape((3,4))  
>>>
>>> a.tobytes('A')  
>>>
b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b'
>>> a.tobytes('A') == a.T.tobytes('A')  
>>>
True

--

___
Python tracker 

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

[issue35845] Can't read a F-contiguous memoryview in physical order

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Sorry, my fingers slipped.  Let me try again:

As for tobytes(), if we want to follow NumPy, we can have 'A' mean 'F' if 
F-contiguous, 'C' otherwise: [...]

--

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> But given the precedent set by itertools and math.factorial,
> perhaps you are right and we ought to stick to the longer name

I disagree.  Let's stick with comb() which is what SciPy uses.  It is tedious 
to write out combinations in a formula what includes other steps. Also, I 
really want to differentiate it from the existing combinations() in the 
itertools module (it is reasonably forseeable that the two will used together.

--

___
Python tracker 

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

[issue35766] Merge typed_ast back into CPython

[Guido van Rossum]

Guido van Rossum  added the comment:

Also the tests now all pass; for now I am happy with the solution I found for 
the indentation error (see 
https://github.com/python/cpython/pull/11645#issuecomment-456627216).

--

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[Yash Aggarwal]

Yash Aggarwal  added the comment:

Agreed, comb sounds much better than combination. And using the name binomial 
would make it sound like something that would puke out whole binomial series 
rather than a single coefficient(maybe leave it for that in case is it decided 
to be useful in the future).

PR 11414 implements simple algorithm that performs slower than using a 
factorial definition for k>n/3. 
@kellerfuchs I'd prefer if we could work on this since it's conflict free and 
already reflects the behavior everyone agreed upon. 

Would it be better to create a separate issue for math.perm to discuss its 
behavior?


If the behavior of comb is satisfactory, can we start with optimizations?

--

___
Python tracker 

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

[issue35431] Add a function for computing binomial coefficients to the math module

[Tim Peters]

Tim Peters  added the comment:

> As far as I can tell from the discussions here, Steven
> and you stated a preference for the shortened names, and
> that's it.

Plus Mark, plus me - all backed "comb()" specifically.

> I find it hard to imagine anyone needing combinations without
> also needing permutations, and I didn't think it was necessary
< to explicitly say so.

Of course it is.  Merely saying something is possible is no reason at all to do 
it.  The original report didn't say anything about counting partial 
permutations, and so it's "feature creep" on the face of it to tack that on.

I personally have scant use for `perm()`, but have written my own `comb()` many 
times.  Far more often than I've written a `factorial()` and a `product()` 
combined, but I've written each of the latter more than twice, and a `perm()` 
not even once.  Especially if `prod()` (the topic of a different report) is 
added, the case for adding a `perm()` gets weaker (rising and falling 
factorials are special cases of what `prod()` does, and `perm()` is just an 
instance of falling factorial).

Which doesn't mean `perm()` must not be added ;-)  You're now the first to say 
it _would_ be useful, which is a start.  Can we get a second?

In any case, I don't want to _see_ this report get bogged down by feature 
creep:  `comb()` is what it was about from the start, and everyone so far has 
agreed `comb()` would be useful.

--

___
Python tracker 

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

[issue35821] Clarify when logging events are propagated when propagate is true

[Vinay Sajip]

Vinay Sajip  added the comment:

> I'm not sure which part of what I wrote you think is inaccurate.

It's just that language can be tricky. When you said "pass to the parent 
logger" this might be misconstrued as some kind of call to a method of the 
parent logger.

Your OP says that you think "logged to this logger" means (2), but actually it 
means (1). Expanding with examples:

If the propagate attribute of the logger named A.B.C evaluates to true, any 
event logged to A.B.C via a method call such as 
logging.getLogger('A.B.C').error(...) will [subject to passing that logger's 
level and filter settings] be passed in turn to any handlers attached to 
loggers named A.B, A and the root logger, after first being passed to any 
handlers attached to A.B.C. If any logger in the chain A.B.C, A.B, A has its 
propagate attribute set to false, then that is the last logger whose handlers 
are offered the event to handle, and propagation stops at that point.

--

___
Python tracker 

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