[issue23718] strptime() can produce invalid date with negative year day

[Tamás Bence Gedai]

Tamás Bence Gedai added the comment:

Actually there are already test cases, but they test for the wrong behaviour. 
The very same example is tested there, but the test gives the expected result, 
so tm_yday = -3. My implementation returns 362, which looks more reasonable. So 
currently with my patch the test fails.

See the tests here: 
https://github.com/python/cpython/blob/master/Lib/test/test_strptime.py#L523

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Mathieu Dupuy]

Mathieu Dupuy added the comment:

(OK, I said a stupidity:  datetime's strptime handle microseconds. But time's 
one doesn't)

--

___
Python tracker 

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

[issue20169] random module doc page has broken links

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +georg.brandl
priority: low -> normal
versions: +Python 3.6 -Python 3.4

___
Python tracker 

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

[issue26362] Approved API for creating a temporary file path

[Ben Finney]

Ben Finney added the comment:

An example::

import io
import tempfile
names = tempfile._get_candidate_names()

def test_frobnicates_configured_spungfile():
""" ‘foo’ should frobnicate the configured spungfile. """

fake_file_path = os.path.join(tempfile.gettempdir(), names.next())
fake_file = io.BytesIO("Lorem ipsum, dolor sit amet".encode("utf-8"))

patch_builtins_open(
when_accessing_path=fake_file_path,
provide_file=fake_file)

system_under_test.config.spungfile_path = fake_file_path
system_under_test.foo()
assert_correctly_frobnicated(fake_file)

With a supported standard library API for this – ‘tempfile.makepath’
for example – the generation of the filesystem path would change from
four separate function calls::

names = tempfile._get_candidate_names()
fake_file_path = os.path.join(tempfile.gettempdir(), names.next())

to a simple function call::

fake_file_path = tempfile.makepath()

and have the benefit of not reaching in to a private API.

--

___
Python tracker 

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

[issue26309] socketserver.BaseServer._handle_request_noblock() doesn't shutdown request if verify_request is False

[Martin Panter]

Martin Panter added the comment:

Yes this patch looks pretty good, thanks

--
title: socketserver.BaseServer._handle_request_noblock() don't shutdwon request 
if verify_request is False -> socketserver.BaseServer._handle_request_noblock() 
doesn't shutdown request if verify_request is False

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Mathieu Dupuy]

Mathieu Dupuy added the comment:

simpler version using a simpler, stricter regex

--
Added file: http://bugs.python.org/file41934/simplerfromisoformat.patch

___
Python tracker 

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

[issue26362] Approved API for creating a temporary file path

[Ben Finney]

Ben Finney added the comment:

It has been pointed out that `tempfile.mktemp` does in fact access the 
filesystem, to query whether the entry exists.

So this request would be best met by exposing a simple “get a new return value 
from the `tempfile._RandomNameSequence` instance” function.

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Mathieu Dupuy]

Mathieu Dupuy added the comment:

Oh my god you're right. Thanks there is the re.ASCII flag.

2016-02-16 15:07 GMT+10:30 Martin Panter :

>
> Martin Panter added the comment:
>
> The regular expression r"\d" matches any digit in Unicode I think, not
> just ASCII digits 0-9. Perhaps we should limit it to ASCII digits. Or is it
> intended to allow non-ASCII digits like in "२०१६-०२-१६ ०१:२१:१४"?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Martin Panter]

Martin Panter added the comment:

The regular expression r"\d" matches any digit in Unicode I think, not just 
ASCII digits 0-9. Perhaps we should limit it to ASCII digits. Or is it intended 
to allow non-ASCII digits like in "२०१६-०२-१६ ०१:२१:१४"?

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Mathieu Dupuy]

Mathieu Dupuy added the comment:

The real question is : should we accept whatever iso8601 format is common to be 
found on the internet, or just be able to consume back the string issued by 
isoformat. From that results the answers to the questions you're asking: don't 
accept single digits, neither second-less datetime, ...
I don't really mind what the answer is. I'm OK for a stricter acceptance. I 
would like to ask ourselves : does a simpler, stricter implementation fulfill 
people needs ? If it's OK for you, it's OK for me.

