Guido van Rossum wrote:
I've now looked at asciistr. (Thanks Glenn and Ethan for the link.)
Now that I (hopefully) understand it, I'm worried that a text
processing algorithm that uses asciistr might under hard-to-predict
circumstances (such as when the arguments contain nothing of interest
to
Glenn Linderman wrote:
A mechanism could be defined where
format string would only contain format specifications, and any other
text would be considered an error.
Someone already did -- it's called struct.pack(). :-)
--
Greg
___
Python-Dev mailing
On 1/14/2014 12:03 AM, Guido van Rossum wrote:
On Mon, Jan 13, 2014 at 6:25 PM, Terry Reedy tjre...@udel.edu wrote:
byteformat(b'\x00{}\x02{}def', (b'\x01', b'abc',))
b'\x00\x01\x02abcdef'
re.split produces [b'\x00', b'', b'\x02', b'', b'def']. The only ascii bias
is the one already present
Nick Coghlan writes:
Give up makes it sound like I got tired of arguing without being
convinced rather than admitting I was just plain wrong.
I thought it was something in between (you explicitly said lenient
PEP 460 doesn't hurt you, but my understanding was you still believe
that there's a
In article 3f3jh11tmgz7...@mail.python.org,
benjamin.peterson python-check...@python.org wrote:
http://hg.python.org/cpython/rev/715fd3d8ac93
changeset: 88454:715fd3d8ac93
branch: 3.1
parent: 86777:b1ddcb220a7f
parent: 88453:87673659d8f7
user:Benjamin Peterson
On 14 Jan 2014 19:11, Stephen J. Turnbull step...@xemacs.org wrote:
Nick Coghlan writes:
Give up makes it sound like I got tired of arguing without being
convinced rather than admitting I was just plain wrong.
I thought it was something in between (you explicitly said lenient
PEP 460
Guido van Rossum writes:
Of course, nobody in their right mind would use a format string
containing UTF-16 or EBCDIC.
How about Shift JIS and Big 5 (traditionally mandated by Microsoft
in their respective regions, with Shift JIS still overwhelmingly
popular) and GB* (GB18030 is not just a
On 14 January 2014 19:54, Stephen J. Turnbull step...@xemacs.org wrote:
Guido van Rossum writes:
And that is precisely my point. When you're using a format string,
all of the format string (not just the part between { and }) had
better use ASCII or an ASCII superset. And this (rightly)
On Tue, Jan 14, 2014, at 01:17 AM, Ned Deily wrote:
In article 3f3jh11tmgz7...@mail.python.org,
benjamin.peterson python-check...@python.org wrote:
http://hg.python.org/cpython/rev/715fd3d8ac93
changeset: 88454:715fd3d8ac93
branch: 3.1
parent: 86777:b1ddcb220a7f
parent:
On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman et...@stoneleaf.us 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
On Tue, Jan 14, 2014 at 12:20 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
I've now looked at asciistr. (Thanks Glenn and Ethan for the link.)
Now that I (hopefully) understand it, I'm worried that a text
processing algorithm that uses asciistr might under
On Mon, Jan 13, 2014 at 5:14 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Jan 13, 2014 at 2:05 PM, Brett Cannon br...@python.org wrote:
I have been going on the assumption that bytes.format() would change what
'{}' meant for itself and would only interpolate bytes. That convenient
Brett,
I like your proposal. There is one idea I have that could,
perhaps, improve it:
1. “%s and “{}” will continue to work for bytes and bytearray in
the following fashion:
- check if __bytes__/Py_buffer supported.
- if it is, check that the bytes are strictly in the printable
On Tue, Jan 14, 2014 at 12:29 PM, Yury Selivanov yselivanov...@gmail.comwrote:
Brett,
I like your proposal. There is one idea I have that could,
perhaps, improve it:
1. “%s and “{}” will continue to work for bytes and bytearray in
the following fashion:
- check if __bytes__/Py_buffer
On January 14, 2014 at 12:47:35 PM, Brett Cannon (br...@python.org) wrote:
On Tue, Jan 14, 2014 at 12:29 PM, Yury Selivanov wrote:
Brett,
I like your proposal. There is one idea I have that could,
perhaps, improve it:
1. “%s and “{}” will continue to work for bytes and
On Tue, Jan 14, 2014 at 7:59 AM, Guido van Rossum gu...@python.org wrote:
Here's an example of what I mean:
I sent that off without proofreading, and I also got one detail about
asciistr() wrong. Here are some corrections.
def spam(a):
r = asciistr('(')
if a: r += a.strip()
r +=
Nick Coghlan wrote:
Arbitrary binary data and ASCII compatible binary data are *different
things* and the only argument in favour of modelling them with a single
type is because Python 2 did it that way.
Greg Ewing replied:
I would say that ASCII compatible binary data is a
*subset* of
[Other readers: asciistr is at https://github.com/jeamland/asciicompat]
On Mon, Jan 13, 2014 at 11:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
Right, asciistr is designed for a specific kind of hybrid API where
you want to accept binary input (and produce binary output) *and* you
want to
On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov yselivanov...@gmail.comwrote:
- Try str(), and do .encode(‘ascii’, ‘stcict’)” on the result.
please no -- that's the source of a lot of pain in py2 now.
having a failure as a result of the value, rather than the type, of an
object just makes
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
On Tue, Jan 14, 2014 at 9:45 AM, Chris Barker chris.bar...@noaa.gov wrote:
On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov yselivanov...@gmail.com
wrote:
- Try str(), and do .encode(‘ascii’, ‘stcict’)” on the result.
please no -- that's the source of a lot of pain in py2 now.
having a
On 1/14/2014 1:11 PM, Jim J. Jewett wrote:
But in terms of explaining the text model, that
separation is important enough that
(1) We should be reluctant to strengthen the
its really just ASCII messages.
(2) It *may* be worth creating a virtual
split in the
I think this was supposed to be 461, not 460 =)
On Tue, Jan 14, 2014 at 2:12 PM, guido.van.rossum
python-check...@python.org wrote:
http://hg.python.org/peps/rev/a25f48998ad3
changeset: 5346:a25f48998ad3
user:Guido van Rossum gu...@dropbox.com
date:Tue Jan 14 11:12:09
On Tue, 14 Jan 2014 10:52:05 -0800
Guido van Rossum gu...@python.org wrote:
Would you rather raise an exception, truncate the
value, or mess up the formatting? All languages newer than Fortran
that I've used have chosen the latter, and I still agree it's a good
idea.
Well that's useful when
On Tue, Jan 14, 2014 at 1:52 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Jan 14, 2014 at 9:45 AM, Chris Barker chris.bar...@noaa.gov wrote:
On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov yselivanov...@gmail.com
wrote:
- Try str(), and do .encode(‘ascii’, ‘stcict’)” on the result.
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 *may* be worth creating a virtual
split in the documentation.
(rough sketch
On Tue, 14 Jan 2014 11:43:16 -0800, Jim J. Jewett jimjjew...@gmail.com
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
On 01/14/2014 01:52 PM, Guido van Rossum wrote:
But the way to arrive at this behavior without duplicating a whole lot
of code seems to be to call the existing text-based __format__ API and
convert the result to bytes -- for numbers this should be safe (their
formatting produces just ASCII
Personally I wouldn't add any words suggesting or referring to the
option of creation another class for this purpose. You wouldn't
recommend subclassing dict for constraining the types of keys or
values, would you?
On Tue, Jan 14, 2014 at 11:43 AM, Jim J. Jewett jimjjew...@gmail.com wrote:
On Tue, Jan 14, 2014 at 12:04 PM, Eric V. Smith e...@trueblade.com wrote:
On 01/14/2014 01:52 PM, Guido van Rossum wrote:
But the way to arrive at this behavior without duplicating a whole lot
of code seems to be to call the existing text-based __format__ API and
convert the result to bytes
Duh. Here's the text, as well. ;)
PEP: 461
Title: Adding % and {} formatting to bytes
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman et...@stoneleaf.us
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-01-13
Python-Version: 3.5
Post-History: 2014-01-13
On 01/11/2014 07:35 PM, Larry Hastings wrote:
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide
concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with
actual code,
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
On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings la...@hastings.org wrote:
I have now received exactly zero feedback about the prototype, which
suggests people aren't using it.
Oops, I had half a post written about this two days ago, but never got
it posted.
I did some experimenting on winreg.c
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
On 01/14/2014 12:48 PM, Zachary Ware wrote:
On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings la...@hastings.org wrote:
I have now received exactly zero feedback about the prototype, which
suggests people aren't using it.
Oops, I had half a post written about this two days ago, but never got
it
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman et...@stoneleaf.us wrote:
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
On Tue, 14 Jan 2014 11:56:25 -0800
Ethan Furman et...@stoneleaf.us 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.
- input type is numeric?
use its
On Tue, Jan 14, 2014 at 3:22 PM, Larry Hastings la...@hastings.org wrote:
On 01/11/2014 07:35 PM, Larry Hastings wrote:
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide
concrete examples of the various options?
My own
On Tue, Jan 14, 2014 at 2:55 PM, Ethan Furman et...@stoneleaf.us 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 ideas? Guido, do you want
one
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 Tue, 14 Jan 2014 12:22:12 -0800
Larry Hastings la...@hastings.org wrote:
https://bitbucket.org/larry/clinic-buffer-samples/src
In it I converted Modules/_pickle.c four different ways. There's a
README, please read it.
I'm +1 on the sidefile approach. +0 on the various buffer
On 1/14/2014 3:54 PM, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman et...@stoneleaf.us wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought there would be some combination using %.15s but I
On 14/01/2014 20:54, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman et...@stoneleaf.us wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought there would be some combination using %.15s but I
Nick Coghlan wrote:
The
mini-language parser has to assume in encoding in order to interpret
the format string, and that's *all* done assuming an ASCII compatible
format string (which must make life interesting if you try to use an
ASCII incompatible coding cookie for your source code
I don't
On Jan 14, 2014, at 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
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 et...@stoneleaf.us wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought there
On 01/14/2014 12:57 PM, Antoine Pitrou wrote:
On Tue, 14 Jan 2014 11:56:25 -0800
Ethan Furman et...@stoneleaf.us 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.
On 2014-01-14 20:54, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman et...@stoneleaf.us wrote:
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
On 15 Jan 2014 04:16, Guido van Rossum gu...@python.org wrote:
[Other readers: asciistr is at https://github.com/jeamland/asciicompat]
On Mon, Jan 13, 2014 at 11:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
Right, asciistr is designed for a specific kind of hybrid API where
you want to
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou solip...@pitrou.net wrote:
I'm +1 on the sidefile approach. +0 on the various buffer approaches.
-0.5 on the current sprinkled everywhere approach.
I concur with Antoine except that I'm a full -1 on commingling
generated code with hand edited code.
On January 14, 2014 at 4:36:00 PM, Ethan Furman (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 wrote:
%s, because it is the most general, has the most convoluted
resolution:
- input type is bytes?
pass it
On Tue, 14 Jan 2014 13:07:57 -0800
Ethan Furman et...@stoneleaf.us wrote:
Meaning any bytes or bytes-subtype will support the Py_buffer protocol, and
this should be the first thing we try?
Sounds good.
For that matter, should the first test be does this object support
Py_buffer and
On Tue, Jan 14, 2014 at 2:54 PM, Larry Hastings la...@hastings.org wrote:
I will consider you a +1 on the buffer approach and NaN on the other
approaches.
Oops, I'll give you some real numbers:
-1 _pickle.original.c
+1 _pickle.using-buffer.c
+0 _pickle.using-modified-buffer.c
+1
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 et...@stoneleaf.us wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought there
Let me answer you both since the issues are related.
On 1/14/2014 7:46 AM, Nick Coghlan wrote:
Guido van Rossum writes:
And that is precisely my point. When you're using a format string,
Bytes interpolation uses a bytes format, or a byte string if you will,
but it should not be thought
Guido van Rossum wrote:
def spam(a):
r = asciistr('(')
if a: r += a.strip()
r += asciistr(')')
return r
The general fix would be to add
else: r += a[:0]
The awkwardness might be reducable if asciistr let
you write something like
r = asciistr('(', a)
meaning give me
On 1/14/2014 4:46 AM, Nick Coghlan wrote:
The one remaining way I could potentially see a formatb method working
is along the lines of what Glenn (I think) suggested: just like struct
definitions, the formatb specifier would have to consist*solely* of
substitution fields. However, that's
On 15 Jan 2014 08:00, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
def spam(a):
r = asciistr('(')
if a: r += a.strip()
r += asciistr(')')
return r
The general fix would be to add
else: r += a[:0]
The awkwardness might be reducable if
Am 14.01.2014 21:22, schrieb Larry Hastings:
On 01/11/2014 07:35 PM, Larry Hastings wrote:
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide
concrete examples of the various options?
My own opinion could easily be influenced
Guido van Rossum wrote:
Actually, Nick explained that asciistr() + asciistr() returns str,
That part seems wrong to me, because it means that
you can't write polymorphic byte/string functions
that are composable.
I would be -1 on that, and prefer that
asciistr + asciistr -- asciistr.
--
Greg
On 15 Jan 2014 07:36, Ethan Furman 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 et...@stoneleaf.us wrote:
%s, because it is the most general, has the most convoluted resolution:
- input type is bytes?
On 15 Jan 2014 08:14, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
Actually, Nick explained that asciistr() + asciistr() returns str,
That part seems wrong to me, because it means that
you can't write polymorphic byte/string functions
that are composable.
I
On 01/14/2014 02:17 PM, Nick Coghlan wrote:
On 15 Jan 2014 07:36, Ethan Furman et...@stoneleaf.us
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 et...@stoneleaf.us mailto:et...@stoneleaf.us wrote:
%s,
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:
- modified buffer approach
- buffer approach
- side file
Could you put that in the form of numbers from +1 to -1? I'm literally
making
On 01/14/2014 01:38 PM, Raymond Hettinger wrote:
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net wrote:
I'm +1 on the sidefile approach. +0 on the various buffer approaches.
-0.5 on the current sprinkled everywhere approach.
I concur with Antoine
On 15 Jan 2014 08:23, Ethan Furman et...@stoneleaf.us wrote:
On 01/14/2014 02:17 PM, Nick Coghlan wrote:
On 15 Jan 2014 07:36, Ethan Furman et...@stoneleaf.us 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
I think of PEP 460 as the strict version and PEP 461 as the lenient
version. I don't think it makes sense to have more variants. So please
collaborate with whichever you like best. :-)
On Tue, Jan 14, 2014 at 1:11 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/14/2014 01:05 PM, Brett Cannon
14.01.14 23:38, Raymond Hettinger написав(ла):
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net wrote:
I'm +1 on the sidefile approach. +0 on the various buffer approaches.
-0.5 on the current sprinkled everywhere approach.
I concur with Antoine
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 292 string
templates in any way, shape or
On Tue, Jan 14, 2014 at 1:37 PM, Nick Coghlan ncogh...@gmail.com wrote:
Yep - that's why I consider asciistr to be firmly in the power tool
category. If you know what you're doing, it should let you write hybrid API
code that is just as concise as Python 2, but it's also far more error prone
Guido van Rossum wrote:
I understand that '' here stands for any arbitrary combination, but
what about searches? Given that asciistr's base class is str, won't it
still blow up if you try to use it as an argument to e.g.
bytes.startswith()? Equality tests also sound problematic; is b'x' ==
15.01.14 00:40, Guido van Rossum написав(ла):
I think of PEP 460 as the strict version and PEP 461 as the lenient
version. I don't think it makes sense to have more variants. So please
collaborate with whichever you like best. :-)
Perhaps the consensus will be PEP 460.5? Or PEP 460.3, or may
On 01/14/2014 01:38 PM, Raymond Hettinger wrote:
FWIW, I think everyone should place a lot of weight on
Serhiy's comments and suggestions. His reasoning is
clear and compelling. And the thoughts are all soundly
based on extensive experience with the clinic's effect on
the C source code.
Guido van Rossum wrote:
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 output in favor of more strict
behavior.
Nick Coghlan wrote:
On 15 Jan 2014 08:00, Greg Ewing greg.ew...@canterbury.ac.nz
mailto:greg.ew...@canterbury.ac.nz wrote:
If so, would it help if asciistr were a built-in
type, so that other things could be made aware of
it?
That way lies the Python 2 text model, and we're not going
Even though I’m not a core dev, I happen to work with cpython source
code quite a lot, whether it’s me working on a C extension, or just
digging it for some obscure details of how python works.
And what I want to say is that cpython sources are great. They are
easy to understand even for people
On Tue, Jan 14, 2014 at 10:58:49AM -0500, R. David Murray wrote:
On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman et...@stoneleaf.us wrote:
Has anyone actually used __bytes__ yet? What for?
bytes(email.message.Message()) returns the message object serialized to
wire format.
--David
On 1/14/2014 10:11 AM, Jim J. Jewett wrote:
Virtual subclass ASCIIStructuredBytes
You would first have to define what you meant by a virtual subclass, and
that somewhere would have to be linked every place you use the term,
because it is a new term.
Why not just call the sections of the
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.
The numeric codes all exist in Python 2, so
On Tue, Jan 14, 2014 at 10:16:17AM -0800, Guido van Rossum wrote:
Hm. It is beginning to sound more and more flawed. I also worry that
it will bring back the nightmare of data-dependent UnicodeError back.
E.g. this (from tests/basic.py):
def
I favor a dual-mode approach. I think the existing behavior is best for the
conversion of existing modules, because it's easy to interactively verify
the generated code. Once that's done, long-term maintenance definitely
favors a more centralized format.
+1 _pickle.original.c /* used only during
On Tue, Jan 14, 2014 at 5:32 PM, Ryan Smith-Roberts r...@lab.net wrote:
NaN _pickle.using-sidefile.c /* not enough experience with it */
I hate to weasel like that. Intellectually I think I favor the sidefile
over all other approaches for its cleanliness. But I'd have to actively use
it in a
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 Wed, Jan 15, 2014 at 01:03:13PM +1300, Greg Ewing wrote:
Nick Coghlan wrote:
That way lies the Python 2 text model, and we're not going there. It's
probably best to think of asciistr as a way of demonstrating a
rhetorical point about the superiority of the Python 3 text model
Hmmm...
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 05:32 PM, Ryan Smith-Roberts wrote:
Pondering it this afternoon, I thought of a configuration that
minimizes both code churn and readability impact: two buffers. One at
the top containing forward declarations and defines (an inline header
file if you like), and the rest of the
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.
I am am having trouble binding an Entry widget to Return
Here is the snippet (butCol is a Frame widget to put
On 14Jan2014 11:43, Jim Jewett jimjjew...@gmail.com wrote:
Greg Ewing replied:
... ASCII compatible binary data is a
*subset* of arbitrary binary data.
I wrote: [...]
(2) It *may* be worth creating a virtual
split in the documentation. [...]
Ethan likes the idea, but
On 1/14/2014 7:53 PM, Rob Ward wrote:
I apologise if I have come to the wrong place here,
Yes, you have ;-).
pydev is for development *of* future versions of Python. Try python-list
for development *with* current version.
--
Terry Jan Reedy
___
On 2014-01-15 00:53, 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.
I am am having trouble binding an Entry widget to Return
Here is the
Hey Rob,
The place to get help with Tkinter is tkinter-disc...@python.org. I've
CC'ed that list for you.
--Guido
On Tue, Jan 14, 2014 at 4:53 PM, Rob Ward rl.w...@bigpond.com wrote:
I apologise if I have come to the wrong place here, but 12hrs searching,
plus experimenting, on the WWW for
On Tue, Jan 14, 2014 at 3:06 PM, Guido van Rossum gu...@python.org wrote:
Personally I wouldn't add any words suggesting or referring to the
option of creation another class for this purpose. You wouldn't
recommend subclassing dict for constraining the types of keys or
values, would you?
Yes,
R. David Murray writes:
a file is a just a wire with an indefinite destination and
transmission time
+1 QOTW
Of course! Store and ... wait for it ... forward architecture
4-ever!
Store and Forward, Inc. Since 1969.
___
Python-Dev mailing list
I am exhausted from all these discussions. I just recommend not
touching those docs.
On Tue, Jan 14, 2014 at 8:08 PM, Jim Jewett jimjjew...@gmail.com wrote:
On Tue, Jan 14, 2014 at 3:06 PM, Guido van Rossum gu...@python.org wrote:
Personally I wouldn't add any words suggesting or referring to
Steven D'Aprano wrote:
I don't think mixing bytes and strings makes good semantic sense.
It's not about mixing bytes and text -- it's about
writing polymorphic code that will work on either
bytes *or* text. Not both at the same time.
If we had quantum computers, this would be easy
to solve:
On 01/14/2014 12:22 PM, Larry Hastings wrote:
On 01/11/2014 07:35 PM, Larry Hastings wrote:
I've uploaded a prototype here:
https://bitbucket.org/larry/python-clinic-buffer
[...] I've created a new repository containing the concrete examples
of the various options that Barry proposed
On Tue, Jan 14, 2014 at 3:12 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 14 Jan 2014 12:22:12 -0800
Larry Hastings la...@hastings.org wrote:
https://bitbucket.org/larry/clinic-buffer-samples/src
In it I converted Modules/_pickle.c four different ways. There's a
README,
Steven D'Aprano writes:
I thought I understand the purpose of asciistr was exactly that, to
produce something that was compatible with both bytes and strings.
asciistr *canonizes* something as an ASCII string, and therefore
compatible with both bytes and str. It can't *create* such a thing
1 - 100 of 103 matches
Mail list logo
