[issue2518] smtpd.py to handle huge email

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

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

[issue19679] smtpd.py (SMTPChannel): implement enhanced status codes

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue14261] Cleanup in smtpd module

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

--
nosy: +barry
resolution:  -> wont fix
stage: needs patch -> 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

[issue3802] smtpd.py __getaddr insufficient handling

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

--
nosy: +barry
resolution:  -> wont fix
stage: test needed -> 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

[issue8503] smtpd SMTPServer does not allow domain filtering

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

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

[issue19806] smtpd crashes when a multi-byte UTF-8 sequence is split between consecutive data packets

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

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

[issue22159] smtpd.PureProxy and smtpd.DebuggingServer do not work with decode_data=True

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

--
nosy: +barry
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue22071] Remove long-time deprecated attributes from smtpd

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

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

[issue11260] smtpd-as-a-script feature should be documented and should use argparse

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

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

[issue22158] RFC 6531 (SMTPUTF8) support in smtpd.PureProxy

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

--
nosy: +barry
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue12816] smtpd uses library outside of the standard libraries

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and will likely not 
get any future development.  Please see aiosmtpd as a much better third party 
replacement.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue25553] smtpd strips final carraige return from received message body

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and likely won't see 
much future improvements.  Please take a look at aiosmtpd as a much better 
third party replacement.

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

[issue26036] Unnecessary arguments on smtpd.SMTPServer

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix simce smtpd.py is deprecated and likely won't see 
any future improvements.  Please take a look at aiosmtpd as a much better third 
party replacement.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue16462] smtpd should return greeting

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm closing this as won't fix since smtpd.py is deprecated and likely won't see 
any fixes.  Please take a look at aiosmtpd as a much better third party 
replacement.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue19678] smtpd.py: channel should be passed to process_message

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm going to close this as won't fix since smtpd.py is deprecated, and there's 
little chance that folks are still interested in working on it.  See aiosmtpd 
as a much better third party replacement.

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

[issue12815] Coverage of smtpd.py

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

smtpd.py is deprecated so there's really almost zero chance we'll be doing any 
development on it.  Please check out 

http://aiosmtpd.readthedocs.io/en/latest/

for a third party replacement (maybe pulled into the stdlib for 3.8?)

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Mark Shannon]

Mark Shannon  added the comment:

Can we stick to the one PR, please?
Once it is merged then we can improve things.

Also, I don't like leaving NULLs on the stack, they are an invitation to 
seg-fault. PR 5143 leaves more NULLs on the stack for longer.

--

___
Python tracker 

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

[issue30121] Windows: subprocess debug assertion on failure to execute the process

[STINNER Victor]

STINNER Victor  added the comment:

> Oops, I merged the pull requests, but I forgot to close the issue.

Oops, I forgot to close the issue, again... Thanks Segev for closing it, 
finally :-)

--

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 5143 is yet one alternative. It is a variant of PR 5006 that restores 
SETUP_EXCEPT and gets rid of the new opcode BEGIN_FINALLY. SETUP_FINALLY, 
SETUP_WITH and SETUP_ASYNC_WITH now push NULL on the stack instead.

PR 5143 removes and add fewer opcodes than PR 5006, but changes the behavior of 
more opcodes. I don't know what of them looks simpler.

--

___
Python tracker 

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

[issue32525] Empty tuples are not optimized as constant expressions

[benrg]

New submission from benrg :

>From 3.3 on, the expression () is compiled to BUILD_TUPLE 0 instead of 
>LOAD_CONST. That's probably fine and I suppose it's slightly more efficient to 
>avoid adding an entry to the constant table.

The problem is that BUILD_TUPLE 0 is not treated as a constant for folding 
purposes, so any otherwise constant expression that contain () ends up 
compiling into O(n) bytecode instructions instead of 1. I think this is a bug 
(rather than an enhancement) because it seems unlikely to be the intended 
behavior.

In 3.2 an earlier, and in 2.7, the constant-folding behavior is different, and 
many constant tuples aren't recognized at compile time for reasons unclear to 
me, but there are definitely cases it will fold that 3.3+ won't. For example, 
"x in {(), None}" tests a frozenset in 3.2, but builds a set at run time in 
3.3+.

--
components: Interpreter Core
messages: 309739
nosy: benrg
priority: normal
severity: normal
status: open
title: Empty tuples are not optimized as constant expressions
type: performance
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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +5002

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

> Still, this feature is not appealing enough to try to squeeze into 3.7 
> release schedule.  I think this should go through a round of discussion 
> either on datetime-sig or python-ideas.

Agreed. I will put together some summary in the next week or so and send it to 
one of those (probably python-ideas, I guess).

