Yes. The network link on dinsdale is maxed out,
since it hosts too many services (and since there was a massive
increase in traffic over the last year). As a consequence,
connections may time out.
We are working on migrating services to a new machine. Unfortunately,
the current hold-up is that
Paul Moore writes:
I suppose if you're saying that pip install lxml should download and
install for me Visual Studio, libxml2 sources and any dependencies,
and run all the builds, then you're right. But I assume you're not.
Indeed, if only a source package is available, it should. That's
Playing with cpython source, I found some strange strings in
socketmodule.c:
---
if (flowinfo 0 || flowinfo 0xf) {
PyErr_SetString(
PyExc_OverflowError,
getsockaddrarg: flowinfo must be 0-1048575.);
return 0;
Hello,
I'm one of this year's Google Summer of Code students working
on improving pickle by creating a new version. My name is Stefan and
my mentor is Alexandre Vassalotti.
If you're interested, you can monitor the progress in the dedicated
blog at [2] and the bitbucket repository at [3].
One
I am out of the office until 06/30/2012.
I will be out of the office the week of June 25. I expect to have some
email access but will likely be delayed in responding.
Note: This is an automated response to your message Python-Dev Digest,
Vol 107, Issue 104 sent on 06/23/2012 2:02:24.
This
Why do I get the feeling that most people who hate distutils and want
to replace it, has transferred those feelings to distutils2/packaging,
mainly because of the name?
In the end, I think this discussion is very similar to all previous
packaging/building/installing discussions: There is a lot of
On 22 June 2012 17:56, Donald Stufft donald.stu...@gmail.com wrote:
On Friday, June 22, 2012 at 12:54 PM, Alexandre Zani wrote:
Key distribution is the real issue though. If there isn't a key
distribution infrastructure in place, we might as well not bother with
signatures. PyPI could issue
Hi all,
now that the final PEP scheduled for 3.3 is final, we're entering
the next round of the 3.3 cycle.
I've decided to make Tuesday 26th the big release day. That means:
- Saturday: last feature-level changes that should be done before beta,
e.g. removal of packaging
- Sunday: final
I realize it is late, but any chance to get http://bugs.python.org/issue15139
in today?
Frá: python-dev-bounces+kristjan=ccpgames@python.org
[python-dev-bounces+kristjan=ccpgames@python.org] fyrir h#246;nd
g.brandl-nos...@gmx.net
On 06/23/2012 12:37 PM, Lennart Regebro wrote:
Why do I get the feeling that most people who hate distutils and want
to replace it, has transferred those feelings to distutils2/packaging,
mainly because of the name?
In the end, I think this discussion is very similar to all previous
On Sat, 23 Jun 2012 11:00:34 +
Kristján Valur Jónsson krist...@ccpgames.com wrote:
I realize it is late, but any chance to get http://bugs.python.org/issue15139
in today?
-1.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
On Sat, Jun 23, 2012 at 8:37 PM, Lennart Regebro rege...@gmail.com wrote:
In the end, I think this discussion is very similar to all previous
packaging/building/installing discussions: There is a lot of emotions,
and a lot of willingness to declare that X sucks but very little
concrete
Oh sorry, having read the thread this spawned from I see you're taking
about MS Windows singed binaries. Something I know next to nothing
about, so ignore my babbling.
On 23 June 2012 11:52, Floris Bruynooghe f...@devork.be wrote:
On 22 June 2012 17:56, Donald Stufft donald.stu...@gmail.com
On Sat, Jun 23, 2012 at 12:25 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 23, 2012 at 8:37 PM, Lennart Regebro rege...@gmail.com wrote:
In the end, I think this discussion is very similar to all previous
packaging/building/installing discussions: There is a lot of emotions,
and a
On Sat, Jun 23, 2012 at 1:25 PM, Nick Coghlan ncogh...@gmail.com wrote:
If you think that, you haven't read the whole thread.
This is true, I kinda gave up early yesterday. It's good that it became better.
//Lennart
___
Python-Dev mailing list
On Sat, Jun 23, 2012 at 9:53 PM, David Cournapeau courn...@gmail.com wrote:
Nick, I am unfamiliar with python-ideas rules: should we continue
discussion in distutils-sig entirely, or are there some specific
topics that are more appropriate for python-ideas ?
No, I think I just need to join
On Sat, 23 Jun 2012 13:12:19 +0200
Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Jun 2012 11:00:34 +
Kristján Valur Jónsson krist...@ccpgames.com wrote:
I realize it is late, but any chance to get
http://bugs.python.org/issue15139 in today?
-1.
Let me elaborate: the patch
I'm surprised gpg hasn't been mentioned here. I think these are all
solved problems, most free software that is signed signs it with the
gpg key of the author. In that case all that is needed is that the
cheeseshop allows the uploading of the signature.
For the record, the cheeseshop has been
Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no writes:
As for me, I believe I've been rather blunt and direct in my criticism
in this thread: It's been said by Tarek that distutils2 authors that
they don't know anything about compilers. Therefore it's almost
unconceivable to me that
Au contraire, it is actually a very major improvement, the result of pretty
extensive profiling, see
http://blog.ccpgames.com/kristjan/2012/05/25/optimizing-python-condition-variables-with-telemetry/
The proposed patch reduces signaling latency in busy applications as
demonstrated by the
On Sat, 23 Jun 2012 12:27:52 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
For me, the bigger problem with the present distutils2/packaging
implementation
is that it propagates the command-class style of design which IMO caused so
much pain in extending distutils. Perhaps some of
On Sat, 23 Jun 2012 12:32:37 +
Kristján Valur Jónsson krist...@ccpgames.com wrote:
Au contraire, it is actually a very major improvement, the result of pretty
extensive profiling, see
http://blog.ccpgames.com/kristjan/2012/05/25/optimizing-python-condition-variables-with-telemetry/
It
On 06/23/2012 02:27 PM, Vinay Sajip wrote:
Dag Sverre Seljebotnd.s.seljebotnat astro.uio.no writes:
As for me, I believe I've been rather blunt and direct in my criticism
in this thread: It's been said by Tarek that distutils2 authors that
they don't know anything about compilers. Therefore
Antoine Pitrou solipsis at pitrou.net writes:
Remember that distutils2 was at first distutils. It was only decided to
be forked as a new package when some people complained.
This explains a lot of the methodology. Also, forking distutils helped
maintain a strong level of compatibility.
Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no writes:
Of course you can always do anything, as numpy.distutils is a living
proof of. Question is if it is good design. Can I be confident that the
hooks are well-designed for my purposes?
Only you can look at the design to determine that.
On Sat, 23 Jun 2012 13:14:42 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Kudos to Tarek, Éric and others for taking this particular world on their
shoulders and re-energizing the discussion and development work to date, but
it
seems the net needs to be spread even wider to ensure
On Sat, 23 Jun 2012 15:28:00 +0200
ezio.melotti python-check...@python.org wrote:
+ .. deprecated-removed:: 3.3 3.5
+ The *strict* argument and the strict mode have been deprecated.
+ The parser is now able to accept and parse invalid markup too.
+
What if people want to accept
On 06/23/2012 03:20 PM, Vinay Sajip wrote:
Dag Sverre Seljebotnd.s.seljebotnat astro.uio.no writes:
Of course you can always do anything, as numpy.distutils is a living
proof of. Question is if it is good design. Can I be confident that the
hooks are well-designed for my purposes?
Only you
Antoine Pitrou solipsis at pitrou.net writes:
But what makes you think that redesigning everything would make those
Windows features magically available?
Nothing at all.
This isn't about representing constitutencies. python-dev is not a
bureaucracy, it needs people doing actual work.
On Sat, 23 Jun 2012 14:14:46 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Some
projects can be worked on in comparative isolation; other things, like
packaging, need inputs from a wider range of people to gain the necessary
credibility.
packaging already improves a lot over
On Sat, Jun 23, 2012 at 3:29 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Jun 2012 15:28:00 +0200
ezio.melotti python-check...@python.org wrote:
+ .. deprecated-removed:: 3.3 3.5
+ The *strict* argument and the strict mode have been deprecated.
+ The parser is now
Hello,
I've just noticed the following:
$ mkdir foo
$ ./python
Python 3.3.0a4+ (default:837d51ba1aa2+1794308c1ea7+, Jun 23 2012,
14:43:41) [GCC 4.5.2] on linux
Type help, copyright, credits or license for more information.
import foo
foo
module 'foo' (namespace)
Should even an empty
Yes. Otherwise, where to draw the line? What if it contains a single
dot file? What if it contains no Python files? What if it contains
only empty subdirectories?
On Sat, Jun 23, 2012 at 8:25 AM, Antoine Pitrou solip...@pitrou.net wrote:
Hello,
I've just noticed the following:
$ mkdir foo
On Sat, 23 Jun 2012 08:38:02 -0700
Guido van Rossum gu...@python.org wrote:
Yes. Otherwise, where to draw the line? What if it contains a single
dot file? What if it contains no Python files? What if it contains
only empty subdirectories?
That's true. I would have hoped for it to be recognized
Should even an empty directory be a valid namespace package?
Yes, that's what the PEP says, by BDFL pronouncement.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
That's true. I would have hoped for it to be recognized only when
there's at least one module or package inside, but it doesn't sound
easy to check for (especially in the recursive namespace packages case
- is that possible?).
Yes - a directory becomes a namespace package by not having an
Antoine Pitrou solipsis at pitrou.net writes:
packaging already improves a lot over distutils. I don't see where
I don't dispute that.
there is a credibility problem, except for people who think distutils
is sh*t.
I don't think you have to take such an extreme position in order to suggest
On Sat, 23 Jun 2012 17:55:24 +0200
mar...@v.loewis.de wrote:
That's true. I would have hoped for it to be recognized only when
there's at least one module or package inside, but it doesn't sound
easy to check for (especially in the recursive namespace packages case
- is that possible?).
Hi all,
I've checked in the (hopefully final) update of PEP 398: all PEP
scale changes are now final or deferred to 3.4.
I also adjusted the release day to be the 26th of June, which leaves
us with the following rough plan:
- Saturday: last large changes, such as removal of packaging
- Sunday:
On Sun, Jun 24, 2012 at 2:18 AM, hynek.schlawack
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/c910af2e3c98
changeset: 77635:c910af2e3c98
user: Hynek Schlawack h...@ox.cx
date: Sat Jun 23 17:58:42 2012 +0200
summary:
#4489: Add a shutil.rmtree that isn't
It is used automatically on platforms supporting the necessary os.openat()
and
os.unlinkat() functions. Main code by Martin von Löwis.
Unfortunately, this isn't actually having any effect at the moment
since the os module APIs changed for the beta release.
The hasattr(os, 'unlinkat')
Am 23.06.2012 12:54, schrieb g.brandl-nos...@gmx.net:
Hi all,
now that the final PEP scheduled for 3.3 is final, we're entering
the next round of the 3.3 cycle.
I've decided to make Tuesday 26th the big release day. That means:
- Saturday: last feature-level changes that should be done
Original-Nachricht
Datum: Sat, 23 Jun 2012 21:55:55 +0200
Von: Christian Heimes li...@cheimes.de
An: python-dev@python.org
Betreff: Re: [Python-Dev] 3.3 release plans
Am 23.06.2012 12:54, schrieb g.brandl-nos...@gmx.net:
Hi all,
now that the final PEP scheduled for
I've been thinking about extensions to the stable ABI. On the one hand,
introducing new API can cause extension modules not to run on older
Python versions. On the other hand, the new API may well be stable in
itself, i.e. remain available for all coming 3.x versions.
As a compromise, I propose
On Sat, Jun 23, 2012 at 5:31 PM, Martin v. Löwis mar...@v.loewis.dewrote:
I've been thinking about extensions to the stable ABI. On the one hand,
introducing new API can cause extension modules not to run on older
Python versions. On the other hand, the new API may well be stable in
itself,
On Sat, Jun 23, 2012 at 2:31 PM, Martin v. Löwis mar...@v.loewis.dewrote:
I've been thinking about extensions to the stable ABI. On the one hand,
introducing new API can cause extension modules not to run on older
Python versions. On the other hand, the new API may well be stable in
itself,
On Sat, 23 Jun 2012 23:31:07 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I've been thinking about extensions to the stable ABI. On the one hand,
introducing new API can cause extension modules not to run on older
Python versions. On the other hand, the new API may well be stable in
itself,
Am 23.06.2012 23:41, schrieb Antoine Pitrou:
Perhaps something more user-friendly than the hexversion?
IMHO 0x0303 for 3.0.0 is user-friendly enough. A macro like
PY_VERSION(3, 0, 0) could be added, too.
Christian
___
Python-Dev mailing list
On 23.06.2012 23:41, Antoine Pitrou wrote:
On Sat, 23 Jun 2012 23:31:07 +0200
Martin v. Löwis mar...@v.loewis.de wrote:
I've been thinking about extensions to the stable ABI. On the one hand,
introducing new API can cause extension modules not to run on older
Python versions. On the other
On 06/23/2012 03:08 PM, Martin v. Löwis wrote:
On 23.06.2012 23:41, Antoine Pitrou wrote:
Perhaps something more user-friendly than the hexversion?
Please propose something. I think the hexversion *is* user-friendly,
+1 to the idea, and specifically to using hexversion here. (Though what
Am 24.06.2012 01:11, schrieb Larry Hastings:
On 06/23/2012 03:08 PM, Martin v. Löwis wrote:
On 23.06.2012 23:41, Antoine Pitrou wrote:
Perhaps something more user-friendly than the hexversion?
Please propose something. I think the hexversion *is* user-friendly,
+1 to the idea, and
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes li...@cheimes.de wrote:
+1 for the general idea and for using Py_LIMITED_API. I still like my
idea of a simple macro based on Include/patchlevel.h, for example:
#define Py_API_VERSION(major, minor, micro) \
(((major) 24) | ((minor) 16) |
On 06/23/2012 04:44 PM, Chris Angelico wrote:
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimesli...@cheimes.de wrote:
+1 for the general idea and for using Py_LIMITED_API. I still like my
idea of a simple macro based on Include/patchlevel.h, for example:
#define Py_API_VERSION(major, minor,
Am 24.06.2012 01:44, schrieb Chris Angelico:
This strikes me as in opposition to the Python-level policy of duck
typing. Would it be more appropriate to, instead of asking if it's
Python 3.3.0, ask if it's a Python that supports PY_FEATURE_FOOBAR? Or
would that result in an unnecessary
As long as we are _before_ feature freeze, I would have thought it fine. Also,
I'm sure we could allow ourselves some flexibility, after all, it is we that
make these schedules, not the other way round.
But no matter. Condition variable wakeup has been sluggish for many years, I'm
sure our
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes li...@cheimes.de wrote:
Am 24.06.2012 01:11, schrieb Larry Hastings:
On 06/23/2012 03:08 PM, Martin v. Löwis wrote:
On 23.06.2012 23:41, Antoine Pitrou wrote:
Perhaps something more user-friendly than the hexversion?
Please propose something.
56 matches
Mail list logo
