Martin v. Löwis v.loewis.de> writes:
>
> Not sure whether it's still relevant after the offers of individually
> donated hardware.
We'll see, indeed.
> However, if you want to look into this, feel free to
> set up EC2 slaves.
I only know to setup mainstream Linux distros though (Debian- or
Red
Brett Cannon python.org> writes:
>
> Just wanted to publicly thank everyone who has been causing all the
> checkins to fix and stabilize the test suite (I think it's mostly
> Antoine and Mark, but I could be missing somebody; I'm under a
> deadline so only have marginal higher brain functionality
Hello again,
Brett Cannon python.org> writes:
>
> I think it's worth it. Removal of the GIL is a totally open-ended problem
> with no solution in sight. This, on the other hand, is a performance benefit
> now. I say move forward with this. If it happens to be short-lived because
> some actua
Hello,
I wondered if someone had a clue about the following behaviour.
While debugging an erratic test_mailbox failure on RDM's buildbot (and other
machines), it turned out that the system sometimes set the wrong mtime on a
directory:
$ date && python -c 'import os; os.link("setup.py", "t/c")' &&
Adam Olsen gmail.com> writes:
>
> Looks like an OS bug to me. Linux I'm guessing?
Yes, but only on certain boxes. I could never reproduce on my home box.
RDM (David)'s buildbot is a Gentoo vserver with a reiserfs filesystem.
___
Python-Dev mailing l
Le lundi 02 novembre 2009 à 08:02 +1100, Robert Collins a écrit :
>
> The FAT rounding issue is a possibility, but I didn't think reiserfs was
> short that much precision.
>
> I'd check that the work area you had really was reiser, not a mounted AT
> partition, and if its not look up the ReiserFS
Christian Heimes cheimes.de> writes:
>
> +1 from me. I trust you like Brett does.
>
> How much work would it cost to make your patch optional at compile time?
Quite a bit, because it changes the logic for processing asynchronous pending
calls (signals) and asynchronous exceptions in the eval lo
Cameron Simpson zip.com.au> writes:
>
> Personally, I'm for the iteration spec in a lot of ways.
>
> Firstly, a .get()/.pick() that always returns the same element feels
> horrible. Is there anyone here who _likes_ it?
I do. Since the caller is asking for an arbitrary element, returning the sam
Martin v. Löwis v.loewis.de> writes:
>
> I've looked at this part of the implementation, and have a few comments.
> a) why is gil_interval a double? Make it an int, counting in
>microseconds.
Ok, I'll do that.
> b) notice that, on Windows, minimum wait resolution may be as large as
>15m
twistedmatrix.com> writes:
>
> Starting with a mainstream distro doesn't seem like a bad idea. For
> example, there isn't currently a 32bit Ubuntu (any version) slave. That
> would be a nice gap to fill in, right?
I've setup a buildslave on an EC2 Ubuntu Karmic instance here:
http://www.pyth
Martin v. Löwis v.loewis.de> writes:
>
[gil_drop_request]
> Even if it is read from memory, I still wonder what might happen on
> systems that require explicit memory barriers to synchronize across
> CPUs. What if CPU 1 keeps reading a 0 value out of its cache, even
> though CPU 1 has written an
Le lundi 02 novembre 2009 à 13:31 +0100, "Martin v. Löwis" a écrit :
>
> There was discussion that an EC2 instance can be turned on only when
> needed, so we could try to set up something like that (the build master
> could then trigger activation of the machine, IIUC). However, it might
> be that
Le lundi 02 novembre 2009 à 07:42 -0500, sstein...@gmail.com a écrit :
>
> If you could send me the script that you used to set it up, I could
> give it a shot on RackSpace where it's cheaper (and I have a temporary
> developer account).
There's no need for a special script, really.
Install P
> OTOH, that isn't that expensive (compared to the other PSF expenses),
> plus people keep donating money, so when we say what we use it for,
> there may be a larger return than just the test results.
>
> OTTH, the same could be achieved by buying a hosted server elsewhere.
One advantage of a re
Sturla Molden molden.no> writes:
>
> And the timeout "milliseconds" would now be computed from querying the
> performance
> counter, instead of unreliably by the Windows NT kernel.
Could you actually test your proposal under Windows and report what kind of
concrete benefits it brings?
Thank yo
Sturla Molden molden.no> writes:
>
> By the way Antoine, if you think granularity of 1-2 ms is sufficient,
It certainly is.
But once again, I'm no Windows developer and I don't have a native Windost host
to test on; therefore someone else (you?) has to try.
Also, the MSDN doc (*) says timeBegi
Sturla Molden molden.no> writes:
>
> I'd love to try, but I don't have VC++ to build Python, I use GCC on
> Windows.
You can use Visual Studio Express, which is free (gratis).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Guido van Rossum python.org> writes:
>
> Is it even wort doing a 2.7 release? Isn't the effort better spent on
> 3.2 alone? (Note, these aren't rhetorical questions. It's well
> possible that there are good reasons for pushing along with 2.7. Maybe
> considering those reasons will also help answe
Sturla Molden molden.no> writes:
>
> Porting NumPy is not a trivial issue. It might take
> a complete rewrite of the whole C base using Cython.
I don't see why they would need a rewrite. Little of the C API has changed
between 2.x and 3.x. Cython itself is supposed to support both 2.x and 3.x,
David Cournapeau gmail.com> writes:
>
> To answer your question, the main issues are:
> - are two branches are necessary or not ? If two branches are
> necessary, I think we simply do not have the resources at the moment.
> - how to maintain a compatible C API across 2.x and 3.x
> - is it prac
David Cournapeau gmail.com> writes:
>
> We can port to PEP 3118 without
> porting to 3.x, and we can port to 3.x without taking care of PEP
> 3118.
I'm not sure you can do the latter. The old buffer API (the one PEP 3118
replaces) doesn't exist in py3k.
Antoine.
_
Paul Moore gmail.com> writes:
>
> FWIW, I did a quick survey of some packages (a sampling of packages
> I've used or considered using in the past):
>
> Twisted - no plans yet for Python 3
Well Twisted depends on zope.interface which is not ported yet.
Twisted apparently has plans to reduce or r
Guido van Rossum python.org> writes:
>
> The PEP tries to spell out some gray areas but I'm sure there will be
> others; that's life. Do note that the PEP proposes to be *retroactive*
> back to the 3.1 release, i.e. the "frozen" version of the language is
> the state in which it was released as 3
Arc Riley gmail.com> writes:
>
> +1 on ending with 2.6.I'm the maintainer of 3rd party Python 3-only packages
> and have ported a few modules that we needed with some help from the 2to3
> tool. It's really not a big deal - and Py3 really is a massive improvement.
> The main thing holding back t
Georg Brandl gmx.net> writes:
>
> skip pobox.com schrieb:
> > Martin> And if *2.6* becomes the last of the 2.x series?
> >
> > With all due respect, I don't think you can make that decision now. The
> > time to have stated 2.6 would be the end of the 2.x line was when 2.6 was
> > released.
Brett Cannon python.org> writes:
>
> I'm afraid there is some FUD going around here, which is
> understandable since no one wants to burn a ton of time on something
> that will be difficult or take a lot of time. But I have not heard
> anyone in this email thread (or anywhere for that matter) say
Guido van Rossum python.org> writes:
>
> You're obviously talking about a *random* element. This is a separate
> use case (though I agree many people don't know the difference).
>
> Picking a random element can be done in O(1) only if the data
> structure supports access by index, which Python's
Greg Ewing canterbury.ac.nz> writes:
> >
> >>Picking a random element can be done in O(1) only if the data
> >>structure supports access by index, which Python's hash tables don't.
> >
> > Well, at the implementation level, they can. You'd just have to pick a new
> > random index until it points
Glyph Lefkowitz twistedmatrix.com> writes:
>
> Keep in mind also that the 2.x translation process is extremely slow
> and results in a clunky development process. There's no '2to3 --
> interactive' commandline that lets me type python 2 at a >>> prompt
> and get python 3 results out so that
Michael Foord voidspace.org.uk> writes:
>
> I would love to see nonlocal backported to 2.7 as it cleans up a simple
> pattern that I use relatively often for testing.
Well you know I'm sure that if someone proposes a proper patch it will
eventually get accepted ;)
Regards
Antoine.
_
Hello,
> Solaris X86, 16 cores: some python extension are likely missing (see
config.log)
> Windows XP SP3, 4 cores: all python extensions but TCL (I didn't bother
checking why it failed as it is not used in the benchmark). It is a release
build.
>
> The results look promising but I let you sh
Hello Guido,
> How close are you to merging this into the Py3k branch? It looks like
> a solid piece of work, that can only get better in the period between
> now and the release of 3.2. But I don't want to rush you, and I only
> have had a brief look at your code.
The code is ready. Priority re
Hello again,
> It shows that, on my platform for this specific benchmark:
> * newgil manage to leverage a significant amount of parallelism
> (1.7) where python 3.1 does not (3.1 is 80% slower)
I think you are mistaken:
-j0 (main thread only)
newgil: 47.483s, 47.605s, 47.512s
-j4
Baptiste Lepilleur gmail.com> writes:
>
> I've tried, but there is no change in result (the regexp does not use \w &
> co but specify a lot unicode ranges). All strings are already of unicode
> type in 2.6.
No they aren't. You should add "from __future__ import unicode_literals" at the
start of
Stefan Krah bytereef.org> writes:
>
> Are there cases where == and != are actually needed to give a result
> for NaNs?
It is a common expectation that == and != always succeed. They return True or
False, but don't raise an exception even on unrelated operands:
>>> b"a" == "a"
False
>>> "5" == 5
Greg Ewing canterbury.ac.nz> writes:
>
> If anonymous code blocks still get discussed even when
> they have no chance of being accepted, this suggests that
> a moratorium is *not* going to stop discussion of new
> features.
Well, if they get discussed, it's probably that some people can't help
p
Stefan Krah bytereef.org> writes:
>
> >>> d = {0:Decimal("NaN")}
> >>> Decimal("NaN") in d.values()
> False
>
> So, since non-decimal use cases are limited at best, the equality/inequality
> operators might as well have the behavior of the other comparison operators,
> which is safer for the use
Stefan Krah bytereef.org> writes:
>
> I see the point, but Decimal("NaN") does not hash:
Ok but witness again:
>>> L = [1, 2, Decimal("NaN"), 3]
>>> 3 in L
True
>>> class H(object):
... def __eq__(self, other): raise ValueError
...
>>> L = [1, 2, H(), 3]
>>> 3 in L
Traceback (most recent cal
Stefan Krah bytereef.org> writes:
>
> I guess my point is that NaNs in lists and dicts are broken in so many
> ways that it might be good to discourage this use. (And get the added
> benefit of safer mathematical behavior for == and !=.)
Giving users seemingly random and unexplainable exceptions
Nick Coghlan gmail.com> writes:
>
> It's also one of the major reasons for not sharing mutable containers
> between threads if you can avoid it (and serialising access to them if
> you can't)
Not necessarily, for example it is common to rely on the fact that list.append()
is atomic.
Regards
An
Guido van Rossum python.org> writes:
>
> Was this discussed somewhere?
I don't remember so, except for a short subthread on python-ideas where you
indeed mentioned (to my disappointment :-)) that you were against a one-year
release period.
Regards
Antoine.
___
Hello again,
I've now removed priority requests, tried to improve the internal doc a
bit, and merged the changes into py3k.
Afterwards, the new Windows 7 buildbot has hung in test_multiprocessing,
but I don't know whether it's related.
Regards
Antoine.
Guido van Rossum python.org> writes:
Le Thu, 05 Nov 2009 22:53:27 -0500, R. David Murray a écrit :
> The buildbot waterfall is much greener now. Thanks to all who have
> contributed to making it so (and it hasn't just been Mark and Antoine
> and I, though we've been the most directly active (and yes, Mark, you
> did contribute sever
Guido van Rossum python.org> writes:
>
> If you were to ask me, the people arguing against ratings and user
> comments are fighting a losing battle. If they had an iPhone or
> Android phone (or some other device with an "app store" kind of place
> to find downloads) they'd know the value (for pro
A.M. Kuchling amk.ca> writes:
>
> For comments, haloscan and disqus are third-party comment-hosting
> services; http://redalt.com/blog/comment-services has a longer list.
They are horrible for page loading times; and besides, I don't know how you can
trust such third-party to provide an importan
Martin v. Löwis v.loewis.de> writes:
>
> I think you are missing the point of the commenting system: these
> comments are *not* directed towards the package author. Instead, they
> are directed towards fellow users of the package. For this kind of
> message, a bugtracker is completely inappropria
Masklinn masklinn.net> writes:
>
> On 13 Nov 2009, at 00:00 , Antoine Pitrou wrote:
> >
> > Then why not simply add a sentence or two before the comment form warning
that
> > the comment system is not meant to ask for help, support or debugging about
the
> > pa
Masklinn masklinn.net> writes:
>
> And then user will probably ask why you're not answering the question since
> you're here anyway, or might go
> as far as telling you that if you're not going to help you might as well not
> answer.
As I said, you are regarding the user as an idiot or as a trol
Ben Finney benfinney.id.au> writes:
>
> There's a problem with the poll's placement: on the front page of the
> PyPI website.
Speaking of which, why is it that http://pypi.python.org/pypi and
http://pypi.python.org/pypi/ (note the ending slash) return different contents
(the latter being very vo
Matthew Woodcraft woodcraft.me.uk> writes:
>
> It seems clear to me that, given those figures, allowing comments would
> not be following the result of the vote.
>
> So I think that simply implementing the option that receives most votes
> is not a wise plan.
Can we defer any further discussion
Martin v. Löwis v.loewis.de> writes:
>
> > The buildbots still show occasional oddities. For example, right now in
> > the page "http://www.python.org/dev/buildbot/3.x/";, some results have
> > disappeared (the columns for "AMD64 Ubuntu" builders have become empty).
>
> Yes, I noticed it too.
Chris Withers simplistix.co.uk> writes:
>
> PS: While I'm sure a lot of python-dev people are interested in this
> topic, I'm pretty sure this whole huge sprawling thread belongs on
> catalog-sig...
Yes, please :)
Antoine.
___
Python-Dev mailing
Tarek Ziadé gmail.com> writes:
>
> This cannot work on all platforms, when our Makefile is not shipped
> with python but python-devel. (like Fedora)
This practice is stupid anyway, because it means you have to install
python-devel even to install pure Python packages with setuptools/distribute.
Benjamin Peterson python.org> writes:
>
> 2009/11/15 Michael Foord voidspace.org.uk>:
> > Well, personally I think it would be a good thing if this raised an
> > exception during bytecode compilation - but it would fall under the
> > moratorium and have to wait a few years.
>
> It could probabl
Hello,
I've submitted a patch (*) to add an optional timeout to locking operations
(Lock.acquire() etc.). Since it's a pretty basic functionality, I would like to
know if there was any good reason for not doing it.
(*) http://bugs.python.org/issue7316
Thank you
Antoine.
_
Guido van Rossum python.org> writes:
>
> I think the number of platforms
> has dwindled to two or three (Posix, Windows, and maybe one minority
> OS?), so now's the time to do it. (IOW I think the idea of the patch
> is fine.)
Thanks. (the minority OS would be OS/2, I think)
> Will locks be int
Barry Warsaw python.org> writes:
>
> > If no one else wants to try and ruin Python 3, I'll do it .
>
> Ha ha ha^H^H^H^H^H^H^H^H^HGreat! Benjamin's the expert now, but I'm
> here to help if needed.
Well Georg isn't a novice when it comes to ruining things, especially
documentation and commit
Jesse Noller gmail.com> writes:
>
> Nick is right, many of the BSDs and FreeBSD up until fairly recently
> did not have named shared semaphore support. Still yet, the behavior
> is broken on some OSes such as OS X which you have to work around.
The core locking support only uses anonymous se
Hello,
> > I've submitted a patch (*) to add an optional timeout to locking
> > operations (Lock.acquire() etc.). Since it's a pretty basic
> > functionality, I would like to know if there was any good reason for
> > not doing it.
>
> I always assumed it was because as a least-common-denominator
Tarek Ziadé gmail.com> writes:
>
> So what I am proposing is to inject those values in a private dict in
> the new sysconfig.py module,
> that can be read through the get_config_vars / get_config_var APIs.
>
> This means that sysconfig.py will be added as "sysconfig.py.in"
This means you have t
M.-A. Lemburg egenix.com> writes:
>
> We could then also have a py2compat.c to hold corresponding
> C code, e.g. to provide compatibility wrappers of new APIs that
> implement different semantics in 3.x.
If the semantic differences are embodied in the builtin object types I wonder
how you can ma
Paul Moore gmail.com> writes:
>
> I'm getting odd failures with some of the tests as well, at the moment
> - test_smtplib and others failing but when "Re-running failed tests in
> verbose mode" there were no failures.
>
> I wonder if it could be a flaky network connection...?
test_smtplib is no
Eric Smith trueblade.com> writes:
>
> But in trunk, the value is just used as-is. So when formating a decimal,
> for example, '\xc2\xa0' is just inserted into the result, such as:
> >>> format(Decimal('1000'), 'n')
> '1\xc2\xa'
> This doesn't make much sense,
Why doesn't it make sense? It's
> Well, one problem is that it messes up character counts.
Well, I know it does. That's why py3k is inherently better than 2.x's
bytestrings-by-default behaviour. There's a reason we don't try to
backport py3k's unicode goodness to 2.x, and that's it would be terribly
messy to do so while retaini
Hello,
I was going to suggest adding ccbench and iobench to the Tools directory,
so I wonder whether there are any rules for putting stuff there?
Thank you
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Kristján Valur Jónsson ccpgames.com> writes:
>
> The problem with this is that once you have called
> factorial() once, you end up with a recursive cycle.
You don't need a closure to exhibit a reference cycle. A global function is
enough:
>>> def helper(n):
... if n:
... return n*helper(n-1
Kristján Valur Jónsson ccpgames.com> writes:
>
> a gc.collect() cycle visits a large amount of objects that it
> won‘t release causing cache thrashing.
>
> There is a reason we disabled ‚gc‘, and it is simply because we
> get lower cpu and smoother execution.
Could you try to enable the gc with
twistedmatrix.com> writes:
>
> I don't know if this is related at all (and I guess we won't until
> Lennart can be more specific :), but here are some Twisted unit test
> failures which are probably due to unittest changes in 2.7:
You should do a specific diagnosis for each of these failures,
Tarek Ziadé gmail.com> writes:
>
> Do you have a better suggestion ? I was thinking about StandardVersion
> but "Standard"
> doesn't really express what we want to achieve here I think,
I think StandardVersion is fine.
___
Python-Dev mailing list
Pyt
Michael Foord voidspace.org.uk> writes:
>
> I also use -v for verbose in a few scripts (including options to
> unittest when run with python -m). I've seen -V as a common abbreviation
> for --version (I've just used this with Mono for example).
+1 for letting -v mean "--verbose". This is a rea
Hello,
Mark Dickinson gmail.com> writes:
>
> I'd like to request that Stefan Krah be granted commit privileges to the
> Python
> svn repository, for the sole purpose of working on a (yet to be created)
> py3k-decimal-in-c branch.
Regardless of whether the commit rights are granted (I am not a
Steven Bethard gmail.com> writes:
>
> Please read the PEP if you haven't, particularly the "Why isn't the
> functionality just being added to optparse?" section. I don't believe
> it is sensible to re-implement all of optparse. What Ian Bicking is
> proposing, I believe, is simpler -- adding a fe
Dino Viehland microsoft.com> writes:
>
> > * get_platform(): Return a string that identifies the current
> > platform. (this one is used by site.py for example)
>
> I wonder if this would make more sense a built-in. Ultimately it seems
> like the interpreter implementation knows best about wh
Steven Bethard gmail.com> writes:
>
> Because people are continuing this discussion, I'll say again that
> argparse already supports this:
Well I think the point is that if there is a default, the default should be
sensible and not run against expectations.
It would probably be fine not to have
Tarek Ziadé gmail.com> writes:
>
> This was ambiguous because it was unclear, as MvL stated, if "2.5"
> was just "2.5.0" or included
> versions like "2.5.1" or "2.5.2".
How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5
itself? (ditto for "2.5.N" matching only 2.5.N for
> And in fact this case is often more the important one. Packages that
> depend on having a *recent* version of python will often crash
> quickly, before doing permanent damage, when an undefined syntax,
> function, or method is invoked, while packages that depend on a quirk
> in behavior of an o
> > How can they know that they depend on "a quirk in behaviour of an older
> > version" if a newer version hasn't been released? This sounds bogus.
>
> Of course a newer version has been released. Who said it hasn't been?
> Eg, the discussion of <=2.5. Hasn't 2.6 been released? Or am I
> ha
David Lyon preisshare.net> writes:
>
> Requires a particular python version.
>
> > Requires-Python: 2.5:2.7
Why not drop ranges as well as operators and simply use commas?
The above would be rewritten as:
Requires-Python: 2.5, 2.6, 2.7
This would prevent the ambiguity on the inclusive or ex
R. David Murray bitdance.com> writes:
>
> > Why not drop ranges as well as operators and simply use commas?
> > The above would be rewritten as:
> >
> > Requires-Python: 2.5, 2.6, 2.7
> >
> > This would prevent the ambiguity on the inclusive or exclusive nature
of the
> > upper bound of the r
Hi Chris,
> Is there a high volume of incoming bugs to the Python tracker?
> If so, I'd like to help with triaging. I think I have all the necessary
> access, what I'm missing is the knowledge of how to set myself up to get
> notifications of new bugs...
Do you really want to get such notifica
Le Wed, 06 Jan 2010 08:57:42 -0600, Brian Curtin a écrit :
> On the topic of bugs that can be readily closed (literally), I've
> recently come across a number of issues which appear to be sitting in a
> patch or review stage, but their patches have been committed and the
> issue remains open. What
Antoine Pitrou pitrou.net> writes:
>
> Le Wed, 06 Jan 2010 08:57:42 -0600, Brian Curtin a écrit :
> > On the topic of bugs that can be readily closed (literally), I've
> > recently come across a number of issues which appear to be sitting in a
> > patch or revi
e else (that would be the case
for e.g. a list that your function has created and is busy populating).
I agree that releasing the GIL when doing non-trivial regex searches is a
worthwhile research, so please don't give up immediately :-)
Regards
Antoine Pitrou.
Martin v. Löwis v.loewis.de> writes:
>
> I don't think that's possible. The regex engine can also operate on
> objects whose representation may move in memory when you don't hold
> the GIL (e.g. buffers that get mutated).
Why is it a problem? If we get a buffer through the new buffer API, the ob
Le Thu, 07 Jan 2010 22:11:36 +0100, Martin v. Löwis a écrit :
>
> Even if we do use the new API, and correctly, it still might be
> confusing if the contents of the buffer changes underneath.
Well, no more confusing than when you compute a SHA1 hash or zlib-
compress the buffer, is it?
Regards
Victor Stinner haypocalc.com> writes:
>
> I wrote a new version of my patch (version 3):
>
> * don't change the default behaviour: use open(filename, encoding="BOM") to
> check the BOM is there is any
Well, I think if we implement this the default behaviour *should* be changed.
It looks a bit
Guido van Rossum python.org> writes:
>
> > Well, I think if we implement this the default behaviour *should* be
> > changed.
> > It looks a bit senseless to have two different "auto-choose" options, one
with
> > encoding=None and one with encoding="BOM".
>
> Well there *are* two different auto
Guido van Rossum python.org> writes:
>
> On Thu, Jan 7, 2010 at 10:12 PM, Tres Seaver palladion.com>
wrote:
> > The BOM should not be seekeable if the file is opened with the proposed
> > "guess encoding from BOM" mode: it isn't properly part of the stream at
> > all in that case.
>
> This fee
Hello Victor,
Victor Stinner haypocalc.com> writes:
>
> (1) Change default open() behaviour or make it optional?
>
[...]
>
> Antoine would like to check BOM by default, because both options (system
> locale vs checking for BOM) is the same thing.
To be clear, I am not saying it is the same t
Walter Dörwald livinglogic.de> writes:
>
> On the surface this looks like there's an encoding named "BOM", but
> looking at your patch I found that the check is still done in
> TextIOWrapper. IMHO the best approach would to the implement a *real*
> codec named "BOM" (or "sniff"). This doesn't
pobox.com> writes:
>
> If a patch to merge this to 2.7 is already under
> consideration I won't look at it,
Why won't you look at it? :)
Actually, if these patches are to be merged someone should certainly look at
them, and do the (possibly) remaining work.
http://bugs.python.org/issue5683
http
Martin v. Löwis v.loewis.de> writes:
>
> > Sorry but this is missing the point. The point here is to improve the open()
> > function. I'm sure people who know about encodings are able to install the
> > chardet library or even whip up their own BOM detection routine...
>
> How does the requireme
> However if this autodetection feature is useful in other cases (no
> matter how it's activated), it should be a codec, because as part of the
> open() function it isn't reusable.
It is reusable as part of io.TextIOWrapper, though.
Regards
Antoine.
___
David Lyon preisshare.net> writes:
>
> > This has nothing to do with pushing 3.x, but all with managing
> > available manpower and still providing quality software.
>
> Python 3.x needs more carrots.
As someone who experiences the difference almost every day, I can say 3.x
definitely has enough
Andrew Bennetts bemusement.org> writes:
>
> But a hypothetical 2.8 would also give people a way to move closer to
> py3k without giving up on using all their 2.x-only dependencies. I
> think it's much more likely that libraries like Twisted can support 2.8
> in the near future than 3.x.
I don't
Le Mon, 11 Jan 2010 19:57:46 -0600, Brian Curtin a écrit :
>
> For example, there are currently over
> 1500 open issues with no stage set, some of which seemingly haven't been
> read by anyone at all.
I think most issues /have/ been read. It's just that for many of them,
nobody is interested eno
Le Tue, 12 Jan 2010 10:20:27 +, Antoine Pitrou a écrit :
>
> I don't think this has anything to do with properly setting the stage
> field. We just have limited time and manpower. Perhaps one of our goals
> should be to reach out more to potential contributors.
Speaking of
Christian Heimes cheimes.de> writes:
>
> How about:
>
> * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 /
> X86-64 binary -- does not include source)
+1. I don't care about trademarks or official names, we should call it whatever
is obvious for our users.
As for Itanium, it i
Jeroen Ruigrok van der Werven in-nomine.org> writes:
>
> -On [20100113 22:13], Ralf Schmitt (ralf brainbot.com) wrote:
> >hehe. tab completion:
>
> With bpython and ipython available, why would you even want to stick to the
> 'plain old' interactive interpreter?
Why wouldn't we?
There are prob
Ned Deily acm.org> writes:
>
> I've recently seen a couple of references to 3.1.2 go by in checkins
> which made me wonder whether dates have been proposed yet for updates to
> either 3.1 or 2.6. I don't recall seeing any and I didn't see any
> references in the PEPs. Some advance warning wo
2501 - 2600 of 4909 matches
Mail list logo
