Re: [Python-Dev] Mercurial migration: help needed

> From my POV, this would be required in some form or another before such > a scheme could actually work. Without it we end up with an improved > win32text (good!) I still think this would be actually bad. Instead, a new extension should be written, with a name that does not have "win32" as a su

Re: [Python-Dev] Issue 1170: Unicode for ‘shlex ’

> What is the procedure for finding out why an issue hasn't progressed? It's fairly simple: just read through the issue, and it should be obvious. In the specific case, no committer has ever commented on the issue, so chances are high that no committer has ever *seen* the issue. > I don't want to

Re: [Python-Dev] Mercurial migration: help needed

>>> From my POV, this would be required in some form or another before such >>> a scheme could actually work. Without it we end up with an improved >>> win32text (good!) >> >> I still think this would be actually bad. >> >> Instead, a new extension should be written, with a name that does not >>

Re: [Python-Dev] Mercurial migration: help needed

> If this becomes seen as 'my' cause, I suspect it will run out of steam > very quickly. I truly hope python-dev, as a community, takes some > ownership of this issue That certainly won't happen. python-dev, as a community, has never ever taken ownership of anything. It's always individuals who t

Re: [Python-Dev] Support for Encrypted Zip as python scripts

>> No doubt this is a useful functionality to have but it would be great to >> have some comments on whether >> this can be(or even should be) feasibly added as an inbuilt support. > > MvL already asked for a patch so I suppose that means he thinks it's > useful. I am actual skeptical that it is

Re: [Python-Dev] Support for Encrypted Zip as python scripts

Bugbee, Larry wrote: >>> I like the idea, but... >> For what use case? > > I don't have a specific case in mind. In general, however, it would be > nice to be able to protect intellectual property This I'm also unclear about. How does it protect intellectual property? Won't the person running th

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

> ipaddr looks like a reasonable library from here, but AFAIK it's not > widely used outside of google. I don't know if it's reasonable to > want some amount public usage before a brand-new API goes into the > standard library, but such use is more likely to uncover API flaws or > quirks than a PE

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

>> netaddr employs a simple variant of the GoF Strategy design pattern (with > added Python sensibility). > > It would be nice if you could avoid employing this kind of acronyms without > explaining them. Not everybody drinks the design pattern kool-aid. > (Google tells me that GoF seems to mean "

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

>> DrKJam gmail.com> writes: >>> netaddr employs a simple variant of the GoF Strategy design pattern (with >> added Python sensibility). >> >> It would be nice if you could avoid employing this kind of acronyms >> without explaining them. Not everybody drinks the design pattern >> kool-aid. > > A

[Python-Dev] No 2.4.7 release

I once announced that I would be working on releasing 2.4.7 this month. However, since no patches have been committed to 2.4.6, there is little point in making a release. As 2.4 is nearing its end-of-life soon, there likely won't be any 2.4.7 release. Python 2.5 has seen only two patches since 2.

Re: [Python-Dev] 3to2 0.1 alpha 1 released

> I have released the first alpha version of 3to2 after finishing it for > my Google Summer of Code 2009(tm) project. Congratulations! I understand SoC is basically over, but I would still like to request two things: - can you please register it with PyPI? - can you please announce/report some pl

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

>> The ability to change the default encoding is a misfeature. There's >> essentially no way to write correct Python code in the presence of >> this feature. > > How so? If every single piece of text in your project is encoded in a > superset of ascii (such as utf-8), why would this be a problem?

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

>> 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 rather > than deleting it? Please don't post crazy ideas unless you really mean them. This

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

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

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

>> One specific problem is dictionaries will stop working correctly if you >> set the default encoding to anything but ASCII. > > ...except they haven't. In your application. Can you please agree that this a semantical problem that is completely unacceptable for language design? > Indeed, but t

Re: [Python-Dev] deleting setdefaultencoding iin site.py is evil

> if hasattr(sys, "setdefaultencoding"): > +sys._setdefaultencoding = sys.setdefaultencoding > del sys.setdefaultencoding Ah, so you didn't want to rename the function. I agree that this would not break backwards compatibility. I guess the basic objection remains: making it

Re: [Python-Dev] 3to2 0.1 alpha 1 released

>> None at the moment. I think the community needs to show its interest >> in it and Joe his willingness to maintain it in the future in order >> for it to qualify for addition to the stdlib. > > Is that how 2to3 got in? If I remember correctly, this was a huge > request from the language summit -

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

> IPv6Address.is_ipv4_compat > IPv6Network.is_ipv4_compat > > Returns True if this address/network is IPv4-compatible IPv6 e.g. > ::192.0.2.0 or ::192.0.2.0/124 , False otherwise. -1. These addresses are deprecated. > IPv6Address.is_ipv4_mapped > IPv6Network.is_ipv4_mapped

Re: [Python-Dev] 3to2 0.1 alpha 1 released

> How about moving it to a new repository on 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 push to it). Regards, Martin _