By taking the Django version, I deviated the bit from the author's original 
need which was just being able to parse back datetime isoformat. The 
limitations he raises for not using strptime are gone now (strptime understand 
timezone), but it still can't understand microseconds nor optional parts (T or 
space for separator, optional microseconds). Even for a much simpler, stricter 
implementation, I'd like to stick with regex.

I'll do a date & time version, I just wait that we fall agree on the whole 
datetime thing.

Wether we change to a simpler code or keep it this way, I can rewrite tests & 
docstring.

--

___
Python tracker 

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

[issue20169] random module doc page has broken links

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: rhettinger -> 

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Martin Panter]

Martin Panter added the comment:

It looks to me like you copied a lot of code, doc strings, tests, etc from 

 and . I wouldn’t call it 
trivial. There is a BSD license for Django. Or do we have to get the relevant 
authors to do the Python CLA thing?

The current patch seems to allow a timezone without a colon, or even without 
minutes (+1100 and +11 as well as the RFC’s +11:00). Is this needed? The colon 
was made optional in Django in ; 
the argument given for this just seems to be ISO 8601 alignment, nothing 
practical. According to  Postgre 
SQL outputs time zones without the minutes field, but I don’t know if Python 
should go out of its way to support this obscure format.

RFC 3339 does not specify single digits in many places (e.g. 2016-2-1 1:0:0 is 
not specified). Should we also be stricter, at least for the minutes and 
seconds fields?

Also, is it necessary to allow the seconds field to be omitted, as in 
"2016-02-01 01:21"?

It seems that the “datetime” module does not support leap seconds, so if we 
mention RFC 3339 we should point out this inconsistency.

Victor: From my limited experiments, datetime.fromtimestamp() seems to use the 
round-to-even rule (not always rounding half up). Can you confirm? Maybe we 
should use that for consistency if it is practical. Otherwise, truncation 
towards zero would be the simplest.

As well as adding datetime.fromisoformat(), I think we should add similar 
methods to the separate date and time classes. One can parse the RFC’s 
full-date format fairly easily with strptime(), but not so for partial-time 
because of the fractional seconds.

--

___
Python tracker 

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

[issue22062] Fix pathlib.Path.(r)glob doc glitches.

[Mike Short]

Changes by Mike Short :


Added file: http://bugs.python.org/file41933/pathlib.py.patch

___
Python tracker 

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

[issue22062] Fix pathlib.Path.(r)glob doc glitches.

[Mike Short]

Changes by Mike Short :


--
keywords: +patch
Added file: http://bugs.python.org/file41932/pathlib.patch

___
Python tracker 

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

[issue26368] grammatical error in asyncio stream documentation

[Ned Deily]

Ned Deily added the comment:

Thanks for the report, Ryan!

--
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
title: grammatical error in documentation -> grammatical error in asyncio 
stream documentation
versions:  -Python 3.4

___
Python tracker 

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

[issue26368] grammatical error in documentation

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8ee91cb2e2a4 by Ned Deily in branch '3.5':
Issue #26368: fix typo in asynchio stream doc, reported by Ryan Stuart.
https://hg.python.org/cpython/rev/8ee91cb2e2a4

New changeset 12502327d2c0 by Ned Deily in branch 'default':
Issue #26368: fix typo in asynchio stream doc, reported by Ryan Stuart.
https://hg.python.org/cpython/rev/12502327d2c0

--
nosy: +python-dev

___
Python tracker 

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

[issue26368] grammatical error in documentation

[Ryan Stuart]

New submission from Ryan Stuart:

The note for 18.5.5.1. Stream functions is missing a word. It should read "Note 
The top-level functions in this module are meant **as** convenience wrappers 
only; there’s really nothing special there, and if they don’t do exactly what 
you want, feel free to copy their code."

--
assignee: docs@python
components: Documentation
files: asyncio-stream_docs.patch
keywords: patch
messages: 260339
nosy: Ryan Stuart, docs@python
priority: normal
severity: normal
status: open
title: grammatical error in documentation
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41931/asyncio-stream_docs.patch

