> You can't seriously expect users to wait for years for an integrated
> package management tool. Especially on Windows - that's cruel :-)
Hmm. I'm -0 on providing a tool whose only purpose is to download
files from a web server. I always use a web browser for that...
> A Package Manager isn't a
On Sat, 25 Jul 2009 11:42:13 +0200, "Martin v. Löwis"
wrote:
>> It's my intention to get a Package Manager included in standard
>> python - yes.
>
> In addition to the other constraints you'll have to meet for this
> to happen, you also have to wait a rather long time (several years)
> before inc
On Sat, 25 Jul 2009 12:47:21 -0400, Terry Reedy wrote:
The Python Package Manager can be written to work in console mode.
>>> I think this would be best.
>>
>> Haha - I'm glad somebody took this seriously... It was a sort of a joke
>> comment but it's a serious possibility.
>
> I took it
>Maximum alignment currently on x86 is 16 bytes for SSE vector
> types. Next year AVX will add 32 byte types and while they are
> supposed to work OK with 16 byte alignment, performance will be better
> with 32 byte alignment.
That doesn't really matter. What matters is the platform's ABI, i.e
Martin v. Löwis:
> Yes: alignof(PyGC_HEAD) would be specified as being the maximum
> alignment on a platform; sizeof(PyGC_HEAD) would be frozen.
Maximum alignment currently on x86 is 16 bytes for SSE vector
types. Next year AVX will add 32 byte types and while they are
supposed to work OK with
On 2009-07-25 17:28, Brett Cannon wrote:
On Fri, Jul 24, 2009 at 18:06, Jean-Paul Calderone mailto:exar...@divmod.com>> wrote:
On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney
mailto:ben%2bpyt...@benfinney.id.au>>
wrote:
[snip]
If that is not your intent, then your
On Sat, Jul 25, 2009 at 15:28, Brett Cannon wrote:
>
>
> On Fri, Jul 24, 2009 at 18:06, Jean-Paul Calderone wrote:
>
>> On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney <
>> ben+pyt...@benfinney.id.au > wrote:
>>
>>> [snip]
>>>
>>> If that is not your intent, then your application shouldn't be ment
On Fri, Jul 24, 2009 at 18:06, Jean-Paul Calderone wrote:
> On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney
> >
> wrote:
>
>> [snip]
>>
>> If that is not your intent, then your application shouldn't be mentioned
>> in standard Python documentation.
>>
>>
> Hm. But docutils isn't part of the stand
On Thu, Jul 23, 2009 at 4:28 PM, Thomas Wouters wrote:
>
> So attached (and at http://codereview.appspot.com/96125/show ) is a
> preliminary fix, correcting the problem with os.fork(), os.forkpty() and
> os.fork1(). This doesn't expose a general API for C code to use, for two
> reasons: it's not ea
On Sat, Jul 25, 2009 at 2:53 AM, "Martin v. Löwis" wrote:
>> This is fixed in the trunk (Revision 72880), but there has been number
>> of valid requests to backport it Python 2.6. While I agree and ready
>> to backport to Python 2.6, I would like to ask here if there are any
>> objections in this f
David Lyon wrote:
The Python Package Manager can be written to work in console mode.
I think this would be best.
Haha - I'm glad somebody took this seriously... It was a sort of a joke
comment but it's a serious possibility.
I took it seriously too ;-). It seems to me that you project can
> We could add a PY_LONG_LONG to the mix just in case.
> By the way, will this kind of thing be frozen by the PEP ABI?
Yes: alignof(PyGC_HEAD) would be specified as being the maximum
alignment on a platform; sizeof(PyGC_HEAD) would be frozen. The
actual content would not be frozen, i.e. it could b
>> Why is that difficult? It's sizeof(PyGC_Head).
>
> Is it enough to correctly propagate the alignment for, say, a long double in
> the following PyObject? I'm sorry, I'm not enough of a C lawyer.
Yes, sizeof must always be a multiple of the alignment. Otherwise, array
elements would be misalign
Antoine Pitrou pitrou.net> writes:
>
> We could add a PY_LONG_LONG to the mix just in case.
> By the way, will this kind of thing be frozen by the PEP ABI?
(I meant the ABI PEP, sorry)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
Neil Hodgson gmail.com> writes:
>
> typedef union _gc_head {
>struct {
>union _gc_head *gc_next;
>union _gc_head *gc_prev;
>Py_ssize_t gc_refs;
>} gc;
>long double dummy; /* force worst-case alignment */
>double dumm
Martin v. Löwis:
> I propose to add another (regular) double into the union.
Adding a regular double as a second dummy gives the same sizes and
alignments with Mingw or MSVC as the original definition with MSVC:
typedef union _gc_head {
struct {
union _gc_head *gc_next;
On Sat, 25 Jul 2009 10:28:51 +0100, Paul Moore wrote:
> ??? I see no bias as you describe in the distutils enhancement work.
ok
> Native applications are by definition not platform neutral. How does
> your proposal help Linux users? Mac OS? Solaris?
I'm doing a Linux/Solaris version. But I find
On Sat, 25 Jul 2009 16:00:13 +1000, Ben Finney
wrote:
> I think you know quite well what “depend on” means in this instance,
> so this is taking it to silly extremes.
haha - yes - no offence.
It was just bad humour.
Have a nice weekend
David
___
Pyt
Martin v. Löwis v.loewis.de> writes:
>
> > In addition to that union, we should also have a particular mechanism to
compute
> > what the proper offset should be between the PyGC_Head and the PyObject.
>
> Why is that difficult? It's sizeof(PyGC_Head).
Is it enough to correctly propagate the al
> For that reason, I don't like the addition of the opaque header
> too much. If there were an option to make the header explicit,
> we would not have to round up the object size to a multiple
> of (8, 16), but could arrange embedded doubles as they fit the best.
We could add the gc head *after* t
> Antoine Pitrou pitrou.net> writes:
>> In any case, you seem to be right on this particular point: the PyGC_Head
>> union
>> should probably contain a "double" alternative in addition to the "long
>> double"
>> (and perhaps even a "long long" one).
>
> Sorry, I realize that this doesn't really
>> This may not be recognized so far, because there is no builtin
>> GC-enabled type that embeds a double.
>> But if you create such a type, then the double will be correctly
>> aligned in your object's structure, but then, when the object
>> gets allocated, it is misaligned, because the header siz
> To Martin: So I disagree. The gc header is not responsible for
> alignment in the first place, but to propagate it, correctly.
I think we are in agreement in this respect. That's the whole point
of the long double: to make the gc head's alignment the maximum
alignment on that platform
> And thi
> This is fixed in the trunk (Revision 72880), but there has been number
> of valid requests to backport it Python 2.6. While I agree and ready
> to backport to Python 2.6, I would like to ask here if there are any
> objections in this front.
In msg76855 Greg ruled that it is a new feature, and th
> It's my intention to get a Package Manager included in standard
> python - yes.
In addition to the other constraints you'll have to meet for this
to happen, you also have to wait a rather long time (several years)
before inclusion becomes possible. This time is necessary for the
community to acc
2009/7/25 David Lyon :
>> It would, in fact, be best to work with the team performing ongoing
>> active standardisation of distutils functionality.
>
> I am already doing that.
>
> But there is a bias against windows development and a bias
> against native applications. That's fine because I know t
26 matches
Mail list logo
