[issue32070] Clarify the behavior of the staticmethod builtin

2018-12-23 Thread Raymond Hettinger


Change by Raymond Hettinger :


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



[issue35105] Document that CPython accepts "invalid" identifiers

2018-12-23 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

I don't think we can mark this as an implementation detail for setattr(). The 
details are downstream and determined by the target object, not by setattr() 
itself.

Suggested wording:

'''
Note, setattr() attempts to update the object with the given attr/value pair.
Whether this succeeds and what its affect is is determined by the target object.
If an object's class defines `__slots__`, the attribute may not be writeable.
If an object's class defines property with a setter method, the *setattr()*
will trigger the setter method which may or may not actually write the 
attribute.
For objects that have a regular dictionary (which is the typical case), the
*setattr()* call can make any string keyed update allowed by the dictionary
including keys that aren't valid identifiers -- for example setattr(a, '1', 
'one')
will be the equivalent of vars()['1'] ='one'.
This issue has little to do with setattr() and is more related to the fact that 
instance dictionaries can hold any valid key. In a way, it is no different than 
a user writing a.__dict__['1'] = 'one'. That has always been allowed and the 
__dict__ attribute is documented as writeable, so a user is also allowed to 
write `a.dict = {'1': 'one'}.
'''

In short, we can talk about this in the setattr() docs but it isn't really a 
setattr() issue. Also, the behavior is effectively guaranteed by the other 
things users are allowed to do, so there is no merit in marking this as an 
implementation detail. Non-identifier keys can make it into an instance 
dictionary via multiple paths that are guaranteed to work.

--
nosy: +rhettinger

___
Python tracker 

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



[issue30561] sync-up gammavariate and expovariate code

2018-12-23 Thread Raymond Hettinger


Change by Raymond Hettinger :


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



[issue35568] Expose the C raise() function in the signal module, for use on Windows

2018-12-23 Thread Vladimir Matveev


Change by Vladimir Matveev :


--
nosy: +v2m

___
Python tracker 

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



[issue35575] Improved range syntax

2018-12-23 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

These proposals probably should be discussed on Python-Ideas first. You should 
also familiarize yourself with previous proposals to enhance range, such as

https://mail.python.org/pipermail/python-ideas/2018-November/054510.html

and the bug report #35200

For what it is worth, Guido was generally (slightly) opposed to "constant bool 
parameters", functions that take a parameter which is generally given as a 
literal True/False flag. That's often (not always) a design smell. I agree with 
him, so I would be very wary about adding not one but two such constant bool 
parameters.

Especially for such a trivial enhancement. There's nothing in the 
`inc_start=True, inc_stop=False` functionality which can't be more easily done 
by simply adding one to the appropriate range arguments:

# same as inc_start=False, inc_stop=True but easier
range(start+1, end+1)  


You say:

"a mix of round parentheses and square brackets could be allowed"


but I think such a proposal would run foul of the requirement that Python's 
grammar be no more complex than LL(1). 