___
Python tracker 

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

[issue26367] importlib.__import__ does not fail for invalid relative import

[Manuel Jacob]

New submission from Manuel Jacob:

Python 3.6.0a0 (default:6c6f7dff597b, Feb 16 2016, 01:24:51) 
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib
>>> importlib.__import__('array', globals(), locals(), level=1)

>>> __import__('array', globals(), locals(), level=1)
Traceback (most recent call last):
  File "", line 1, in 
ImportError: attempted relative import with no known parent package

Instead of failing, importlib.__import__ returns a module with a wrong name.  
This happens with both built-in modules and pure python modules.  However it 
fails when replacing 'array' with 'time' (this seems to be related to whether 
the module is in Modules/Setup.dist).

--
messages: 260338
nosy: brett.cannon, eric.snow, mjacob, ncoghlan
priority: normal
severity: normal
status: open
title: importlib.__import__ does not fail for invalid relative import
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Mathieu Dupuy]

Mathieu Dupuy added the comment:

> I suggest to parse directly the string with C code, since the format looks 
> quite simple (numbers and a few separators).

But some of them are optional. And I would really like to mimic the same 
implementation logic in C.

Now I think the python version is fairly ready. What next ?

--

___
Python tracker 

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

[issue25738] http.server doesn't handle RESET CONTENT status correctly

[Mathieu Dupuy]

Mathieu Dupuy added the comment:

I was looking at this issue, and actually the problem is on a different level.
The function the patch takes place is "send_errror". As its name suggests, it's 
only used to send error (I checked in the code : it's only used to send 4XX/5XX 
reply). I'm sure none of this reply forbid to carry a body.
So I think the whole "if code >= 200 and code >= 200 and   code 
not in (code not in (HTTPStatus.NO_CONTENT, HTTPStatus.NOT_MODIFIED)):" should 
just be replaced by a assert 400 <= code < 600.

And more seriously : who could be using this code for a modern real world usage 
? Why not delete it ? Isn't it harmful that unwarned might use it ?

--
nosy: +deronnax

___
Python tracker 

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

[issue20169] random module doc page has broken links

[Ori Avtalion]

Changes by Ori Avtalion :


--
nosy: +salty-horse

___
Python tracker 

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

[issue26354] re.I does not work as expected

[Magesh Kumar]

Magesh Kumar added the comment:

Thanks Matthew. :-)

--

___
Python tracker 

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

[issue26359] CPython build options for out-of-the box performance

[SilentGhost]

Changes by SilentGhost :


--
nosy: +haypo

___
Python tracker 

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

[issue26354] re.I does not work as expected

[Matthew Barnett]

Matthew Barnett added the comment:

The 3rd argument is the count (the maximum number of replacements, although 0 
means no limit, not no replacements). You're passing in the flag re.I instead. 
re.I happens to have the numeric value 2, so you're telling it to do no more 
than 2 replacements.

--

___
Python tracker 

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

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Martin Panter]

Martin Panter added the comment:

If you changed existing versionadded notices to versionchanged in similar 
cases, how would the size of the patch compare? This problem was also recently 
brought up at 
.

My weak opinion is that a new parameter is a new API item, not just a change in 
behaviour, so should probably have “versionadded”. But I hardly think it is a 
big problem whichever markup is used.

--
nosy: +martin.panter

___
Python tracker 

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

[issue26224] Add "version added" for documentation of asyncio.timeout for documentation of python 3.4, 3.5, 3.6

[Martin Panter]

Changes by Martin Panter :


--
stage:  -> patch review

___
Python tracker 

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

[issue14597] Cannot unload dll in ctypes until script exits

[Mark Mikofski]

Mark Mikofski added the comment:

I think I have this issue even after interpreter exits. My setup.py creates a 
.dll then later loads the dll for testing using ctypes. Subsequent runs of 
setup.py that would force rebuilding the .dll attempt to delete the old dll 
first if it exists, but I get permission denied.

Oddly, if I put the load library call inside a function, then, after exiting 
the interpreter the dll can be deleted.

