Am 05.11.2013 08:31, schrieb Terry Reedy:
> On 11/5/2013 12:50 AM, Georg Brandl wrote:
>
>> [defaults]
>> import = --no-commit
>
> Thank you. A message in a patch is now ignored rather than
> auto-committed.
Yes; that's why I'd prefer the commit-and-then-amend way.
Georg
On 11/5/2013 12:50 AM, Georg Brandl wrote:
[defaults]
import = --no-commit
Thank you. A message in a patch is now ignored rather than
auto-committed. I still have to click away the edit box that would allow
me to enter a message and override 'no-commit', but I have always
managed to do that
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"),
> * class method ("cls"), or
> * class static ("null"
Am 05.11.2013 00:43, schrieb Terry Reedy:
> On 11/4/2013 5:15 PM, Nick Coghlan wrote:
>
>> - I actually have "--no-commit" configured as a standard option for hg
>> import in my .hgrc file so I never forget
>
> On Windows, hg uses .ini files. Do you have any idea what the
> [section]
> option = v
On Mon, Nov 04, 2013 at 08:47:53PM +, John Klos wrote:
[...]
> The short answer is to skip those tests on VAXen. The better answer is to
> patch any isnan functions to always return false on VAXen and patch any
> code which tries to parse, for instance, float("NaN") to use something
> uncomm
On Mon, Nov 4, 2013 at 3:47 PM, 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
Quoting John Klos :
The nice Python folks who were at SCALE in Los Angeles last year
gave me a Python t-shirt for showing Python working on m68k and for
suggesting that I'd get it working on VAX. With libffi support for
VAX from Miod Vallat, this is now possible.
I'm sorry to hear that -
On Mon, Nov 4, 2013 at 3:36 PM, Nick Coghlan wrote:
> 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
On 11/4/2013 5:15 PM, Nick Coghlan wrote:
- I actually have "--no-commit" configured as a standard option for hg
import in my .hgrc file so I never forget
On Windows, hg uses .ini files. Do you have any idea what the
[section]
option = value
would look like? There is gui dialog for managing th
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
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").
I now boldly propose that for the first
> We'd have to have one uncommor and two extremely unlikely events all happen
> simultaneously for your example to be of concern:
Understood. But when things run millions of times a second,
"extremely unlikely" things can happen more often that you wanted.
> Two, someone would have to decide to
On Mon, Nov 4, 2013 at 3:47 PM, John Klos wrote:
> What would be the best way to find code which handles evaluation of "NaN"?
I would be surprised to find NaN handling outside of math module, float
object and their complex counterparts (cmath and complex object). Other
areas that deal with NaN
The short answer is to skip those tests on VAXen. The better answer is to
patch any isnan functions to always return false on VAXen and patch any code
which tries to parse, for instance, float("NaN") to use something uncommon,
such as the largest representable number (const union __double_u __infi
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
I think I spoke to soon on my earlier reply. If you have control
over the whole system, you could *set* policy on behalf of a whole
platform (like VAX) so you can "safely" use an otherwise non-normal
set of bits to designate divide by zero (a negative sign bit with the
rest all zeros, for example
> The nice Python folks who were at SCALE in Los Angeles last year gave me a
> Python t-shirt for showing Python working on m68k and for suggesting that
> I'd get it working on VAX. With libffi support for VAX from Miod Vallat,
> this is now possible.
>
> However, when compiling Python, it seems th
Hi,
The nice Python folks who were at SCALE in Los Angeles last year gave me a
Python t-shirt for showing Python working on m68k and for suggesting that
I'd get it working on VAX. With libffi support for VAX from Miod Vallat,
this is now possible.
However, when compiling Python, it seems tha
On 11/04/2013 07:52 AM, 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 all its
On 04.11.2013 20:54, Victor Stinner wrote:
> 2013/11/4 M.-A. Lemburg :
>> Some things to try on the box:
>>
>> * ping6 2001:888:2000:d::a2 (that's python.org)
>
> $ ping6 -c 4 2001:888:2000:d::a2
> PING 2001:888:2000:d::a2(2001:888:2000:d::a2) 56 data bytes
> 64 bytes from 2001:888:2000:d::a2: icm
On lun., 2013-11-04 at 20:54 +0100, Victor Stinner wrote:
> 2013/11/4 M.-A. Lemburg :
> > Some things to try on the box:
> >
> > * ping6 2001:888:2000:d::a2 (that's python.org)
>
> $ ping6 -c 4 2001:888:2000:d::a2
[...]
On the box, not on your home machine!
Regards
Antoine.
__
Good news everybody!
A while ago John Kelsey has presented NIST's plans to change SHA-3 [1]
in order to make it faster but also weaker. Last Friday he posted a mail
on NIST's internal hash-forum mailing list. NIST is planing to drop
these plans and to move forward with the SHA-3 draft in its origi
2013/11/4 M.-A. Lemburg :
> Some things to try on the box:
>
> * ping6 2001:888:2000:d::a2 (that's python.org)
$ ping6 -c 4 2001:888:2000:d::a2
PING 2001:888:2000:d::a2(2001:888:2000:d::a2) 56 data bytes
64 bytes from 2001:888:2000:d::a2: icmp_seq=1 ttl=56 time=53.0 ms
64 bytes from 2001:888:2000:
On 04.11.2013 17:05, R. David Murray wrote:
> On Mon, 04 Nov 2013 16:34:46 +0100, Antoine Pitrou wrote:
>> On lun., 2013-11-04 at 16:09 +0100, M.-A. Lemburg wrote:
>>> On 04.11.2013 11:01, Victor Stinner wrote:
Hi,
bugs.python.org is still not responding on IPv6. Can someone please
On Mon, 04 Nov 2013 16:34:46 +0100, Antoine Pitrou wrote:
> On lun., 2013-11-04 at 16:09 +0100, M.-A. Lemburg wrote:
> > On 04.11.2013 11:01, Victor Stinner wrote:
> > > Hi,
> > >
> > > bugs.python.org is still not responding on IPv6. Can someone please
> > > remove the record from python.or
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 all its descendents (requires some
extension to be configu
Hi there,
Thanks for letting us know, however you'll need to report this bug at:
http://bugs.python.org/
I'd recommend using one of the Python libraries listed here if that's possible
in your case:
http://developer.github.com/v3/libraries/#python
I know that the following library is well main
On lun., 2013-11-04 at 16:09 +0100, M.-A. Lemburg wrote:
> On 04.11.2013 11:01, Victor Stinner wrote:
> > Hi,
> >
> > bugs.python.org is still not responding on IPv6. Can someone please
> > remove the record from python.org DNS, or fix the IPv6
> > configuration?
> >
> > It's an issue on my
On 04.11.2013 11:01, Victor Stinner wrote:
> Hi,
>
> bugs.python.org is still not responding on IPv6. Can someone please
> remove the record from python.org DNS, or fix the IPv6
> configuration?
>
> It's an issue on my PC because my PC has IPv6 address and so it cannot
> reach bugs.python.or
On 04.11.2013 16:10, Benjamin Peterson wrote:
> 2013/11/4 M.-A. Lemburg :
>> On 04.11.2013 11:01, Victor Stinner wrote:
>>> Hi,
>>>
>>> bugs.python.org is still not responding on IPv6. Can someone please
>>> remove the record from python.org DNS, or fix the IPv6
>>> configuration?
>>>
>>> It's
2013/11/4 M.-A. Lemburg :
> On 04.11.2013 11:01, Victor Stinner wrote:
>> Hi,
>>
>> bugs.python.org is still not responding on IPv6. Can someone please
>> remove the record from python.org DNS, or fix the IPv6
>> configuration?
>>
>> It's an issue on my PC because my PC has IPv6 address and so
On Mon, Nov 4, 2013 at 6:11 AM, Matěj Cepl wrote:
> I am not sure how widespread is this breaking of RFC, but it seems to me
> that quite a lot (e.g., http://stackoverflow.com/a/9698319/164233 which
> just en passant expects urllib2 authentication stuff to be useless), and
> the question is wheth
Hi,
GitHub API v3 is intentionally broken (see
http://developer.github.com/v3/auth/):
> The main difference is that the RFC requires unauthenticated requests
> to be answered with 401 Unauthorized responses. In many places, this
> would disclose the existence of user data. Instead, the GitHub API
Hi,
bugs.python.org is still not responding on IPv6. Can someone please
remove the record from python.org DNS, or fix the IPv6
configuration?
It's an issue on my PC because my PC has IPv6 address and so it cannot
reach bugs.python.org. wget is really slow because it tries first
IPv6, but the
Hi!
On Mon, Nov 04, 2013 at 03:56:25AM -0500, Terry Reedy wrote:
> The one
> thing I tried but could not do was to directly change status 'A'
> back to '?'.
hg forget file
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, the
In article , Georg Brandl
wrote:
> Am 04.11.2013 01:59, schrieb Ned Deily:
> > In article <21110.62791.44734.656...@cochabamba.vanoostrum.org>,
> > Piet van Oostrum wrote:
> >> I tried to install matplotlib 1.3.1 on the release candidates of Python
> >> 2.7.6
> >> and 3.3.3.
> >
> > [...]
>
On 11/4/2013 1:09 AM, Zachary Ware wrote:
On Sun, Nov 3, 2013 at 10:54 PM, Terry Reedy wrote:
On 11/3/2013 11:48 PM, terry.reedy wrote:
http://hg.python.org/cpython/rev/cced7981ec4d
changeset: 86908:cced7981ec4d
branch: 2.7
user:Terry Jan Reedy
date:Sun Nov 03 23:37:54
37 matches
Mail list logo
