y exercise."
This is effectively a BDFL pronouncement. Nothing has changed the
validity of the premise of the statement, so the conclusion remains
valid, as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
> Do we already have the machines? or do they need to be acquired?
Yes, the machines are all there, see
http://www.python.org/dev/buildbot/all/
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
>> Additionally, I'm very apprehensive about doing any kind of release
>> without the buildbots running. Does anyone know when they might be up?
When I (or somebody else) contacts all the slave operators and asks them
to restart the buildbot slaves.
nce I created it,
and will happily continue to take responsibility for it.
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
that would be possible
to add.
> And since it's the master's perspective that really matters when it
> comes to a buildbot being available, getting status from the master
> would be very helpful.
This sounds very reasonable. I'll ask on the buildbot list; maybe
so
6 doesn't support masks at all, and even for IPv4, I think there are
conventions (if not RFCs) against using them in a way that does not
correspond to a prefix length.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
used for an 31-bit prefix.
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
configuration, it works for me, it works for you,
> probably.
> It is not weird, it is common, it is used for PPPoE, for ADSL, for dialup.
So where is that defined?
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
any applications still display netmasks in dot-quad form, and I would
> be terribly annoyed if I had to count the bits myself before passing it
> to IPv4Address.
I wouldn't ask for that: it should certainly be possible to supply
masks. However, I would want to reject masks that don
e ~/.hgrc, which should list a
single name/email address pair, to be used for all Mercurial
repositories. So I put "Martin v. Löwis " into
.hgrc, which is my name and my email address. It's not the same as the
tracker name or the subversion committer name; it can'
of /31 networks, where an 8-year-old
RFC specifies how to do broadcasts on these. I think RFCs should
be considered wherever applicable.
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
as host addresses, even though STD 3
says that they are reserved and must not be assigned to hosts.
> If after further examination of the
> facts we find that it should be honored, then what do we do for
> .network and .broadcast on a /32 "network"?
For these, I would
t seems most natural
that the IP library is the piece of code that is able to compute a
network out of that input.
Does that answer your question?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
erbose in specifying arguments, whereas getopt's
sequence-of-letters is really nice and compact.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
ecified address, or the network address); following
the Python Zen, we should refuse the temptation to guess.
Unfortunately, that would mean that we should provide two comparison
operations, and have neither available as == (unless one is more clearly
right than the other, which I'm skepti
ill, people proposing that 192.168.1.1/24 should be rejected (I still
don't know whether anybody is actually proposing that) *have* to provide
a proposal how this should be input instead. Otherwise, such proposals
must be rejected, since there is a clear and evident need to support
such i
> Martin v. Löwis v.loewis.de> writes:
>>> Could you explain what benefit there is for allowing the user to create
>>> network objects that don't represent networks? Is there a use-case
>>> where these networks-that-aren't-networks are something other
> You do find "address plus mask" when specifying an IP address for an
> interface. This is a shorthand for specifying the IP address plus the
> network, since the network can be derived from the IP plus the mask.
> But it is a _shorthand_
Ju
rational numbers: clearly, 3÷2 == 6÷4;
would a Python library still remember (and repr) the original numerator
and denominator?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
d reach
> out to them and say this, in a rather more clear fashion. Currently,
> most signs point towards UCS4 builds as being the better option.
There is no such consensus. Linux distributions really should build
Python in UCS-4 mode, and I would be in f
is not that
> much more and does not require you to know to use 'or' or the dict
> constructor along with dict.get() in order to keep it compact.
See above - getopt users don't care about compactness in
the processing.
> I can
> only imagine what some newbi
ipt,
you expect that it either works out of the box, or gives an error
message if it finds that something is wrong with the environment.
So it is quite normal that people who don't understand how the Python
interpreter works (or that it has a Unicode type) install Python.
Regards,
Martin
;format" (like the method name of the
string type), i.e.
logging.Formatter(
format="{asctime} - {name} - {levelname} - {message}")
For the % formatting, I suggest "dicttemplate" (assuming that
you *have* to use dictionary %(key)s style cu
becomes clear when reading the "Backwards Compatibility" section:
# Backwards compatibility can be maintained by leaving the existing
# mechanisms in place. The new system does not collide with any of
# the method names of the existing string formatting techniques
nd "format"; the other option would be to not only deprecate
the positional passing, but also the passing under the name fmt=.
As for calling it "dicttemplate" - I'm sure people can and will propose
alternative spellings :-)
Regards,
Martin
> PEP 291 (Backward Compatibility for Standard Library) mentions logging as
> having
> 1.5.2 compatibility, and I'm thinking that it can be removed from that PEP
> altogether.
Done!
Martin
___
Python-Dev mailing list
Python-De
se case". I do find it puzzling that non of the readers here
can think of any, and the continued assertion that use cases do exist
without them being presented is somewhat disturbing.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.or
hink such consensus is
available, and might not be available for a few more years. Pushing
the issue probably delays obtaining consensus.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
are seemingly rare, though).
> It's two lines in Setuptools.
But that change may be incorrect.
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
case, I probably would not have
moderated the comment away since it was not spam.
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
slog, I don't think that's appropriate. I presume this is meant to
follow RFC 5424? If so, it SHOULD send the data in UTF-8, in which case
it MUST include a BOM also. A.8 then says that if you are not certain
that it is UTF-8 (which you wouldn't be if the application passes a
> I know that the issue tracker for PyPI is (still) on SF, but
> development appear to happen elsewhere and I can't find any
> contact information on the PyPI web pages.
PyPI discussion takes place mostly on catalog-sig.
Regards,
Martin
; What's the value of this attribute? The main reason I ask is there's
> no way that I know of to determine the JIT being used in .NET. We could
> of course fill in some dummy value here for IronPython but I'm also not
> sure why anyone would use this.
Also, why is it t
primary means
of distinction. However, there may be alternative implementations
written in C (e.g. unladen swallow), or otherwise be "C based" (e.g.
pypy).
So I propose that the python.org version is identified as "python".
> name (required):
> mixed case name of the imp
until 2.6.5 is released.
This also speaks against the patch. Anything being changed in this area
ideally should be the final state of affairs for the rest of 2.6.x.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
) would cause severe problems. We
are still trying to recover from the switch to VS 2008. That said,
staying with VS 2003 really hadn't been an option, either. It's
just said that Microsoft has created a new DLL hell in their attempt
to fix the old one, and that they fail to a
it
"candidate". Since the code base of 2.6.4rc1 was not released as-is,
we would need to consider another candidate.
But then, Barry doesn't like release candidates in the first place.
Regards,
Martin
___
Python-Dev mailing li
w
that would fit into the "within the next day or two" plan.
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
> That seems to argue for doing rc2 on Sunday the 18th. If I tag the
> release some time Saturday, you could have the binaries by Sunday
> right?
Correct.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
> The patch I developed for comment only adds const to the input
> parameters and used casts to
> allow output parameters to stay without the const.
What specific APIs are you talking about here?
Regards,
Martin
___
Python-Dev mailing list
P
> I suggest following POSIX's lead and omitted the const in these cases.
Thanks, that sounds reasonable.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
ations would be actually able to use this (or
any other new feature added to 2.7): most code supporting 2.x will also
have to support 2.6, so the keyword won't be available to such code,
anyway.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
r.
In addition, in the *specific* case: the nonlocal keyword isn't
necessary for a transition *at all*. Code that currently works without
it won't need it when ported to 3.x. You may not be able to use it while
maintaining 2.x and 3.x simultaneously, but you can certainly do the
transition ju
noring opportunities
for migrating to Python 3.0. My Django port demonstrates that you
can very well support 2.3 and 3.0 simultaneously:
http://wiki.python.org/moin/PortingDjangoTo3k
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.or
these cases, in order to use the new feature, no change to
Python code will be necessary: the feature just becomes available
transparently.
This is the kind of new features I like to see in 2.7.
The other kind (i.e. features that do require application changes
in o
ut I wouldn't expect that
a moratorium on language changes would rule out adding a method to the
set type.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
As for OS/2: this should probably stay.
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
for a solution quickly. If the source control
is down, somebody *will* "volunteer" to fix it. If the automated
build system produces results less useful, people will worry, but
not take action.
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
build slave
needs to stay connected all the time, so that the build master can
trigger a build when necessary.
So if your setup requires the slaves to shut down after a build, I don't
think this can possibly work.
Regards,
Martin
___
Python-Dev
the one obvious way to do it.
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
t; would see it as a needlessly confusing micro-optimisation.
That's exactly my view.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
though
this might be doing to much with its thread-safety).
- if you absolutely want to use a set as a work queue,
then the .pop() method should be sufficient, right?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
ver several builds, you may find that you have to click away dozens
of such messages. This could use some improvement.
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
ave been removed. For the system messages, there is a way to
turn them off in the parent process. David Bolen (IIRC) had developed
a patch, but I think this patch only runs on his system(s).
Regards,
Martin
(*) it may help if Buildbot would create a Win32 job object, and
then use Term
gh :-))
That's really not an issue. Feel free to play as much as you want, with
the live infrastructure. You can't break anything doing so (perhaps
except for spamming the mailing list with faulty reports). If you then
decide to withdraw your offer, that's fin
buildbots sometimes report false positives. Some tests fail in
a non-repeatable fashion, only on selected systems. So when you
change something, the tests break, and you cannot really see how
this could be possibly related to your change. Then you start
ignoring these reports - both th
to me.
As for EC2 (and other cloud providers); I'm somewhat skeptical about
platform coverage, also. How many different processors and operating
systems can they possibly support?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
htt
dy would volunteer to set up slaves in EC2, and operate them,
I'm fairly certain that the PSF would pay the bill. It might be useful
to have two people operating them, so that the knowledge and the load
is shared.
Regards,
Martin
___
Python-Dev mail
> I don't need to know that it works on every checkin
For us, that is a fairly important requirement, though.
Reports get more and more useless if they aren't instantaneous.
Sometimes, people check something in just to see how the build
slaves react.
Re
n buildbot could also
provide it, of course. Do you have a spec of the interface somewhere?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
r an App Engine App could listen
to 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
Triggered by the recent discussion, I looked at the changes in status
display that the buildbot people have implemented recently. I added
a few links into alternate renderings; see
http://www.python.org/dev/buildbot/
Regards,
Martin
___
Python-Dev
ave comes back, it will pick up pending work. Longer
scheduled downtimes (e.g. for vacations) are acceptable.
Only turning on the slave occasionally makes it useless.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
(except that one
might expect that any takes a predicate as the argument).
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
till skeptical about the need to have something
like this). Also setting aside the moratorium here, which may disallow
that kind of change for a foreseeable feature in any form.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
tively low frequency (though I guess it does have a big
> impact in terms of availability) makes it hard to dedicate time to
> that compared to my "real world" work :-)
In addition, if it was happening frequently, we would rather investigate
the pr
tried that out a couple of weeks ago, but never received any email.
I didn't have the time to look into this further since.
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
> What do you think of creating a "buildbot" category in the tracker? There are
> often problems on specific buildbots which would be nice to track, but there's
> nowhere to do so.
Do you have any specific reports that you would want to classify with
this ca
ses are tested - and we do have machines also that provide
/dev/shm).
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
created a "buildbot" keyword. I gave it the
description
"indicates that tests fail on a buildslave for uncertain reasons"
If that is indeed the intended purpose of this classification, please
keep it in mind when assigning the tag. If I misunderstood the purpose
of the key
, this is indeed the right place for discussion.
For mere inquiries for help, other places are better (such as
python-list). For specific feature requests, use the bug tracker.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python
> Any thoughts/comments/ideas, anything?:)
Announce it to comp.lang.python.announce if you haven't done so, yet.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
- I created one (in case you didn't notice).
As for exchanging info: if you talk about the specific Python buildbot
installation (instead of info about buildbot, the software), then
python-dev is the proper place to exchange info about it.
Regards,
Martin
__
ionally, it would be most simple
if you could invoice the PSF (IIUC). Giving the PSF as the billing
address would probably also work (check with the treasurer).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
> How about:
> "indicates that related test failures are causing buildbot
> instability"
Ok, changed!
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> It's not really reproducible. I think it sometimes happens when I
>> restart the master; sometimes, some clients fail to reconnect
>> (properly).
>
> Another common problem is that some build
s are of
this code (ISTM that multiple threads may simultaneously attempt
to set the drop request, overlapping with the holding thread actually
dropping the GIL). There is also the question whether it is
thread-safe to write into a "volatile int"; I keep forge
Sturla Molden wrote:
> Martin v. Löwis skrev:
>> b) notice that, on Windows, minimum wait resolution may be as large as
>>15ms (e.g. on XP, depending on the hardware). Not sure what this
>>means for WaitForMultipleObjects; most likely, if you ask for a 5ms
>>
Of course, on x86, you won't see any issues, because it's cache-coherent
anyway.
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
it might
be that the machine would have to be up most of the day, as there would
be one build going on always, anyway.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
his is apparently used to satisfy reads
as soon as the cache line is read (so that the cache line can be
discarded earlier). Wrt. to your requirement ("rather timely fashion",
this still seems to be fine).
Still, this all needs to be documented in the code :-)
just the test results.
OTTH, the same could be achieved by buying a hosted server elsewhere.
Regards,
Martin
P.S. Perhaps this *is* the time for Steve to ask for "always-on" machines.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
larger sleep values,
then it loses accuracy.
Why not just call timeBeginPeriod, and then rely on the higher clock
rate for WaitForMultipleObjects?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
ield?
Would you be willing to manage the field (in the sense of managing the
set of values)? If so, please send me a list of values.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
e idea, but it seems to me that some
> integration between the issue tracker and Rietveld would be beneficial.
See
http://psf.upfronthosting.co.za/roundup/meta/issue247
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
me people can agree to drop 2.6 support, 2.7 will be
out of bug fix maintenance already (*). I'm fairly skeptical that people
will be interested in adding new code to specifically clean up their
2.x codebase.
Regards,
Martin
(*) just as it happened with any other release: people are now dro
R. David Murray wrote:
> On Mon, 2 Nov 2009 at 22:17, "Martin v. Löwis" wrote:
>>> I don't currently have an opinion on this backport proposal, but in
>>> regard to this argument: if we do not do any 2.x releases after 2.7,
>>> then over time the n
not sure whether that's because they see themselves also as
users, or because they sympathize with the users, or for other reasons).
In any case, a decision not to release 2.7 should be made before
Benjamin produces the first alpha release.
Regards,
Martin
_
favor back porting as many features from Python 3 as possible.
And if *2.6* becomes the last of the 2.x series?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
3.x might - except
for changes to 2to3, which can simplify porting a lot. But 2to3 should
be run under 3.x, IMO.)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
>> 2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
>> object), which means it is better for people wanting to ease transition to
>> 3.x.
>>
>> But of course, as Martin said, few people will want to support 2.7 only and
>> not
>
MvL concerning psycopg2 port.
You may also want to take a look at my ZODB port:
https://www.dcl.hpi.uni-potsdam.de/home/loewis/zodb/
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
>> I'm not ready for that yet. I think there's plenty of time before we
>> have to agree to such a bleak view. In the mean time let's do
>> something practical like help NumPy port to Py3k.
>
> Or, for example, Django...
See
http://wiki.python.org/
support an
> extension module on Python 2 and Python 3.
>
> YMMV.
Exactly my experience as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
tibility with 2.4 and 2.5.
These I don't know. I found that I had little use for the 3k warnings
in porting to 3k; I usually rely on tests to find out whether the code
still works correctly.
> There is also little documentation on how to port a significant C
> codebase
s.
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
obably be many years in the future.
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
> * General language semantics
> The language operates as-is with only specific exemptions (see
> below).
Would PEP 382 (namespace packages) fall under the moratorium?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python
ango...
>>
>> See
>>
>> http://wiki.python.org/moin/PortingDjangoTo3k
>
> Well, that's certainly a start.
>
> I guess the logical question is: Now what?
Use it, and report bugs.
Regards,
Martin
___
Pytho
doesn't *run* on 2.6? Why?
(not sure what you mean by "targetting")
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
1101 - 1200 of 5755 matches
Mail list logo