Windos 7 x64
Python 2.7.10

Sorry if this is by design, a Windows feature, unrelated or the wrong issue. I 
search SO and these bugs, and only found answers related to unloading dll 
during script.

--
nosy: +bwanamarko

___
Python tracker 

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

[issue26354] re.I does not work as expected

[Magesh Kumar]

Magesh Kumar added the comment:

Corrected Message :


If we compare the first example () and the  example, I am using 
re.I as the third element. But for the  example, still I am able to get 
the substitution happening correctly.

Could you pls, let me know the reason of change in behaviour.

--

___
Python tracker 

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

[issue26354] re.I does not work as expected

[Magesh Kumar]

Magesh Kumar added the comment:

:-)
Thanks a lot Matthew for the inputs.

If we compare the first example () and the  example, I am using 
re.I as the third element. But for the  example, still I am not to get 
the substitution happening correctly.

Could you pls, let me know the reason of change in behaviour.

--

___
Python tracker 

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

[issue26354] re.I does not work as expected

[Matthew Barnett]

Matthew Barnett added the comment:

The pattern '\', which is the same as '', matches the string 
'', and that is replaced with ''.

--

___
Python tracker 

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

[issue26354] re.I does not work as expected

[Magesh Kumar]

Magesh Kumar added the comment:

Thanks for the inputs, It would be of great help, if someone could help me in 
explaining the below output :

>>> a 
'ype="str">falseDefaultMulticastClient>> b = re.sub('\', '', a, re.I)
>>> b
'ype="str">falseDefaultMulticastClient

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

[issue26357] asyncio.wait loses coroutine return value

[Yury Selivanov]

Yury Selivanov added the comment:

TBH I never ever needed to do membership tests on (done, failed) result of 
asyncio.wait.  If you need to do such tests - just wrap your coroutines into 
tasks manually.  I honestly don't understand what's the problem and why we need 
to change anything in asyncio or in Python.  There're tons of code on asyncio 
now, and this is only a second time someone wants to "fix" await.

Fixing #25887 allows us to enable multiple awaits on coroutines later, but I 
wouldn't rush that in 3.5 or 3.6.

Restricting asyncio.wait to accept only futures will also cause a lot of pain.  
I'd just fix the docs with an explanation of this problem and with a snippet of 
code showing how to do membership tests if needed.  Alternatively, we can add a 
wrapper for asyncio.wait (wait_futures?), that will only accept futures/tasks.

--

___
Python tracker 

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

[issue21145] Add the @cached_property decorator

[STINNER Victor]

STINNER Victor added the comment:

"Most implementations these days support TTL because they require it."

I used this pattern a lot in my old Hachoir project, but I never needed the TTL 
thing. In my case, data come from the disk and are never invalidated.

Example with the description property:

https://bitbucket.org/haypo/hachoir3/src/9ae394a18d74bb20b5562964e57074e5624132f5/hachoir/field/field.py?at=default=file-view-default#field.py-79

--

___
Python tracker 

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

[issue26357] asyncio.wait loses coroutine return value

[André Caron]

André Caron added the comment:

Hi Guido,

Thanks for the quick reply :-)

AFAICT, there seem to be three possible directions regarding this issue -- for 
both wait() and as_completed():

1) remove the need for ensure_future(): make the membership test succeed and 
allow multiple await expressions on the same coroutine;

2) fail fast: reject coroutine objects as inputs to wait() and reject multiple 
await expressions on coroutine objects (see issue #25887);

3) clarify API usage: deprecate couroutine objects and enhance docs for wait(), 
as_completed() and ensure_future().

>From a pure API standpoint, #1 makes the API more uniform and less surprising, 
>#2 makes it easier to detect and fix incorrect usage and #3 accelerates 
>troubleshooting when people get bitten by this quirk in the API.

