> It's true that as Martin said, we can rebase our code to Py3K in a
> branch on python.org any time we like, the question is more "if we do
> the work, will the Python community accept it".
I've stated my personal preference already. Let me add an observation on
top of that: even if the core comm
> Where the default *file system encoding* is used (i.e. text files are
> written or read without specifying an encoding)
I think you misunderstand the notion of the *file system encoding*.
It is *not* a "file encoding", but the file *system* encoding, i.e.
the encoding for file *names*, not for f
> 1. What are the implications for PEP 384 (Stable ABI) if U-S is added?
I haven't studied U-S yet, but I'd hope that there might be no
implications. No basic API should change, and everything the JIT
compiler does should be well shielded from the object API (which PEP 384
deals with).
> 2. What
Reid Kleckner wrote:
> On Thu, Jan 21, 2010 at 7:25 AM, Antoine Pitrou wrote:
>>> 32-bit; gcc 4.0.3
>>>
>>> +-+---+---+--+ |
>>> Binary size | CPython 2.6.4 | CPython 3.1.1 | Unladen Swallow r988 |
>>> +=+===+=
> How large is the LLVM shared library? One surprising data point is that the
> binary is much larger than some of the memory footprint measurements given in
> the PEP.
Could it be that you need to strip the binary, or otherwise remove
unneeded debug information?
Regards,
Martin
_
> There is "freeze":
> http://wiki.python.org/moin/Freeze
>
> Which IIRC Robert Collins tried in the past, but didn't see a huge gain.
> It at least tries to compile all of your python files to C files and
> then build an executable out of that.
"to C files" is a bit of an exaggeration, though. I
> On Wed, Jan 20, 2010 at 10:54:11PM -0800, Gregory P. Smith wrote:
>> I think having a run time flag (or environment variable for those who like
>> that) to disable the use of JIT at python3 execution time would be a good
>> idea.
>
> Another approach could be to compile two binaries, 'python' wh
> Sure, though it sounds quite similar to what they were mentioning with:
> "the creation of hermetic Python "binaries", with all necessary modules
> preloaded"
I wondered whethe this hermetic binary would also include the result of
JIT compilation - if so, it would go beyond freeze, and contain a
Reid Kleckner wrote:
> On Thu, Jan 21, 2010 at 4:34 PM, "Martin v. Löwis" wrote:
>>> How large is the LLVM shared library? One surprising data point is that the
>>> binary is much larger than some of the memory footprint measurements given
>>> in
>
> With my "downstream distributor of Python" hat on, I'm wondering if it
> would be feasible to replace the current precompiled .pyc/.pyo files in
> marshal format with .so/.dll files in platform-specific shared-library
> format, so that the pre-compiled versions of the stdlib could be
> memory-map
> Ok, I'm just using the wrong terminology. I'm aware that mbcs is used
> for filename encoding on Windows (right?).
Not anymore, no.
> The encoding I'm talking
> about is the encoding that Python uses to decode a file (or encode a
> string) when you do the following in Python 3:
>
> text =
> I'm not an expert here, but this is why we've tried to avoid exposing
> C++ functions into the public API. As long as the public API stays C,
> we only require that LLVM and Python are compiled with the same
> compiler, right?
Possibly not. You may end up loading two different C++ runtimes into
> But I believe they would be the same set of problems that PEP 384
> addresses for cross-version compatibility. Because the linker only sees
> the C symbols, it shouldn't be possible for the C++ specific parts of
> the runtimes to interfere with each other.
Unfortunately, on systems with a global
> It is provided as a separate tool (and often invoked by application
> installers) rather than allowing the native code to be distributed
> because the results can be system specific.
Actually, they have now changed the implementation: it is now a service
which will do the ngen compilation in bac
> This all begs the question: why is there a default? and why is the
> default a guess?
>
> I have to admit that I was completely oblivious to this potential
> pitfall, and mostly that's because in the most common case, I am working
> with ASCII files.
You answered your own question: it is this r
>> So for the limited case of text IO, Python 3.x now makes a guess.
>> However, this guess is not in the face of ambiguity: it is the
>> locale that the user (or his administrator) has selected,
>
> That is a mistaken assumption for many. I have never, that I know of,
> selected a locale on any o
> No, but it's most likely a wrong guess, since text files don't
> really have anything to do with what the user wants to see in
> a user interface.
That also depends on the operating system. On Windows, there is
a long tradition of encoding all text in the system code page.
All text editors on Wi
> However it is likely to be often wrong, and where the user's locale
> specifies an encoding like CP1252 then it will result in silent
> corruption rather than an immediate exception.
Why do you say that? Why do you think it will likely be often wrong?
Most likely, encoding text files with cp1252
> So what is your naive programmer supposed to expect
> when writing a cat program?
This may be a bit out of context - however, a simple cat program should
open files in binary, and be done.
(not sure whether the average naive programmer is able to grasp the
notion of binary IO and to oppose to t
> I concede that I have no better statistics on the matter than you do,
> but I think that's wishful thinking. It is quite common for "pure
> output" to be mixed with "echoed input", for example. Even if a file
> is converted to another format (eg, restructured text to LaTeX), it's
> very common
Subject: [ANN] Python 2.5.5 Release Candidate 2.
On behalf of the Python development team and the Python community, I'm
happy to announce the release candidate 2 of Python 2.5.5.
This is a source-only release that only includes security fixes. The
last full bug-fix release of Python 2.5 was Pytho
> Using any guessing based on the locale (which describes the codec used
> byt the user's console, but is completely uncorrelated to any particular
> file on the user's filesystem)
No, it's not just the encoding of the console. It is also the encoding
that text editors will use, in absence of a mo
> We really do need precise descriptions of the problems so we can avoid them.
One family of problems is platform lack of initializer support in the
object file format; any system with traditional a.out (or b.out) is
vulnerable (also, COFF is, IIRC).
The solution e.g. g++ came up with is to have
Floris Bruynooghe wrote:
> Since I was under the
> impression that the JIT/LLVM can't emit machine code for the platforms
> where these C++ problems would likely occur nothing would be lost.
AFAICT, LLVM doesn't support Itanium or HPPA, and apparently not POWER,
either (although they do support PP
>> a) main() is not compiled with g++: static objects get not constructed
>> b) code that gets linked into shared libraries (assuming the system
>> supports them) does not get its initializers invoked.
>> c) compilation of main() with a C++ compiler, but then linking with ld
>> results in an un
Nick Coghlan wrote:
> Jeffrey Yasskin wrote:
>> (b) could be a problem if we depend on LLVM as a shared library on one
>> of these platforms (and, of course, if LLVM's JIT supports these
>> systems at all). The obvious answers are: 1) --without-llvm on these
>> systems, 2) link statically on these
> This
> may not be a problem in the LLVM code base, but it is the typical
> problem that C++ devs run into with initialization of objects with
> static storage duration.
This *really* doesn't have to do anything with U-S, but I'd like to
point out that standard C++ has a very clear semantics in t
> Lists are indeed used *everywhere* and *vast* quantities, which is
> why optimizations on list operations are worthwhile to pursue.
Unfortunately, the proposed change is a pessimisation, not an
optimisation. We probably shouldn't discuss it further, at least not
until a PEP gets written by its p
> In my mind Python's lists should have the same performance
> characteristics as the paper list (or better).
I think you'll have to adjust your mind then. People have
proposed various data structures that *do* work efficiently as
paper lists. So if you want a paper list, use one of them, rather
t
This is a repost from a posting I sent last August. One of the issues
(the hg-eol extension) is largely resolved, so I'm only asking for
help on the other issue.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
d
> On Windows, would a C extension author be able to distribute a single
> binary (bdist_wininst/bdist_msi) which would be compatible with
> with-LLVM and without-LLVM builds of Python?
When PEP 384 gets implemented, you not only get that, but you will also
be able to use the same extension module
> I mean port it to py3k first and then backport it from trunk to 2.6 and
> from py3k to 3.1. If you want to wait then it's probably enough to add a
> note to the ticket and I'll fix it later.
I haven't followed this discussion, but I'd like to point out that the
only changes allowed for 2.6 are b
>> Linux distributions such as Ubuntu [2]_ and Debian [3]_ provide more
>> than one Python version at the same time to their users. For example,
>> Ubuntu 9.10 Karmic Koala can install Python 2.5, 2.6, and 3.1, with
>> Python 2.6 being the default.
>>
>> In order to ease the burden on operating sy
> Agreed this should be discussed in the PEP, but one obvious problem is
> the speed impact. Picking up a file from a subdirectory is going to
> introduce less overhead than unpacking it from a zipfile.
There is also the issue of race conditions with multiple simultaneous
accesses. The original fo
> By the way, the part that caused me the most confusion in the language
> in the PEP was the emphasized *and their dependencies*, as if a package
> having dependencies somehow turned the problem into a factorial explosion.
> But there seems to be nothing special, according to your explanation,
> a
> This would eliminate the read-time race condition but still
> potentially allow for a write-time race condition if locking isn't
> used. The benefit of this approach is that it is no less clear than
> pyc is today and doesn't result in n * versions_of_python pyc files.
> There is still the overhe
>> foo.pyr/
>> cpython-25.pyc
>> cpython-25U.pyc
>> cpython-27.pyc
>> cpython-27U.pyc
>> cpython-32.pyc
>> unladen-011.pyc
>> wpython-11.pyc
>
> +1. It should be quite easy to assign a new name every time the magic
> number is updated.
It would actually be possible to drop the magi
> Exactly. How would you define where the pyr folder goes? At the root
> of a package? What if I delete the __init__.py file there? Will the
> existing pyr folder be orphaned and a new one created in each
> subfolder? Unlike VCS working copies, the package / module / script
> hierarchy is not forma
> Not really -- much of the code I've seen that tries to guess the source
> file name from a __file__ value just does something like this:
>
>if fname.lower().endswith(('.pyc', '.pyo')): fname = fname[:-1]
>
> That's not compatible with using .pyr, either.
If a single pyc folder is used, I t
>I can also see advantages to allowing out of tree compiled cache
> directories. For example, you could have a locked down .py tree with
> .pycs going into per-user trees. This prevents another user from
> spoofing a .pyc I use as well as allowing users to install arbitrary
> versions of Python
> But I don't understand how this answers the question. If the
> python26-zope.sendmail package doesn't run setup.py, then a
> python-zope.sendmail package where you specify at install time which
> directory to install the files to isn't going to run setup.py, either.
> If the only difference betw
> 3. In each top level directory on sys.path, shadow file heirarchy
> Major Pro: trivial to separate out all cached files
> Major Con: ??? (I got nuthin')
The major con of this option (and option 2) is an ambiguity of where to
look for in case of packages. In particular for namespace packages
> Any help you could provide would be appreciated.
Please use unified diffs in the future.
I'm -0 on this patch; it still has the negative, cautionary-patronizing
tone ("Do not", "can be tricky", "be mindful"), as if readers are unable
to grasp the description that they just read (and indeed, in
> And I disagree this would be difficult as the PEP suggests given the
> proper file format. For zip files zipimport already has the read code
> in C; it just would require the code to write to a zip file. And as
> for the format I mentioned above, that's dead-simple to implement.
How do you write
Antoine Pitrou wrote:
> Jesse Noller gmail.com> writes:
>> I don't see the need for the change from fork as of yet (for
>> multiprocessing) and I am leery to change the internal implementation
>> and semantics right now, or anytime soon. I'd be interested in seeing
>> the patch, but if the concern
> The python I use (win32 2.6.2) does not complain if it cannot read
> from or write to a .pyc; and thus it handles multiple python processes
> trying to create .pyc files at the same time. Is the .zip case really
> any different? Since .pyc files are an optimization, it seems natural
> and correct
>> Instead, we should aim to make Python fork-safe. If the primary concern
>> is that locks get inherited, we should change the Python locks so that
>> they get auto-released on fork (unless otherwise specified on lock
>> creation). This may sound like an uphill battle, but if there was a
>> smart
> We must distinguish between locks owned by the thread which survived the
> fork(), and locks owned by other threads. I guess it's possible if we
> keep track of the thread id which acquired the lock, and if we give
> _whatever_after_fork() the thread id of the thread which initiated the
> fork()
> Le lundi 01 février 2010 à 23:58 +0100, "Martin v. Löwis" a écrit :
>> Interestingly, the POSIX pthread_atfork documentation defines how you
>> are supposed to do that: create an atfork handler set, and acquire all
>> mutexes in the prepare handler. Then fork
> Although I would be in favor of an atfork callback registration system
> (similar to atexit), it seems there is no way to solve the fork()
> problem automatically with this. Any attempt to acquire/release locks
> automatically will lead to deadlocks, as it is necessary to know the
> exact program
>> As an aside, I think this should be documented *somewhere* other than
>> just in import.c! I'd totally forgotten about it until I read the
>> source and almost missed it. Either it should be documented or it
>> should be ripped out.
>
> The -U option is already gone in 3.x.
Precisely my view
>> That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and
>> feasible to back port that to Python 2.6? I remember talking about this a
>> while back but I don't remember what we decided and I can't find a bug on the
>> issue.
>
> I don't know about feasible but I think it's (
> This patch is still waiting a review and backporting from trunk.
>
> http://mail.python.org/pipermail/python-dev/2009-October/092771.html
>
> Can we get it in?
Only if one of the Mac people checks it in. As they are *REALLY* scarce,
the answer is probably "no".
I'd offer a special version of
> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote:
>> Barry Warsaw python.org> writes:
>>> Python 3 uses the .py file for __file__ but I'd like to see a transition to
>>> __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM
>>> or
>>> whatever compilation cache artifact
Guido van Rossum wrote:
> On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan wrote:
>> On the issue of __file__, I'd suggesting not being too hasty in
>> deprecating that in favour of __source__. While I can see a lot of value
>> in having it point to the source file more often with a different
>> attr
Benjamin Peterson wrote:
> 2010/2/8 Dirkjan Ochtman :
>> On Sun, Feb 7, 2010 at 22:51, Benjamin Peterson wrote:
>>> Will you do test conversions of the sandbox projects, too?
>> Got any particular projects in mind?
>
> 2to3.
Does Mercurial even support merge tracking the way we are doing it for
> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608 Is it ok to release new
> versions that are known to crash?
As a general principle: yes, that's ok. We even distribute known
crashers with every release.
Regards,
Martin
___
> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>> that are known to crash?
>
> I've changed this issue to release blocker. What a
>>> I've changed this issue to release blocker. What are the other issues?
>> For a bug fix release, it should (IMO) be a release blocker *only* if
>> this is a regression in the branch or some recent bug fix release over
>> some earlier bug fix release.
>
> As far as I remember, I think we have h
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> IOW, I feel that release blockers should only be used if something
>> really bad would happen that can be prevented by not releasing. If
>> nothing actually gets worse by the release, the release shouldn'
> On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" wrote:
>>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>>> one - http://bugs.python.org/issue6
> If a committer or triage
> person sets an issue to release blocker it should mean that they think
> the release manager should make a decision about that issue before the
> next release. That decision may well be that it shouldn't be a blocker.
I think it's (slightly) worse. For the release man
> Why even keep 2to3 in the sandbox? It should be mature enough now to be
> maintained directly in the tree.
I think the original plan was to make standalone releases, so that
people could upgrade their installation from a newer release of 2to3.
IMO, it is realistic to predict that this will not
>> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis" wrote:
>>> IMO, it is realistic to predict that this will not actually happen. If
>>> we can agree to give up the 2to3 sandbox, we should incorporate
>>> find_pattern into the tree, and perhaps test.
> I personally like 2to3 in a separate repo because it fits well with my
> view that 2to3 is an extra application that happens to also be
> distributed with python.
But isn't that just a theoretical property? I know that's how 2to3
started, but who, other than the committers, actually accesses the
I recently set up a Mercurial hosting solution myself, and noticed that
there is no audit trail of who had been writing to the "master" clone.
There are commit messages, but they could be fake (even misleading to a
different committer).
The threat I'm concerned about is that of a stolen SSH key. I
> Mozilla's pushlog can be seen here:
>
> http://hg.mozilla.org/mozilla-central/pushloghtml
>
> And its code is avaliable here:
> http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip/pushlog-feed.py
>
> Dirkjan is its author, so I suppose he was already thinking about having a
> s
>> But isn't that just a theoretical property? I know that's how 2to3
>> started, but who, other than the committers, actually accesses the 2to3
>> repo?
>
> It's used in 3to2 for example.
That doesn't really seem to be the case. AFAICT, 3to2 is a hg
repository, with no inherent connection to the
> The other thing is that we will loose some vcs history and some
> history granularity by switching development to the trunk version,
> since just the svnmerged revisions will be converted.
I suppose it might be possible to fake the history of Lib/lib2to3 with
commits that didn't actually happen,
Benjamin Peterson wrote:
> 2010/2/13 Jake McGuire :
>> I have a local patch, but wanted to see if anyone had ideas or
>> experience weighing these tradeoffs.
>
> Interning is really only useful because it speeds up dictionary
> lookups for identifiers. A better idea would be to just attach the
> s
Georg Brandl wrote:
> Am 13.02.2010 13:19, schrieb Antoine Pitrou:
>> Martin v. Löwis v.loewis.de> writes:
>>> Alterntively, the email notification sent to python-checkins could could
>>> report who the pusher was.
>> This sounds reasonable, assuming it does
Starting around 14:00 UTC today, we will take the trackers at
bugs.python.org, bugs.jython.org, and psf.upfronthosting.co.za offline
for a system upgrade. The outage should not last longer than four hours
(probably much shorter).
Regards,
Martin
___
Pyth
Stefan Behnel wrote:
> Benjamin Peterson, 13.02.2010 03:52:
>> It's about time for another 3.1 bug fix release. I propose this schedule:
>>
>> March 6: Release Candidate (same day as 2.7a4)
>> March 20: 3.1.2 Final release
>
> Does a crash like #7173 qualify as a blocker for 3.1.2?
I'm not the r
>> That information is also
>> available from the system on Mac OS and Windows.
>
> It is not available on Windows in any reasonable and useable form.
That's not true. The registry is readable by any user, and the format is
fully documented.
Regards,
Martin
__
> It's time to comment and review.
Unfortunately, it's not. I strongly object to any substantial change to
the code base without explicit approval by Fredrik Lundh.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Antoine Pitrou wrote:
> Le Thu, 18 Feb 2010 22:46:41 +0100, Martin v. Löwis a écrit :
>>> It's time to comment and review.
>> Unfortunately, it's not. I strongly object to any substantial change to
>> the code base without explicit approval by Fredrik Lu
> My point is, as a matter of *policy*, nothing should be released that
> uses deprecated stuff. I can't create a bug report about wrong (or
> incomplete) policies.
Sure you can. Write a bug report asking that PEP 4 gets amended with
specific wording.
Not that PEP 4 is followed in practice at al
> We need someone to maintain the copy of ElementTree in the Python
> repository.
We have one: Fredrik Lundh.
> Ideally this means pulling upgrades and bugfixes from
> Fredrik's repository every now and then. If the goals of Python
> ElementTree and Fredrik ElementTree diverge I don't see a probl
> The last commits by Fredrik to ElementTree in Python SVN that I can
> see are dated 2006-08-16. The last commits I can see to ElementTree at
> http://svn.effbot.python-hosting.com/ are dated 2006-07-05.
And?
> To paraphrase Antoine's comment [1] on Rietveld -- we need a process
> that results i
> Actually this should not be a fork of the upstream library.
> The goal is to improve stability and predictability of the ElementTree
> implementations in the stdlib, and to fix some bugs.
> I thought that it is better to backport the fixes from upstream than to
> fix each bug separately in the st
> First of all the links are not a feature of the operating system but
> rather a feature of the file system (version).
That's not really true. Even though ext2 supports symbolic links, on XP
with an ext2 driver, you still don't get symbolic links.
So you need the feature *both* in the operating
> Maybe I am fully misunderstanding something here and I am also known for
> just bluntly stating things but:
>
> Isn't inclusion into the standard library under the assumption that
> maintenance will be performed on the code?
In general, that's the assumption, and Guido has stated that he dislik
Joe Amenta wrote:
> Hey folks,
>
> I'm going to write a PEP for inclusion of lib3to2 in the standard
> library for 3.2 and above. Before do, though, do people have any quick
> thoughts about it?
I do: it seems too early to me. Before it is added, I'd like a see a
significant success story of its
> Right. As Maciej asked about this, let's discuss it here: there are
> currently no emails for these repositories. I'd like to get that
> going; should I just have it send emails for each push to the normal
> commits mailing list for now?
I think sending them there "for now" is fine; in the long
>> The other thing is that we will loose some vcs history and some
>> history granularity by switching development to the trunk version,
>> since just the svnmerged revisions will be converted.
>
> So the consensus is that 2to3 should be pulled out of the main Python
> tree?
Not sure what you me
>>> Should the 2to3 hg repository be deleted, then?
>> Which one? To my knowledge, there is no official 2to3 repository yet.
>> When the switchover happens, 2to3 should not be converted to its own hg
>> repository, yes.
>
> This one: http://hg.python.org/2to3
Ah, this shouldn't be used at all for
> Sorry, I meant "pull from". I want an updated snapshot of 2to3 for the
> benchmark suite, and I'm looking for the best place to grab it from.
The 2to3 code currently still lives in the subversion sandbox.
Regards,
Martin
___
Python-Dev mailing list
Py
Dirkjan Ochtman wrote:
> On Mon, Feb 22, 2010 at 16:06, "Martin v. Löwis" wrote:
>> I think sending them there "for now" is fine; in the long term, I
>> propose to add an X-hgrepo header to the messages so that people can
>> filter on that if they want to.
> On Tue, Feb 23, 2010 at 00:55, "Martin v. Löwis" wrote:
>> Ah, this shouldn't be used at all for anything (except for studying how
>> Mercurial works). Along with the cpython repository, it is Dirkjan's
>> test conversion. Even if it survived the ultim
Doug Hellmann wrote:
> We've recently run into an issue with subprocess on Solaris, as
> described (by an earlier reporter) in issue #7242. The patch there
> solves our problem, and has been verified to work by other users as
> well. What's the status of the ticket? Is there anything I can do to
Doug Hellmann wrote:
>
> On Feb 25, 2010, at 2:34 PM, Martin v. Löwis wrote:
>
>> Doug Hellmann wrote:
>>> We've recently run into an issue with subprocess on Solaris, as
>>> described (by an earlier reporter) in issue #7242. The patch there
>>> so
I don't recall whether we have already decided about continued support
for Windows 2000.
If not, I'd like to propose that we phase out that support: the Windows
2.7 installer should display a warning; 3.2 will stop supporting Windows
2000.
Opinions?
Regards,
Martin
__
>> If not, I'd like to propose that we phase out that support: the Windows
>> 2.7 installer should display a warning; 3.2 will stop supporting Windows
>> 2000.
>
>Is there any reason for this? I can understand dropping Windows 9x
> due to the lack of Unicode support but is there anything missi
Neil Hodgson wrote:
> Martin v. Löwis:
>
>> See http://bugs.python.org/issue6926
>>
>> The SDK currently hides symbolic constants from us that people are
>> asking for.
>
>Setting the version to 0x501 (XP) doesn't actively try to stop
> runnin
> It seems someone has decided that code.python.org doesn't resolve
> anymore.
Correct - I deleted the DNS record, and the site, as it didn't work
anymore (and because Barry confirmed that it is ok to delete the site)
> This is annoying since there were Mercurial mirrors there
> ( at http://code.
> It seems someone has decided that code.python.org doesn't resolve
> anymore.
I have now restored it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
Johan Harjano ran into an interesting problem when trying to run the
Django test suite under Python 3.1.
Django has doctests of the form
>>> a6.headline
u'Default headline'
Even when converting the doctest with 2to3, the expected output is
unmodified. However, in 3.x, the expected output will ch
Andrew Bennetts wrote:
> "Martin v. Löwis" wrote:
> [...]
>> Any proposal appreciated.
>
> I propose screaming “help me, I have written a test suite using nothing
> but string matching assertions, what is wrong with me?!”
> The issue shows (yet again) a general problem with doctests being
> overspecified -- the test shouldn't care that the output starts with
> 'u', it should only care that the value is unicode, but there's no
> easy way to express this in doctests. But since these doctests exist I
> suggest that the
> 1.) I assume the Grammar/grammar is read top to bottom. Confirm?
Confirm - but this is not surprising: *any* source file is typically
read from top to bottom. Randoma access reading is typically done for
binary files, only.
So you must be asking something else, but I can't guess what that mig
901 - 1000 of 5277 matches
Mail list logo
