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

Hi, 2017-12-12 21:21 GMT+01:00 Guido van Rossum : > I'm still hoping to accept this PEP, but I don't have time to wrap my head > around -Xdev ("devmode"?) which appears to be Victor's latest pet project. > Should PEP 565 be changed to copy with devmode's behavior, or the other way > around, or sho

Re: [Python-Dev] PEP 567 -- Context Variables

Hi Yury, I like the overall idea and I prefer this PEP over PEP 550 since it's shorter and easier to read :-) Question: Is there an API to list all context variables? Would it be possible to have a very summary of the changes in the PEP? I propose: """ * Added contextvars module with ContextVar

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

2017-12-13 0:24 GMT+01:00 Guido van Rossum : > Considered disagreement is acceptable. Sure, I'm fine with that ;-) > Nick, congrats with PEP 565! Please update the PEP to mark it as approved > with a link to this message as the resolution, and let's get the > implementation into 3.7a4! Nick wrot

Re: [Python-Dev] PEP 567 -- Context Variables

Hi Dima, 2017-12-13 7:39 GMT+01:00 Dima Tisnek : > get()/set(value)/delete() methods: Python provides syntax sugar for > these, let's use it. > (dict: d["k"]/d["k] = value/del d["k"]; attrs: obj.k/obj.k = value/del > obj.k; inheriting threading.Local) I was trapped by Context which is described a

Re: [Python-Dev] Support of the Android platform

Hi Xavier, I looked at your scripts to build Android but I failed to use them. Anyway, I'm not sure why these scripts have to be part of the CPython git repository. Technically, is there a reason to put it aside the source code and Unix build scripts (configure/Makefile/setup)? Your https://gith

Re: [Python-Dev] Support of the Android platform

2017-12-14 10:26 GMT+01:00 Xavier de Gaye : > The 'Mac' build system has its own subdirectory in the source tree and it > makes sense as it is the reference build system for this platform. I do not > see why this should be different for Android. Hum, Mac/ is mostly the recipe to build the installe

[Python-Dev] PEP 432 progress: Python initalization

Hi, Serhiy Storchaka seems to be worried by the high numbers of commits in https://bugs.python.org/issue32030 "PEP 432: Rewrite Py_Main()", so let me explain the context of this work :-) To prepare CPython to implement my UTF-8 Mode PEP (PEP 540), I worked on the implementation of Nick Coghlan's

Re: [Python-Dev] PEP 432 progress: Python initalization

; /* sys.argv list, can be NULL */ PyObject *module_search_path; /* sys.path list */ PyObject *warnoptions; /* sys.warnoptions list, can be NULL */ PyObject *xoptions; /* sys._xoptions dict, can be NULL */ } _PyMainInterpreterConfig; Victor 2017-12-14 16:16 GMT+01:00 Victor

Re: [Python-Dev] PEP 432 progress: Python initalization

2017-12-14 22:54 GMT+01:00 Terry Reedy : > You could have (and still could) made that a master issue with multiple > dependencies. Last summer, I merged at least 20 patches for one idlelib > file. I split them up among 1 master issue and about 6 dependency issues. > That was essential because mos

Re: [Python-Dev] New crash in test_embed on macOS 10.12

