ncertain what I should
rename them to. So proposals that rename only one of them aren't
that helpful. It would be helpful if people would indicate support
for Antoine's proposal.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@py
> Wouldn't renaming the existing "surrogates" handler be an incompatible
> change, and thus inappropriate?
No - it's new in Python 3.1.
So what do you think about Antoine's proposal?
Regards,
Martin
___
Python-Dev mai
n be named analogously
> "utf_8b_encoder_invalid_codepoints". Even these, to me, would be better
> than confusing giving them the same name as the codec.
So are you proposing that I should rename the PEP 383 handler
to "utf_8b_encoder_invalid_codepoints"?
Regards,
Martin
__
he primary application of this error
>> handler (i.e. file IO operations), there is no way of specifying
>> an addition error handler anyway.
>
> Would it be useful to allow setting this somewhere?
I'm deliberately not proposing this as part of the PEP. First, it
has eno
trip",
> errors="roundtripreplace", errors="tosurrogate",
> errors="surrogatereplace", errors="surrogateescape",
> errors="binaryreplace", errors="binaryescape". This includes Antoine's
> pro
ize yourself with the implementation
before commenting further?
Thanks,
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
ppy to make it "surrogatepass" and "surrogateescape" as
proposed by Walter. I'm sure you didn't really mean the spelling of
"excape" to be taken literally - whether or not you meant the plural
and the underscore literally, I
ys.path, in any order.
>
> How would this work if base, addon1 and addon2 were eggs managed by
> buildout or setuptools?
What is a managed egg (i.e. what kind of management does buildout
or setuptools apply to it)?
Regards,
Martin
_
4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*,
xm.*, paste.*, Products.*, buildout.*, five.*, silva.*, tl.*, tw.*,
themerubber.*, themetweaker.*, zc.*, z3c.*, zgeo.*, z3ext.*, etc.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http
es, rather than modifying existing ones.
If you always use --single-version-externally-managed with easy_install,
it will stop editing .pth files on installation.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Chris Withers wrote:
> Martin v. Löwis wrote:
>>> So this __init__.py can have code in it?
>>
>> That's the point, yes.
>>
>>> And base.tar can have other modules and subpackages in it?
>>
>> Certainly, yes.
>
> Great, when is the
, as the setuptools mechanism
doesn't support base packages.
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
> (or the generated script wrappers) to add them to sys.path.
Ah, ok. Is there also an easy_install invocation that unpacks the zip
file into some location of sys.path (which then wouldn't require
editing sys.path)?
Regards,
Martin
___
Python-
> GNU stow does handle these issues.
If GNU stow solves all your problems, why do you want to
use easy_install in the first place?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
Zooko Wilcox-O'Hearn wrote:
> On May 10, 2009, at 11:18 AM, Martin v. Löwis wrote:
>
>> If GNU stow solves all your problems, why do you want to use
>> easy_install in the first place?
>
> That's a good question. The answer is that there are two separate jobs:
rs (and neither sure what your
current strategy is wrt. volumes on the other machines).
Compared to /srv, everything else is peanuts, anyway.
Regards,
Martin
P.S. I have removed ~root/.ssh/authorized_keys. It only
contained my key, and root logins are disallowed, anyway.
P.P.S. You can stop doing
[please ignore this message - I sent it to the wrong mailing list]
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
d releases: would we still
maintain them? If so, how many of them? For how long?
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
on HP-UX, and discussion whether this patch
is the appropriate solution.
Regards,
Martin
(**) There is, of course, ActiveState, which does provide binaries,
including for HP-UX, so I suppose they support it - at least if you
buy commercial support.
___
nload/other - contributions are welcome.
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
com/en-us/library/aa365247.aspx
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
sers of a conversion function that requires cleanup need to
initialize the output pointer to NULL, and then release memory
explicitly when the argument conversion fails.
Which of these do you like best?
Regards,
Martin
___
Python-Dev mailing list
Python
e says: it might be best to just remove that option.
For compatibility, perhaps deprecate it in 2.7 and 3.1, and remove in
in 3.2.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Thomas Wouters reminded me of a long-standing idea; I finally
found the time to write it down.
Please comment!
Regards,
Martin
PEP: 384
Title: Defining a Stable ABI
Version: $Revision: 72754 $
Last-Modified: $Date: 2009-05-17 21:14:52 +0200 (So, 17. Mai 2009) $
Author: Martin v. Löwis
Status
see.
Why do you think that optimization efforts could be related to
the PEP 384 proposal?
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 T_ constants
would need to be changed as well.
So if that's the rationale, I would propose to make it namespace-safe
under a different file name, and add alias #defines in structmember.h
for compatibility.
I also think this should happen independent of PEP 384.
See also iss
Dirkjan Ochtman wrote:
> On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis"
> wrote:
>> I fail to see the relationship, so: no effect that I can see.
>>
>> Why do you think that optimization efforts could be related to
>> the PEP 384 proposal?
>
&
core as ref counting.
Access to the type object reference is probably similar. All the other
structs are used "directly" in C code, with no accessor macros.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
uld it help IronClad if it could restrict itself to PEP 384
compatible modules?
b) Would further restrictions in the PEP help that cause?
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
ime of 3.x. Another approach could be to document
the known restrictions, and otherwise declare "use at your own risk".
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
en scp/rcp/ftp it to the target system.
We cannot add an FTP URL to the download page, because we don't
run an ftp server anymore, and don't plan to.
[I don't quite get the "Here is what ended up working" part. What
is http://www.e?]
Regards,
Martin
e, I would actually like to deprecate,
>> then remove these APIs. I had originally hoped that this would happen
>> for 3.0 already, alas, nobody worked on it.
>>
>> In any case, I have removed them from the ABI now.
>
> How do you expect Python extensions to all
untime DLL doesn't change
> between releases, but it becomes a problem when they do e.g.
> due to an upgrade to a new MSVC++ compiler version or in case
> the extension was downloaded pre-compiled from pypi or some
> other site.
What problem specifically may occur?
Regards,
Martin
I start a Python 3.5 application which uses a limited
> API extension, this would try to load python32.dll into the
> Python 3.5 process. AFAIK, that's not possible due to the
> naming conflicts.
I don't see this problem. As long as we manage to install multiple
versions of python3.d
> 3. ?? - I'm sure there are other issues that deserve a look.
What about fairness? I don't know off-hand whether the GIL is
fair, or whether critical sections are fair, but it needs to be
considered.
Regards,
Martin
___
Python-Dev mailin
re it; it won't happen that one thread
starves waiting for the mutex. This is something that the mutex needs to
provide, not the application.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
Apples & oranges when it
> comes to stuff like this
Please trust Antoine that it's relevant: if the current implementation
isn't fair on Linux, there is no need for the new implementation to be
fair on Windows.
Regards,
Martin
___
Python-D
l too narrow, for some applications I would envision - such
as computing consistency of BGP tables and whois databases).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ddr was first offered. It's just
not an important library, and people will continue to roll their own
for some time. OTOH, with ipaddr in the standard library, people will
also start contributing extensions that make it support their use cases,
so it should grow a wider
iscussed on the tracker).
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
Clay McClure wrote:
> On Tue, Jun 2, 2009 at 1:38 AM, "Martin v. Löwis" wrote:
>
>> For the net-vs-host issue, I think a backwards-compatible solution
>> is possible: just give the IP() function an option parameter that
>> makes it reject a netmask during par
fully (but I might
be wrong with that, and there might be a different reason).
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
> You seem comfortable with these quirks, but then you're not planning
> to write software with this library. Developers who do intend to write
> meaningful network applications do seem concerned, yet we're ignored.
I don't hear a
refer its
removal at this point.
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 module has these minor flaws, they should be fixed at some
point", which means "commit, then change later". This is what happened.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
r because his author
offered to maintain it. I then didn't have the time to review it
myself, and was happy that others picked it up.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
ker to
> add responses.
Actually, one of roundup's big advantages over many competitors is that
you can also respond by email; many contributors actually do that.
You only have to remember that this isn't really email, so you can
usually omit salute and si
and there's no documentation
> (that I'm aware of) which says that a "-1" is required, or how it will
> be used or interpreted.
Well, there is
http://www.python.org/dev/peps/pep-0010/
I personally use them sometimes, but wouldn't insist on others using them.
> Is there a good python-dev archive search mechanism (other than to
> google "python-dev " ;) out there? Wouldn't that help?
I would add site:mail.python.org into the google query, but apart from
that: what's wrong with googl
someone can remove
> python-dev from the "nosies." No new code is required to set this up
> as far as I can tell.
That would certainly be possible. I'm not sure whether it *should*
be done, though. If anybody actually wants that feature, please create
a ticket in t
y easy. Start a search, put your account name into "Nosy list
member", and put "My nosy" (or some such) into "Query name**". Then hit
search, and watch "My nosy" appear under "Your queries".
Regards,
Martin
, rather
> than a 2.x to 3.y upgrades?
IMO, it's much up to the contributors. If the regular committers
want to continue to work on 2.x, and a release manager is found
to create releases, we can continue to release 2.8, and perhaps
2.9. However, I think at this point, it is too early
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I have thought that 2.7 was now to come out instead with 3.2 and would
>>> include backported 3.2 new features. Others expect 2.7 to come out soon
>>> after 3.1 and to only contain new 3.1 features. So Guido or someo
#x27;ll have to convince me that having new features
> in 2.7 that aren't in 3.1 is a good idea :)
I don't see why the precise ordering of release dates matters at all.
It seems you are happy with having 3.2 be released "around the same
time" as 2.7. What is "the same time
>> Also, Martin suggested we migrate to Python's svn and then go along
>> for the svn->hg ride. Does that still make sense now that some
>> planning has been done?
>
> I don't think so. It should not matter from which repository the conversion
> is d
> For my part I'm fine either way (and I agree that Martin should decide
> based on what is best for him).
See my other message. We need to collect SSH keys, and I don't mind
moving the Jython repository. OTOH, if the Jython repository gets
converted into hg right away, it'
suggests that you *do* want to see new features (namely, a native
curses module, and a native readline module).
Which one is it?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
that long).
If nobody else has time to submit a patch, either, Python 3.1 will
get released with this bug.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
e yourself much more with OpenSSL.
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
>> This question is really off-topic for python-dev. As a python-dev
>> poster, you should do research upfront, and only post on what you
>> consider facts.
>
> Martin, I told him to ask his question about _ssl internals on
> python-dev as he is new, and looking to work
In any case, _ssl.c is *not* the place
where any of the certificate validation actually happens - nor does it
happen elsewhere in the Python source code, IIUC.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
asing control of xmlrpclib.
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
e6267
While I have your attention, please also review
http://bugs.python.org/issue6233
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
erybody else who said that this would be a change
for the worse. This kind of syntax is one of the most prominent features
of Perl.
$...@~ly/your/s!,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On-topic would have been a disussion of which of these features would
be useful for the trace module to be built-in, how to best provide them,
along with an offer to produce a patch.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python
> Comments?
I don't think there is any need to support that in the Python core.
Instead, if you find such a functionality useful, feel free to implement
it yourself, and share it with others.
Regards,
Martin
___
Python-Dev mailing list
Py
> Can you tell me which modules provide to
> decode and execute a .pyc file ?
The bytecode loader in in marshal.c; the byte code interpreter is in
ceval.c. Also consider frameobject.c and codeobject.c.
HTH,
Martin
___
Python-Dev mailing list
Pyth
le, not what the specific
patch would look like)?
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
preferably only fixes that have already been applied to later
releases of Python.
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
nt, which you should now seek.
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
tibilities. So any change must be done with greatest care,
but simultaneously, should also try to arrange to cover all cases.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
> - Post that to python-list, with a note pointing to the PEP for people
> who care about distutils details
If that hasn't been done before (I have not followed), it should be done
right away. PEP 1 makes it a mandatory requirement for acceptance.
Rega
but it
doesn't seem to hurt having it, especially since "egg-info" already
managed to sneak in.
> I hope it'll make it one day. If not, I don't understand the goal of
> the "Python Language Summit'
Just be patient. Both Python 2.7 and 3.2 are still many mon
> I dunno what the right solution is.
I feel that it is straight forward. Either provide a
/usr/bin/python-uninstall utility, or arrange to make
python -mdistutils.uninstall work, so one would do
python -mdistutils.uninstall some_package
Regards,
Mar
> PS: if this gets fixed somehow, can the fix be backported to the
> Python 2.5.x releases?
Definitely not - it's not security critical.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
ndows and hg could provide detailed
instructions well in advance of August 1.
If we don't have anybody familiar with Windows and hg, we have a
really serious problem.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
ntly: 2.4 and
2.5, although 2.4 will be closed soon.
- our committers consistently refuse to merge changes across
branches themselves, and likely continue to do so unless there
is some feature of hg that I missed (e.g. one were merging
would happen without any user specifically asking for i
ng it (either code.python.org, or sys.revision), *cannot*
be agnostic of the specific technology.
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
few the
> other) is a big problem. But feel free to enlighten me!
If "both" means "both the server side test, and win32text", then Mark
already gave the answer: he cannot use win32test because he does not
know how to operate it (and
I have now turned the 3.0 buildbots off, and created new
builders for 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
from your proposed sys.revision.
For cloned branches, I wonder how sys.revision[1] would be computed.
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
used for the specific version.
Regards,
Martin
(*) even for svn it was best-effort only in case there were local
modifications.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
rrors the output of the hg id command, which is
> intended for this kind of usage.
I would like to see this well before the switch also. It could be
a patch (unified diff) stored in the tracker, or it could be an actual
branch that then needs to get merged with all active branches (IIUC).
Regard
Barry Warsaw wrote:
> On Jul 3, 2009, at 5:00 PM, Martin v. Löwis wrote:
>
>> I'm -1 on calling it "sys.revision", as this makes it difficult to
>> tell what the actual versioning system was, and hence how the
>> data should be interpreted. It will already b
should just freeze the tuple at
> e.g. ('CPython', 'branches/release26-maint', None).
That would work for me (I had to re-read the documentation to see
that None is a valid, documented value for version, and allowed
if "the tree was exported").
Interesting to notice
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>> I would drop the roundup integration from the things that need to
>> be done pre-migration - there currently is no svn integration, so
>> not having it for hg is not a step backwards.
>
> That's not quite true - the
> I see that George Brandl and Martin van Loewis seem to be accomodating
> your viewpoint, but I don't get the impression that either you (as the
> hg migration proponent) nor they (as core committers) realize how far
> apart your assumptions are.
Actually, I (probably) don&#
omeone does a hg merge.
I probably don't fully understand, but that seems to imply a workflow
were all changes made to one branch should also automatically be
integrated into a different branch. I'm curious as to how such a
mechanism can apply to Python.
Regards,
Martin
__
e of the Python source
code, Mercurial, and either autoconf or Visual Studio (preferably both).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
> with him).
I think that's straight-forward. Once we know what URLs to link to,
we just need to fix the regexps.
> For build identification, I'd only be able to do the C/Python side of
> things and (with luck) autoconf.
Ok, we'll see in a week from now whe
s-is, for all the stuff that won't be migrated.
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
l33d00 after problems on Pentium CPUs".
In practice, rather 30ba63d28b1b or 12fb3b32d75d (from html5lib,
fwiw).
Dirkjan meant "[a-f0-9]{12}" literally.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
or a, say,
"r" or "R" prefix, or perhaps "V" or "merc:".
I think you are proposing that there is no prefix because the chance
for a misidentification of some word as a hg revision number is small,
as it has to be exactly 12 hex digits.
Regards,
Martin
llow revisions of a patch
- motivation 4: allow tracking the mainline while working on a patch
- motivation 5: avoid using arcane third-party tools for merge tracking
So merge tracking was not the main argument, but the fifth.
Regards,
Martin
___
Python-Dev
ide a patch to
bugs.python.org. I believe this patch is *very* difficult to
implement, unless the function can accept some severe limitations.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
er *how* it's done as long as you can pass char**
in some way.
> Alternately a function to convert the char **argv to wchar_t **argv
> could be ok too.
Convert in what manner? What is the encoding of your char**?
Regards,
Martin
___
Python-Dev
;. That would be setting expectations far too high because
> packaging cross-platform is so messy.
OTOH, it *is* expected that the PEP explicitly lists aspects that it
didn't resolve, so that any reader can find out whether something was
discu
life easier.
I usually abstain from "me too" messages, but only this time:
as Antoine says.
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
gain, did you search for closed reports also?
> Is there some sort of delay in updating the search indexes?
No, it's immediate.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
,
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
901 - 1000 of 5755 matches
Mail list logo
