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 1/6/2014 3:16 PM, Nick Coghlan wrote:
I thought I mentioned it on this list last year when I first wrote it,
but some messages I've seen recently suggest many folks haven't seen it
before.
And even more will see it if you provide a link.
Please.
Emile
___
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 Mon, Jan 6, 2014 at 3:40 PM, Skip Montanaro wrote:
> On Mon, Jan 6, 2014 at 2:17 PM, Antoine Pitrou
> wrote:
> >> I agree with Serhiy, but that is probably known at this point. :)
> >
> > I agree with Serhiy and you too. Clinic's current output makes C files
> > more tedious to read, and I'm
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 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 extensively over the past
several days due to Alex's misunderstanding o
On Mon, Jan 6, 2014, at 03:16 PM, 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
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
I've just posted about PEP 460 and this discussion on the mercurial-devel
mailing list.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/option
06.01.14 22:53, Erik Bray написав(ла):
I ask because some built-in functions are used internally by other
built-in functions. I don't know how common this is but, for example,
fileio_read calls fileio_readall. So if fileio_readall is renamed to
io_FileIO_readall_impl or whatever we need to also
On Mon, Jan 6, 2014 at 10:17 AM, Antoine Pitrou wrote:
> 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 no
On Sun, Jan 5, 2014 at 11:21 AM, Larry Hastings wrote:
> Now, properly converting a function to work with Argument Clinic does not
> change its behavior. Internally, the code performing argument parsing
> should be nigh-identical; it should call the same PyArg_Parse function, with
> the same argu
On Mon, Jan 6, 2014 at 2:17 PM, Antoine Pitrou wrote:
>> I agree with Serhiy, but that is probably known at this point. :)
>
> I agree with Serhiy and you too. Clinic's current output makes C files
> more tedious to read, and I'm not really willing to participate in the
> "conversion derby" becaus
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 Tue, 07 Jan 2014 01:22:21 +1000, Nick Coghlan wrote:
> 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:
> > what
On Mon, Jan 6, 2014 at 9:43 AM, Guido van Rossum wrote:
> Since MSIEXEC.EXE is a legit binary (not coming from our packager) and
> Akamai is a legitimate company (MS most likely has an agreement with
> them), at this point I would assume that there's something that
> MSIEXEC.EXE wants to get from
Dear friends,
This is related with ticket 19717: "resolve() fails when the path
doesn't exist".
Assuming /home/cutecat exists but not /home/cutecat/aa,
what is the desired output of
Path('/home/cutecat/aa/bb/cc').resolve(strict=False)?
Should it be:
"/home/cutecat" (the existed path only),
"/h
On 6 January 2014 15:29, Bob Hanson wrote:
> At any rate, the attempts to connect to the network seem like
> undesirable behavior to this man. If pip is necessary, then some
> Window users may well end up without it -- and then not know why
> something later doesn't work.
I have installed python
Since MSIEXEC.EXE is a legit binary (not coming from our packager) and
Akamai is a legitimate company (MS most likely has an agreement with
them), at this point I would assume that there's something that
MSIEXEC.EXE wants to get from Akamai, which is unintentionally but
harmlessly triggered by the
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 the record: I'm running 32bit Windows XP (Pro) SP2 and
installing "for all users."]
TL;DR: No matter what I tried this morning re uninstalling and
reinstalling 3.4.0b2, pip or no pip, MSI still tried to connect
to the Akamai URLs.
On Sun, 05 Jan 2014 23:06:49 -0500, R. David Murray wrote:
>
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, 2014 at 8:59 AM, Antoine Pitrou
wrote:
>> >>
>> >> On Tue, 7 Jan 2014 00:54:17 +1100
>> >> Chris A
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, Jan 6, 2014 at 9:45 AM, Nick Coghlan wrote:
>
> 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
On 01/06/2014 09:50 AM, Xavier Morel wrote:
> On 2014-01-06, at 14:44 , Antoine Pitrou wrote:
>>> Then,
>>> the following points must be decided to define the complete list of
>>> supported features (formatters):
>>>
>>> * Format integer to hexadecimal? ``%x`` and ``%X``
>>> * Format integer to oc
On 2014-01-06, at 14:44 , Antoine Pitrou wrote:
>> Then,
>> the following points must be decided to define the complete list of
>> supported features (formatters):
>>
>> * Format integer to hexadecimal? ``%x`` and ``%X``
>> * Format integer to octal? ``%o``
>> * Format integer to binary? ``{!b}``
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 Mon, Jan 6, 2014 at 8:44 AM, Antoine Pitrou wrote:
>
> 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
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 "insert the result
> > > of calling __str__", but bytes forma
On Mon, Jan 6, 2014 at 2:09 AM, Chris Angelico wrote:
> The first build my new root buildbot did showed errors in the 2.7 test
> suite, but I thought little of it as quite a few other 2.7 buildbots
> are showing red, too. But it seems they're showing different errors,
> so there might be somethin
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__.
>
> Since it derives from the C pr
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__.
Since it derives from the C printf notation, it means "insert string
here". The fact that __str__
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
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.
The PEP is a draft with open questions. First, I'm not sure that both
bytes%args and byte
On 04.01.14 13:58, Serhiy Storchaka wrote:
Should implicit converting an instance of int, float, complex, str,
bytes, etc subclasses to call appropriate special method __int__ (or
__index__), __float__, __complex__, __str__, __bytes__, etc? Currently
explicit converting calls these methods, but
On Mon, Jan 6, 2014 at 7:58 PM, Christian Heimes wrote:
> Interesting, maybe it's a general NAT issue? So far I have seen the issue on
> Windows only. What kind of VM are you using? I'm using virtualbox for my
> Windows VMs.
It's Oracle VirtualBox v4.2.20 r90963.
> Just backport the test fixes.
On 06.01.2014 09:22, Chris Angelico wrote:
No, it's Debian Wheezy inside Debian Wheezy; though the outer system
is a somewhat messy one (I installed Wheezy before it was stable, and
compiled my own ALSA drivers and a few other things).
But it could well be that same issue, as it seems to involve
On Mon, Jan 6, 2014 at 7:11 PM, Christian Heimes wrote:
> On 06.01.2014 08:09, Chris Angelico wrote:
>>
>> Then further down, several SSL tests attempt:
>>
>> s.connect_ex(("svn.python.org", 444)))
>>
>> and get back EAGAIN when they're expecting ECONNREFUSED. Possibly my
>> firewall's delaying th
On 06.01.2014 08:09, Chris Angelico wrote:
Then further down, several SSL tests attempt:
s.connect_ex(("svn.python.org", 444)))
and get back EAGAIN when they're expecting ECONNREFUSED. Possibly my
firewall's delaying things somewhat and it's timing out with a signal;
when I try manually, the co
39 matches
Mail list logo
