Re: [Python-Dev] PEP 565: show DeprecationWarning in __main__ (round 2)

25.11.17 07:33, Nick Coghlan пише: * ``FutureWarning``: always reported by default. The intended audience is users of applications written in Python, rather than other Python developers (e.g. warning about use of a deprecated setting in a configuration file format). Given its presence

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

24.11.17 00:20, Greg Ewing пише: Serhiy Storchaka wrote: Ivan explained that this function should be rough equivalent to    def f():    t = [(yield i) for i in range(3)]    return (x for x in t) This seems useless to me. It turns a lazy iterator into an eager one, which is a gross

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

24.11.17 02:50, Nick Coghlan пише: If we went down that path, then a list comprehension like the following:     results = [(yield future) for future in list_of_futures] might be compiled as being equivalent to:     def __listcomp_generator(iterable):     result = []     for future

Re: [Python-Dev] Python initialization and embedded Python

24.11.17 04:21, Glenn Linderman пише: On 11/23/2017 5:31 PM, Nick Coghlan wrote: - a consolidated list of *all* the APIs that can safely be called before Py_Initialize So it is interesting to know that list, of course, but the ones that are to be supported and documented might be a smaller

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

23.11.17 18:08, Guido van Rossum пише: This thread is still going over the speed limit. Don't commit anything without my explicit approval. I'm not going to write a single line of code while the decision about this issue is not made. This is not easy issue. A problem with dropping the

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

23.11.17 16:30, Paul Moore пише: Ok, cool. My main point still applies though - has anyone confirmed why a function scope was considered necessary at the time of the original implementation, but it's apparently not now? I'm pretty sure it was a deliberate choice, not an accident. The

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

23.11.17 14:30, Antoine Pitrou пише: On Thu, 23 Nov 2017 14:17:32 +0200 Serhiy Storchaka <storch...@gmail.com> wrote: I used the "yield" statement, but I never used the "yield" expressions. And I can't found examples. Could you please present a real-world use case f

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

23.11.17 13:49, Antoine Pitrou пише: I'm still in favour of deprecating and then disallowing. We could disallow it without deprecation. The current behavior definitely is wrong, nobody should depend on it. It should be either fixed or disallowed. Nobody seems to have presented a

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

22.11.17 17:10, Ivan Levkivskyi пише: - fix yield in comprehensions I'm working on this. I was going to inline the generating function a long time ago for small performance benefit, but the benefit looked too small for complicating the compiler code. Now I have other reason for doing this.

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

22.11.17 15:25, Ivan Levkivskyi пише: I think this is indeed a problem.. For me the biggest surprise was that `yield` inside a comprehension does not turn a surrounding function into comprehension, see also

[Python-Dev] Tricky way of of creating a generator via a comprehension expression

From https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions. g = [(yield i) for i in range(3)] Syntactically this looks like a list comprehension, and g should be a list, right? But actually it is a generator. This code is equivalent to the

Re: [Python-Dev] Comment on PEP 562 (Module __getattr__ and __dir__)

20.11.17 03:02, Guido van Rossum пише: Serhiy's definition sounds recursive (defining __getattr__ to define the behavior of __getattr__) but Mark's suggestion makes his intention unclear since the error message is still the same. It is recursive only when the '__dict__' attribute is not

Re: [Python-Dev] Comment on PEP 562 (Module __getattr__ and __dir__)

19.11.17 22:24, Mark Shannon пише: Just one comment. Could the new behaviour of attribute lookup on a module be spelled out more explicitly please? I'm guessing it is now something like: `module.__getattribute__` is now equivalent to: def __getattribute__(mod, name):     try:    

Re: [Python-Dev] Make the stable API-ABI usable

19.11.17 12:59, Antoine Pitrou пише: On Sun, 19 Nov 2017 00:18:28 +0100 Victor Stinner <victor.stin...@gmail.com> wrote: Le 18 nov. 2017 10:44, "Serhiy Storchaka" <storch...@gmail.com> a écrit : The simplest way to do this: #define PyTuple_GET_ITEM PyTuple_GetItem This

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