> Why not start with that?  Remember: python standard library is where code 
> goes to die.  By implementing this feature in dateutil you will not be tied 
> to relatively slow python release schedule.  Of course, you cannot change 
> datetime.now from a 3rd party module, but you can provide your own 
> dateutil.now with the desired features.

This is sort of independent of whether it is implemented in `datetime`, but 
it's a bit more complicated than that. I have already, for example, implemented 
a `today()` utility that does what `datetime.today()` should do if it weren't 
leaking implementation details from how `date.today()` is implemented (i.e. 
gives you the current date at midnight), because I think that's a very common 
use.

The reasons I brought this here are:

1. I would *prefer* it if what I implement is more or less in line with what is 
implemented in the standard library if a standard library solution is going to 
be provided so that my `dateutil` function is more of a version-independent 
backport than a "second way of doing things", so the direction that Python is 
going can inform how I choose to implement my `dateutil` backport.

2. The solution in `dateutil`, which provides functions and classes that 
manipulate `datetime`, will likely be different from how it is handled 
upstream, so it's worth having a discussion about what to do in the standard 
library - the standard library, for example, can overload existing operators on 
`datetime`, provide alternate constructors, or modify the arguments to existing 
alternate constructors. The semantics of this are somewhat different from a 
`dateutil` function that constructs a datetime (for example, there was a lot of 
discussion in `dateutil.utils.today` about what the function should be called - 
it would be cleanly namespaced if it were `datetime.today()`, but `today()` 
seems like it might return a `date`, etc).

For something like this, where `dateutil` is acting more like `boltons` in that 
it is providing little convenience functions and extensions to the `datetime` 
library, I think it makes sense to see whether this might get an implementation 
upstream and what that implementation might look like upstream, even if what 
happens is that I go off and implement something similar in `dateutil` and we 
give it a year or two in `pip` to see what problems arise.

I'll also note that even though `dateutil` has a less constrained release 
schedule and gets to backport features from later Python versions (allowing for 
earlier adoption), it's widely-used enough that I'm not very comfortable making 
backwards-incompatible releases. As a result, once an interface is released, 
it's more or less set, so it's more or less just as important to get this right 
in dateutil as it is in datetime.

--

___
Python tracker 

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

[issue32267] strptime misparses offsets with microsecond format

[Alexander Belopolsky]

Change by Alexander Belopolsky :


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

[issue30121] Windows: subprocess debug assertion on failure to execute the process

[Segev Finer]

Change by Segev Finer :


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

[issue32524] Python 2.7 leaks a packages __init__.py module object on SyntaxError

[Segev Finer]

Change by Segev Finer :


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

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> (And, honestly, `dateutil` would provide a version-independent backport 
> anyway).

Why not start with that?  Remember: python standard library is where code goes 
to die.  By implementing this feature in dateutil you will not be tied to 
relatively slow python release schedule.  Of course, you cannot change 
datetime.now from a 3rd party module, but you can provide your own dateutil.now 
with the desired features.

The only downside I see is that you will need to copy much of datetime.now 
implementation which is rather convoluted.

--

___
Python tracker 

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

[issue32524] Python 2.7 leaks a packages __init__.py module object on SyntaxError

[Segev Finer]

New submission from Segev Finer :

With the file hello/__init__.py:

ham = 123
spam()spam()

I get the following:

Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import hello
Traceback (most recent call last):
  File "", line 1, in 
  File "hello\__init__.py", line 2
spam()spam()
 ^
SyntaxError: invalid syntax
>>> import hello
>>> print hello

>>> print dir(hello)
['__doc__', '__file__', '__name__', '__package__', '__path__']
>>>

I'd expect to get the SyntaxError twice, which is indeed what happens on at 
least Python 3.6 (Possibly earlier Python 3 versions).

Originally found here https://github.com/pallets/flask/issues/2423 & 
https://github.com/pallets/flask/pull/2588

I'm going to submit a PR with a fix.

--
components: Interpreter Core
messages: 309736
nosy: Segev Finer
priority: normal
severity: normal
status: open
title: Python 2.7 leaks a packages __init__.py module object on SyntaxError
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am about +0 on adding a keyword argument to datetime.now.  Note that as I 
wrote in issue 19475 (msg202242), "precision" may be a misleading name because 
python makes no guarantee about the precision of the computer clock.

Still, this feature is not appealing enough to try to squeeze into 3.7 release 
schedule.  I think this should go through a round of discussion either on 
datetime-sig or python-ideas.

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

> This can be accomplished rather efficiently by truncating a time tuple:

This will not preserve tzinfo, and (though this is not a concern unless 
nanosecond precision is added), I don't believe it preserves microseconds 
either.

