Barry A. Warsaw added the comment:
I agree. It should also be pointed out that we've had inconsistencies between
the module attributes and the spec attributes, and even fixing those has lead
to problems. There should be a single source of truth, and the module spec
should be that.
+1
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue33301>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue29319>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue1>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Not that I've thought this through in much detail, but what if we start out by
proxying those module attributes to the spec via PEP 562 hooks? We can do that
in 3.8, issue (silent?) deprecation warnings, and then do a full deprecation
process for
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue32387>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue33465>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
It seems pretty easy to use an extension module that's less likely to be
built-in. What about binascii?
--
___
Python tracker
<https://bugs.python.org/is
Change by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +6482
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33465>
___
___
Py
Barry A. Warsaw added the comment:
binascii gets built-in too, so it seems like _hashlib is a good choice.
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue33499>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
New changeset 8709b236fc997077d24b4802320db287640f82e2 by Barry Warsaw in
branch 'master':
bpo-33465: Use an unlikely to be built-in C extension in a test (#6797)
https://github.com/python/cpython/commit/8709b236fc997077d24b4802320db2
Barry A. Warsaw added the comment:
New changeset 2cdb70ac5df30db021417ab71a327d9b4322de13 by Barry Warsaw (Miss
Islington (bot)) in branch '3.7':
bpo-33465: Use an unlikely to be built-in C extension in a test (GH-6797)
(#6869)
https://github.com/python/cpyt
Change by Barry A. Warsaw :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31574>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I like the idea of a gen 4 that never gets collected. This would have been
useful for the original problem that inspired me to add the `generation`
argument to `gc.collect()`. The nice thing about this, is just as you suggest:
you could force a collection
New submission from Barry A. Warsaw:
It's a very common pattern to see the following at module scope:
cre_a = re.compile('some pattern')
cre_b = re.compile('other pattern')
and so on. This can cost you at start up time because all those regular
expressions are comp
Changes by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +3742
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31580>
___
___
Py
Barry A. Warsaw added the comment:
Let's separate the use of lru_cache from the deferred compilation. I think
I'll just revert the change to use lru_cache, although I'll note that the
impetus for this was the observation that once MAXCACHE is reached the entire
regexp cache i
Barry A. Warsaw added the comment:
On Sep 26, 2017, at 11:27, R. David Murray wrote:
>
> Precompiling as a compile-time optimization would be cool. I think we are
> currently favoring doing that kind of thing as an AST optimization step?
I was thinking about that too.
> I think
Barry A. Warsaw added the comment:
I'm closing this experiment.
I'm not convinced that even if we can make start up time faster for module
global regular expressions, we'll ever get enough buy-in from the ecosystem to
make this worth it, because you'd really want to get a
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31642>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31650>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31660>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
PEP is accepted. PR needs review.
--
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31353>
___
_
Barry A. Warsaw added the comment:
I think using re.ASCII is a good addition since RFC 2047 says:
Generally, an "encoded-word" is a sequence of printable ASCII
characters that begins with "=?", ends with "?=", and has two "?"s in
between. It s
Barry A. Warsaw added the comment:
Technically it *is* an API change since `flags` is a part of the public API.
The documentation says:
$identifier names a substitution placeholder matching a mapping key of
"identifier". By default, "identifier" is re
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31671>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31669>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
PEPs aren't really intended to be ongoing specs, keeping up with implementation
changes. The documentation is pretty clear in defining identifiers as "any
case-insensitive ASCII alphanumeric string (including underscores) that starts
with an und
Barry A. Warsaw added the comment:
On Oct 4, 2017, at 02:29, INADA Naoki wrote:
>
> INADA Naoki added the comment:
>
>> Yet one way -- make re.ASCII a local flag. Than we could just change the
>> idpattern attribute to r'(?a:[_a-z][_a-z0-9]*)', without t
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31690>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Oct 3, 2017, at 23:51, INADA Naoki wrote:
>> It's better to keep the re.IGNORECASE since the RFC also says:
>>
>> Both 'encoding' and 'charset' names are case-independent. Thus the
>> charset name &q
Barry A. Warsaw added the comment:
On Oct 4, 2017, at 10:05, Serhiy Storchaka wrote:
>
> See issue31690. But this solution can be used only in 3.7.
That’s fine. I don’t think this is important enough to backport.
--
___
Python tracker
Change by Barry A. Warsaw :
--
title: Add documentation for METH_FASTCALL -> Add documentation for
METH_FASTCALL and _PyObject_FastCall*()
___
Python tracker
<https://bugs.python.org/issu
Barry A. Warsaw added the comment:
This and the _PyObject_FastCall* APIs really do need to be documented,
especially if they're going to be used in the interpreter itself. The leading
underscore signifies that it's not part of the public API (well, METH_FASTCALL
doesn't
New submission from Barry A. Warsaw :
I already added a section to the C API docs for some useful macros. I didn't
know about this one when I did that, but it seems like a useful macro to
document, so I will do that.
--
assignee: barry
components: Documentation
messages: 303707
Change by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +3864
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31693>
___
___
Py
Change by Barry A. Warsaw :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Barry A. Warsaw :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
> -export-dynamic -o python \
> Modules/python.o \
> -L. -lpython2.7 -lpthread -ldl -lutil -lm
The CONFIG_ARGS variable should always be set, so I assume that
your _sysconfigdata.py was generated in a previous broken bui
Barry A. Warsaw added the comment:
On Oct 6, 2017, at 15:04, Serhiy Storchaka wrote:
> Serhiy Storchaka added the comment:
>
> Another solution (works in 3.6 too): set idpattern to
> r'(?-i:[_a-zA-Z][_a-zA-Z0-9]*)'.
>
> This looks pretty weird, setting the
Barry A. Warsaw added the comment:
With some comments to clarify of course.
--
___
Python tracker
<https://bugs.python.org/issue31672>
___
___
Python-bugs-list m
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31756>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Barry A. Warsaw :
__spec__ is defined in PEP 451. If you search for "__spec__" in the docs, you
get a number of hits.
https://docs.python.org/3/search.html?q=__spec__&check_keywords=yes&area=default
Click on the first link:
https://docs.python.org/3/ref
Change by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +3984
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31799>
___
___
Py
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue25711>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I've landed here after chatting with @brett.cannon. I have a use case for this
(making pex startup faster by bypassing pkg_resources) but I need to hack
around the limitation of dlopen'ing .so's from zips. Our idea was to have a
zipimport
Barry A. Warsaw added the comment:
New changeset 191e3138200906e43cba9347177914325b54843f by Barry Warsaw in
branch 'master':
bpo-31799: Make module.__spec__ more discoverable (#4010)
https://github.com/python/cpython/commit/191e3138200906e43cba9347177914
Barry A. Warsaw added the comment:
New changeset 858ea4354fafa36e57859d2dfd70f8a057984075 by Barry Warsaw (Miss
Islington (bot)) in branch '3.6':
[3.6] bpo-31799: Make module.__spec__ more discoverable (GH-4010) (#4021)
https://github.com/python/cpyt
Change by Barry A. Warsaw :
--
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.4, Python 3.5
___
Python tracker
<https://bugs.python.org/i
Change by Barry A. Warsaw :
--
pull_requests: +3998
___
Python tracker
<https://bugs.python.org/issue25711>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I've ported the patch to a branch on GH. See PR 4023. I started from
zipimport-2.patch. It doesn't work, but it will be easier to work on as a PR
rather than a patch.
Contributions welcome! Let's see if we can
Change by Barry A. Warsaw :
--
pull_requests: +4205
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue31415>
___
___
Python-
Barry A. Warsaw added the comment:
I like this a lot and while the issue is still open, I'm piggybacking my PR
4240 on this one.
I have a use case for enabling this feature via environment variable, so PR
4240 adds PYTHONPROFILEIMPORTTIME which also enables this feature.
We build our
Barry A. Warsaw added the comment:
This is defined behavior, not a bug. See the end of the section on string
literals:
https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
--
nosy: +barry
resolution: -> not a bug
stage: -> resolved
status
Barry A. Warsaw added the comment:
New changeset 700d2e4755921d6c339ff20dacecde1aea64de34 by Barry Warsaw in
branch 'master':
bpo-31415: Support PYTHONPROFILEIMPORTTIME envvar equivalent to -X importtime
(#4240)
https://github.com/python/cpyt
Barry A. Warsaw added the comment:
On Nov 2, 2017, at 22:50, INADA Naoki wrote:
>
> When adding environment variable option, it should be documented in
> man page and `python -h`.
I thought about that, but the problem is that none of the -X options are
documented in the —help outpu
Change by Barry A. Warsaw :
--
nosy: +barry
versions: +Python 3.7 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue31936>
___
___
Python-bugs-list m
Change by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +4219
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31936>
___
___
Py
Barry A. Warsaw added the comment:
Re-reading the paragraph now, it also parsed weirdly for me. See the linked PR
for a suggested improvement, along with your change.
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue31
Barry A. Warsaw added the comment:
On Nov 3, 2017, at 11:05, Serhiy Storchaka wrote:
>
> But now, after adding the environment variable, do we still need the -X
> option? From a user side I don't see much difference between specifying an
> option and an environment varia
Barry A. Warsaw added the comment:
New changeset 93952f881500053057c2e08c4b253ac61233d7db by Barry Warsaw in
branch 'master':
Fix a grammatical problem and reword for clarity. (#4257)
https://github.com/python/cpython/commit/93952f881500053057c2e08c4b253a
Change by Barry A. Warsaw :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Barry A. Warsaw added the comment:
-1 until we have something we can call a "mifflin".
(Kidding of course!)
--
nosy: +barry
___
Python tracker
<https://bugs.python.o
Barry A. Warsaw added the comment:
On Nov 3, 2017, at 14:41, Serhiy Storchaka wrote:
>
> Note that with environment variable you get more information.
Fun!
--
___
Python tracker
<https://bugs.python.org/i
Barry A. Warsaw added the comment:
On Nov 3, 2017, at 14:23, Terry J. Reedy wrote:
>
> Does it set the EV for the entire session (which one likely would not want),
> or just the one command (which has no Windows equivalent that I know of)?
> Please leave the easily remember
Barry A. Warsaw added the comment:
Okay, given the non-propagation and Windows issues. I'm -1 on removing -X, +1
on fixing the negative cache.
--
___
Python tracker
<https://bugs.python.org/is
Barry A. Warsaw added the comment:
On Nov 4, 2017, at 14:29, Terry J. Reedy wrote:
> The importtime output is sent to stderr. Should this be documented?
Yes. :)
--
___
Python tracker
<https://bugs.python.org/issu
New submission from Barry A. Warsaw :
Issue bpo-26182 added DeprecationWarnings for "import async" and "import await"
since both of those pseudo-keywords were to become actual reserved keywords in
Python 3.7. This latter has now happened, but the fix in bpo-26182 is
inco
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31975>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31984>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I think there is nothing left to do for this issue, so I'm closing it.
--
status: open -> closed
___
Python tracker
<https://bugs.python.org
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue32030>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Barry A. Warsaw :
timeit is cool, but it's not appropriate for all performance testing. For
example, since it uses only a single Python process, anything that's cached is
not a good candidate for timeit profiling. The classic example is timing
imports. E.g.
Barry A. Warsaw added the comment:
On Nov 15, 2017, at 17:00, Serhiy Storchaka wrote:
>
> +1 to all said by Raymond. But this is rather the matter of a special article
> or blog post than a note in the documentation.
Maybe a HOWTO on performance testing and analysis? We already ha
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue32043>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue32088>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
pull_requests: +4420
___
Python tracker
<https://bugs.python.org/issue31672>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
@inada.naoki - I think changing this to ?a will make things more clear. I
submitted a PR for that, and then once it lands, we can close this issue.
--
___
Python tracker
<https://bugs.python.org/issue31
Barry A. Warsaw added the comment:
Yeah, I find it pretty common to set both stdout and stderr to PIPE, but I'm
with you in hesitating to add YAO to the subprocess API. If you do move
forward with this though, I think capture_output would have to be mutually
exclusive to stdout and s
Barry A. Warsaw added the comment:
New changeset e256b408889eba867e1d90e5e1a0904843256255 by Barry Warsaw in
branch 'master':
bpo-31672 - Add one last minor clarification for idpattern (#4483)
https://github.com/python/cpython/commit/e256b408889eba867e1d90e5e1a090
Change by Barry A. Warsaw :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Barry A. Warsaw :
The check_node() function in test_uuid.py uses the wrong bitmask, causing the
tests to fail on valid MAC addresses. Also, the description in the comment is
incorrect. From my reading of the wikipedia page, the test is trying to ensure
that the MAC
Change by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +4431
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32107>
___
___
Py
Barry A. Warsaw added the comment:
Pure chance I believe. It all depends on the MAC address of the machines the
test runs on (which is perhaps an unacceptable environmental variability in the
test suite, and should be fixed/mocked?).
FWIW, I saw the failures on my 2017 MacBook Pro, where
Barry A. Warsaw added the comment:
Yikes. It's entirely possible that these tests are tainted by environmental
leakage. I was looking into why Travis fails on my PR:
https://travis-ci.org/python/cpython/jobs/305433725
and stepping through _ifconfig_getnode() on my Mac. The &qu
Barry A. Warsaw added the comment:
On Nov 21, 2017, at 15:47, Serhiy Storchaka wrote:
> If your fix is correct (and it looks correct to me), we should fix not only
> the test, but, first of all, the _*_getnode functions. Perhaps they should
> ignore locally administered MAC addr
On 22.11.2017 08:40, Serhiy Storchaka wrote:
> Usually the read() method of a file-like object takes one optional argument
> which limits the amount of data (the number of bytes or characters) returned
> if specified.
>
> codecs.StreamReader.read() also has such parameter.
Barry A. Warsaw added the comment:
On Nov 23, 2017, at 11:24, Serhiy Storchaka wrote:
> Wait, now I understand the purpose of the current test! There is just a typo
> in a comment, should be 41 instead of 47. The test itself is correct. If the
> address is obtained from network
Barry A. Warsaw added the comment:
On Nov 26, 2017, at 12:40, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> If I understand correctly, the original problem was that tests failed in some
> environments, right? In that case we should either change the
Barry A. Warsaw added the comment:
On Nov 26, 2017, at 14:07, Serhiy Storchaka wrote:
>
> Universally/locally administered MAC addresses doesn't have relation to this
> issue. My assumption was about the multicast bit (1<<40).
AFAICT, the multicast bit is only required
Change by Barry A. Warsaw :
--
pull_requests: +4504
___
Python tracker
<https://bugs.python.org/issue32107>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
PR #4576 includes all related changes.
--
___
Python tracker
<https://bugs.python.org/issue32107>
___
___
Python-bugs-list m
Barry A. Warsaw added the comment:
On Nov 27, 2017, at 01:24, Serhiy Storchaka wrote:
>
> 3. Makes methods for getting the address of the real network card preferring
> universally administered addresses and falling back to locally administered
> address only if universally
Barry A. Warsaw added the comment:
New changeset 9522a218f7dff95c490ff359cc60e8c2af35f5c8 by Barry Warsaw in
branch 'master':
bpo-32107 - Better merge of #4494 (#4576)
https://github.com/python/cpython/commit/9522a218f7dff95c490ff359cc60e8
Barry A. Warsaw added the comment:
On Nov 27, 2017, at 15:18, Serhiy Storchaka wrote:
>
> My apologies for my dim comment and my obliviousness that leaded to spending
> your time on trying to fix a wrong issue.
No worries at all. Thanks for working with me to make the fix as g
Change by Barry A. Warsaw :
--
pull_requests: +4514
___
Python tracker
<https://bugs.python.org/issue32107>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
pull_requests: +4515
___
Python tracker
<https://bugs.python.org/issue32107>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Nov 27, 2017, at 16:08, Serhiy Storchaka wrote:
>
> We shouldn't check the 42nd bit in maintenance releases. This check will fail
> on some computers.
Oh, without the preferential return of the universally administered MAC, you’re
right.
1301 - 1400 of 2560 matches
Mail list logo