Antoine Pitrou wrote:
bytearray(ba) + bbc
bytearray(b'abc')
ba + bytearray(bbc)
b'abc'
It's quite convenient.
It's a bit disconcerting that the left operand wins,
rather than one of them being designated as the
wider type, as occurs with many other operations on
mixed types, e.g. int +
Donald Stufft wrote:
1. The statement *item is roughly the same thing as (item[0], item[1], item[n])
No, it's not -- that would make it equivalent to tuple(item),
which is not what it means in any of its existing usages.
What it *is* roughly equivalent to is
item[0], item[1], item[n]
Victor Stinner wrote:
Le 10 févr. 2015 06:48, Greg Ewing greg.ew...@canterbury.ac.nz
mailto:greg.ew...@canterbury.ac.nz a écrit :
It could potentially be a little more efficient by
eliminating the construction of an intermediate list.
Is it the case in the implementation? If it has
Donald Stufft wrote:
perhaps a better
solution is to simply make it so that something like ``a_list +
an_iterable`` is valid and the iterable would just be consumed and +’d
onto the list.
I don't think I like the asymmetry that this would
introduce into + on lists. Currently
[1, 2, 3]
Donald Stufft wrote:
However [*item for item in ranges] is mapped more to something like this:
result = []
for item in iterable:
result.extend(*item)
Actually it would be
result.extend(item)
But if that bothers you, you could consider the expansion
to be
result = []
for item in
Donald Stufft wrote:
why is:
print(*[1], *[2], 3) better than print(*[1] + [2] + [3])?
It could potentially be a little more efficient by
eliminating the construction of an intermediate list.
defining + or | or some other symbol for something similar
to [1] + [2] but for dictionaries. This
Maciej Fijalkowski wrote:
However, you can't access thread
locals from signal handlers (since in some cases it mallocs, thread
locals are built lazily if you're inside the .so, e.g. if python is
built with --shared)
You might be able to use Py_AddPendingCall to schedule
what you want done
Andrea Griffini wrote:
Sorry if the question is naive, but why is co_names needed? Wouldn't be
simpler to just use co_consts?
One reason might be that keeping them separate means
you can have up to 256 names and 256 consts using
1-byte opcode arguments. Otherwise, you'd be limited
to a total
Petr Viktorin wrote:
On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar mistersh...@gmail.com wrote:
How do I disassemble a generated comprehension?
Put it in a function, then get it from the function's code's constants.
It would be handy if dis had an option to disassemble nested
functions
On 01/21/2015 11:16 PM, Neil Girdhar wrote:
Why not have BUILD_MAP work like BUILD_LIST? I.e., STORE_MAP takes a
parameter n and adds the last n pairs of stack elements into the n-1 stack
element (the dictionary).
It probably wouldn't make much difference. Building a list is
substantially
Guido van Rossum wrote:
On Mon, Jan 19, 2015 at 11:43 AM, Paul Sokolovsky pmis...@gmail.com
mailto:pmis...@gmail.com wrote:
b.lower_inplace()
b.lower_i()
Please don't go there. The use cases are too rare.
And if you have such a use case, it's not too
hard to do
b[:] = b.lower()
MRAB wrote:
Maybe, also, strptime could support %*f to gobble as many digits as
are available.
The * would suggest that the number of digits is being
supplied as a parameter. Maybe %?f.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Steven D'Aprano wrote:
If this feature is going to be used, I would expect to be able to re-use
pre-written module types. E.g. having written module with properties
(so to speak) once, I can just import it and use it in my next project.
There would be nothing to stop __new__.py importing it
Nathaniel Smith wrote:
Option 4: Add a new function sys.swap_module_internals, which takes
two module objects and swaps their __dict__ and other attributes. By
making the operation a swap instead of an assignment, we avoid the
lifecycle pitfalls from Option 3.
Didn't I see somewhere that
Guido van Rossum wrote:
Are these really all our options? All of them sound like hacks, none of
them sound like anything the language (or even the CPython
implementation) should sanction.
If assignment to the __class__ of a module were permitted
(by whatever means) then you could put this in
Nathaniel Smith wrote:
So pkgname/__new__.py might look like:
import sys
from pkgname._metamodule import MyModuleSubtype
sys.modules[__name__] = MyModuleSubtype(__name__, docstring)
To start with, the 'from
pkgname._metamodule ...' line is an infinite loop,
Why does
Guido van Rossum wrote:
The issue here is that asyncio only interprets StopIteration as
returning from the generator (with a possible value), while a Trollius
coroutine must use raise Return(value) to specify a return value;
this works as long as Return is a subclass of StopIteration, but PEP
Guido van Rossum wrote:
Hm, that sounds like you're either being contrarian or Chris and I have
explained it even worse than I thought.
I'm not trying to be contrary, I just think the PEP could
explain more clearly what you're trying to achieve. The
rationale is too vague and waffly at the
Ethan Furman wrote:
Actually, it's asking, Most other duck-typed methods will still raise a
TypeError, but these few don't. Has that ever been a problem for you?
I don't think I've *ever* been bothered by getting an
AttributeError instead of a TypeError or vice versa.
Both indicate bugs in my
Nick Coghlan wrote:
That assumption will allow MinGW-w64 to link with the appropriate
MSVCRT versions for extention building without anything breaking.
If that works, then the same technique should allow CPython
itself to be built in a VS-compatible way with mingw,
shouldn't it?
Those
anatoly techtonik wrote:
That's a cool stuff. `bytes-like object` is really a much better name for users.
I'm not so sure. Usually when we talk about an xxx-like object we
mean one that supports a certain Python interface, e.g. a file-like
object is one that has read() and/or write() methods.
I wrote:
But you can't
create an object that supports the buffer protocol by implementing
Python methods.
Another thing is that an object implementing the buffer
interface doesn't have to look anything at all like a
bytes object from Python, so calling it bytes-like
could be rather confusing.
Donald Stufft wrote:
My biggest problem with ``python3``, is what happens after 3.9.
Python2 technically includes 1.x versions as well, so it
wouldn't be unprecedented for python3 to imply versions
beyond 3.x. It would be a bit confusing, though.
--
Greg
Barry Warsaw wrote:
On Sep 19, 2014, at 08:40 AM, Guido van Rossum wrote:
Until I say so. Which will happen in the distant future.
I'm gonna hid your time machine keys so you didn't find them.
Hiding someone's time machine keys never works. Chances are
he's already taken a trip to the
Victor Stinner wrote:
Le 1 sept. 2014 00:17, Marko Rauhamaa ma...@pacujo.net
mailto:ma...@pacujo.net a écrit :
If a signal is received when read() or write() has completed its task
partially ( 0 bytes), no EINTR is returned but the partial count.
Obviously, Python should take that
Victor Stinner wrote:
As written in the PEP, if you want to be notified of the
signal, set a signal handler which raises an exception.
I'm not convinced that this covers all possible use cases.
It might be all right if you have control over the signal
handler, but what if you don't?
I think
M.-A. Lemburg wrote:
we needed
a way to make sure that Python 3 also optionally supports working
with lone surrogates in such UTF-8 streams (nowadays called CESU-8:
http://en.wikipedia.org/wiki/CESU-8).
I don't think CESU-8 is the same thing. According to the wiki
page, CESU-8 *requires* all
Isaac Morland wrote:
In HTML 5 it allows non-ASCII-compatible encodings as long as U+FEFF
(byte order mark) is used:
http://www.w3.org/TR/html-markup/syntax.html#encoding-declaration
Not sure about XML.
According to Appendix F here:
http://www.w3.org/TR/xml/#sec-guessing
an XML parser
Antoine Pitrou wrote:
I think if you want low-level features (such as unconverted bytes paths
under POSIX), it is reasonable to point you to low-level APIs.
The problem with scandir() in particular is that there is
currently *no* low-level API exposed that gives the same
functionality.
If
Ben Hoyt wrote:
Does that mean that new APIs should explicitly not support bytes?
... Bytes paths are essentially broken on Windows.
But on Unix, paths are essentially bytes. What's the
official policy for dealing with that?
--
Greg
___
Python-Dev
Stephen J. Turnbull wrote:
This case can be handled now using the surrogateescape
error handler,
So maybe the way to make bytes paths go away is to always
use surrogateescape for paths on unix?
--
Greg
___
Python-Dev mailing list
Steven D'Aprano wrote:
I've long believed that + is the wrong operator for concatenating
strings, and that makes a much better operator.
Do you have a reason for preferring '' in particular, or
do you just want something different from '+'?
Personally I can't see why bitwise and on strings
Shiz wrote:
I'm not sure a check to see if e.g.
/system exists is really enough to conclude Python is running on Android
on its own.
Since MacOSX has /System and typically a case-insensitive
file system, it certainly wouldn't. :-)
--
Greg
___
Paul Moore wrote:
Huh? CreateProcess uses PATH:
Hmm, in that case Microsoft's documentation
is lying, or subprocess is doing something itself
before passing the command name to CreateProcess.
Anyway, looks like there's no problem.
--
Greg
___
Fabio Zadrozny wrote:
Well, I must say that the exec(open().read()) is not really a proper
execfile implementation because it may fail because of encoding
issues...
It's not far off, though -- all it needs is an optional
encoding parameter.
--
Greg
On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico ros...@gmail.com
mailto:ros...@gmail.com wrote:
ISTM what you want is not shell=True, but a separate function that
follows the system policy for translating a command name into a
path-to-binary.
According to the docs,
Nikolaus Rath wrote:
you almost certainly want to do
Popen(['/bin/sh', 'for i in `seq 42`; do echo $i; done'], shell=False)
because if your shell happens to be tcsh or cmd.exe, things are going to
break.
On Unix, the C library's system() and popen() functions
always use /bin/sh, NOT the
Nathaniel Smith wrote:
For the numpy case, we really need to see all the operands, *and* know
what the operation in question is...
Okay, I see what you mean now.
Given all that, it might be simpler just to have the
method perform the operation itself if it can. It has
all the information
Steven D'Aprano wrote:
I don't know about car engine controllers, but presumably they have
diagnostic ports, and they may sometimes output text. If they output
text, then at least hypothetically car mechanics in Russia might prefer
their car to output правда and ложный rather than true and
Julian Taylor wrote:
tp_can_elide receives two objects and returns one of three values:
* can work inplace, operation is associative
* can work inplace but not associative
* cannot work inplace
Does it really need to be that complicated? Isn't it
sufficient just to ask the object potentially
Steven D'Aprano wrote:
(1) I asked if it would be okay for MicroPython to *optionally* use
nominally Unicode strings limited to ASCII. Pretty much the only
response to this as been Guido saying That would be a pretty lousy
option,
It would be limiting to have this as the *only* way of
Nathaniel Smith wrote:
I.e., BIN_ADD could do
if (Py_REFCNT(left) == 1)
result = PyNumber_InPlaceAdd(left, right);
else
result = PyNumber_Add(left, right)
Upside: all packages automagically benefit!
Potential downsides to consider:
- Subtle but real and user-visible change in Python
Nathaniel Smith wrote:
I'd be a
little nervous about whether anyone has implemented, say, an iadd with
side effects such that you can tell whether a copy was made, even if the
object being copied is immediately destroyed.
I can think of at least one plausible scenario where
this could
Paul Sokolovsky wrote:
All these changes are what let me dream on and speculate on
possibility that Python4 could offer an encoding-neutral string type
(which means based on bytes)
Can you elaborate on exactly what you have in mind?
You seem to want something different from Python 3 str,
Serhiy Storchaka wrote:
html.HTMLParser, json.JSONDecoder, re.compile, tokenize.tokenize don't
use iterators. They use indices, str.find and/or regular expressions.
Common use case is quickly find substring starting from current position
using str.find or re.search, process found token,
Serhiy Storchaka wrote:
A language which doesn't support O(1) indexing is not Python, it is only
Python-like language.
That's debatable, but even if it's true, I don't think
there's anything wrong with MicroPython being only a
Python-like language. As has been pointed out, fitting
Python onto
Glenn Linderman wrote:
For that kind of thing, you don't need an actual character
index, just some way of referring to a place in a string.
I think you meant codepoint index, rather than character index.
Probably, but what I said is true either way.
This starts to diverge from Python
Glenn Linderman wrote:
so algorithms that walk two strings at a time cannot use the same
StringPosition to do so... yep, this is quite divergent from CPython and
Python.
They can, it's just that at most one of the indexing
operations would be fast; the StringPosition would
devolve into an
Chris Barker wrote:
Personally, I often miss the ability to chain operations on mutable
objects, but I can only imagine that that design decision was made for
good reason. However, as I teach Python, I find I have nothing to say
other than that's the way it's done in Python.
Python has
Paul Sokolovsky wrote:
Well, here it itches to ask if C++-like offsetting of subclass to base
class this pointer was considered,
I suppose in theory it would be possible to build a new
set of __slot__ descriptors for the subclass. It mightn't
even be all that difficult. My guess would be that
Chris Angelico wrote:
add_HTTP_header
add_http_header
addHTTPHeader
addHttpHeader
Five... there are FIVE options...
convertXMLtoJSON
i.e. don't capitalise a part that follows capitalised
initials.
--
Greg
___
Python-Dev mailing list
Stephen J. Turnbull wrote:
Benjamin Peterson writes:
I suppose there's no way to get the compiler to both make for x in d
work as above, and make for k, v in d be equivalent to Python 2's
for k, v in d.iteritems()?
it would change the meaning of currently correct
programs, so it's a
Nick Coghlan wrote:
there are actually now *two* main ways of consuming
Python:
Really? We'd better do something about that. We don't want
anyone consuming Python -- we want some left over for the
rest of us!
(I'm making a serious point -- it's annoying when people use
the word consume as
Guido van Rossum wrote:
Some quick thoughts:
- I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
Python Twee?
Or maybe Python Tween, as in between 2 and 3.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On 11/04/14 21:50, Chris Barker wrote:
On Thu, Apr 10, 2014 at 7:12 PM, Christian Tismer tis...@stackless.comwrote:
def __init__(self, **kwargs):
first_arg = kwargs.pop('option_1', somedefault)
...
nth_arg = kwargs.pop('option_n', somedefault')
...
Is:
def
Victor Stinner wrote:
I started to implement the RFC 1924 to have a full support.
3 days later, when my code was working, I saw the date of the RFC...
Do you still have the code? It needn't go to waste -- this
would make a fine addition to Python's easter egg basket!
--
Greg
Alexander Belopolsky wrote:
We can start by reviewing the reasons for having separate
PyNumber/PySequence/PyMappingMethods structures. I believe that one of
the reasons is that many types need to allocate only one of the three.
That much is probably true.
Numpy arrays, IIRC, allocate all
Alexander Belopolsky wrote:
I meant ISO 8601 syntax for durations [1].
ISO 8601 doesn't seem to define a representation for
negative durations, though, so it wouldn't solve the
original problem.
--
Greg
___
Python-Dev mailing list
R. David Murray wrote:
I've done the 'landmark' thing as well, in the string context; that can be
very useful when doing incremental test driven development. (Granted, you
could do that with __bytes__;
Can't you do it more easily just by wrapping ascii()
around the argument? That seems
Nick Coghlan wrote:
On 16 March 2014 01:40, Guido van Rossum gu...@python.org wrote:
This downside of using subclassing as an API should be well known by now and
widely warned against.
I've actually pondered the idea of suggesting we explicitly recommend
the procedural facade around an
Chris Angelico wrote:
Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all
about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.,
3.=, 3., 3.?, 3.@, 3.A.
And we have all of UCS-4 to play with, so for all
practical purposes the 3.x line can live forever!
The
MRAB wrote:
What does irregardless mean?
It's what people say when they misunderestimate the
importance of correct prefix usage in English.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Antoine Pitrou wrote:
We might allow the creation of traceback objects, but without any custom
frame objects it is unclear how useful that would be.
When I was implementing Pyrex, I would have found it
very useful to be able to create Traceback objects
without Frames, but only if the Traceback
Steven D'Aprano wrote:
Return the value for key if key is in the dictionary, else default.
If default is not given, it defaults to None, so that this method
never raises a KeyError.
I think that's supposed to mean that it won't raise
KeyError as a result of the key not being in
Chris Angelico wrote:
On Sat, Feb 22, 2014 at 10:57 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
I'm still not convinced it would be all *that* difficult.
Seems to me it would be semantically equivalent to
renaming the inner variable and adding a finally clause
to unbind
Nick Coghlan wrote:
On 21 February 2014 13:15, Chris Angelico ros...@gmail.com wrote:
Generator expressions require parentheses, unless they would be
strictly redundant. Ambiguities with except expressions could be
resolved in the same way, forcing nested except-in-except trees to be
Antoine Pitrou wrote:
lst = [1, 2]
value = lst[2] except IndexError: No value
the gain in concision is counterbalanced by a loss in
readability,
This version might be more readable:
value = lst[2] except No value if IndexError
since it puts the normal and exceptional values next
Nick Coghlan wrote:
As Chris later noted, you likely *could* still implement expression
local name binding for an except expression without a full closure, it
would just be rather difficult.
I'm still not convinced it would be all *that* difficult.
Seems to me it would be semantically
Eli Bendersky wrote:
For instance, it is sometime non-trivial to know which exceptions some
function may throw. When you write a try...raise statement, you think
hard about covering all the bases. In an expression you're unlikely to,
Speak for yourself. I don't think I would put any less
Chris Angelico wrote:
it wouldn't be that big a deal to completely reject multiple except
clauses and simply require that the
(rest of original post truncated)
Oh, no! The PSU has gotten wind of this proposal and doesn't
like it!
--
Greg
___
Ethan Furman wrote:
On 02/21/2014 03:29 PM, Greg Ewing wrote:
value = lst[2] except No value if IndexError
It does read nicely, and is fine for the single, non-nested, case (which
is probably the vast majority), but how would it handle nested exceptions?
Hmmm, probably not very well
Steven D'Aprano wrote:
result = computation(
int(arg) except ValueError: abort(Invalid int)
)
Actually, not quite so nice as I first thought, since you're relying on
the side-effects of abort() rather than returning a value.
Yeah, while I was writing
On 20/02/14 08:23, Glenn Linderman wrote:
Of course it is not backwards compatible... but once all the database related
None usage is switched to Null usage it should work the same as before,
My problem with this is that there is no clear distinction
between database-related None usage and
Georg Brandl wrote:
Seeing how you need a key function in any case for this sort to work,
it's only the or mindate added, which I can't recognize as ridiculous
amount of boilerplate.
Well, I don't much like having to construct a key
function in the first place for something as common
as
M.-A. Lemburg wrote:
The alternative would be adding a new singleton to mean mostly
the same thing as None, but having the property of comparing
less than all other objects and then recommend its use in the
DB-API for Python 3 applications...
Which I think would be a *really bad* idea, because
Tim Peters wrote:
Guido wanted to drop all the arbitrary but consistent mixed-type
comparison crud for Python 3.
Nobody is asking for a return to the arbitrary-but-
[in]consistent mess of Python 2, only to bring
back *one* special case, i.e. None comparing less
than everything else.
I think
Terry Reedy wrote:
To make None a true bottom object, the rich comparison
methods would have to special-case None as either argument before
looking at the __rc__ special methods of either.
I don't think it would be necessary to go that far.
It would be sufficient to put the special case
Tim Peters wrote:
[Greg Ewing]
often
one wants to sort a collection of objects having
keys that can take on null values.
Perhaps that's often true of your code, but it's never been true of mine.
It's fairly common in accounting circles. I have a
collection of invoices, each of which can
Larry Hastings wrote:
3) We hold off on merging the rest of the Derby patches until after
3.4.0 final ships, then we merge them into the 3.4 maintenance branch so
they go into 3.4.1.
But wouldn't that be introducing a new feature into a
maintenance release? (I.e. some functions that didn't
Brett Cannon wrote:
On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum r...@rachum.com
mailto:r...@rachum.com wrote:
lambda (x, y): whatever
http://python.org/dev/peps/pep-3113/
Part of the rationale in that PEP is that argument unpacking
can always be replaced by an explicitly named
Nick Coghlan wrote:
I have a different proposal: let's *just* add mod formatting to bytes,
and leave the extensible formatting system as a text only operation.
+1
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Neil Schemenauer wrote:
Objects that implement __str__ can also implement __bytes__ if they
can guarantee that ASCII characters are always returned,
I think __ascii_ would be a better name. I'd expect
a method called __bytes__ on an int to return some
version of its binary value.
--
Greg
Ethan Furman wrote:
Well, I'm not sure what booted into touch means,
It's a rugby term, referring to kicking the ball
over the touch line.
As a metaphor, it seems to mean making a problem
go away.
--
Greg
___
Python-Dev mailing list
Glenn Linderman wrote:
x = 354
b%c % x
Is this an intended exception to the overriding principle?
I think it's an unavoidable one, unless we want to
introduce an integer in the range 0-255 type. But
that would just push the problem into another place,
since
b%c % byte(x)
would then blow
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
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
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
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
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' ==
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
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:
Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
b'%s' % 'x' == b'x' (i.e. the three-byte string containing an 'x'
enclosed in single quotes)
I'm not sure about the quotes. Would anyone ever
Glenn Linderman wrote:
Quotes in the stream are a great debug hint, without blowing up.
But do you really want those quotes turning up in
a *binary* stream, where they're somewhere between
awkward and near-impossible to spot by eyeballing,
and may only be discovered when something else --
Nick Coghlan wrote:
By allowing format characters that *do* assume ASCII, the entire
construct is rendered unsafe - you have to look inside the format
string to determine if it is assuming ASCII compatibility or not, thus
the entire construct must be deemed as assuming ASCII compatibility at
the
Nick Coghlan wrote:
so the latter would be less of
an attractive nuisance when writing code that needs to handle arbitrary
binary formats and can't assume ASCII compatibility.
Hang on a moment. What do you mean by code that
handles arbitrary binary formats?
As far as I can see, the
Stephen J. Turnbull wrote:
PBP doesn't think it's a great idea to pass around bytes that are
implicitly some other type, but didn't mind it (or got used to it) in
Python 2, and so they're not looking at that as a problem that Python
3 can solve. They're looking at Python 3 as the problem that
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.
I would say that ASCII compatible binary data is a
*subset* of arbitrary binary data. As
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 argument when using %s in a bytes
formatting
501 - 600 of 2277 matches
Mail list logo