You're right that technically, the case of side-effect-only coroutine 
invocations is a use case that's currently supported by wait() and that 
removing this (e.g. by adopting #2) would be a compatibility break.  I 
personally doubt that this is a common use case as both wait() and 
as_completed() seem specifically designed to recover the results, but I'm not 
an asyncio expert either.

Asyncio is still young and is undergoing adoption, so I would like to see this 
issue resolved without resorting to #3.

Any chance #1 or #2 can be considered?

--

___
Python tracker 

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

[issue21145] Add the @cached_property decorator

[Antoine Pitrou]

Antoine Pitrou added the comment:

I'm sure many people don't need a TTL on a cached property. Please stop arguing 
about that.

--

___
Python tracker 

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

[issue21145] Add the @cached_property decorator

[Omer Katz]

Omer Katz added the comment:

In that case, most of the users won't use the standard library
@cached_property anyway since they require it.

On Mon, Feb 15, 2016, 19:51 Antoine Pitrou  wrote:

>
> Antoine Pitrou added the comment:
>
> The TTL idea is completely outlandish in a general-purpose library. Let's
> keep things simple and not try to build a kitchen-sink decorator.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue21145] Add the @cached_property decorator

[Antoine Pitrou]

Antoine Pitrou added the comment:

The TTL idea is completely outlandish in a general-purpose library. Let's keep 
things simple and not try to build a kitchen-sink decorator.

--

___
Python tracker 

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

[issue21145] Add the @cached_property decorator

[Omer Katz]

Omer Katz added the comment:

Most implementations these days support TTL because they require it.
The whole point is to remove the need to reimplement such basic
functionality over and over.

‫בתאריך יום ב׳, 15 בפבר׳ 2016 ב-18:33 מאת ‪STINNER Victor‬‏ <‪
rep...@bugs.python.org‬‏>:‬

>
> STINNER Victor added the comment:
>
> I like the idea of an helper to build a property on-demand, but I dislike
> the TTL idea, it seems too specific.
>
> If you need TTL, implement your own decorator, or use a regular property
> and implement your own logic there.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Georg Brandl]

Georg Brandl added the comment:

The devguide should be updated, yes.

And probably someone should look at the remaining versionadded's...

--

___
Python tracker 

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

[issue21145] Add the @cached_property decorator

[STINNER Victor]

STINNER Victor added the comment:

I like the idea of an helper to build a property on-demand, but I dislike the 
TTL idea, it seems too specific.

If you need TTL, implement your own decorator, or use a regular property and 
implement your own logic there.

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[STINNER Victor]

STINNER Victor added the comment:

> No regex available at all in CPython?

It's not really convenient to use the re module in C.

> Otherwise, yeah, if I have to, I can do it with strptime.

I suggest to parse directly the string with C code, since the format looks 
quite simple (numbers and a few separators).

--

___
Python tracker 

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

[issue26309] socketserver.BaseServer._handle_request_noblock() don't shutdwon request if verify_request is False

[Aviv Palivoda]

Aviv Palivoda added the comment:

I changed the test to just check that shutdown_request is called. Hope this is 
more clear then the previous test.

--
Added file: 
http://bugs.python.org/file41930/socketserver-shutdown-if-verify-false4.patch

___
Python tracker 

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

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Ezio Melotti]

Ezio Melotti added the comment:

I agree with Georg.
I also went to double-check what the devguide says, and at 
https://docs.python.org/devguide/documenting.html#paragraph-level-markup it 
shows an example of versionadded for a parameter.
If a versionchanged should be used instead, maybe the devguide should be fixed.

Having versionadded/changed used consistently would also be nice though, 
especially if we can start exploiting them (together with 
deprecated/deprecated-removed) to auto-generate sections of the whatsnew page.

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue26364] pip uses colour in messages that does not work on white terminals

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the report, but this needs to be reported to the pip issue tracker: 
https://github.com/pypa/pip/issues

For the record, I found a similar report at 
https://github.com/pypa/pip/issues/2449

--
nosy: +berker.peksag
resolution:  -> third party
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

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Georg Brandl]

Georg Brandl added the comment:

Hi Tony,

thanks for the patch, and for the will to contribute.  I'm not sure this patch 
should be merged though; the original intention was to use "versionadded" where 
the API item is completely new.  So "The parameter x was added" in a function 
is using "versionchanged" because only an aspect of the function's signature 
was changed.

