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

On Wed, Apr 13, 2016, at 23:27, Nick Coghlan wrote: > In this kind of case, inheritance tends to trump protocol. For > example, int subclasses can't override operator.index: ... > The reasons for that behaviour are more pragmatic than philosophical: > builtins and their subclasses are extensively

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016, at 23:17, Nick Coghlan wrote: > - os.fspath -> str (no coercion) > - os.fsdecode -> str (with coercion from bytes) > - os.fsencode -> bytes (with coercion from str) > - os._raw_fspath -> str-or-bytes (no coercion) > > (with "coercion" referring to how the result of

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

On 14 April 2016 at 13:14, Ethan Furman wrote: > On 04/13/2016 07:57 PM, Nikolaus Rath wrote: >> Either I haven't understood your answer, or you haven't understood my >> question. I'm concerned about this case: >> >>class Special(bytes): >>def __fspath__(self): >>

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 12:49, Nick Coghlan wrote: > The API could be something like: > > - os.fspath -> str-or-bytes > - os.fsencode -> bytes (with coercion from str) > - os.fsdecode -> str (with coercion from bytes) > - os.strpath -> str (no coercion) There seems to be fairly

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

On 04/13/2016 07:57 PM, Nikolaus Rath wrote: On Apr 13 2016, Ethan Furman wrote: On 04/13/2016 03:45 PM, Nikolaus Rath wrote: When passing an object that is of type str and has a __fspath__ attribute, all approaches return the value of __fspath__(). However, when passing something of type

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

On 14 April 2016 at 08:26, Victor Stinner wrote: > 2016-04-14 0:11 GMT+02:00 Ryan Gonzalez : >> So code that depends on iterating through bytecode via HAS_ARG is going to >> break... > > Sure. This change is backward incompatible for applications

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

On Apr 13 2016, Ethan Furman wrote: > On 04/13/2016 03:45 PM, Nikolaus Rath wrote: > >> When passing an object that is of type str and has a __fspath__ >> attribute, all approaches return the value of __fspath__(). >> >> However, when passing something of type bytes, the

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 07:37, Victor Stinner wrote: > Le mercredi 13 avril 2016, Brett Cannon a écrit : >> >> All of this is demonstrated in >> https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 by the >> various possibilities. In the

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

On Apr 13, 2016 19:06, Brett Cannon wrote: > On Wed, 13 Apr 2016 at 15:46 Nikolaus Rath wrote: >> When passing an object that is of type str and has a __fspath__ >> attribute, all approaches return the value of __fspath__(). >> >> However, when passing

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

On Apr 13, 2016 20:06, Chris Barker wrote: > > In this case, I don't know that we need to be tolerant of buggy __fspathname__() implementations -- they should be tested outside these checks, and not be buggy. So a buggy implementation may raise and may be ignored,

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

On 04/13/2016 05:06 PM, Chris Barker wrote: In this case, I don't know that we need to be tolerant of buggy __fspathname__() implementations -- they should be tested outside these checks, and not be buggy. So a buggy implementation may raise and may be ignored, depending on what Exception the

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

On Wed, Apr 13, 2016 at 1:47 PM, Random832 wrote: > On Wed, Apr 13, 2016, at 16:39, Chris Barker wrote: > > so are we worried that __fspath__ will exist and be callable, but might > > raise an AttributeError somewhere inside itself? if so isn't it broken > > anyway, so

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

On Wed, 13 Apr 2016 at 15:20 Victor Stinner wrote: > Oh, since others voted, I will also vote and explain my vote. > > I like choice 1, str only, because it's very well defined. In Python > 3, Unicode is simply the native type for text. It's accepted by almost > all

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

On Wed, 13 Apr 2016 at 15:46 Nikolaus Rath wrote: > On Apr 13 2016, Brett Cannon wrote: > > On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < > > python-dev@python.org> wrote: > > > >> Ethan Furman stoneleaf.us> writes: > >> > >> > Do we allow

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

On 04/13/2016 03:45 PM, Nikolaus Rath wrote: When passing an object that is of type str and has a __fspath__ attribute, all approaches return the value of __fspath__(). However, when passing something of type bytes, the second approach returns the object, while the third returns the value of

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

On Apr 13 2016, Brett Cannon wrote: > On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < > python-dev@python.org> wrote: > >> Ethan Furman stoneleaf.us> writes: >> >> > Do we allow bytes to be returned from os.fspath()? If yes, then do we >> > allow bytes from

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

On 2016-04-13 12:24 PM, Victor Stinner wrote: Can someone please review the change? +1 for the change. I can take a look at the patch in a few days. Yury ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

2016-04-14 0:11 GMT+02:00 Ryan Gonzalez : > So code that depends on iterating through bytecode via HAS_ARG is going to > break... Sure. This change is backward incompatible for applications parsing bytecode in C or Python. That's why the patch also has to update the dis module.

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

Oh, since others voted, I will also vote and explain my vote. I like choice 1, str only, because it's very well defined. In Python 3, Unicode is simply the native type for text. It's accepted by almost all functions. In other emails, I also explained that Unicode is fine to store undecodable

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

So code that depends on iterating through bytecode via HAS_ARG is going to break... Darn it. :/ -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Apr 13, 2016 4:44 PM, "Victor Stinner"

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

Le mercredi 13 avril 2016, Ryan Gonzalez a écrit : > What is the value of HAS_ARG going to be now? > I asked Demur to keep HAS_ARG(). Not really for backward compatibility, but for the dis module: to keep a nice assembler. There are also debug traces in ceval.c which use it.

[Python-Dev] Tag-based buildmaster (was: Most 3.x buildbots are green again ... )

(Cross-posting to python-buildbots, discussion is probably best continued there) On Wed, Apr 13, 2016 at 3:37 PM, Brett Cannon wrote: > On Wed, 13 Apr 2016 at 13:17 Zachary Ware > wrote: >> After receiving a suggestion from koobs several months

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Oops sorry, I forgot to add that I have no strong opinion on the type (I only have a minor preference for str only). Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Le mercredi 13 avril 2016, Brett Cannon a écrit : > > All of this is demonstrated in > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 by > the various possibilities. In the end it's not a corner case because the > definition of __fspath__ will be such that

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

The EXTENDED_ARG is included in the multibyte ops, I treat it just like any other operator. Here's a snippet of my hacked-dis.dis output, which made it clear to me that I could just count them as an "operator with word operand." Line 3000: x = x if x or not x and x is None else x 0001dc83 7c 00

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

What is the value of HAS_ARG going to be now? -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Apr 13, 2016 11:26 AM, "Victor Stinner" wrote: > Hi, > > In the middle of recent

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

2016-04-13 23:02 GMT+02:00 Eric Fahlgren : > Percentage of 1-byte args= 96.80% Yeah, I expected such high ratio. Good news that you confirm it. > Non-argument ops =53,719 > One-byte args= 368,787 > Multi-byte args =

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

On Wednesday, April 13, 2016 09:25, Victor Stinner wrote: > The side effect of wordcode is that arguments in 0..255 now uses 2 bytes per > instruction instead of 3, so it also reduce the size of bytecode for the most > common case. > > Larger argument, 16-bit argument (0..65,535), now uses 4

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

On Wed, Apr 13, 2016, at 16:39, Chris Barker wrote: > so are we worried that __fspath__ will exist and be callable, but might > raise an AttributeError somewhere inside itself? if so isn't it broken > anyway, so should it be ignored? Well, if you're going to say "ignore the protocol because it's

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

On Wed, 13 Apr 2016 at 13:40 Chris Barker wrote: > so are we worried that __fspath__ will exist and be callable, but might > raise an AttributeError somewhere inside itself? if so isn't it broken > anyway, so should it be ignored? > It should propagate instead of

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

so are we worried that __fspath__ will exist and be callable, but might raise an AttributeError somewhere inside itself? if so isn't it broken anyway, so should it be ignored? and I know it's asking poermission rather than forgiveness, but what's wrong with: if hasattr(path, "__fspath__"):

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Wed, 13 Apr 2016 at 13:17 Zachary Ware wrote: > [SNIP] > --- > > After receiving a suggestion from koobs several months ago, I've been > intermittently thinking about completely redoing our buildmaster setup > such that instead of a single builder per version on

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Wed, Apr 13, 2016 at 6:40 AM, Victor Stinner wrote: > Hi, > > Last months, most 3.x buildbots failed randomly. Some of them were > always failing. I spent some time to fix almost all Windows and Linux > buildbots. There were a lot of different issues. Thank you for

Re: [Python-Dev] List posting custom [was: current status of discussions]

On Wed, Apr 13, 2016 at 5:56 AM, Stephen J. Turnbull wrote: > The following is my opinion, as will become obvious, but it's based on > over a decade of observing these lists, and other open source > development lists. In a context where some core developers have >

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

On Wed, 13 Apr 2016 at 12:39 Fred Drake wrote: > On Wed, Apr 13, 2016 at 3:24 PM, Chris Angelico wrote: > > Is that the intention, or should the exception catching be narrower? I > > know it's clunky to write it in Python, but AIUI it's less so in C: > > > >

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

On Thu, Apr 14, 2016 at 5:46 AM, Random832 wrote: > On Wed, Apr 13, 2016, at 15:24, Chris Angelico wrote: >> Is that the intention, or should the exception catching be narrower? I >> know it's clunky to write it in Python, but AIUI it's less so in C: > > How is it less so

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

On Wed, Apr 13, 2016, at 15:24, Chris Angelico wrote: > Is that the intention, or should the exception catching be narrower? I > know it's clunky to write it in Python, but AIUI it's less so in C: How is it less so in C? You lose the ability to PyObject_CallMethod.

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

On 4/13/2016 13:49, Ethan Furman wrote: Number 3: it allows bytes, but only when told it's okay to do so. Having code get a bytes object when one is not expected is not a headache we need to inflict on anyone. This is an artifact of the other needless restrictions I said I wouldn't rant

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

On Thu, Apr 14, 2016 at 5:30 AM, Brett Cannon wrote: > > > On Wed, 13 Apr 2016 at 12:25 Chris Angelico wrote: >> >> On Thu, Apr 14, 2016 at 3:10 AM, Brett Cannon wrote: >> >

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

On Wed, Apr 13, 2016 at 3:24 PM, Chris Angelico wrote: > Is that the intention, or should the exception catching be narrower? I > know it's clunky to write it in Python, but AIUI it's less so in C: > > try: > callme = path.__fspath__ > except AttributeError: > pass >

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

On Wed, 13 Apr 2016 at 12:25 Chris Angelico wrote: > On Thu, Apr 14, 2016 at 3:10 AM, Brett Cannon wrote: > > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 > has the > > four potential approaches implemented (although it doesn't follow

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

On Thu, Apr 14, 2016 at 3:10 AM, Brett Cannon wrote: > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the > four potential approaches implemented (although it doesn't follow the > "separate functions" approach some are proposing and instead goes with

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

Brett Cannon python.org> writes: > In the spirit of Python 3 I feel like bytes might not be needed in practice, > but something like this with defaults of False will allow people to easily > test all the various options. > > > >

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

On 04/13/2016 10:22 AM, Alexander Walters wrote: On 4/13/2016 13:10, Brett Cannon wrote: https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the four potential approaches implemented (although it doesn't follow the "separate functions" approach some are proposing and

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

On 4/13/2016 13:10, Brett Cannon wrote: https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the four potential approaches implemented (although it doesn't follow the "separate functions" approach some are proposing and instead goes with the allow_bytes approach I

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, 13 Apr 2016 at 09:52 Random832 wrote: > On Wed, Apr 13, 2016, at 11:28, Ethan Furman wrote: > > On 04/13/2016 08:17 AM, Random832 wrote: > > > On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote: > > > > >> I'd expect the main consumers to be os and os.path, and

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

On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < python-dev@python.org> wrote: > Ethan Furman stoneleaf.us> writes: > > > Do we allow bytes to be returned from os.fspath()? If yes, then do we > > allow bytes from __fspath__()? > > De-lurking. Especially since the ultimate goal is

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 09:58 AM, Brett Cannon wrote:> On Wed, 13 Apr 2016 at 09:19 Fred Drake wrote: >> I do the same, but... this is one of those cases where a caller will >> usually be passing a constant directly. If passed as a positional >> argument, it'll just be confusing ("what's True?" is my

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Apr 13 2016, Ethan Furman wrote: > (I'm not very good at keeping similar sounding functions separate -- > what's the difference between shutil.copy and shutil.copy2? I have to > look it up every time). Well, "2" is more than "" (or 1), so copy2() copies *more* than copy()

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, 13 Apr 2016 at 09:19 Fred Drake wrote: > On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote: > > - a single os.fspath() with an allow_bytes parameter > > (mostly True in os and os.path, mostly False everywhere > > else) > > -0 > > > - a

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016, at 11:28, Ethan Furman wrote: > On 04/13/2016 08:17 AM, Random832 wrote: > > On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote: > > >> I'd expect the main consumers to be os and os.path, and would honestly > >> be surprised if we needed many explicit invocations above that

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Wed, 13 Apr 2016 at 06:14 Stefan Krah wrote: > Victor Stinner gmail.com> writes: > > Maybe it's time to move more 3.x buildbots to the "stable" category? > > http://buildbot.python.org/all/waterfall?category=3.x.stable > > +1 I think anything that is actually stable

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 13 April 2016 at 17:31, Ethan Furman wrote: > On 04/13/2016 09:27 AM, Paul Moore wrote: >> >> On 13 April 2016 at 17:18, Fred Drake wrote: > > >>> Names like os.fspath() and os.fssyspath() seem good to me. >> >> >> -1 on fssyspath - the "system" representation is bytes on

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Wed, 13 Apr 2016 at 05:57 Tim Golden wrote: > On 13/04/2016 12:40, Victor Stinner wrote: > > Last months, most 3.x buildbots failed randomly. Some of them were > > always failing. I spent some time to fix almost all Windows and Linux > > buildbots. There were a lot of

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 09:27 AM, Paul Moore wrote: On 13 April 2016 at 17:18, Fred Drake wrote: Names like os.fspath() and os.fssyspath() seem good to me. -1 on fssyspath - the "system" representation is bytes on POSIX, but not on Windows. Let's be explicit and go with fsbytespath(). It will be

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

Nice work. I think that for CPython, speed is much more important than memory use for the code. Disk space is practically free for anything smaller than a video. :-) On Wed, Apr 13, 2016 at 9:24 AM, Victor Stinner wrote: > Hi, > > In the middle of recent discussions

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 09:18 AM, Fred Drake wrote: On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote: - a single os.fspath() with an allow_bytes parameter (mostly True in os and os.path, mostly False everywhere else) -0 - a str-only os.fspathname() and a str/bytes os.fspath() +1 on using

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016 at 12:27 PM, Paul Moore wrote: > -1 on fssyspath - the "system" representation is bytes on POSIX, but > not on Windows. Let's be explicit and go with fsbytespath(). Depends on the semantics; if we're expecting it to return str-or-bytes, os.fssyspath()

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 13 April 2016 at 17:18, Fred Drake wrote: > Names like os.fspath() and os.fssyspath() seem good to me. -1 on fssyspath - the "system" representation is bytes on POSIX, but not on Windows. Let's be explicit and go with fsbytespath(). But agreed that always-constant boolean

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

Glad it's working again! And it was a combination or R. David Murray, Ezio Melotti, Mark Mangoba ( http://pyfound.blogspot.com/2016/04/the-psf-has-hired-it-manager.html in case you don't know who Mark is), and myself along with Upfront (b.p.o hosting provider). On Tue, 12 Apr 2016 at 21:40 Terry

[Python-Dev] Wordcode: new regular bytecode using 16-bit units

Hi, In the middle of recent discussions about Python performance, it was discussed to change the Python bytecode. Serhiy proposed to reuse MicroPython short bytecode to reduce the disk space and reduce the memory footprint. Demur Rumed proposes a different change to use a regular bytecode using

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote: > - a single os.fspath() with an allow_bytes parameter > (mostly True in os and os.path, mostly False everywhere > else) -0 > - a str-only os.fspathname() and a str/bytes os.fspath() +1 on using separate functions.

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 08:17 AM, Random832 wrote: On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote: I'd expect the main consumers to be os and os.path, and would honestly be surprised if we needed many explicit invocations above that layer, other than in pathlib itself. I made a toy implementation

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote: > I'd expect the main consumers to be os and os.path, and would honestly > be surprised if we needed many explicit invocations above that layer, > other than in pathlib itself. I made a toy implementation to try this out, and making os.open

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 07:21 AM, Nick Coghlan wrote: On 14 April 2016 at 00:11, Paul Moore wrote: On 13 April 2016 at 14:51, Nick Coghlan wrote: The potential SE-strings only come back when you pass str, and the operating system data isn't properly encoded according to the nominal filesystem

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 00:11, Paul Moore wrote: > On 13 April 2016 at 14:51, Nick Coghlan wrote: >> The potentially SE-strings only come back when you pass str, and the >> operating system data isn't properly encoded according to the nominal >> filesystem

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 13 April 2016 at 14:51, Nick Coghlan wrote: > The potentially SE-strings only come back when you pass str, and the > operating system data isn't properly encoded according to the nominal > filesystem encoding. They round trip nicely to other operating system > APIs, but can

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

On 13 April 2016 at 02:19, Chris Barker wrote: > So: why use strings as the lingua franca of paths? i.e. the basis of the > path protocol. maybe we should support only two path representations: > > 1) A "proper" path object -- i.e. pathlib.Path or anything else that >

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 13 April 2016 at 02:15, Ethan Furman wrote: > On 04/11/2016 04:43 PM, Victor Stinner wrote: >> >> Le 11 avr. 2016 11:11 PM, "Ethan Furman" a écrit : > > >>> So my concern in such a case is what happens if we pass this SE >>> string somewhere else: a UTF-8 file, or over a

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

Victor Stinner gmail.com> writes: > Maybe it's time to move more 3.x buildbots to the "stable" category? > http://buildbot.python.org/all/waterfall?category=3.x.stable +1 I think anything that is actually stable should be in that category. > By the way, I don't understand why "AMD64

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On 13/04/2016 12:40, Victor Stinner wrote: > Last months, most 3.x buildbots failed randomly. Some of them were > always failing. I spent some time to fix almost all Windows and Linux > buildbots. There were a lot of different issues. Can I state the obvious and offer a huge vote of thanks for

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On 4/13/2016 7:40 AM, Victor Stinner wrote: > Last months, most 3.x buildbots failed randomly. Some of them were > always failing. I spent some time to fix almost all Windows and Linux > buildbots. There were a lot of different issues. Thanks for all of your work on this, Victor. It's much

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Wed, Apr 13, 2016 at 9:40 PM, Victor Stinner wrote: > Maybe it's time to move more 3.x buildbots to the "stable" category? > http://buildbot.python.org/all/waterfall?category=3.x.stable Move the Bruces into stable, perhaps? The AMD64 Debian Root one. Been fairly

[Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

Hi, Last months, most 3.x buildbots failed randomly. Some of them were always failing. I spent some time to fix almost all Windows and Linux buildbots. There were a lot of different issues. So please try to not break buildbots again and remind to watch them sometimes: