Re: [Python-Dev] Speeding up CPython 5-10%

On 01.02.2016 17:54, Yury Selivanov wrote: If I were to do some big refactoring of the ceval loop, I'd probably consider implementing a register VM. While register VMs are a bit faster than stack VMs (up to 20-30%), they would also allow us to apply more optimizations, and even bolt on a simpl

Re: [Python-Dev] More optimisation ideas

On Mon, 01 Feb 2016 14:12:27 +1100, Steven D'Aprano wrote: > On Sun, Jan 31, 2016 at 08:23:00PM +, Brett Cannon wrote: > > So freezing the stdlib helps on UNIX and not on OS X (if my old testing is > > still accurate). I guess the next question is what it does on Windows and > > if we would wa

Re: [Python-Dev] Speeding up CPython 5-10%

On 01.02.2016 19:28, Brett Cannon wrote: A search for [stack vs register based virtual machine] will get you some information. Alright. :) Will go for that. You aren't really supposed to yet. :) In Pyjion's case we are still working on compatibility, let alone trying to show a speed improveme

Re: [Python-Dev] More optimisation ideas

Thanks, Brett. Wasn't aware of lazy imports as well. I think that one is even better reducing startup time as freezing stdlib. On 31.01.2016 18:57, Brett Cannon wrote: I have opened http://bugs.python.org/issue26252 to track writing the example (and before ppl go playing with the lazy loader, b

Re: [Python-Dev] Speeding up CPython 5-10%

On 01.02.2016 18:18, Brett Cannon wrote: On Mon, 1 Feb 2016 at 09:08 Yury Selivanov > wrote: On 2016-01-29 11:28 PM, Steven D'Aprano wrote: > On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote: >> Hi, >> >> >> tl;dr The s

Re: [Python-Dev] Opcode cache in ceval loop

On 01.02.2016 20:51, Yury Selivanov wrote: If LOAD_ATTR gets too many cache misses (20 in my current patch) it gets deoptimized, and the default implementation is used. So if the code is very dynamic - there's no improvement, but no performance penalty either. Will you re-try optimizing it?

Re: [Python-Dev] Opcode cache in ceval loop

On 01.02.2016 21:35, Yury Selivanov wrote: It's important to understand that if we have a lot of cache misses after the code object was executed 1000 times, it doesn't make sense to keep trying to update that cache. It just means that the code, in that particular point, works with different ki

Re: [Python-Dev] Opcode cache in ceval loop

On 01.02.2016 22:27, Yury Selivanov wrote: Right now they are private constants in ceval.c. I will (maybe) expose a private API via the _testcapi module to re-define them (set them to 1 or 0), only to write better unittests. I have no plans to make those constants public or have a public API

Re: [Python-Dev] Opcode cache in ceval loop

On 01.02.2016 22:43, Yury Selivanov wrote: Sven, On 2016-02-01 4:32 PM, Sven R. Kunze wrote: On 01.02.2016 22:27, Yury Selivanov wrote: Right now they are private constants in ceval.c. I will (maybe) expose a private API via the _testcapi module to re-define them (set them to 1 or 0), only

Re: [Python-Dev] Speeding up CPython 5-10%

On 02.02.2016 00:27, Greg Ewing wrote: Sven R. Kunze wrote: Are there some resources on why register machines are considered faster than stack machines? If a register VM is faster, it's probably because each register instruction does the work of about 2-3 stack instructions, meaning

Re: [Python-Dev] Opcode cache in ceval loop

On 02.02.2016 20:41, Yury Selivanov wrote: Hi Victor, On 2016-02-02 4:33 AM, Victor Stinner wrote: Hi, Maybe it's worth to write a PEP to summarize all your changes to optimize CPython? It would avoid to have to follow different threads on the mailing lists, different issues on the bug tracker

Re: [Python-Dev] Opcode cache in ceval loop

On 03.02.2016 22:22, Yury Selivanov wrote: One way of tackling this is to give each optimized opcode a counter for hit/misses. When we have a "hit" we increment that counter, when it's a miss, we decrement it. Within a given range, I suppose. Like: c = min(c+1, 100) I kind of have somethin

Re: [Python-Dev] Opcode cache in ceval loop

