e process of working
on a problem, they will learn that it is better to wait a day or two
before responding, in case you figure it out on your own.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
an only refer to a revision
> previous to the one where it is inserted in .hgtags. If I understand
> correctly, all relevant tagging revisions from SVN are replaced by
> Mercurial revisions setting tags, which then refer to their immediate
> predecessors.
Ah, ok. Thank
e or naïve or *
I didn't consider your message rude. It is perhaps naïve (apparently
ignoring the status quo), but you don't have to apologize for that.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
oint is that we need the
maximum alignment, and that certainly shouldn't be 12.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
Roumen Petrov wrote:
> Martin v. Löwis wrote:
> [SNIP]
>> No. tim_one changed it to be long double in r25454 to support some
>> system that Dave Abrahams uses, so it needs to stay that way :-)
>>
>> However, we can certainly acknowledge that this is a bug in MingW,
alignment of the union to be the
alignment of the union branch that requires that largest alignment.
So if the largest alignment is the one that a pointer has,
then alignof(PyGC_HEAD) == alignof(gc_next). The double is in the
union only in case it has larger alignment than
ne, please provide a patch to bugs.python.org.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
at makes the relevance more
apparent.
Please provide a patch to bugs.python.org.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
mplies that any addition could only depend on Python (and
OS API) - so things *can* be added. For example, setuptools could
be added by this principle. OTOH, if your tool depends on setuptools,
you'll have to wait for setuptools to get included before inclusio
feature, and thus cannot be
backported. I trust his judgement - so to convince me, you would need
to convince Greg first :-)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
> 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
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).
I agree.
Regards,
Martin
_
en the PyGC_Head and the PyObject.
Why is that difficult? It's sizeof(PyGC_Head).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
s to allow inclusion of a "long double"
>> in them)
>
> Well, I doubt that a 12 byte long double causes any other
> alignment but 4.
What you apparently fail to understand is this: On some platforms,
sizeof(long double) == 16, and alignof(long double) == 16.
rwise, array
elements would be misaligned.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
could be changed in
principle as long as the change would be guaranteed not to affect
the structure size.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
he platform's ABI, i.e.
what the maximum alignment is that the compiler gives, and what the
alignment of a malloc() result is. That is unlikely to change even
if x86 evolves.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
port
statements, and then they have to find out how to make those work.
Does your tool help with that?
When the user is not so new anymore, I seriously doubt that they
still ask for a package management tool - except perhaps for
dependencies, and here they use easy_install.
Regards,
Martin
___
if
they haven't installed interbasedb yet?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
dows.
For removal of packages, an alternative *is* available: APR.
> pythonpkgmgr is not so different to that. And the idea behind it is
> to bring consistancy in package management across the different
> platforms.
At the cost of being incon
it "manages packages", I would expect it to manage them
the same way as the native package manager does, but alas, it doesn't
(IIUC). So there are now two incompatible ways to install a package:
either with the native manager, or with pythonpkgmgr. If you in
t; If there is a problem, then it is already a pre-existing problem
> that is not of my doing.
Yes, eggs have the same problem. That's one of the reasons they
don't get integrated into Python.
Regards,
Martin
___
Python-Dev mailing list
P
ase152p1-patches: merges?
Probably merged. I don't recall whether 1.5.2p1 really happened;
in r14966, Fred claims that he merged all changes from 1.5.2p2 (!).
"Hopefully I got all this right!"
I surely hope the same - I doubt anybody would go back and check
whether anything is m
eed to step forward, or we
cannot move to hg.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ld have to be part of the clone, of course, being
versioned, and all that. I think hg is well capable of keeping versioned
configuration information in the clone, as demonstrated by the .hgignore
files.
Regards,
Martin
___
Python-Dev mailing list
Pyt
nd has limitations, and
a long-term one, that improves the hook system of Mercurial to
implement the proper functionality (which then might get shipped
with Mercurial in a cross-platform manner).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyt
er checks and never converts. So if you manage to mess
up, and don't have the hook installed on Unix, you lose when trying
to push. That will teach you to be more careful in the future, or
to install the hook (which hopefully becomes built into Mercurial at
some point).
Whether it is actually
s problem
> in many different contexts, enough to know that it's not obvious what
> the “right” solution is.
The configuration options of svn have served us well enough.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
e to the solution, and sit back and wait for
solutions to emerge. Then you can vote on PEP 385 up or down still.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
hem
very much in Python.
> Well, I'd be happy to help convince the hg crew to accept whatever we
> come up with, but I'm not sure I'm the best person to come up with it.
That is all very well. See my other message (asking for volunteers)
as well. If you have more work you would
> cope with that, hg needs to do extra work on the client side.
I think you still miss the point. *If* hg does the extra work, *then*
Windows users are *not* second-class citizens anymore. They *only*
consider themselves second-class if they have to do additional *manual*
work (*).
Regards,
ile, it would
be good if it supported that cross-platform. It then may make win32text
obsolete (in particular if it provided some useful defaults).
On Unix, the functionality might be as simple as checking conformance
with the eol-style at pre-commit time.
Regards,
Martin
___
fronted
with LF-only files. It is very annoying if you have to look at source
code at somebody else's machine which doesn't have any programmer
editor installed (except for Visual Studio).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@
certainly a bug of the web page. I'm not so sure it's a bug in the
files: I would claim that it's a bug in ViewCVS.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
changed accordingly.
>
> It's certainly ok to convert them to utf-8 (and add the marker anyway).
No, it's not. PEP 8 mandates that non-ASCII code in the Python source
code is in Latin-1.
Regards,
Martin
___
Python-Dev mailin
see
> any good reason for having any encodings but UTF-8 in Python's.)
Just in case my previous message gets overlooked: PEP 8 mandates Latin-1
for Python 2.x source code (except for files that test PEP 263).
Regards,
Martin
___
Python-Dev m
of the PEPs must be made and implemented
- developer documentation needs to be written
- a decision must be made what to do with the migrated parts of
subversion, in the subversion repository
I may have missed some things. I would like to see test period (say,
two weeks) were we can find fur
n principle, perhaps. However, Python doesn't have any .po files, AFAIK.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> This is simply false AFAICS. There was little participation on this
> particular issue during PEP 374 that I can recall. Now that it is
> clearly an issue after all, it's still early in the PEP 385 process.
> Martin has already picked up the ball on EOL support, and has c
> What's the last revision supposed to be? I keep a somewhat regularly
> updated full sync of the Python repo.
We don't know exactly; python-checkins has recorded r74352. If anybody
has a more recent checkout (svn info .), please speak up.
ely, the
RAID controller keeps its configuration on the controller (not
on the disks), so it is unclear still whether the replacement
will be able to recognize the RAID array.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
s
> pattern often enough that it might be in the stdlib.
Can you kindly give one or two examples of where compose would have been
useful?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
xpression, preferably without looking at the patch that
has been proposed first. I bet there is a 50% chance that you get
it wrong (because there are two possible interpretations).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Martin v. Löwis wrote:
>> The reason I came across the old patch was because I was searching
>> for something that did exactly what compose does. That is to say, I
>> had a use case that was compelling enough that I thought there should
>> be something in functools to
/* Can't reference self beyond this point */
Py_DECREF(type);
HTH,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
c? Can I
> safely implement my tp_dealloc function like this?
If you bypass documented API, you really need to study the code,
understand its motivation, judge whether certain usage is "safe" wrt.
to the current implementation, and judge the likelihood of this code
n
r
> module, for example; or `partial` itself for that matter). They are
> there for advanced programmers.
It's quite ok if only advanced programmers know that they are there,
and know how to write them. However, I still think it is desirable
that "lesser" programmers are then abl
because the other lists appeared to be more focused
> on Python-the-language.
The general python-list, or, more specifically, capi-sig.
python-dev is exclusively reserved for current development of Python
(including PEP discussions). It is out-of-scope to ask questions of
the form "how
name.age on all elements of
the list.
> (Aside: how do I look at the patch? The only link I have is here:
> http://mail.python.org/pipermail/patches/2007-February/021687.html
> but I can't see how to get to the patch from there.)
It's best to search for "compose" in the b
table, either, nor would the patch
proposed in #7762 give you an introspectable getter.
ISTM that people have fairly different requirements wrt. that feature.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
tor, which is
a...@python.org. Not sure whether this alias is still useful.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ry: a
short-term one, that operates as a hook and has limitations, and
a long-term one, that improves the hook system of Mercurial to
implement the proper functionality (which then might get shipped
with Mercurial in a cross-platform manner).
Regards,
Martin
__
>>> Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?)
>> 2.5 needs VS 2003.
>
> The 64 bits version of 2.5 is built with VS 2005, though.
Not really - it is built with the compiler in the platform SDK.
Regards,
Martin
_
cast_address
> or something, other names which tell you about the data would seem more
> appropriate (like greatest)
No. I think setting the broadcast address to something else just does
not need to be supported.
Regards,
Martin
___
Python-Dev maili
can't simultaneously create all nodes in the tree and glue
them together, so you have to create the tree in steps - which means
that it will be intermittently incorrect).
You seem to propose some middle ground, but I'm not sure I understand
what that middle ground is.
Regards,
Martin
__
sible to bypass it by filling a
value directly into __dict__?
If you can come up with a patch that checks in a reliable manner,
I would be in favor of adding that (in 2.7 and 3.2), taking out
the corresponding checks when converting to the internal AST.
Regards,
Martin
ot;win32" as a substring, and that has no provision for guessing
line breaks by inspecting files.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
s apparently addressed by
> a patch, assigned to that issue since 2007-12-22.
Apparently, or really? Did you review the patch?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
gt; Assuming I am correct, I am inclined to agree - win32text may be "good
> enough" in the short term, but it is far from ideal.
I also feel that an extension that is inherently platform independent
and has a clear specification has much higher chances of becoming a
standard feature
7;m not sure what would happen in that
> case...
My prediction is that it will depend on whether workable code is
available by the time a decision is made to migrate. If code is
available, then migration will happen (no matter whether the code
has an owner); if no code is a
, I suppose there could be (US) export
> problems with the code, so it would have to be optional (and we might
> not be able to build it into binaries we distribute from python.org).
The zipfile module already supports decryption. I forgot whether we
determined that support f
property?
Won't the person running the zipfile have to enter the password? Whom
would you protect the IP from?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
y
wanted to see their library incorporated instead - or they can just
state that they don't want *this* library to be incorporated for
specific technical reasons.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
quot;The reverse DNS lookup record for this IP address"""
return self._module.int_to_arpa(self._value)
So IPv4 addresses and IPv6 addresses share the same class, but instances
have different values of _module. IPAddress.__init__ looks at the
version keywor
think it's too early to tell. It may be that they have not yet
achieved their purpose - just let's wait fifty more years
(and I'm only half-joking).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
since 2.5.4. However, since several
months have been passed since that release, I'll be creating a 2.5.5
release candidate within a few days.
Further security releases of Python 2.5 will be made until September 2011.
Regards,
Martin
___
Python-Dev ma
t some plans for the future of this
project? In particular, will you continue to work on it?
Thanks,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
re are with that function even exists,
> and it's extremely useful when used correctly...
It has worked in your application. See my example above: it is very easy
to create applications that stop working correctly if you use
setdefaultencod
eas unless you really mean them.
This specific crazy idea must be rejected; it would break backwards
compatibility, for no good reason.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
Chris Withers wrote:
> Martin v. Löwis wrote:
>>>> In retrospect, it should have been called sys._setdefaultencoding().
>>>> That sends an extra signal that it's not meant for general use.
>>> Crazy idea: how about mutating it into sys._setdefaultencoding
impression that Python is full of
problems, when many these warnings really refer to boundary cases only.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
iciently
(so the current implementation is only efficient, but not correct).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
st from the language summit - and by huge, I mean really, really
> big.
Ok, so then it should be easy to generate some real interest out of
it, right? E.g. a somebody actually running the tool, or perhaps even
a bug report?
Regards,
Martin
___
Pyth
0.2.0').ipv6(ipv4_mapped=True)
> IPv6Address('::192.0.2.0')
-0. Call it ipv4_mapped().
If there is to be an ipv6 method, it should take an IPv6Network,
to allow constructing things like 2001:888:2000:d::82.94.164.162.
> 4) IP
> How about moving it to a new repository on hg.python.org
> <http://hg.python.org>? Give it more of an "official" feel without the
> burden of being in theb cpython tree?
Unfortunately, this is not yet set up (i.e. you can't
> Does it sound worthy enough to create a patch for and integrate into
> python itself?
Probably not, given that people think that the algorithm itself is
fairly useless.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.or
areful
if they don't use the extension).
I think subversion's behavior wrt. incorrect eol-style is more subtle.
In some cases, it will complain about inconsistencies, rather than
fixing them automatically.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
) still means that exit is invoked right away, and the return
value of main is the exit code - right?). Calling exit means to call
all exit handlers.
So to match POSIX semantics, we should also call the exit handlers in
the child process (along with invoking a final garbage collect
says that ending the last thread is equivalent to exit(0),
and this is what Python should also do when the last thread ends.
This is independent of somebody calling _exit(), which should have
the very effect that calling _exit has (i.e. immediate process
termination).
Regards,
Martin
__
> I saw on planet Python that the buildbots have currently been shut
> down. I guess this makes my question fairly irrelevant for the moment,
> then :-(
That was a misunderstanding. It was only the community buildbots, and
Grig Gheorghiu is working on restoring them.
Regard
iscussions, please use catalog-sig. For PyPI bug
reports, use the bug tracker.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
blems with OpenID, right?
> and the latter times out attempting a connection for me.
Please try again; it does work most of the time (if it still doesn't
work, check your internet connection).
Regards,
Martin
___
Python-Dev mailing list
Python-
e mercurial list as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
eks ago, so the subversion solution
(of rejecting the commit to happen) doesn't quite work that well for
a DVCS.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> Can anyone (re-) post the specification of the proposed extension, to
> the level that it is currently defined?
For reference, here are the original specification, mine and Martin
Geisler's:
http://mail.python.org/pipermail/python-dev/2009-August/090984.html
http://mail.python.or
s should already be caught on the clients.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ets individually,
>> but only the last of them?).
>
> Yes, the server-side hook will have to work like this in order for
> people to fix mistakes like you just described.
Not necessarily. People could also be required to go back and replay
all changes.
Regards,
Martin
__
n a few minutes. So I conclude that, from a certain
project size on, hg is unusable on Windows, atleast on my office
machine, running Windows 7.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
g, not a technical one).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
y a really good internet connection;
I think hg.mozilla.org does as well. Plus, it worked when doing
it on the very same machine on Linux.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
sitory.
Correct. I believe Martin (the other one) proposed to make it
configurable. I agree that using LF in the repository is sensible.
Wrt. "should": there is the debate whether intermediate revisions
can deviate from that requirement.
> It's not
> clear to me what should be hel
t a feature that
"native" is configurable, per user or per repo. It should default
to CRLF on Windows, but you might want to set it to LF on your
system. In that case, the extension would have just its checking
functionality.
Regards,
Martin
___
>> - Martin Geisler also proposes that there is a section
>> [repository]
>> native =
>> I personally feel YAGNI; it should only support LF (adding such
>> a feature later may be considered)
>
> Do you mean what native is in the repo or what it should be consi
e before the commit ever occurs, minimizing the
> whitespace-only commits even more.
It would, of course, be possible to ban them altogether, at the expense
of users having to replay changes.
Regards,
Martin
___
Python-Dev mailing list
Python-De
l as the time until then), so I would
prefer to make it a week later.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
than
"it works", in particular wrt. the installation procedure.
Of course, testing that it works is a good idea independent of any logo
certification.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
lot of stuff in it that isn't
strictly necessary to provide the feature listed in the rationale.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e PEP at
all yet. I may be able to do so before the end of the year, but can't
promise that.
In any case, I don't see a reason to hurry - if the PEP is adopted
two or three months before the release of 2.7, it will still be in
time, IMO.
Regards,
Martin
__
of enforcing strictness here. There are good use
cases: if you know your address is 82.94.164.162, how do you compute
what you should spell for 82.94.164.162/27? It's very easy to make a
mistake here, and doing the computation in your head is really not
something that should be necessary,
free of charge, and these days also
free of registration.
- these days, specific implementations typically do *not* deviate from
POSIX. Some provide additional features, but in a way that does not
harm compatibility.
Regards,
Martin
___
Python-De
1001 - 1100 of 5755 matches
Mail list logo
