[issue30297] Recursive starmap causes Segmentation fault

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Options like -fno-stack-limit and -fsplit-stack can help to avoid a crash, but 
they are compiler-specific and we should test how they affect the performance 
and memory consumption.

How can we test that the available stack is too small? This is not a part of 
the language, we need to use some compiler-specific tricks.

If add such check, it should be added not in the c-eval loop (or not only in 
the c-eval loop), but for every call of tp_iternext. Recursive call can avoid 
the c-eval loop. Maybe add the check in PyIter_Next() and always use 
PyIter_Next() instead of direct calls of tp_iternext. If the check for the 
stack size is not cheap we can just count the deep of the recursion and check 
the exact stack size every say 50 levels. And this is a good opportunity to 
check for KeyboardInterrupt .

In any case it would be useful to add a user specified limit on the deep of the 
recursion similar to sys.getrecursionlimit(). Even if the stack grows 
unlimitedly we don't want to fall in the swapping on unexpected deep recursion.

--

___
Python tracker 

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

[issue29447] Add/check os.PathLike support for the tempfile module's 'dir' arguments

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I don't see any changes in tempfile.py. If the path-like protocol already is 
supported for the dir argument, no change in the documentation is needed.

tempfile.mkdtemp(dir=pathlike.Path(''), pre=b'', suf=b'') should raise a 
TypeError, but add also tests for path-like objects returning bytes path.

--

___
Python tracker 

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

[issue29947] In SocketServer, why not passing a factory instance for the RequestHandlerClass instead of the class itself?

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +1598

___
Python tracker 

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

[issue29447] Add/check os.PathLike support for the tempfile module's 'dir' arguments

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +1599

___
Python tracker 

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

[issue30299] Display the bytecode when compiled a regular expression in debug mode

[Terry J. Reedy]

Terry J. Reedy added the comment:

Whoops, the one I thought I added previously.  I must not have clicked the 
[comment] button after writing it and before closing the tab.

--

___
Python tracker 

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

[issue29447] Add/check os.PathLike support for the tempfile module's 'dir' arguments

[Louie Lu]

Louie Lu added the comment:

@Brett, do you think if given a path-like dir, it should only be treated as 
`str`, or it could be `str` and `bytes`?

My PR is now treated path-like dir as `str`, not `bytes`.

This will affect at this places:

tempfile.mkdtemp(dir=pathlike.Path(''), pre=b'', suf=b'')