That said, it's also not very readable code without a wrapper - it's not 
obvious that you're trying to truncate, or what level you're truncating to, 
just reading it. I think it's worth considering "truncate" to be a first-class 
operation of datetimes, since it comes up very frequently - people truncating 
off unnecessary microseconds from `now`, people truncating the result of 
`datetime.now()` to get today, people getting the beginning of a given month, 
etc.

Of course, then the question is just "where does this wrapper live". It can 
live in user code, which is probably not ideal since a bunch of people are 
implementing their own versions of this common operation and carrying around 
`utils` submodules or whatever just for this, or it can live in third party 
libraries like `dateutil` or `boltons`, or it can live in the standard library 
- where it will likely get the most optimized treatment. (And, honestly, 
`dateutil` would provide a version-independent backport anyway).

That said, if the answer to the above is "not in the standard library", I think 
it makes sense to add a precision argument to `now`, since that is probably the 
most common use case for this sort of truncation function - and it also makes a 
lot of sense to allow users to specify the precision with which they get the 
current time.

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> replacing all elements of a datetime below a certain level is a very common 
> idiom

This can be accomplished rather efficiently by truncating a time tuple:

>>> t = datetime.now()
>>> datetime(*t.timetuple()[:6])
datetime.datetime(2018, 1, 9, 14, 47, 12)
>>> datetime(*t.timetuple()[:5])
datetime.datetime(2018, 1, 9, 14, 47)
>>> datetime(*t.timetuple()[:4])
datetime.datetime(2018, 1, 9, 14, 0)
>>> datetime(*t.timetuple()[:3])
datetime.datetime(2018, 1, 9, 0, 0)

if you do this often, you can wrap this in a function


_PARTS = {'seconds': 6, 'minutes': 5, ...}
def truncate_to(t, timespec):
return datetime(*t.timetuple()[:_PARTS[timespec])

--

___
Python tracker 

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

[issue24340] co_stacksize estimate can be highly off

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset d4864c61e3e27e337762dc45e504977299bd5b46 by Serhiy Storchaka in 
branch 'master':
bpo-24340: Fix estimation of the code stack size. (#5076)
https://github.com/python/cpython/commit/d4864c61e3e27e337762dc45e504977299bd5b46


--

___
Python tracker 

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

[issue29640] _PyThreadState_Init and fork race leads to inconsistent key list

[Petr Viktorin]

Petr Viktorin  added the comment:

WIP pull request: https://github.com/python/cpython/pull/5141
(I'll not get back to this for a few days, sadly.)

--

___
Python tracker 

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

[issue29640] _PyThreadState_Init and fork race leads to inconsistent key list

[Petr Viktorin]

Change by Petr Viktorin :


--
pull_requests: +5000
stage:  -> patch review

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> I think that a "truncate to rrule" function is *way* beyond the scope of the 
> standard library

I agree and I did not propose that.  What I said was that in the process of 
implementing truncate to rrule in dateutil you may encounter some common 
pattern that may benefit from a new stdlib datetime feature.

The operation that I often need is

def truncate_datetime(t:datetime, interval:timedelta, start=datetime.min) -> 
datetime
"""Return the largest datetime of the form start + interval * i not greater 
than t"""

but it is exactly the kind of one-liner that does not belong to stdlib.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thank you for the fix David!

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

[issue32493] UUID Module - FreeBSD build failure

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset b4ebaa7099c3413b42a9581c4ca560fe7540 by Antoine Pitrou (David 
Carlier) in branch 'master':
bpo-32493: Not only AIX, but FreeBSD has uuid_create support (#5089)
https://github.com/python/cpython/commit/b4ebaa7099c3413b42a9581c4ca560fe7540


--

___
Python tracker 

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

[issue32517] test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

[Matt Billenstein]

Matt Billenstein  added the comment:

Note, I can repro running it by hand from the cli.  And I cannot repro on 3.x, 
only 3.6 on the same machine.

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

> Looking at the dateutil, I don't see a truncate to rrule function.  Maybe a 
> good starting point would be to implement that in dateutil and if some 
> simpler pattern emerges that can be proposed for stdlib, we can discuss it 
> then.

I think that a "truncate to rrule" function is *way* beyond the scope of the 
standard library, since it would require an actual rrule implementation - about 
which there are still many questions. That said, to accomplish what you want, 
you would just use `rrule.before` (floor) or `rrule.after` (ceil):

from dateutil.rrule import rrule, DAILY
from datetime import datetime

rr = rrule(freq=DAILY, byhour=15, byminute=30, dtstart=datetime(2000, 1, 1))

print(rr.before(datetime(2011, 4, 17, 12, 18)))
# 2011-04-16 15:30:00

print(rr.before(datetime(2011, 4, 17, 16, 17)))
# 2011-04-17 15:30:00


That said, I don't see why this is any different from the `timespec` option to 
isoformat (with the exception that this would support `day` and `month`). In 
fact, in Python 3.7, you can implement it in *terms* of timespec fairly easily:

def truncate(dt, timespec):
return dt.fromisoformat(dt.isoformat(timespec=timespec))

I think the fact that `timespec` is useful indicates why this is useful even 
before serialization - a lot of times you want a datetime *up to a specific 
precision*. I would also argue that the fact that `replace` allows you to 
manipulate each component individually - and the fact that replacing all 
elements of a datetime below a certain level is a very common idiom - 
demonstrates that these arbitrary truncation rulesets *are* special in that 
they are among the most common operations that people do.

--

___
Python tracker 

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

[issue29640] _PyThreadState_Init and fork race leads to inconsistent key list

[Petr Viktorin]

Petr Viktorin  added the comment:

Gah! The more I look into locks & forks ... the more I learn, to put it mildly.

Instead of piling on workarounds, I'll try my hand at using native thread-local 
storage for pthread, and avoid the locking altogether.

Hopefully that can make it in as a bugfix? At least for this bug, it most 
likely *is* the most appropriate fix -- though I can only fix it for pthread.

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

The problem that I have with the round/truncate proposal is that it is not 
general enough.  Days, hours, minutes etc. are just arbitrary intervals that 
became popular for obscure historical and astronomical reasons.  In practice, 
you are as likely to encounter 1 second timeseries as say 10 second timeseries. 
 Hourly timeseries are as likely to use the "top of the hour" (0 minutes) as 
they are to use the "bottom of the hour" (30 minutes).  In general, you want to 
have a kind of "snap to grid" functionality on the time axis where "the grid" 
is an arbitrary RRULE.

Looking at the dateutil, I don't see a truncate to rrule function.  Maybe a 
good starting point would be to implement that in dateutil and if some simpler 
pattern emerges that can be proposed for stdlib, we can discuss it then.

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Jan 9, 2018, at 08:33, Paul Ganssle  wrote:

> @Barry I don't think it's a good idea to duplicate the `replace` 
> functionality in `datetime` like that. I think the main problem isn't the 
> `.replace`, it's the fact that you have to specify exactly which components 
> you want to set to zero - to get "the beginning of this month" or "today at 
> midnight" or "the beginning of the current hour" or "the beginning of the 
> current minute", you have to manually replace a whole list of these 
> components.

I personally haven’t ever had to do anything but get rid of the microseconds 
field, so maybe my use case is too limited.  It’s a minor inconvenience and I 
don’t like having to throw away an intermediate datetime, so that’s the main 
thing I’d like to improve.  I’d also caution trying to get too fancy and 
complicated for use cases that are already supported or are rare.

--

___
Python tracker 

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

[issue10496] Python startup should not require passwd entry

[Melissa Chang]

Change by Melissa Chang :


--
nosy:  -Melissa Chang

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

> In my experience, when dealing with temporal data truncation (rounding 
> towards -infinity) is more useful than any other form of rounding. See also 
> issue 19475.

Ah, I agree - if you see that's how my __round__ implementation works. I guess 
that's another problem with the semantics of `round` (which are assumed to 
round to the nearest whole number). I suppose we could implement __floor__, but 
then you have the counter-intuitive property that in order to get access to 
this method, you have to import `math.floor`.

We could add a `datetime.truncate()` method, maybe, and not try to be clever 
about overloading existing operations. Or punt on the idea of truncation in 
general and do what I proposed in the original thread and have all the 
truncation happen in `now`.

--

___
Python tracker 

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

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt  added the comment:

On 09/01/2018 16:21, Antoine Pitrou wrote:
> Antoine Pitrou  added the comment:
>
>> What is the desired behavior, specifically, of
> uuid.getnode() - constant, or 'random'?
>
> I'm also certain getnode() is supposed to return a hardware-determined number 
> (usually the MAC address of an Ethernet interface).  A random output wouldn't 
> need so much platform-specific harness.

FYI

The current implementation (Lib/uuid.py) - python2 as an example with 
with no _uuid support, compared to the master (as of yesterday) with 
_uuid support.

Program (x2.py):

michael@x071:[/data/prj/python/git]cat *master/x2.py
import uuid
import sys
print (sys.version)
print("getnode = %x\n" % uuid.getnode())
print("getnode = %x\n" % uuid.getnode())

michael@x071:[/data/prj/python/git]python *master/x2.py
2.7.12 (default, Sep 29 2016, 12:02:17) [C]
getnode = a92929dc8a78

getnode = a92929dc8a78

michael@x071:[/data/prj/python/git]python *master/x2.py
2.7.12 (default, Sep 29 2016, 12:02:17) [C]
getnode = cdff09dd1306

getnode = cdff09dd1306

So it appears, everytime python runs - without _uuid - a new "getnode()" 
value is established, for as long as the process runs (hoping!)

Below - the value returned is the MAC address of the first ethernet 
adapter (ent0)

michael@x071:[/data/prj/python/git]gcc*/python *master/x2.py
3.7.0a3+ (default, Jan  8 2018, 16:05:08)
[GCC 4.7.4]
getnode = fad18cf76204

getnode = fad18cf76204

michael@x071:[/data/prj/python/git]xlc*/python *master/x2.py
3.7.0a3+ (heads/master:9b99747, Jan  8 2018, 15:50:03) [C]
getnode = fad18cf76204

getnode = fad18cf76204

*

Is there any interest for a PR on Python2.7 and/or Python3.5? I guess it 
could be considered a bug IF the getnode() value is suppossed to be 
related to the MAC address and/or consistent over sessions.

HTH, Michael

>
> --
> nosy: +pitrou
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Pox, please retest with either 3.6.4 or 3.7.0a3 (or .0a4 when released, soon).  
Both were released after the merge that should fix this.

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

In my experience, when dealing with temporal data truncation (rounding towards 
-infinity) is more useful than any other form of rounding. See also issue 19475.

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

One thing to note, the "example implementation" of __round__ above is an actual 
working prototype*:

>>> round(Datetime.now(), 'second')
Datetime(2018, 1, 9, 11, 59, 35)

>>> round(Datetime.now(), 'day')
Datetime(2018, 1, 9, 0, 0)

>>> round(Datetime.now(), 'minute')
Datetime(2018, 1, 9, 11, 59)


So to be clear, `ndigits` can already accept any arbitrary type, it's just the 
fact that it's *called* `ndigits` that may be confusing to users.

*with the exception that it has a bug, the final line should actually be:

return self.replace(**{arg: dflt_args[arg] for arg in args[(idx+1):]})

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

I think if we're going to use `timedelta` then `__mod__` is the more 
appropriate option here, since it would be hard to interpret what `round(dt, 
timedelta(hours=2, microseconds=31))` would do.

Either __mod__ or __round__ with `timedelta` is a bit of a stretch in my 
opinion, and also is limited to well-defined units (and as such you can't round 
to the nearest month or year). I think a `round` taking either a string or an 
enum is the simplest, easiest to understand implementation (and/or adding a 
precision argument to `now` that is equivalent to `round(datetime.now(), 
precision)`).

--

___
Python tracker 

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

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

@Pox, nevertheless, the fix committed in 
https://github.com/python/cpython/pull/4073 should also fix this issue. Do you 
disagree?

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Maybe __round__ can be generalized to take a timedelta instead of ndigits?

For some related prior art, take a look at 
.

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

@Barry I don't think it's a good idea to duplicate the `replace` functionality 
in `datetime` like that. I think the main problem isn't the `.replace`, it's 
the fact that you have to specify exactly which components you want to set to 
zero - to get "the beginning of this month" or "today at midnight" or "the 
beginning of the current hour" or "the beginning of the current minute", you 
have to manually replace a whole list of these components.

It doesn't help that `datetime.today()` leaks implementation details from 
`date.today()`, thus making it a slower, worse version of `datetime.now()`, 
since the overwhelmingly most common use cases for datetime rounding are 
probably "get today at midnight" and "get the current time with second 
precision". Still, I think a more general fix would be better now and in the 
future.

Even if we had "get today at midnight" and a `microseconds=0` argument to 
`datetime.now`, without a more general version of this, if (or possibly *when*) 
nanosecond precision is added to `datetime`, you'd now start having to add 
`microseconds=0, nanoseconds=0` or something to `datetime` (depending on the 
implementation of nanoseconds).

--

___
Python tracker 

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

[issue32523] inconsistent spacing in changelog.html

[Ned Deily]

Ned Deily  added the comment:

See also discussion at https://github.com/python/core-workflow/issues/209

--

___
Python tracker 

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

[issue29640] _PyThreadState_Init and fork race leads to inconsistent key list

[STINNER Victor]

STINNER Victor  added the comment:

Python 3 is not affected by this issue because it uses native thread locale 
storage (TLS):

* pthread: pthread_getspecific() / pthread_setspecific()
* Windows: TlsGetValue() / TlsSetValue()

I'm not sure that it's doable to backport such enhancement, since Python 2.7 
supports many thread implementations, not only NT (Windows) and pthread:

* Python/thread_atheos.h
* Python/thread_beos.h
* Python/thread_cthread.h
* Python/thread_lwp.h
* Python/thread_nt.h
* Python/thread_os2.h
* Python/thread_pth.h
* Python/thread_pthread.h
* Python/thread_sgi.h
* Python/thread_solaris.h
* Python/thread_wince.h

Maybe it's doable for a Linux vendor, but it's going to be a large change that 
has to be maintained downstream :-/

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

The .replace(microseconds=0) hack annoys me too, but I'd be happier with a 
simpler solution: make datetime.now() accept a microseconds parameter, so 
datetime.now(microseconds=0) would be equivalent to 
datetime.now().replace(microseconds=0)

--

___
Python tracker 

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

[issue32523] inconsistent spacing in changelog.html

[Ned Deily]

New submission from Ned Deily :

The rendered changelog.html files produced "make html" have inconsistent 
spacing between items. Usually, the first changelog topic section (e.g. 
Security) starts with no blank lines between items but occasionally some 
subsequent sections will render with a blank link between items; this seems to 
be often true for the Library section, but not always. This is visible across 
the recent 3.x branches; here's an example with the stable 3.5 docs:

Library section has blank line separator:
https://docs.python.org/3.5/whatsnew/changelog.html#id5

Library section has no blank separators:
https://docs.python.org/3.5/whatsnew/changelog.html#id11

--
assignee: docs@python
components: Documentation
messages: 309711
nosy: docs@python, ned.deily
priority: normal
severity: normal
status: open
title: inconsistent spacing in changelog.html
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

[issue32522] Add precision argument to datetime.now

[Barry A. Warsaw]

Change 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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Change by Paul Ganssle :


--
type:  -> enhancement

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[Marcel Plch]

Marcel Plch  added the comment:

I have created a PR at https://github.com/python/cpython/pull/5140
It contains documentation, plus, in --with-pydebug mode, it calls m_traverse to 
catch easy cases of not handling the m_state==NULL case early.

--

___
Python tracker 

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

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

[Pox TheGreat]

Pox TheGreat  added the comment:

Unfortunately this is NOT a duplicate of https://bugs.python.org/issue28326. 
That issue is about a closed output stream. In that case sys.stdout and 
sys.stderr are file like objects which have been closed.

This issue is about sys.stdout and sys.stderr being None! This is because 
pythonw was used not python.

--
resolution: duplicate -> 
status: closed -> open

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

@Victor: With regards to getting a "date as datetime", that is another way to 
do it that I have also done in the past (and in fact it's how the new 
dateutil.utils.today() function is implemented: 
https://github.com/dateutil/dateutil/blob/master/dateutil/utils.py#L7), but 
it's still not particularly elegant and doesn't obviously convey what you want 
there.

And yes, I'm aware of timespec, I linked it in my original report (it was 
actually added in Python 3.6).

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

Paul Ganssle  added the comment:

An alternate possibility here might be to implement either `__round__` or a 
`round` function in `datetime` (which would basically automatically add this 
precision functionality to *all* the constructors, not just now). An example 
implementation:

from datetime import datetime

class Datetime(datetime):
def __round__(self, ndigits=None):
if ndigits is None:
return self

dflt_args = {
'month': 1,
'day': 1,
'hour': 0,
'minute': 0,
'second': 0,
'microsecond': 0
}

args = list(dflt_args.keys())

if ndigits not in dflt_args:
raise ValueError('Unknown rounding component: %s' % ndigits)

idx = args.index(ndigits)

return self.replace(**{arg: dflt_args[arg] for arg in args[idx:]})


It's not great that `__round__`'s argument is `ndigits`, though. If we don't 
want to just add a `round` method to `datetime`, another option might be to 
implement `__mod__` somehow, so you could do `datetime.now() % 
timedelta(seconds=1)`, but that seems complicated (and also doesn't let you 
round to the nearest month).

--

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[Marcel Plch]

Change by Marcel Plch :


--
pull_requests: +4999

___
Python tracker 

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

[issue29640] _PyThreadState_Init and fork race leads to inconsistent key list

[STINNER Victor]

STINNER Victor  added the comment:

There is a more general issue for any lock and fork(): bpo-6721, "Locks in the 
standard library should be sanitized on fork".

--

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[STINNER Victor]

STINNER Victor  added the comment:

> dt = datetime.now(precision='day')

Why not creating a date and then convert it to a datetime object?

> dt = datetime.now().replace(microseconds=0)

Yeah, that one annoys me as well, but I learnt the .replace(microseconds=0) 
hack, or how to format without microseconds.

By the way, are you aware of Python 3.7 enhancement of .isoformat(), the new 
timespec parameter?
https://docs.python.org/dev/library/datetime.html#datetime.datetime.isoformat

--
nosy: +vstinner

___
Python tracker 

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

[issue32522] Add precision argument to datetime.now

[Paul Ganssle]

New submission from Paul Ganssle :

One thing I think that is fairly common is the desire to get the current 
datetime only up to a current precision, so you see a lot of things in, say, 
`dateutil` like this:

dt = datetime.now().replace(hours=0, minutes=0, seconds=0, microseconds=0)

Or:

dt = datetime.now().replace(microseconds=0)

I think it would make sense to add a `precision` keyword argument, similar to 
the `timespec` argument to isoformat 
(https://docs.python.org/3/library/datetime.html#datetime.datetime.isoformat), 
then you could just do:

dt = datetime.now(precision='day')

And get the current date as a datetime.

--
components: Library (Lib)
messages: 309703
nosy: belopolsky, p-ganssle, tim.peters
priority: normal
severity: normal
status: open
title: Add precision argument to datetime.now
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

[issue32493] UUID Module - FreeBSD build failure

[David Carlier]

David Carlier  added the comment:

I guessed that :-) I trusted it worked just fine for you. To be honest I know 
nearly nothing about AIX specificities :-)

--

___
Python tracker 

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

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> What is the desired behavior, specifically, of 
uuid.getnode() - constant, or 'random'?

I'm also certain getnode() is supposed to return a hardware-determined number 
(usually the MAC address of an Ethernet interface).  A random output wouldn't 
need so much platform-specific harness.

--
nosy: +pitrou

___
Python tracker 

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

[issue29640] _PyThreadState_Init and fork race leads to inconsistent key list

[Petr Viktorin]

Petr Viktorin  added the comment:

I'm a bit out of my depth here. Victor, could you chime in?

The problem with Harris' patch is that, once fork() is protected by the thread 
lock, acquiring that lock (by e.g. calling `PyGILState_GetThisThreadState`) 
from an `atfork` handler hangs deadlocks.

I thought that can be solved by doing the locking in an atfork handler, but 
that's not working out -- CPython's pthread_atfork (which would lock 
_PyThread_AcquireKeyLock for the duration of the fork) would need to be called 
*after* an extension's pthread_atfork (which needs the thread lock temporarily).

--

___
Python tracker 

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

[issue32007] nis module fails to build against glibc-2.26

[Christian Heimes]

Christian Heimes  added the comment:

#32521 is a duplicate of this issue. I didn't notice this issue when I created 
a fix.

- I agree with Benjamin, let's deprecate the NIS module. NIS/YP functionality 
has been replaced by NSS a long time ago.
- We have no infrastructure to use pkg-config from distutils yet, which is a 
shame.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Thomas Wouters]

Thomas Wouters  added the comment:

We do use Setup/Setup.local at Google (and have for many years now), and I find 
it very useful. (FWIW, the 'we would use' comment in msg294174 was about the 
new '*disabled*' feature, not about Setup files in general.) Avoiding local 
changes is also important to us, because it makes it much easier to track 
upstream changes. If anyone was thinking of getting rid of Modules/Setup, 
please don't, at least not without something more sensible than setup.py to 
replace it :)