Hi, 2017-12-15 20:55 GMT+01:00 Barry Warsaw : > I haven’t bisected this yet, but with git head, built and tested on macOS > 10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed: > > == > FAIL: test_bpo20891 (test.test_embed

[Python-Dev] Broken svn lookup?

Hi, I was looking at old issues. In https://bugs.python.org/issue8610#msg105805 I found the link: http://svn.python.org/view?view=revision&revision=81190 Sadly, the link fails with HTTP 404 Not Found :-( Is the service down? It's no more possible to browse the old Subversion repository? Vict

Re: [Python-Dev] Broken svn lookup?

wvc off a few months ago because subversion is highly deprecated > at this point. In fact, now that Windows build dependencies have moved off, > I’m probably going to shut it off for good soon. > > > On Mon, Dec 18, 2017, at 06:55, Victor Stinner wrote: >> Hi, >> >> I w

Re: [Python-Dev] PEP 567 v2

Hi, I like the new version of the PEP using "read only mapping" and copy_context(). It's easier to understand. I'm ok with seeing a context as a mapping, but I am confused about a context variable considered as a mapping item. I still see a context variable as a variable, so something which has a

Re: [Python-Dev] PEP 567 v2

NLe 28 déc. 2017 11:20 AM, "Nathaniel Smith" a écrit : On Thu, Dec 28, 2017 at 1:51 AM, Victor Stinner wrote: > var = ContextVar('var', default=42) > > and: > > var = ContextVar('var') > var.set (42) > > behaves the same, no? No, they&

Re: [Python-Dev] PEP 567 v2

> I would really like to invite more people to review this PEP! I expect I'll be accepting it in the next two weeks, but it needs to go through more rigorous review. I read again the PEP and I am still very confused by Context.run(). The PEP states multiple times that a context is immutable: * "

Re: [Python-Dev] PEP 567 v2

Le 2 janv. 2018 18:57, "Guido van Rossum" a écrit : Oh, the "Specification" section in the PEP is too brief on several of these subjects. It doesn't really specify what var.get() does if the value is not set, nor does it even mention var.get() except in the code examples for var.reset(). It's als

Re: [Python-Dev] PEP 567 v2

Why ContextVar.reset(token) does nothing at the second call with the same token? What is the purpose of Token._used? I guess that there is an use case to justify this behaviour. reset() should have a result: true if the variable was restored to its previous state, false if reset() did nothing beca

Re: [Python-Dev] PEP 567 v2

PEP: "int PyContext_Enter(PyContext *) and int PyContext_Exit(PyContext *) allow to set and restore the context for the current OS thread." What is the difference between Enter and Exit? Why not having a single Py_SetContext() function? Victor ___ Pytho

Re: [Python-Dev] PEP 567 v2

What is the behaviour of ContextVar.reset(token) if the token was created from a different variable? Raise an exception? token = var1.set("value") var2.reset(token) The PEP states that Token.var only exists for debug or introspection. Victor Le 3 janv. 2018 00:51, "Victor St

Re: [Python-Dev] PEP 567 v2

ely the current context with another context. The fact that there is no concrete context instance by default doesn't really matter in term of API. Victor Le 3 janv. 2018 00:34, "Victor Stinner" a écrit : > > I would really like to invite more people to review this PEP! I expec

Re: [Python-Dev] PEP 567 v2

Le 3 janv. 2018 06:05, "Yury Selivanov" a écrit : tuples in Python are immutable, but you can have a tuple with a dict as its single element. The tuple is immutable, the dict is mutable. At the C level we have APIs that can mutate a tuple though. Now, tuple is not a direct analogy to Context, b

Re: [Python-Dev] PEP 567 v2

Le 3 janv. 2018 06:34, "Guido van Rossum" a écrit : I think the issue here is a bit different than Yury's response suggests -- it's more like how a variable containing an immutable value (e.g. a string) can be modified, e.g. x = 'a' x += 'b' In our case the *variable* is the current thread stat

Re: [Python-Dev] PEP 567 v2

Le 3 janv. 2018 06:38, "Guido van Rossum" a écrit : But is there a common use case? For var.get() I'd rather just pass the default or catch the exception if the flow is different. Using ctx[var] is rare (mostly for printing contexts, and perhaps for explaining var.get()). I don't think that it

Re: [Python-Dev] PEP 567 v2

Victor: > ContextVar would be simpler if the default would be mandatory as well :-) If we modify ContextVar to use None as the default value, the 'default' parameter of ContextVar.get() becomes useless, ContextVar.get() and context[var] behaviour becomes obvious. Token.MISSING could also be remove

Re: [Python-Dev] PEP 567 v2

> Do you have any use case for modifying a variable inside some context? > numpy, decimal, or some sort of tracing for http requests or async frameworks like asyncio do not need that. Maybe I misunderstood how contextvars is supposed to be used. So let me give you an example. I understand that d

Re: [Python-Dev] PEP 567 v2

2018-01-03 23:01 GMT+01:00 Guido van Rossum : > Heh, you're right, I forgot about that. It should be more like this: > > def run(self, func, *args, **kwds): > old = _get_current_context() > _set_current_context(self) # <--- changed line > try: > return func(*args, **kwds) >

