On 12/05/2013 06:08 PM, Allen Li wrote:
On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote:
Actually if you want to support multiple inheritance of your ABC, your
abstract methods *must* be no-ops (or have some kind of default
behavior that can always be done last).
Done last or
On 12/09/2013 11:52 AM, Allen Li wrote:
Pros:
Save a lot of lines defining interface-like ABCs, especially in small
scripts without docstrings (bad practice, but I do it often =))
If the only pro is encouraging bad practice, it's not going to happen. ;)
Cons:
Do we need it?
In my opinion,
On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
Oh, yes, a %T shortcut for "length limited type name of the supplied
object" would be brilliant. We need this frequently for C level error
messages, and I almost always have to look at a
On 12/18/2013 08:54 AM, Tim Peters wrote:
Which reminds me. I used to think there was no such thing as a stupid
question. Then I discovered Stack Overflow ;-)
+1 QOTW
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
Greetings!
I'm working on Issue19995, and I'm seeing stuff like this:
assert(PyLong_Check(val));
My question is: Are these asserts in final production code?
My possible scenarios are:
- the assert isn't in place
- the assert isn't working correctly
- PyLong_Check isn't working correc
On 01/04/2014 08:20 PM, John Yeuk Hon Wong wrote:
I think it helps Luca and many others (including myself) if there is a
reference of the difference between 2.7 and
Python 3.3+.
Here's another reference:
http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/promotions/python/python2pytho
On 01/05/2014 06:02 PM, Bob Hanson wrote:
I'm presuming, still, that it is something to do with the "ensure
that pip is present on Windows" thing?
Perhaps you could help us out by telling us what site was trying to be accessed?
--
~Ethan~
___
Python
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be
#included'd into the main module file
-1 (Guido has stated a strong dislike for this method)
- gather all generated code to a single place in the C module file, for
exampl
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be
#included'd into the main module file
-1 (Guido has stated a s
On 01/07/2014 12:39 PM, Serhiy Storchaka wrote:
07.01.14 21:53, Antoine Pitrou написав(ла):
- move all generated code to separate C files, which would then be
#included'd into the main module file
Only this option will solve all my issues.
My arguments against current behavior:
[snip]
On 01/07/2014 01:04 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:33:11 -0800
Ethan Furman wrote:
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C
On 01/08/2014 02:28 AM, Antoine Pitrou wrote:
On Wed, 8 Jan 2014 11:02:19 +0100
Victor Stinner wrote:
What does b'%s' % 7 do?
See Examples of the PEP:
b'a%sc%s' % (b'b', 4) gives b'abc4'
[...]
And then what? Use the "default" encoding? ASCII?
Bytes have no encoding. There are just byte
On 01/09/2014 03:39 AM, Serhiy Storchaka wrote:
07.01.14 22:51, Ethan Furman написав(ла):
AFAIK you don't write much C code. So perhaps C sources maintainability is not
too valuable for you.
I don't write much C code yet, no, but C source maintainability is even more important to
On 01/09/2014 02:00 PM, Chris Barker wrote:
On Thu, Jan 9, 2014 at 1:45 PM, Antoine Pitrou wrote:
Chris Barker wrote:
latin-1 guaranteed to work with any binary data, and round-trip accurately?
Yes, it is.
and will surrogateescape work for arbitrary binary data?
Yes, it will.
Then ma
On 01/09/2014 02:54 PM, Paul Moore wrote:
On 9 January 2014 22:08, Ethan Furman wrote:
For example: b'\x01\x00\xd1\x80\xd1\83\xd0\x80'
If that were decoded using latin1 how would I then get the first two bytes
to the integer 256 and the last six bytes to their Cyrillic meaning?
On 01/09/2014 02:54 PM, Paul Moore wrote:
On 9 January 2014 22:08, Ethan Furman wrote:
For example: b'\x01\x00\xd1\x80\xd1\83\xd0\x80'
If that were decoded using latin1 how would I then get the first two bytes
to the integer 256 and the last six bytes to their Cyrillic meaning?
On 01/10/2014 02:42 PM, Antoine Pitrou wrote:
On Fri, 10 Jan 2014 17:33:57 -0500
"Eric V. Smith" wrote:
On 1/10/2014 5:29 PM, Antoine Pitrou wrote:
On Fri, 10 Jan 2014 12:56:19 -0500
"Eric V. Smith" wrote:
I agree. I don't see any reason to exclude int and float. See Guido's
messages http:/
On 01/10/2014 03:22 PM, Mark Lawrence wrote:
On 10/01/2014 22:06, Chris Barker wrote:
I'm not so sure -- it could be used (abused?) for that, but I'm
suggesting it be used for mixed ascii-binary data. I don't know that
there IS a "right" way to do that -- at least not an efficient or easy
to re
On 01/08/2014 02:42 PM, Antoine Pitrou wrote:
With Victor's consent, I overhauled PEP 460 and made the feature set
more restricted and consistent with the bytes/str separation.
From the PEP:
=
Python 3 generally mandates that text be stored and manipulated as
unicode (i.e. str ob
On 01/10/2014 06:04 PM, Antoine Pitrou wrote:
On Fri, 10 Jan 2014 20:53:09 -0500
"Eric V. Smith" wrote:
So, I'm -1 on the PEP. It doesn't address the cases laid out in issue
3892. See for example http://bugs.python.org/issue3982#msg180432 .
Then we might as well not do anything, since any at
On 01/10/2014 06:39 PM, Antoine Pitrou wrote:
On Fri, 10 Jan 2014 18:28:41 -0800
Ethan Furman wrote:
Is it safe to assume you don't use Python for the use-cases under discussion?
You know, I've done quite a bit of network programming.
No, I didn't, that's why I asked.
On 01/10/2014 06:39 PM, Antoine Pitrou wrote:
I know what a network protocol with ill-defined encodings
looks like.
For the record, I've been (and I suspect Eric and some others have also been) talking about well-defined encodings. For
the DBF files that I work with, there is binary, ASCII,
On 01/11/2014 07:38 AM, Steven D'Aprano wrote:
The point that I am making is that many people want to add formatting
operations to bytes so they can put ASCII strings inside bytes. But (as
far as I can tell) they don't need to do this, because they can treat
Unicode strings containing code point
On 01/11/2014 12:43 AM, Nick Coghlan wrote:
In particular, the bytes type is, and always will be, designed for
pure binary manipulation [...]
I apologize for being blunt, but this is a lie.
Lets take a look at the methods defined by bytes:
dir(b'')
['__add__', '__class__', '__contains__', '
On 01/11/2014 07:34 AM, Nick Coghlan wrote:
On 12 January 2014 01:15, M.-A. Lemburg wrote:
We don't have to be pedantic about the bytes/text separation.
It doesn't help in real life.
Yes, it bloody well does. The number of people who have told me that
using Python 3 is what allowed them to fi
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner wrote:
If you agree, I will modify the PEP. If Antoine disagree, I will fork
the PEP 460 ;-)
Please fork it.
You've already stated you don't care that much and are willing to let the PEP as-is b
On 01/11/2014 10:36 AM, Steven D'Aprano wrote:
On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
unicode to bytes
bytes to unicode using latin1
unicode to bytes
Where do you get this from? I don't follow your logic. Start with a text
template:
template = "
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 forgetting about the
> handling of line endings in text mode.
Not so fast! F
On 01/11/2014 11:22 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 10:38:01 -0800
Ethan Furman wrote:
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner wrote:
If you agree, I will modify the PEP. If Antoine disagree, I will fork
the PEP 460
On 01/11/2014 12:45 PM, Donald Stufft wrote:
FWIW as one of the people who it took Python3 to finally figure out how to
actually use unicode, it was the absence of encode on bytes and decode on
str that actually did it. Giving bytes a format method would not have affected
that either way I don’t
The docs say this [1]:
==
test.support.check_warnings(*filters, quiet=True)
A convenience wrapper for warnings.catch_warnings() that makes it easier to test that a warning was correctly
raised. It is approximately equivalent to calling
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner wrote:
b'x=%s' % 10 is well defined, it's pure bytes.
It is well-defined? Then please explain me what the general case of
b'%s' % x
is supposed to call:
This is the key question, isn't it?
On 01/11/2014 05:20 PM, Terry Reedy wrote:
The following function . . .
Thanks, Terry, for doing that.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.
On 01/11/2014 06:29 PM, Steven D'Aprano wrote:
On Sat, Jan 11, 2014 at 11:05:36AM -0800, Ethan Furman wrote:
On 01/11/2014 10:36 AM, Steven D'Aprano wrote:
On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
unicode to bytes
bytes to unicode using latin1
unicod
On 01/11/2014 05:37 PM, Brett Cannon wrote:
You're assuming the context manager is doing something magical to verify that
all calls in the block raise the expected
exception. What you want to do is execute it in a loop::
for test in (...):
with support.check_warnings(("automatic int co
On 01/12/2014 04:24 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 23:10:43 -0800
Ethan Furman wrote:
On 01/11/2014 05:37 PM, Brett Cannon wrote:
You're assuming the context manager is doing something magical to verify that
all calls in the block raise the expected
exception. What you
On 01/12/2014 08:09 AM, Nick Coghlan wrote:
On 13 Jan 2014 01:22, "Kristján Valur Jónsson" wrote:
Imho, this is not equivalent to re-introducing automatic type conversion
between binary/unicode, it is adding a specific convenience function for
explicitly asking for ASCII encoding.
It is not
On 01/12/2014 08:21 AM, Ethan Furman wrote:
On 01/12/2014 08:09 AM, Nick Coghlan wrote:
On 13 Jan 2014 01:22, "Kristján Valur Jónsson" wrote:
Imho, this is not equivalent to re-introducing automatic type conversion
between binary/unicode, it is adding a
specific convenience fu
On 01/12/2014 09:26 AM, Paul Moore wrote:
On 12 January 2014 17:03, Ethan Furman wrote:
We know full well the difference between unicode and bytes, and we know full
well that numbers and much of the text we need has an ASCII (bytes!)
representation. When we do a b'Content Length: %d&#
On 01/11/2014 07:09 PM, Nick Coghlan wrote:
Folks that want implicit serialisation (and I agree it has its uses) should go
help Benno get asciistr up to speed.
asciistr is not what I'm looking for in the way of a boundary type.
I have created a 'bytestring'[1] repository which has the tests
On 01/12/2014 11:00 AM, Paul Moore wrote:
And yet I still don't follow what you *want*. Unless it's that b'%d' %
(12,) must work and give b'12', and nothing else is acceptable.
Nothing else is ideal. I'll go that route if I have to. I understand that in the real world you go with what works,
On 01/12/2014 12:02 PM, Stephen J. Turnbull wrote:
Georg Brandl writes:
Antoine writes:
. . . if it weren't for your stupid maximalist opposition. . .
Can you please stop throwing personal insults around? You don't have to
resort to that level.
Ethan's posts (as an example of one general
On 01/12/2014 12:39 PM, Stephen J. Turnbull wrote:
Daniel Holth writes:
> -1 on adding more surrogateesapes by default. It's a pain to track
> down where the encoding errors came from.
What do you mean "by default"? It was quite explicit in the code I
posted, and it's the only reasonable t
On 01/12/2014 01:06 PM, Greg Ewing wrote:
Paul Moore wrote:
I could easily argue at this point that this is the type of bug that
having %-formatting operations on bytes would encourage - %s means
"format a string" (from years of C and Python (text) experience) so I
automatically supply a string
On 01/12/2014 01:37 PM, Kristján Valur Jónsson wrote:
Right.
I'm saying, let's support two interpolators only:
%b interpolates a bytes object (or one supporting the charbuffer interface)
into a bytes object.
%s interpolates a str object by first converting to a bytes object using strict
ascii c
On 01/12/2014 01:59 PM, Mark Shannon wrote:
Why not just use six.byte_format(fmt, *args)?
It works on both Python2 and Python3 and accepts the numerical format
specifiers, plus '%b' for inserting bytes and '%a'
for converting text to ascii.
Sounds like the second best option!
Admittedly it
On 01/12/2014 02:31 PM, Stephen J. Turnbull wrote:
This corrupts binary_image_data. Each byte > 127 will be replaced by
two bytes. In the second case, you can use latin1 to encode, it it
gives you what you want.
This kind of subtlety is precisely why MAL warned about use of latin1
to smuggle
On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
Nothing else is ideal. I'll go that route if I have to. I
understand that in the real world you go with what works, but in
the development stage you fight for the ideal. :)
You're going to lose, because Pyth
On 01/12/2014 02:52 PM, Antoine Pitrou wrote:
You are right, it is not ok. The wording wasn't constructive or
controlled at all. I'd like to apologize for that.
Thank you. Apology accepted.
At the same point, I was expressing a fair amount of frustration. I
think the last discussion rounds
On 01/12/2014 04:02 PM, Stephen J. Turnbull wrote:
So when you talk about "we", I suspect you are not the "we" everybody
else is arguing with. In particular, AIUI your use case is not
included in the use cases most of us -- including Steven -- are
thinking about.
Ah, so even in the minority I
On 01/12/2014 03:55 PM, Guido van Rossum wrote:
There's a lot of discussion about PEP 460 and I haven't read it all.
Maybe you all have already reached the same conclusion that I have.
No, no agreement has been reached. Your contribution is timely.
PEP 460 itself currently rejects support f
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
%s seems the trickiest: I think with a bytes argument it should just
insert those bytes (and the padding modifiers should work too), and
for other types it should probably work like %a, so that it works as
expected for numeric values, and with a st
On 01/12/2014 06:07 PM, Daniel Holth wrote:
On Sun, Jan 12, 2014 at 8: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 should just
insert those bytes (and the padding modifiers should work too), and
for other
On 01/12/2014 06:16 PM, Ethan Furman wrote:
If you do :
--> b'%s' % 'some text'
Ignore what I previously said. With no encoding the result would be:
b"'some text'"
So an encoding should definitely be specified.
--
~Ethan~
___
On 01/12/2014 06:03 PM, Steven D'Aprano wrote:
The above all sounds reasonable. But the following does not -- I think
it shows some fundamental confusion on your part.
My apologies. The '\xd1.' was a bytestring, I forgot to type the b. (I know, I know, I should've copied and pasted
:( )
On 01/12/2014 07:45 PM, Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 6:16 PM, Ethan Furman wrote:
In reference to a byte stream, if you do:
--> b'%s' % 'some text'.encode('cp1241')
it's really just bytes into bytes.
That's a confusing exampl
.
Hopefully as some consolation I will be very vocal about using str unless bytes is necessary. Any application that uses
text should be using str for it, and only using bytes, if necessary, on the back-end.
Ethan Furman writes:
In only one case did I use the word "text" loosely,
[
On 01/12/2014 08:27 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote:
I didn't trim enough to make my point clear. My apologies.
But
knowledge of ASCII isn't necessary to specify these methods; they can
be defined in a
On 01/12/2014 06:11 PM, 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 should just
insert those bytes (and the padding modifiers should work too), and
for
On 01/12/2014 02:32 PM, Mark Lawrence wrote:
I've just tried asciistr using your test code (having corrected the typo, it's
assertIsInstance, not assertIsinstance :)
and it looks like a very good starting point. Have you, or anyone else for
that matter, actually tried asciistr out?
Ah, than
On 01/12/2014 10:51 PM, Nick Coghlan wrote:
I am a strong -1 on the more lenient proposal, as it makes binary
interpolation in Python 3 an *unsafe operation* for ASCII incompatible
binary formats.
No more unsafe that calling .upper() on ASCII incompatible streams.
The existing binary operat
On 01/12/2014 11:15 PM, Guido van Rossum wrote:
(It's too late here to write more, but it looks like we are in for a
bitter fight. :-( )
It's already been a bitter fight.
The opponents of %-interpolation (Nick, Antoine, Turnbull, D'Aprano, et al*) all seem to be arguing basically what Nick
s
On 01/13/2014 01:49 AM, Mark Shannon wrote:
'%s' can't work in 3.5, as we must differentiate between
strings which meed to be encoded and bytes which don't.
I don't understand this objection:
def __mod__(self, other):
if isinstance(other, bytes):
# no encoding necessary
elif
On 01/13/2014 02:48 AM, Stephen J. Turnbull wrote:
Ethan Furman writes:
The part that you don't seem to acknowledge (sorry if I missed it)
is that there are str-like methods already on bytes.
I haven't expressed myself well, but I don't much care about that.
You don't
On 01/13/2014 08:09 AM, Antoine Pitrou wrote:
On Mon, 13 Jan 2014 07:59:10 -0800
Guido van Rossum wrote:
On Mon, Jan 13, 2014 at 3:41 AM, Antoine Pitrou wrote:
What is the use case for embedding a quoted ASCII-encoded representation
in a byte stream?
It doesn't crash but produces undesired
On 01/13/2014 07:52 AM, Barry Warsaw wrote:
On Jan 12, 2014, at 09:45 PM, Glenn Linderman wrote:
Quotes in the stream are a great debug hint, without blowing up.
They actually terrible for debugging for exactly the same reason as coercion
in Python 2. It's rarely what you really want, it sil
On 01/13/2014 01:13 AM, Nick Coghlan wrote:
On 13 Jan 2014 17:43, "Ethan Furman" wrote:
On 01/12/2014 10:51 PM, Nick Coghlan wrote:
I am a strong -1 on the more lenient proposal, as it makes binary
interpolation in Python 3 an *unsafe operation* for ASCII incompatible
binary for
On 01/13/2014 07:49 AM, Barry Warsaw wrote:
On Jan 12, 2014, at 06:11 PM, Guido van Rossum wrote:
Perhaps not, but it's a hint that you should probably think about an
encoding. It's symmetric with how '%s' % b'x' returns "b'x'". Think of
it as payback time. :-)
Which unfortunately causes no e
On 01/13/2014 08:39 AM, Ethan Furman wrote:
On 01/13/2014 07:49 AM, Barry Warsaw wrote:
On Jan 12, 2014, at 06:11 PM, Guido van Rossum wrote:
Perhaps not, but it's a hint that you should probably think about an
encoding. It's symmetric with how '%s' % b'x'
On 01/13/2014 09:31 AM, Antoine Pitrou wrote:
On Mon, 13 Jan 2014 08:36:05 -0800
Ethan Furman wrote:
You mean crash all the time? I'd be fine with that for both the str case
and the bytes case. But's probably too late
to change the str case, and the bytes case should mirror wha
On 01/13/2014 09:12 AM, Nick Coghlan wrote:
On 14 January 2014 01:54, Ethan Furman wrote:
Forgive me for being dense, but I don't understand your objection. With
Guido's proposal, '%s' % bytes_data, bytes_data is passed through unchanged.
Did you mean something else by &qu
On 01/13/2014 12:02 PM, Brett Cannon wrote:
Personally, neither would I; just focus on bytes.format() and let % operator on
strings slowly go away.
Hey, now, some of us like %! ;)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https:
On 01/13/2014 01:08 PM, Glenn Linderman wrote:
+1 - what Ethan said. A real death, instead death by inappropriately transformed data, is
fine by me, if b"%s" %
str(...) doesn't have the appropriate .encode(...) call. But I could live with
either.
You mean instead of death by a thousand quote
On 01/13/2014 01:20 PM, Mark Lawrence wrote:
On 13/01/2014 21:01, Paul Moore wrote:
I think this should be for 3.5, and should not involve an accelerated
release of 3.5 - we should get it into the 3.5 code early and let
people thrash out the details during the 3.5 release cycle.
I disagree, i
Has anyone actually used __bytes__ yet? What for?
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.c
On 01/13/2014 09:06 PM, Guido van Rossum wrote:
Sorry to butt in, but can you post a link to the asciistr code? Google
has too many hits for other things to be useful to find it, it seems.
https://github.com/jeamland/asciicompat
--
~Ethan~
___
Pytho
On 01/13/2014 09:06 PM, Guido van Rossum wrote:
In contrast, here's the tests I drew up for what I thought bytes should do for
us (no code, just tests):
https://bitbucket.org/stoneleaf/bytestring
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@p
On 01/13/2014 09:12 PM, Ethan Furman wrote:
On 01/13/2014 09:06 PM, Guido van Rossum wrote:
In contrast, here's the tests I drew up for what I thought bytes should do for
us (no code, just tests):
https://bitbucket.org/stoneleaf/bytestring
Ugh. Ignore for now, I need to update th
On 01/14/2014 10:11 AM, Jim J. Jewett wrote:
But in terms of explaining the text model, that
separation is important enough that
(2) It *may* be worth creating a virtual
split in the documentation.
I think (2) is a great idea.
I'm willing ot work on (2) if there is general
Duh. Here's the text, as well. ;)
PEP: 461
Title: Adding % and {} formatting to bytes
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-01-13
Python-Version: 3.5
Post-History: 2014-01-13
Resol
On 01/14/2014 10:52 AM, Guido van Rossum wrote:
Which reminds me. Quite a few people have spoken out in favor of loud
failures rather than silent "wrong" output. But I think that in the
specific context of formatting output, there is a long and IMO good
tradition of producing (slightly) wrong ou
This PEP goes a but further than PEP 460 does, and hopefully spells things out in enough detail so there is no confusion
as to what is meant.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
On 01/14/2014 01:05 PM, Brett Cannon wrote:
On Tue, Jan 14, 2014 at 2:55 PM, Ethan Furman wrote:
This PEP goes a but further than PEP 460 does, and hopefully spells
things out in enough detail so there is no confusion as to what is
meant.
Are we going down the PEP route with the various
On 01/14/2014 12:22 PM, Larry Hastings wrote:
I have now received exactly zero feedback about the prototype, which suggests
people aren't using it. In an attempt to
jump-start this conversation, I've created a new repository containing the "concrete
examples of the various options"
that Barry
On 01/14/2014 01:15 PM, Eric V. Smith wrote:
On 1/14/2014 3:54 PM, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought
On 01/14/2014 12:57 PM, Antoine Pitrou wrote:
On Tue, 14 Jan 2014 11:56:25 -0800
Ethan Furman wrote:
%s, because it is the most general, has the most convoluted resolution:
- input type is bytes?
pass it straight through
It should try to get a Py_buffer instead.
Meaning any
On 01/14/2014 01:17 PM, Mark Lawrence wrote:
On 14/01/2014 20:54, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought
On 01/14/2014 02:17 PM, Nick Coghlan wrote:
On 15 Jan 2014 07:36, "Ethan Furman" mailto:et...@stoneleaf.us>> wrote:
On 01/14/2014 12:57 PM, Antoine Pitrou wrote:
On Tue, 14 Jan 2014 11:56:25 -0800
Ethan Furman mailto:et...@stoneleaf.us>> wrote:
%s, because it is the
On 01/14/2014 02:28 PM, Larry Hastings wrote:
On 01/14/2014 12:51 PM, Ethan Furman wrote:
I checked the README, the current file, and the buffered files. My
preferences from highest to lowest:
+1 modified buffer approach
+0.5 buffer approach
+0 side file
NaN on the others is fine
On 01/14/2014 05:02 PM, Glenn Linderman wrote:
On 1/14/2014 2:38 PM, Nick Coghlan wrote:
I think Brett has the right idea: we shouldn't try to accept numbers
for %s in binary interpolation. If we limit it to just buffer
exporters and objects with a __bytes__ method then the problem goes away.
On 01/14/2014 08:31 PM, Larry Hastings wrote:
I've added a fourth feature to the prototype:
set line_prefix
lets you set a string that is prepended to every line of code generated by
Clinic.
Without the coloring support of my editor I would find that very useful indeed. But since I ha
On 01/15/2014 06:45 AM, Brett Cannon wrote:
bytes.format() below. I'll leave it to you to decide if they warrant using,
leaving as an open question, or rejecting.
Thanks for your comments. I've only barely touched format, so it's not an area
of strength for me. :)
--
~Ethan~
__
On 01/14/2014 02:41 PM, Mark Lawrence wrote:
On 14/01/2014 19:55, Ethan Furman wrote:
This PEP goes a but further than PEP 460 does, and hopefully spells
things out in enough detail so there is no confusion as to what is meant.
--
~Ethan~
Out of plain old curiosity do we have to consider PEP
On 01/15/2014 08:04 AM, Antoine Pitrou wrote:
On Wed, 15 Jan 2014 15:47:43 + (UTC)
Neil Schemenauer wrote:
Objects that implement __str__ can also implement __bytes__ if they
can guarantee that ASCII characters are always returned, no matter
what the *value*
I think that's a slippery slo
On 01/15/2014 07:47 AM, Neil Schemenauer wrote:
Thanks for writing the PEP.
Thank you for your comments!
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyth
On 01/15/2014 08:51 AM, Brett Cannon wrote:
On Wed, Jan 15, 2014 at 10:57 AM, Ethan Furman wrote:
Thanks for your comments. I've only barely touched format, so it's not an area
of strength for me. :)
Time to strengthen it if you are proposing a PEP that is going to affect it.
On 01/15/2014 06:45 AM, Brett Cannon wrote:
I also think that a 'b' conversion be added to bytes.format(). This doesn't
have the same issue as %b if you make {}
implicitly mean {!b} in Python 3.5 as {} will mean what is the most accurate
for bytes.format() in either version. It
also allows for
On 01/15/2014 06:45 AM, Brett Cannon wrote:
The PEP currently says::
format
--
The format mini language will be used as-is, with the behaviors as listed
for %-interpolation.
That's too vague; % interpolation does not support other format operators in
the same way as str.f
On 01/15/2014 08:33 AM, Mark Lawrence wrote:
For completeness I believe %r and %a should be included here as well.
Good point. Done.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
Current copy of PEP, many modifications from all the feedback. Thank you to
everyone.
I know it's been a long week (feels a lot longer!) while all this was hammered
out, but I think we're getting close!
Abstract
This PEP proposes adding the % and {} form
501 - 600 of 1590 matches
Mail list logo