That said, I don't really care about the Setup.dist/Setup distinction. I 
vaguely recall the situation before we had Setup.dist, which I guess was 
slightly worse, but primarily for people who build from the source repo. Having 
a Setup.local file is convenient as long as the Setup file is necessary for the 
base build, but Setup/Setup.dist doesn't matter.

--

___
Python tracker 

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

[issue32518] HTTPServer can't deal with persistent connection properly

[R. David Murray]

R. David Murray  added the comment:

Well, it does support a persistent connection, but that connection lasts until 
it is shut down from the other side.  Documentation improvement suggestions are 
welcome.

--

___
Python tracker 

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

[issue32518] HTTPServer can't deal with persistent connection properly

[R. David Murray]

R. David Murray  added the comment:

In particular, if we don't already have an example of using the threading mixin 
we should, so a doc RFE to add that would be nice.

--

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

[Anant Prakash]

Anant Prakash  added the comment:

Ignore my previous comment.
My bad.

--

___
Python tracker 

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

[issue32459] Capsule API usage docs are incompatible with module reloading (etc)

[Petr Viktorin]

Change by Petr Viktorin :


--
nosy: +Dormouse759, encukou

___
Python tracker 

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

[issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed

[Andy Balaam]

Andy Balaam  added the comment:

I would argue that this makes as_completed a lot more useful than it is now, so 
would be worth adding (maybe after 3.7).

But, if this does not go into asyncio, is there another library where it would 
belong?  Or should this be a completely new library?

--

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Tom Karzes]

