On 11/4/2013 1:09 AM, Zachary Ware wrote:
On Sun, Nov 3, 2013 at 10:54 PM, Terry Reedy tjre...@udel.edu 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 tjre...@udel.edu
In article l57ffp$h5l$1...@ger.gmane.org, Georg Brandl g.bra...@gmx.net
wrote:
Am 04.11.2013 01:59, schrieb Ned Deily:
In article 21110.62791.44734.656...@cochabamba.vanoostrum.org,
Piet van Oostrum p...@vanoostrum.org wrote:
I tried to install matplotlib 1.3.1 on the release candidates
Hi!
On Mon, Nov 04, 2013 at 03:56:25AM -0500, Terry Reedy tjre...@udel.edu 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
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
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
On Mon, Nov 4, 2013 at 6:11 AM, Matěj Cepl mc...@redhat.com 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
2013/11/4 M.-A. Lemburg m...@egenix.com:
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
On 04.11.2013 16:10, Benjamin Peterson wrote:
2013/11/4 M.-A. Lemburg m...@egenix.com:
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
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.org. wget
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 PC because my
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
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 rev deletes a revision and all its descendents (requires some
extension to be
On Mon, 04 Nov 2013 16:34:46 +0100, Antoine Pitrou anto...@python.org 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
On 04.11.2013 17:05, R. David Murray wrote:
On Mon, 04 Nov 2013 16:34:46 +0100, Antoine Pitrou anto...@python.org 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
2013/11/4 M.-A. Lemburg m...@egenix.com:
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
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
On lun., 2013-11-04 at 20:54 +0100, Victor Stinner wrote:
2013/11/4 M.-A. Lemburg m...@egenix.com:
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.
On 04.11.2013 20:54, Victor Stinner wrote:
2013/11/4 M.-A. Lemburg m...@egenix.com:
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
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 rev deletes a revision and all
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
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 that
On 5 Nov 2013 02:03, Guido van Rossum gu...@python.org 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 rev deletes a
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
On Mon, Nov 4, 2013 at 3:47 PM, John Klos j...@ziaspace.com 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
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 use
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 one, the
On 5 Nov 2013 08:49, Larry Hastings la...@hastings.org 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
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 the
On Mon, Nov 4, 2013 at 3:36 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 5 Nov 2013 08:49, Larry Hastings la...@hastings.org 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
Quoting John Klos j...@ziaspace.com:
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
On Mon, Nov 4, 2013 at 3:47 PM, Larry Hastings la...@hastings.org 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
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
uncommon,
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 = value
would
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).
I now
On 11/5/2013 12:50 AM, Georg Brandl wrote:
mercurial.ini setting with tortoisehg workbench
[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
Am 05.11.2013 08:31, schrieb Terry Reedy:
On 11/5/2013 12:50 AM, Georg Brandl wrote:
mercurial.ini setting with tortoisehg workbench
[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
36 matches
Mail list logo
