2008/11/5 Stephen J. Turnbull <[EMAIL PROTECTED]>:
> > I see no excuse to let the fact that it's Python make it acceptable
> > to have an application with otherwise unacceptable performance.
>
> Barry and many others obviously find the performance of non-git VCSes
> acceptable. On the other hand
2008/11/3 Brett Cannon <[EMAIL PROTECTED]>:
> At this point I am looking for any suggestions for fundamental usage
> scenarios that I am missing from the PEP. If you think the few already
> listed are missing some core part of a VCS, please let me know.
My apologies, I can't check if this is alrea
2008/11/5 Barry Warsaw <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Nov 5, 2008, at 6:09 AM, Paul Moore wrote:
>
>> I'll freely admit a (not very) hidden bias here - the slowness of an
>> initial clone (or going through the
2008/11/5 David Ripton <[EMAIL PROTECTED]>:
> All timings very approximate:
>
> Time for average user to check out Python sources with bzr: 10 minutes
>
> Time for average user to check out Python sources with git or hg: 1 minute
>
> Time for average user's trivial patch to be reviewed and committe
2008/11/5 Nick Coghlan <[EMAIL PROTECTED]>:
> Paul Moore wrote:
>> While that would be good, my understanding is that stacked branches in
>> Bazaar only work (for history operations) while you're online. So they
>> make Bazaar work a little like a centralised VCS, I
2008/11/6 Dirkjan Ochtman <[EMAIL PROTECTED]>:
> Brett Cannon python.org> writes:
>> So my first choice for Mercurial fell through. If you would like to
>> represent Mercurial, let me know.
>
> I can represent Mercurial, though it may be (more?) helpful if some of the
> Mercurial-using python-dev
2008/12/4 Barry Warsaw <[EMAIL PROTECTED]>:
>>> * that 3.1 will rearrange the standard library in mostly-known ways, and
>>> * that we expect people to use 3.0 mostly for compatibility testing, not
>>> going into serious production
>>> use until 3.1 or maybe even 3.2.
>> The latter statement wo
2008/12/4 "Martin v. Löwis" <[EMAIL PROTECTED]>:
> Any objections?
The timing is right, go for it.
Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
2008/12/4 Raymond Hettinger <[EMAIL PROTECTED]>:
> Also, we don't know the timing of the third-party updates.
> Some may never get converted. Some may convert quickly
> and easily. Someone (perhaps me) may organize a series of
> funded sprints to get many of the major packages converted.
One pie
2008/12/12 Sturla Molden :
> Last month there was a discussion on Python-Dev regarding removal of
> reference counting to remove the GIL. I hope you forgive me for continuing
> the debate.
[...]
> Python could be better off doing what tcl does. Allow each process to
> embed multiple interpreters; r
2008/12/17 Greg Ewing :
> Nick Coghlan wrote:
>
>> Actually, I believe 3.0 already took a big step towards allowing this by
>> changing the way modules are initialised.
>
> It's a step, but I wouldn't call it a big one. There are
> many other problems to be solved before fully independent
> interpr
2008/12/18 Greg Ewing :
> Paul Moore wrote:
>>
>> Do you know if these remaining problems are listed anywhere?
>
> There was a big discussion about this in comp.lang.python
> not long ago. Basically all the built-in types and constants
> are shared between interpreters,
2008/12/23 Rocky Bernstein :
> Now that there is a package mechanism (are package mechanisms?) like
> zipimporter that bundle source code into a single file, should the
> notion of a "file" location should be adjusted to include the package
> and/or importer?
Check PEP 302 (http://www.python.org/d
2008/12/23 :
> What is wanted is a uniform way get and describe a file location
> from a code object that takes into account the file might be a member
> of an archive.
But a code object may not have come from a file. Ignoring the
interactive prompt (not because it's unimportant, just because peo
2008/12/23 Nick Coghlan :
> Finding a loader given only a pseudo-filename and no module is actually
> possible in the specific case of zipimport, but is still pretty obscure
> at this point in time:
>
> 1. Scan sys.path looking for an entry that matches the start of the
> pseudo-filename (rememberi
2008/12/23 R. Bernstein :
> A use case here I am thinking of here is in a stack trace or a
> debugger, or a tool which wants to show in great detail, information
> from a code object obtained possibly via a frame object.
Thanks for the clarifications. I see what you're after much better now.
>
2008/12/30 Phillip J. Eby :
> You know, all this path separator and list complication isn't really
> necessary, when you can just take the os.path.dirname() of the return from
> commonprefix().
>
> Perhaps we could just add that recommendation to the docs?
Actually, consider the following (on Wind
2008/12/31 Phillip J. Eby :
> Change that to [os.path.normpath(p)+'/' for p in paths] and you've got
> yourself a winner.
s#'/'#os.sep# to make it work on Windows as well :-)
Have we established yet that this is hard enough to get right to
warrant a stdlib implementation?
Paul
___
2009/1/4 Brett Cannon :
> Bazaar has been backwards-compatible with everything from my
> understanding, so any changes they have made to the repository layout
> or network protocol they use should not be an issue regardless of what
> client or server versions are being used. As for the version numb
2009/1/8 Brett Cannon :
> My work rewriting import in pure Python code has reached beta.
> Basically the code is semantically complete and as
> backwards-compatible as I can make it short of widespread testing or
> running on a Windows box.
I should have done this earlier, sorry. A quick test on W
2009/1/8 Brett Cannon :
> Thanks, Paul! I changed it to _os.getcwd() since that's what nt exposes.
Ta. I wasn't sure _os.getcwd() returned a full pathname.
The only difference between the importlib results and the normal ones
seems to be that with importlib, test_multiprocessing is skipped,
where
2009/1/8 Nick Coghlan :
>> Well, it's not part of the interpreter yet. That can be viewed as a
>> separate step.
>
> True, but what you're doing here can be viewed as the continuation of
> the original implementation plan for PEP 302 - it was always intended
> that every module would eventually get
2009/1/19 Vitor Bosshard :
> Are you even sure the list comprehension doesn't already shortcut evaluation?
>
> This quick test in 2.6 hints otherwise:
>
>
a = (i for i in range(10) if i**2<10)
Yes, but your test, once it becomes true, remains so. Consider
>>> list(n for n in range(10) if n%2
2009/1/20 Benjamin Peterson :
> We might be opening a can of worms, though. Do we document everything
> that takes a dictionary argument with collections.Mapping or
> everything that takes a integer numbers.Rationale? What if multiple
> types are possible?
No. Only document things as taking an ABC
2009/1/23 "Martin v. Löwis" :
>> Brett mentioned in his email that he wasn't ready to make a decision yet, I
>> think? I also think that the PEP could still use some modifications from
>> people
>> who have more experience with the DVCSs.
>
> My question really was whether it is already ready for
2009/1/28 Antoine Pitrou :
> When writing large chunks of text (4096, 1e6), bookkeeping costs become
> marginal and encoding costs dominate. 2.x has no encoding costs, which
> explains why it's so much faster.
Interesting. However, it's still "slower" in terms of perception. In
2.x, I regularly do
2009/1/28 Antoine Pitrou :
> Paul Moore gmail.com> writes:
>>
>> It would be helpful to limit this cost as much as possible - maybe
>> that's simply ensuring that the default encoding for open is (in the
>> majority of cases) a highly-optimised one whose costs
2009/1/28 Antoine Pitrou :
> If you look at how utf-8 decoding is implemented (in unicodeobject.c), it's
> quite obvious why it is so :-) There is a (very) fast path for chunks of pure
> ASCII data, and (fast but not blazingly fast) fallback for non ASCII data.
Thanks for the explanation.
> Pleas
2009/1/28 "Martin v. Löwis" :
> Paul Moore wrote:
>> Hmm, I just checked and on Windows, it
>> appears that sys.getdefaultencoding() is UTF-8. That seems odd - I
>> would have thought the majority of Windows systems were NOT set to use
>> UTF-8 by default...
&g
2009/1/28 "Martin v. Löwis" :
> print(open("a1").read())
>> Traceback (most recent call last):
>> File "", line 1, in
>> File "D:\Apps\Python30\lib\io.py", line 1491, in write
>> b = encoder.encode(s)
>> File "D:\Apps\Python30\lib\encodings\cp850.py", line 19, in encode
>> return
2009/1/28 "Martin v. Löwis" :
> Well, first try to understand what the error *is*:
>
> py> unicodedata.name('\u0153')
> 'LATIN SMALL LIGATURE OE'
> py> unicodedata.name('£')
> 'POUND SIGN'
> py> ascii('£')
> "'\\xa3'"
> py> ascii('£'.encode('cp850').decode('cp1252'))
> "'\\u0153'"
>
> So when Pytho
2009/1/28 Raymond Hettinger :
> [Adam Olsen]
>>
>> It'd also help if the file repr gave the encoding:
>
> +1 from me too. That will be a big help.
Definitely. People *are* going to get confused by encoding errors -
let's give them all the help we can.
Paul
2009/1/29 Oleg Broytmann :
> On Thu, Jan 29, 2009 at 08:06:18AM -0800, Aahz wrote:
>> On Thu, Jan 29, 2009, Michael Foord wrote:
>> > Don't we have a pretty-print API - and isn't it spelled __str__ ?
>>
>> In theory, yes. In practice, we wouldn't be having this discussion if
>> that really worked.
2009/1/30 Steven D'Aprano :
>> But that's beside the
>>
>> point, I don't like __pprint__ in any event. Too special.
>
> I'm not sure what you mean by "too special". It's no more special than any
> other special method. Do you mean the use-case is not common enough? I would
> find this useful. Whet
2009/1/30 Steve Holden :
> Most consistently missing from this picture has been effective
> communications (in both directions) with the user base.
Serious question: does anybody know how to get better communication
from the user base? My impression is that it's pretty hard to find out
who is actu
2009/1/30 Walter Dörwald :
> Paul Moore wrote:
>
>> [...]
>> In all honesty, I think pkgutil.simplegeneric should be documented,
>> exposed, and moved to a library of its own[1].
>
> http://pypi.python.org/pypi/simplegeneric
Thanks, I was aware of that. I assume th
2009/1/31 "Martin v. Löwis" :
> Notice that bdist_wininst doesn't really work in 3.0. So you likely
> won't see many packages until 3.0.1 is released.
Ah, that might be an issue :-)
Can you point me at specifics (bug reports or test cases)? I could see
if I can help in fixing things.
Paul.
_
2009/1/31 "Martin v. Löwis" :
>> Can you point me at specifics (bug reports or test cases)? I could see
>> if I can help in fixing things.
>
> See r69098.
Thanks. So 3.0.1 and later will be fine - my apologies, I hadn't quite
understood what you said.
Paul.
___
2009/2/2 Nick Coghlan :
> Paul Moore wrote:
>> 2009/2/2 Nick Coghlan :
>>> A trio of patches that:
>>> 1. promoted simplegeneric from pkgutil to functools (with appropriate
>>> documentation and tests)
>>> 2. changed pkgutil to use functools.simpl
2009/2/2 Nick Coghlan :
> A trio of patches that:
> 1. promoted simplegeneric from pkgutil to functools (with appropriate
> documentation and tests)
> 2. changed pkgutil to use functools.simplegeneric instead of its current
> internal version
> 3. updated pprint to be a generic function (and hence
On 15 August 2011 11:31, Tarek Ziadé wrote:
> IOW, the task to do is:
>
> 1/ copy packaging and all its stdlib dependencies in a standalone project
> 2/ rename packaging to distutils2
> 3/ make it work under older 2.x and 3.x (2.x would be the priority) <
> 4/ release it, promote its usage
>
On 19 August 2011 16:40, Éric Araujo wrote:
>> One thing that I, as a semi-interested bystander, would like to see is
>> sort of a component of 4. Namely, a document somewhere addressing the
>> question of why I, as a current user of distutils (setup.py, etc),
>> should convert my project to use p
My buildbot seems to have been failing for a while (I've been away on
holiday) - http://www.python.org/dev/buildbot/buildslaves/moore-windows
The failures seem to generally be in distutils and/or packaging. I see
quite a lot of reds in the waterfall display at the moment, and I
can't see any parti
On 26 August 2011 03:52, Guido van Rossum wrote:
> I know that by now I am repeating myself, but I think it would be
> really good if we could get rid of this ambiguity. PEP 393 seems the
> best way forward, even if it doesn't directly address what to do for
> IronPython or Jython, both of which h
On 26 August 2011 17:51, Guido van Rossum wrote:
> On Fri, Aug 26, 2011 at 2:29 AM, "Martin v. Löwis" wrote:
(Regarding my comments on code point semantics)
>> You seem to assume it is ok for Jython/IronPython to provide indexing in
>> O(n). It is not.
>
> Indeed.
On 26 August 2011 18:02, Gui
On 29 August 2011 10:39, Stefan Behnel wrote:
> In the CPython backend, the header files are normally #included by the
> generated C code, so they are used at C compilation time.
>
> Cython has its own view on the header files in separate declaration files
> (.pxd). Basically looks like this:
>
>
On 6 October 2011 17:02, Barry Warsaw wrote:
> I don't particularly like the -m interface though. Yes, it should work, but I
> also think there should be a command that basically wraps whatever the -m
> invocation is, just for user friendliness.
No problem with a wrapper, but the nice thing abou
I see that the Packaging documentation is now more complete (at least
at docs.python.org) - I don't know if it's deemed fully complete yet,
but I scanned the documentation and "Installing Python Projects" looks
pretty much converted (and very good!!), but "Distributing Python
Projects" still has qu
On 9 October 2011 08:15, Éric Araujo wrote:
>> But one thing struck me - the "Installing Python Projects" document
>> talks about source distributions, but not much about binary
>> distributions.
> This is inherited from distutils docs, not a deliberate choice. We just
> haven’t thought much, if
On 9 October 2011 20:47, Tarek Ziadé wrote:
> On Sun, Oct 9, 2011 at 9:31 PM, PJ Eby wrote:
> ...
>>> What we can do however
>>> is to see what bdist_egg does and define a new bdist command inspired by
>>> it, but without zipping, pkg_resource calls, etc.
>>
>> Why? If you just want a dumb bdist
2011/10/10 PJ Eby :
> On Sun, Oct 9, 2011 at 4:14 PM, Paul Moore wrote:
>>
>> As regards the format, bdist_dumb is about the right level - but
>> having just checked it has some problems (which if I recall, have been
>> known for some time, and are why
On 10 October 2011 12:47, Nick Coghlan wrote:
> IIRC, even the Express edition should still work once the 64 bit
> Platform SDK is installed. Regardless, the intent is that it should be
> possible to build Python with only the free tools from MS. If they
> broke the Express editions such that extr
On 10 October 2011 17:12, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> I'd propose that the install arguments used in bdist_wininst be
>> transferred to bdist_dumb (or a new command bdist_binary created based
>> on the same), because the bdist_wini
On 10 October 2011 21:38, Vinay Sajip wrote:
>> I'm not sure what you mean by a "setup.cfg-based directory". Could
>
>> you
>> clarify, and maybe explain how you'd expect to create such an archive?
>> We may be talking at cross-purposes here.
>
> Here's how I see it: at present, you can install a
On 13 October 2011 17:35, Éric Araujo wrote:
> Le 11/10/2011 03:29, Nick Coghlan a écrit :
>> On Mon, Oct 10, 2011 at 2:29 PM, Paul Moore wrote:
>>> Ideally bdist_wininst and bdist_msi would also integrate with pysetup
>>> and with virtual environments, but I imagin
On 13 October 2011 17:25, Éric Araujo wrote:
>> 1. By using setup.cfg technology, it would be easy enough to zip up a
>> binary build in a way that pysetup could unpack and install.
> Correct. I’m still pondering whether I find the idea of registering
> built files in setup.cfg as elegant or hack
On 13 October 2011 18:30, "Martin v. Löwis" wrote:
>> wininst and msi bdists can continue to be used as previously, for people
>> who want clicky installation to their system Python. With built-in
>> package management and virtual environments in 3.3+, we can just
>> recommend that people publish
Looking at a RECORD file installed by pysetup (on 3.3 trunk, on
Windows) all of the filenames seem to be absolute, even though the
package is pure-Python and so everything is under site-packages.
Looking at PEP 376, it looks like the paths should be relative to
site-packages. Two questions:
1. Am
On 13 October 2011 20:28, Tim Golden wrote:
> On 13/10/2011 19:36, Paul Moore wrote:
>>
>> I don't really understand the benefits of bdist_msi over
>> bdist_wininst
>
> Just commenting on this particular issue: in essence, the .MSI
> format is the Microsoft stan
On 14 October 2011 15:07, "Martin v. Löwis" wrote:
>> I can't really comment on this. I agree in principle with what you're
>> saying, but I know little about the MSI format so I can't say much
>> more. It feels to me like you're suggesting that the MSI file
>> encapsulate the file layout logic th
On 14 October 2011 15:13, "Martin v. Löwis" wrote:
>> Thanks for the clarification. I can see why this would be important.
>> But maintaining 3 different interfaces to do essentially the same
>> thing (collect some data from the user, then based on that data put
>> the same set of files in the sam
On 14 October 2011 17:46, "Martin v. Löwis" wrote:
>
>> - On formats, I strongly believe that having multiple formats is a
>> problem. But I need to be clear here - an installer (MSI, wininst) is
>> a bundle containing executable code (which drives the interface), plus
>> a chunk of data that is t
On 15 October 2011 09:04, Nick Coghlan wrote:
> On Sat, Oct 15, 2011 at 4:42 AM, Paul Moore wrote:
>> I wish I felt more comfortable with MSI as a format (as opposed to an
>> opaque clickable installer). I'd be interested to know what others
>> think.
>
> Compi
On 13 October 2011 17:25, Éric Araujo wrote:
>> My expectation would be that the user would type pysetup install
>> some_binary_format_file.zip and have that file unpacked and all the
>> "bits" put in the appropriate place. Basically just like installing
>> from a source archive - pysetup install
On 16 October 2011 22:32, Vinay Sajip wrote:
> There's one area of pysetup3 functionality which I don't think has been
> discussed in this thread, though it's pertinent to Windows users. Namely, a
> completely declarative approach to installation locations will not satisfy all
> requirements. For
On 17 October 2011 10:15, Vinay Sajip wrote:
> It may not work for you, because in the default branch, packaging is currently
> missing some functionality or has bugs (I've raised about a dozen issues since
> trying to get packaging working with virtual environments).
Ah. That might be part of th
On 19 October 2011 00:18, Mark Hammond wrote:
> On 18/10/2011 8:59 PM, Sam Partington wrote:
>> ... and I can imagine lots of users swapping "python" with
>> "py".
>
> Why would users choose to do that? Using "python" presumably already works
> for them, so what benefit do they get? If the main
On 19 October 2011 13:17, Sam Partington wrote:
> Ok ok, I give up. Apparently I am the only one who wants to be able
> to run different versions of python based on the shebang line AND add
> occasional arguments to the python command line.
I don't know if this is of use to anyone, but I attach
(Sorry, should have gone to the list...)
On 22 October 2011 13:15, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
>> As a simpler alternative, I suggest the launcher just gain a "--which"
>> long option that displays the full path to the interpreter it found.
>>
>> So:
>>
>> C:\> py -2 -
I'd like to reopen the discussions on how the new packaging module
will handle/support binary distributions in Python 3.3. The previous
thread (see
http://mail.python.org/pipermail/python-dev/2011-October/113956.html)
included a lot of good information and discussion, but ultimately
didn't reach a
On 30 October 2011 18:04, Ned Deily wrote:
> Has anyone analyzed the current packages on PyPI to see how many provide
> binary distributions and in what format?
A very quick and dirty check:
dmg: 5
rpm: 12
msi: 23
dumb: 132
wininst: 364
egg: 2570
That's number of packages with binary distributi
On 30 October 2011 23:17, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> The MSI format is a little more tricky, mainly because it is a more
>> complex format and (as far as I can tell from a brief check) files are
>> stored in the opaque CAB format, so the o
On 31 October 2011 10:42, "Martin v. Löwis" wrote:
> Am 31.10.2011 09:07, schrieb Vinay Sajip:
> This presumption is false (as is the claim that you need to install the
> MSI to get at the files). It's quite possible to extract the files from
> the MSI without performing the installation. There ar
On 31 October 2011 14:22, Antoine Pitrou wrote:
> On Mon, 31 Oct 2011 05:59:09 -0400
> "Eric V. Smith" wrote:
>>
>> It might be true that such systems don't need binary packages on PyPI,
>> but the original question is about binary package support for the
>> packaging module on non-Windows system
On 31 October 2011 16:08, Tres Seaver wrote:
> On 10/31/2011 11:50 AM, Carl Meyer wrote:
>
>> I have no problem including the basic posix/nt activate scripts if
>> no one else is concerned about the added maintenance burden there.
>>
>> I'm not sure that my cross-shell-scripting fu is sufficient t
On 31 October 2011 18:36, Ned Deily wrote:
> In article
> ,
> Paul Moore wrote:
>> On 30 October 2011 18:04, Ned Deily wrote:
>> > Has anyone analyzed the current packages on PyPI to see how many provide
>> > binary distributions and in what format?
&
On 31 October 2011 20:10, Carl Meyer wrote:
>> For Windows, can you point me at the nt scripts? If they aren't too
>> complex, I'd be willing to port to Powershell.
>
> Thanks! They are here:
> https://bitbucket.org/vinay.sajip/pythonv/src/6d057cfaaf53/Lib/venv/scripts/nt
The attached should work
On 1 November 2011 16:29, Paul Moore wrote:
> On 31 October 2011 20:10, Carl Meyer wrote:
>>> For Windows, can you point me at the nt scripts? If they aren't too
>>> complex, I'd be willing to port to Powershell.
>>
>> Thanks! They are here:
>&
On 1 November 2011 16:40, Paul Moore wrote:
> On 1 November 2011 16:29, Paul Moore wrote:
>> On 31 October 2011 20:10, Carl Meyer wrote:
>>>> For Windows, can you point me at the nt scripts? If they aren't too
>>>> complex, I'd be willing to port t
On 7 November 2011 09:26, Vinay Sajip wrote:
> Martin v. Löwis v.loewis.de> writes:
>
>>
>> Again, that's a bdist_msi implementation issue. It could generate custom
>> actions that run the "proper" setup.cfg hooks (I presume - I have no
>> idea what a setup.cfg hook actually is).
>>
>
> I know th
On Wed, Nov 9, 2011 at 10:14, Barry Warsaw wrote:
>
> I think we should have an official pronouncement about Python 2.8, and
> PEPs
> are as official as it gets 'round here. Thus I propose the following. If
> there are no objections , I'll commit this taking the next available
> number.
+1 on h
On 9 November 2011 23:11, Guido van Rossum wrote:
> On Wed, Nov 9, 2011 at 2:13 PM, Greg Ewing
> wrote:
>> In my current grammar, it's a syntax error on its own,
>> but 'f(yield from x, y)' parses as 'f((yield from x), y)',
>> which seems like a reasonable interpretation to me.
>
> Once you real
On 16 November 2011 13:23, Brian Curtin wrote:
> Not dead, there was just a period where I got a little too busy with real
> life, plus development seemed to slow down for a while. I have a few drafts
> working (like a post on all of the recent PEP activity) and a few more in my
> head, but I'd li
On 17 November 2011 21:09, Jerome Leclanche wrote:
>> We run the blog out of a Mercurial repository on BitBucket and do the
>> writing in reStructuredText, then publish via Blogger.
>
> It sounds to me like this could be a reason why there are so few
> volunteers. Blog authors/writers usually don'
On 25 November 2011 11:37, Matt Joiner wrote:
>> No "wtf" here, the read() loop is quadratic since you're building a
>> new, larger, bytes object every iteration. Python 2 has a fragile
>> optimization for concatenation of strings, which can avoid the
>> quadratic behaviour on some systems (depen
On 25 November 2011 15:07, Amaury Forgeot d'Arc wrote:
> 2011/11/25 Paul Moore
>> It would be nice to have the optimisation back if it's easy enough to
>> do so, for quick-and-dirty code, but it is not a good idea to rely on
>> it (and it's especially unw
On 4 December 2011 12:20, Tim Golden wrote:
> On 04/12/2011 11:42, Nick Coghlan wrote:
>>
>> There's actually two questions to be answered:
>> 1. What should we do in 3.2 and 2.7?
>> 2. Should we do anything more in 3.3?
See below...
> This is actually a separate issue: how much of Python will w
On 9 December 2011 18:15, Bill Janssen wrote:
> I use ElementTree for parsing valid XML, but minidom for producing it.
>
> I think another thing that might go into "refreshing the batteries" is a
> feature comparison of BeautifulSoup and HTML5lib against the stdlib
> competition, to see what needs
On 5 January 2012 19:33, David Malcolm wrote:
> We have similar issues in RHEL, with the Python versions going much
> further back (e.g. 2.3)
>
> When backporting the fix to ancient python versions, I'm inclined to
> turn the change *off* by default, requiring the change to be enabled via
> an env
On 6 January 2012 20:25, Mark Shannon wrote:
> Hi,
>
> It seems to me that half the folk discussing this issue want a super-strong,
> resist-all-hypothetical-attacks hash with little regard to performance. The
> other half want no change or a change that will have no observable effect.
> (I may b
On 7 January 2012 22:56, Eli Bendersky wrote:
>
>> A then-related question is whether Python 3.3 should be compiled with
>> Visual
>> Studio 11. I'd still be in favor of that, provided Microsoft manages to
>> release
>> that soon enough.
>
>
> Martin, I assume you mean the Express version of Visua
On 18 January 2012 04:32, Terry Reedy wrote:
>> It's really about making feature releases more frequent,
>
>> not making previews available during development.
>
> Given the difficulty of making a complete windows build, it would be nice to
> have one made available every 6 months, regardless of h
On 18 January 2012 07:46, Georg Brandl wrote:
>> But I am dubious that releases that are obsolete in 6 months and lack
>> 3rd party support will see much production use.
>
> Whether people would use the releases is probably something that only
> they can tell us -- that's why a community survey is
On 20 January 2012 03:57, Brian Curtin wrote:
>> FWIW, it might well be that I can't be available for the 3.3 final
>> release (I haven't finalized my vacation schedule yet for August).
>
> In the interest of not having Windows releases depend on one person,
> and having gone through building the
On 27 January 2012 21:48, Antoine Pitrou wrote:
> Well, obviously __preview__ is not for the most conservative users. I
> think the name clearly conveys the idea that you are trying out
> something which is not in its definitive state, doesn't it?
Agreed. But that in turn implies to me that __pre
On 28 January 2012 09:18, Nick Coghlan wrote:
> It's basically us saying to Python users "We're explicitly flagging
> this PyPI module for inclusion in the next major Python release. We've
> integrated it into our build process, test suite and binary releases,
> so you don't even have to download
On 28 January 2012 01:48, Barry Warsaw wrote:
> The thinking goes like this: if you would normally use an __preview__ module
> because you can't get approval to download some random package from PyPI, well
> then your distro probably could or should provide it, so get it from them. In
> fact, if
On 29 January 2012 18:10, C. Titus Brown wrote:
> python-dev isn't that inappropriate, IMO, but probably the best place to
> go with this discussion is python-ideas. Could you repost over there?
I agree that python-dev isn't particularly appropriate, python-list is
probably your best bet. The py
On 29 January 2012 21:39, Gregory P. Smith wrote:
> An example of this working: ipaddr is ready to go in. It got the
> eyeballs and API modifications while still a pypi library as a result
> of the discussion around the time it was originally suggested as being
> added. I or any other committers
On 31 January 2012 11:11, Nick Coghlan wrote:
> although decimal.Decimal is also a contender if backed up by
> Stefan's C implementation.
As you mention this, and given the ongoing thread about __preview__
and "nearly ready for stdlib" modules, what is the current position on
cdecimal? I seem to
1501 - 1600 of 1862 matches
Mail list logo