Tom Karzes  added the comment:

Here's my situation:  I originally used optparse, although some of the guys I 
worked with at the time were starting to use argparse.  At first I thought, I'm 
sticking with optparse, it's more standard than argparse and probably better 
supported.  But at some point optparse became documented as deprecated, with 
argparse being hailed as its replacement.

At that point my preference switched, again mostly because I wanted the most 
reliable, best supported option parsing package.  And yes, I have come to 
appreciate some of the features of argparse, but to me that takes a back seat 
to correct functionality.

The documentation for argparse promotes the idea that it completely subsumes 
optparse, and that applications that use optparse can easily be converted to 
use argparse.  And for the most part that's true, except that optparse 
identifies options correctly and argparse does not.  That really, really needs 
to be documented.

What I want is a supported, standard option parsing library that knows how to 
extract option values correctly.  I used to have that with optparse, but now I 
feel like the rug's been pulled out from under me.  optparse is supposedly 
deprecated, and argparse doesn't work.  So I either use a package that could be 
removed from Python distributions at any time, or I use a package that has 
dangerous bugs.  I don't find either alternative very attractive.

As I said, un-deprecating optparse would be sufficient, especially if people 
started adding some of the argparse functionality to it.  Creating a new 
package would work too.  But from what I've seen, it sounds like argparse is 
beyond hope of repair and will never work properly.  I.e., it's a dead-end 
development path.  So why isn't *argparse* deprecated?

