On 14 April 2016 at 14:05, Random832 wrote:
> 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 philosophica
On 14 April 2016 at 13:54, Random832 wrote:
> 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)
>>
>> (wit
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 s
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 __fspath_
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):
>> return 'str-
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 broad opposition to th
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 by
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 parsing
> bytecode in C or Python. That's why the p
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 second approach
>> returns
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 end it's not a corner case because the
>> defin
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 something of type bytes, the second approac
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, depending on what Exception the
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 bu
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 should it be ignored?
>
>
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 functions. In other emails, I
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 bytes to be returned from os.fspath()?
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 __
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 __fspath__()?
>>
>> De-
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
https://mail.python.org/mailman/listinfo/py
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.
I don't see how yo
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 filen
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" wrote:
> Le mercredi 13
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.
For ceval.c, we mig
(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 ago, I've been
>> intermittently thinking about com
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:
https://mail.p
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 there's no ambiguit
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 0
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 discussions about Python perform
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 =12,191
Again, only a very
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 bytes
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
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 swallowing up the exception, ot
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__"):
p
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 each slave, we
> instead set up
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 doing this!
> Maybe it's ti
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
> unsubscribed from these lists, a
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:
> >
> > try:
> > callme = path.__fspath__
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 in C? You lose the abilit
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.
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 abou
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:
>> > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has
>> > the
>> > four potential approaches implement
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
> else:
> path = cal
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 the
> > "separate functions" approach
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 the
> allow_bytes app
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.
>
>
>
> https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869a
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
inste
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 originally
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 would honestly
> > >> be su
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 b
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 usua
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() -
it includes the me
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 str-only os.fspathname() and a str/bytes os.f
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 l
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 should be in that category
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 POSIX, but
>> not on W
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 different issues.
>
> Can
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 con
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 about Python performance, it w
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 s
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() seems fine. If only ret
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 parameters are a bad
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 R
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 1
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.
> I'm partial to the
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
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 suppo
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 encoding.
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 encoding. They round trip nicely to other op
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 indeed be a problem
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
> supports the path protocol.
>
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 socket, or into a
>>> d
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 OpenIndiana
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 thi
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 appreci
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 consistently green.
ChrisA
___
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:
http://buildbot.python.o
76 matches
Mail list logo
