Re: [Python-Dev] Additional behaviour for itertools.combinations
Raymond Hettinger wrote:
Since I expect students to be among the users for the comb/perm
functions, there is some merit to keeping the API as simple as possible.
Besides, it is not hard to use the existing tool as a primitive to get to
the one you want:
def mycombinations(iterable, r_seq):
# mycombinations('abc', [1,2]) --> A B C AB AC BC
iterable = list(iterable)
return chain.from_iterable(imap(combinations, repeat(iterable),
r_seq))
[Nick Coglan]
Perhaps a reasonable starting point would be to include this as one of
the example itertools recipes in the documentation?
I would have suggested that but recipe itself is use case challenged.
The OP did not mention any compelling use cases or motivations.
Essentially, he just pointed-out that it is possible, not that it is desirable.
I can't the of a case where I've wanted to loop over variable length
subsequences. Having for-loops with tuple unpacking won't work
because the combos have more than one possible size.
This seems like a hypergeneralization to me.
Raymond
___
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
Re: [Python-Dev] Operator module deprecations
Brett Cannon wrote:
> On Sat, Jan 24, 2009 at 14:46, Raymond Hettinger wrote:
>> I would like to deprecate some outdated functions in the operator module.
>>
>> The isSequenceType(), isMappingType(), and isNumberType()
>> functions never worked reliably and now their
>> intended purpose has been largely fulfilled by
>> ABCs.
>>
>> The isCallable() function has long been deprecated
>> and I think it's finally time to rip it out.
>>
>> The repeat() function never really corresponded to an
>> operator. Instead, it reflected an underlying implementation detail (namely
>> the naming of the sq_repeat slot and the abstract C API function
>> PySequence_Repeat). That functionality is already exposed by operator.mul:
>>
>> operator.mul('abc', 3) --> 'abcabcabc'
>
> +1 to all of it.
What Brett said.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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
Re: [Python-Dev] Additional behaviour for itertools.combinations
Raymond Hettinger wrote:
> Since I expect students to be among the users for the comb/perm
> functions, there is some merit to keeping the API as simple as possible.
> Besides, it is not hard to use the existing tool as a primitive to get to
> the one you want:
>
> def mycombinations(iterable, r_seq):
> # mycombinations('abc', [1,2]) --> A B C AB AC BC
> iterable = list(iterable)
> return chain.from_iterable(imap(combinations, repeat(iterable),
> r_seq))
Perhaps a reasonable starting point would be to include this as one of
the example itertools recipes in the documentation?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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
Re: [Python-Dev] Operator module deprecations
On Sat, Jan 24, 2009 at 14:46, Raymond Hettinger wrote:
> I would like to deprecate some outdated functions in the operator module.
>
> The isSequenceType(), isMappingType(), and isNumberType()
> functions never worked reliably and now their
> intended purpose has been largely fulfilled by
> ABCs.
>
> The isCallable() function has long been deprecated
> and I think it's finally time to rip it out.
>
> The repeat() function never really corresponded to an
> operator. Instead, it reflected an underlying implementation detail (namely
> the naming of the sq_repeat slot and the abstract C API function
> PySequence_Repeat). That functionality is already exposed by operator.mul:
>
> operator.mul('abc', 3) --> 'abcabcabc'
+1 to all of it.
___
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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
On Sat, Jan 24, 2009 at 16:44, Nick Coghlan wrote: > Brett Cannon wrote: >> On Sat, Jan 24, 2009 at 15:34, "Martin v. Löwis" wrote: > Second, I think it would be good to explicitly mention the option of > deferring this PEP. Based on previous discussion, it sounds like there > are a fair number of people who think that there is a DVCS in Python's > future, but not now (where "now" means over the next couple of years). Sure, I can add a note somewhere that says if a clear winner doesn't come about the PEP can be revisited to a later date. >>> I think the request is slightly different: consider that a potential >>> outcome should be "svn for the next five years, then reconsider" - not >>> because none of the DVCS is a clear winner, but because there is too >>> much resistance to DVCSes in general, at the moment. >> >> I already put a note in that no DVCS might be chosen once the PEP is >> finished. Whether it is because no DVCS is a clear improvement over >> svn or people just don't like a DVCS seems like a minor thing to worry >> about to spell out in the PEP. > > I suspect the reactions will be more nuanced than that anyway - e.g. my > current position is that while I like the idea of a DVCS in principle > and agree there are definite gains to be had in switching to one, I > don't think the contenders have had enough time to shake out their > competing feature sets and relative performance. We don't seem to lose a > lot by sticking with SVN at least until after 2.7/3.1 are out the door > and then revisiting the DVCS question (this is particularly so given > that the current plan is go for a fairly short turnaround on those two > releases). > As part of my impressions I plan to also look at usage on top of svn as a viable alternative if no clear winner comes about. That way if they work well directly on top of svn we can write up very clear documentation on how to use any of them directly on top of svn and still gain the benefits of offline checkins and cheap branching. Maintenance then becomes simply keeping a read-only mirror going on code.python.org. > As the zen says, now is better than never, but never is often better > than *right* now :) Don't worry, I am not going to push something down anyone's throats if I don't feel secure that it is the best choice. ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
Brett Cannon wrote: > On Sat, Jan 24, 2009 at 15:34, "Martin v. Löwis" wrote: Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where "now" means over the next couple of years). >>> Sure, I can add a note somewhere that says if a clear winner doesn't >>> come about the PEP can be revisited to a later date. >>> >> I think the request is slightly different: consider that a potential >> outcome should be "svn for the next five years, then reconsider" - not >> because none of the DVCS is a clear winner, but because there is too >> much resistance to DVCSes in general, at the moment. > > I already put a note in that no DVCS might be chosen once the PEP is > finished. Whether it is because no DVCS is a clear improvement over > svn or people just don't like a DVCS seems like a minor thing to worry > about to spell out in the PEP. I suspect the reactions will be more nuanced than that anyway - e.g. my current position is that while I like the idea of a DVCS in principle and agree there are definite gains to be had in switching to one, I don't think the contenders have had enough time to shake out their competing feature sets and relative performance. We don't seem to lose a lot by sticking with SVN at least until after 2.7/3.1 are out the door and then revisiting the DVCS question (this is particularly so given that the current plan is go for a fairly short turnaround on those two releases). As the zen says, now is better than never, but never is often better than *right* now :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
On Sat, Jan 24, 2009 at 15:34, "Martin v. Löwis" wrote: >>> Second, I think it would be good to explicitly mention the option of >>> deferring this PEP. Based on previous discussion, it sounds like there >>> are a fair number of people who think that there is a DVCS in Python's >>> future, but not now (where "now" means over the next couple of years). >> >> Sure, I can add a note somewhere that says if a clear winner doesn't >> come about the PEP can be revisited to a later date. >> > > I think the request is slightly different: consider that a potential > outcome should be "svn for the next five years, then reconsider" - not > because none of the DVCS is a clear winner, but because there is too > much resistance to DVCSes in general, at the moment. I already put a note in that no DVCS might be chosen once the PEP is finished. Whether it is because no DVCS is a clear improvement over svn or people just don't like a DVCS seems like a minor thing to worry about to spell out in the PEP. -Brett ___ 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
Re: [Python-Dev] Change Makefile.pre.in based on configure?
>> How do I work around this difference in Makefile.pre.in? Martin> To answer this question, I would have to see the exact fragment Martin> that you want to see in the Solaris case, and the exact fragment Martin> that you want to have in the OSX case. Can you provide these? I'll work on it and get back to you if I get completely stuck. I think I've figured a way out of my current dilemma, but a little experimentation will be required to see if I'm correct. Thx, Skip ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
>> Second, I think it would be good to explicitly mention the option of >> deferring this PEP. Based on previous discussion, it sounds like there >> are a fair number of people who think that there is a DVCS in Python's >> future, but not now (where "now" means over the next couple of years). > > Sure, I can add a note somewhere that says if a clear winner doesn't > come about the PEP can be revisited to a later date. > I think the request is slightly different: consider that a potential outcome should be "svn for the next five years, then reconsider" - not because none of the DVCS is a clear winner, but because there is too much resistance to DVCSes in general, at the moment. 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
Re: [Python-Dev] Change Makefile.pre.in based on configure?
> How do I work around this difference in Makefile.pre.in? To answer this question, I would have to see the exact fragment that you want to see in the Solaris case, and the exact fragment that you want to have in the OSX case. Can you provide these? 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
Re: [Python-Dev] ac_sys_system == Monterey*?
http://bugs.python.org/issue4111 Jeez, I'm an idiot. Should be http://bugs.python.org/issue5047 Skip ___ 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
Re: [Python-Dev] ac_sys_system == Monterey*?
Martin> Monterey was cancelled in 2000, although parts of it were Martin> integrated into AIX 5L. Thanks... http://bugs.python.org/issue4111 It doesn't appear it's mentioned anywhere other than in the configure script. Skip ___ 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
[Python-Dev] Operator module deprecations
I would like to deprecate some outdated functions in the operator module.
The isSequenceType(), isMappingType(), and isNumberType()
functions never worked reliably and now their
intended purpose has been largely fulfilled by
ABCs.
The isCallable() function has long been deprecated
and I think it's finally time to rip it out.
The repeat() function never really corresponded to an
operator. Instead, it reflected an underlying
implementation detail (namely the naming of the
sq_repeat slot and the abstract C API function
PySequence_Repeat). That functionality is already
exposed by operator.mul:
operator.mul('abc', 3) --> 'abcabcabc'
Raymond
___
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
[Python-Dev] mingw+msys port of python2.7a0 (svn #r68884)
http://bugs.python.org/issue5046 mingw+msys port which was previously done against python-2.5.2 has been brought forward to latest subversion r68884. the primary reason for initially doing python 2.5.2 was to 1) "stay out of the way" of primary python development 2) provide some hope for those people still using win98 and nt. builds using msvcr90 are possible with the --enable-msvcr9build switch. install mingw, install msys, optionally install a boat-load of libraries such as sqlite3, zlib, bz2, dbm etc. (good luck, it's a pain - ask me if you'd like some prebuilt). make sure you patch the mingw runtime if you want to use --enable-msvcr9build (again, ask me if you'd like the patched headers and prebuilt libmsvcrNN.a files). also added is the msi module - http:/ /lkcl.net/msi.tgz and run make in the msi directory, to install the import libraries and header files borrowed from Wine and beaten into submission. run ./configure --enable-win32build=yes --enable-shared=yes and go do something else for about 10 minutes, then run make and make install. no proprietary compilers or tools were used or harmed [*] in the making or development of this patch. l. [*] such a shame... ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
On Sat, Jan 24, 2009 at 07:25, Aahz wrote: > On Thu, Jan 22, 2009, Brett Cannon wrote: >> >> I have now converted PEP 374 >> (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST >> and checked it in. > > First of all, thanks for providing PEP number, URL, and short title; > that makes it much easier to keep track of the discussion on list. > =) Welcome. > Second, I think it would be good to explicitly mention the option of > deferring this PEP. Based on previous discussion, it sounds like there > are a fair number of people who think that there is a DVCS in Python's > future, but not now (where "now" means over the next couple of years). Sure, I can add a note somewhere that says if a clear winner doesn't come about the PEP can be revisited to a later date. -Brett ___ 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
Re: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
>> but basically, not only is this technique nothing new - it's in use in >> Apache RunTime, FreeDCE, the NT Kernel, the Linux Kernel - but also > This look like simple RPC implemantation. yep. > If I remember well SUN-RPC assign number to program, function, version. yep - i forgot about that one: yes, that's another example. this is pretty basic well-understood, well-documented techniques that virtually every large project that requires isolation between components (and an upgrade path) ends up using in one form or another. the only fly in the ointment will be that putting pointers to PyType_String etc. etc. into a vector table (struct), you end up with an extra de-ref overhead, which is often an argument utilised to do away with vector tables. but - tough: the decision involves getting away from "Hell" to something that makes everyone's lives that much easier, it's an easy decision to make. >> surely, that should be the _only_ dll which gets _specifically_ linked >> against msvcr71.dll (or 90, or... whatever) and it would be even >> _better_ if that then got _named_ msvcr71.pyd, msvcr90.pyd etc. > > [SNIP] > Yes it is enough to encapsulate memory allocation and file functions into > python shared library. The python provide memory allocation functions, but > not all modules use them. File functions are hiden by posixmodule and python > modules can't use them. except ... posixmodule gets renamed to ntmodule oh, i see what you mean: python modules aren't allowed _direct_ access to msvcrtNN's file functions, they have to go via posixmodule-renamed-to-ntmodule. so it's still ok. l. ___ 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
[Python-Dev] Change Makefile.pre.in based on configure?
I'm working on issue 4111 which will add dtrace support to Python when requested by the builder and when supported by the platform (currently just Solaris and Mac OSX I believe). Sun and Apple have quite different ways to generate the code necessary to link into the executable. Sun's dtrace command supports a -G flag which generates a .o file from a .d file. Apple instead generates an include file using the -h flag to dtrace (-G and .o file generation are not supported). This puts a bit of a crimp in generating Makefile dependencies. In the Sun case you have a couple extra .o files to link into libpython. In the Apple case you have a couple extra .h files which define Dtrace macros. How do I work around this difference in Makefile.pre.in? I can detect Sun vs. Apple in the configure script, but I see no conditional logic in Makefile.pre.in to use as an example. It seems to only use variable expansion on the RHS of stuff. Can I do something like if @WITH_DTRACE_SUN@ = 1 then ... Sun-style dependencies here ... else ... Apple-style dependencies here ... fi where WITH_DTRACE_SUN is a macro defined in pyconfig.h by the configure script? Thanks, Skip ___ 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
Re: [Python-Dev] ac_sys_system == Monterey*?
> What is Monterey? Monterey was the code name of a joint operating system project of SCO and IBM, porting AIX to 64-bit processors (apparently, IA-64 and POWER). See http://www.cs.umbc.edu/help/architecture/idfmontereylab.pdf http://en.wikipedia.org/wiki/Project_Monterey Monterey was cancelled in 2000, although parts of it were integrated into AIX 5L. 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
Re: [Python-Dev] ac_sys_system == Monterey*?
s...@pobox.com wrote: From configure.in: # The current (beta) Monterey compiler dies with optimizations # XXX what is Monterey? Does it still die w/ -O? Can we get rid of this? case $ac_sys_system in Monterey*) OPT="" ;; esac What is Monterey? Can this check be removed from trunk/py3k branches? This post http://mail.python.org/pipermail/patches/2000-August/001708.html would have you believe it's a 64-bit AIX compiler. ___ 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
[Python-Dev] ac_sys_system == Monterey*?
>From configure.in: # The current (beta) Monterey compiler dies with optimizations # XXX what is Monterey? Does it still die w/ -O? Can we get rid of this? case $ac_sys_system in Monterey*) OPT="" ;; esac What is Monterey? Can this check be removed from trunk/py3k branches? Skip ___ 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
Re: [Python-Dev] Additional behaviour for itertools.combinations
From: "Konrad Delong"
I'm not sure if it's the right place to post it. If so - I'll be glad
to learn where is one.
Please post a feature request on the bug tracker and assign it to me.
Anyway:
I think the function itertools.combinations would benefit from making
the 'r' (length of the combinations) argument optionally a sequence.
With that change one could call combinations(sequence, [2, 3]) in
order to get all combinations of length 2 and 3.
In particular, one could call combinations(sequence,
range(len(sequence)) in order to get *all* combinations of given
sequence.
This design is similar to the API for similar functionality in mathematica.
The question is whether there are sufficient worthwhile use cases
to warrant the added API complexity and algorithm complexity.
The latter is a bit tricky if we want to maintain the lexicographic
ordering and the notion of combinations being a subsequence of
the permutations code.
Since I expect students to be among the users for the comb/perm
functions, there is some merit to keeping the API as simple as possible.
Besides, it is not hard to use the existing tool as a primitive to get to
the one you want:
def mycombinations(iterable, r_seq):
# mycombinations('abc', [1,2]) --> A B C AB AC BC
iterable = list(iterable)
return chain.from_iterable(imap(combinations, repeat(iterable), r_seq))
PS. Didn't want to spoil the beginning of the post, but I consider it
to be a good practice to introduce oneself when posting the first
time, so: Hello, my name is Konrad, I'm an IT student and I'm
following python-dev for some time, but never posted before.
Hello Konrad. Welcome to python-dev.
Raymond Hettinger
___
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
[Python-Dev] Additional behaviour for itertools.combinations
I'm not sure if it's the right place to post it. If so - I'll be glad to learn where is one. Anyway: I think the function itertools.combinations would benefit from making the 'r' (length of the combinations) argument optionally a sequence. With that change one could call combinations(sequence, [2, 3]) in order to get all combinations of length 2 and 3. In particular, one could call combinations(sequence, range(len(sequence)) in order to get *all* combinations of given sequence. The change would be backwards compatible as it would check for sequential arguments. Is it worth the shot? best regards Konrad PS. Didn't want to spoil the beginning of the post, but I consider it to be a good practice to introduce oneself when posting the first time, so: Hello, my name is Konrad, I'm an IT student and I'm following python-dev for some time, but never posted before. ___ 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
Re: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
Luke Kenneth Casson Leighton wrote: On Fri, Jan 23, 2009 at 10:48 PM, Roumen Petrov [SNIP] but it would certainly mean that there would be both a future-proof path for binary modules from either msvc-compiled _or_ mingw-compiled 2.5, 2.6, 2.7 etc. to work with 2.5, 2.6, 2.7, 2.8 etc. _without_ a recompile. [forwards-future-proof-compatibility _is_ possible, but... it's a bit more... complicated. backwards-compatibility is easy]. what you do is you make sure that the vector-table is always and only "extended" - added to - never "removed from" or altered. if one function turns out to be a screw-up (inadequate, not enough parameters), you do NOT change its function parameters, you add an "Ex" version - or an "Ex1" version. [SNIP] but basically, not only is this technique nothing new - it's in use in Apache RunTime, FreeDCE, the NT Kernel, the Linux Kernel - but also it's actually _already_ in use in one form in the way that python objects are typecast from PyObject to other types of structs! the difference is that a bit-field would make detection of revisions a bit easier but to be honest you could just as easily make it an int and increase the revision number. This look like simple RCP implemantation. If I remember well SUN-RPC assign number to program, function, version. [SNIP] surely, that should be the _only_ dll which gets _specifically_ linked against msvcr71.dll (or 90, or... whatever) and it would be even _better_ if that then got _named_ msvcr71.pyd, msvcr90.pyd etc. [SNIP] Yes it is enough to encapsulate memory allocation and file functions into python shared library. The python provide memory allocation functions, but not all modules use them. File functions are hiden by posixmodule and python modules can't use them. Roumen ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
Aahz wrote: > On Thu, Jan 22, 2009, Brett Cannon wrote: >> I have now converted PEP 374 >> (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST >> and checked it in. > > First of all, thanks for providing PEP number, URL, and short title; > that makes it much easier to keep track of the discussion on list. > > Second, I think it would be good to explicitly mention the option of > deferring this PEP. Based on previous discussion, it sounds like there > are a fair number of people who think that there is a DVCS in Python's > future, but not now (where "now" means over the next couple of years). Put me in that category - the switch from CVS to SVN was simple and obvious because SVN set out to be a better CVS and achieved that goal admirably. The only major hurdle to adopting it was getting the history across, and Martin was able to handle that in the end. The benefits of atomic commits alone were well worth the migration cost. With the level of development still going on in the DVCS area, I think this is a time when dragging our feet on making a decision may actually work to our advantage. Although if Brett genuinely wants to narrow it down to a two-horse race at PyCon, then I think the one thing to keep in mind is how well the chosen tool embodies the Zen of Python (especially "Readability counts" and "One obvious way to do it"). Core devs *are* core devs at least in part because we largely like and agree with those design philosophies. I personally find the command lines for 2 of the presented options quite pleasant to read, while the examples of using the 3rd make me shudder the way I do when I'm forced to read or write a Perl script.* Performance problems can be fixed, but an antithetical design philosophy is unlikely to make for a good tool fit. Cheers, Nick. * In other words, the examples of using git in the PEP make me want to run screaming in the opposite direction. However, assuming bzr's performance issues and line feed handling limitations are addressed by the time the switch actually happens, I'm currently fairly neutral on the choice between bzr and hg. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] subprocess crossplatformness and async communication
Anatoly, I'm confused. The subprocess already allows reading/writing its stdin/stdout/stderr, and AFAIK it's a platform-neutral API. I'm sure there's something missing, but your post doesn't make it clear what exactly, and the recipe you reference is too large to digest easily. Can you explain what it is that the current subprocess does't have beyond saying "async communication" (which could mean many things to many people)? --Guido On Sat, Jan 24, 2009 at 5:07 AM, anatoly techtonik wrote: > Greetings, > > This turned out to be a rather long post that in short can be summarized as: > "please-please-please, include asynchronous process communication in > subprocess module and do not allow "available only on ..." > functionality", because it hurts the brain". > > Code to speak for itself: http://code.activestate.com/recipes/440554/ > > > The subprocess module was a great step forward to unify various spawn > and system and exec and etc. calls in one module, and more importantly > - in one uniform API. But this API is partly crossplatform, and I > believe I've seen recent commits to docs with more unix-only > differences in this module. > > The main point of this module is to "allows you to spawn new > processes, connect to their input/output/error pipes, and obtain their > return codes". PEP 324 goal is also to make "make Python an even > better replacement language for over-complicated shell scripts". > > Citing pre-subrocess PEP 324, "Currently, Python has a large number of > different functions for process creation. This makes it hard for > developers to choose." Now there is one class with many methods and > many platform-specific comments and notices. To make thing worse > people on Unix use subprocess with fcntl and people on windows tend > not to use it at all, because it looks complicated and doesn't solve > the problem with asynchronous communication. > > That I suggest is to add either support for async crossplatfrom > read/write/probing of executed process or a comment at the top of > module documentation that will warn that subprocess works in blocking > mode. With async mode you can emulate blocking, the opposite is not > possible. This will save python users a lot of time. > > Thanks for reading my rant. > > > BTW, the proposed change is top 10 python recipe on ActiveState > http://code.activestate.com/recipes/langs/python/ > > -- > --anatoly t. > ___ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
On Thu, Jan 22, 2009, Brett Cannon wrote: > > I have now converted PEP 374 > (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST > and checked it in. First of all, thanks for providing PEP number, URL, and short title; that makes it much easier to keep track of the discussion on list. Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where "now" means over the next couple of years). -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ 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
Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?
On Fri, Jan 23, 2009 at 11:18:37PM +0100, "Martin v. L?wis" wrote:
> > I don't see how starting with an empty directory helps. The filename
> > comes from the client, and the FTP server can't know what the actual
> > encoding of that filename is.
>
> Sure it can. If the client supports RFC 2640, it will send file names
> in UTF-8. If the client does not support RFC 2640, the client must
> restrict itself to 7-bit file names (i.e. ASCII). If the client violates
> the protocol, the server must respond with error 501.
Perhaps, that is true, but that is in the world of standards. In my life I
remember the situation when users uploaded files from Windows with names in
CP866
encoding to UNIX-based ftp server, which by itself had KOI8-R as the encoding
for LC_CTYPE. Since administrator was unhappy being impossible to read the
names of files correctly, he found and installed specialized ("russified")
version of ftp daemon, which had configuration settings, that said what is the
network encoding and what is the filesystem encoding.
So both ftp daemon and ftp clients violated RFC, but users and administrator
were happy.
I think, we should preserve the ability of ftp client to download all files he
see in the listing from the server.
What to do with user specified filenames when they cannot be encoded into ascii
and server does not support UTF8, but violates RFC and allows 8-bit bytes in the
file names?
The ideal ftp client will ask the user about the encoding he thiks filenames
are
stored on the server side and then recode from user's encoding. It also allow
the
user to try several variants, if first don't work. It will allow user to
download
files with names in several different encodings from the same server using
single
ftp session.
Dumb client will send filename from user as bytes,
and will succeed, if user was able to specify filename verbatim.
Anything between that will make the idea of using Unicode as character encoding
for filenames absurd, since it will only break the i18n capabilities of the
library.
If python library will have file name encoding hardwired to latin1, but
arguments will
only be unicode strings, well, a lot of people will not even notice that, since
they
use only ascii part of utf-8. But then there will be again numerous
"russification"-like
patches to python and to modules, which are incompatible with everything, but
work well
in some very specific situations. This is the evil that was supposed to be
defeated
with i18n and with the total adoption of Unicode.
Alexey G.
___
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
[Python-Dev] subprocess crossplatformness and async communication
Greetings, This turned out to be a rather long post that in short can be summarized as: "please-please-please, include asynchronous process communication in subprocess module and do not allow "available only on ..." functionality", because it hurts the brain". Code to speak for itself: http://code.activestate.com/recipes/440554/ The subprocess module was a great step forward to unify various spawn and system and exec and etc. calls in one module, and more importantly - in one uniform API. But this API is partly crossplatform, and I believe I've seen recent commits to docs with more unix-only differences in this module. The main point of this module is to "allows you to spawn new processes, connect to their input/output/error pipes, and obtain their return codes". PEP 324 goal is also to make "make Python an even better replacement language for over-complicated shell scripts". Citing pre-subrocess PEP 324, "Currently, Python has a large number of different functions for process creation. This makes it hard for developers to choose." Now there is one class with many methods and many platform-specific comments and notices. To make thing worse people on Unix use subprocess with fcntl and people on windows tend not to use it at all, because it looks complicated and doesn't solve the problem with asynchronous communication. That I suggest is to add either support for async crossplatfrom read/write/probing of executed process or a comment at the top of module documentation that will warn that subprocess works in blocking mode. With async mode you can emulate blocking, the opposite is not possible. This will save python users a lot of time. Thanks for reading my rant. BTW, the proposed change is top 10 python recipe on ActiveState http://code.activestate.com/recipes/langs/python/ -- --anatoly t. ___ 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
Re: [Python-Dev] About SCons Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
On Sat, Jan 24, 2009 at 12:28 AM, Roumen Petrov >> >> I would better use SCons for both unix and windows builds. In case of >> windows for both compilers - mingw and microsoft ones. To port curses >> extension to windows I need to know what gcc options mean, what are >> the rules to write Makefiles and how to repeat these rules as well as >> find options in visual studio interface. Not mentioning various >> platform-specific defines and warning fixes. > > Did you select one of existing curses library for windows ? I've selected PDCurses and successfully compiled the module and run demos manually - you may see the batch and the patch at http://bugs.python.org/issue2889 However, I was asked for VS2008 project file and this is where it all stopped for 8 months already. First I couldn't get the VS2008, then it refused to run on my W2K and now I can't get enough time to learn it (including that I have 50%/40% experience in PHP/Python and only 5%/5% C/Java). -- --anatoly t. ___ 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
[Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
On Fri, Jan 23, 2009 at 10:48 PM, Roumen Petrov wrote: >>> python.exe (say, the official one) loads >>> python25.dll. Then, an import is made of a ming-wine extension, say >>> foo.pyd, which is linked with libpython2.5.dll, which then gets loaded. >>> Voila, you have two interpreters in memory, with different type objects, >>> memory heaps, and so on. >> >> ok, there's a solution for that - the gist of the solution is already >> implemented in things like Apache Runtime and Apache2 (modules), and >> is an extremely common standard technique implemented in OS kernels. >> the "old school" name for it is "vector tables". >> > [SNIP] Did you think that this will escape python MSVC from "Assembly hell" > ? let me think about that write some things down, i might have an answer at the end :) but it would certainly mean that there would be both a future-proof path for binary modules from either msvc-compiled _or_ mingw-compiled 2.5, 2.6, 2.7 etc. to work with 2.5, 2.6, 2.7, 2.8 etc. _without_ a recompile. [forwards-future-proof-compatibility _is_ possible, but... it's a bit more... complicated. backwards-compatibility is easy]. what you do is you make sure that the vector-table is always and only "extended" - added to - never "removed from" or altered. if one function turns out to be a screw-up (inadequate, not enough parameters), you do NOT change its function parameters, you add an "Ex" version - or an "Ex1" version. just like microsoft does. [ now you know _why_ they do that "ridiculous" thing of adding FunctionEx1 FunctionEx2 and if you look at the MSHTML specification i think they go up to _six_ revisions of the same function in one case!] to detect revisions of the vector-table you use a "negotiation" tactic. you add a bit-field at the beginning of the struct, and each bit expresses a "new revision" indicating that the vector table has been extended (and so needs to be typecast to a different struct - exactly the same as is done with PyObject being typecast to different structs). the first _function_ in the vector-table is one which the module must call (in its init()) to pass in the "version number" of the module, to the python runtime. just in case someone needs to know. but for the most part, the initiation - of function call-out - is done _from_ modules, so each and every module will never try to call something beyond what it understands. but basically, not only is this technique nothing new - it's in use in Apache RunTime, FreeDCE, the NT Kernel, the Linux Kernel - but also it's actually _already_ in use in one form in the way that python objects are typecast from PyObject to other types of structs! the difference is that a bit-field would make detection of revisions a bit easier but to be honest you could just as easily make it an int and increase the revision number. ok, i've thought about your question, and i think it might [save us from assembly hell]. what you would likely have to do is compile _individual modules_ with assemblies, should they need them. for example, the msvcrt module would obviously have to be hey, that'd be interesting, how about having different linked versions of the msvcrt module? coool :) in the mingw builds, it's not necessary to link in PC/msvcrtmodule.o into the python dll - so (and this confused the hell out of me for a minute so i had to do find . -name "msvcrt*") you end up with a Modules/msvcrt.pyd. surely, that should be the _only_ dll which gets _specifically_ linked against msvcr71.dll (or 90, or... whatever) and it would be even _better_ if that then got _named_ msvcr71.pyd, msvcr90.pyd etc. i'll do an experiment, later, to confirm that this actually _does_ work - i.e. creating an msvcr80.pyd with "mingw gcc -specs=msvcr80". the neat thing is that if it works, you wouldn't need to _force_ people to link to the python dll or the python exe with msvcr90 or any other version. and the mingw built python.exe or python dll would be interchangeable, as it would be _specific modules_ that required specific versions of the msvc runtime. l. ___ 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
