On Mon, 25 Nov 2013 11:20:08 +1300
Ben Hoyt wrote:
>
> This mainly depends on how Path is going to cache stat information. If
> it caches it, then this will just work. Sounds like Guido's opinion
> was that both cached and uncached use cases are important, but that it
> should be very clear which
On Mon, 25 Nov 2013 12:04:28 +1300
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 plugg
On Fri, 29 Nov 2013 09:16:38 +
Kristján Valur Jónsson wrote:
> Closing the ticket, twice, is a rude, and unnecessary action.
Closing the ticket means "we don't believe there is an issue, or we
don't think it would be reasonable to fix it". If that's our judgement
on the issue, how is it rude
On Fri, 29 Nov 2013 15:25:14 +
Kristján Valur Jónsson wrote:
>
> > -Original Message-
> > From: Python-Dev [mailto:python-dev-
> > bounces+kristjan=ccpgames@python.org] On Behalf Of Antoine Pitrou
> > Sent: 29. nóvember 2013 14:58
> > To: pyth
On Sat, 30 Nov 2013 19:29:37 +0100
Christian Heimes wrote:
> This fix requires only a new SSLContext attribute and a small
> modification to SSLSocket.do_handshake():
>
> if self.context.check_hostname:
> try:
> match_hostname(self.getpeercert(), self.server_hostname)
> ex
On Sun, 01 Dec 2013 02:53:32 +0100
Christian Heimes wrote:
> Am 30.11.2013 23:51, schrieb Antoine Pitrou:
> > Small nit: what happens if the server_hostname is None (i.e. wasn't
> > passed to context.wrap_socket())?
>
> The code will raise an exception. My patch
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 the
> context can't get into the inconsistent verify_mode=CERT_NONE and
> check_hostname=True state,
Hi Fil,
On Wed, 4 Dec 2013 23:17:11 +1100
Fil Mackay wrote:
>
> I've found that libffi does support this type, but sadly ctypes and cffi do
> not. Adding to ctypes does not seem to be trivial, since the description of
> an integer type is limited to a single character ("q" in the case of long
>
On Mon, 9 Dec 2013 10:28:17 +0100
Victor Stinner wrote:
> Hi,
>
> 2013/12/9 Serhiy Storchaka :
> > But tracemalloc doesn't count memory allocated besides Python allocators
> > (e.g. memory for executable, static variables and stack, memory allocated by
> > extensions and C lib, unallocated but no
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
> date:Wed Dec 11 21:07:54 2013 +0200
> summary:
> Issu
On Sun, 15 Dec 2013 09:10:08 +1000
Nick Coghlan wrote:
>
> The question should probably be addressed directly in PEP 7, and I'd
> be inclined to just bless the "%.400s" variant for future code.
Shouldn't we have a special "%T" shortcut instead of trying to
harmonize all the occurrences of `"%.40
On Sat, 14 Dec 2013 15:14:10 +0100
Jurko Gospodnetić wrote:
>
>I believe the current Python default SIGINT handling by raising an
> asynchronous KeyboardInterrupt exception is dangerous, and can directly
> cause Python interpreter crashes even if no user code is involved, or
> any sort of
On Tue, 17 Dec 2013 13:18:25 -0500
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> http://hg.python.org/cpython/rev/b1e94e332ec8
>
>
> Do we really want to change an undocumented-but-effectively-public API in
> a late-in-the-release-cycle third dot release? It caused,
On Wed, 18 Dec 2013 00:19:23 +0100
Daniel Pocock wrote:
>
> If a main thread does things like importing a module and obtaining a
> reference to a Python method, can those things be used by other C++
> threads or do they have to repeat those lookups?
The C++ threads must use the PyGILState API to
On Wed, 18 Dec 2013 11:31:47 -0500
Daniel Holth wrote:
> But who could forget njzrs' wasp UAV software line 107, using
> int=float?
> https://github.com/nzjrs/wasp/blob/master/sw/groundstation/wasp/__init__.py#L107
>
And the purpose is quite Pythonesque:
"""
Generates a noisy random wal
On Tue, 31 Dec 2013 11:24:26 +1100
Chris Angelico wrote:
> Does Buildbot retain a constant TCP socket to its server? I'm seeing this:
>
> http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.3/builds/0
I'm quite sure it does. It's necessary to get a real-time view of the
test log.
On Tue, 31 Dec 2013 09:33:21 -0800
Chris Barker wrote:
>
> It might be interesting to toss that survey out into the wild more and see
> what happens...
It's already been tossed in the wild, since the message originally was
posted on python-list.
Feel free to spread the URL a bit more.
Regards
On Thu, 2 Jan 2014 13:10:36 -0800
Dan Stromberg wrote:
> Is there a better place to put this than:
> http://stromberg.dnsalias.org/~strombrg/python-2.x-vs-3.x-survey/
Thank you for doing this!
If wiki.python.org supports file uploads, it may be the place for
publishing the results.
Regards
Ant
On Sun, 5 Jan 2014 11:23:45 -0600
Brian Curtin wrote:
> On Sun, Jan 5, 2014 at 3:08 AM, Lennart Regebro wrote:
> > On Sun, Jan 5, 2014 at 5:20 AM, John Yeuk Hon Wong
> > wrote:
> >> I think it helps Luca and many others (including myself) if there is a
> >> reference of the difference between 2.
Hi,
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner wrote:
>
> The PEP is a draft with open questions. First, I'm not sure that both
> bytes%args and bytes.format(args) are needed. The implementation of
> .format() is more complex, so why not only adding bytes%args?
I think we must either imp
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 "insert the result
> > of calling __str__", but bytes formatting should *not* call __str__.
&g
On Tue, 7 Jan 2014 00:45:58 +1000
Nick Coghlan wrote:
>
> Right, but it seems to me that a new helper module that could be made
> backwards compatible at least as far as 2.6 (if not further) would be more
> useful for that than a builtin change that won't be available until 2015.
More useful in
On Mon, 6 Jan 2014 00:25:53 +0100
Stefan Krah wrote:
> Nick Coghlan wrote:
> > > I had that working at one point. Guido said no, keep it all in one file.
> > > I'm flexible but first you'd have to convince him.
> >
> > It's also not something we're stuck with forever - we can start with it
>
On Mon, 06 Jan 2014 23:25:12 +
Mark Lawrence wrote:
> On 06/01/2014 23:16, 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 the GIL
> > instead of Unicode), and I've updated it ex
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 the GIL
> instead of Unicode), and I've updated it extensively over the past several
> days due to Alex'
On Tue, 07 Jan 2014 10:40:15 +0100
Georg Brandl wrote:
> Am 06.01.2014 14:24, schrieb Victor Stinner:
> > Hi,
> >
> > bytes % args and bytes.format(args) are requested by Mercurial and
> > Twisted projects. The issue #3982 was stuck because nobody proposed a
> > complete definition of the "new" f
On Tue, 07 Jan 2014 11:33:55 +0100
Georg Brandl wrote:
>
> The proposal would be to focus entirely on addressing these roadblocks
> in the 3.5 version, and no other new features -- the release cycle
> needn't be 18 months for this one. This is similar to the moratorium
> for 3.2, but that one ca
Hello,
Several core developers a bit unhappy with the way Argument Clinic
currently scatters generated code into hand-written C modules. The
opinion is that it makes C files more confusing and annoying to
navigate through.
Several solutions have been proposed:
- move all generated code to separa
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman wrote:
> On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
> >
> > - move all generated code to separate C files, which would then be
> >#included'd into the main module file
>
> -1 (Guido has stated a strong disl
On Tue, 07 Jan 2014 17:26:20 +0200
Serhiy Storchaka wrote:
>
> Behavior of --canonicalize-existing can be derived from --canonicalize,
> just check that resulting patch exists. But other modes can't be derived
> from --canonicalize-existing.
>
> def resolve_existing(path):
> path = path.r
On Tue, 07 Jan 2014 22:45:54 +0200
Serhiy Storchaka wrote:
> 07.01.14 22:28, Antoine Pitrou написав(ла):
> >> So perhaps two main modes should be --canonicalize (default) and
> >> --canonicalize-missing (with missing=True)?
> >
> > That sounds reasonable. And I t
On Tue, 07 Jan 2014 12:33:11 -0800
Ethan Furman wrote:
> On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
> > On Tue, 07 Jan 2014 12:03:00 -0800
> > Ethan Furman wrote:
> >> On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
> >>>
> >>> - move all generat
On Tue, 7 Jan 2014 15:46:50 -0500
Barry Warsaw wrote:
>
> If adopted for Python 3.4, PEP 460 should be modest in its goals, but I think
> I'd still like to see the following excluded and unknown features added:
>
> * Attribute access: {obj.attr}
> * Indexing: {dict[key]}
> * format keywords?
On Tue, 7 Jan 2014 05:16:18 -0500
Donald Stufft wrote:
> Given the low adoption rates for Python 3
It would be nice not repeating that mantra since there are no reliable
usage figures available.
Regards
Antoine.
___
Python-Dev mailing list
Python-De
On Wed, 08 Jan 2014 13:51:36 +0900
"Stephen J. Turnbull" wrote:
> Benjamin Peterson writes:
>
> > I agree. This is a very important, much-requested feature for low-level
> > networking code.
>
> I hear it's much-requested, but is there any description of typical
> use cases? The ones I've see
On Wed, 8 Jan 2014 11:02:19 +0100
Victor Stinner wrote:
>
> > What does b'%s' % 7 do?
>
> See Examples of the PEP:
>
> b'a%sc%s' % (b'b', 4) gives b'abc4'
[...]
> > And then what? Use the "default" encoding? ASCII?
>
> Bytes have no encoding. There are just bytes :-)
Therefore you shouldn't a
Hi Victor,
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner wrote:
> Hi,
>
> bytes % args and bytes.format(args) are requested by Mercurial and
> Twisted projects. The issue #3982 was stuck because nobody proposed a
> complete definition of the "new" features. Here is a try as a PEP.
There is
On Wed, 8 Jan 2014 11:16:49 -0700
Eric Snow wrote:
>
> It boils down to 3.5 being *the* target for porting from 2.7.
No. Please let's stop being self-deprecating. 3.3 is fine as a porting
target, as the many high-profile libraries which have already been
ported can attest.
> Otherwise we'd be b
On Wed, 8 Jan 2014 11:59:51 -0700
Eric Snow wrote:
> As others have opined,
> formatting a bytes object is out of place.
However, interpolating a bytes object isn't out of place, and it is
what a minimal "formatting" primitive could do.
Regards
Antoine.
___
Hi,
Another remark about the PEP: it should define bytearray % args and
bytearray.format(args) as well.
Regards
Antoine.
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner wrote:
> Hi,
>
> bytes % args and bytes.format(args) are requested by Mercurial and
> Twisted projects. The issue #3982
Hi,
With Victor's consent, I overhauled PEP 460 and made the feature set
more restricted and consistent with the bytes/str separation. However, I
also added bytearray into the mix, as bytearray objects should
generally support the same operations as bytes (and they can be useful
*especially* for
On Thu, 9 Jan 2014 10:15:08 +
Kristján Valur Jónsson wrote:
>
> Moving to python 3, I found that this quickly caused problems. So, I
> explicitly added an encoding. Better guess an encoding, something that is
> likely, e.g. cp1252
> with open(fn1, encoding='cp1252') as f1:
> with open
On Thu, 09 Jan 2014 03:54:13 +
MRAB wrote:
> I'm thinking that the "i" format could be used for signed integers and
> the "u" for unsigned integers. The width would be the number of bytes.
> You would also need to have a way of specifying the endianness.
>
> For example:
>
> >>> b'{:<2i}'.f
On Thu, 9 Jan 2014 17:09:10 +1000
Nick Coghlan wrote:
>
> There's also the fact that POSIX folks are used to "r" and "rb" being
> the same thing.
Which fails immediately under Windows :-)
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@pyth
On Thu, 9 Jan 2014 12:55:35 +
Kristján Valur Jónsson wrote:
> > If you don't "care" about the encoding, why don't you use latin1?
> > Things will roundtrip fine and work as well as under Python 2.
>
> Because latin1 does not define all code points, giving you errors there.
>>> b = bytes(rang
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 point. Now it's up to people who need those additional
tools to p
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
> > also added bytearray into the mix, as bytearray objects should
> > generally support the same operations as bytes (and they can
On Thu, 9 Jan 2014 13:36:05 -0800
Chris Barker wrote:
>
> Some folks have suggested using latin-1 (or other 8-bit encoding) -- is
> that guaranteed to work with any binary data, and round-trip accurately?
Yes, it is.
> and will surrogateescape work for arbitrary binary data?
Yes, it will.
Reg
On Fri, 10 Jan 2014 11:32:05 +1000
Nick Coghlan wrote:
> >
> > It's consistent with bytearray.join's behaviour:
> >
> > >>> x = bytearray()
> > >>> x.join([b"abc"])
> > bytearray(b'abc')
> > >>> x
> > bytearray(b'')
>
> Yeah, I guess I'm OK with us being consistent on that one. It's still
> weird
On Fri, 10 Jan 2014 12:56:19 -0500
"Eric V. Smith" wrote:
>
> I agree. I don't see any reason to exclude int and float. See Guido's
> messages http://bugs.python.org/issue3982#msg180423 and
> http://bugs.python.org/issue3982#msg180430 for some justification and
> discussion.
If you are represent
On Fri, 10 Jan 2014 17:20:32 -0500
"Eric V. Smith" wrote:
>
> Isn't the point of the PEP to make it easier to port 2.x code to 3.5?
> Is
> there really existing code like this in 2.x?
No, but so what? The point of the PEP is not to allow arbitrary
Python 2 code to run without modification under
On Fri, 10 Jan 2014 17:33:57 -0500
"Eric V. Smith" wrote:
> On 1/10/2014 5:29 PM, Antoine Pitrou wrote:
> > On Fri, 10 Jan 2014 12:56:19 -0500
> > "Eric V. Smith" wrote:
> >>
> >> I agree. I don't see any reason to exclude int and float.
On Fri, 10 Jan 2014 14:58:15 -0800
Ethan Furman wrote:
> On 01/10/2014 02:42 PM, Antoine Pitrou wrote:
> > On Fri, 10 Jan 2014 17:33:57 -0500
> > "Eric V. Smith" wrote:
> >> On 1/10/2014 5:29 PM, Antoine Pitrou wrote:
> >>> On Fri, 10 Jan 20
On Fri, 10 Jan 2014 18:14:45 -0500
"Eric V. Smith" wrote:
>
> >> Because embedding the ASCII equivalent of ints and floats in byte streams
> >> is a common operation?
> >
> > Again, if you're representing "ASCII", you're representing text and
> > should use a str object.
>
> Yes, but is there e
On Sat, 11 Jan 2014 00:43:39 +0100
Juraj Sukop wrote:
> Basically, to ".encode('ascii')" every possible
> number is not exactly simple or pretty.
Well it strikes me that the PDF format itself is not exactly simple or
pretty. It might be convenient that Python 2 allows you, in certain
cases, to "i
On Fri, 10 Jan 2014 16:23:53 -0800
Ethan Furman wrote:
> On 01/08/2014 02:42 PM, Antoine Pitrou wrote:
> >
> > With Victor's consent, I overhauled PEP 460 and made the feature set
> > more restricted and consistent with the bytes/str separation.
>
> From the P
On Fri, 10 Jan 2014 20:53:09 -0500
"Eric V. Smith" wrote:
>
> So, I'm -1 on the PEP. It doesn't address the cases laid out in issue
> 3892. See for example http://bugs.python.org/issue3982#msg180432 .
Then we might as well not do anything, since any attempt to advance
things is met by stubborn o
On Fri, 10 Jan 2014 18:28:41 -0800
Ethan Furman wrote:
>
> Is it safe to assume you don't use Python for the use-cases under discussion?
You know, I've done quite a bit of network programming. I've also done
an experimental port of Twisted to Python 3. I know what a network
protocol with ill-def
On Sat, 11 Jan 2014 08:26:57 +0100
Georg Brandl wrote:
> Am 11.01.2014 03:04, schrieb Antoine Pitrou:
> > On Fri, 10 Jan 2014 20:53:09 -0500
> > "Eric V. Smith" wrote:
> >>
> >> So, I'm -1 on the PEP. It doesn't address the ca
On Sun, 12 Jan 2014 01:34:26 +1000
Nick Coghlan wrote:
>
> Yes, it bloody well does. The number of people who have told me that
> using Python 3 is what allowed them to finally understand how Unicode
> works vastly exceeds the number of wire protocol and file format devs
> that have complained ab
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner wrote:
>
> If you agree, I will modify the PEP. If Antoine disagree, I will fork
> the PEP 460 ;-)
Please fork it.
> b'x=%s' % 10 is well defined, it's pure bytes.
It is well-defined? Then please explain me what the general case of
b'%s' % x
On Sat, 11 Jan 2014 10:38:01 -0800
Ethan Furman wrote:
> On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
> > On Sat, 11 Jan 2014 18:41:49 +0100
> > Victor Stinner wrote:
> >>
> >> If you agree, I will modify the PEP. If Antoine disagree, I will fork
> >&
On Sat, 11 Jan 2014 23:10:43 -0800
Ethan Furman wrote:
> On 01/11/2014 05:37 PM, Brett Cannon wrote:
> >
> > You're assuming the context manager is doing something magical to verify
> > that all calls in the block raise the expected
> > exception. What you want to do is execute it in a loop::
> >
Hi Ethan,
On Sun, 12 Jan 2014 13:28:15 -0800
Ethan Furman wrote:
> On 01/12/2014 12:02 PM, Stephen J. Turnbull wrote:
> > Georg Brandl writes:
> >> Antoine writes:
> >>>
> >>> . . . if it weren't for your stupid maximalist opposition. . .
> >>
> >> Can you please stop throwing personal insults a
On Sun, 12 Jan 2014 18:11:47 -0800
Guido van Rossum wrote:
> On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote:
> > On 01/12/2014 04:47 PM, Guido van Rossum wrote:
> >> %s seems the trickiest: I think with a bytes argument it should just
> >> insert those bytes (and the padding modifiers should
On Mon, 13 Jan 2014 07:59:10 -0800
Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 3:41 AM, Antoine Pitrou wrote:
> > What is the use case for embedding a quoted ASCII-encoded representation
> > in a byte stream?
>
> It doesn't crash but produces undesired output (a
On Mon, 13 Jan 2014 08:36:05 -0800
Ethan Furman wrote:
> On 01/13/2014 08:09 AM, Antoine Pitrou wrote:
> > On Mon, 13 Jan 2014 07:59:10 -0800
> > Guido van Rossum wrote:
> >> On Mon, Jan 13, 2014 at 3:41 AM, Antoine Pitrou
> >> wrote:
> >>> What
On Mon, 13 Jan 2014 08:36:05 -0800
Ethan Furman wrote:
> On 01/13/2014 08:09 AM, Antoine Pitrou wrote:
> > On Mon, 13 Jan 2014 07:59:10 -0800
> > Guido van Rossum wrote:
> >> On Mon, Jan 13, 2014 at 3:41 AM, Antoine Pitrou
> >> wrote:
> >>> What
On Mon, 13 Jan 2014 09:34:39 -0800
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. I've not done a full audit of the code, but
On Mon, 13 Jan 2014 18:51:32 + (UTC)
Augie Fackler wrote:
>
> (Please don't remove me from the CC list - I could only respond via gmane
> because I'm not subscribed to python-dev.)
Responding via gmane is what I do, too :-)
My NNTP client doesn't allow SMTP / NNTP mixed postings, so I'm forc
On Mon, 13 Jan 2014 13:32:28 -0800
Guido van Rossum wrote:
>
> But formatb() feels absurd to me. PEP 460 has neither a precise
> specification or any actual examples, so I can't tell whether the
> intention is that the format string can *only* contain {...} sequences
> or whether it can also cont
On Mon, 13 Jan 2014 13:56:44 -0800
Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 1:40 PM, Antoine Pitrou wrote:
> > On Mon, 13 Jan 2014 13:32:28 -0800
> > Guido van Rossum wrote:
> >>
> >> But formatb() feels absurd to me. PEP 460 has neither a precise
On Tue, 14 Jan 2014 10:52:05 -0800
Guido van Rossum 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 printing out h
On Tue, 14 Jan 2014 11:56:25 -0800
Ethan Furman wrote:
>
> %s, because it is the most general, has the most convoluted resolution:
>
>- input type is bytes?
> pass it straight through
It should try to get a Py_buffer instead.
>- input type is numeric?
> use its __xxx__ [1] [2
On Tue, 14 Jan 2014 12:22:12 -0800
Larry Hastings 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 approaches.
-0.5 on
On Tue, 14 Jan 2014 13:07:57 -0800
Ethan Furman 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 not worry a
On Wed, 15 Jan 2014 13:22:44 +0100
"Martin v. Löwis" wrote:
> Am 12.01.14 18:39, schrieb Nachshon David Armon:
> >>> I propose that this new version of python use the python 3 unicode model.
> >>> As the version of python will be fully compatible with both python 2 and
> >>> with python 3 but NOT
On Wed, 15 Jan 2014 16:31:17 +0200
Serhiy Storchaka wrote:
> 15.01.14 14:22, "Martin v. Löwis" написав(ла):
> > I don't think that it is possible to write an interpreter that is fully
> > compatible for all it accepts. Would you think that the program
> >
> > print(repr(2**80).endswith("L"))
> >
>
On Wed, 15 Jan 2014 15:47:43 + (UTC)
Neil Schemenauer wrote:
>
> Objects that implement __str__ can also implement __bytes__ if they
> can guarantee that ASCII characters are always returned, no matter
> what the *value*
I think that's a slippery slope. __bytes__ should mean that the object
On Wed, 15 Jan 2014 21:55:46 -0800
Larry Hastings wrote:
>
> Passing in "None" here is inconvenient as it's an integer argument.
Inconvenient for whom? The callee or the caller?
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Thu, 16 Jan 2014 04:42:43 -0500
Terry Reedy wrote:
> On 1/16/2014 3:31 AM, Serhiy Storchaka wrote:
> > 16.01.14 08:05, Guido van Rossum написав(ла):
> >> In this specific case it's clear to me that the special-casing of
> >> negative count is intentional -- presumably it emulates sequence
> >>
On Thu, 16 Jan 2014 01:55:43 +0100 (CET)
victor.stinner wrote:
> http://hg.python.org/cpython/rev/f07161c4f3aa
> changeset: 88494:f07161c4f3aa
> user:Victor Stinner
> date:Thu Jan 16 01:55:29 2014 +0100
> summary:
> asyncio: Fix CoroWrapper (fix my previous commit)
>
> Add __
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman wrote:
>
> PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a bit massaging:
http://www.python.org/dev/peps/pep-0461/
> .. note:
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah wrote:
> > I'd rather see memoryview.h than memoryview.clinic.c.
>
> Or, if this collides with Include/*, one of the following:
>
>memoryview_func.h // public functions
>
>memoryview_if.h // public interface
Objects/memoryview.clinic.h s
On Sat, 18 Jan 2014 18:18:49 +0100
Stefan Krah wrote:
> Antoine Pitrou wrote:
> > Objects/memoryview.clinic.h should be fine.
>
> Last attempt:
>
> Objects/memoryview.api.h
>
>
> That is more neutral and describes what the file contains.
Disagreed. It'
On Mon, 20 Jan 2014 00:05:16 -0800
Larry Hastings wrote:
>
> On 01/19/2014 08:29 AM, Ethan Furman wrote:
> > On 01/19/2014 03:32 AM, Georg Brandl wrote:
> >> Am 19.01.2014 11:19, schrieb Larry Hastings:
> >>> Not kidding, my best idea so far is "foo.clinic.h.h",
> >>
> >> Why not always put clin
On Wed, 22 Jan 2014 05:30:40 -0500
Donald Stufft wrote:
> I would like to propose that a backwards incompatible change be
> made to Python to make verification of hostname and certificate
> chain the default instead of requiring it to be opt in.
>
> Python 3.4 has made great strides in making it
On Wed, 22 Jan 2014 15:13:00 +0100
Christian Heimes wrote:
> On 22.01.2014 13:43, Jesse Noller wrote:
> > I have to concur with Donald here - in the case of security, especially
> > language security which directly impacts the implicit security of
> > downstream applications, I should not have t
On Wed, 22 Jan 2014 15:33:21 +0100
Christian Heimes wrote:
>
> About two months ago (maybe three) I proposed to deprecated implicit SSL
> context, unverified certs and unverified hostnames all together. But I
> was voted down. Donald made a similar attempt half an year ago, too.
So why are you t
On Wed, 22 Jan 2014 08:12:06 -0700
Eric Snow wrote:
> On Jan 22, 2014 6:17 AM, "M.-A. Lemburg" wrote:
> > Using an environment switch the extra checks could even be enabled
> > without any code changes.
>
> When Donald brought this up it sounded good. It still does. This is
> similar to what w
On Wed, 22 Jan 2014 13:50:37 -0500
Donald Stufft wrote:
>
> Ironically this is the exact reason why validation should happen by default :]
I think most of us would agree that a new client API should do
validation by default (with an easy way to opt out). So let's
concentrate on the question of w
On Thu, 23 Jan 2014 01:45:15 -0500
Scott Dial wrote:
>
> Anecdotally, I already know of a system at work that is using HTTPS
> purely for encryption, because the authentication is done in-band. So, a
> self-signed cert was wholly sufficient. The management tools use a
> RESTful interface over HTT
On Thu, 23 Jan 2014 06:02:18 +
Kristján Valur Jónsson wrote:
>
> If not already possible, I suggest that we allow the use of a certificate
> validation callback
> (it isn't possible for 2.7, I just hacked in one yesterday to allow me to
> ignore out-date-failure for certificates.)
> Using t
On Fri, 24 Jan 2014 18:32:17 +0200
Ram Rachum wrote:
> Question: Why is there no str.rreplace in Python?
What would it do?
(also, I think such questions are better asked on python-ideas)
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python
On Fri, 24 Jan 2014 20:07:43 -0800
Larry Hastings wrote:
>
> A) pydoc and help() should not show bound parameters in the signature,
> like inspect.signature.
-1 from me. The problem is this will make help(c.foo) inconsistent with
help(c) and help(C), and is bound to confuse newcomers.
Speaking
On Sat, 25 Jan 2014 05:42:58 -0800
Larry Hastings wrote:
> On 01/25/2014 05:37 AM, Antoine Pitrou wrote:
> > Speaking of which, I think asking for votes before all arguments have
> > been made is counter-productive.
>
> Sorry, I didn't realize there was an established p
On Sat, 25 Jan 2014 15:02:56 +0100 (CET)
victor.stinner wrote:
> +
> +@tasks.coroutine
> +def wait():
> +loop = self.loop
> +calls.append(loop._run_once_counter)
> +yield from tasks.sleep(loop.granularity * 10, loop=loop)
> +calls.app
On Sat, 25 Jan 2014 23:37:49 +0100 (CET)
eric.snow wrote:
> http://hg.python.org/cpython/rev/665f1ba77b57
> changeset: 88710:665f1ba77b57
> user:Eric Snow
> date:Sat Jan 25 15:32:46 2014 -0700
> summary:
> Issue 19944: Fix importlib.find_spec() so it imports parents as needed.
On Sat, 25 Jan 2014 18:30:24 -0800
Raymond Hettinger wrote:
>
> On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:
>
> > Nick also suggested to document
> > our deprecation policy in PEP 5 (Guidelines for Language Evolution:
> > http://www.python.org/dev/peps/pep-0005/ ).
>
> Here's a few though
On Mon, 27 Jan 2014 14:02:29 +1000
Nick Coghlan wrote:
>
> If we do go this path, then we should backport the full fix (i.e.
> accepting None to indicate repeating forever), rather than just a
> partial fix.
>
> That is, I'm OK with either not backporting anything at all, or
> backporting the fu
601 - 700 of 4909 matches
Mail list logo
