you want to see how it fares on the various systems which we have
build slaves for, feel free to create a branch, and then manually
ask the slaves to build branches/yourbranch.
Or, just commit it into the trunk, and see how it does.
Regards,
Martin
___
P
ngs. So he seems to be
> navigating this particular minefield pretty well so far.
Yes, I'm also quite grateful for the contributions I have received from
Daniel. I hope he'll stay around for some time without exhausting.
Regards,
Martin
___
Python-Dev
mand
line).
Of course, such a project might better be mentored at subversion than
Python.
Regards,
Martin
P.S. I don't believe your claim that it forgot changesets. Could it be
that it simply forgot adding files, and that it did so because you
already had the files in the sandbox, so tha
made the life worse for Debian
package maintainers, at least initially - i.e. for a few years).
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
s the to-be-merged changes directly
conflict. Just svn-update, then try committing again.
It's actually also possible to recover from overlapping merges also:
just re-run svnmerge with --record-only (-M); this assumes nobody else
has merged the very same changes concurrently.
Regards,
Martin
he student's application to get in
contact with a potential mentor, and we could prioritize porting
projects assuming the package authors indicate sufficient intent to
accept the results of the porting.
Regards,
Martin
___
Python-Dev mailing list
Pytho
r 3.x version if it comes with the
> blessings of Fredrik, i.e. if I were you I'd try pushing this with
> Fredrik.
I don't think a GSoC project can possibly help with that.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
nt.
>
>
> It's the latter; it's "pending feedback".
Which "latter" (there seem to be multiple pairs in Tennessee's message)?
In any case, it's not really "pending feedback". Instead, it means "if
there is no feedback really soon
>
> It should probably be replaced with Brett's document.
>
>
> I say replace as well.
Will then dev/workflow be removed? I don't think we need two
copies (possibly inconsistent)? So if dev/workflow stays,
PEP 3 should be withdrawn.
Regards,
Martin
___
develop applications myself, and had only once in ten years
the desire to package everything in a stand-alone way, and then ended
up using freeze. I'm genuinely curious what the scenarios are where
people desire such packaging - I did hear the desire often, but ne
ging
solution can help here in any way.
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
everything.
The Windows story is indeed sad, as none of the Windows packaging
formats provides support for dependencies (MSI has some support,
but as far as I understand it, it's pretty useless). But yes, for
Windows, you want .exe or .msi installers, not something proprietary.
Regards,
Martin
_
ue
usually, since the mess will live on the web servers, and not on
everybody's end user machine.
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
should never conclude with "I don't
know"; this would be time-wasting.
If, for a bug, the reviewer disagrees that it would be a bug if the
behavior actually exists, then the issue should be closed (resolution
not-a-bug/invalid). If the reviewer ag
> There was a discussion about this on the py3k mailing list back in
> mid-2007 ("buildbots" thread) and perhaps later as well, at which
> point I believe Martin added an "-n" option to regrtest and the
> buildbot test.bat file to disable the assertions. Is that
pyqtshell/> become good
> IDLE alternative.
Could well be. To see it integrated into Python (and perhaps replace
IDLE), a lot of steps would need to happen, though. But perhaps you
weren't asking for it to be included in Python - it can also be a good
alternati
ody has explicitly
requested such an assignment, or unless he gave blank permission to
be assigned certain kinds of issues.
> Hmm. Maybe I should write a short "guide to performing triage" and
> post it for feedback.
That can't hurt. Different people make different e
p unless it gets issues to be
resolved, eventually. In the specific case: if the bug has already been
confirmed, there is nothing else to be done for the review.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
entation requirement.
Right - plus, distutils also supports creating MSIs.
> How were Mike's packages fundamentally
> different than that?
Dunno.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
n, though.
However, I would still be unhappy if Python on Windows would pop up
might pop up windows in cases where you get a proper exception on Unix.
So I'd rather see these bugs fixed instead of silencing them.
Regards,
Martin
___
Python-Dev mailing l
ils.mk fragment)
In that sense, distutils is for Python what make is for C.
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/pytho
as no conclusion of how specifically that functionality should
be offered; several people agreed that Python should mandate a standard
format, which it is then able to compare. So you might not be able to
spell it "10.3.40-beta", but perhaps "10.3.40b1" or "1
is (assuming
it gets contributed), but *independently* I think a specfication
is needed what version strings it actually understands. Such
specification must precede the actual implementation (in distutils).
Regards,
Martin
___
Python-Dev mailing list
Python
inst
works fine on Linux, and I'm skeptical that Linux users would have easy
access to it if it became part of py2exe.
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
proof of concept
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
PEP 345 introduces "Requires" and "Provides" wich are
are implemented in Distutils and PyP, but are not
widely used. 40 out of +4000 if I remember correctly. Martin will
correct me here if I am wrong.
Here are the actual numbers of packages that had a certain spec
ink this is the same rationale for debian packages. Right now people tend
to use external tools like stdeb and they are OK with it (but still
gets problems extracting stuff out of Python packages at this point)
Explicit is better than implicit: What is your list of problem
x27;t *provide* them...
So that making a
FHS compliant package would be as simple as
python setup.py distutils --datadir=bla --htmldir=foo
What's the meaning of the distutils command?
Regards,
Martin
___
Python-Dev mailing list
P
t; it was removed by an unintentional merge
from the trunk.
Notice, however, that the feature was never present in the trunk.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
I propose the following PEP for inclusion to Python 3.1.
Please comment.
Regards,
Martin
Abstract
Namespace packages are a mechanism for splitting a single Python
package across multiple directories on disk. In current Python
versions, an algorithm to compute the packages __path__ must
zled how
easily you judge a the performance impact of a patch without having
seen any benchmarks. If I have learned anything about performance, it
is this: never guess the performance aspects of code without
benchmarking.
Regards,
Martin
___
ng them around in
>> the Modules/ directory.
>
> Welcome back!
>
> I have no particular opinion on this. I suggest waiting for Benjamin's advice
> and following it :-)
I would suggest to leave it as is:
a) never change a ru
x27;foo' and Element('foo') are different
things, you should not implement __eq__ in a way that they are
considered equal.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
.
Thanks for the feedback,
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
Chris Withers wrote:
> Martin v. Löwis wrote:
>> I propose the following PEP for inclusion to Python 3.1.
>> Please comment.
>
> Would this support the following case:
>
> I have a package called mortar, which defines useful stuff:
>
> from mortar impor
t have access to a list
> of files in a package directory, but is well capable for the checking
> the existence of a file.
Do you have a specific mechanism in mind?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
kg was found, nor an __init__.py, it proceeds with the next
sys.path item (skipping the directory entirely)
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
lections.namedtuple is also implemented using exec.
Ah, but it uses "exec ... in ...". That is much safer than an
unqualified exec (where the issue is what namespace it executes in,
and, consequentially, what early binding is possible).
The patch bans only unq
endorsed,
though. In that sense, it feels very much like easy_install (which also
does dependencies).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
> I think Benjamin is right. While most of the C source is indeed
> exactly one level below the root, there's plenty of code that isn't,
> e.g. _ctypes, cjkcodecs, expat, _multiprocessing, zlib. And even
> Objects/stringlib.
It's fine
re found with the demo installation.
I would personally remove all non-mercurial stuff out of PEP 374,
and retitle it, but that would be your choice.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
d on this? Is there an open bug tracker issue with more
> information? Who's working on this?
For Python 2.5.4, no further changes will be made. If you can reproduce
with 2.6, and can't find a tracker issue, make a new report.
Regards,
Martin
___
he PEP - putting it in a wiki page would
also allow referring to it.
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
se.py script.
>
> There is probably some other things that I missed
Here are some:
- integrate with the buildbot
- come up with a strategy for /external (also relevant for
the buildbot slaves)
- decide what to do with the bzr mirrors
Regards,
Martin
_
y, we could
> simply a new Mercurial repository and copy the content of /external in
> it.
>> - decide what to do with the bzr mirrors
>>
>
> I don't see much benefits to keep them.
Both should go into the PEP.
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
le, Sphinx dependencies to build the docs
> reside their. A simple script that downloads a tarball and extracts it
> seems more elegant.
Such a script would, in particular, also have to work on the Windows
buildbot slaves. /external is primarily used for the Window build.
Regards,
Martin
lexandre has also volunteered, you two need to decide who is
in charge. Whoever does that will certainly get access to
code.python.org; the demo installation should run on that machine.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
Dirkjan Ochtman wrote:
> On 05/04/2009 11:06, "Martin v. Löwis" wrote:
>> In particular, the Stackless people have requested that they move along
>> with what core Python does, so their code should also be converted.
>
> I'd be interested to hear if they w
ps the standard library, than extracting it from the source.
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 of the web site) is served
# from index.html, and provides links to the Waterfall as well as the
# other pages.
In the 0.7.9 release notes, it says
# The html.Waterfall status target was replaced by html.WebStatus in
# 0.7.6, and will be removed by 0.8.0.
But then, I have not tried in
ciated with svn).
The PEP should then explain what the authorized_keys lines should
look like; this allows people to review the security of the setup.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
ssh-key <-> logname.
> In any case, some web
> interface to facilitate setting up new clones (branches) is also
> something that's probably desirable. I think Mozilla has some tooling
> for that which we might be able to start off of.
How to authenticate in that interfac
hon.org's admins are with this idea.
If it's the same as the current subversion access, it's fine. Otherwise,
it needs discussion.
> We could still enable pushing through http(s) for hgweb(dir).
But that would require to hand out (and manage) passwords, right?
Martin
___
at will be easy. Would be good to enable compression
> on the SSH, though, if that's not already done.
Where is that configured?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
a repo or imported
> via hg import?
Not sure. What is the recommendation?
Ideally, we would have a contributor agreement on file of any, well,
contributor.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
Nick Coghlan wrote:
> Dirkjan Ochtman wrote:
>> I have a stab at an author map at http://dirkjan.ochtman.nl/author-map.
>> Could use some review, but it seems like a good start.
>
> Martin may be able to provide a better list of names based on the
> checkin name<->
ild of that branch just on that specific slave (use
branches/ in the input field). When doing so, feel free to cancel
any automated build that is currently running; make sure to use your
real name in the UI so we know it's not spam.
Regards,
Martin
__
e;
> people from Indonesian, Burmese and Malaysian cultures often only use a
> single name.
That's why asking for a policy. We have to have *some* way of
identifying where a certain change originated from. I'm sure
there is solution, and it doesn't matter to me whether I need
mercurial checkout that gets these things right
(perhaps a Mercurial branch in itself?). Subversion-specific code
is both in configure.in, Makefile.pre.in, and PCbuild/make_buildinfo.c
(not sure whether that would still be needed).
Regards,
Martin
> Such a policy would then translate to a dead end for Python 2.x
> based applications.
2.x based applications *are* in a dead end, with the only exit
being portage to 3.x.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.or
ementation? I'm impressed. And
> by impressed I mean frightened.
Well, Mark is the guy who deals with floating point numbers for fun.
*That* should frighten you :-)
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
that he can parse directly out of byte strings, and marshal
into them (which is important, as you typically receive them over the
wire). Having to run them through a codec slows parsing down.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
as a project under the Python Software
> Foundation, intends to follow the same policy as CPython.
Please keep pushing. From this message alone, I find two questions
to the lawyer, and one (possibly two) feature requests for the bug
tracker.
Regards,
Martin
_
ython in the first place.
I can understand that you don't want to spend much time on it. How
about removing it from 3.1? We could re-add it when long-term support
becomes more likely.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
content-transfer-encoding: 8bit, I think there is just
no way to represent email as text. You have to accept conversion to,
say, base64 (or quoted-unreadable) when converting an email message to
text.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev
ly)
384kiB. It then grows, requiring 1536kiB. Whether or not having 22k
interned strings is "typical", I still don't know.
Wrt. your proposed change, I would be worried about maintainability,
in particular if it would copy parts of the set implementation.
Regards,
Martin
import gc
ed by not having to waste time with a module
that doesn't quite work, or may change.
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
because startup overhead
> for us is almost 400ms to 'do nothing', which is a lot for a command
> line app.
Maybe I misunderstand your proposed change: how could the representation
of the interning dict possibly change the runtime of interni
reasonable. (but then, I also stand by my view that we
shouldn't proceed without Bob's approval).
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
#x27;t a very
> interesting problem for me to solve.
And I didn't expect you to - it seems people are quite willing to do
the actual work, as long as there is some guidance.
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
l measurements. Too many effects come together, so the actual
performance is difficult to predict (and, for that prediction, you
would need *at least* a work load that you want to measure - starting
bzr would be such a workload, of course).
Regards,
Martin
rather than bytes.
I don't think this can be approached from a theoretical point of view.
Instead, what matters is how users want to use it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
I to accept or produce bytes in any language that provides a
> Unicode string type.
So how do you integrate the encoding detection that the RFC suggests
to be done?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
uld be answered by verifying how people use
the json library in 2.x.
> The standard does not specify any correspondence between representations
> and domain objects
And that is not the issue at all; nobody is debating what output the
parsing should produce.
Regards,
Martin
, 1)), "em") == 0;
> if (!res && !PyErr_Occurred())
> err_string("operador de comparação desconhecido");
> }
> return (res);
> }
>
Notice that Python source is represented in UTF-8 in the parser.
It might be that the C sour
call a suggestion that
> using bytes would be significantly faster.
Not sure whether it would be *significantly* faster, but yes, Bob wrote
an accelerator for parsing out of a byte string to make it really fast;
IIRC, he claims that it is faster than p
g a PEP
(whose acceptance then might not happen within a summer).
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
ually works by then). Decision to accept it or not as a SoC project
is independent, but if accepted, the student should well understand
the outcome of this discussion.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
e imho.
I completely agree that this is a useful functionality to have, and I
also agree it *eventually* belongs into the standard library.
I just don't like the idea of bypassing the proper process by making
it part of distutils. This model (I need it, so I add it) made both
distutils and setuptoo
stutils, and likely, people will start using the distutils
implementation as if it were official API). Also, if you want it
pluggable, you likely come up with *another* ad-hoc plugin system.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyt
sufficient for most cases. For
committers, we should continue to require contributor forms.
Contributor forms can be electronic, but they need to name the
parties, include a signature (including electronic), and include
a company contribution agreement as necessary.
Regards,
Martin
P.S. I'm sure
ript library.
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
of them is more appropriate, if, what you want,
is bytes. I argue that the second form is better, since it saves you
an encode invocation.
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
e applications
might be where they want it. Perhaps they misunderstand something
when they think they want it.
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
#endif
Earlier versions included that ifdef block directly in pyconfig.h.in.
In case it isn't clear how this works: GCC predefines __BIG_ENDIAN__
on PPC but not on x86; for universal binaries, two (or more) separate
preprocessor (and compile
> If this approach is sane, could it be adopted for all other instances of
> endianness detection in the py3k code base?
Don't worry - the approach that we already take is already sane, so no
further changes are needed.
Regards,
Martin
___
that
the installation should also provide a python3 symlink.
I don't recall the agreement wrt. to the names of executables on
Windows.
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
> Although I guess choosing a file association for .py files becomes
> rather more interesting...
Indeed. We could register a py3 extension (and py3w? pyw3?),
but then .py might remain associated with python3, even though
people want it associated with py
I'm proposing the following PEP for inclusion into Python 3.1.
Please comment.
Regards,
Martin
PEP: 383
Title: Non-decodable Bytes in System Character Interfaces
Version: $Revision: 71793 $
Last-Modified: $Date: 2009-04-22 08:42:06 +0200 (Mi, 22. Apr 2009) $
Author: Martin v. Löwis
S
PI to non-decodable bytes, this interface
>> has the limitation that chosen representation only "works" if the data
>> get converted back to bytes with the python-escape error handler
>> also.
>
> I thought the error handler would be used for decoding.
It's us
interfaces. I don't understand from the rest of your message what
would *actually* break if people would use the proposed interfaces.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
on a VCS is a
> major PITA, and py3k is currently not helping the situation.
I find these statements contradicting:
py3k *is* keeping the byte-based APIs for file names intact, so
why is it not helping the situation, when this is what is needed
to make p
arguments as bytes. With the PEP, such a way would
actually become available for applications that desire it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
MRAB wrote:
> Martin v. Löwis wrote:
> [snip]
>> To convert non-decodable bytes, a new error handler "python-escape" is
>> introduced, which decodes non-decodable bytes using into a private-use
>> character U+F01xx, which is believed to not conflict with privat
X will trigger an error, which is then
>> handled by the handler to produce \xXX.
>
> But only for non-UTF8 encodings?
Right. For ease of use, the implementation will specify the error
handler regardless, and the recommended use for applications will
be
the decorate/sort/undecorate pattern,
and encourage use of the key= argument. Or, if you really need
to decorate into a tuple, still pass a key= argument.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
> Why not use U+DCxx for non-UTF-8 encodings too?
I thought of that, and was tricked into believing that only U+DC8x
is a half surrogate. Now I see that you are right, and have fixed
the PEP accordingly.
Regards,
Martin
___
Python-Dev mailing l
Cameron Simpson wrote:
> On 22Apr2009 08:50, Martin v. Löwis wrote:
> | File names, environment variables, and command line arguments are
> | defined as being character data in POSIX;
>
> Specific citation please? I'd like to check the specifics of this.
For example, on e
eld bytes( ord(c) for c in os_listdir_string )
> - have os.open() et al transcode unicode code points back into bytes.
> i.e. a straight one-to-one mapping, using only codepoints in the range
> 1..255.
That would be an alternative approach to the same problem (and one that
I think will
d, they
use the Windows ANSI code page (which varies with the installation).
> Given this, can't people who
> must have access to all files / environment data just use the bytes
> interface?
No, because the Windows API would interpret the bytes
701 - 800 of 5755 matches
Mail list logo
