On 17 November 2013 01:34, Maciej Fijalkowski wrote:
> On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote:
>> On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote:
>>> On 16 November 2013 23:17, Maciej Fijalkowski wrote:
>>>> On Sat, Nov 16, 2013 at 3:51 AM
oy the very
people that actually rely on the feature that is up for removal or
replacement, when you *really* want them engaged and clearly
explaining their use cases.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 17 Nov 2013 04:45, "Eric Snow" wrote:
>
> On Sat, Nov 16, 2013 at 11:15 AM, Antoine Pitrou
wrote:
> >
> > Hello,
> >
> > Alexandre Vassalotti (thanks a lot!) has recently finalized his work on
> > the PEP 3154 implementation - pickle protocol 4.
> >
> > I think it would be good to get the PEP
On 17 Nov 2013 09:48, "Brett Cannon" wrote:
>
>
> I personally think it would be a good idea to re-arrange the files to
make things more beginner-friendly. I believe Nick was also talking about
renaming directories, etc. at some point.
Yeah, the main ones I am interested in are a separate "Progra
On 19 Nov 2013 08:52, "Tim Peters" wrote:
>
> [Tim]
> >> But it has a different kind of advantage: PREFETCH was optional. As
> >> Guido said, it's annoying to bloat the size of small pickles (which
> >> may, although individually small, occur in great numbers) by 8 bytes
> >> each. There's real
On 19 Nov 2013 09:33, "Tim Peters" wrote:
>
> [Antoine]
> > Well, sending oceans of tiny integers will also incur many system calls
> > and additional synchronization costs, since sending data on a
> > multiprocessing Queue has to acquire a semaphore. So it generally
> > sounds like a bad idea, IM
verhead; and the max frame size is 2**61 rather than
> 2**64, which should still be sufficient.
>
> And the frame size is read using either one or two read() calls, which
> is efficient.
And it's only a minimal change from the current patch. Sounds good to me.
Cheers,
Nick.
--
N
3.4
can't provide any context for failures in the bz2_codec input
validation, because that throws a stateful OSError that the chaining
system can't handle, and thus doesn't wrap)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 20 Nov 2013 10:48, "Victor Stinner" wrote:
>
> 2013/11/20 Guido van Rossum :
> > I'm guessing CF is the PEP-BDFL?
>
> Yes, you delegated him this PEP :-)
>
> > So he should approve it (the period for
> > final comments is long over) and then you can merge.
>
> I'm asking if the code *must* be m
Christian has indicated he now considers PEP 456, which adds an updated and
configurable hash algorithm ready for pronouncement (
http://www.python.org/dev/peps/pep-0456/)
I am happy the PEP and the associated implementation represent a desirable
improvement to CPython, and approve of the proposal
uld we please move discussion of hypothetical future divisions of
the codec namespace into additional APIs to python-ideas? We don't
even have consensus to restore the codecs module to parity with its
Python 2 functionality at this point, let alone agreement on adding
more convenience APIs f
On 21 Nov 2013 10:33, "Antoine Pitrou" wrote:
>
> On Wed, 20 Nov 2013 17:30:44 -0500
> Barry Warsaw wrote:
> > On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:
> >
> > >Many customers are forced to stick with Python 2.X because of other
products,
> > >but they require a Python 2.X version wh
Another alternative I'd prefer to an ABI version bump: backporting the "C
runtime independence" aspects of the stable ABI to Python 2.7.
There are only a relatively small number of APIs that lead to the
requirement for consistent C runtimes, so allowing those to be excluded at
compile time would m
On 22 Nov 2013 07:43, "Charles-François Natali" wrote:
>
> Hi,
>
> I'm happy to officially accept PEP 454 aka tracemalloc.
> The API has substantially improved over the past weeks, and is now
> both easy to use and suitable as a fundation for high-level tools for
> memory-profiling.
>
> Thanks to
On 22 Nov 2013 02:03, "Chris Barker - NOAA Federal"
wrote:
>
>
>>
>> with older releases (I admit I don't understand the ABI compatibility on
OSX).
>
>
> Well, with OS-X, it's not exactly the C lic in the same way, but there
are different SDKs for different OS versions, and you can add to that PPC
On 22 Nov 2013 09:02, "Victor Stinner" wrote:
>
> 2013/11/21 Nick Coghlan :
> > Huzzah! Thanks to you both for getting this ready for inclusion :)
>
> I now hope that someone will use it :-)
>
>
> By the way, collections.namedtuple has a private _source attrib
ld backport to 2.7.7 rather than Stackless making a 2.8 release
just to update to a backwards incompatible C runtime on Windows.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
time than the Visual Studio 2008 one.
I believe this approach would be substantially less confusing for the
broader community than trying to explain that a 2.8 release of
Stackless Python was really just a version bump for the Windows CRT
ABI.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@g
On 21 November 2013 21:31, wrote:
>
> Quoting Nick Coghlan :
>
>> Another alternative I'd prefer to an ABI version bump: backporting the "C
>> runtime independence" aspects of the stable ABI to Python 2.7.
>
> P.S. Thinking about this, there are som
On 22 Nov 2013 04:12, "Christian Heimes" wrote:
>
> Am 21.11.2013 18:57, schrieb Tim Peters:
> > Best to change the failing tests. For example, _they_ can sort the
> > dict keys if they rely on a fixed order. Sorting in general is a
> > dubious idea because it can be a major expense with no real
On 22 Nov 2013 10:58, "Steve Dower" wrote:
>
> Nick Coghlan wrote:
> > For 2.7.7, I think some combination of the two following ideas would be
worth
> > pursuing:
> > - a C runtime independent API flag (set by default on Windows when
building with
> > a
Windows ABI issue without the
Stackless community needing to take such a drastic step, though, so I
for one greatly appreciate Christian raising the question here and
giving us the opportunity to help out.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 24 Nov 2013 01:21, "Antoine Pitrou" wrote:
>
> On Sat, 23 Nov 2013 15:32:58 +0200
> Serhiy Storchaka wrote:
> > 22.11.13 18:44, Antoine Pitrou написав(ла):
> > > I've pushed pathlib to the repository. I'm hopeful there won't be
> > > new buildbot failures because of it, but still, there may be
On 24 Nov 2013 17:15, "Gregory P. Smith" wrote:
>
> our buildbots are setup to configure --with-pydebug which also
unfortunately causes them to compile with -O0... this results in a python
binary that is excruciatingly slow and makes the entire test suite run take
a long time.
>
> given that nobod
On 25 Nov 2013 09:07, "Ben Hoyt" wrote:
>
> > Right now, pathlib doesn't cache. Guido decided it was safer to start
> > off like that, and perhaps later we can add some optional caching.
> >
> > One reason caching didn't go in is that it's not clear which API is
> > best. Working on pluggin scandi
On 25 Nov 2013 09:14, "Ben Hoyt" wrote:
>
> >> 4) Is path_obj.glob() recursive? In the PEP it looks like it is if the
> >> pattern starts with '**',
> >
> >
> > I don't think it has to *start* with **. Rather, the ** is
> > a pattern that can span directory separators. It's not a
> > flag that app
On 25 Nov 2013 09:31, "Ben Hoyt" wrote:
>
> > It's also quite likely the "rich stat object" API will be pursued for
3.5,
> > which is a much safer approach to stat result caching than trying to
embed
> > it directly in pathlib.Path objects.
>
> As a Windows dev, I'm not sure I love the "rich stat
On 25 Nov 2013 09:42, "Ben Hoyt" wrote:
>
> > Using "**" for directory spanning globs is also another case of us
borrowing
> > a reasonably common idiom from *nix systems that may not be familiar to
> > Windows users.
>
> Okay, *nix wins then. :-) Python's stdlib is already fairly
> *nix-oriented
On 25 Nov 2013 13:18, "Ben Hoyt" wrote:
>
> > The idea of the rich stat result object is that has all that info
> > prepopulated, based on an initial stat call. "Caching" it amounts to
"keep a
> > reference to it".
> >
> > It is suggested that it would be a subset of the pathlib.Path API:
> > http
On 25 Nov 2013 14:46, "gregory.p.smith" wrote:
>
> http://hg.python.org/cpython/rev/cac7319c5972
> changeset: 87537:cac7319c5972
> branch: 2.7
> parent: 87534:3981e57a7bdc
> user:Gregory P. Smith
> date:Mon Nov 25 04:45:27 2013 +
> summary:
> Fix test_fcntl to ru
to be suitable for software development, but I guess that's
enterprise companies for you :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
own :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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/
and truly proven
he doesn't have either of those.
Anatoly has the entire rest of the internet to play in, we shouldn't
have to put up with his disruptions when we're actually trying to get
stuff done.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 1 Dec 2013 04:32, "Christian Heimes" wrote:
>
> Hi,
>
> Larry has granted me a special pardon to add an outstanding fix for SSL,
> http://bugs.python.org/issue19509 . Right now most stdlib modules
> (ftplib, imaplib, nntplib, poplib, smtplib) neither support server name
> indication (SNI) nor c
d due to point of exception != point of error)
- have setting check_hostname potentially affect verify_mode and
vice-versa (bad due to being implicit magic)
We wouldn't be able to make check_hostname read-only the way we would
if we added the configuration method now, but that doesn't b
On 1 December 2013 21:40, Antoine Pitrou wrote:
> On Sun, 1 Dec 2013 21:33:06 +1000
> Nick Coghlan wrote:
>>
>> If we don't do that, then I think Christian's approach is a reasonable
>> compromise given the late stage of the release cycle - it ensures
On 2 Dec 2013 21:18, "victor.stinner" wrote:
>
> http://hg.python.org/cpython/rev/b231e0c3fd26
> changeset: 87692:b231e0c3fd26
> branch: 3.3
> parent: 87690:7d3297f127ae
> user:Victor Stinner
> date:Mon Dec 02 12:16:46 2013 +0100
> summary:
> Issue #19728: Fix sys.ge
On 5 Dec 2013 00:41, "Brett Cannon" wrote:
>
> On 2008-12-03, Python 3.0.0 was released by Barry. I was actually on IRC
the night when it happened, with Guido leaving his office across the hall
from mine. We gave each other a high-five and then we both went home. Not
exactly a party, but I know I
On 12 Dec 2013 08:26, "Antoine Pitrou" wrote:
>
> On Wed, 11 Dec 2013 20:28:19 +0100 (CET)
> serhiy.storchaka wrote:
> > http://hg.python.org/cpython/rev/618cca51a27e
> > changeset: 87899:618cca51a27e
> > branch: 3.3
> > parent: 87896:46186736e91c
> > user:Serhiy Storchaka
>
type names) to limit the maximum length of error messages
(to add another variant to the mix, PEP 7 has "%.100s" in an example
about breaking long lines that happens to include reporting
TypeError).
The question should probably be addressed directly in PEP 7, and I'd
be inclined
ve to look at an existing example to
remember the exact incantation :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
On 16 Dec 2013 02:58, "Ethan Furman" wrote:
>
> 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
&g
On 17 Dec 2013 02:23, "Eric V. Smith" wrote:
>
> On 12/16/2013 10:29 AM, Walter Dörwald wrote:
> > I'd vote for including the module name in the string and using
> > __qualname__ instead of __name__, i.e. make "{:T}".format(obj)
> > equivalent to
> > "{0.__class__.__module__}.{0.__class__.qualname
On 18 Dec 2013 06:21, "Maciej Fijalkowski" wrote:
>
> On Tue, Dec 17, 2013 at 7:21 PM, Brett Cannon wrote:
> > Maybe someone from PyPy should bring this up as an official topic at the
> > language summit to figure out the blockers (again). Or it can join
regex on
> > the list of "module discussed
so that *everyone* can just
skip straight to 2.7.7.
That kind of user visible change shouldn't have been made in a point
release, regardless of what the docs said. It just isn't worth the
risk of breaking the code of people that are relying on what's
possible rath
(such as not initialising the
thread local storage for the GIL state APIs).
I don't see anything in your article about how you ensure that the
main thread of the application *before anything else related to the
embedded Python happens* calls both Py_Initialize() and
PyEval_InitThreads(). If
On 19 December 2013 21:28, Daniel Pocock wrote:
> On 19/12/13 12:22, Nick Coghlan wrote:
>> I don't see anything in your article about how you ensure that the
>> main thread of the application *before anything else related to the
>> embedded Python happens* call
n some cases *cough* ;)
Cheers,
Nick.
P.S. We're actively working on eliminating that particular rationale.
While some of the key elements have already been released, there's
still more work to be done :)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 6 Jan 2014 05:54, "Larry Hastings" wrote:
>
> On 01/05/2014 01:49 PM, Serhiy Storchaka wrote:
>>
>> But I very much upset by the fact that the generated code is written
mixed with written manually. It is difficult to navigate (list of symbols
now contains three times more names), makes it diffi
On 6 Jan 2014 22:15, "Brett Cannon" wrote:
>
>
>
>
> On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou
wrote:
>>
>> On Tue, 7 Jan 2014 00:54:17 +1100
>> Chris Angelico wrote:
>> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou
wrote:
>> > > BTW, there's a subtlety here: ``%s`` currently means "in
On 6 Jan 2014 22:56, "Brett Cannon" wrote:
>
>
>
>
> On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan wrote:
>>
>>
>> On 6 Jan 2014 22:15, "Brett Cannon" wrote:
>> >
>> >
>> >
>> >
>> > On Mon, Jan 6,
On 5 Jan 2014 12:54, "r.david.murray" wrote:
>
> http://hg.python.org/cpython/rev/069f88f4935f
> changeset: 88308:069f88f4935f
> user:R David Murray
> date:Sat Jan 04 23:52:50 2014 -0500
> summary:
> whatsnew: XMLPullParser, plus some doc updates.
>
> I was confused by the tex
For anyone that isn't already aware, I wrote a Q & A about Python 3 last
year (in response to an article about how we should have fixed the GIL
instead of Unicode), and I've updated it extensively over the past several
days due to Alex's misunderstanding of the objectives for Python 3.4 as
well as
On 7 Jan 2014 07:46, "Antoine Pitrou" wrote:
>
> I assume it's
>
http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html
Thanks, that's the one - I copied the link, but neglected to paste it in
before hitting send :P
Cheers,
Nick.
>
> Regards
>
> Antoine.
>
>
> __
On 7 Jan 2014 08:03, "Antoine Pitrou" wrote:
>
> On Tue, 7 Jan 2014 09:16:10 +1000
> Nick Coghlan wrote:
> > For anyone that isn't already aware, I wrote a Q & A about Python 3 last
> > year (in response to an article about how we should have fixed t
On 7 Jan 2014 18:18, "Donald Stufft" wrote:
>
> Given the low adoption rates for Python 3 it would not surprise me if
people
> who are hampered by the lack of this change are willing to wait until a
Python
> version is released that has it.
Once the code exists (regardless of the exact spelling),
On 8 Jan 2014 06:24, "Brett Cannon" wrote:
>
>
>
>
> On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah wrote:
>>
>> Antoine Pitrou wrote:
>> > Several solutions have been proposed:
>> > - move all generated code to separate C files, which would then be
>> > #included'd into the main module file
>>
>
MSI may be
looking for a new version to interpret that new setting.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubs
u need to
> *tell* Python what the encoding is. That's a brute fact of the world of
> text in computing.
Set the mode to "rb", process it as binary. Done.
See
http://python-notes.curiousefficiency.org/en/latest/python3/text_file_processing.html
for details.
st.
> ___
> 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/ncoghlan%40gmail.com
--
Nick Coghlan | ncogh.
>
> ___
> 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/ncoghlan%40gmail.com
--
Nick Coghlan | ncogh...@gmai
On 9 Jan 2014 11:29, "INADA Naoki" wrote:
>
>
>> And I think everyone was well intentioned - and python3 covers most of
the
>> bases, but working with binary data is not only a "wire-protocol
programmer's"
>> problem.
If you're working with binary data, use the binary API offered by bytes,
bytear
On 9 Jan 2014 22:08, "Antoine Pitrou" wrote:
>
> On Thu, 9 Jan 2014 09:03:40 -0500
> Daniel Holth wrote:
> > They emphatically do not want the Python 2
> > model especially not implicit coercion. They only want additional
> > tools for text or string processing in Python 3.
>
> That's a good poin
On 9 Jan 2014 22:25, "Kristján Valur Jónsson" wrote:
>
>
>
> > -Original Message-
> > From: Victor Stinner [mailto:victor.stin...@gmail.com]
> > Sent: 9. janúar 2014 13:51
> > To: Kristján Valur Jónsson
> > Cc: Antoine Pitrou; python-dev@python.org
> > Subject: Re: [Python-Dev] Python3 "co
On 9 Jan 2014 06:43, "Antoine Pitrou" wrote:
>
>
> Hi,
>
> With Victor's consent, I overhauled PEP 460 and made the feature set
> more restricted and consistent with the bytes/str separation.
+1
I was initially dubious about the idea, but the proposed semantics look
good to me.
We should probab
On 10 Jan 2014 03:32, "Antoine Pitrou" wrote:
>
> On Fri, 10 Jan 2014 05:26:04 +1000
> Nick Coghlan wrote:
> >
> > We should probably include format_map for consistency with the str API.
>
> Yes, you're right.
>
> > >However, I
> > >
heckins mailing list
>> python-check...@python.org
>> https://mail.python.org/mailman/listinfo/python-checkins
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
&g
list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
the
approach, but we won't know for sure until people actually try it
out).
Fortunately, after years of my suggesting the idea to almost everyone
that complained about the move away from the broken POSIX text model
in Python 3, Benno Rice has started experimenting with such a type
based
ng it with me at LCA, Benno Rice offered
to try out the idea, just to determine whether or not it was actually
possible. If there are any CPython bugs that mean the idea *doesn't*
currently work (such as interoperability issues in the core types),
then I'm certainly happy for us to fix *tho
acher) have also struggled with
that distinction, I added a new question and answer to my Python 3
Q&A:
http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#what-actually-changed-in-the-text-model-between-python-2-and-python-3
Cheers,
Nick.
--
Nick Coghlan
eir own extension
type to figure out what the API should look like. Jamming speculative
API design into the core text model without experimenting in a third
party extension first is a straight up stupid idea.
Anyone that is pushing for this should be checking out Benno's first
draft experimental pr
On 12 Jan 2014 03:29, "Ethan Furman" wrote:
>
> 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 t
On 12 Jan 2014 03:44, "Victor Stinner" wrote:
>
> Hi,
>
> I'm in favor of adding support of formatting integer and floatting
> point numbers in the PEP 460: %d, %u, %o, %x, %f with padding and
> precision (%10d, %010d, %1.5f) and sign (%-i, %+i) but without
> alternate format ("{:#x}"). %s would a
ch stuffed, as you get
lost in a mazy of twisty values, as the same data type is used with
very different semantics, depending on which end of a data
transformation you're on (although sometimes you'll get a different
data type, depending on the data *values* involved).
Cheers,
Nick.
--
On 12 January 2014 02:33, M.-A. Lemburg wrote:
> On 11.01.2014 16:34, Nick Coghlan wrote:
>> While that was an *expedient* (and, in fact, necessary) solution at
>> the time, the fact it is still thoroughly confusing people 13 years
>> later shows it is not a *comprehensible*
so that's an option definitely worth
considered if a project would like to support Python 3, but are having
difficulty getting their with purely volunteer effort.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
19097: Raise the correct Exception when cgi.FieldStorage is given an
> + Invalid fileobj.
You may want to tweak the tracker so the comment ends up on the
appropriate issue (#19092 is something else entirely)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.co
On 12 Jan 2014 21:53, "Juraj Sukop" wrote:
>
>
>
>
> On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano
wrote:
>>
>> On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote:
>>
>> > AFAIK (and just for the record), there could be both Latin1 text and
UTF-16
>> > in a PDF (and other encodin
On 12 Jan 2014 22:10, "Paul Moore" wrote:
>
> On 12 January 2014 09:23, Georg Brandl wrote:
> >> On 12 January 2014 01:01, Victor Stinner
wrote:
> >>> Supporting formating integers would allow to write b"Content-Length:
> >>> %s\r\n" % 123, which would work on Python 2 and Python 3.
> >>
> >> I'
Hi Nachson,
Python 2.7 with the -3 warning flag covers most of this, while using tox to
run automated tests under both 2.x and 3.x should cover the rest (tox is
also useful for checking code runs under Python 2.6, even if you normally
use a newer version).
Is there anything in particular you feel
On 12 Jan 2014 23:39, "Nachshon David Armon"
wrote:
>
> Hi,
> I am Nachshon and this is my first post to the python mailing list.
>
> I have been porting some libraries from python 2 to python 3 recently
with the goal of a common codebase that will run on both versions. I was
thinking it would mak
On 13 Jan 2014 01:22, "Kristján Valur Jónsson"
wrote:
>
>
> Well, my suggestion would that we _should_ make it work, by having the %s
format specifyer on bytes objects mean: str(arg).encode('ascii', 'strict')
> It would be an explicit encoding operator with a known, fixed, and well
specified encod
that it be considered since at least 2010). The problem
with "str" in Python 2 was that one type was used to represent too
many things with serious semantic differences.
The ongoing attempts to reintroduce that ambiguity to the core bytes
type rather than exploring
uot;I wish the Python 3 bytes type
was more like the Python 2 str type" and instead think "hmm, the
Python 3 bytes type doesn't seem like a great fit for my use case,
maybe I need a different type".
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austr
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
>> bin
On 13 Jan 2014 17:14, "Donald Stufft" wrote:
>
>
> On Jan 13, 2014, at 1:59 AM, Nick Coghlan wrote:
>
> > On 13 January 2014 16:52, Donald Stufft wrote:
> >>
> >> On Jan 13, 2014, at 12:45 AM, Glenn Linderman
wrote:
> >>
> >>
core builtin types, because we're in a better position to fix
interoperability issues now that
we don't have to deal with the close coupling between str and unicode
that existed in Python 2, and the bytes type will generally play nice
with anything that exposes the PEP 3118 buffer interfa
On 13 January 2014 17:15, Guido van Rossum wrote:
> On Sun, Jan 12, 2014 at 10:59 PM, Nick Coghlan wrote:
>> All it takes is to let go of the idea "I wish the Python 3 bytes type
>> was more like the Python 2 str type" and instead think "hmm, the
>> Python 3
a trivial bug fix (adding
the necessary "b", and perhaps some explicit encoding calls) rather
than a major restructuring of the code.
If they use mod-formatting, that's a slightly bigger fix, but still
just switching to a different spelling of the formatting operation.
Both u
e, and stores a bunch of
other state directly on the C stack.
I don't see anything *intrinsically* impossible about the idea, it
just wouldn't be easy, since you'd have to come up with a way of
dealing with that C level state that didn't slow down normal
operation.
Cheers,
Nick.
--
Nick
e are calling for a shortened 3.5 release cycle -
> I'd rather not see that happen, for the aforementioned reason of wanting
> time to make sure this is Right - it'd be a shame to do the work and rush it
> out only to find something missing in an important way.
By shortened, we&
On 14 January 2014 01:54, Ethan Furman wrote:
> 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 stro
On 14 Jan 2014 03:34, "Guido van Rossum" wrote:
>
> On Mon, Jan 13, 2014 at 8:51 AM, Nick Coghlan wrote:
> > On 13 January 2014 23:57, Augie Fackler wrote:
> >> 1) What do we need in terms of functionality
> >>
> >> Best guess, %s, %d, and %f.
On 14 Jan 2014 04:58, "Guido van Rossum" wrote:
>
> Let me try rebooting the reboot.
>
> My interpretation of Nick's argument is that he are asking for a bytes
> formatting language that doesn't have an implicit ASCII assumption.
>
> To me this feels absurd. The formatting codes (%s, %c) themselve
sed,
since this observation makes it clear that there's *no* coherent way
to offer a pure binary interpolation API - the only general purpose
combination mechanism for segments of binary data that can avoid
making assumptions about the encodings of
e "interesting" issues getting formatting to
produce anything other than text (contrary to what I said elsewhere in
these threads - I hadn't thought through the full implications at the
time).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 14 January 2014 16:04, Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 9:34 PM, Nick Coghlan 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
On 14 Jan 2014 19:11, "Stephen J. Turnbull" 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
sers of ASCII incompatible encodings (mostly in Asia) being
the main one, but I think the increased convenience in working with
ASCII compatible binary protocols and file formats is worth the cost.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
1101 - 1200 of 6587 matches
Mail list logo