Re: [Python-Dev] Fast Implementation for ZIP decryption

> 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.org http://mail.pyth

Re: [Python-Dev] Mercurial migration: help needed

> I suggested a new extension for two reasons: > > * I'm using Linux, and I mentally skip over all extensions that mention > "win32"... I guess others do the same, and in this case it's really a > shame since converting EOL markers is a cross-platform problem: if > someone creates a reposito

Re: [Python-Dev] Whether to call Py_Finalize when exiting from the child process of a fork from a spawned thread

> On one hand, you may not want to call the user's atexit handlers > multiple times from different processes if they have externally > visible effects. On the other hand, people seem to assume that > Py_Finalize will be called at process exit to do various cleanups. On > the third hand, maybe Pyt

Re: [Python-Dev] Whether to call Py_Finalize when exiting from the child process of a fork from a spawned thread

>> Standard POSIX fork semantics should be a guidance. IIUC, termination >> of the last thread is equivalent to calling exit(0) (although return >> from main() 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

Re: [Python-Dev] Setting up a buildbot

> 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. Regards, Martin _

Re: [Python-Dev] OT : Cannot login to PyPI using MyOpenId

Olemis Lang wrote: > I realized that PyPI accepts MyOpenId and tried to login to the site. > In the process I get this message : > > {{{ > OpenID provider did not provide your email address > }}} > > I mean, is it mandatory to provide the e-mail address in order to bind > a user to an OpenId ? >

Re: [Python-Dev] OT : Cannot login to PyPI using MyOpenId

>> For general PyPI discussions, please use catalog-sig. For PyPI bug >> reports, use the bug tracker. > > The Python bug tracker http://bugs.python.org/>? Or the tracker > linked from http://pypi.python.org/pypi?:action=openid> which leads > to http://sourceforge.net/tracker/?group_id=66150&atid=

Re: [Python-Dev] Mercurial migration: help needed

> What is the hope of an EOL extension which meets our requirements coming > directly out of the hg community? If that hope is small, where does > that leave us? As before. I'll repost my request for help, and we stay with subversion meanwhile. Perhaps I'll post it to some mercurial list as well

Re: [Python-Dev] Mercurial migration: help needed

> I'm starting to wonder what the problem really is that makes it so > Python-specific. If I understood correctly, it's about a couple of files which > must be stored using non-Unix line endings, right? (in the PC and PCbuild > directories?) No. It's about files that must, when checked out on Wind

[Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

> 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.org/pipermail/pyt

Re: [Python-Dev] Mercurial migration: help needed

> I don't think this problem is really serious. > If the push fails, you can just commit (locally) a new changeset that > repairs the EOL or indentation problems I would find that unfortunate. It's a fairly irrelevant change, yet it may manage to corrupt the history (hg blame). > and push the who

Re: [Python-Dev] Mercurial migration: help needed

>> I don't think this problem is really serious. If the push fails, you >> can just commit (locally) a new changeset that repairs the EOL or >> indentation problems, and push the whole bunch of changesets again (I >> assume the server-side hook will not examine changesets individually, >> but only

Re: [Python-Dev] Mercurial migration: help needed

> FWIW, I had the same impression as Antoine. I am aware that 'stupid'pad > requires /r/n, but do IDLE and other editors (on Windows) that people > would actually use to create/edit such files? I would personally be > willing to install a notepad replacement if needed to quickview such files. Visu

Re: [Python-Dev] Mercurial migration: help needed

>> But it shouldn't happen often that the server refuses a push; >> all errors should already be caught on the clients. > > We could just mandate the same hook code as a commit hook. I would be in favor (although, IIUC, "mandate" here would be a social thing, not a technical one). Regards, Marti

Re: [Python-Dev] Mercurial migration: help needed

> I know a lot of projects use Mercurial on Windows as well, I'm not > aware of any big problems with it. I trust that indeed, there are no big problems for most users. I also trust that the hg developers are, in general, open to incorporating improvements on Windows. I'm still skeptical though w

Re: [Python-Dev] Mercurial migration: help needed

> There are 2 separate questions - (1) what is held in the repository, > and (2) what is in the user's workspace. The two clearly interact. [...] > As regards (1), I assume that for "text" files, a consistent EOL > convention (assumed LF) should be used in the repository. Correct. I believe Martin

Re: [Python-Dev] Mercurial migration: help needed

>> 2. Allowing text files to be checked out in whatever form the user >> prefers seems complicated. The alternative would likely be to say test >> files are checked out in "native" form. That works, but would irritate >> me as I work on Windows, but prefer strongly to use LF line endings >> (yes, I

Re: [Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

>> - 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 considered > on the user's machine? The

Re: [Python-Dev] hgeol extension (Was: Mercurial migration: help needed)

> Right, but I am just thinking about how we specify in .hgeols what the > repository is expected to be as this extension might work out nicely > for other projects who prefer CLRF as their repo-native line ending. This is what I refer to as YAGNI. Subversion has LF as the internal storage, and, I

Re: [Python-Dev] Python 2.6.3

Barry Warsaw schrieb: > I had previously wanted to release Python 2.6.3 over the summer, but for > various personal reasons, the summer was just too insane. I'd like to > reschedule a 2.6.3 release, shooting for final release on 25-September. I'm travelling that week (as well as the time until th

Re: [Python-Dev] FWD: Front Runner Program

> My recently acquired* MSDN account has led me to getting XP up and > running in a VM, and I would be happy to try other Windows OSes of > interest. Without checking the specific program, I think chances are that there are higher requirements for being listed in some Microsoft list than "it work

Re: [Python-Dev] clarification on PEP 3124 status

> Could somebody please clarify the status of PEP 3124? At > http://ftp.python.org/dev/peps/ , it is listed as "under > consideration", but http://ftp.python.org/dev/peps/pep-3124/ says it > has been deferred. This isn't really contradictory. "under consideration" means "in progress": it has neith

Re: [Python-Dev] PEP 3144 review.

> What's the opinion of the other interested party or parties? I don't > want a repeat of the events last time, where we had to pull it at the > last time because there hadn't been enough discussion. I'm slightly interested, but didn't have the time to review the PEP at all yet. I may be able to d

Re: [Python-Dev] PEP 3144 review.

>>> I don't see any valid reason for entering a network as >>> "192.168.1.1/24" rather >>> than the canonical "192.168.1.0/24". The former might indicate a >>> typing error >>> or >>> a mental slip, so let's be helpful and signal it to the user. >> >> Or perhaps there can be an optional "strict=Tru

Re: [Python-Dev] POSIX [Fuzziness in io module specs]

>> I >> believe POSIX documentation to be more accessible to a variety of Python >> developers than other system's, and it's better documented: rationales >> are included, history is available, etc. > > I'm not sure that's true. Various Unix/Linux man pages are readily > available on the Internet

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

Zooko O'Whielacronx wrote: > I'm sorry, I should have mentioned that I did read those archives > before I posted my letter. That discussion was all about whether UCS2 > or UCS4 is better. I consider that question to be mostly irrelevant > to this issue, which is about compatibility for people who

Re: [Python-Dev] thinking about 2.7 / buildbots / testing

> 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/listinfo/p

Re: [Python-Dev] thinking about 2.7

>> 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. Regards, Martin ___

Re: [Python-Dev] thinking about 2.7

>> When I (or somebody else) contacts all the slave operators and asks them >> to restart the buildbot slaves. > > Does this mean you're taking responsibility for this task? Or are you > looking for a volunteer? I had been running this buildbot installation ever since I created it, and will happ

Re: [Python-Dev] thinking about 2.7

> I don't know if it's possible but it would be great if the buildbot > master could send an email to a buildbot maintainer if it thinks a > buildbot is down. I think it should be possible to detect that. I wouldn't recommend immediate reaction, but rather a delayed reaction (say, 12h). Buildbot i

Re: [Python-Dev] PEP 3144 review.

> - Masks are also 32- (128-) bit integers, which happen to have the >property that their leftmost N bits are all zero and the rest are all >one. As a side note, I would be in favor of dropping the concept of a mask from the library, and only support a prefix length. IPv6 doesn't support

Re: [Python-Dev] PEP 3144 review.

> I don't think the RFCs forbid the zero address being used RFC 1122 does: "IP addresses are not permitted to have the value 0 or -1 for any of the , , or fields (except in the special cases listed above)." RFC 3021 modifies this requirement, allowing the zero address to be used for an 31-bit p

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

>>> I think using .network and .broadcast are pretty well understood to be the >>> [0] and [-1] of the network address block. I don't think we want to start >>> creating new terms or access patterns here. >>> >>> +1 on leaving .network and .broadcast as-is (including returning a >>> IPvXAddress obj

Re: [Python-Dev] PEP 3144 review.

>> As a side note, I would be in favor of dropping the concept of a mask >> from the library, and only support a prefix length. > > -1 > >> IPv6 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

Re: [Python-Dev] Misc/maintainers.rst

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'

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

Guido van Rossum wrote: > I realize I'm late to this party, but this is just a naming issue, right? Not really (AFAIU). > For any network, there are two special addresses, one with the last > bits all zeros, one with the last bits all ones. We can call them A > and B, or network and broadcast, or

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

>> For the broadcast address, it's different, since you might also use >> it in programming (i.e. when sending broadcasts). > > So there is no need to look up the broadcast address in the > configuration? Don't you have to look up the rest of the network > configuration too? (Or otherwise how do y

Re: [Python-Dev] PEP 3144 review.

>> Finally, to Stephen's point about seeing the other side of the >> argument, I wrote this offlist a week ago: >> >> I *understand* what you're saying, I *understand* that >> 192.168.1.1/24 isn't a network, > > But you still want to treat it as one. > > Could you explain what benefit there is

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

> If you think getopt and optparse should stick around in 3.X, why is > that? If you think there are things that getopt and optparse do better > than argparse, could you please give some examples? I personally consider getopt superior to both optparse and argparse. Those are terribly verbose in sp

Re: [Python-Dev] PEP 3144 review.

> The fundamental divide here is between two behaviors. > > ipaddr: > > >>> x = IPv4Network('192.168.1.1/24') > >>> y = IPv4Network('192.168.1.0/24') > >>> x == y > False > >>> x.ip > IPv4Address('192.168.1.1') > > desired: > > >>> x = IPv4Network('192.168.1.1/24') >

Re: [Python-Dev] PEP 3144 review.

>> It's fairly obvious to me why the library should support 192.168.1.1/24 >> as an input, and return a network. >> >> End-users are likely going to enter such things (e.g. 82.94.164.162/29), >> as they will know one IP address in the network (namely, of one machine >> that they are looking at), an

Re: [Python-Dev] PEP 3144 review.

> 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

Re: [Python-Dev] PEP 3144 review.

> 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_ Just as he says. Martin

Re: [Python-Dev] PEP 3144 review.

> I would say that there certainly are precedents in other areas for > keeping the information about the input form around. For example, > occasionally it would be handy if parsing a hex integer returned an > object that was compatible with other integers but somehow kept a hint > that would cause

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

James Y Knight wrote: > On Sep 28, 2009, at 4:25 AM, M.-A. Lemburg wrote: >> Distributions should really not be put in charge of upstream >> coding design decisions. > > I don't think you can blame distros for this one > > From PEP 0261: > It is also proposed that one day --enable-unicode

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

> Let's take ``getopt.getopt(sys.argv[1:], "a:b", ["alpha=", "beta"])`` > as an example and simply assume that 'alpha' takes a string as an > argument and that it's required and that 'beta' is a boolean flag. To > pull everything out you could do:: > > options, args = getopt.getopt(sys.argv[1:],

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

>> I've also encountered this trap multiple times. Obviously, the problem >> is not rebuilding Python which is quick, but to figure out the correct >> configure option to use (--enable-unicode=ucs4). Others have also >> spent some time scratching their heads over the strange >> PyUnicodeUCS4_FromUn

Re: [Python-Dev] transitioning from % to {} formatting

Steven Bethard wrote: > There's a lot of code already out there (in the standard library and > other places) that uses %-style formatting, when in Python 3.0 we > should be encouraging {}-style formatting. I don't agree that we should do that. I see nothing wrong with using % substitution. > We

Re: [Python-Dev] transitioning from % to {} formatting

>>> There's a lot of code already out there (in the standard library and >>> other places) that uses %-style formatting, when in Python 3.0 we >>> should be encouraging {}-style formatting. >> >> I don't agree that we should do that. I see nothing wrong with using >> % substitution. > > It's a ma

Re: [Python-Dev] transitioning from % to {} formatting

> Although I hate the name 'dicttemplate', this seems like the best > solution to me. Maybe it's good that 'dicttemplate' is so ugly though > so that people will naturally prefer 'format' :). But I like this > because there's not really any magic, it's explicit, and the decision is > made by the

Re: [Python-Dev] Python logging and 1.5.2 compatibility

> 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-Dev@python.org http://mail.p

Re: [Python-Dev] PEP 3144 review.

> I don't know -- this is (from what Peter told me) a common use case so > he (and presumably others) would from time to time have to write > extra code to keep track of that IP address in a new app. I, and probably others, would really, REALLY like to see one such "common use case". I do find it

Re: [Python-Dev] transitioning from % to {} formatting

> I agree with this 100% but I can't see it working unless we have some > sort of transition plan. Just saying "ok, switch your format strings > from % to {}" didn't work in Python 3.0 for various good reasons, and > I can't imagine it will work in Python 4.0 unless we have a transition > plan. Th

Re: [Python-Dev] Package install failures in 2.6.3

>> My question was less about the political aspects than the technical aspects. >> I gather you're saying that the fix to setuptools will make it work in >> 2.6.3 without inadvertently breaking it for 2.6.2, 2.6.1, and 2.6.0, right? >> Have you tried the fix in those older versions to be sure? >>

Re: [Python-Dev] eggs now mandatory for pypi?

>> * Moderation > [...] >> * Flagging as spam > > * Captcha ? In the specific case, neither would have helped. a) the user making the comment that the package author felt to be impolite was a real user, with an established, well-known identity, and long-time member of the community (IIUC). That

Re: [Python-Dev] Logging, Unicode and sockets

> I've noticed that the socket-based logging handlers - SocketHandler, > DatagramHandler and SysLogHandler - aren't Unicode-aware and can break in the > presence of Unicode messages. I can't understand what the problem with SocketHandler/DatagramHandler is. As they use pickle, they should surely b

Re: [Python-Dev] eggs now mandatory for pypi?

> 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 ___ Python-Dev m

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

> Given that this is all about establishing some common ground between > implementations I would propose not using a CPython specific term > here such as PyStructSequence :) The Python docs seem to use structseq > for sys.float_info. Also, why does it have to be a sequence in the first place? Wou

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

> sys.implementation is a PyStructSequence that contains various > information about the current implementation. Some fields are required > to be present on every implementation. I think it is important to confirm in advance that all the implementations listed below agree to implement the PEP "soo

Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?

> It would be nice to get this issue resolved out for 2.6.4: > > http://bugs.python.org/issue4120 > > The problem is that extensions built with 2.6.x will not work > when used with a User-only installation of Python on machines that > don't already have the MS VC90 CRT DLLs installed system-wide

Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?

>> As this bug already exists in 2.6.2, I don't think the change is >> eligible for 2.6.4. >> >> In addition, I want to review it, which I won't be able to until >> Sunday. > > Then I'd suggest to wait another week with 2.6.4 to give you a > chance to look at the patch. That won't make the chang

Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?

> I always thought that the idea of a release candidate was that if there > were any fixes _at all_ that there would be a new rc. Only when no > bugs needing fixed are found does the rc turn into the actual release. This was also my understanding; that's the point of calling it "candidate". Sinc

Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?

> So, we can either make Sunday's release rc2 and do the final release one > week later, or I can try to get an rc2 out in the next day or two, with > a final release mid-next week. > > Thoughts? I won't be able to produce Windows binaries until Saturday. Now sure how that would fit into the "wit

Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?

> 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.python.org/mailma

Re: [Python-Dev] Add const to python API - issue 6952

> 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 Python-Dev@py

Re: [Python-Dev] Add const to python API - issue 6952

> 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 Unsubscribe: http://mail.pytho

Re: [Python-Dev] nonlocal keyword in 2.x?

Mike Krell wrote: > Is there any possibility of backporting support for the nonlocal keyword > into a 2.x release? If so, only into 2.7. Can you please explain why it would be desirable to do that? 2.7 will likely be the last 2.x release, so only a fairly small portion of the applications would

Re: [Python-Dev] nonlocal keyword in 2.x?

exar...@twistedmatrix.com wrote: > On 08:24 pm, mar...@v.loewis.de wrote: >> Mike Krell wrote: >>> Is there any possibility of backporting support for the nonlocal keyword >>> into a 2.x release? >> >> If so, only into 2.7. Can you please explain why it would be desirable >> to do that? 2.7 will l

Re: [Python-Dev] nonlocal keyword in 2.x?

> From the Django roadmap for supporting 3.0, using 2.6 as a stepping > stone (and if 2.7 was a *better* stepping stone then it would make it > easier): > >http://groups.google.com/group/django-developers/msg/0888b1c8f2518059? Is that still a current plan? It's from November 2008. > This get

Re: [Python-Dev] nonlocal keyword in 2.x?

> Others have explained the rationale for the backport, so I won't bother > repeating those arguments. > > I understand your point about code supporting 2.6, but as you say, that > applies to any new features being added in 2.7. I'm therefore confused > as to what the rationale for a 2.7 release

Re: [Python-Dev] First shot at some_set.get()

> I'm not being tongue-in-cheek or sarcastic. My question was serious -- > if there is a moratorium, is there any reason to bother submitting > patches for functional changes to built-ins? A lot can change between > now and 2013, and I for one wouldn't bother making a patch that I knew > wouldn

Re: [Python-Dev] Clean up Python/thread_*.h ?

> Making a decision and removing the files considered unnecessary would clarify > what platforms still are/should be supported. I think any such removal should go through the PEP 11 process. Put a #error into the files for 3.2, and a removal notice into the PEP, then remove them in 3.3. As for OS

Re: [Python-Dev] Possible language summit topic: buildbots

Mark Dickinson wrote: > Would it be worth spending some time discussing the buildbot situation > at the PyCon 2010 language summit? In the past, I've found the > buildbots to be an incredibly valuable resource; especially when > working with aspects of Python or C that tend to vary significantly

Re: [Python-Dev] Possible language summit topic: buildbots

> I've been trying to get some feedback about firing up buildbots on Cloud > Servers for a while now and haven't had much luck. I'd love to find a > way of having buildbots come to life, report to the mother ship, do the > build, then go away 'till next time they're required. I'm not quite sure w

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

> Given Alexander's premise, I agree with your response. But his premise > is wrong. Python's current builtin set class maps abstract equivalence > classes to representative members. And this *is* useful. Mapping > arbitrary members of such classes to representative members, sometimes > called 'can

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

> If you actually care about that aspect of the semantics for a particular > application, it would be far clearer to use a full dict() and live with > the additional memory usage. While I can see how saving that > pointer-per-entry might make sense in some circumstances, for most I > would see it a

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

> Hmm, perhaps when using sets as work queues? A number of comments: - it's somewhat confusing to use a set as a *queue*, given that it won't provide FIFO semantics. - there are more appropriate and direct container structures available, including a dedicated Queue module (even though this

Re: [Python-Dev] Possible language summit topic: buildbots

Antoine Pitrou wrote: >> For a), I think we can solve this only by redundancy, i.e. create more >> build slaves, hoping that a sufficient number would be up at any point >> in time. > > We are already doing this, aren't we? > http://www.python.org/dev/buildbot/3.x/ > > It doesn't seem to work ver

Re: [Python-Dev] Possible language summit topic: buildbots

> As I have no specific experience maintaining any of the CPython build > slaves, I can't speak to any maintenance issues which these slaves have > encountered. I would expect that they are as minimal as the issues I > have encountered maintaining slaves for other projects, but perhaps this > is w

Re: [Python-Dev] Possible language summit topic: buildbots

> OK, sounds useful. If I'm offline for a while, do multiple builds get > queued, or only the "last" one? IIRC, it will only build the last one, then with a huge blame list. > If the former, I can imagine coming > back to a pretty huge load if the slave breaks while I'm on holiday > :-( If it's

Re: [Python-Dev] Possible language summit topic: buildbots

> I think that money can help in two ways in this case. > > First, there are now a multitude of cloud hosting providers which will > operate a slave machine for you. BuildBot has even begun to support > this deployment use-case by allowing you to start up and shut down vms > on demand to save on

<    2   3   4   5   6   7   8   9   10   11   >