> The change to universal binaries, perhaps?
That shouldn't really matter - the machine code should still be the
same, and it should all get loaded at program startup. IOW, startup
and imports may get slower, but otherwise, it should have no impact.
Regards
> I haven't yet tried posting a query to a FreeBSD list, as it could simply
> be a bug on amd64, but I was wondering whether there was anything (other
> than deactivating tests and documenting use of ulimit -v on this
> platform) that could be done to work around this behaviour.
I think it should
the physical memory.
It might be useful to have an interpreter-maintained limit on the amount
of memory Python can consume, but such a feature is clearly out of scope
for the current state of the code.
Regards,
Martin
___
Python-Dev mailing list
Python-
calls
to memory allocators are channeled through Python API, which could be
diverted on source level also.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
find
failures to properly check for NULL results much better than
stress-testing.
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/pyth
The first major heading in that file reads
"What's New in Python 2.6 release candidate 2?"
> Am I missing something?
Perhaps reading the file that was linked might have helped.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@
> >> http://www.python.org/download/releases/2.6/NEWS.txt
> >>
> >> Seems a bit mislabelled if nothing else.
>
> Martin> How so? The first major heading in that file reads
>
> Seems more like the Misc/NEWS file to me.
Correct.
>
ould still be hesitant to run this test by default - 30s
is too long, IMO. It is unlikely that regular changes to Python break
any of these tests, and if they do, the buildbots will tell. Anybody
changing the bsddb library itself will know to run the full test suite.
Re
k gets released elsewhere quickly. On OSX, for whatever
reason, that assumption might be false, so the timeout eventually
occurs, along with retries and whatnot.
Of course, that's just a theory - one would have to debug the test suite
to find out what's really going on.
should also
be a copy of the documentation online, at
http://www.python.org/doc/2.6/
http://www.python.org/doc/3.0/
In addition, some documentation set should show up at
http://docs.python.org/
Not sure whether this should be 2.6 or 3.0.
Regards,
Martin
__
> What is your opinion, and who should decide?
Please don't post patches to the mailing list. Post them exclusively
to bugs.python.org instead.
Also, don't post unrelated patches in a single message. Create separate
issues in the bug tracker for them.
Re
needed.
If that understanding is incorrect, it may be because it broke over
time, or it may be that my understanding was incorrect to begin with.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
sion 3. We can discuss that when I have
> actual patches.
I guess none of your changes are suitable for 2.5 (as they probably
constitute new features). You should really target trunk (i.e. 2.7) when
you produce patches.
Regards,
Martin
___
Python-
changes
are might have impact on the earlier changes (which I had
already accepted).
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
devices have
> different SDKs and each configuration/SDK/CPU is another entry in that file.
> Further, the SDKs or devices differ in what they support, the platform CE as
> such doesn't exist.
Hmm. And you *can* provide an SCons file that supports all the SDKs?
Regards,
Martin
___
olution (IMO) should be to change
the system (leaving open the question whether or not Python should
be also changed to work with such broken systems).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
the problem will have to come up with his/her own solution.
This is quite in the abstract. Can you be more specific?
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
Ulrich Eckhardt wrote:
>>> Well, currently it does make a difference. Simple example: CreateFile().
>> It's not so simple: Python doesn't actually call CreateFile
>
> Martin, CreateFile() was just used as an example. You can substitute it with
> LoadString() o
s fairly easily,
even in 2-byte mode (through UTF-16).
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
uld contribute code that normalizes file
names appropriately on systems that require such normalization.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
r 3.1
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
-8b / PUA hacks?
Not sure what "it" is: to write the code above using the PUA hack:
for filename in os.listdir(os.getcwd())
text = repr(filename)
print("=== File {0} ===".format(text))
for line in open(filenmae):
...
> Change the default file system encoding to store bytes in Unicode is like
> introducing a new Python type: .
Exactly. Seems like the best solution to me, despite your polemics.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.or
Guido van Rossum wrote:
> On Mon, Sep 29, 2008 at 11:00 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> Change the default file system encoding to store bytes in Unicode is like
>>> introducing a new Python type: .
>> Exactly. Seems like the
n to introduce a new data type in the strict sense - merely
to pass through undecodable bytes through the regular Unicode type.
So the result of adding them is a regular Unicode string.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:
;PATH"]). And so on (passwd/group file,
Tkinter, ...)
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
ot;mbcs")
encoding; this is inside the system DLLs.
CP_ACP is a lossy encoding (from Unicode to bytes): Microsoft uses
replacement characters if they can, starting with similarly-looking
characters, and falling back to question marks.
Regards,
Martin
___
might give you a list of file names
which you then can't open/stat/recurse into.
(of course, you could use UTF-8 as the file system encoding on Windows,
but then you will have to rewrite a lot of C code first)
Regards,
Martin
___
Python-Dev mailin
rted later. Unix missed the opportunity
of declaring that all file APIs are UTF-8 (except for Plan-9 and OS X,
neither being "true" Unix).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
hat would its listFiles() method do with
> undecodable filenames?
Apparently (JDK 1.5.0_16, on Linux), it decodes undecodable bytes/byte
sequences as U+FFFD (REPLACEMENT CHARACTER). Opening such a file will
fail with FileNotFoundException.
IOW, Java hasn't solved the problem in the last
r bad designs in other places, but this one really
gives a good tradeoff of all issues, all things considered).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
thon side (i.e. can they
> both be returned from listdir() and passed to open())?
Certainly!
> CIf I compare
> these two filenames, do they compare differently?
Certainly!
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://
s, it won't be easy to display such
file names on stdout, or in a GUI window.
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
> However, Martin, I can promise you that I will _never_ ask for any
> convenience functions related to bytes as a result of this decision.
:-)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
"unformatted" IO) deal
just fine with embedded NULL characters.
> * Java doesn't support unicode > 0x (bouuuuh!)
I don't think that is true anymore.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
htt
estion.
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
> Why not use versioned URLs, but with a link at the top of old pages
> saying they're outdated, linking to the new version. Either way they
> should update their links, but this way you don't shoot them in the
> foot to do it.
Wouldn't that require changes to the
em, right?
(of course, somebody could go over it from time to time and block
everything older than a month that was still available, just to prevent
accidental merging)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
> shouldn't we use a suitable gcc option for the buildbots to prevent that
> from happening?
Which one specifically?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
hat needs backporting. Tracking what still
needs merging should happen in the bug tracker, by leaving the report
open until merging has been done. Every change that isn't immediately
merged and doesn't have an open issue just won't get merged
to regenerate them, and still expect the output to be the
same. Also, I don't think the generator supports templating in the
way you might expect it to. To be specific, it's latex2html.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@p
-Werror" to the standard build
> target. However a new build target with extra checks should help to
> detect errors much sooner.
That would need to go along with a policy that Python must never cause
GCC to emit any warnings.
Regards,
Martin
en
if only for security patches).
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
aces.
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
version numbers...
Can you propose a spec?
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
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>>> This may be more complicated than it sounds, because you'd probably
>>> add a very general requirement-indicating feature to PyPI, not merely
>>> a 'supports 3.0' Boolean on each
talk too many people into porting, since
there will be some glitches which need to be resolved, and may not get
resolved before 3.2 or so. So people with a natural wariness are advised
to trust this wariness, or else all their concerns become
self-fulfilling prophecies.
Regards,
Martin
mine whether a package works with Python 3.
> the metadata of a package should provide this information imho.
Well, the classifiers *are* part of the metadata of the package.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
so maybe the same version number should be used? That
> is should there be?
It all depends on how you do the porting. If all it takes to run the
program through 2to3 to make it port correctly, I recommend to use
the build_py_2to3 build step of distutils in 3.0. Then the same source
can be in
ckages that do support both versions need
to register twice, upload twice, etc.
In any case, if that route is chosen, we have to adjust distutils
before the 3.0 release is made.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
ly that they
come up with things like
foobar_py3-1.0.tar.gz
and register a second project foobar_py3 in PyPI.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
> Why does "key in wc_status_kind_wc" work when I use an object returned
> by keys() by not when I use pysvn.wc_status_kind.unversioned?
This is too little detail to come up with an explanation. Do your
objects support __eq__.
e would be a release candidate, and
two weeks, the final release.
Simultaneously, I would also release 2.4.6.
If people think 2.5.2 should be released earlier than that, please
let me know.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
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
d when he will complete),
I see little chance that that any additional backporting will happen.
I will send an announcement asking people to propose missing backports.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
of
particular interest.
Regards,
Martin
[1] http://svn.python.org/projects/python/branches/release25-maint/
[2] http://bugs.python.org/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
- There's no os.environb for bytewise access to the environment. Seems
> important.
Not to me. I don't have environment variables with non-ASCII characters
in them, and I think few other people do.
> I'm sure there's even more APIs dealing with pathnames, command li
7;m not really in a position to
> help with the above for that period...)
But please do file bug reports, preferably along with any patches to
distutils that you already have.
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
last 2.5.x release in particular, we
will strictly enforce the "no new features" policy; users interested
in new features should switch to 2.6.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
argv and environ: are you suggesting that the behavior described
in the PEP is desirable? I don't think it is (but I don't think it
should change for 3.0, either, only for 3.1)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
James Y Knight wrote:
> or at least fully recognized and documented as a half-baked
> solution.
I would prefer that, leaving a full resolution to 3.1 (or perhaps 3.2).
If we wait long enough, the issue will disappear (a strategy that Sun
is apparently taking for Java :-)
Regards,
ink of. (Hence Martin's
>> question, I presume). I have no idea, however, how porting could make
>> that happen.
>>
>
> I see no reply from Martin. What was his question?
Whether __eq__ was implemented for the specific type (and whether
that implement
ain
> to cut releases 3 weeks in a row?
It's a lot of effort, yes. Also for users, who will have barely
installed one release candidate when the next one comes out.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
really need to implement tp_richcompare.
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
k into this before the next release
candidate.
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
ind some time next week to look into this, but I
wouldn't mind if anybody else did.
In any case, thanks for this research so far (and too bad that nobody
noticed throughout all the beta releases).
Regards,
Martin
___
Python-Dev mailing
[switching to python-dev]
Georg Brandl wrote:
> Martin v. Löwis schrieb:
>> Raymond Hettinger wrote:
>>>> Merges should be handled by the original committer.
>>> Respectfully disagree. Some people here having been taking
>>> responsibility for keepin
help
> to understand the motivation of each backport.
Yes, that is unfortunate.
I'm skeptical that new tests actually need backporting at all. Python
doesn't really get better by new tests being added to an old branch.
Near-term, it might get worse because th
t rather
> latent bugs newly detected, and (presumably) as "wont-fix".
No such way exists, hence they can't be labeled that way.
No such labeling can be added, since that would be a new feature.
Regards,
Martin
___
Python-Dev mailing list
P
x27;t want to state a policy about whether new tests
should or should not get added to maintenance branches. I'd leave this
up to the committers, and just wanted to caution about this risk.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@py
Andrew Bennetts wrote:
> "Martin v. Löwis" wrote:
> [...]
>> There is a certain prevention already that later maintenance fixes don't
>> break the earlier ones: those fixes typically get checked into the trunk
>> also, where the tests do exist. So the comm
ions from that other than Python is apparently
broken, and that they therefore shouldn't use it - even if the test
that fails is in a module that they likely never use.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
t before: I don't have any plans to look through
change lists myself. If people want certain changes considered, they
will tell us; if nobody is interested in a certain backport, there is
no need to backport.
Regards,
Martin
___
Python-Dev mailing
eady
includes a manifest, as do all the pyd files)?
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
the issue-tracker
No, see above.
Regards,
Martin
P.S. It's too bad that nobody noticed this in all these alpha and beta
releases.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
o 2.5.2.
It has the possibility of breaking compilation; such patches are
unacceptable. See my comments for details.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
> Since we tripped over these with Trac/Genshi we would appreciate if the
> following could be applied (if not already):
Ok, I've marked them as candidates for a backport.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
> I don't see a downside and can see how it would help with private
> assemblies.
>
> [I've also added a comment to this effect to the bug]
Thanks! I'll go ahead and accept this, then.
Regards,
Martin
___
Python-Dev mailing
who think this is good to apply, which I can add myself
> to).
The "developer" role has more user interface. I've just given it to you.
> Hmm, I've spent more time on this than I should have, and it's gone
> way off topic. Is there anywhere better to discuss it?
There
the tarfile module).
If a committer agrees to restrict himself to a certain area,
he will usually keep that promise, so there isn't really any
need for a finer-grained access control, IMO.
Regards,
Martin
___
Python-Dev mailing list
Python-De
has been working that way fine for the last few years. The
public record if it is in Misc/developers.txt (although that file might
be slightly incomplete/incorrect).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
> AFAICS there are no buildbots for the release26-maint branch.
That's correct. I'm waiting to create them until after we retire the
2.5 ones.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
Benjamin Peterson wrote:
> On Thu, Oct 30, 2008 at 3:38 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> AFAICS there are no buildbots for the release26-maint branch.
>> That's correct. I'm waiting to create them until after we retire the
>>
are still worried: buildbot has a "try" feature, where developers
can try out changes on the slaves before committing them. This isn't
currently activated in the Python buildbot - but if you need it, we
could look into it (if you are curious, just exp
> By the way, it seems that this python-checkins mailing list did not
> archive the recent commits:
> http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end
> I miss them... Can someone fix it?
Which ones are you missing specifically?
Reg
> I haven't seen any of the ones today.
OK, I've respooled them.
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/a
>> Yet another hint at the evil force-Bazaar-upon-them conspiracy .
>
> I'm not so sure Bazaar isn't it's own victim :)
I have now restored the original URL structure, and moved the loggerhead
installation to
http://code.python.org/l
t figure out how to activate
that.
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
ic/images/ico_folder.gif
I'll leave these to Barry; the loggerhead installation is still not
complete (so it's not yet an official service).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
ting the stage
> using
> the same rules (using the keywords and status)?
Most certainly. See the scripts directory of the python-dev instance for
examples.
Regards,
Martin
P.S. These things might better belong to tracker-discuss.
___
Python-Dev
problem. Cython imports
a number of builtin modules - if they are written in Cython, we have
the bootstrapping problem.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
>> (No big deal
>> though). More importantly, there seem to be no images, e.g.:
>
>>http://code.python.org/static/images/ico_folder.gif
>
>> Looks like it should be
>
>>http://code.python.org/loggerhead/static/images/ico_folder.gif
>
> I t
s, the GMP binaries would be incorporated into pythonxy.dll.
This would force anybody providing a copy of pythonxy.dll to also
provide the sources of GMP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
stems
(regardless of how inefficient it might be on minor platforms).
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
> Martin> On Windows, the GMP binaries would be incorporated into
> Martin> pythonxy.dll. This would force anybody providing a copy of
> Martin> pythonxy.dll to also provide the sources of GMP.
>
> As I understand it the proposal was to allow people to subst
[EMAIL PROTECTED] wrote:
> >> OTOH, it should be no big deal to drop a zip archive of the GMP
> >> sources which correspond to the code bound into the DLL.
>
> Martin> How would end users then extract the sources from the DLL? How
> Martin> wou
compiler. However, if speed matters then it's hard to beat
> Cython even with hand-written C code.
I would personally prefer a Cython integration over a ctypes one, for
the standard library (and supported inclusion of ctypes into Python
regardless).
Regards,
Martin
__
st won't accept having to download gmp.dll from elsewhere (they
may not even know what Python is). So then you have to include the
source (of GMP, not Python). The L is really only about "include source
just from the library (gmp), not the application (Python)".
Regards,
Martin
__
about
> what.
I find it fairly easy to use "svn annotate" to learn about the source
of an XXX comment. In many cases, the XXX comment is fairly obvious,
anyway, so knowing who added it, and when, doesn't provide much useful
information.
Regards,
Martin
___
hat the relative path
doesn't, by accident, refer to the root directory?
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
3701 - 3800 of 5764 matches
Mail list logo