Should it raise a TypeError (since we can't mix str and bytes), or it will 
convert path-like to bytes.

--

___
Python tracker 

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

[issue29990] Range checking in GB18030 decoder

[Xiang Zhang]

Changes by Xiang Zhang :


--
pull_requests: +1597

___
Python tracker 

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

[issue11245] Implementation of IMAP IDLE in imaplib?

[Kostis Anagnostopoulos]

Kostis Anagnostopoulos added the comment:

Before merging `imaplib2` please consider making proper use of the Python's 
standard `logging` module.

--
nosy: +ankostis

___
Python tracker 

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

[issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods"

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'll fix that up.  I've already been working on revising the document.  There 
are a number of updates needed (user-friendly intro, properties revised to show 
the setting methods, __set_name__, etc).

--
assignee: docs@python -> rhettinger
nosy: +rhettinger
priority: high -> normal

___
Python tracker 

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

[issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods"

[Steven D'Aprano]

Steven D'Aprano added the comment:

Be careful with the documentation patch. Although unbound method as an object 
type is gone, unbound method as a concept is not.

Conceptually, something like ``MyClass.spam`` is an unbound method: it is a 
method of the MyClass type, but bound to no instance. In Python 2 that concept 
was implemented by MethodType. In Python 3, the concept is implemented by 
FunctionType.

While it is certainly true from one perspective that unbound methods are 
nothing but functions, it is nevertheless also sometimes useful to distinguish 
from "functions defined in a class" (methods) and "other functions". I think 
that nearly all Python programmers would be happy to call ``spam`` below:

class MyClass:
def spam(self, arg): ...

a method, even though it is also/really a function.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue30302] Improve .__repr__ implementation for datetime.timedelta

[Utkarsh Upadhyay]

Utkarsh Upadhyay added the comment:

> This was discussed fairly recently: 
> 

That thread went deep and culminated here, as far as I can tell: 
https://marc.info/?l=python-dev=145077422417470=2 (I may not have explored 
all the branches, though.)

So there indeed seems to be general agreement about changing this. It was 
heartening to know that I wasn't the only one to stumble. \o/

> The built-in help was also discussed in that thread. I don’t think it got 
> fixed yet, did it?

No, the doc-string is as uninformative as then, as far as I can tell:

  In [178]: datetime.timedelta?
  Init signature: datetime.timedelta(self, /, *args, **kwargs)
  Docstring:  Difference between two datetime values.
  File:   ~/miniconda3/lib/python3.5/datetime.py
  Type:   type 

I'll investigate what documentation for other functions looks like and see if I 
can come up with something better. The exact documentation would be best 
discussed over diffs on Github.

Then there is the issue of repr being explicitly documented, as you had pointed 
out on the Github issue. Guido thinks that any breakage is _unlikely_ but 
"asked around" here: https://marc.info/?l=python-dev=145065347022557=2

As far as I can tell, he didn't see an explicit response.

> The size of the repr could be reduced a bit by dropping the module name: 
> datetime.timedelta vs just timedelta. Although that would be inconsistent 
> with the other classes; I’m not sure about this.

Personally, I don't see a big problem either way but having datetime.timedelta 
in the repr feels reassuring to me that I have the 'right' type instead of some 
other 'timedelta' from a non-stdlib module (e.g. moments or pandas).


> 1. Drop leading zeros: timedelta(seconds=60) rather than timedelta(days=0, 
> seconds=60). This would also help reduce the size.

This sounds reasonable. I'll make this change and add corresponding tests.

> 2. Factor out the negative sign: -timedelta(seconds=60) rather than 
> timedelta(days=-1, seconds=86340).

I'm not sure there was consensus about this; if I understand correctly, Guido 
thinks that it is important that the repr return what the attributes hold: 
https://marc.info/?l=python-dev=145066934224955=2

--

___
Python tracker 

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

[issue30297] Recursive starmap causes Segmentation fault

[Raymond Hettinger]

Raymond Hettinger added the comment:

Serhiy, do you have any ideas for a non-invasive global solution to running out 
of C-stack?

The GCC options for -fno-stack-limit and -fsplit-stack are one avenue.  Another 
is to put in a periodic check in the c-eval loop to test whether available 
stack is getting too small and to find a way to exit gracefully.

--

___
Python tracker 

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

[issue30297] Recursive starmap causes Segmentation fault

[Raymond Hettinger]

Raymond Hettinger added the comment:

What makes this report unique is that it is the first one occurring in the wild 
(i.e. wasn't an example contrived solely for the purpose of producing a crash). 
 Otherwise, we're not ever seeing this happen in real code.

--

___
Python tracker 

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

[issue30302] Improve .__repr__ implementation for datetime.timedelta

[Martin Panter]

Martin Panter added the comment:

This was discussed fairly recently: 
.
 There seems to be a bit of support for changing this. It is not a bug fix, so 
has to go into the next release, now 3.7.

I disagree that the positional timedelta parameters are well-known.

The built-in help was also discussed in that thread. I don’t think it got fixed 
yet, did it?

The datetime class represents absolute dates. It is nonsense to specify a date 
without a year. Timedelta is different, because time is measured with different 
units. The first parameter (days) is surprising considering most other Python 
APIs (sleep etc) deal with seconds.

The size of the repr could be reduced a bit by dropping the module name: 
datetime.timedelta vs just timedelta. Although that would be inconsistent with 
the other classes; I’m not sure about this.

Other improvements that I would like to see:

1. Drop leading zeros: timedelta(seconds=60) rather than timedelta(days=0, 
seconds=60). This would also help reduce the size.

2. Factor out the negative sign: -timedelta(seconds=60) rather than 
timedelta(days=-1, seconds=86340).

--
nosy: +martin.panter
title: Improve .__repr__ implementation for datetime.datetime.timedelta -> 
Improve .__repr__ implementation for datetime.timedelta
versions:  -Python 2.7, Python 3.3, Python 3.4, 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

[issue30302] Improve .__repr__ implementation for datetime.datetime.timedelta

[Utkarsh Upadhyay]

Utkarsh Upadhyay added the comment:

> The drawback is that this change increases the length of the repr.

I would argue that it is a reasonable trade-off given the increase in ease of 
understanding. 

I know that this is a weak argument, but, keywords are not without precedent. 
Consider the comically more verbose example:

import time
time.gmtime(1121871596)
# time.struct_time(tm_year=2005, tm_mon=7, tm_mday=20, tm_hour=14, tm_min=59, 
tm_sec=56, tm_wday=2, tm_yday=201, tm_isdst=0)


> datetime.datetime has more arguments, and its repr doesn't use keywords.

I think that guessing the meaning of values is much harder when it comes to 
timedelta.


> Users of datetime.timedelta know what arguments mean. If they don't know they 
> always can look in the documentation or builtin help.

I created the issue after ... a friend ... spent an embarrassing amount of time 
debugging because he thought that the third argument represented milliseconds 
and not microseconds. <_<

I could, of course, tell him:

> In the face of ambiguity, resist the temptation to guess.

But he could retort:

> Explicit is better than implicit.

and 

> Readability counts.

I think he has a point.

--

___
Python tracker 

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

[issue30299] Display the bytecode when compiled a regular expression in debug mode

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What the review note you mean Terry?

--

___
Python tracker 

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

[issue30302] Improve .__repr__ implementation for datetime.datetime.timedelta

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The drawback is that this change increases the length of the repr. If you 
output few values in a row (for example output the repr of a list of 
timedeltas), this makes the output less readable.

Users of datetime.timedelta know what arguments mean. If they don't know they 
always can look in the documentation or builtin help.

datetime.datetime has more arguments, and its repr doesn't use keywords.

--
nosy: +belopolsky, serhiy.storchaka

___
Python tracker 

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

[issue30302] Improve .__repr__ implementation for datetime.datetime.timedelta

[Utkarsh Upadhyay]

Changes by Utkarsh Upadhyay :


--
pull_requests: +1595

___
Python tracker 

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

[issue30302] Improve .__repr__ implementation for datetime.datetime.timedelta

[Utkarsh Upadhyay]

New submission from Utkarsh Upadhyay:

Currently, the default implementation of datetime.datetime.__repr__ (the 
default output string produced at the console/IPython) gives a rather cryptic 
output:

from datetime import datetime as D
D.fromtimestamp(1390953543.1) - D.fromtimestamp(1121871596)
# datetime.timedelta(3114, 28747, 10)

For the uninitiated, it is not obvious that the numeric values here are `days`, 
`seconds` and `microsecond` respectively.

Would there be any pushback against changing this to:

# datetime.timedelta(days=3114, seconds=28747, microseconds=10)

?

--
components: Library (Lib)
messages: 293212
nosy: musically_ut
priority: normal
severity: normal
status: open
title: Improve .__repr__ implementation for datetime.datetime.timedelta
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue30299] Display the bytecode when compiled a regular expression in debug mode

[Terry J. Reedy]

Terry J. Reedy added the comment:

The new output is the blank line and numbered lines, produced by the new dis 
function.

The addition is specific to CPython's re module.  Thus the doc for re.DEBUG 
remains "Display debug information about compiled expression."  I think that 
the NEWS entry should also mention that this is a cpython-specific enhancement 
and not a language change.  See review note.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue26336] Expose regex bytecode of compiled pattern object