let's say 20% miss threshold, you increment by 1 on hit, and decrement by 4 on miss. Division is expensive. On Feb 3, 2016, at 13:37, Sven R. Kunze wrote: On 03.02.2016 22:22, Yury Selivanov wrote: One way of tackling this is to give each optimized opcode a counter for hit/misses. Wh

Re: [Python-Dev] More optimisation ideas

On 04.02.2016 14:09, Nick Coghlan wrote: On 2 February 2016 at 06:39, Andrew Barnert via Python-Dev wrote: On Feb 1, 2016, at 09:59, mike.romb...@comcast.net wrote: If the stdlib were to use implicit namespace packages ( https://www.python.org/dev/peps/pep-0420/ ) and the various loaders/imp

Re: [Python-Dev] Opcode cache in ceval loop

On 05.02.2016 00:06, Matthias Bussonnier wrote: On Feb 4, 2016, at 08:22, Sven R. Kunze wrote: On 04.02.2016 16:57, Matthias Bussonnier wrote: On Feb 3, 2016, at 13:22, Yury Selivanov wrote: An ideal way would be to calculate a hit/miss ratio over time for each cached opcode, but that

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

On Fri, 26 Feb 2016 10:05:19 -0800, Dan Stromberg wrote: > But what do you really think? > > IMO, windows builds probably should do both visual studio and mingw. > That is, there probably should be two builds on windows, since there's > no clear consensus about which to use. > > I certainly pref

Re: [Python-Dev] Bug in build system for cross-platform builds

On Mon, 14 Mar 2016 03:04:08 -, "Gregory P. Smith" wrote: > On Sun, Mar 13, 2016 at 7:41 PM Martin Panter wrote: > > > On 13 March 2016 at 01:13, Russell Keith-Magee > > wrote: > > > The patches that I've uploaded to Issue23670 [1] show a full > > cross-platform > > > [1] http://bugs.python

Re: [Python-Dev] Not receiving bug tracker emails

On Wed, 30 Mar 2016 08:08:59 +0300, Serhiy Storchaka wrote: > On 30.03.16 03:23, Victor Stinner wrote: > > same for me, i'm using using gmail with a @gmail.com email. > > > > Victor > > > > 2016-03-30 1:30 GMT+02:00 Martin Panter : > >> For the last ~36 hours I have stopped receiving emails for m

[Python-Dev] bugs.python.org email blockage at gmail

We think we have a partial (and hopefully temporary) solution to the bugs email blockage: ipv6 has been turned off on bugs, so it is sending only from the ipv4 address. Google appears to be accepting the emails again. However, the IPV4 address has a poor reputation, and Verizon at least appears t

Re: [Python-Dev] bugs.python.org email blockage at gmail

On Wed, 06 Apr 2016 12:21:04 +1000, Nick Coghlan wrote: > On 6 April 2016 at 11:27, Terry Reedy wrote: > bugs.python.org is currently sending notification emails directly to > recipients, rather than routing them via the outbound SMTP server on > mail.python.org. Correct. > Reconfiguring it to

Re: [Python-Dev] bugs.python.org email blockage at gmail

On Wed, 06 Apr 2016 12:03:36 +0900, "Stephen J. Turnbull" wrote: > R. David Murray writes: > > > again. However, the IPV4 address has a poor reputation, and Verizon > > at least appears to be blocking it. So more work is still needed. > > Don't tak

Re: [Python-Dev] Defining a path protocol

On 06.04.2016 21:02, Alexander Belopolsky wrote: On Wed, Apr 6, 2016 at 2:32 PM, Brett Cannon > wrote: +1 for __path__, +0 for __fspath__ (I don't know how widespread the notion that "fs" means "file system" is). Same here. In the good old days, "fs" stood

Re: [Python-Dev] When should pathlib stop being provisional?

On 06.04.2016 07:00, Guido van Rossum wrote: On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote: [...] we can't do: app_root = Path(...) config = app_root/'settings.cfg' with open(config) as blah: # whatever It feels like instead of addressing this basic disconnect, th

Re: [Python-Dev] Defining a path protocol

On 06.04.2016 22:28, Brett Cannon wrote: On Wed, 6 Apr 2016 at 13:20 Sven R. Kunze <mailto:srku...@mail.de>> wrote: What about __file_path__ Can be a directory as well (and you could argue semantics of file system inodes, beginners won't know the subtlety and/o

Re: [Python-Dev] Defining a path protocol

On 06.04.2016 22:55, Brett Cannon wrote: On Wed, 6 Apr 2016 at 13:54 Sven R. Kunze <mailto:srku...@mail.de>> wrote: Furthermore, we MIGHT later want some URI support, so I don't know off the top of my head if there's a difference between __fspath__ and __u

Re: [Python-Dev] When should pathlib stop being provisional?

06.04.2016 23:03, Ethan Furman wrote: On 04/06/2016 01:47 PM, Sven R. Kunze wrote: I still cannot remember what the concrete issue was why we dropped pathlib the same day we gave it a try. It was something really stupid and although I hoped to reduce the size of the code, it was less readable. But it

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, 08 Apr 2016 19:24:44 -, Brett Cannon wrote: > On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote: > > > On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker > > wrote: > > > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven > > wrote: > > >> > > >> > > > >> > __pathstr__ # pathstring > > >> >

Re: [Python-Dev] Pathlib enhancments - method name only

On Sat, 09 Apr 2016 17:48:38 +1000, Nick Coghlan wrote: > On 9 April 2016 at 04:25, Brett Cannon wrote: > > On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote: > >> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote: > >> > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote: > >> >> On Fri, Apr 8, 201

[Python-Dev] pathlib+os/shutil feedback

I talked to my colleague. He didn't remember the concrete use-case, though, he instantly mentioned three possible things (no order of preference): 1) pathlib + mtime 2) os.walk and pathlib 3) creation/removal of paths He wasn't too sure but I checked with the docs and his memories seemed to b

Re: [Python-Dev] Pathlib enhancments - method name only

On Sun, 10 Apr 2016 18:51:23 +1200, Greg Ewing wrote: > > On 9 April 2016 at 23:02, R. David Murray wrote: > > > >>That is, a 'filename' is the identifier we've assigned to this thing > >>pointed to by an inode in linux, but an os path is a text

Re: [Python-Dev] pathlib+os/shutil feedback

On 10.04.2016 16:51, Paul Moore wrote: On 10 April 2016 at 15:07, Sven R. Kunze wrote: If there's some agreement to change things with respect to those 5 points, I am willing to put some time into it. In broad terms I agree with these points. Thanks for doing the research. It would cert

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting something myself. I cannot agree completely. But starting with a comment from Paul, I realized that pathlib is something different than a string. Af

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 22:55, Alexander Walters wrote: Every conceivable way to fix pathlib have already been argued. Are any of them worth doing? Can we get consensus enough to implement one of them? If not, we should consider either dropping the matter or dropping the module. Right now, I don't se

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:08, Random832 wrote: On Mon, Apr 11, 2016, at 17:04, Sven R. Kunze wrote: PS: The only way out that I can imagine is to fix pathlib. I am not in favor of fixing functions of "os" and "os.path" to except "path" objects; Why not? It occurred to

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:05, Random832 wrote: On Mon, Apr 11, 2016, at 16:48, Sven R. Kunze wrote: On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting something myself. I cannot agree completely. But starting

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:15, Ethan Furman wrote: We've pretty decided that we have two options: 1. remove pathlib 2. make the stdlib work with pathlib So we're trying to make option 2 work before falling back to option 1. If you have a way to make pathlib work with the stdlib that doesn't involve "fi

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

, Apr 11, 2016, at 17:43, Sven R. Kunze wrote: So, I might add: 3. add more high-level features to pathlib to prevent a downgrade to os or os.path 3. reimplement the entire ecosystem in every walled garden so no-one has to leave their walled gardens. What's the point of batteries being includ

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 12:41, Paul Moore wrote: As your thoughts appear to have been triggered by my comments, I feel I should clarify. 1. I like pathlib even as it is right now, and I'm strongly -1 on removing it. 2. The "external dependency" aspect of 3rd party solutions makes them far less useful to m

Re: [Python-Dev] pathlib - current status of discussions

Sorry for disturbing this thread's harmony. On 12.04.2016 08:00, Ethan Furman wrote: On 04/11/2016 10:14 PM, Chris Barker - NOAA Federal wrote: Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Because library

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 16:59, Random832 wrote: Strings are strings. Paths are paths. That's were the difference is. Yes but why aren't these both "things that you may want to use to open a file"? Because "things that you may want to use to open a file" is a bit vague and thus conceal the fact that w

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 12.04.2016 18:04, Chris Barker wrote: On Tue, Apr 12, 2016 at 7:54 AM, Sven R. Kunze <mailto:srku...@mail.de>> wrote: My conclusion is that these changes are not optional and tweaking os, io and shutil is just yet another workaround for a clean solution. :) Is

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 00:13, Brett Cannon wrote: I see this whole discussion breaking down into a few groups which changes what gets done upfront and what might be done farther down the line: 1. Maximum acceptance: do whatever we can to make all representation of paths just work, which means maki

Re: [Python-Dev] file system path protocol PEP

Thanks Brett for your hard work. My comments below: On 11.05.2016 18:43, Brett Cannon wrote: Rationale = Historically in Python, file system paths have been represented as strings or bytes. This choice of representation has stemmed from C's own decision to represent file system paths as

Re: [Python-Dev] file system path protocol PEP

On 11.05.2016 23:57, Brett Cannon wrote: On Wed, 11 May 2016 at 14:29 Nikolaus Rath > wrote: On May 11 2016, Brett Cannon mailto:br...@python.org>> wrote: > This PEP proposes a protocol for classes which represent a file system > path to be able to provi

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 17:42, Ethan Furman wrote: On 05/12/2016 01:31 AM, Sven R. Kunze wrote: I think the "Rationale" section ignores the fact the Path also supports the .path attribute now. Which indeed defines a common interface between path objects. The version of Python that has Pat

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 18:56, Ethan Furman wrote: On 05/12/2016 09:26 AM, Sven R. Kunze wrote: str and bytes will receive the __fspath__ attribute when this PEP is accepted? No, they won't. The __fspath__ protocol will reduce the rich path object down to a str/bytes object. Would this mak

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 19:27, Ethan Furman wrote: Maybe, but a bad idea for two reasons: 1) Reducing a str to the exact same str is silly; and, more importantly Finding something silly is no technical argument. Best, Sven ___ Python-Dev mailing list Python-D

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 18:24, Guido van Rossum wrote: def fspath(p: Union[str, bytes, PathLike]) -> Union[str, bytes]: if isinstance(p, (str, bytes)): return p try: return p.__fspath__ except AttributeError: raise TypeError(...) @Brett Would you think it makes sense t

Re: [Python-Dev] file system path protocol PEP

new fspath semantics to the PEP. While I hope Brett is asleep in his time zone, I'm guessing he will agree (just saying this because you write "@Brett"). -- Koos On Fri, May 13, 2016 at 10:58 AM, Sven R. Kunze wrote: On 12.05.2016 18:24, Guido van Rossum wrote: def fspath(p: U

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 11:48, Koos Zevenhoven wrote: This issue is coupled with the future optimization questions. AFAIC coupling API design to optimization is called premature optimization. However, the proposed semantics will change if the checks are swapped. So, my actual question is: Is that an i

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 17:29, Brett Cannon wrote: Purposeful change. It was what I had in my head after I posted my "groups" breakdown email and what Guido suggested as well independently. This helps alleviate any perf worries as type checks in C are pointer checks that are cheap to make compared to att

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 18:43, Chris Angelico wrote: https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Check https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_CheckExact Thanks for pointing me at this. I searched via github and found usages only: https://github.com/python/cpython/search?u

Re: [Python-Dev] Adding Type[C] to PEP 484

On 15.05.2016 19:30, Guido van Rossum wrote: Right. I still have no good intuition for what Type[BasicUser, ProUser] would mean so I think you should be required to use the Union, which is clear. Type[] should only allow one parameter. Type[A, B] reminds me of isinstance(obj, (A, B)). Sven _

[Python-Dev] I broke the 3.5 branch, apparently

I don't understand how it happened, but apparently I got a merge commit backward and merged 3.6 into 3.5 and pushed it without realizing what had happened. If anyone has any clue how to reverse this cleanly, please let me know. (There are a couple people at the sprints looking in to it, but the m

Re: [Python-Dev] FIXED: I broke the 3.5 branch, apparently

On Fri, 03 Jun 2016 23:21:25 +0100, MRAB wrote: > On 2016-06-03 22:50, R. David Murray wrote: > > I don't understand how it happened, but apparently I got a merge commit > > backward and merged 3.6 into 3.5 and pushed it without realizing what > > had happened. If

Re: [Python-Dev] Logging Module format

On Sun, 20 Oct 2013 16:34:30 -0700, Hasan Diwan wrote: > I've been using the logging module recently and noticed the default format > doesn't timestamp log entries. I've not figured out how to change the > format after initialization. This is python 2.7, on Mac OS X. Help, anyone? This mailing li

Re: [Python-Dev] Coding practice for context managers

On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman wrote: > On 10/20/2013 07:42 PM, Raymond Hettinger wrote: > > > > In short, I recommend that efforts be directed at improving help() rather > > than limiting introspection by way of less clean coding practices. > > +1 I'm also +1 on improving hel

Re: [Python-Dev] Coding practice for context managers

On Mon, 21 Oct 2013 12:11:57 +0100, Paul Moore wrote: > On 21 October 2013 11:59, R. David Murray wrote: > > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman wrote: > >> On 10/20/2013 07:42 PM, Raymond Hettinger wrote: > >> > > >> > In short, I recom

Re: [Python-Dev] Coding practice for context managers

On Mon, 21 Oct 2013 07:21:11 -0400, "R. David Murray" wrote: > On Mon, 21 Oct 2013 12:11:57 +0100, Paul Moore wrote: > > On 21 October 2013 11:59, R. David Murray wrote: > > > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman > > > wrote: > > >>

Re: [Python-Dev] PEP 455: TransformDict

On Wed, 30 Oct 2013 01:12:03 -0600, Raymond Hettinger wrote: > If I had to choose right now, a safe choice would be to focus on > the primary use case and implement a clean CaseInsensitiveDict > without the double-dict first-saved case-preserving feature. > That said, I find the TD to be fascinat

Re: [Python-Dev] PEP 455: TransformDict

On Wed, 30 Oct 2013 01:12:03 -0600, Raymond Hettinger wrote: > I'm giving a thorough evaluation of the proposal > and am devoting chunks of time each weekend > to reviewing the email threads, the links provided > in the PEPs, looking at how well the TD fits in existing code. > > I'm giving this

Re: [Python-Dev] Contributing to PSF

On Fri, 01 Nov 2013 22:50:28 +0530, Anup Kumar wrote: > My name is Anup. I am pursuing my Enginering degree at Amrita in India. I > want to start contributing to PSF by fixing bugs and if possible by helping > to develop the python software. So, I request some one to help me for that. Welcome, A

[Python-Dev] python2 and python3 and vim

I came across this in the VIM documentation: Vim can be built in four ways (:version output): 1. No Python support(-python, -python3) 2. Python 2 support only(+python or +python/dyn, -python3) 3. Python 3 support only(-python, +python3 or +python3/dyn) 4. Python

Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?

On Mon, 04 Nov 2013 16:34:46 +0100, Antoine Pitrou wrote: > On lun., 2013-11-04 at 16:09 +0100, M.-A. Lemburg wrote: > > On 04.11.2013 11:01, Victor Stinner wrote: > > > Hi, > > > > > > bugs.python.org is still not responding on IPv6. Can someone please > > > remove the record from python.or

Re: [Python-Dev] Issue 19332: Guard against changing dict during iteration

On Wed, 06 Nov 2013 23:34:22 +1100, Steven D'Aprano wrote: > On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote: > > > http://bugs.python.org/issue19332 > > Duplicate of this: http://bugs.python.org/issue6017 > > The conclusion on that also was that it is not worth guarding against >

Re: [Python-Dev] Issue 19332: Guard against changing dict during iteration

On Wed, 06 Nov 2013 16:10:16 +0100, Victor Stinner wrote: > More recently, I added another exception if a dictionary is modified > during a lookup. > > When I proposed a new frozendict type to secure my pysandbox project, > Armin Rigo wrote that CPython segfaults must be fixed. So I fixed a > co

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

On Sun, 17 Nov 2013 17:14:38 +0100, Victor Stinner wrote: > 2013/11/16 Maciej Fijalkowski : > > Can I see some writeup how -OO benefit embedded devices? > > You get smaller .pyc files. In an embedded device, the whole OS may be > written in a small memory, something like 64 MB or smaller. Removi

Re: [Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching

On Tue, 26 Nov 2013 09:30:10 -0800, Eli Bendersky wrote: > Hello, > > argparse does prefix matching as long as there are no conflicts. For > example: > > argparser = argparse.ArgumentParser() > argparser.add_argument('--sync-foo', action='store_true') > args = argparser.parse_args() > > If I pa

Re: [Python-Dev] Add Gentoo packagers of external modules to Misc/ACKS

As far as we have been able to determine, Tae Wong is in fact a bot (note the 'seo' in the email address...a tip of the hand, as far as I can see). We have removed all access permissions (including email) from the related account on the bug tracker already. IMO this address should be blocked from

Re: [Python-Dev] Add Gentoo packagers of external modules to Misc/ACKS

On Mon, 09 Dec 2013 10:22:18 -0500, John Wong wrote: > Looks like a human to me instead, or some kind of smart AI. look he just > responded again. Could be. He's never responded to a direct question on the bug tracker, though, just posts a new comment with some loose connection to the first comm

Re: [Python-Dev] cpython (3.3): Issue #17576: Deprecation warning emitted now when __int__() or __index__()

On Thu, 12 Dec 2013 10:54:05 +0200, Serhiy Storchaka wrote: > 12.12.13 00:24, Antoine Pitrou написав(ла): > > On Wed, 11 Dec 2013 20:28:19 +0100 (CET) > > serhiy.storchaka wrote: > >> http://hg.python.org/cpython/rev/618cca51a27e > >> changeset: 87899:618cca51a27e > >> branch: 3.

Re: [Python-Dev] Default SIGINT handling dangerous?

On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti" wrote: >My scripts replace the default SIGINT/SIGBREAK signal handlers as > soon as possible, and everything works great after that, but things get > ugly if Ctrl-C is pressed before the script gets a chance to do this. I > could even

Re: [Python-Dev] Interested in GSoC 2014

On Tue, 24 Dec 2013 12:11:41 +0530, Prasad Joshi wrote: > I am interested in participating GSoC 2014. I have went through last > year's eligibility criterion, I think I am qualified to participate. I > know GSoC 2014 still has more than 2-3 months, however I would like to > start early. Please le

Re: [Python-Dev] Buildbot running Debian amd64 as root

On Mon, 30 Dec 2013 15:00:02 -0600, Zachary Ware wrote: > On Mon, Dec 30, 2013 at 2:31 PM, Zachary Ware > wrote: > > and we should just fix the tests that expect zlib unconditionally. > > Both of which turned out to be trivial; the import of zlib was already > guarded in both places, but one sk

Re: [Python-Dev] [RELEASED] Python 3.4.0b2

On Sun, 05 Jan 2014 19:32:15 -0800, Bob Hanson wrote: > On Sun, 5 Jan 2014 21:09:53 -0600, Tim Peters wrote: > > So it's just Akamai caching content. Common as mud. Can't say > > specifically what was being cached, but it _could_ be that your ISP > > contracts with Akamai. > > Still not followi

Re: [Python-Dev] [Python-checkins] cpython: whatsnew: XMLPullParser, plus some doc updates.

On Tue, 07 Jan 2014 01:22:21 +1000, Nick Coghlan wrote: > On 5 Jan 2014 12:54, "r.david.murray" wrote: > > > > http://hg.python.org/cpython/rev/069f88f4935f > > changeset: 88308:069f88f4935f > > user:R David Murray > > date:

Re: [Python-Dev] The Great Argument Clinic Conversion Derby is now open!

On Tue, 07 Jan 2014 16:46:59 -0800, Larry Hastings wrote: > > I'm trying to get a huge chunk of work done on Python 3.4 in the next, > oh, week-and-a-half, and I could use your help. I'm trying to convert a > whole bunch of call sites in Python to use "Argument Clinic", a new > build utility

Re: [Python-Dev] Python3 "complexity" (was RFC: PEP 460: Add bytes...)

On Wed, 08 Jan 2014 19:22:08 +, "Matt Billenstein" wrote: > I started in Python blissfully unaware of unicode - it was a different time > for > sure, but what I knew from C worked pretty much the same in Python - I could > read some binary data out of a file, twiddle some bits, and write it b

Re: [Python-Dev] Python3 "complexity" (was RFC: PEP 460: Add bytes...)

On Wed, 08 Jan 2014 22:04:56 +, wrote: > Believe it or not, sometimes you really don't care about encodings. > Sometimes you just want to parse text files. Python 3 forces you to > think about abstract concepts like encodings when all you want is to > open that .txt file on the drive and extr

Re: [Python-Dev] Python3 "complexity" (was RFC: PEP 460: Add bytes...)

On Thu, 09 Jan 2014 00:12:57 +, wrote: > I think there might be a different analogy: Having to specify an > encoding is like having strong typing. In Python 2.7, we _can_ forego > that and just duck-type our strings :) Python is a strongly typed language. Saying that python2 let you duck t

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

tl;dr: At the end I'm volunteering to look at real code that is having porting problems. On Sat, 11 Jan 2014 17:33:17 +0100, "M.-A. Lemburg" wrote: > asciistr is interesting in that it coerces to bytes instead > of to Unicode (as is the case in Python 2). > > At the moment it doesn't cover the m

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Sat, 11 Jan 2014 11:54:26 -0800, Ethan Furman wrote: > On 01/11/2014 11:49 AM, Stephen J. Turnbull wrote: > > MRAB writes: > > > > > > with open("outfile.pdf", "w", encoding="latin-1") as f: > > > > f.write(pdf) > > > > > > > [snip] > > > The second example won't work because you

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Sun, 12 Jan 2014 17:51:41 +1000, Nick Coghlan wrote: > On 12 January 2014 04:38, R. David Murray wrote: > > But! Our goal should be to help people convert to Python3. So how can > > we find out what the specific problems are that real-world programs are > > facing, loo

Re: [Python-Dev] PEP 460 reboot

On Mon, 13 Jan 2014 12:41:18 +0100, Antoine Pitrou wrote: > On Sun, 12 Jan 2014 18:11:47 -0800 > Guido van Rossum wrote: > > On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote: > > > On 01/12/2014 04:47 PM, Guido van Rossum wrote: > > >> %s seems the trickiest: I think with a bytes argument it

Re: [Python-Dev] magic method __bytes__

On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman wrote: > Has anyone actually used __bytes__ yet? What for? bytes(email.message.Message()) returns the message object serialized to "wire format". --David PS: I've always thought of "wire format" as *including* files...a file is a just a "wire" w

Re: [Python-Dev] Byte/text documentation improvements (was: PEP 460 reboot)

On Tue, 14 Jan 2014 11:43:16 -0800, "Jim J. Jewett" wrote: > Greg Ewing replied: > > >> ... ASCII compatible binary data is a > >> *subset* of arbitrary binary data. > > I wrote: > > > But in terms of explaining the text model, that > > separation is important enough that > > >(2) It *ma

Re: [Python-Dev] Binding problem

On Wed, 15 Jan 2014 11:53:05 +1100, "Rob Ward" wrote: > I apologise if I have come to the wrong place here, but 12hrs > searching, plus experimenting, on the WWW for advice on it has not > yielded any successful advice to resolve the issue. This is indeed the wrong place. Your best bet for gett

Re: [Python-Dev] [Python-checkins] cpython: whatsnew: move of reload, update new windows-only ssl functions entry.

On Sat, 01 Feb 2014 13:20:48 -0500, Brett Cannon wrote: > On Sat, Feb 1, 2014 at 12:27 PM, r.david.murray > wrote: > > > http://hg.python.org/cpython/rev/b3f034f5000f > > changeset: 4:b3f034f5000f > > parent: 2:19d81cc213d7 > > user:R David

Re: [Python-Dev] [Python-checkins] cpython: whatsnew: 'U' mode deprecation (#15204).

On Mon, 10 Mar 2014 23:09:53 +1000, Nick Coghlan wrote: > On 10 Mar 2014 11:36, "r.david.murray" wrote: > > > > http://hg.python.org/cpython/rev/2d5544afb510 > > changeset: 89547:2d5544afb510 > > user:R David Murray > > date:

Re: [Python-Dev] Python 3.4 change in importlib/__init__.py breaking cxFreeze?

On Mon, 10 Mar 2014 23:25:17 +1000, Nick Coghlan wrote: > On 10 Mar 2014 19:15, "Jurko Gospodnetić" wrote: > > > > Hi all. > > > > Python 3.4 introduced a change to Lib/importlib/__init__.py that added > the following code to it: > > > >> else: > >> # importlib._bootstrap is the built-in

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

On Mon, 10 Mar 2014 16:06:22 -, Brett Cannon wrote: > On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner > wrote: > > > 2014-03-10 16:25 GMT+01:00 Stefan Richthofer : > > > I don't see the point in this discussion. > > > As far as I know, the major version is INTENDED to > > > indicate backwa

Re: [Python-Dev] undocumented help() function change in Python 3.4?

On Mon, 10 Mar 2014 14:15:28 +0100, =?UTF-8?B?SnVya28gR29zcG9kbmV0acSH?= wrote: >Hi. > > On 8.3.2014. 6:48, Nick Coghlan wrote: > > Yeah, the changes to help() are doubly indirect - help() uses pydoc > > which uses inspect, and inspect saw a lot of changes. > > > > I'll make a few updates to

[Python-Dev] Whats New in 3.4 is pretty much done...

Well, I think What's New for 3.4 is done. I've been through all of the NEWS items from the start of 3.4 through the beta1 release. I've gone over the list of changes Serhiy found via the versionadded/versionchanged in the docs. (Since he marked some that didn't turn out to be 3.4 changes, I assu

Re: [Python-Dev] undocumented help() function change in Python 3.4?

On Tue, 11 Mar 2014 10:15:21 +0100, Georg Brandl wrote: > Am 11.03.2014 08:00, schrieb Ned Deily: > > In article , > > Georg Brandl wrote: > > > >> Am 11.03.2014 06:31, schrieb Ned Deily: > >> > In article > >> > , > >> > Ni

Re: [Python-Dev] undocumented help() function change in Python 3.4?

On Tue, 11 Mar 2014 19:57:36 +0100, Georg Brandl wrote: > Am 11.03.2014 15:54, schrieb Guido van Rossum: > > I'm not sure I agree completely with this lax attitude about the contents > > of the > > docs, and especially the What's New parts of it (both Misc/NEWS and > > Doc/whatsnew/3.4.rst). > >

Re: [Python-Dev] Why not make frames? [was: Alternative forms [was: PEP 463: Exception-catching expressions]]

On Mon, 10 Mar 2014 14:26:14 +1100, Chris Angelico wrote: > On Mon, Mar 10, 2014 at 1:16 PM, Jim J. Jewett wrote: > > I don't claim that syntax is perfect. I do think it is less flawed > > than the no-parentheses (or external parentheses) versions: > > > > (expr1 except expr3 if expr2) > >

Re: [Python-Dev] Whats New in 3.4 is pretty much done...

On Thu, 13 Mar 2014 15:23:14 -0500, "Andrew M. Hettinger" wrote: > Antoine Pitrou wrote on 03/13/2014 01:46:12 PM: > > On Thu, 13 Mar 2014 14:57:41 +0100 > > Victor Stinner wrote: > > > 2014-03-13 11:49 GMT+01:00 Christian Heimes : > > > > * All stdlib modules now support server cert verificati

[Python-Dev] Confirming status of new modules in 3.4

I just want to summarize the status of the modules that have been added to the stdlib in 3.4 to make sure they are all labeled correctly: Provisional: asyncio pathlib Not Provisional: ensurepip enum selectors statistics tracemalloc I'm especially curious about tracemalloc, since I know Victor

Re: [Python-Dev] unit tests for error messages

On Wed, 19 Mar 2014 20:32:38 +0100, Georg Brandl wrote: > Am 19.03.2014 19:55, schrieb Antoine Pitrou: > > On Wed, 19 Mar 2014 10:53:31 -0700 > > Ethan Furman wrote: > > > >> I just made a change to some error messages [1] (really, just one): > >> > >> old behavior: > >> > >>'%o' % 3.14 >

Re: [Python-Dev] unittest assertRaisesRegex bug?

On Wed, 19 Mar 2014 16:41:10 -0700, Thomas Wouters wrote: > On Wed, Mar 19, 2014 at 4:13 PM, Ethan Furman wrote: > > > On 03/19/2014 03:57 PM, Antoine Pitrou wrote: > > > >> On Wed, 19 Mar 2014 15:17:53 -0700 > >> Ethan Furman wrote: > >> > >>> On 03/19/2014 03:13 PM, Antoine Pitrou wrote: > >>

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