I've always maintained that core functionality is of primary importance.  Shiny 
bells and whistles, no matter how useful, are of secondary importance.  In my 
opinion, the wrong package was deprecated.

--

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

[Anant Prakash]

Anant Prakash  added the comment:

I am going to take the patch, edit and make a github PR for this.

Any updates on this issue are welcome. Thank you

--
nosy: +Anant Prakash

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Eric V. Smith]

Eric V. Smith  added the comment:

I tend to agree with you about pre-scanning the arguments to find options. But 
at this point, our options to change the code are limited. The last time I 
looked at this (and it's been years), I came to the conclusion that the 
argument pre-scanning was sufficiently baked in to argparse that a separate 
traditional" mode was better done as a separate library.

But I lack the time and energy to research if there's an existing third party 
library that's acceptable, what it would take to enhance optparse, or write a 
new library.

It sounds like what you want is optparse, but with help in processing 
positional arguments. Is that a fair statement? Or is there some other feature 
of argparse that's preventing you from using optparse? I know for me it's help 
with positional arguments.

I think at some point we need to close this bug, because I don't see a way of 
modifying argparse to do what you (and I) want. paul.j3 explains several times 
in his messages on this thread that it's just how argparse fundamentally works.

--

___
Python tracker 

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

[issue32517] test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

[Matt Billenstein]

Matt Billenstein  added the comment:

I don't see a conflict in the uids:

mattb@mattb-mbp2:~ $ id -u buildbot
506
mattb@mattb-mbp2:~ $ id -u _timed
266
mattb@mattb-mbp2:~ $ grep _timed /etc/passwd
_timed:*:266:266:Time Sync Daemon:/var/db/timed:/usr/bin/false
mattb@mattb-mbp2:~ $ grep 506 /etc/passwd
mattb@mattb-mbp2:~ $

Buildbot is started via launchd:

mattb@mattb-mbp2:~ $ sudo cat /Library/LaunchDaemons/net.buildbot.slave.plist

http://www.apple.com/DTDs/PropertyList-1.0.dtd;>


Label
net.buildbot.slave
UserName
buildbot
WorkingDirectory
/Users/buildbot/buildarea
ProgramArguments

/Users/buildbot/bin/run_slave.sh

StandardOutPath
twistd.log
StandardErrorPath
twistd.log
KeepAlive

SessionCreate




--

___
Python tracker 

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

[issue32507] Change Windows install to applocal UCRT

[Steve Dower]

Steve Dower  added the comment:

Missed the a4 cutoff, but it'll be in 3.7.0b1.

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

[issue32507] Change Windows install to applocal UCRT

[Steve Dower]

Steve Dower  added the comment:


New changeset d135f20ae8887acc7716561bc8f4c7eb6d58d24c by Steve Dower in branch 
'master':
bpo-32507: Change Windows install to include app-local UCRT (#5119)
https://github.com/python/cpython/commit/d135f20ae8887acc7716561bc8f4c7eb6d58d24c


--

___
Python tracker 

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