On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes 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. I
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 us
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 prol
On 06/23/2012 04:44 PM, Chris Angelico wrote:
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes 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) \
(((m
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes 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) | ((micro)
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, an
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
On 23.06.2012 23:41, Antoine Pitrou wrote:
> On Sat, 23 Jun 2012 23:31:07 +0200
> "Martin v. Löwis" 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 ne
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
Pytho
On Sat, 23 Jun 2012 23:31:07 +0200
"Martin v. Löwis" 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, i.e. remain
On Sat, Jun 23, 2012 at 2:31 PM, "Martin v. Löwis" 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, i.e. remain av
On Sat, Jun 23, 2012 at 5:31 PM, "Martin v. Löwis" 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, i.e. remain av
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 th
Original-Nachricht
> Datum: Sat, 23 Jun 2012 21:55:55 +0200
> Von: Christian Heimes
> 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 3.3 is
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 b
>> 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, 'un
On Sun, Jun 24, 2012 at 2:18 AM, hynek.schlawack
wrote:
> http://hg.python.org/cpython/rev/c910af2e3c98
> changeset: 77635:c910af2e3c98
> user: Hynek Schlawack
> date: Sat Jun 23 17:58:42 2012 +0200
> summary:
> #4489: Add a shutil.rmtree that isn't suspectible to symlink attacks
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: f
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 possibl
Antoine Pitrou 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 that
th
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 __init
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:
htt
On Sat, 23 Jun 2012 08:38:02 -0700
Guido van Rossum 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 only when
the
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 wrote:
>
> Hello,
>
> I've just noticed the following:
>
> $ mkdir foo
> $ ./python
>
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
Should even an empty directory be a val
On Sat, Jun 23, 2012 at 3:29 PM, Antoine Pitrou wrote:
> On Sat, 23 Jun 2012 15:28:00 +0200
> ezio.melotti 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
On Sat, 23 Jun 2012 14:14:46 + (UTC)
Vinay Sajip 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 distutils. I don't see wh
Antoine Pitrou 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. People c
On 06/23/2012 03:20 PM, Vinay Sajip wrote:
Dag Sverre Seljebotn 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 th
On Sat, 23 Jun 2012 15:28:00 +0200
ezio.melotti 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 only valid markup?
R
On Sat, 23 Jun 2012 13:14:42 + (UTC)
Vinay Sajip 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 that all constituenci
Dag Sverre Seljebotn 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.
> And of c
Antoine Pitrou 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.
Right, but
On 06/23/2012 02:27 PM, Vinay Sajip wrote:
Dag Sverre Seljebotn 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
unc
On Sat, 23 Jun 2012 12:32:37 +
Kristján Valur Jónsson 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 might be. But to eval
On Sat, 23 Jun 2012 12:27:52 + (UTC)
Vinay Sajip 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 the dafter limitatio
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 exampl
Dag Sverre Seljebotn 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 much good can
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
On Sat, 23 Jun 2012 13:12:19 +0200
Antoine Pitrou wrote:
> On Sat, 23 Jun 2012 11:00:34 +
> Kristján Valur Jónsson wrote:
> > I realize it is late, but any chance to get
> > http://bugs.python.org/issue15139 in today?
>
> -1.
Let me elaborate: the patch hasn't been reviewed, and it's a ver
On Sat, Jun 23, 2012 at 9:53 PM, David Cournapeau 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 distutils-sig. pyth
On Sat, Jun 23, 2012 at 1:25 PM, Nick Coghlan 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
Python-Dev@python.org
htt
On Sat, Jun 23, 2012 at 12:25 PM, Nick Coghlan wrote:
> On Sat, Jun 23, 2012 at 8:37 PM, Lennart Regebro 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 t
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 wrote:
> On 22 June 2012 17:56, Donald Stufft wrote:
>> On Friday, June 22, 2012 at 12
On Sat, Jun 23, 2012 at 8:37 PM, Lennart Regebro 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 explanation of *why
On Sat, 23 Jun 2012 11:00:34 +
Kristján Valur Jónsson 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
http://mail.python.o
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
packaging/bu
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önd
g.brandl-nos...@gmx.net [g.brandl-nos...@gmx
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 featur
On 22 June 2012 17:56, Donald Stufft 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 x509 certs to packag
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
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
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 o
> 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.");
> ret
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. Tha
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 OS
56 matches
Mail list logo