There may be a bit of confusion because many people wrote changes, and not 
every change is reviewed by the same developers, but this is the original 
intent that I think we should not change wholesale.

--
nosy: +georg.brandl

___
Python tracker 

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

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Tony R.]

New submission from Tony R.:

In the documentation, I noticed several uses of ``.. versionchanged::`` that 
described things which had been added.  

I love Python, and its documentation, and I wanted to contribute.  So, I 
figured a low-risk contribution would be to change ``.. versionchanged::`` to 
“.. versionadded” where appropriate.  (I also tweaked the descriptions 
accordingly.  E.g., “Added the *x* argument” became “The *x* argument”, because 
it’s unnecessary to say “added” in a description under “.. versionadded”.)

I did also make a few unrelated tweaks along the way--all very minor, and 
related to phrasing or formatting. 

Please let me know if I can do anything else to get this merged!

--
assignee: docs@python
components: Documentation
files: _docs-version-markup.patch
keywords: patch
messages: 260313
nosy: Tony R., docs@python
priority: normal
severity: normal
status: open
title: Use “.. versionadded” over “.. versionchanged” where appropriate
type: enhancement
Added file: http://bugs.python.org/file41929/_docs-version-markup.patch

___
Python tracker 

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

[issue21145] Add the @cached_property decorator

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

May be. If somebody provide a patch.

--

___
Python tracker 

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

[issue26365] ntpath.py Error in Windows

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The first argument of os.path.join() (as well as all other) in Python 2.7 must 
be str or unicode. You pass a tuple.

--
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue26365] ntpath.py Error in Windows

[Ben Kummer]

New submission from Ben Kummer:

ntpath.py throws an error in Python2.7.11 Windows

Code snippet:
product_dir ="/zope/eggs43"
my_tuple= os.path.split(product_dir)[:-1]
roduct_prefix = os.path.join(my_tuple )

The same code works in python 2.7.11 under Linux

Traceback:
C:\zope\selenium_test>c:\Python27\python.exe python_bug_reproduce.py
Traceback (most recent call last):
  File "python_bug_reproduce.py", line 10, in 
main()
  File "python_bug_reproduce.py", line 7, in main
product_prefix = os.path.join(my_tuple )
  File "c:\Python27\lib\ntpath.py", line 90, in join
return result_drive + result_path
TypeError: cannot concatenate 'str' and 'tuple' objects


code to reproduce:

#!/usr/bin/python
import os

def main():
product_dir ="/zope/eggs43"
my_tuple= os.path.split(product_dir)[:-1]
product_prefix = os.path.join(my_tuple )

if __name__ == "__main__":
main()

--
components: Windows
files: python_bug_reproduce.py
messages: 260310
nosy: ben.kummer, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ntpath.py Error in Windows
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41928/python_bug_reproduce.py

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Mathieu Dupuy]

Mathieu Dupuy added the comment:

> Hum, you should use the same rounding method than
datetime.datetime.fromtimestamp(): ROUND_HALF_UP, as round().
In practice, you can for example pass a floating point number as
microseconds to datetime.datetime constructor.

Unfortunately, you're mistaking with the timedelta constructor. Datetime's one 
only take int :(
But I figured out an elegant manner to cope with (in my opinion)

> Since datetime is implemented in C, I'm not sure that using the re is
the best choice. Since the regex looks simple enough, we may parse the
string without the re module. Well, maybe only for the C
implementation.

No regex available at all in CPython ? Otherwise, yeah, if I have to, I can do 
it with strptime.

> What is the behaviour is there are spaces before/after the string?
What if there are other characters like letters before/after? You
should add an unit test for that. I expect an error when parsing
"t=2012-04-23T09:15:00" for example.
Your regex ends with $ but doesn't start with ^. Using re.match(), ^
and $ are probably not needed, but I'm not confident when I use regex
:-)

re.match only look at the beginning of the string, so no need for '^'. And 
therefore, the case
you mention is already handled :)

joined to this mail the last revision of the feature, with correct rounding, 
more test and one useless
line removed. Maybe the good one :) ?