(Someone will correct me if I'm wrong.)

--
nosy: +steven.daprano

___
Python tracker 

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



[issue35574] Coconut support

2018-12-23 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

One more thing: if you intend to proceed with this, either as individual 
enhancements or a PEP, you should discuss them on the Python-Ideas mailing list 
first, to see how much or little community support the proposals have.

Until then, I'm closing this as "Postponed".

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



[issue35573] is_HDN is returns false positive and false negative value for two test cases respectively

2018-12-23 Thread Divya Rani


Divya Rani  added the comment:

The function link is here: 
https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/http/cookiejar.py#L521

The function returned true for "foo!bar.com" which is false positive and the 
test case is taken from the list of invalid domain names present in Guava test 
suite 
https://github.com/google/guava/blob/581ba1436ebaa54a7f5d0f1db8cc4da0ca72127e/android/guava-tests/test/com/google/common/net/InternetDomainNameTest.java#L81

Domain names with dots at the end are fully qualified domain names. (reference:
1.https://stackoverflow.com/questions/19480767/domain-names-with-dots-at-the-end#answer-19498025
2. https://en.wikipedia.org/wiki/Fully_qualified_domain_name#Syntax
)
the function returned false for "woo.com." which is a false negative.
The test case is again taken from list of valid domain names provided by guava 
test suite 
(https://github.com/google/guava/blob/581ba1436ebaa54a7f5d0f1db8cc4da0ca72127e/android/guava-tests/test/com/google/common/net/InternetDomainNameTest.java#L65)

--
nosy:  -xtreak

___
Python tracker 

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



[issue35574] Coconut support

2018-12-23 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Do you have agreement from the maintainer(s) of Coconut that they are willing 
to put Coconut into the Python language and/or std library?

Given that Coconut is effectively a radically different language from Python (a 
superset of Python) this is not a small change. While it is at least possible 
that we would consider individual features from Coconut, integrating the two 
languages is unlikely. That would basically turn Python into Coconut and make 
Python obsolete.

In any case, as a radical change, possibly as big as the move from Python 2 to 
3, this will absolutely need a PEP.

https://www.python.org/dev/peps/

You say:

"Coconut allows making code *so* much more readable."

but that's your opinion, I'm sure that there are many people who don't like or 
appreciate the sort of functional idioms which Coconut specializes in.

But having said that, I personally do like *some* of the Coconut syntax. I 
think a more productive approach will be to propose *individual* enhancements, 
allowing each enhancement to be considered on its own merits, rather than 
suggesting the two languages be integrated. That sort of "everything or 
nothing" approach is almost certainly going to get the response "OK, nothing".

As for the IDE support, that's not our problem. We're not responsible for 
convincing IDEs to provide better support for every experimental third-party 
language.

--
nosy: +steven.daprano

___
Python tracker 

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



[issue35576] function splitextTest does not return expected value

2018-12-23 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

As Karthikeyan said, (1) is a duplicate of issue35538. This is expected 
behavior.

(2) is a duplicate of issue35183 which is still discussed.

I do not know what relations do tests for third-party Java library have with 
the Python stdlib. Note that that tests imply that the extension of ".." is 
".", that is considered obviously wrong.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> os.path.splitext documentation needs typical example

___
Python tracker 

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



[issue35573] is_HDN is returns false positive and false negative value for two test cases respectively

2018-12-23 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

> What is the module "cookiejar" you are importing? Is that a third-party 
> module? It doesn't seem to be in the standard library. There is a module 
> `http.cookiejar` but it doesn't seem to have an `is_HDN` function.

is_HDN does exist in http.cookiejar [0] which I assume OP is referring to but 
it's undocumented and used internally in other functions. From the comments and 
given it was added in 2a6ba9097ee (2004) this may not be as extensive as the 
guava implementation which I assume is at [1]

IPV4_RE = re.compile(r"\.\d+$", re.ASCII)
def is_HDN(text):
"""Return True if text is a host domain name."""
# XXX
# This may well be wrong.  Which RFC is HDN defined in, if any (for
#  the purposes of RFC 2965)?
# For the current implementation, what about IPv6?  Remember to look
#  at other uses of IPV4_RE also, if change this.
if IPV4_RE.search(text):
return False
if text == "":
return False
if text[0] == "." or text[-1] == ".":
return False
return True

[0]  
https://github.com/python/cpython/blob/b7105c9c9663637e4500bfcac75c911e78d9a1c0/Lib/http/cookiejar.py#L521
[1] 
https://github.com/google/guava/blob/1e072a7922a0b3f7b45b9f53405a233834175177/guava/src/com/google/common/net/InternetDomainName.java#L132

--
nosy: +xtreak

___
Python tracker 

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



[issue35576] function splitextTest does not return expected value

2018-12-23 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Please provide a proper reproducible bug report. Don't make us GUESS what 
function you are referring to.

I don't know any "splitextTest" function that you describe in the bug report 
title. Do you mean os.path.splitext? Then you should say so. If not, then what 
function are you referring to?

What results do you expect, why do you expect them, and what results do you get?

Why should we care what test results some Java library returns? Maybe they've 
got it wrong, or maybe their function just works differently from ours. Unless 
this function is documented as being exactly compatible with the Java code you 
link to, I don't think it is very important what guava does.

Perhaps you should raise a bug report at Guava and tell them that according to 
the Python language, their function is wrong.

The os.path.splitext function is documented as returning the file extension as 
either the empty string "" or beginning with a single period, and leading dots 
are not part of the extension. So the examples you show are correct, if you are 
talking about os.path.splitext. If you are talking about something else, please 
explain what.

https://docs.python.org/3/library/os.path.html#os.path.splitext

--
nosy: +steven.daprano

___
Python tracker 

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



[issue35576] function splitextTest does not return expected value

2018-12-23 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

Thanks for the report

> 1. For input ".blah." output is "." 

Please see issue35538

> 2. For input "..." output is "..." 

Please find the tests at 
https://github.com/python/cpython/blob/master/Lib/test/test_posixpath.py#L111

For completeness this is the behavior in master

./python.exe
Python 3.8.0a0 (heads/master:284b787612, Dec 23 2018, 23:11:33)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.splitext("...")
('...', '')
>>> os.path.splitext(".blah.")
('.blah', '.')

You can find links to other discussions in mailing list and other issues raised 
about this behavior at https://bugs.python.org/issue34931#msg328820 . Though 
this might be different from the behavior of guava I think this is something 
discussed extensively in the mailing list and finally to go with this behavior. 
So I don't think this is a bug but a behavior difference between guava and 
CPython implementation.

--
nosy: +xtreak

___
Python tracker 

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



[issue35573] is_HDN is returns false positive and false negative value for two test cases respectively

2018-12-23 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

What is the module "cookiejar" you are importing? Is that a third-party module? 
It doesn't seem to be in the standard library. There is a module 
`http.cookiejar` but it doesn't seem to have an `is_HDN` function.

If this is a third-party library, please close this and report it to the 
maintainers of that library.

Can you please explain *why* these are "false positive" and "false negative", 
and which is which?

In particular, do you know for a fact that the test cases you reference 
actually pass, and are correct if they pass? I'm not an expert, but I don't 
think domain names can end with a dot, and the "woo.com." test case is the 
*only* one which ends with a dot, so I suspect it may be a typo, and the test 
case doesn't actually pass. (Or if it does pass, perhaps it shouldn't.)

--
nosy: +steven.daprano

___
Python tracker 

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



[issue33661] urllib may leak sensitive HTTP headers to a third-party web site

2018-12-23 Thread Emmanuel Arias


Emmanuel Arias  added the comment:

Hi!, 

Like say Katsuhiko YOSHIDA 
(https://github.com/python/cpython/pull/11292#issuecomment-449667371) this 
should be filter other sensitive header. I think that is reasonable if we think 
on a complete solution to this issue. 

Maybe this issue could be apply on 3.5+ version?

--
nosy: +eamanu

___
Python tracker 

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



[issue34764] Improve documentation example for using iter() with sentinel value

2018-12-23 Thread Raymond Hettinger


Change by Raymond Hettinger :


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



[issue35566] DOC: Add links to annotation glossary term

2018-12-23 Thread Raymond Hettinger


Change by Raymond Hettinger :


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



[issue35576] function splitextTest does not return expected value

2018-12-23 Thread Divya Rani


New submission from Divya Rani :

1. For input ".blah." output is "." 
2. For input "..." output is "..." 

results produced by the function are wrong according to the test suite provided 
by guava.
1. 
https://github.com/google/guava/blob/1e072a7922a0b3f7b45b9f53405a233834175177/guava-tests/test/com/google/common/io/FilesTest.java#L644
2.
https://github.com/google/guava/blob/1e072a7922a0b3f7b45b9f53405a233834175177/guava-tests/test/com/google/common/io/FilesTest.java#L628

--
components: Library (Lib)
messages: 332407
nosy: Divya Rani
priority: normal
severity: normal
status: open
title: function splitextTest does not return expected value
type: behavior
versions: Python 3.6

___
Python tracker 

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



[issue35573] is_HDN is returns false positive and false negative value for two test cases respectively

2018-12-23 Thread Divya Rani


Divya Rani  added the comment:

import cookiejar

cookiejar.is_HDN("foo!bar.com")
Output:
True

cookiejar.is_HDN("woo.com.")

Output:
False

Test cases taken from:
1. 
https://github.com/google/guava/blob/581ba1436ebaa54a7f5d0f1db8cc4da0ca72127e/android/guava-tests/test/com/google/common/net/InternetDomainNameTest.java#L81
2.
https://github.com/google/guava/blob/581ba1436ebaa54a7f5d0f1db8cc4da0ca72127e/android/guava-tests/test/com/google/common/net/InternetDomainNameTest.java#L65

--
nosy:  -xtreak

___
Python tracker 

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



[issue33678] selector_events.BaseSelectorEventLoop.sock_connect should preserve socket type

2018-12-23 Thread twisteroid ambassador


twisteroid ambassador  added the comment:

Looks like this bug is also cause by using _ensure_resolved() more than once 
for a given host+port, so it can probably be fixed together with 
https://bugs.python.org/issue35545 .

Masking sock.type should not be necessary anymore since 
https://bugs.python.org/issue32331 fixed it.

--
nosy: +twisteroid ambassador

___
Python tracker 

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



[issue35573] is_HDN is returns false positive and false negative value for two test cases respectively

2018-12-23 Thread Karthikeyan Singaravelan


New submission from Karthikeyan Singaravelan :

Can you please add a reproducible test case and a description to the issue 
explaining expected behavior and actual behavior?

Thanks

--
nosy: +xtreak

___
Python tracker 

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



[issue35575] Improved range syntax

2018-12-23 Thread Solomon Ucko


New submission from Solomon Ucko :

3 independent but related proposals. (#4 requires #3.) The main issue for #2 
and #4 is the readability of a mix of square and round brackets, especially 
within nested brackets. This would be less of an issue with [Coconut 
support](https://bugs.python.org/issue35574).

#1. Range inclusive/exclusive keyword arguments (mostly backward compatible)

Inclusive/exclusive options for range as keyword arguments (defaulting to 
`inc_start=True, inc_stop=False`). Code that processes range objects will 
ignore these unless using `in` tests. The semantics would be as follows:

```python
class range:
...

def __iter__(self):
if self.inc_start:
yield self.start

i = self.start + self.step

while i < self.stop if self.step > 0 else i > self.stop:
yield i
i += self.step

if self.inc_stop and i == self.stop:
yield i
```

This would allow for control over the slightly controversial decision of 
inclusivity/exclusivity for ranges on a case-by-case basis. Any existing code 
that creates ranges would not be impacted.


#2. Range syntax (fully backward compatible)

Maybe `(start:stop)`, `(start:stop]`, `[start:stop)` and `[start:stop]` could 
be used to represent ranges? (`(` = exclusive; `[` = inclusive.) Step notation 
would also be legal. (E.g. `(start:stop:step)`.)

This would allow for a concise, familiar notation for ranges.


#3. Slice inclusive/exclusive keyword arguments (mostly backward compatible)

This is analogous to #1, except with `slice` instead of `range`.


#4. Slice inclusive/exclusive syntax (would require a __future__ in Python 3)

As opposed to forcing half-open intervals, a mix of round parentheses and 
square brackets could be allowed to be used for slices, analogously to #2. 
Since square brackets with a colon currently represent half-open intervals, 
this would have to require a __future__ import in Python 3. This could become 
the default in Python 4.

--
components: Interpreter Core
messages: 332403
nosy: Solomon Ucko, benjamin.peterson, brett.cannon, yselivanov
priority: normal
severity: normal
status: open
title: Improved range syntax
type: enhancement
versions: Python 3.8

___
Python tracker 

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



[issue35574] Coconut support

2018-12-23 Thread Solomon Ucko


New submission from Solomon Ucko :

Any chance we could integrate [Coconut](http://coconut-lang.org/) into Python? 
Any sain Python code should work with Coconut and Coconut allows making code 
*so* much more readable.

IMO, the reason not many people use Coconut is that they haven't heard of it 
and because of its lack of IDE support. (I would use it if it had more IDE 
support than just syntax highlighting.) The reason it has so little IDE support 
is that not many people use it. Making it a part of Python would alleviate 
these concerns.

--
messages: 332402
nosy: Solomon Ucko, benjamin.peterson, brett.cannon, yselivanov
priority: normal
severity: normal
status: open
title: Coconut support
type: enhancement
versions: Python 3.8

___
Python tracker 

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



[issue35573] is_HDN is returns false positive and false negative value for two test cases respectively

2018-12-23 Thread Divya Rani


Change by Divya Rani :


--
components: Library (Lib)
nosy: Divya Rani
priority: normal
severity: normal
status: open
title: is_HDN is returns false positive and false negative value for two test 
cases respectively
type: behavior
versions: Python 3.6

___
Python tracker 

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



[issue35121] Cookie domain check returns incorrect results

2018-12-23 Thread Ned Deily


Change by Ned Deily :


--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue35121] Cookie domain check returns incorrect results

2018-12-23 Thread Ned Deily


Change by Ned Deily :


--
keywords: +security_issue
priority: normal -> high

___
Python tracker 

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



[issue35572] Logging module cleanup

2018-12-23 Thread Ned Deily


Change by Ned Deily :


--
nosy: +vinay.sajip
versions:  -Python 2.7, 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



[issue35572] Logging module cleanup

2018-12-23 Thread Solomon Ucko


New submission from Solomon Ucko :

The logging module should be changed to use snake_case (as opposed to 
camelCase). Also, logger.basicConfig should list keyword arguments and defaults 
in the argument list, as opposed to using `**kwargs` and `dict.pop` (for 
readability and improved inspection capabilities). These should both be 
relatively easy changes to make. The case conversion should leave the camelCase 
versions as deprecated but left for backwards compatibility (as in the operator 
module).

--
components: Extension Modules
messages: 332401
nosy: Solomon Ucko
priority: normal
severity: normal
status: open
title: Logging module cleanup
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, 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



[issue30802] datetime.datetime.strptime('200722', '%Y%U')

2018-12-23 Thread Sergey Bon.


Sergey Bon.  added the comment:

Not following msg332388 would lead to this:


# Sunday of the week 53

>>> datetime.strptime ('2017 Sun 53', '%Y %a %U')
datetime.datetime(2017, 12, 31, 0, 0)


# First day of the week 53
# oops! assumed Monday is the first day of the week but 2017 ends on Sunday

>>> datetime.strptime ('2017 53', '%Y %U')
datetime.datetime(2018, 1, 1, 0, 0)

>>> datetime.strptime ('2017 Mon 53', '%Y %a %U')
datetime.datetime(2018, 1, 1, 0, 0)

--

___
Python tracker 

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



[issue30802] datetime.datetime.strptime('200722', '%Y%U')

2018-12-23 Thread Sergey Bon.


Sergey Bon.  added the comment:

Documentation says:

%U - Week number of the year (Sunday as the first day of the week)
%W - Week number of the year (Monday as the first day of the week)

It wouldn't be intuitive if %U assumed Sunday when weekday provided and Monday 
otherwise. There are two separate directives specifically to distinguish these 
two cases, so which day of the week is the first one should be determined on 
the used directive:

>>> datetime.strptime ('2018 Mon 52', '%Y %a %W')
datetime.datetime(2018, 12, 24, 0, 0)

>>> datetime.strptime ('2018 52', '%Y %W')
datetime.datetime(2018, 12, 24, 0, 0)

>>> datetime.strptime ('2018 Sun 52', '%Y %a %U')
datetime.datetime(2018, 12, 30, 0, 0)

>>> datetime.strptime ('2018 52', '%Y %U')
datetime.datetime(2018, 12, 30, 0, 0)

--
nosy: +sergey-bon

___
Python tracker 

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



[issue35208] IDLE: Squeezed line count ignores wrapping before newline

2018-12-23 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

The specific bug being fixed here is that wrapped lines before newline are 
ignored because after 

if s[pos] == '\n':
linecount += 1
current_column = 0

this block

if current_column > 0:
lines, column = divmod(current_column - 1, linewidth)
linecount += lines
current_column = column + 1

has no effect.  The fix, in the PR, is to put the linecount increment in the \n 
block before resetting current_column.  (Since the column>0 block also has no 
net effect after \t, I removed it)

--
title: IDLE: Squeezed lines count ignores window width -> IDLE: Squeezed line 
count ignores wrapping before newline

___
Python tracker 

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



[issue35555] IDLE: Gray out Code Context on non-editor windows

2018-12-23 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Thank you.  The backport is PR 11300.

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



[issue24814] Idle: Disable menu items when not applicable

2018-12-23 Thread Cheryl Sabella


Cheryl Sabella  added the comment:

#3 - Show/Hide Code Context

--
dependencies: +IDLE: Gray out Code Context on non-editor windows
nosy: +cheryl.sabella
versions: +Python 3.7, Python 3.8 -Python 2.7, 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



[issue35555] IDLE: Gray out Code Context on non-editor windows

2018-12-23 Thread Terry J. Reedy


Change by Terry J. Reedy :


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



[issue35570] 2to3 creates code using deprecated imp module

2018-12-23 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

Seems this came up when the original version of fixer was added as noted in 
https://bugs.python.org/issue11797#msg206884 . Looking further this seems to be 
similar to https://bugs.python.org/issue21446 where it was fixed in 3.7 and 
master to use importlib.reload . Since 3.6 is having it's last bug fix release 
I am not sure of the backport. Adding benjamin.peterson to the issue .

--
nosy: +benjamin.peterson, xtreak

___
Python tracker 

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



[issue28108] Python configure fails to detect tzname on platforms that have it.

2018-12-23 Thread Alexey Izbyshev


Alexey Izbyshev  added the comment:

The resolution of this [1] glibc bug report effectively says that the use of 
global variables tzname, timezone and daylight is not supported by glibc unless 
a POSIX-style TZ setting is used (which is probably never in real world).

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23859

--
nosy: +izbyshev

___
Python tracker 

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



[issue35537] use os.posix_spawn in subprocess

2018-12-23 Thread Alexey Izbyshev


Alexey Izbyshev  added the comment:

> * cwd

posix_spawn_file_actions_addchdir_np() is scheduled for glibc 2.29 [1] and 
exists in Solaris [2] (though its suffix indicates that it's "non-portable" -- 
not in POSIX). POSIX also has a bug for this [7].

> * start_new_session

posix_spawnattr_setflags() supports POSIX_SPAWN_SETSID in musl [3] and glibc 
2.26 [4] and is scheduled to be added into POSIX. Solaris also has 
POSIX_SPAWN_SETSID_NP.

> * pass_fds: there is not API to mark a fd as inheritable (clear O_CLOEXEC 
> flag)

POSIX has a bug for this [5]. It's marked fixed, but the current POSIX docs 
doesn't reflect the changes. The idea is to make 
posix_spawn_file_actions_adddup2() clear O_CLOEXEC if the source and the 
destination are the same (unlike dup2(), which would do nothing). musl has 
already implemented the new behavior [6], but glibc hasn't.

Another alternative (also described in the POSIX bug report) is to remove 
O_CLOEXEC via a side-effect of posix_spawn_file_actions_adddup2() to a dummy 
descriptor and then dup2() it back again. This is not correct in general case 
-- record locks (fcntl(F_SETLK)) associated with the file referred to by the 
descriptor are released on the second dup2() -- but in our case those locks are 
not preserved for the new process anyway, so this is not a problem. I'm not 
aware of other correctness problems with this, but one needs to check for 
platforms where a file descriptor may have associated flags other than 
O_CLOEXEC (such flags would be cleared by dup2).

> For pipes like stdout=PIPE or stdout=fd, I didn't look yet how to implement 
> that properly

You'd need to reimplement the corresponding logic from _posixsubprocess. 
Basically, posix_spawn_file_actions_adddup2() and 
posix_spawn_file_actions_addclose() do the job, but you need to avoid corner 
cases regarding low fds (0, 1, 2) that might have been reused for pipes.

I don't know correct solutions for close_fds. It is already hard: it's 
implemented in async-safe way only for Linux now (and only if /proc is 
available) or if /proc is not available and the brute-force implementation is 
used.

And of course, in theory you could implement any of the above by a helper 
binary as you did for prlimit.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17405
[2] 
https://docs.oracle.com/cd/E88353_01/html/E37843/posix-spawn-file-actions-addchdir-np-3c.html
[3] 
https://git.musl-libc.org/cgit/musl/commit/?id=bb439bb17108b67f3df9c9af824d3a607b5b059d
[4] https://www.sourceware.org/ml/libc-alpha/2017-08/msg00010.html
[5] http://austingroupbugs.net/view.php?id=411
[6] 
https://git.musl-libc.org/cgit/musl/commit/?id=6fc6ca1a323bc0b6b9e9cdc8fa72221ae18fe206
[7] http://austingroupbugs.net/view.php?id=1208

--

___
Python tracker 

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



[issue35571] Parallel Timeout Class

2018-12-23 Thread Stefan Volz


New submission from Stefan Volz :

Hello, I'm currently writing my finals project using Python and needed a 
feature that threading.Timer could nearly but not quite fulfill:
Execute a function after given time *with arguments provided and have the timer 
resettable*. 

So I did it myself and today I had the idea that it may be a good addition to 
the standartlibrary. The class is attached, on the bottom is a small test.

--
components: Extension Modules
files: Timeout.py
messages: 332392
nosy: Stefan Volz
priority: normal
severity: normal
status: open
title: Parallel Timeout Class
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file48014/Timeout.py

___
Python tracker 

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



[issue35567] Convert membership test from dict-of-constants to a set

2018-12-23 Thread Raymond Hettinger


Change by Raymond Hettinger :


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



[issue35569] OSX: Enable IPV6_RECVPKTINFO

2018-12-23 Thread Ronald Oussoren


Ronald Oussoren  added the comment:

#include  in the macOS 10.14 SDK says:

/*
 * RFC 3542 define the following socket options in a manner incompatible
 * with RFC 2292:
 *   IPV6_PKTINFO
 *   IPV6_HOPLIMIT
 *   IPV6_NEXTHOP
 *   IPV6_HOPOPTS
 *   IPV6_DSTOPTS
 *   IPV6_RTHDR
 *
 * To use the new IPv6 Sockets options introduced by RFC 3542
 * the constant __APPLE_USE_RFC_3542 must be defined before
 * including 
 *
 * To use the old IPv6 Sockets options from RFC 2292
 * the constant __APPLE_USE_RFC_2292 must be defined before
 * including 
 *
 * Note that eventually RFC 3542 is going to be the
 * default and RFC 2292 will be obsolete.
 */

My conclusion from reading this: the name might suggest that this is an 
internal macro, but should be safe to use.

--
components: +macOS
nosy: +ned.deily, ronaldoussoren
stage:  -> needs patch
versions: +Python 3.8

___
Python tracker 

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



[issue35567] Convert membership test from dict-of-constants to a set

2018-12-23 Thread Cheryl Sabella


Change by Cheryl Sabella :


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

___
Python tracker 

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



[issue35570] 2to3 creates code using deprecated imp module

2018-12-23 Thread Hanno Boeck


New submission from Hanno Boeck :

2to3 (in python 3.6.6) will rewrite the reload function to use the imp module. 
However according to [1] "Deprecated since version 3.4: The imp package is 
pending deprecation in favor of importlib."
Also running the code with warnings enabled will show a deprecation warning.

Example, take this minimal script:

#!/usr/bin/python
import sys
reload(sys)

Running to 2to3 ends up with:
#!/usr/bin/python
import sys
import imp
imp.reload(sys)

$ PYTHONWARNINGS=d python3 foo.py
test.py:3: DeprecationWarning: the imp module is deprecated in favour of 
importlib; see the module's documentation for alternative uses
  import imp


[1] https://docs.python.org/3/library/imp.html

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 332390
nosy: hanno
priority: normal
severity: normal
status: open
title: 2to3 creates code using deprecated imp module
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



[issue35569] OSX: Enable IPV6_RECVPKTINFO

2018-12-23 Thread chrysn


New submission from chrysn :

Python builds on MacOS do not expose the IPV6_RECVPKTINFO flag specified in 
[RFC3842], which is required for UDP protocols that need control over their 
servers' sending ports like [CoAP].

While I don't own Apple hardware and thus can't test it, the [nginx] code 
indicates that this API is available on OSX and is just gated behind 
`-D__APPLE_USE_RFC_3542`. Searching the web for that define indicates that 
other interpreted langues and applications use the flag as well (PHP, Ruby; 
PowerDNS, nmap, libcoap).

Please consider enabling this on future releases of Python on OSX.

[RFC3542]: https://tools.ietf.org/html/rfc3542
[CoAP]: https://github.com/chrysn/aiocoap/issues/69
[nginx]: http://hg.nginx.org/nginx/rev/9fb994513776

--
components: IO
messages: 332389
nosy: chrysn
priority: normal
severity: normal
status: open
title: OSX: Enable IPV6_RECVPKTINFO
type: enhancement

___
Python tracker 

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



[issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in conf.py

2018-12-23 Thread jfbu


jfbu  added the comment:

sorry for previous message whose text mentioned the GitHub pull request number 
but this links to bpo issue of that number, of course completely unrelated

--
pull_requests: +10525

___
Python tracker 

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



[issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in conf.py

2018-12-23 Thread jfbu


Change by jfbu :


--
pull_requests:  -10524

___
Python tracker 

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



[issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in conf.py

2018-12-23 Thread jfbu


jfbu  added the comment:

GitHub PR #11290 has been merged into master

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

___
Python tracker 

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



[issue35208] IDLE: Squeezed lines count ignores window width

2018-12-23 Thread Tal Einat


Tal Einat  added the comment:

> Part of my thinking with the simple auto-squeeze formula, besides just 
> simplifying the code, it this.  Raymond claimed that squeezing slows down 
> printing.  If measurably true, one way to avoid a slow down would be to use a 
> simple heuristic formula to estimate the number of wrapped lines instead of 
> exactly counting.  This would be a separate issue, if needed.

After Raymond opened issue #35196, I checked and found several places where the 
auto-squeeze code was being inefficient.  There's a PR ready with those 
optimizations attached to that issue (GH-10454).

--

___
Python tracker 

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



[issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in conf.py

2018-12-23 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +mdk

___
Python tracker 

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



[issue32067] Deprecate accepting unrecognized braces in regular expressions

2018-12-23 Thread Serhiy Storchaka


Change by Serhiy Storchaka :


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