13.11.17 01:34, Nick Coghlan пише: On 13 November 2017 at 03:10, Serhiy Storchaka <storch...@gmail.com> wrote: 12.11.17 11:24, Nick Coghlan пише: The PEP also proposes repurposing the existing FutureWarning category to explicitly mean "backwards compatibility warnings that shou

Re: [Python-Dev] Python initialization and embedded Python

19.11.17 04:17, Nick Coghlan пише: 1. Breaking calling Py_DecodeLocale() before calling Py_Initialize() is a compatibility break with the API implied by our own usage examples, and we'll need to revert the breakage for 3.7, and ensure at least one release's worth of DeprecationWarning before

Re: [Python-Dev] Python initialization and embedded Python

18.11.17 16:17, Nick Coghlan пише: On 18 November 2017 at 10:01, Victor Stinner wrote: I'm writing this email to ask if this change is an issue or not to embedded Python and the Python C API. Is it still possible to call "all" functions of the C API before calling

Re: [Python-Dev] Make the stable API-ABI usable

18.11.17 11:13, Victor Stinner пише: The idea behind adding PyTuple_GET_ITEM() is to be able to compile C extensions using it, without having to modify the code. The simplest way to do this: #define PyTuple_GET_ITEM PyTuple_GetItem This will not add new names to ABI. Such defines can be

Re: [Python-Dev] Show DeprecationWarning in debug mode?

18.11.17 03:22, Victor Stinner пише: I noticed that Python not only hides DeprecationWarning, but also PendingDeprecationWarning and ImportWarning by default. While I understand why we decided to hide these warnings to users for a Python compiled in release mode, why are they hidden in Python

Re: [Python-Dev] Make the stable API-ABI usable

18.11.17 03:05, Victor Stinner пише: tl; dr I propose to extend the existing "stable API" to make it almost as complete as the current API. For example, add back PyTuple_GET_ITEM() to be stable API, but it becomes a function call rather than a macro. The final question is if it's not too late to

Re: [Python-Dev] Python initialization and embedded Python

18.11.17 02:01, Victor Stinner пише: Many global variables used by the "Python runtime" were move to a new single "_PyRuntime" variable (big structure made of sub-structures). See Include/internal/pystate.h. A side effect of moving variables from random files into header files is that it's not

Re: [Python-Dev] PEP 562

15.11.17 12:53, Ivan Levkivskyi пише: On 15 November 2017 at 08:43, Serhiy Storchaka <storch...@gmail.com <mailto:storch...@gmail.com>> wrote: It is worth to mention that using name as a module global will bypass __getattr__. And this is intentional, otherwise calling

Re: [Python-Dev] PEP 562

14.11.17 22:34, Ivan Levkivskyi пише: This function will be called only if ``name`` is not found in the module through the normal attribute lookup. It is worth to mention that using name as a module global will bypass __getattr__. And this is intentional, otherwise calling __getattr__ for

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

13.11.17 18:40, Antoine Pitrou пише: On Mon, 13 Nov 2017 17:08:06 +0100 Victor Stinner wrote: In short: python3.7 -X dev script.py behaves as: PYTHONMALLOC=debug python3.7 -Wd -b -X faulthandler script.py I would personally not add `-b` in those options. I

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

13.11.17 14:29, Antoine Pitrou пише: On Mon, 13 Nov 2017 22:37:46 +1100 Chris Angelico wrote: On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou wrote: On Sun, 12 Nov 2017 19:48:28 -0800 Nathaniel Smith wrote: On Sun, Nov 12, 2017 at 1:24

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

12.11.17 03:47, Guido van Rossum пише: - In Python 3 code, using `\u` escapes in a b'...' literal gives "DeprecationWarning: invalid escape sequence '\u'" In both cases these warnings are currently only generated if you run mypy with these warnings enabled, e.g. `python3 -Wd -m mypy `. But

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