[Terry J. Reedy]

Terry J. Reedy added the comment:

I changed the title because I believe a) the Python-level tuple of ints should 
be created on demand (I am not sure what the patch does); and b) the exposure 
should be done by an overt function rather than be an  'attribute', even if 
that is a front for a property getter.  The former would have to come with re.  
A function does not need to be a method, and can therefore be provided in a 3rd 
party module that accesses the C attribute via ctypes.  Such a function could 
be used with past versions of CPython.

Jelle, I suggest that you augment regdis with such function, so it does not 
depend on this issue.


I am closing this for reasons stated and the following.

I reread the thread.  Only one person with commit privileges participated.  The 
proposal got only tepid support for stdlib inclusion and at least as much or 
more support for 3rd party activity.  The thread ended with Jonathan saying 
"I've decided to shelve this idea for the time being".  Given the opposition of 
the current re maintainer, this proposal lacks sufficient support.

Modules as a whole can be OS specific (several examples) or CPython-specific 
(dis).  We generally avoid adding features within modules whose existence is 
implementation-specific.  "This attribute [a tuple of ints] is not guaranteed 
to exist in all implementations of Python." is almost enough to kill the 
proposal.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
title: Expose regex bytecode as attribute of compiled pattern object -> Expose 
regex bytecode of compiled pattern object
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue30301] “AttributeError: 'SimpleQueue' object has no attribute '_poll'”

[Daniel Moore]

New submission from Daniel Moore:

I originally posted this as a question on StackOverflow thinking I was doing 
something wrong:

http://stackoverflow.com/questions/43834494/python-3-6-attributeerror-simplequeue-object-has-no-attribute-poll/43835368#43835368

But I think I found the solution and answered my own question. I'm pretty sure 
you need to set:

self._poll = self._reader.poll

in the __setstate__ method in the SimpleQueue class of queues.py from the 
multiprocessing library. Otherwise, I'd love to know an alternative solution.

Thanks!

--
components: Library (Lib), Windows
messages: 293209
nosy: Daniel Moore, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: “AttributeError: 'SimpleQueue' object has no attribute '_poll'”
type: crash
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

[issue14010] deeply nested filter segfaults

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See issue30297 for yet one instance of this in starmap().

--

___
Python tracker 

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

[issue30297] Recursive starmap causes Segmentation fault

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This looks as a duplicate of issue14010 (and many other issues).

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
superseder:  -> deeply nested filter segfaults

___
Python tracker 

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

[issue30168] Class Logger is unindented in the documentation.

[Vinay Sajip]

Vinay Sajip added the comment:


New changeset 55ace65eba587fe3cf3759a43cccf85214651971 by Vinay Sajip (Jim 
Fasarakis-Hilliard) in branch 'master':
Closes bpo-30168: indent methods in Logger Class (#1295)
https://github.com/python/cpython/commit/55ace65eba587fe3cf3759a43cccf85214651971


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

[issue30300] asyncio.Controller

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
pull_requests: +1594

___
Python tracker 

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

[issue30300] asyncio.Controller

[Barry A. Warsaw]

New submission from Barry A. Warsaw:

Over in https://github.com/aio-libs/aiosmtpd we have a Controller class which 
is very handy for testing and other cases.  I realized that this isn't really 
aiosmtpd specific, and with just a few tweaks it could be appropriate for the 
stdlib.

I have a branch ready for a pull request.  This is the tracking/discussion 
issue.

--
components: Library (Lib)
messages: 293205
nosy: barry
priority: normal
severity: normal
status: open
title: asyncio.Controller
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

[issue30145] Create a How to or Tutorial documentation for asyncio

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue30297] Recursive starmap causes Segmentation fault

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'm not sure this can be fixed reasonably.  It would entail taking every 
possible iterator in all of Python and adding some sort of recursion depth 
check.  That approach risks introducing bugs, risks breaking existing code that 
relies on heavy iteration depth (we know YouTube uses such code), and it would 
slow-down iteration everywhere (possibly by quite a bit since iteration is a 
thin and fast protocol).

Also, this is a general case of recursive crashers (there are a number of open 
bugs on this) that are hard to detect and prevent.

IMO, what is really needed is something that monitors the C stack and 
gracefully detects the situation just before a crash and gracefully unwinds the 
calls.  This isn't easy to do but it would be a broad, complete, performant, 
and minimally invasive solution to a problem that is irritating but only arises 
very rarely (and typically only in code that isn't really sane to begin with). 

The usual recursion depth checks on function calls are reasonable because 1) 
their overhead is minimal compared to overall function call overhead and 2) 
they detect common programming errors.   

To me, the starmap() case is different because the problem is rare and because 
iteration is a tight fast protocol.  

One other thought:  While a RuntimeError would be much preferred to a crash, 
the programmer has to respond in the same way, by changing their code.  In the 
pbkdf2_bin() example, the code can't be made to run as-is.  The approach has to 
be changed to a list based approach (even using hand-rolled iterators instead 
of starmap() won't help).

A last thought:  I presume that the whole reason for using starmap() instead of 
"yield from" or somesuch is the person writing code needed good performance, so 
taking away performance defeats the original intent.

--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue30298] Weak deprecations for inline regular expression modifiers

[Raymond Hettinger]

Raymond Hettinger added the comment:

LGTM

--
nosy: +rhettinger

___
Python tracker 

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

[issue30248] Using boolean arguments in the _json module

[Raymond Hettinger]

Raymond Hettinger added the comment:

This looks like a nice improvement.

--

___
Python tracker 

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

[issue30296] Remove unnecessary tuples, lists, sets, and dicts from Lib

[Raymond Hettinger]

Raymond Hettinger added the comment:

Jon, we usually try to avoid sweeping changes across the library and instead 
preference to focus on one module at a time (Guido calls this "holistic 
refactoring").  There is a risk of introducing bugs and of destabiliizing code 
that has sat untouched but working for a long time.

Also, as Serhiy and Steven have pointed out, there are sometimes subtle reasons 
to prevent the existing code.  For example, I find the original to be clearer 
in this example:

 - return list(set(item.name for item in self.list)) +
 + return list({item.name for item in self.list})

and the original to be both clearer and faster in this example:

 - return list(map(_convert, node.elts))
 + return [_convert(v) for v in node.elts]

In some cases, using "dict(...)" or "set(...)" is clearer about the intension 
or more readable because it is parallel to the surrounding code (such as the 
parallelism of successive line in ast.py).

In some cases such as _pydecimal we have a aversion to changing code that 
aspires to be backwards compatible across many versions.

That said, there are a few places where it might be worthwhile for making a 
change.  Converting to set literals is almost always a win:

 -interesting = set(("include", "lib", "libpath", "path"))   
 +interesting = {"include", "lib", "libpath", "path"}

As Serhiy noted, in some places using map() would be an improvement, so we 
should look at doing a few of those (where there is a win in term of speed, 
space, and readability):

 - version_info = tuple([int(x) for x in version.split(".")])
 + version_info = tuple(map(int, version.split(".")))

Overall, I think most of these shouldn't be done, but I will mark a few where 
some change might be considered an improvement.  Steven or Serhiy are both 
welcome to veto any one of those.  Likewise, if the original author of the code 
is still active, they have a veto as well.  The status quo usually wins until 
we're refactoring a single module and make improvements while thinking about 
that module.

You picked a difficult first patch because you picked a topic that we usually 
avoid (wholesale sweeps through the standard library) and an area where 
deciding "what is best" involves subtleties with respect to clarity, 
parallelism with surrounding code, speed, clear intention, back compatibility, 
and how the original author thinks about the code.

--

___
Python tracker 

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

[issue30295] msvcrt SetErrorMode not documented

[Eryk Sun]

Changes by Eryk Sun :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue30295] msvcrt SetErrorMode not documented

[Eryk Sun]

Eryk Sun added the comment:

msvcrt set_error_mode, CrtReportMode, CrtReportFile and the associated CRT 
constants should be documented for use with debug builds. Also, msvcrt is 
missing the set_error_mode constants _OUT_TO_DEFAULT, _OUT_TO_STDERR, 
_OUT_TO_MSGBOX, and _REPORT_ERRMODE.

SetErrorMode [1] and the SEM_* constants are defined in msvcrt, for convenience 
I suppose. They're not related to the CRT. I think they should be aliased in 
the os module and documented there. GetErrorMode [2] can also be provided in 
Python 3.5+. It would be useful to also provide SetThreadErrorMode [3] and 
GetThreadErrorMode conditionally in Windows 7+, which is practically all 
Windows users nowadays.

[1]: https://msdn.microsoft.com/en-us/library/ms680621
[2]: https://msdn.microsoft.com/en-us/library/ms679355
[3]: https://msdn.microsoft.com/en-us/library/dd553630

--
nosy: +eryksun

___
Python tracker 

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

[issue26336] Expose regex bytecode as attribute of compiled pattern object

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See issue30299 which adds the output of decoded bytecode in debug mode. The 
format of the bytecode is implementation detail, it is irregular, new opcodes 
can be added, and the format of existing opcodes can be changed. Thus it is 
hard to support third-party disassembler.

--

___
Python tracker 

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

[issue30299] Display the bytecode when compiled a regular expression in debug mode

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1593

___
Python tracker 

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

[issue30299] Display the bytecode when compiled a regular expression in debug mode

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Proposed patch makes compiling a regular expression in debug mode (with the 
re.DEBUG flag) displaying the bytecode in human readable form (in addition to 
the syntax tree). For example:

>>> re.compile('test_[a-z_]+', re.DEBUG)
LITERAL 116
LITERAL 101
LITERAL 115
LITERAL 116
LITERAL 95
MAX_REPEAT 1 MAXREPEAT
  IN
RANGE (97, 122)
LITERAL 95

 0. INFO 16 0b1 6 MAXREPEAT (to 17)
  prefix_skip 5
  prefix [0x74, 0x65, 0x73, 0x74, 0x5f] ('test_')
  overlap [0, 0, 0, 1, 0]
17: LITERAL 0x74 ('t')
19. LITERAL 0x65 ('e')
21. LITERAL 0x73 ('s')
23. LITERAL 0x74 ('t')
25. LITERAL 0x5f ('_')
27. REPEAT_ONE 12 1 MAXREPEAT (to 40)
31.   IN 7 (to 39)
33. RANGE 0x61 0x7a ('a'-'z')
36. LITERAL 0x5f ('_')
38. FAILURE
39:   SUCCESS
40: SUCCESS
re.compile('test_[a-z_]+', re.DEBUG)

This feature is needed mainly for our own needs. It can help optimizing regular 
expression compilation.

--
components: Library (Lib), Regular Expressions
messages: 293198
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Display the bytecode when compiled a regular expression in debug mode
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue30298] Weak deprecations for inline regular expression modifiers

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1592

___
Python tracker 

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

[issue30298] Weak deprecations for inline regular expression modifiers

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

There is a difference between handling inline modifiers in regular expressions 
between Python and all other regular expression engines that support inline 
modifiers. In other engines an inline modifier affect only the part of the 
pattern after it. It Python it affects also the part before it. For avoiding 
possible confusion and for removing this difference in distant future, using 
inline modifiers not at the start of the pattern was deprecated in 3.6 (see 
issue22493).

But the condition for raising a warning is too strong. It allows using 
'(?is)...', but '(?i)(?s)...' emits a warning. This makes hard modifying 
regular expressions by prefixing them with inline modifiers. This condition is 
unjustifiably strong because '(?i)(?s)...' doesn't have any ambiguity. It also 
disallows ' (?i)...' in verbose mode despite the fact that whitespaces are not 
significant in verbose mode.

Proposed patch weaks the condition of deprecation warnings. It allows using 
several subsequent inline modifiers at the start of the pattern and ignores 
whitespaces in verbose mode.

--
components: Library (Lib), Regular Expressions
messages: 293197
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Weak deprecations for inline regular expression modifiers
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue29447] Add/check os.PathLike support for the tempfile module's 'dir' arguments

[Louie Lu]

Louie Lu added the comment:

Regards my words, some place need to changed to support PathLike, I'll test it 
tomorrow.

--

___
Python tracker 

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

[issue30296] Remove unnecessary tuples, lists, sets, and dicts from Lib

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

* Some functions that accept an arbitrary iterable first convert it to 
temporary list and iterate that list. In these cases there is no significant 
difference in memory usage between list comprehension and generator, but the 
variant with list comprehension is slightly faster.

* foo(bar(x) for x in a) can be written also as foo(map(bar, a)). Both 
expressions are idiomatic, different users have different preferences, the 
variant with map can be faster for larger loops. The variant with map can even 
be faster than comprehensions.

* Proposed patch changes some files which should be kept compatible with old 
Python versions. Old Python versions can not support set and dict 
comprehensions.