--
Added file: http://bugs.python.org/file41927/fromisoformat4.patch

___
Python tracker 

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

[issue21145] Add the @cached_property decorator

[Omer Katz]

Omer Katz added the comment:

Can we make this happen for 3.6?

--
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue26364] pip uses colour in messages that does not work on white terminals

[Barry Scott]

New submission from Barry Scott:

pip3 (3.5 on Mac OS X) is outputting a message in yellow that I can barely see 
on a white background terminal.

"You are using pip version 7.1.2, however version 8.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command."

I suggest that pip only uses text output. But if the pip developers insist on 
using colour then set both foreground and background colours.

--
messages: 260307
nosy: barry.scott
priority: normal
severity: normal
status: open
title: pip uses colour in messages that does not work on white terminals
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue26363] __builtins__ propagation is misleading described in exec and eval documentation

[Julien]

Changes by Julien :


--
nosy: +sizeof

___
Python tracker 

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

[issue26363] __builtins__ propagation is misleading described in exec and eval documentation

[Xavier Combelle]

New submission from Xavier Combelle:

According to my experiment in code, the current behavior of python3.5 is 
different that the document says. If I understand well the purpose of this 
behavior is to propagate the __builtins__ global constant if globals has not 
one.

In
https://docs.python.org/3.6/library/functions.html#eval

it is written  "If the globals dictionary is present and lacks ‘__builtins__’, 
the current globals are copied into globals before expression is parsed." only 
the __builtins__ looks copied not all the globals


In
https://docs.python.org/3.6/library/functions.html#exec
It is written:
"If the globals dictionary does not contain a value for the key __builtins__, a 
reference to the dictionary of the built-in module builtins is inserted under 
that key." it looks like it is not a reference to the built-in module builtin, 
but a reference to __builtin__ global

--
title: builtins propagation is misleading described in exec and eval 
documentation -> __builtins__ propagation is misleading described in exec and 
eval documentation
versions: +Python 3.5

___
Python tracker 

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

[issue26039] More flexibility in zipfile interface

[Thomas Kluyver]

Thomas Kluyver added the comment:

Hi Serhiy, any more comments on the zf.open() patch?

--

___
Python tracker 

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

[issue26363] builtins propagation is misleading described in exec and eval documentation

[Xavier Combelle]

Changes by Xavier Combelle :


--
assignee: docs@python
components: Documentation
nosy: docs@python, xcombelle
priority: normal
severity: normal
status: open
title: builtins propagation is misleading described in exec and eval 
documentation

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[STINNER Victor]

STINNER Victor added the comment:

> How does it parse this date:
> 2016-02-15T11:59:46.16588638674+09:00

Mathieu Dupuy added the comment:
> discarding the microseconds digits after the 6th.

Hum, you should use the same rounding method than
datetime.datetime.fromtimestamp(): ROUND_HALF_UP, as round().

In practice, you can for example pass a floating point number as
microseconds to datetime.datetime constructor.

Since datetime is implemented in C, I'm not sure that using the re is
the best choice. Since the regex looks simple enough, we may parse the
string without the re module. Well, maybe only for the C
implementation.

What is the behaviour is there are spaces before/after the string?
What if there are other characters like letters before/after? You
should add an unit test for that. I expect an error when parsing
"t=2012-04-23T09:15:00" for example.

Your regex ends with $ but doesn't start with ^. Using re.match(), ^
and $ are probably not needed, but I'm not confident when I use regex
:-)

--

___
Python tracker 

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

[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator

[Michel Desmoulin]

Michel Desmoulin added the comment:

We fixed our bug days ago, but I would have expected [*gen] to have triggered 
an exception before it even got to gather().

The real code was something like:

>>> l = (ensure_awaitable(callable_obj) for callable_obj in callable_list)
>>> gather(*l)

ensure_awaitable() is just using inspect to turn coroutine functions into 
coroutines, and wraps non coroutine callables with 
asyncio.coroutine(callable)().

In the end, ensure_awaitable did raise TypeError if the argument passed was not 
a callable.

--

___
Python tracker 

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