13.11.17 05:48, Nathaniel Smith пише: On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote: This change will lead to DeprecationWarning being displayed by default for: * code executed directly at the interactive prompt * code executed directly as part of a single-file

Re: [Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

13.11.17 02:00, Guido van Rossum пише: It's hard to keep those two in sync, since the actual Grammar file is constrained by being strictly LL(1)... Can you get someone else to review the implementation? I haven't change the grammar, just have changed checks in the CST to AST transformer.

Re: [Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

12.11.17 18:57, Guido van Rossum пише: Sounds good to me. Thanks! Here is an implementation: https://bugs.python.org/issue32012. I have found that formally trailing comma after generator expression is not allowed by the grammar defined in the language reference: call: `primary` "("

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

12.11.17 11:24, Nick Coghlan пише: The PEP also proposes repurposing the existing FutureWarning category to explicitly mean "backwards compatibility warnings that should be shown to users of Python applications" since: - we don't tend to use FutureWarning for its original nominal purpose

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

12.11.17 12:06, Nick Coghlan пише: So if folks would like dict unpacking syntax, then a suitable place to start would be a proposal for a "getitems" builtin that allowed operations like: b, a = getitems(d, ("b", "a")) operator.itemgetter and operator.attrgetter may provide some

[Python-Dev] Disallow ambiguous syntax f(x for x in [1],)

Initially generator expressions always had to be written inside parentheses, as documented in PEP 289 [1]. The additional parenthesis could be omitted on calls with only one argument, because in this case the generator expression already is written inside parentheses. You could write just

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

09.11.17 14:22, Raymond Hettinger пише: Stylistically, all of these seem awkward and I think there is more to it than just the name. I'm not sure it is wise to pass complex inputs into a two-argument macro that makes an assignment and has a conditional refcount side-effect. Even now, one of

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

09.11.17 04:08, Raymond Hettinger пише: On Nov 8, 2017, at 8:30 AM, Serhiy Storchaka <storch...@gmail.com> wrote: Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all maintained versions ([1] and [2]). Despite their names they are private. I

Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

08.11.17 18:37, Victor Stinner пише: I like these macros! Technically, would it be possible to use an inline function instead of a macro for Python 3.7? No, unless there is a way to pass arguments by reference in C99. Py_SETREF(x, y) is the safe equivalent of x = y; Py_DECREF(x,

[Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all maintained versions ([1] and [2]). Despite their names they are private. I think that they are enough stable now and would be helpful in third-party code. Are there any objections against adding them to the stable C

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

08.11.17 04:33, Nick Coghlan пише: On 8 November 2017 at 11:44, Nick Coghlan wrote: 2. So far, I haven't actually come up with a perturbed iteration implementation that doesn't segfault the interpreter. The dict internals are nicely laid out to be iteration friendly, but

Re: [Python-Dev] The current dict is not an "OrderedDict"

07.11.17 16:56, Steven D'Aprano пише: To clarify: if we start with an empty dict, add keys A...D, delete B, then add E...H, we could expect: {A: 1} {A: 1, B: 2} {A: 1, B: 2, C: 3} {A: 1, B: 2, C: 3, D: 4} {D: 4, A: 1, C: 3} # some arbitrary reordering {D: 4, A: 1, C: 3, E: 5} {D: 4, A: 1, C:

Re: [Python-Dev] Partial support of a platform

06.11.17 19:41, Victor Stinner пише: Example of platforms: MinGW, Cygwin, OpenBSD, NetBSD, xWorks RTOS, etc. But the way, is there an exhaustive list of platforms "officially" supported by CPython? Several month ago there was a couple of buildbots including NetBSD and OpenBSD. What happened

Re: [Python-Dev] Partial support of a platform

06.11.17 23:24, Antoine Pitrou пише: On Mon, 6 Nov 2017 18:41:30 +0100 Victor Stinner wrote: Example of platforms: MinGW, Cygwin, OpenBSD, NetBSD, xWorks RTOS, etc. We support POSIX-compatible platforms. Do OpenBSD and NetBSD need special care? Yes, because our

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

06.11.17 21:56, Paul Sokolovsky пише: Btw, in all this discussion, I don't remember anyone mentioning sets. I don't recall the way they're implemented in CPython, but they have strong conceptual and semantic resemblance to dict's. So, what about them, do they become ordered too? No, sets are

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

06.11.17 09:09, Guido van Rossum пише: I still find this unfriendly to users of Python scripts and small apps who are not the developers of those scripts. (Large apps tend to spit out so much logging it doesn't really matter.) Isn't there a better heuristic we can come up with so that the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

06.11.17 05:01, INADA Naoki пише: FYI, Raymond's original compact dict (moving last item to slot used for deleted item) will break OrderedDict. So it's not easy to implement than it looks. OrderedDict uses linked list to keep which slot is used for the key. Moving last item will break it. It

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

06.11.17 04:05, Nick Coghlan пише: On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both mistakenly though the async/await deprecation warnings were missing from 3.6. They weren't missing, we'd just both forgotten those warnings were off by default (7 years after the change to the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

05.11.17 21:30, Stefan Krah пише: On Sun, Nov 05, 2017 at 09:09:37PM +0200, Serhiy Storchaka wrote: 05.11.17 20:39, Stefan Krah пише: On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote: 2. Someone invents a new arbitrary-ordered container that would improve on the memory and/or CPU

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

05.11.17 21:20, Stefan Krah пише: On Sun, Nov 05, 2017 at 09:01:40PM +0200, Serhiy Storchaka wrote: Do you suggest to make dictionary displays producing OrderedDict instead of dict? No, this is essentially a language spec doc issue that would guarantee the ordering properties of the current

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

05.11.17 20:39, Stefan Krah пише: On Sun, Nov 05, 2017 at 01:14:54PM -0500, Paul G wrote: 2. Someone invents a new arbitrary-ordered container that would improve on the memory and/or CPU performance of the current dict implementation I would think this is very unlikely, given that the

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

04.11.17 19:30, Stefan Krah пише: would it be possible to guarantee that dict literals are ordered in v3.7? The issue is well-known and the workarounds are tedious, example: https://mail.python.org/pipermail/python-ideas/2015-December/037423.html If the feature is guaranteed now, people

[Python-Dev] Remove typing from the stdlib (was: Reminder: 12 weeks to 3.7 feature code cutoff)

03.11.17 16:36, Guido van Rossum пише: > Maybe we should remove typing from the stdlib? > https://github.com/python/typing/issues/495 I didn't use typing, but AFAIK the most used feature from typing is NamedTuple. If move NamedTuple and maybe other convenient classes not directly related to

Re: [Python-Dev] Reorganizing re and curses related code

03.11.17 12:29, Nick Coghlan пише: On 3 November 2017 at 20:01, Serhiy Storchaka <storch...@gmail.com> wrote: Since virtually all changes in these files at recent years have been made by me, I don't think this will harm other core developers. Are there any objections? Sound fine

[Python-Dev] Reorganizing re and curses related code

Currently the implementation of re and curses related modules is sparsed over several files: re: Lib/re.py Lib/sre_compile.py Lib/sre_constants.py Lib/sre_parse.py _sre: Modules/_sre.c Modules/sre_constants.h Modules/sre.h Modules/sre_lib.h _curses:

[Python-Dev] The syntax of replacement fields in format strings

According to the specification of format string syntax [1] (I meant str.format(), not f-strings), both argument name and attribute name must be Python identifiers. But the current implementation is more lenient and allow arbitrary sequences of characters while they don't contain '.', '[',

Re: [Python-Dev] The type of the result of the copy() method

29.10.17 19:04, Guido van Rossum пише: It's somewhat problematic. If I subclass dict with a different constructor, but I don't overload copy(), how can the dict.copy() method construct a correct instance of the subclass? Even if the constructor signatures match, how can dict.copy() make sure

Re: [Python-Dev] Migrate python-dev to Mailman 3?

26.10.17 12:24, Victor Stinner пише: We are using Mailman 3 for the new buildbot-status mailing list and it works well: https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/ I prefer to read archives with this UI, it's simpler to follow threads, and it's possible to reply on

[Python-Dev] The type of the result of the copy() method

The copy() methods of list, dict, bytearray, set, frozenset, WeakValueDictionary, WeakKeyDictionary return an instance of the base type containing the content of the original collection. The copy() methods of deque, defaultdict, OrderedDict, Counter, ChainMap, UserDict, UserList, WeakSet,

Re: [Python-Dev] \G (match last position) regex operator non-existant in python?

27.10.17 18:35, Guido van Rossum пише: The "why" question is not very interesting -- it probably wasn't in PCRE and nobody was familiar with it when we moved off PCRE (maybe it wasn't even in Perl at the time -- it was ~15 years ago). I didn't understand your description of \G so I googled it

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

04.10.17 21:06, Barry Warsaw пише: Victor brings up a good question in his review of the PEP 553 implementation. https://github.com/python/cpython/pull/3355 https://bugs.python.org/issue31353 The question is whether $PYTHONBREAKPOINT should be ignored if -E is given? I think it makes sense

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

26.09.17 23:47, Guido van Rossum пише: I've read the current version of PEP 552 over and I think everything looks good for acceptance. I believe there are no outstanding objections (or they have been adequately addressed in responses). Therefore I intend to accept PEP 552 this Friday, unless

Re: [Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)

03.10.17 18:15, Guido van Rossum пише: It's really not that hard. You just check the magic number and if it's the new one, skip 4 words. No need to understand the internals of the header. Hence you should know all old magic numbers to determine if the read magic number is the new one. Right?

Re: [Python-Dev] Make re.compile faster

03.10.17 17:21, Barry Warsaw пише: What if the compiler could recognize constant arguments to re.compile() and do the regex compilation at that point? You’d need a way to represent the precompiled regex in the bytecode, and it would technically be a semantic change since regex problems would

Re: [Python-Dev] Make re.compile faster

03.10.17 06:29, INADA Naoki пише: More optimization can be done with implementing sre_parse and sre_compile in C. But I have no time for it in this year. And please don't do this! This would make maintaining the re module hard. The performance of the compiler is less important than

Re: [Python-Dev] Make re.compile faster

03.10.17 06:29, INADA Naoki пише: Before deferring re.compile, can we make it faster? I profiled `import string` and small optimization can make it 2x faster! (but it's not backward compatible) Please open an issue for this. I found: * RegexFlag.__and__ and __new__ is called very often. *

Re: [Python-Dev] Python startup optimization: script vs. service

02.10.17 16:26, Victor Stinner пише: While "import module" is fast, maybe we should use sometimes a global variable to cache the import. module = None def func(): global module if module is None: import module ... I optimized "import module", and I think it can be optimized even

Re: [Python-Dev] bpo-30806 netrc.__repr__() is broken for writing to file (GH-2491)

30.09.17 10:10, INADA Naoki пише: https://github.com/python/cpython/commit/b24cd055ecb3eea9a15405a6ca72dafc739e6531 commit: b24cd055ecb3eea9a15405a6ca72dafc739e6531 branch: master author: James Sexton committer: INADA Naoki date:

Re: [Python-Dev] API design question: how to extend sys.settrace()?

27.09.17 15:56, Victor Stinner пише: In bpo-29400, it was proposed to add the ability to trace not only function calls but also instructions at the bytecode level. I like the idea, but I don't see how to extend sys.settrace() to add a new "trace_instructions: bool" optional (keyword-only?)

Re: [Python-Dev] To reduce Python "application" startup time

05.09.17 16:02, INADA Naoki пише: While I can't attend to sprint, I saw etherpad and I found Neil Schemenauer and Eric Snow will work on startup time. I want to share my current knowledge about startup time. For bare (e.g. `python -c pass`) startup time, I'm waiting C implementation of ABC.

Re: [Python-Dev] Why aren't decorators just expressions?

16.09.17 12:39, Larry Hastings пише: So why don't decorators allow arbitrary expressions?  The PEP discusses the syntax for decorators, but that whole debate only concerned itself with where the decorator goes relative to "def", and what funny punctuation might it use.  It never says

Re: [Python-Dev] PEP 559 - built-in noop()

09.09.17 21:46, Barry Warsaw пише: One use case would be for PEP 553, where you could set the breakpoint environment variable to the following in order to effectively disable it:: $ setenv PYTHONBREAKPOINT=noop Are there other use cases? PEP 553 still is not approved, and you could use

Re: [Python-Dev] PEP 548: More Flexible Loop Control

06.09.17 03:11, R. David Murray пише: I've written a PEP proposing a small enhancement to the Python loop control statements. Short version: here's what feels to me like a Pythonic way to spell "repeat until": while: break if The PEP goes into some detail on why this

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

05.09.17 11:38, INADA Naoki пише: ## Cons * All Python 3.7 implementations should provide _collections.OrderedDict PyPy has it already. But I don't know about micropython. Current C implementation of OrderedDict is not safe regarding using mutating dict methods (or dict C API) like

Re: [Python-Dev] bpo-5001: More-informative multiprocessing error messages (#3079)

30.08.17 01:52, Antoine Pitrou пише: https://github.com/python/cpython/commit/bd73e72b4a9f019be514954b1d40e64dc3a5e81c commit: bd73e72b4a9f019be514954b1d40e64dc3a5e81c branch: master author: Allen W. Smith, Ph.D committer: Antoine Pitrou

Re: [Python-Dev] Need help to fix urllib(.parse) vulnerabilities

21.07.17 13:02, Victor Stinner пише: Recently, two security vulnerabilities were reported in the urllib module: https://bugs.python.org/issue30500 http://python-security.readthedocs.io/vuln/bpo-30500_urllib_connects_to_a_wrong_host.html#bpo-30500-urllib-connects-to-a-wrong-host => already fixed

Re: [Python-Dev] Impact of Namedtuple on startup time

17.07.17 15:43, Antoine Pitrou пише: Cost of creating a namedtuple has been identified as a contributor to Python startup time. Not only Python core and the stdlib, but any third-party library creating namedtuple classes (there are many of them). An issue was created for this:

Re: [Python-Dev] Summary of Python tracker Issues

23.06.17 19:09, Python tracker пише: ACTIVITY SUMMARY (2017-06-16 - 2017-06-23) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6026 ( -8) Terry closed a

Re: [Python-Dev] Summary of Python tracker Issues

30.06.17 19:09, Python tracker пише: ACTIVITY SUMMARY (2017-06-23 - 2017-06-30) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6006 (-20) Victor closed a

Re: [Python-Dev] New work-in-progress bisection tool for the Python test suite (in regrtest)

26.06.17 23:37, Victor Stinner пише: 2017-06-26 21:58 GMT+02:00 Brett Cannon : I don't see why regrtest isn't the right place for this. The current regrest CLI isn't designed for subcommands, and I don't want to "pollute" regrtest with multiple options for bisect. Currently,

Re: [Python-Dev] __qualname__ format question

25.06.17 15:06, Christian Tismer пише: by chance, I stumbled over meth_get__qualname__ in methodobject.c and calculate_qualname in descrobject.c . The first uses res = PyUnicode_FromFormat("%S.%s", type_qualname, m->m_ml->ml_name); and the latter uses res =

Re: [Python-Dev] New workflow change: Welcome to blurb

24.06.17 18:57, Larry Hastings пише: On 06/24/2017 01:53 AM, Antoine Pitrou wrote: Would you like to make it 3.5-compatible? 3.6 is quite young and not all systems have it (e.g. Ubuntu 16.04, which many people use, has 3.5). Well, tbh I think that's a bit silly. First of all, it shouldn't

Re: [Python-Dev] New workflow change: Welcome to blurb

25.06.17 06:04, Nick Coghlan пише: On 25 June 2017 at 11:56, Terry Reedy wrote: On 6/24/2017 7:48 PM, Brett Cannon wrote: I should also mention that after Larry blows up Misc/NEWS into individual files in about a week I will add a check to Bedevere for a news file unless the

Re: [Python-Dev] New workflow change: Welcome to blurb

25.06.17 04:51, Nick Coghlan пише: So count me in as a +1 for standardising on a model where: - client-side core-workflow tools are free to use features from the latest released version of Python - we expect core devs to set up a venv or conda env to run those tools if their system Python is

Re: [Python-Dev] New workflow change: Welcome to blurb

24.06.17 18:57, Larry Hastings пише: On 06/24/2017 01:53 AM, Antoine Pitrou wrote: Would you like to make it 3.5-compatible? 3.6 is quite young and not all systems have it (e.g. Ubuntu 16.04, which many people use, has 3.5). Well, tbh I think that's a bit silly. First of all, it shouldn't

Re: [Python-Dev] New workflow change: Welcome to blurb

24.06.17 11:53, Antoine Pitrou пише: On Fri, 23 Jun 2017 20:24:05 -0700 Larry Hastings wrote: We've been talking about addressing this for years. Fixing this was one of the goals of the new workflow. And finally, as of right now, the future is here. Ladies and

Re: [Python-Dev] [python-committers] New workflow change: Welcome to blurb

2017-06-24 6:24 GMT+03:00 Larry Hastings : > One minor but ongoing problem we've had in CPython core development has been > the mess of updating Misc/NEWS. Day-to-day developers may have a conflict > if they lose a push race, which means a little editing. You'll have a >

Re: [Python-Dev] Issue #21071: change struct.Struct.format type from bytes to str

27.03.17 15:12, Victor Stinner пише: I would like to change struct.Struct.format type from bytes to str. I don't expect that anyone uses this attribute, and struct.Struct() constructor accepts both bytes and str. http://bugs.python.org/issue21071 It's just to be convenient: more functions

[Python-Dev] Handle errors in cleanup code

There is an idiomatic Python code: do_something() try: do_something_other() except: undo_something() raise If an error is raised when execute do_something_other(), then we should first restore the state that was before calling do_something(), and then

Re: [Python-Dev] PEP 7 and braces { .... } on if

03.06.17 23:30, Barry Warsaw пише: On Jun 03, 2017, at 07:25 PM, Serhiy Storchaka wrote: But the latter example continuation lines are intended at the same level as the following block of code. I propose to make exception for that case and allow moving an open brace to the start of the next

Re: [Python-Dev] PEP 7 and braces { .... } on if

Yet about braces. PEP 7 implicitly forbids breaking the line before an opening brace. An opening brace should stay at the end the line of the outer compound statement. if (mro != NULL) { ... } else { ... } if (type->tp_dictoffset != 0 && base->tp_dictoffset

Re: [Python-Dev] Extremely slow test modules

03.06.17 16:01, Antoine Pitrou пише: On Sat, 3 Jun 2017 15:28:18 +0300 Serhiy Storchaka <storch...@gmail.com> wrote: test_tools (in particular the test for the unparse.py script), test_tokenize, and test_lib2to3 read and proceed every Python file in the stdlib. This is necessary in ful

Re: [Python-Dev] Extremely slow test modules

03.06.17 13:31, Antoine Pitrou пише: Is there a reason some of our tests are excruciatingly slow in `-uall` mode? `test_multiprocessing_spawn` is understandable (after all, it will spawn a new executable for each subprocess), but other tests leave me baffled: - test_tools: 7 min 41 sec -

Re: [Python-Dev] "Global freepool"

01.06.17 21:44, Larry Hastings пише: p.s. Speaking of freelists, at one point Serhiy had a patch adding a freelist for single- and I think two-digit ints. Right now the only int creation optimization we have is the array of constant "small ints"; if the int you're constructing isn't one of

Re: [Python-Dev] "Global freepool"

01.06.17 12:20, Victor Stinner пише: 2017-06-01 10:40 GMT+02:00 Antoine Pitrou : This is already exactly how PyObject_Malloc() works. (...) Oh ok, good to know... IMHO the main thing the private freelists have is that they're *private* precisely, so they can avoid a

Re: [Python-Dev] PEP 7 and braces { .... } on if

01.06.17 09:36, Benjamin Peterson пише: Modern GCC can defend against these kinds of problems. If I introduce a "goto fail" bug somewhere in Python, I get a nice warning: ../Objects/abstract.c: In function ‘PyObject_Type’: ../Objects/abstract.c:35:5: warning: this ‘if’ clause does not guard...

Re: [Python-Dev] PEP 7 and braces { .... } on if

31.05.17 20:27, Guido van Rossum пише: I interpret the PEP as saying that you should use braces everywhere but not to add them in code that you're not modifying otherwise. (I.e. don't go on a brace-adding rampage.) If author and reviewer of a PR disagree I would go with "add braces" since

Re: [Python-Dev] Put token information in one place

31.05.17 20:58, Brett Cannon пише: I assume there's a build rule for Python/graminit.c and porting pgen to Python would require Python be installed to do a build from scratch. Have we made that a requirement yet? If so then rewriting pgen in Python would make it easier to maintain (although

Re: [Python-Dev] PEP 7 and braces { .... } on if

31.05.17 17:11, Victor Stinner пише: I have a question on the CPython coding code for C code, the PEP 7: https://www.python.org/dev/peps/pep-0007/ """ Code structure: (...); braces are strongly preferred but may be omitted where C permits, and they should be formatted as shown: if (mro !=

[Python-Dev] Put token information in one place

Currently when you add a new token you need to change a couple of files: * Include/token.h * _PyParser_TokenNames in Parser/tokenizer.c * PyToken_OneChar(), PyToken_TwoChars() or PyToken_ThreeChars() in Parser/tokenizer.c * Lib/token.py (generated from Include/token.h) * EXACT_TOKEN_TYPES in

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

30.05.17 18:38, Guido van Rossum пише: On Mon, May 29, 2017 at 11:16 PM, Serhiy Storchaka <storch...@gmail.com <mailto:storch...@gmail.com>> wrote: 30.05.17 09:06, Greg Ewing пише: Steven D'Aprano wrote: What does "tp" stand for? Type something

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

30.05.17 09:06, Greg Ewing пише: Steven D'Aprano wrote: What does "tp" stand for? Type something, I guess. I think it's just short for "type". There's an old tradition in C of giving member names a short prefix reminiscent of the type they belong to. Not sure why, maybe someone thought it

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

29.05.17 17:15, Serhiy Storchaka пише: 29.05.17 15:13, Antoine Pitrou пише: I hope readers won't get bothered by what is mostly a link to blogpost (well, two of them :-)), but I suspect there at least 2 or 3 people who might be interested in the following analysis: https://www.corsix.org

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

29.05.17 15:13, Antoine Pitrou пише: I hope readers won't get bothered by what is mostly a link to blogpost (well, two of them :-)), but I suspect there at least 2 or 3 people who might be interested in the following analysis:

<    1   2   3   4   5   6   7   8   9   10   >