obj) as the coerce-to-str API
- os.fspath(pathlib.PurePath(obj)) as the error-on-bytes API
That more strongly nudges people towards "use pathlib if you want to
ensure cross-platform friendly path handling", which is an outcome I'm
fine with.
Cheers,
Nick.
--
Nick Coghlan |
;t have any use cases for a bytes-only API - only str-or-bytes
(in the polymorphic low level functions) and str-only (in newer high
level APIs like pathlib).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev
ritance from the relevant builtin type was
previously the only option, retaining that behaviour is also the only
way to avoid a performance regression for those subclasses.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
P
nd clean up resource allocations.
Switching it over to the suggested PyGC_CollectIfEnabled() API should
be fine though - it will just need to be documented that calling
Py_Initialize again in the same process is unsupported if you have the
GC disabled dur
ectly.
What that means is that any time we want to expose thread local state
to both C and Python code, it will generally be the responsibility of
the C code to both manage the key in the thread state dict (or the
field in the thread state struct), and also to provide a Python API
for access t
g extensions for older Python
versions (since you need to make sure the binaries are compatible),
but that's not a topic devinabox concerns itself with.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-De
On 31 May 2016 3:12 pm, "Glenn Linderman" wrote:
>
> On 5/31/2016 12:55 PM, rndblnch wrote:
>>
>> Guido van Rossum gmail.com> writes:
>>
>>>
>>> Also -- the most important thing. What to call these things? We're
>>> pretty much settled on the semantics and how to create them (A =
>>> NewType('A'
On 19 Oct 2013 02:56, "Brett Cannon" wrote:
>
> importlib.machinery.FileFinder does a stat call to check if a path is a
file if the package check failed. Now I'm willing to bet that the check is
rather redundant as the file extension should be a dead give-away that
something in a directory is a fi
On 19 Oct 2013 03:57, "Charles-François Natali" wrote:
>
> Hi,
>
> I'm happy to see this move forward!
Speaking of which... Charles-François, would you be willing to act as
BDFL-Delegate for this PEP? This will be a very useful new analysis tool,
and between yourself and Victor it looks like you'
On 19 Oct 2013 02:01, "brett.cannon" wrote:
>
> http://hg.python.org/cpython/rev/33844153cd02
> changeset: 86438:33844153cd02
> user:Brett Cannon
> date:Fri Oct 18 12:01:06 2013 -0400
> summary:
> Issue #18416: Fix various os calls in importlib.machinery.FileFinder
> now that
On 19 Oct 2013 03:24, "brett.cannon" wrote:
>
> http://hg.python.org/cpython/rev/11f2f4af1979
> changeset: 86444:11f2f4af1979
> user:Brett Cannon
> date:Fri Oct 18 13:24:13 2013 -0400
> summary:
> Issue #18810: Be optimistic with stat calls when seeing if a directory
> exists
it permits arbitrary "bail out now" behaviour (by
passing the exit label to other operations), but the fact every label
uses a custom exception type derived directly from BaseException would
mean it still ends up being quite heavily constrained (since the
*only* thing it would be able to
raise ValueError(msg)
ValueError: no signature found for builtin function
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
hich can be awkward, but that awkwardness
> isn't really demonstrated in the example. "exit_label" is an awkward name,
> too, since there are no labels, and no exit(). (yes, I know you meant exit
> the loop; naming is hard.)
You exit with statements - that's why the final
e it should be explicitly
recorded somewhere in the language reference, I'm just not sure where.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
rk that way may then help to
enlighten them as to the true nature of the underlying construct.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailm
On 19 October 2013 22:53, Antoine Pitrou wrote:
> On Sat, 19 Oct 2013 21:41:17 +1000
> Nick Coghlan wrote:
>>
>> Having noticed the discrepancy, I feel like it should be explicitly
>> recorded somewhere in the language reference, I'm just not sure where.
>
> S
a
> proper review from real experts. This stuff is super complex and highly
> fragile. :(
At the very least, it would be good if you and/or MAL could review the
cert verification in pip. PEP 453 makes that kinda important :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gm
appropriate name.
>>
>> What am I missing?
>
>
> ``if cache_module in cache:``, the line above the _path_join() call and the
> guard that blocks the entire package search.
Ah, that's what I get for reviewing diffs on my phone and hence not
looking up the full context :)
On 20 October 2013 00:44, Christian Heimes wrote:
> Am 19.10.2013 16:14, schrieb Nick Coghlan:
>> At the very least, it would be good if you and/or MAL could review
>> the cert verification in pip. PEP 453 makes that kinda important
>> :)
>
> Where can I find the code
.org/all/builders/AMD64%20OpenIndiana%203.x/builds/6535/steps/compile/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/204/steps/compile/logs/stdio
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 20 Oct 2013 06:14, "Glenn Linderman" wrote:
>
> On 10/19/2013 12:46 PM, Ian Cordasco wrote:
>>
>> Also the three of us maintaining requests and the author of urllib3
>> are all very conscious that the packaged pem file is outdated. We have
>> an open issue about how to rebuild it accurately whi
equests`` project (and hence ``pip``).
====
Regards,
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.pyt
On 20 October 2013 16:08, Armin Rigo wrote:
> Hi Nick,
>
> On Sat, Oct 19, 2013 at 1:41 PM, Nick Coghlan wrote:
>> recreating the *exact* exception subclass check from
>> Python is actually difficult these days.
>
> Can't it be done roughly like that?
>
&
his change was likely backwards
incompatible with cross-version Windows installers created with previous
versions of Python, so the change has been removed from this PEP
[#windows-incompatibility]_.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 21 Oct 2013 12:44, "Raymond Hettinger"
wrote:
>
> Two of the new context managers in contextlib are now wrapped in
pass-through factory functions. The intent is to make the help() look
cleaner. This practice does have downsides however.
>
> The usual way to detect whether something is usable
On 21 Oct 2013 21:22, "R. David Murray" wrote:
>
> On Mon, 21 Oct 2013 12:11:57 +0100, Paul Moore
wrote:
> > On 21 October 2013 11:59, R. David Murray wrote:
> > > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman
wrote:
> > >> On 10/20/2013 07:42 PM, Raymond Hettinger wrote:
> > >> >
> > >> > I
On 21 Oct 2013 22:10, "Antoine Pitrou" wrote:
>
> Le Mon, 21 Oct 2013 20:46:39 +1000,
> Nick Coghlan a écrit :
> > On 21 Oct 2013 12:44, "Raymond Hettinger"
> > wrote:
> > >
> > > Two of the new context managers in contextlib are now wr
On 21 Oct 2013 23:54, "Antoine Pitrou" wrote:
>
> Le Mon, 21 Oct 2013 23:12:40 +1000,
> Nick Coghlan a écrit :
> > On 21 Oct 2013 22:10, "Antoine Pitrou" wrote:
> > >
> > > Le Mon, 21 Oct 2013 20:46:39 +1000,
> > > Nick Coghl
On 22 October 2013 19:33, "Martin v. Löwis" wrote:
> Am 20.10.13 14:27, schrieb Nick Coghlan:
>> I have posted the latest version of PEP 453 to python.org.
>
> This version looks good to me, and I accept it for inclusion in Python 3.4.
>
> I'd like to thank
On 24 Oct 2013 03:37, "hakril lse" wrote:
>
> Hi,
>
> I have a question about a choice of implementation concerning
> 'superobject' with the descriptors.
>
> When a 'superobject' looks for a given attribute, it runs through the
> mro of the object.
> If it finds a descriptor, the 'superobject' cal
e PEP should explicitly state that any such omissions will
be treated as bugs in the 3.4.x series (although we'll aim to handle
them all in the initial implementation).
Thanks for recording the details of the earlier off-list discussion :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.c
ased
filters, and it's unlikely I'll be adding it any time soon, deferring
a stat caching design sounds like a reasonable idea to me.
> Still, I need to find someone to pronounce on it.
I'd offer, but I already have a scary number of things I need to get
done by beta 1 :P
(or switch
to a lab server with the same CPU architecture but more RAM).
If Victor were only interested in analysing x86[_64] software, I'd
agree with you, but embedded scenarios don't always offer that freedom
to do resource consumption analysis on a more powerful system.
Chee
On 25 Oct 2013 06:42, "Barry Warsaw" wrote:
>
> On Oct 24, 2013, at 01:12 PM, Ned Deily wrote:
>
> >Yes, this problem also affects 2.6. There are some mitigating factors.
The
> >support for libedit on OS X is only enabled when building for an OS X
10.5 or
> >later ABI because in earlier releases
On 25 Oct 2013 09:02, "Terry Reedy" wrote:
>
> Progess on the Python3 as 'standard Python' front: Yesterday, FESCO
(Fedora Steering Committee?) approved a proposal to make Python 3 (version
unspecified, I presume 3.3 or 3.4) the default Python in Fedora 22 (I did
not see a date anywhere).
The cur
cit finder + loader
>> use-case.
>
> Yeah, it actually was to ensure that you could reload a module using a
> different loader than the one that originally loaded it, e.g. due to a
> change in path hooks, etc.
Yeah, the rationale makes sense, we only missed it due to the lack of
a regres
TRINGS,
>>
>>
>> I think that does not detect --without-doc-strings (i.e. the C docstrings
>> are
>> empty).
>
>
> Indeed. HAVE_DOCSTRINGS was introduced to skip tests for the C docstrings.
> Python docstrings tests are skipped if
On 27 October 2013 03:32, Nick Coghlan wrote:
> On 27 October 2013 01:10, Serhiy Storchaka wrote:
>> 26.10.13 15:50, Stefan Krah написав(ла):
>>
>>> nick.coghlan wrote:
>>>>
>>>> http://hg.python.org/cpython/rev/a9bbc2d0c1dc
>>>
On 27 Oct 2013 04:16, "Serhiy Storchaka" wrote:
>
> 26.10.13 20:32, Nick Coghlan написав(ла):
>
>> On 27 October 2013 01:10, Serhiy Storchaka wrote:
>>>
>>> 26.10.13 15:50, Stefan Krah написав(ла):
>>>
>>>> nick.coghlan wrote:
On 27 October 2013 03:27, Nick Coghlan wrote:
> On 26 October 2013 08:51, PJ Eby wrote:
>> Mostly, this just seems like an ugly wart -- Python should be dynamic
>> by default, and that includes reloading. While the import machinery
>> has lots of ugly caching under t
On 27 October 2013 14:29, Eric Snow wrote:
> On Sat, Oct 26, 2013 at 9:44 PM, Nick Coghlan wrote:
>> Accordingly, I think we should add a "How Reloading Will Work"
>> section, akin to the existing "How Loading Will Work"
>> (http://www.python.org/dev/
On 28 Oct 2013 02:37, "PJ Eby" wrote:
>
> On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote:
> > Now, regarding the signature of exec_module(): I'm back to believing
> > that loaders should receive a clear indication that a reload is taking
> > place. Leg
On 28 Oct 2013 08:41, "PJ Eby" wrote:
>
> On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan wrote:
> >
> > On 28 Oct 2013 02:37, "PJ Eby" wrote:
> >>
> >> On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan
wrote:
> >> > Now, regardi
On 29 Oct 2013 14:45, "Eric Snow" wrote:
>
> On Sat, Oct 26, 2013 at 11:03 PM, Nick Coghlan wrote:
> > I don't think we can postpone it to later, as we need to be clear on:
> >
> > 1. Does reload use __name__ or __spec__.name when both are available?
&
nges to 3.4 to me :)
/me should take another run at the known crasher tests one of these
days. Maybe during the beta cycle...
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.or
location in the Python test suite for example.
>
> Tarek Ziadé asked on Twitter if there is a tool to track the origin of
> the object:
> "I wonder is there's a tool to trace back objects declarations that
> raise ResourceWarning in Py"
> https://twitter.com/t
On 30 October 2013 09:02, Eric Snow wrote:
> On Tue, Oct 29, 2013 at 3:32 AM, Nick Coghlan wrote:
>> On 29 Oct 2013 14:45, "Eric Snow" wrote:
>>> I'd rather give loaders another optional method:
>>> supports_reload(name). Complicating the spec methods
On 31 Oct 2013 03:41, "Eric Snow" wrote:
>
> On Tue, Oct 29, 2013 at 7:29 PM, Nick Coghlan wrote:
> > OK, time for me to stop trying to remember the details of the problem
> > I'm trying to solve and go look them up in the source code :)
> >
> >
On 31 Oct 2013 08:54, "Eric Snow" wrote:
>
> On Wed, Oct 30, 2013 at 4:09 PM, Nick Coghlan wrote:
> > On 31 Oct 2013 03:41, "Eric Snow" wrote:
> >> Our recent discovery about reloading should probably be reflected in
> >> the signature of finder
On 31 Oct 2013 18:52, "Eric Snow" wrote:
>
> On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan wrote:
> > There's also the option of implementing the constraint directly in the
> > finder, which *does* have the necessary info (with the change to pass
the
> > p
On 1 Nov 2013 01:37, "PJ Eby" wrote:
. ;-)
>
> I also suspect, that if properly spelled out, those use cases are
> going to boil down to:
>
> 1. Throwing errors if you have an existing module object you can't
> load into, and
> 2. Passing in a previous spec object, if available
>
> In other words
odule being loaded, it's just an indication to the finder that the
target namespace for execution will be a pre-existing module rather
than a new one.
For the same reason, I also have a mild preference for "target" (or
the more explicit "l
On 3 November 2013 01:21, Brett Cannon wrote:
> On Sat, Nov 2, 2013 at 5:46 AM, Nick Coghlan wrote:
>> For the same reason, I also have a mild preference for "target" (or
>> the more explicit "load_target") as the name, although I won't object
>> i
On 4 Nov 2013 03:00, "R. David Murray" wrote:
>
> I came across this in the VIM documentation:
>
> Vim can be built in four ways (:version output):
> 1. No Python support(-python, -python3)
> 2. Python 2 support only(+python or +python/dyn, -python3)
> 3. Python 3 suppo
On 5 Nov 2013 02:03, "Guido van Rossum" wrote:
>
> Two more approaches that can help when you haven't pushed yet:
>
> - hg rollback undoes the most recent local commit while leaving the local
workspace unchanged so the files are now patched but not committed
>
> - hg strip deletes a revision and
On 5 Nov 2013 08:49, "Larry Hastings" wrote:
>
>
>
> When Clinic generates a function, it knows what kind of callable it
represents, and it names the first argument (the "PyObject *") accordingly:
> module-level function ("self"),
> method ("self"),
> class method ("cls"), or
> class static ("null
On 5 Nov 2013 17:19, "Stefan Behnel" wrote:
>
> Larry Hastings, 04.11.2013 23:47:
> > When Clinic generates a function, it knows what kind of callable it
> > represents, and it names the first argument (the "PyObject *")
accordingly:
> >
> > * module-level function ("self"),
> > * method ("self"
On 6 Nov 2013 15:02, "Ethan Furman" wrote:
>
> http://bugs.python.org/issue19332
>
> Summary:
>
> --> d = {1: 'one'}
> --> for k in d:
> ... d[k+1] = d[k] * k
> ...
> Traceback (most recent call last):
> File "", line 1, in
> RuntimeError: dictionary changed size during iteration
>
> --> for
On 7 Nov 2013 03:18, "Antoine Pitrou" wrote:
>
> Le 06/11/2013 06:41, Nick Coghlan a écrit :
>
>>
>> The behaviour of mutating builtin containers while iterating over them
>> is formally undefined beyond "it won't segfault" (one of the few suc
On 7 Nov 2013 21:34, "Victor Stinner" wrote:
>
> 2013/11/7 Steven D'Aprano :
> > My initial instinct here was to say that sounded like premature
> > optimization, but to my surprise the overhead of generating the error
> > message is actually significant -- at least from pure Python 3.3 code.
>
>
On 8 Nov 2013 04:42, Martin v. Löwis wrote:
>
> Am 07.11.13 13:44, schrieb Thomas Heller:
>
> > I thought that the stable API would keep exactly the same across
> > releases - is this expectation wrong or is this a bug?
>
> Oscar is right - this change doesn't affect the ABI, just the API.
>
> Tha
On 8 Nov 2013 04:44, "Brett Cannon" wrote:
> On Thu, Nov 7, 2013 at 7:41 AM, Nick Coghlan wrote:
>>
>> The bigger problem is you can't change the constructor signature in a
backwards incompatible way. You would need a new class method as an
alternative constructor
On 8 Nov 2013 04:18, "Christian Heimes" wrote:
>
> Hi,
>
> I'd like to simplify, unify and tighten SSL handling and verification
> code in Python 3.5. Therefore I propose to deprecate some features for
> Python 3.4. SSLContext objects are going to be the central instance for
> configuration.
>
> I
New C APIs should either be documented or have an underscore prefix.
Also, if they're part of the stable ABI, they need a version guard.
Wishlist item: an automated ABI checker that can diff the exported symbols
against a reference list (Could ctypes or cffi be used for that?)
As long as this ki
On 7 Nov 2013 04:06, "victor.stinner" wrote:
>
> http://hg.python.org/cpython/rev/69071054b42f
> changeset: 86968:69071054b42f
> user:Victor Stinner
> date:Wed Nov 06 18:58:22 2013 +0100
> summary:
> Issue #19512: Add a new _PyDict_DelItemId() function, similar to
> PyDict_Del
On 8 Nov 2013 09:45, "Victor Stinner" wrote:
>
> Hi,
>
> [PyRun_InteractiveOneObject()]
>
> 2013/11/8 Nick Coghlan :
> > New C APIs should either be documented or have an underscore prefix.
>
> I created the issue #19518 to add documentation (but also to ad
On 8 Nov 2013 09:48, "Victor Stinner" wrote:
>
> 2013/11/8 Nick Coghlan :
> >> http://hg.python.org/cpython/rev/69071054b42f
> >> changeset: 86968:69071054b42f
> >> user:Victor Stinner
> >> date:Wed Nov 06 18:58:22 201
On 8 Nov 2013 10:15, "Eric Snow" wrote:
>
> On Thu, Nov 7, 2013 at 4:55 PM, Victor Stinner
wrote:
> > About the 72523 functions PyRun_xxx(), I don't understand something.
> > The PyRun_FileEx() is documented in the Python "very high" C API to
> > use Python. But this function is not part of the s
On 8 Nov 2013 22:03, "Thomas Heller" wrote:
>
> Am 08.11.2013 12:19, schrieb Victor Stinner:
>
>> 2013/11/8 Nick Coghlan :
>>>>
>>>> In Python 3.3, _PyDict_GetItemIdWithError(), _PyDict_GetItemId() and
>>>> _PyDict_SetItemId() are
On 9 Nov 2013 02:41, "Christian Heimes" wrote:
>
> Am 08.11.2013 08:42, schrieb Antoine Pitrou:
> > 3.2 actually, while many code bases are still 2.x-compatible.
> > There's no need to make migration more annoying right now.
>
> There is also no need to hinder and delay future improvements for the
upgrade to the import
system than my indirect import idea that originally spawned the discussion
on import-sig :)
Cheers,
Nick.
>
>
> On Fri, Nov 8, 2013 at 2:49 PM, Eric Snow
wrote:
>>
>> I'm pleased to announce that Brett Cannon and Nick Coghlan (the
>> co-BDFL-
On 13 Nov 2013 07:18, "Victor Stinner" wrote:
>
> Please tell me if you know sandbox projects for Python so I can
> redirect users of pysandbox to a safer solution. I already know PyPy
> sandbox.
Sandboxing is hard enough (see also the many JVM vulnerabilities) that the
only ones I even remotely
On 13 Nov 2013 13:44, "Ned Batchelder" wrote:
>
> On 11/12/13 6:48 PM, Terry Reedy wrote:
>>
>> On 11/12/2013 4:16 PM, Victor Stinner wrote:
>>
>>> It would also be nice to help developers looking for a sandbox for
>>> their application. Please tell me if you know sandbox projects for
>>> Python s
On 13 Nov 2013 12:11, "Christian Heimes" wrote:
>
> Am 13.11.2013 01:47, schrieb Glenn Linderman:
> > If it is an implementation issue, then perhaps a different
> > implementation would help. Or perhaps a "safe compiler".
> >
> > If it is a language design issue, then a different implementation
>
On 13 Nov 2013 09:56, "Josiah Carlson" wrote:
>
> Python-dev is for the development of the Python core language, the
CPython runtime, and libraries. Your sandbox, despite using and requiring
deep knowledge of the runtime, is not developing those things. If you had a
series of requests for the lang
.assertIn('family=%i' % socket.AF_INET, repr(s))
> AssertionError: 'family=2' not found in " family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=0,
> laddr=('0.0.0.0', 0)>"
I fixed this to turn the buildbots green again before committing the
codec e
2.7.7 a viable option:
http://bugs.python.org/issue19543
Regards,
Nick.
P.S. Until the next docs rebuild, you can see a summary of the
non-Unicode codec handling improvements in the What's New diff here:
http://hg.python.org/cpython/rev/854a2cea31b9
--
Nick Coghlan | ncogh..
On 14 November 2013 00:30, Walter Dörwald wrote:
> On 13.11.13 14:51, nick.coghlan wrote:
>
>> http://hg.python.org/cpython/rev/854a2cea31b9
>> changeset: 87084:854a2cea31b9
>> user:Nick Coghlan
>> date:Wed Nov 13 23:49:21 2013 +1000
>>
On 14 November 2013 02:12, Nick Coghlan wrote:
> On 14 November 2013 00:30, Walter Dörwald wrote:
>> On 13.11.13 14:51, nick.coghlan wrote:
>>
>>> http://hg.python.org/cpython/rev/854a2cea31b9
>>> changeset: 87084:854a2cea31b9
>>> user:Nick Cog
On 14 November 2013 01:43, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > The long gory history in http://bugs.python.org/issue7475 took a
> > different turn earlier this year when I noticed
> > (http://bugs.python.org/issue7475#msg187698) that the codecs
On 14 Nov 2013 10:40, "christian.heimes" wrote:
>
> http://hg.python.org/cpython/rev/99ba1772c469
> changeset: 87089:99ba1772c469
> user:Christian Heimes
> date:Thu Nov 14 01:39:35 2013 +0100
> summary:
> Issue #17828: va_start() must be accompanied by va_end()
> CID 1128793:
On 14 Nov 2013 13:52, wrote:
>
> results for 784a02ec2a26 on branch "default"
>
>
> test_codeccallbacks leaked [40, 40, 40] references, sum=120
> test_codeccallbacks leaked [40, 40, 40] memory blocks, sum=120
> test_codecs leaked [38, 38, 38] references
On 14 Nov 2013 21:58, "Nick Coghlan" wrote:
>
>
> On 14 Nov 2013 13:52, wrote:
> >
> > results for 784a02ec2a26 on branch "default"
> >
> >
> > test_codeccallbacks leaked [40, 40, 40] ref
On 15 Nov 2013 08:34, "Victor Stinner" wrote:
>
> Hi,
>
> I saw that Nick Coghlan documented codecs.encode() and
> codecs.decode(), and changed the exception raised when codecs like
> rot_13 are used on bytes.decode() and str.encode().
>
> I don't
Python 3's
binary codec support to stay broken instead :P
(Starting a new thread instead of replying to the one where I specifically
asked about taking the next step does nothing to improve my mood)
Regards,
Nick.
>
> Victor
>
> 2013/11/14 Victor Stinner :
> > Hi,
> >
&g
On 15 Nov 2013 09:11, "Nick Coghlan" wrote:
>
>
> On 15 Nov 2013 08:42, "Victor Stinner" wrote:
> >
> > Oh, I forgot to mention that I sent this email in reaction to this
issue:
> >
> > http://bugs.python.org/issue19585
> >
> > M
uity regarding the direction
of the operation)
- an ABC for "ByteSequence" might be a good idea (ducktyped to check
if memoryview can retrieve a 1-D byte array)
- an ABC for "String" might be a good idea (but opens a big can of worms)
- the codecs module should offer a
k-around for this kind of change?
IIRC, doctest ignores the traceback contents by default - this is just
a bug where the chaining is also triggering for the initial codec
lookup when it should avoid doing that.
Created http://bugs.python.org/issue19609
Cheers,
Nick.
--
Nick Coghlan
one.
A new API for binary transforms is potentially an academically
interesting concept, but it solves zero current real world problems.
By contrast, being clear about the fact that codecs.encode and
codecs.decode exist and are available as far back as Python 2.4 helps
to eliminate a genuine barrier t
aceback (most recent call last):
File "", line 1, in
LookupError: unknown encoding: hex
Rather than the more useful:
>>> b"abcdef".decode("hex")
Traceback (most recent call last):
File "", line 1, in
TypeError: 'hex' decoder returned &
The TypeError isn't new, only the part after the semi-colon telling
them that codecs.decode() doesn't include the typecheck (because it
isn't constrained by the text model).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 16 Nov 2013 02:36, "Antoine Pitrou" wrote:
>
> On Sat, 16 Nov 2013 00:46:15 +1000
> Nick Coghlan wrote:
> > On 16 November 2013 00:04, Antoine Pitrou wrote:
> > >> Rather than the more useful:
> > >>
> > >> >>> b"ab
On 16 Nov 2013 08:25, "Christian Tismer" wrote:
>
> On 13/11/13 00:49, Josiah Carlson wrote:
>>
>>
>> Python-dev is for the development of the Python core language, the
CPython runtime, and libraries. Your sandbox, despite using and requiring
deep knowledge of the runtime, is not developing those
On 16 Nov 2013 10:47, "Victor Stinner" wrote:
>
> 2013/11/16 Nick Coghlan :
> > To address Serhiy's security concerns with the compression codecs (which are
> > technically independent of the question of restoring the aliases), I also
> > plan to d
On 16 Nov 2013 11:35, "Christian Tismer" wrote:
> IOW: Do we really need a full abstraction, embedded in a virtual OS, or
> is there already a compromise that suits 98 percent of the common needs?
>
> I think as a starter, categorizing the expectations of some measure of
> 'secure python'
> would
answer is "is this a
Unicode codec or not?".
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
Unsubscrib
On 16 November 2013 21:38, Nick Coghlan wrote:
> On 16 November 2013 20:45, Victor Stinner wrote:
>> Why not using str type for str and str subtypes, and bytes type for bytes
>> and bytes-like object (bytearray, memoryview)? I don't think that we need an
>> ABC here.
&g
's still a lot of confusion over the matter, even
amongst core developers. That's a problem, and something we need to
fix before giving further consideration to the transform/untransform
idea.
*(Victor's proposal in issue 19619 is actually relatively modest, now
that I understand i
illed?
"I don't care about embedded devices" is not a good rationale for
killing features that really only benefit people running Python on
such systems.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
1001 - 1100 of 6587 matches
Mail list logo