Re: [Python-Dev] PEP 567 v2

Ok, I finally got access to a computer and I was able to test the PEP 567 implementation: see my code snippet below. The behaviour is more tricky than what I expected. While running context.run(), the context object is out of sync of the "current context". It's only synchronized again at run() exi

Re: [Python-Dev] PEP 567 v2

2018-01-04 0:44 GMT+01:00 Victor Stinner : > The behaviour is more tricky than what I expected. While running > context.run(), the context object is out of sync of the "current > context". It's only synchronized again at run() exit. So > ContextVar.set() doesn't i

[Python-Dev] PEP 567 (contextvars) idea: really implement the current context

Hi, It seems like many people, including myself, are confused by the lack of concrete current context in the PEP 567 (contextvars). But it isn't difficult to implement the current context (I implemented it, see below). It might have a *minor* impact on performance, but Context mapping API is suppo

Re: [Python-Dev] PEP 567 (contextvars) idea: really implement the current context

Victor: > I modified Context mapping API to use the context variables from the > current thread state if it's the current thread state. Oops, I mean: "if it's the current context". Nathaniel: """ - BUT it doesn't allow mutation through the MutableMapping interface; instead, the only way to mutate

Re: [Python-Dev] PEP 567 (contextvars) idea: really implement the current context

2018-01-04 3:15 GMT+01:00 Nathaniel Smith : > The problem with such an API is that it doesn't work (or at the very > least creates a lot of complications) in a potential future PEP 550 > world, (...) Hum, it's annoying that many design choices of the PEP 567 are motivated by the hypothetical accep

Re: [Python-Dev] PEP 567 v2

Currently, Context.get(var) returns None when "var in context" is false. That's surprising and different than var.get(), especially when var has a default value. Code: --- import contextvars name = contextvars.ContextVar('name', default='victor') context = contextvars.copy_context() print(name in

Re: [Python-Dev] PEP 567 v2

You can only modify a context when it's the current context, so using ContextVar.set() in Context.run(). Victor Le 5 janv. 2018 11:42 AM, "Paul Moore" a écrit : On 4 January 2018 at 23:58, Guido van Rossum wrote: > On Thu, Jan 4, 2018 at 9:27 AM, Paul Moore wrote: >> >> On 4 January 2018 at 1

Re: [Python-Dev] PEP 567 pre v3

Le 8 janv. 2018 8:36 PM, "Yury Selivanov" a écrit : 2. Context.__contains__, Context.__getitem__ and ContexVar.default So if we keep the current PEP 567 behaviour w.r.t. defaults, ContextVar.get() might return a different value from Context.get(): v = ContextVar('v', default=42) ctx = c

Re: [Python-Dev] PEP 567 pre v3

Hum, now I'm confused. I was probably confused by ContextVar.get() differences with Context.get(). It's fine if it behaves with a dict. Victor Le 9 janv. 2018 12:02 AM, "Nathaniel Smith" a écrit : > On Mon, Jan 8, 2018 at 2:35 PM, Victor Stinner > wrote: > >

Re: [Python-Dev] PEP 567 pre v3

2018-01-09 12:41 GMT+01:00 Yury Selivanov : > But I'd be -1 on making all ContextVars have a None default > (effectively have a "ContextVar.get(default=None)" signature. This > would be a very loose semantics in my opinion. Why do you think that it's a loose semantics? For me ContextVar/Context ar

Re: [Python-Dev] [RELEASE] Python 3.7.0a4 is now available for testing

