meta tracker.
If you are really interested in these, it would be best to add them
as feature requests to roundup itself (since that really is the place
where they should be provided):
http://issues.roundup-tracker.org/
[but then, roundup could also use more contributors]
Regards,
Martin
__
k tests, because you can't sort a list of interfaces anymore
if that list also contains None. So people decided that zope.interfaces
needs to be changed to disallow None, and that was a significant change
that has not yet been fully understood.
Regards,
Martin
since 1.2, but saying "drop Python
> 2.x and switch to 3 now" is simply not realistic in any of the environments in
> which I use Python daily.
And I wouldn't say that. Instead, I say "support both 2.x and 3.x from a
single code base". That approach can work for s
example, porting to the new buffer interface is may be difficult
and/or a lot of work, and you'll have to do it, anyway. Making it then
conditional (with preprocessor statements), and maintaining both APIs
in parallel for some time, is really not that hard, IMO.
Regards,
Martin
__
(although it
could accept them); IO would continue to return str. Therefore, I'm
skeptical that adding a *third* string type to 3.x would do any good.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
face which is not ported yet.
That's not strictly true, see
http://svn.zope.org/zope.interface/branches/regebro-python3/
While this isn't released yet, Lennart and myself have been working
to make it work on 2.x and 3.x. So porting activities *could* start
now (requi
lts out so that I can try experiments on the 3.x
> interpreter; I have to actually put my experiments into my unit tests
> and wait 10 minutes to see if it works. It's like writing C++.
That's not my experience. I see a change in source (say, on Django)
available for 3.x within 5 secon
x27;d then setup two (sets of) builders; they would share
the slave lock, so builds would run sequentially (unless the slave
operator agrees to setup two slaves on one machine).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:
ge. Recompiling a single file typically takes a
few seconds, or less. It would be possible to also run out of the build
area; you still would need to run "setup.py build" after every change.
There is already support for this in both distutils
Ben Finney wrote:
> "Martin v. Löwis" writes:
>
>> Well, 3to2 would then be an option for you: use Python 3 as the source
>> language.
>
> I was under the impression that 2to3 was officially supported as part of
> Python, but 3to2 was a third-party tool. W
l any simpler: if
3to2 would start using the backport, it would actually get more
complicated (not easier), as it now needs to support two cases.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
this approach is
indeed horrible in terms of efficiency; I question 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
wo slaves, murray-gentoo-wide and pitrou-ubuntu-wide,
same passwords. They configure with the option "--with-wide-unicode"
(if I did that correctly).
I think this means that the 2.x branches will have to grow this option
also (although configure should ignore the option, so it sho
n fact unfamiliar with function
> definitions.
I read Raymond's suggestion rather as a question: why bother with a
tedious, multi-year process, when a three-line function will achieve
exactly the same?
Regards,
Martin
___
Python-Dev mailing list
> JFTR, I didn't set up the IRC bot (I assume that credit goes to Martin,
> even if it's only one line in the buildbot config :). I just tried to
> get it to say something :)
Yes, it was always "on". I don't use IRC regularly, so I don't kno
erts" from whining
> about Python not releasing updated binary distributions though. :-(
The Windows binaries currently build with 0.9.8g. Since changing that
would be a source code change (even though just a single line), I think
a full source release would be necessary (most likely
.x. This can
get eventually replaced by a b 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
on editor that is
> small, fast, convenient and extensible/embeddable. IDLE is small and
> fast, but I feel really uncomfortable with its. The worst thing - I
> can't change it.
This I cannot understand. I have changed IDLE many times.
Regards,
Martin
_
hashes don't
collide).
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
nger/index.
I think for regular removal, the same logic should not apply: if a
series of removals is performed, then further (non-pop) removals
see increasing costs, as do regular lookups. So I think that a removal
should trigger shrinking (with appropriate thresholds) unless it's a
.po
27;t really answer that question before, so I do now: I have not
personally plans to replace it, and I'm skeptical wrt. anybody else's
plans unless there is specific code in existence that IDLE could be
replaced *with*.
Regards,
Martin
___
Pytho
ld be bounded.
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
verflowError
before the import, and the err-occurred check after the import picks it
up.
Of course, your guess is as good as mine.
While barking up trees: My guess is that it's a compiler bug (i.e. the
compiler generating bad code).
Regards,
Martin
_
erve to get bad
performance, as they should use .pop in the first place.
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
eatures to whatever editor we choose later)?
I think neither approach can possibly work. It's always the authors of
contribution who need to act first.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
best, i.e.
not start thinking about 3.2 for another 6 months.
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
page reloads.
> Moreover, some buildslaves have gone back in time (they are building
> r76188 after having built and tested r76195)... I swear the new GIL
> doesn't include a time machine.
That's because I resubmitted these changes after restarting the master.
Regards,
Mart
Benjamin Peterson wrote:
> 2009/11/10 "Martin v. Löwis" :
>> I personally think that decoupling the releases would be best, i.e.
>> not start thinking about 3.2 for another 6 months.
>
> The problem with that is that there is a period of time where 2.x has
&
it would be fine with me.
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
ecently (and
keep hoping that this will improve).
One thing that I always wondered about is the status of importlib.
Will that be used in 3.2?
In addition, I still owe a few answers to comments from the previous
discussion.
Regards,
Martin
___
Python-Dev
a change should not be made.
So don't expect any immediate change to happen.
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/p
take a poll RSN, and see what the majority of users
think (rather than their vocal fraction). Then we can see what to do
about it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
The current rate is roughly 1 comment per day (with peaks of 5
comments), so it takes of rather slowly.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
of packages on a
single day).
My understanding is that spambots target systems where a comment form
is present even in the unloggedin state. In PyPI, you need to create
the account before you can comment.
Regards,
Martin
___
Python-Dev mailing list
Py
ling list.
It's really puzzling that people always assume that people would use
comments primarily to get help, or to report problems. It appears that
nobody expects users to merely comment, voicing their opinion - yet
the comment that triggered this parti
the full list of comments, without actually
counting).
> Even on Amazon, an author could, I presume, add a response to a
> factually incorrect review.
And so they can on PyPI.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
as is a mailing list,
or any other kind of support forum.
I agree that users asking for support should not use the PyPI commenting
system.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
at all the negative
comments come from easy_install users, and all the positive comments
from people who browse through PyPI... Notice however that such
easy_install users often would have to create a PyPI account first.
Regards,
Martin
___
Python-Dev m
Ben Finney wrote:
> "Martin v. Löwis" writes:
>
>> Nick Coghlan wrote:
>>> Particularly if the developer is able to add a prominent link to the
>>> project's own support site or mailing list.
>> It's really puzzling that people always a
n primarily) there for the package
authors, but for the package users (and not surprisingly, it's
primarily the package authors who ask for banning the user opinions).
I'm just not willing to submit to one side; hence the poll.
Regards,
Martin
__
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> I think you are missing the point of the commenting system: these
>> comments are *not* directed towards the package author. Instead, they
>> are directed towards fellow users of the package. For this kind of
number of testing solutions (and
> coverage
>> discovery associated) that would be quite an undertaking.
>
> I'm working on such a thing in my spare time. Yep, it's a big time
> commitment.
>
> http://bitbucket.org/djlyon/pypi-package-
> Users (which includes e.g. language users) tend to be lazy, rather than
> stupid.
Then they likely won't comment on PyPI. To do so, they have to setup an
account (which most don't have). They can't post comments without an
acco
> Why can't we just disable it until we can come up with a better system
> that finds a balance between the rights of maintainers, and those of
> the user?
Because I want to wait for the outcome of the poll first.
Regards,
Martin
ore doing anything
> unilaterally. It's a good idea, this community process. We might want
> to apply it to PyPI one of these days.
And indeed, I do: feel free to participate in the poll.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@py
David Lyon wrote:
> On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. Löwis"
> wrote:
>
>> http://pycheesecake.org/
>
> Ok, so what is the current status on it?
Not sure; you would have to ask Grig. Apparently, there is a service
running somewhere that computes ch
7;m doing right now.
Feel free to announce it places where I didn't.
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
turn different contents
> (the latter being very voluminous)? I always mistake one for the other when
> entering the URL directly.
As Ian says: setuptools relies on it. It's part of the specification of
the package index.
Regards,
Martin
___
Py
sing (English is not
my native language, nor the native language of MAL who proposed this
specific wording)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
sig (the place where PyPI was discussed in recent years),
I mentioned that I would announce it today, which I now have.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
ward a link to a survey through that twitterfeed - which I suspect
> is a mix of users of PyPI and uploaders to PyPI.
Feel free to annouce it on Twitter - I don't use that system myself.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@py
python language itself*, but generated a lot of
> traffic.
+1. The place to discuss pypi is catalog-sig.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
the relevance of the
search term that is.
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
create an account will be excluded.
This is indeed intentional: people like you won't upload packages to
PyPI, nor will they take part in the rating system, as both require
a PyPI account.
Regards,
Martin
___
Python-Dev mailing list
Python
> Martin, are you interested in help?
Certainly, yes. For the specific feature in question, I'd like to wait
for the outcome of the poll. Otherwise, contributions are welcome.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.
s it
> just burped on its own :-)
It was actually an Apache misconfiguration (the wrong virtual host would
pick up requests, missing the reverse proxy configuration). I have fixed
that now.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pytho
-topic for python-dev; PyPI discussion should take
place on catalog-sig.
I personally had problems following your message, as it seemed to mix
too many aspects into one message.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
eople you say you
> care most about - i.e., those people browsing the index and looking for
> packages. The *consumers* of the comments, in other words.
Ok: "intentional" is not the right attribute. It's more that I don't
consider it too harmful.
Regards,
Martin
___
I recommend that you get a google account for your email address,
and register to PyPI using OpenID.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
> And that registration should be using any OpenID, so that I don't need
> any new identities to participate on the Python sites: I can re-use
> existing identities.
PyPI actually does support OpenID.
Regards,
Martin
___
Python-Dev maili
ython-devel. (like Fedora)
I don't see a problem with that: you'll need the python-devel package
*anyway* when running distutils, for many packages.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
oes not make sense
> anymore for linux distros to have two distinct packages for Python.
>
> Having some of the makefile vars stored in stdlib solve this problem.
I don't see how this can solve the problem. Distutils contains the
build_ext co
providers, their claimed ID will still change, and they'll have
to reregister in all services they use.
Please correct me if I'm wrong.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
> I'm afraid the PyPI implementation of openid is useless to me too - I
> want to use voidspace.org.uk as my openid but it doesn't let me.
See above - the services may let you *enter* that string, but it
isn't your openid.
Regards,
Martin
___
ntity?
IOW, why should I (as a relying party) pay any attention to the ID
that you entered, rather than to what I get actually validated?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
y help users to remember their openid more easily, and always fill
in the same text into the login box.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
the "claim openid" place,
follow the Launchpad link. It should guide you through the procedure.
Then, when you want to login, again follow the Launchpad link on the
front page.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.
> Why not allow users to login with their own openid, but
> only allow one account to refer back to the same delegated account?
That sounds good. I'm not sure how to implement a provider change
in that scenario, though.
Regards,
Martin
___
Pyt
s...@pobox.com wrote:
> Martin> That's indeed what PyPI attempts to do. At the "claim openid"
> Martin> place, follow the Launchpad link. It should guide you through
> Martin> the procedure.
>
> Well, since I use Google a lot more I'd
e
verifiable ID, and log you in with that.
For this to work, you would have to upgrade your web page to OpenID 2,
as this is the only protocol that PyPI supports.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
> Would it be possible to detect a change of provider and then offer the
> option to migrate the account to the new provider (so long as it does
> not conflict with another account)?
That would be possible - but again complicate the UI.
Regard
Michael Foord wrote:
> Martin v. Löwis wrote:
>>> Would it be possible to detect a change of provider and then offer the
>>> option to migrate the account to the new provider (so long as it does
>>> not conflict with another account)?
>>>
>>
>
ocess
} else
#endif
if (PyLong_Check(o)) {
i.e. eliminating the int case altogether. For another example,
long foo = PyInt_AsLong(Foo);
has a hidden error in 3.x, with intobject: PyLong_AsLong might
overflow, which the 2.x case doesn't.
So eliminating intobject.h likely helps avoiding subt
l.
So with intobject.h, the code will happily compile, but then
fail to detect an exception at run-time - causing other
difficult-to-find bugs.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
ain by using macros somebody else wrote are
really minor.
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
ion
gets discarded, and it wasn't possible anymore to find out what version
of the svn command the slave implements, hence the exception.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
trategy. Christian Heimes created
PCbuild/build_tkinter, so he would probably prefer to use that instead.
When I took over Windows builds from Tim Peters, PCbuild/readme.txt
was the official reference, and I try to stick 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
rvice
off.
> and I thought daily -latest builds for Python latest on Windows and Mac would
> be a good demo...
I'll guess that you will find the same: nobody is really interested
in *using* daily builds of Python.
> OK, I see. Thanks
> I went to double-check this on the buildbots and noticed that there
> aren't any Mac OS X buildbots.
That's not true, see
http://www.python.org/dev/buildbot/builders/x86 osx.5 trunk
Regards,
Martin
___
Python-Dev mailing list
Pytho
on't think we should make
assumptions beyond what standard C guarantees.
Regards,
Martin
(*) If you wonder why the gcc behavior is conforming to C:
if a+1 does not overflow, it will be indeed greater than a,
and the result is 6.
If a+1 does overflow, undefined behavior occurs, and the
pro
extend, yet others perform the shift unsigned
(i.e. zero-extend).
I'd rather prefer to explicitly list what CPython assumes about the
outcome of specific operations. If this is just about &, |, ^, and ~,
then its fine with me.
Regards,
Martin
_
, it is unclear (to me, at
least) what the consequences are. So I'd rather see an explicit list
of consequences, instead of buying a pig in a poke.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
what kind
of code would be ok, and which would not. Perhaps it should include
both a black list and a white list: some may assume that two's
complement already provides guarantees on left-shift, when it
actually does not (**).
Regards,
Martin
(*) I wonder why you are not talking about padding bit
tly in the failing case.
To do so, you may want to familiarize with pdb. Put
import pdb;pdb.set_trace()
into the failing test case, and try single-stepping through it. Make
sure stdin/stdout doesn't get redirected, since that confused pdb.
HTH,
Martin
__
;
> Does this seem like an acceptable change?
Definitely not. This will be just for 2.7, and I see no point in
producing such an incompatibility. Applications may already perform
the conversion themselves, and that would break under such a change.
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
ith each other,
either. You can reach the PSF at p...@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
breaking them
(as a minidom tree *is* cyclic). minidom has this explicit API for
breaking cycles because it predated the introduction of cyclic GC
in Python.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Julien Danjou wrote:
> At 1261178549 time_t, Martin v. Löwis wrote:
>>> Is there to chance to see this *bug* fixed someday?
>> Please ask on python-dev. I may be willing to revive my five-for-one offer.
>
> Not sure I really understand, but I can ask gain here:
> w
ews might be that
we could build trust in the reviewer not just to check in everything,
but apply careful review before.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
y parts of Python,
you must follow the license, in particular clause 2.
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
Thomas Heller wrote:
> I have to shutdown the x86 osx 5 buildbot slave permanently, because
> the machine is getting a new role. Martin, please remove it from
> the configuration.
Thanks for the notice; I have now removed it from the list.
Regard
e-introduction in v1.3 of the format).
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
ls only
> produces metadata v1.2 PKG-INFO files (even if the options used by the
> developer could be written in a valid 1.0 format).
>
> This will be clearer I think.
It would be also incompatible with existing consumers that expect
a Python package to have an earlier version o
used in the future ?
In terms of conformance, what would that mean? If I implement 1.0 (in
addition to also implementing 1.2), would I then be non-conforming
(because the PEP says I should not support 1.0)? For PyPI, that would
be fairly bad, as it will need to support earlier versions for many
years t
of the metadata.
>>> Dropping 1.0 may be fine though - but again, this is out of scope
>>> here.
>
> That's a software implementation issue. Not a metadata issue.
Above you say that the PEP should specify whether to keep or drop 1.0
and 1.1, and now you say
asking that
what Tarek calls a "reference implementation" should be called a
"sample implementation" instead. I'm asking for that precisely to avoid
a skew towards a particular implementation.
Regards,
Martin
___
Python-Dev mailing list
> I'll remove it and push it in Distutils documentation, then might just
> provide a link in the PEP References.
That sounds fine to me.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
h more sense. It was simple and unambiguous, and is relevant
> to typical packaging scenarios.
Unfortunately, it is fairly ambiguous, and makes no sense. It means
"requires Python 2.5 *AND* requires Python 2.6", which is a requirement
that
o be IMO.
>
> An implicit range operator is simpler indeed, and achieves the same goal.
>
> Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well.
So that "2.5.4<=2.5", "2.5<=2.5.2", but not "2.5.4<=2.5.2
nd", see
http://www.python.org/dev/peps/pep-0345/#version-specifiers
If the comma would mean "or", then what would ">1.0, !=1.3.4, <2.0"
mean?
above 1.0 OR unequal to 1.3.4 OR below 2.0
That would mean that *any* version would match t
1201 - 1300 of 5755 matches
Mail list logo