* In general we avoid making changes to many files that doesn't have obvious 
positive effect. Most changes doesn't have measurable effect, they are just 
style changes. But different users have different preferences and existing code 
is not obviously bad.

Assigned to Raymond because it usually opposed to such kind of changes but made 
very similar changes in issue22823.

--
assignee:  -> rhettinger
nosy: +rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue30296] Remove unnecessary tuples, lists, sets, and dicts from Lib

[Steven D'Aprano]

Steven D'Aprano added the comment:

Is this unnecessary code churn?

That's not a rhetorical question. Fixing code that isn't broken is not always a 
good idea.

``func()`` is not always identical to ``func()``, there are situations where there is a significant performance 
difference between the two. E.g. str.join() is significantly faster when passed 
a list than when passed a generator expression. According to my tests:

''.join(['abc' for x in range(100)])

is about 40% faster than

''.join('abc' for x in range(100))

--
nosy: +steven.daprano

___
Python tracker 

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

[issue30297] Recursive starmap causes Segmentation fault

[Sebastian Noack]

Sebastian Noack added the comment:

I just noticed that the segfault can also be reproduced with Python 2 [1]. So 
please ignore what I said before that this wouldn't be the case.

While it is debatable whether using a lazy evaluated object with so many 
recursions is a good idea in the first place, causing it the interpreter to 
crash with a segfault still seems concerning to me.

[1]: https://github.com/mitsuhiko/python-pbkdf2/issues/2

--

___
Python tracker 

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

[issue30297] Recursive starmap causes Segmentation fault

[Sebastian Noack]

New submission from Sebastian Noack:

If I run following code (on Python 3.5.3, Linux) the interpreter crashes with a 
segfault:


def pbkdf2_bin(data, salt, iterations=1000, keylen=24, hashfunc=None):
hashfunc = hashfunc or hashlib.sha1
mac = hmac.new(data, None, hashfunc)
def _pseudorandom(x, mac=mac):
h = mac.copy()
h.update(x)
return h.digest()
buf = []
for block in range(1, -(-keylen // mac.digest_size) + 1):
rv = u = _pseudorandom(salt + _pack_int(block))
for i in range(iterations - 1):
u = _pseudorandom(u)
rv = starmap(xor, zip(rv, u))
buf.extend(rv)
return bytes(buf[:keylen])

pbkdf2_bin(b'1234567890', b'1234567890', 20, 32)


I was able to track it down to the line of buf.extend(rv) which apparently is 
causing the segfault. Note that rv is a lazy-evaluated starmap. I also get a 
segfault if I evaluate it by other means (e.g. by passing it to the list 
constructor). However, if I evaluate it immediately by wrapping the starmap 
constructor with the list constructor, the code works as expected. But I wasn't 
able yet, to further isolate the issue. FWIW, the Python 2 version [1] of this 
code works just fine without forcing immediate evaluation of the starmap.

Note that the code posted, except for the bits I changed in order to make it 
compatible with Python 3, is under the copyright of Armin Ronacher, who 
published it under the BSD license.

[1]: https://github.com/mitsuhiko/python-pbkdf2

--
messages: 293192
nosy: Sebastian.Noack
priority: normal
severity: normal
status: open
title: Recursive starmap causes Segmentation fault
type: crash
versions: Python 3.5

___
Python tracker 

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

[issue29447] Add/check os.PathLike support for the tempfile module's 'dir' arguments

[Louie Lu]

Louie Lu added the comment:

Since tempfile is relay on `os`,

e.g. `file = _os.join.path(dir, pre+name+suf)`, 


it can directly accept dir as PathLike type, this should need to add test case 
for it.

--
nosy: +louielu

___
Python tracker 

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

[issue30296] Remove unnecessary tuples, lists, sets, and dicts from Lib

[Jon Dufresne]

New submission from Jon Dufresne:

Lib has some patterns that could be easily discovered and cleaned up. Doing so 
will reduce the number of unnecessary temporary lists in memory and unnecessary 
function calls. It will also take advantage of Python's own rich features in a 
way that better dog foods the language. For example:

* Replace list() with list comprehension
* Replace dict() with dict comprehension
* Replace set() with set comprehension
* Replace builtin func() with func() 
when supported (e.g. any(), all(), tuple(), min(), & max())

--
components: Library (Lib)
messages: 293190
nosy: jdufresne
priority: normal
pull_requests: 1591
severity: normal
status: open
title: Remove unnecessary tuples, lists, sets, and dicts from Lib
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

[issue30295] msvcrt SetErrorMode not documented

[Giampaolo Rodola']

New submission from Giampaolo Rodola':

Also SEM_FAILCRITICALERRORS and other SEM_constants. They should as setting 
error mode on Windows for console applications is a pretty common use case (in 
fact ./Lib/test/libregrtest/setup.py uses it).

--
assignee: docs@python
components: Documentation
messages: 293189
nosy: docs@python, giampaolo.rodola
priority: normal
severity: normal
status: open
title: msvcrt SetErrorMode not documented
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue30286] ctypes FreeLibrary fails on Windows 64-bit

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

> It's documented that the default conversion for integer arguments is a 32-bit 
> C int. [...] Whenever a pointer is returned, you must set the function's 
> restype.

OK, clear. Closing this out.

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

[issue30291] Allow windows launcher to specify bit lengths with & without minor version

[Steve Barnes]

Steve Barnes added the comment:

I believe that I have a fix in pull request #1488 for the following points, and 
have manually tested for them:

 - py Still defaults to highest py3 with 64 bits as the default
 - py -2/3.n-32 Still works or reports not present as appropriate
 - py -2/3.n-64 Works or reports not present as appropriate
 - py -2/3 Still defaults to highest then 64 bit if present
 - py -2/3-32/64 Gives highest python 2/3 or reports not present
 - py -2/3.nn Should now work if/when there is such a version present, (any 
number of digits as far as the validation goes), or reports no such python.
 - py -4, etc., Ditto
 - py n.m-anything other than 32 or 64 - no change of behaviour.

CLA - Signed and submitted but not a working day yet. All automatic checks 
passed. Will add another push to update to the help message.

--

___
Python tracker 

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

[issue28087] macOS 12 poll syscall returns prematurely

[STINNER Victor]

STINNER Victor added the comment:

You want to get poll() on macOS. I'm ok with that but I would like to see
tests for it. We should remove the skip in the test.

Ok, I will update my PR to just blacklist macOS 10.12.0 and 10.2.1, and
reenable the test. I just have to find the Darwin versions.

I don't think that we have to suggests Python users to upgrade, I expect
macOS popups requesting to apply upgrades are enough ;-)

--

___
Python tracker 

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

[issue30291] Allow windows launcher to specify bit lengths with & without minor version

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +1590

___
Python tracker 

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

[issue30097] Command-line option to suppress "from None" for debugging

[Martin Panter]

Martin Panter added the comment:

This proposal would be useful. My use case is for when an API suppresses an 
external exception context:

>>> import os
>>> try:
... os.environ["NEW_VARIABLE"] = bug  # Hidden exception
... finally:
... del os.environ["NEW_VARIABLE"]  # KeyError
... 
Traceback (most recent call last):
  File "", line 4, in 
  File "/usr/lib/python3.5/os.py", line 699, in __delitem__
raise KeyError(key) from None
KeyError: 'NEW_VARIABLE'

This feels like a step backwards to Python 2, and enabling the full backtrace 
would make this easier to analyze:

>>> try:
... os.environ["NEW_VARIABLE"] = bug  # TypeError
... finally:
... del dict()["NEW_VARIABLE"]  # KeyError
... 
Traceback (most recent call last):
  File "", line 2, in 
  File "/usr/lib/python3.5/os.py", line 688, in __setitem__
value = self.encodevalue(value)
  File "/usr/lib/python3.5/os.py", line 756, in encode
raise TypeError("str expected, not %s" % type(value).__name__)
TypeError: str expected, not object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 4, in 
KeyError: 'NEW_VARIABLE'

--
nosy: +martin.panter

___
Python tracker 

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

[issue30287] cpython and Clang Static Analyzer

[Дилян Палаузов]

Дилян Палаузов added the comment:

I forgot to pass --with-pydebug to ./configure in order to consider also the 
asserts.  Here we go:

scan-build ./configure --enable-loadable-sqlite-extensions --enable-ipv6 
--with-system-expat --with-system-libmpdec --with-pydebug
scan-build -o /home/didopalauzov/public_html/scan-build-python-3763ea865c make

The output, which has now 9 hints less, is at
  https://mail.aegee.org/dpa/scan-build-python-3763ea865c/

The assignments in Modules/socketmodule.c:1456 and 
Modules/_datetimemodule.c:2232 are correctly detected as superfluous.

In Objects/longobject.c/long_format_binary:

default:
assert(0); /* shouldn't ever get here*/
bits = 0; /* to silence gcc warning */

I guess return -1 instead of bits=0 will silent both gcc and the static 
analyzer warning.

--

___
Python tracker 

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

[issue30294] ./configure, pydebug and pymalloc

[Дилян Палаузов]

Дилян Палаузов added the comment:

./configure --help also does not indicate, whether just "./configure" enables 
or disables IPv6, thread support, dtrace*, computed-gotos*, doc-strings*.

The asterisk features, suggest replacing AC_ARG_WITH with AC_ARG_ENABLE, as 
there are only two states.

For ensurepip, AS_HELP_STRING shall be "[--with-ensurepip=@<:@=upgrade@:>@]".

AC_ARG_WITH(lto, AS_HELP_STRING([--with-lto], [Enable Link Time Optimization in 
PGO builds. Disabled by default.]),

Here you see the whole point of the logic, that by inspecting the 
"--with-"/"--without-" status of ./configure --help, one can conclude what the 
defaults are.  "Disabled by default" is redundant.

--

___
Python tracker 

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

[issue30294] ./configure, pydebug and pymalloc

[Дилян Палаузов]

New submission from Дилян Палаузов:

Providing that during ./configure Py_DEBUG can either be set or not, but there 
is no third state, which third state would justify calling ./configure 
--with-pydebug=lambda, --with-pydebug shall be renamed to --enable-pydebug .

Likewise for --with-pymalloc , but it is more tricky.  Currently ./configure 
--help emits "--with(out)-pymallocdisable/enable specialized mallocs".  
Usually from the output of ./configure --help one shall be able to conclude, 
whether a switch is on or off by default, if it is not provided.  E.g. if it is 
by default off, then "--enable-X   enable feature X" is printed; and 
"--disable-Y disable feature-Y" is printed when by default the feature is on.

The code says, that if pymalloc is enabled implicitly, if neither 
--with-pymalloc nor --without-pymalloc is provided.  Let's update the 
AS_HELP_STRING to show the default and also shorten the code, which makes it 
also easier to understand (for me at least)
which makes it also easier to understand (for me at least):

diff --git a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
@@ -3290,12 +3290,7 @@ AC_MSG_RESULT($with_doc_strings)
 # Check for Python-specific malloc support
 AC_MSG_CHECKING(for --with-pymalloc)
 AC_ARG_WITH(pymalloc,
-AS_HELP_STRING([--with(out)-pymalloc], [disable/enable specialized 
mallocs]))
-
-if test -z "$with_pymalloc"
-then
-with_pymalloc="yes"
-fi
+AS_HELP_STRING([--without-pymalloc], [disable specialized 
mallocs]),,with_pymalloc=yes)
 if test "$with_pymalloc" != "no"
 then
 AC_DEFINE(WITH_PYMALLOC, 1,

configure.ac:4629  mentions "# * --with-wide-unicode (adds a 'u')", but since 
commit d63a3b8beb4a0841cb59fb3515347ccaab34b733 "Implement PEP 393", one cannot 
pass --with-wide-unicode to ./configure.

--
components: Build
messages: 293182
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: ./configure, pydebug and pymalloc

___
Python tracker 

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

[issue30291] Allow windows launcher to specify bit lengths with & without minor version

[Eryk Sun]

Eryk Sun added the comment:

I don't see a pressing need to support a -64 architecture suffix. If you run 
3.6 and get a 32-bit version, you can assume there's no 64-bit version 
installed and error out if you need 64-bit. That said, supporting this suffix 
would make the interface and error handling more consistent.

I also noticed the problem with double-digit minor versions, but that's years 
away. It would be an obvious problem resolved early in 3.10 development, 
assuming 3.10 even uses the py launcher as it exists today. I'd just kick the 
can on that one. Maybe add a comment noting the potential problem.

--
nosy: +eryksun

___
Python tracker 

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

[issue29956] math.exp documentation is misleading

[Mark Dickinson]

Mark Dickinson added the comment:

Can this be closed?

--

___
Python tracker 

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

[issue30287] cpython and Clang Static Analyzer

[Mark Dickinson]

Mark Dickinson added the comment:

Thanks for this. I took a look at the 5 reports for Objects/longobject.c, and I 
don't think there's any action to be taken on any of them. (Two false 
positives; two "dead assignments" that are used when asserts are enabled, and 
one division-by-zero that depends on a function being called in a way that 
never happens in practice.)

* Objects/longobject.c:2823 Assigned value is garbage or undefined

This is a false positive. Here we have:

a_bits <= a_size * PyLongShift
shift_digits = (a_bits - DBL_MANT_DIG - 2) / PyLong_SHIFT;

and then we call v_rshift(x_digits, ..., a_size - shift_digits, ...), which 
fills the first a_size - shift_digits entries of x_digits. Since DBL_MANT_DIG 
>= PyLong_SHIFT, we have shift_digits < a_size, so x_digits[0] is always 
initialised by v_rshift.

* Objects/longobject.c:2723 Dead assignment

The value of the assignment is used in a following assert statement; I don't 
think this should be changed.

* Objects/longobject.c:2463 Dead assignment

Again, the value of the assignment is used in an assert.

* Objects/longobject.c:1828 Division by zero

This function will never get called with bits=0. There are asserts to check 
this.

* Objects/longobject.c:2830 Assigned value is garbage or undefined

This is another false positive, similar to the first one. Analysing the 
arithmetic shows that x_digits[0] is always defined.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue30291] Allow windows launcher to specify bit lengths with & without minor version

[Steve Barnes]

Steve Barnes added the comment:

Also noted when looking at the code that the validate function, 
(validate_version), has a couple of issues:

 - It will allow python major versions 0-9 (at the moment only 2 or 3 are 
valid).
 - It will not allow minor versions with more than one digit so if/when python 
3.10 comes out it will stop working, (if there is a 3.10 rather than or as well 
as 4.0).

I am not sure if these potential issues warrant a separate ticket.

--

___
Python tracker 

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