Hi, Python 3.7.0a4 includes the implementation of the PEP 538 (C locale coercion) and PEP 540 (UTF-8 Mode). Please test this Python with various locales, especially with the POSIX ("C") locale! Note: The UTF-8 Mode has a known issue with the readline module, I see how to fix it (add new encode/de

Re: [Python-Dev] PEP 567 v3

Hi Yury, Thanks for the updated PEP v3, it's now much better than PEP v2! I have no more complain against your PEP. I vote +1 for PEP 567 contextvars! > The only open question I personally have is whether ContextVar.reset() > should be idempotent or not. Maybe we should be strict and raise an >

[Python-Dev] Positional-only parameters in Python

Hi, In Februrary 2017, I proposed on python-ideas to change the Python syntax to allow to declare positional-only parameters in Python: https://mail.python.org/pipermail/python-ideas/2017-February/044879.html https://mail.python.org/pipermail/python-ideas/2017-March/044956.html There are already

Re: [Python-Dev] PEP 567 v3

FYI In the PEP 540, I didn't try to elaborate on each design change, but I wrote a very short version history at the end: https://www.python.org/dev/peps/pep-0540/#version-history Maybe something like that would help for the PEP 567? Victor Le 17 janv. 2018 8:26 PM, "Guido van Rossum" a écrit :

Re: [Python-Dev] Positional-only parameters in Python

2018-01-18 10:26 GMT+01:00 Larry Hastings : > Why did Argument Clinic choose that syntax? It was suggested by one Guido > van Rossum in March 2012: (...) > I'm not wading into the debate over what syntax Python should use if it adds > positional-only parameters, except to say that I think "/" is r

[Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

Hi, I'm working on a exhaustive list of platforms supported by Python: http://vstinner.readthedocs.io/cpython.html#supported-platforms I noticed that the extended support phase of Windows Vista is expired, so I proposed to drop Vista support: "Drop support of Windows Vista in Python 3.7"

Re: [Python-Dev] Unexpected bytecode difference

Python bytecode format changed deeply in Python 3.6. It now uses regular units of 2 bytes, instead of 1 or 3 bytes depending if the instruction has an argument. See for example https://bugs.python.org/issue26647 "wordcode". But CALL_FUNCTION bytecode also evolved. Victor 2018-01-20 0:46 GMT+01:

Re: [Python-Dev] Unexpected bytecode difference

It seems like the EXTENDED_ARG doc wasn't updated. Victor 2018-01-20 1:07 GMT+01:00 Alexander Belopolsky : > On Fri, Jan 19, 2018 at 7:01 PM, Guido van Rossum wrote: >> Presumably because Python 3 switched to wordcode. Applying dis.dis() to >> these code objects results in the same output. >> >>

Re: [Python-Dev] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?

I created an issue with more information: https://bugs.python.org/issue32620 Victor 2018-01-22 11:33 GMT+01:00 Larry Hastings : > > > I have three PRs for Python 3.5.5rc1: > > https://github.com/python/cpython/pull/4656 > https://github.com/python/cpython/pull/5197 > https://github.com/python/cpy

Re: [Python-Dev] Support of the Android platform

Hi, I'm still talking with Paul Peny (pmpp on IRC) who is trying to build the master branch of Python on Android, using cross-compilation or directly on an Android device. I started to took notes since Android is a complex platforms and it's not easy for me to remember everything. http://vstinner

Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

2018-01-18 21:27 GMT+01:00 Victor Stinner : > I proposed: "Drop FreeBSD 9 and older support:" > > https://bugs.python.org/issue32593 > https://github.com/python/cpython/pull/5232 > > FreeBSD 9 supported ended 1 year ago (December 2016). > > FreeBSD supp

Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

I asked if we should drop support for Linux kernel 2.6. I now consider that no, we should not. It's not worth it. A colleague proposed to setup a RHEL 6 buildbot which would test Python on Linux 2.6. 2018-01-19 10:26 GMT+01:00 Antoine Pitrou : > What is the problem with supporting Linux 2.6? It

Re: [Python-Dev] Intention to accept PEP 567 (Context Variables)

The PEP 555 looks a competitor PEP of the PEP 567. Since the Yury's PEP 567 was approved, I understand that Koos's PEP 555 should be rejected, no? Victor 2018-01-23 0:52 GMT+01:00 Guido van Rossum : > Yury, > > I am hereby *accepting* the latest version of PEP 567[1]. Congrats! > > --Guido > > [1

Re: [Python-Dev] Support of the Android platform

Ok, I created https://bugs.python.org/issue32637 "Android: set sys.platform and os.name to android" Victor 2018-01-23 18:01 GMT+01:00 Brett Cannon : > > > On Mon, 22 Jan 2018 at 09:29 Victor Stinner > wrote: >> >> Hi, >> >> I'm still talking

Re: [Python-Dev] PEP 432 progress: Python initalization

Hi, FYI I pushed a new change related to the PEP 432: it becomes possible to skip completely the calculation of paths, especially sys.path. If you fill "Path configuration outputs" fileds of PyCoreConfig (see below), _PyPathConfig_Init() should not be called. It should be helpful for some users w

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

GH prefix avoids confusion between bugs.python.org and GitHub, but GitHub generates #xxx in the generated commit message on Merge... Each commit message has to be manually edited. It would be better to get GH automatically. Victor Le 25 janv. 2018 11:44, "INADA Naoki" a écrit : > Hi. > > Devgui

Re: [Python-Dev] Merging the implementation of PEP 563

Hi, If nobody is available to review your PR, I suggest to push it anyway, to get it merged before the feature freeze. The code can be reviewed later. Merging it sooner gives more time to test it and spot bugs. It also gives more time to fix bugs ;-) Well, at the end, it's up to you. Victor 2018

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

2018-01-25 22:46 GMT+01:00 Barry Warsaw : > Why not just auto merge if the PR is approved, CI is all green, and no > additional commits have been pushed? Merging a PR and approving it should be two different actions. Sometimes, you prefer to wait for 2 approvals before merging. Sometimes, you wan

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

2018-01-25 22:55 GMT+01:00 Mariatta Wijaya : > My problem has been that I almost always still need to rewrite the commit > message. > Especially when someone wrote "fix a typo" or "fix several typos". That's the main drawback of GitHub compared to Gerrit. On Gerrit, the commit message is at the sa

Re: [Python-Dev] New Contributor looking for help

This is https://bugs.python.org/issue32667 which I already fixed with Jay Yin yesterday. Victor Le 26 janv. 2018 8:27 PM, "Jay Yin" a écrit : > Hello everyone, > > > I've been trying to build the master branch on Ubuntu 16.04 and it > currently fails 2 test, I was wondering if this was normal o

[Python-Dev] Sad buildbots

Hi, It seems like the feature freeze is close: while I usually get 2 emails/day at maximum on buildbot-status, I got 14 emails during the weekend: https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/ (are all buildbots red? :-p) I will not have the bandwidth to analyze all buildb

Re: [Python-Dev] Sad buildbots

3 GMT+01:00 Ned Deily : > On Jan 28, 2018, at 18:00, Victor Stinner wrote: >> It seems like the feature freeze is close: while I usually get 2 >> emails/day at maximum on buildbot-status, I got 14 emails during the >> weekend: >> https://mail.python.org/mm3/archives/li

Re: [Python-Dev] Making "-j0" the default setting for the test suite?

> * "-j1" would explicitly turn off multiprocessing Running tests "sequentially" but run them in one subprocess per test file is interesting for tests isolation. Runing tests one by one reduces the risk of triggering a race condition (test only failing when the system load is high). -jN was alway

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

See https://bugs.python.org/issue31912 and https://bugs.python.org/issue27987 Victor 2018-01-30 19:56 GMT+01:00 Florian Weimer : > I hope this is the right list for this kind of question. We recently > tried to build Python 2.6 with GCC 8, and ran into this issue: > >

Re: [Python-Dev] Making "-j0" the default setting for the test suite?

2018-01-31 3:23 GMT+01:00 Nick Coghlan : > Something like: > > Total duration: 16 minutes 33 seconds (serial execution, pass > '-j0' for parallel execution) > > Such a change would be a safe way to nudge new contributors towards > "./python -m test -j0" for faster local testing, without risking

Re: [Python-Dev] OS-X builds for 3.7.0

There is https://speed.python.org/comparison/ to compare Python 2.7, 3.5, 3.6 and master (future 3.7). Victor Le 31 janv. 2018 13:14, "Ray Donnelly" a écrit : > On Wed, Jan 31, 2018 at 11:16 AM, Joni Orponen > wrote: > > On Wed, Jan 31, 2018 at 9:31 AM, Ray Donnelly > > wrote: > >> > >> We se

Re: [Python-Dev] OS-X builds for 3.7.0

ve Holden > > On Wed, Jan 31, 2018 at 1:06 PM, Victor Stinner > wrote: >> >> There is https://speed.python.org/comparison/ to compare Python 2.7, 3.5, >> 3.6 and master (future 3.7). >> >> Victor >> >> Le 31 janv. 2018 13:14, "Ray Donnelly&quo

[Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

Hi, I have been asked to express myself on the PEP 572. I'm not sure that it's useful, but here is my personal opinion on the proposed "assignment expressions". PEP 572 -- Assignment Expressions: https://www.python.org/dev/peps/pep-0572/ First of all, I concur with others: Chris Angelico did a g

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

> # Handle a matched regex > if (match := pattern.search(data)) is not None: > ... > > # A more explicit alternative to the 2-arg form of iter() invocation > while (value := read_next_item()) is not None: > ... > > # Share a subexpression between a comprehension

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

I gave the talk "Python 3: 10 years later" at FOSDEM and Pycon Italy and will give it again at Pycon US next month: https://fosdem.org/2018/schedule/event/python3/ My talk is focused on the migration path. How to "port" Python 2 code to Python 3, 2to3 tool, six module, things done to make the migr

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

In my opinion, the largest failure of Python 3 is that we failed to provide a smooth and *slow* transition from Python 2 and Python 3. It can be explained by the long list of backward incompatible changes. My advice would be to restrict the number of backward incompatible changes per release, and

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

2018-04-28 3:33 GMT+02:00 Greg Ewing : > Victor Stinner wrote: >> >> In my opinion, the largest failure of Python 3 is that we failed to >> provide a smooth and *slow* transition from Python 2 and Python 3. > > Although for some things, such as handling of non-ascii tex

Re: [Python-Dev] Bugs Migration to OpenShift

Does it mean that the final switch will happen during the sprints? Would it be possible to do it before or after? If bugs.python.org doesn't work during the sprint, it will be much harder to contribute to CPython during the sprints. (If I misunderstood, ignore my message :-)) Victor 2018-04-29 1

Re: [Python-Dev] PEP 572: Usage of assignment expressions in C

2018-04-28 17:45 GMT+02:00 Antoine Pitrou : > // Read up to n bytes from file descriptor > if ((bytes_read = read(fd, buf, n)) == -1) { > // Error occurred while reading, do something > } About C, there is a popular coding style (not used by our PEP 7) for comparison: if (-1 == n)

Re: [Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

2018-04-27 17:37 GMT+02:00 Petr Viktorin : > (...) > - The paragraph about the anticipated future where python points to Python 3 > is removed. Instead of editing old PEPs, would it make sense to write a new one which replaces the old one? The PEP 394 has been written in 2011 and accepted in 2012

Re: [Python-Dev] [python-committers] IMPORTANT - final 3.7.0 beta cutoff!

Hi, I modified the behaviour of the socketserver module: ThreadingMixIn now waits until all threads complete and ForkingMixIn now waits until all child processes complete https://bugs.python.org/issue31233 https://bugs.python.org/issue31151 I was supposed to do something, like add an option to a

[Python-Dev] Process to remove a Python feature

Hi, As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on the Move to Python 3" thread, I will like to clarify how a feature should be removed from Python. We have multiple tools: * Emit a PendingDeprecationWarning warning at runtime for *slow* deprecation (remove a feature in at

Re: [Python-Dev] Python startup time

What do you propose to make Python startup faster? As I wrote in my previous emails, many Python core developers care of the startup time and we are working on making it faster. INADA Naoki added -X importtime to identify slow imports and understand where Python spent its startup time. Recent ex

Re: [Python-Dev] [RELEASE] Python 2.7.15

Sadly, Python 2.7.15 still miss the implementation of the "PEP 546 -- Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7": https://www.python.org/dev/peps/pep-0546/ Last time I checked, the tests failed on Travis CI and I failed to reproduce the issue: https://bugs.python.org/issue22559 I exp

Re: [Python-Dev] Process to remove a Python feature

2018-05-02 11:17 GMT+02:00 Antoine Pitrou : > It's at least possible with gcc, clang and MSVC: > https://stackoverflow.com/questions/295120/c-mark-as-deprecated/295229#295229 > > You can even add a deprecation message. Aha, I opened an issue: https://bugs.python.org/issue33407 "Implement Py_DEPREC

Re: [Python-Dev] PEP 575: Unifying function/method classes

2018-05-03 11:22 GMT+02:00 Stefan Behnel : > The final split could then be done later, e.g. for Py4.0, where people > would be less surprised about minor breakages. Please don't queue backward incompatible changes for Python 4.0. You should use the regular deprecation process. (I didn't read the

Re: [Python-Dev] Process to remove a Python feature

2018-05-02 19:24 GMT+02:00 Brett Cannon : > On Wed, 2 May 2018 at 02:12 Victor Stinner wrote: >> Does it mean that the Python 3 release following Python 2 end-of-life >> (2020) will be our next feared "Python 4"? Are we going to remove all >> deprecate

Re: [Python-Dev] Process to remove a Python feature

2018-05-04 23:59 GMT+02:00 Terry Reedy : > Would it be possible (and sensible) to use the 2to3 machinery to produce > 36to37.py, etc., to do mechanical replacements when possible and flag other > things when necessary? I suggest you to watch Daniele Esposti's talk "Evolution or stagnation programm

Re: [Python-Dev] Process to remove a Python feature

2018-05-04 20:48 GMT+02:00 Serhiy Storchaka : > I think the information about since which version number it will be removed > is more useful. About deprecation, there is the funny story of bytes filenames on Windows. I deprecated this feature in Windows 3.3 since it was broken. I really wanted har

Re: [Python-Dev] Changes to configure.ac, auto-detection and related build issues

Hi Eitan, 2018-05-15 0:01 GMT-04:00 Eitan Adler : > I am working on updating, fixing, or otherwise changing python's > configure.ac. This work is complex, (...) Is your work public? Is there an open issue on bugs.python.org or an open pull request? If not, would you mind to at least describe the

Re: [Python-Dev] Changes to configure.ac, auto-detection and related build issues

I didn't look at your PRs yet, but PR commits are squashed into a single commit. So it's better to have multiple PRs for different changes. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsub

Re: [Python-Dev] Hashes in Python3.5 for tuples and frozensets

Hi, String hash is randomized, but not the integer hash: $ python3.5 -c 'print(hash("abc"))' -8844814677999896014 $ python3.5 -c 'print(hash("abc"))' -7757160699952389646 $ python3.5 -c 'print(hash(1))' 1 $ python3.5 -c 'print(hash(1))' 1 frozenset hash is combined from values of the set. So it

Re: [Python-Dev] PEP: 576 Title: Rationalize Built-in function classes

2018-05-19 11:15 GMT+02:00 mark : > The PEP can be viewed here: > https://github.com/python/peps/blob/master/pep-0576.rst > (...) > P.S. > I'm happy to have discussion of this PEP take place via GitHub, > rather than the mailing list, but I thought I would follow the conventional > route for now.

[Python-Dev] Reminder: Please elaborate commit messages

Hi, In https://bugs.python.org/issue33531, Andrew Svetlov wrote "Fixed failed sendfile tests on Windows (at least I hope so)." without giving any bpo number or a commit number. So I looked at latest commits and I found: --- commit e2537521916c5bf88fcf54d4654ff1bcd332be4a Author: Andrew Svetlov D

Re: [Python-Dev] Reminder: Please elaborate commit messages

no? :-) Victor 2018-05-22 14:37 GMT+02:00 Andrew Svetlov : > Sorry for that. > I thought that the bpo issue can be skipped because it is tests-only change, > no asyncio code was affected. > Will be more accurate next time. > > On Tue, May 22, 2018 at 3:26 PM Victor Stinner wrote:

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

Ah, Python doesn't compile on Windows anymore :-) https://bugs.python.org/issue33614 Victor 2018-05-23 14:16 GMT+02:00 Victor Stinner : > 2018-05-23 13:45 GMT+02:00 Serhiy Storchaka : >> CI was broken for few latest days, tests are not passed on my computer still >> (and fa

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

2018-05-23 13:45 GMT+02:00 Serhiy Storchaka : > CI was broken for few latest days, tests are not passed on my computer still > (and fail on some buildbots), (...) I looked at buildbots and I confirm that many of the 3.x buildbots are red: AMD64 FreeBSD 10.x Shared 3.x AMD64 Windows8.1 Non-Debug 3

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

2018-05-24 9:23 GMT+02:00 Ned Deily : > Any merges to the 3.7 branch after > that will be released in 3.7.1 which we tentatively are planning to > ship sometime before the end of July (< 2018-07-31). I recall that Python 3.6.0 was full of bugs, some functions like os.waitpid() on Windows (if I rec

Re: [Python-Dev] PEP 574 (pickle 5) implementation and backport available

Link to the PEP: "PEP 574 -- Pickle protocol 5 with out-of-band data" https://www.python.org/dev/peps/pep-0574/ Victor 2018-05-24 19:57 GMT+02:00 Antoine Pitrou : > > Hi, > > While PEP 574 (pickle protocol 5 with out-of-band data) is still in > draft status, I've made available an implementation

Re: [Python-Dev] Add __reversed__ methods for dict

It looks like an optimization, since you can already do something like reversed(list(d)). Do you have benchmark numbers to see the benefit of your change? Even if reversed(list(d)) is slow, I'm not sure that it's worth it to optimize it, since it's a rare usecase. Victor 2018-05-24 14:55 GMT+02:

Re: [Python-Dev] Add __reversed__ methods for dict

INADA Naoki asked Rémi Lapeyre in https://bugs.python.org/issue33462 to start a discussion on python-dev. Victor 2018-05-25 17:48 GMT+02:00 Guido van Rossum : > (Also this probably belongs in python-ideas, unless there's already a > bugs.python.org issue for it -- but you didn't mention that so I

[Python-Dev] macOS: minimum supported version?

Hi, Ned Deily closed old bugs reported on the macOS Tiger buildbot, since this buildbot has been retired 3 months ago (the builders are still visible online, but last builds were 3 months ago). It seems like the oldest macOS buildbot is now macOS El Capitan (macOS 10.11, 2015). Does it mean that

[Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

Hi, Since one or two weeks, I noticed that it's difficult to merge pull requests into the 2.7 branch. If a different commit is pushed in the meanwhile (if a different PR has been merged), the 2.7 branch diverges and the PR is immediately marked as "This branch is out-of-date with the base branch"

Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

2018-05-28 19:47 GMT+02:00 Ned Deily : > Hmm, for some some reason, it appears that, at the moment, the 2.7, 3.4, and > 3.5 branches have that option set, while 3.6, 3.7, and master don't. I'm not > sure how we got to that state. Any other reasons to prefer on versus off? As I wrote, it became

Re: [Python-Dev] Compact GC Header

> I hacked GC module and managed to slim PyGC_Head down from 3 words to 2 > words. > It passes test suite, while some comments and code cleanup is needed before > merge. Does this change break the stable ABI? Victor ___ Python-Dev mailing list Python-De

Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

GitHub provides a [Update branch] button. It seems like the button does a rebase, no? Victor 2018-05-29 18:24 GMT+02:00 Matthias Bussonnier : > On Tue, 29 May 2018 at 08:43, Paul G wrote: >> >> This doesn't seem like the best idea, since it would kick off dozens or >> hundreds of builds for ever

Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

2018-05-29 22:12 GMT+02:00 Miro Hrončok : > On 29.5.2018 22:01, Victor Stinner wrote: >> >> GitHub provides a [Update branch] button. It seems like the button >> does a rebase, no? > > > AFAIK it merges the traget branch to the PR branch. No rebase. Oh right! And i

[Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression

Hi, I fixed a few tests which failed randomly. There are still a few, but the most annoying have been fixed. I will continue to keep an eye on our CIs: Travis CI, AppVeyor and buildbots. Sometimes, even when I report a regression, the author doesn't fix the bug. But when a test fails on Travis CI

[Python-Dev] How to watch buildbots?

Hi, I would like to delegate the maintenance task "watch buildbots", since I'm already very busy with many other maintenance tasks. I'm looking for volunteers to handle incoming emails on buildbot-status. I already started to explain to Pablo Galindo Salgado how to do that, but it would be great t

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