ion of multiple copies of the same Python version, e.g.
from ActivePython, EPD, etc.
> * Does the strategy have general support from Martin, who as the person
> making Python distributions would need to be involved in at least some
> aspects of it (specifically, having the installer MSI in
ternative is that some people just give up contributing
to Python.
I just hope that we can stick with Mercurial for more than five years,
before the next hot thing comes along.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
Am 19.03.2011 23:51, schrieb Nick Coghlan:
> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis" wrote:
>> I, for example, will find issues with it if the implementation uses
>> CreateProcess at some point - the launcher should IMO run Python
>> directly, rather th
you
want to build the 2.5 branch, check it out from subversion.
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
hanges, so that they would
should up on a waterfall filtered by category. Since we have no
waterfall for 2.5, I didn't add any categorization for it. This should
now be fixed.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
is. Thus things would get
> a little more complex as we go snooping for the location of the DLL.
The launcher can know how all released Python versions behaved, so it
can adjust.
> Actually, it does say '...the "console" version of the launcher should
> be associated wit
this launcher just be a basic wrapper
> that cobbles together the arguments for an eventual os.exec*() call?
Windows doesn't support exec*(3).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
> Is it thread / interpreter safe or something dirty can happen?
It is safe, thanks to the global interpreter lock (a.k.a. GIL).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
e terminates way before the actual Python script
terminates, right?
So if somebody would launch a python script with py.exe, they would
think it was completed even though it would still be running.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyt
d
> possibly break existing scripts.
Interesting question. What is it in COM and ISAPI applications?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
e, but is certainly acceptable.
b) platform-independence is not lost as the launcher would continue
to support /usr/bin-based paths. So platform-independence would
be an opt-in feature, at the choice of script authors.
Regards,
Martin
___
Python-De
Am 21.03.2011 00:52, schrieb Mark Hammond:
> On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote:
>>> The above raises an interesting question - if the launcher executed
>>> Python in-process, what would sys.executable be? I can imagine there
>>> are few scena
is issue, it may turn out infeasible to actually implement
the PEP. If Mark takes a stance in this issue, I'd request that the
opposite position is appropriately reflected (and rebutted) in the PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-D
't just exec the relevant python?
Windows doesn't support exec.
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
tually know what use cases would be affected, other
then saying that anything launching py.exe could be affect, in
particular applications using ShellExecuteEx. I don't think it is
feasible to change them all to launch something different instead; some
may be out of our
> I personally would conclude that the last option is the least worst
> scenario by a wide margin.
Ok, I let this rest. Can you please add a summary of this discussion to
the PEP? (also, can you please check in the PEP, and give it a number?)
Thanks,
ormat
was actually encountered - not just if merely PyArg_ParseTuple is
called).
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/
orkspace; that testing and review is
> therefore imposed on the project as a whole, and perhaps not done
> until more concurrent commits have been made.
You make it sound as if you have never used subversion.
Regards,
Martin
___
Python-Dev mailing lis
d it out by accident!]
Thanks - I didn't know, and it sounds useful.
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
;ed); please get in touch with him. Please familiarize
yourself with the existing Python bindings (in the latest RPM 4 release
from rpm.org). You'll notice that this already has Python 3 support;
not sure whether that's the most recent code, though.
Regards,
Martin
__
ting Mercurial). I had meant to insist on a formal
review of the PEP, but gave up on that due to the time pressure
to complete the conversion before PyCon.
Some of the open issues of the PEP are actually still open.
Regards,
Martin
___
Python-Dev mailing list
> It does so at the *tree* level, not at an individual file level.
Thanks - I stand corrected. I was thinking about the file level only (at
which it doesn't do server-side merging - right?).
Regards,
Martin
___
Python-Dev mailing list
Py
- the bug may only affect only infrequent cases,
or many users may be using a different branch, anyway. Others could
then still backport the change if they consider it important (and
do a subsequent "null merge" to properly link the backport).
Regards,
Martin
typo change, and three merges, asking for a collapse of the typo
change is IMO complicating things too much.
OTOH, collapsing weeks of work isn't that much overhead, relatively.
Plus you may want to push the feature branch to hg.python.org/guido,
so that people can still lo
that a single push includes unrelated changes, people
can still look at the individual changesets in the repo to figure it all
out.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
so agree that the GSoC project should focus on the coding/porting
part. Setting up infrastructure is not a good GSoC project, as this
is rather a long-term commitment to keep it running.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:
x27;s a great
project. Alternatively, if the project objective would include creating
a Python distribution (even as a source tarball), it would be great.
If it merely transforms some stdlib modules which then get used nowhere,
it is not so great.
Regards,
Martin
_
compiling with Cython,
but the cases in which you get a TypeError must not 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
ile. Perhaps improve the email hook to give more condensed reports.
If people then complain about too much fine-grainedness, we could
tighten it again.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
amed branch, which, I think, will have an effect similar
> to "mainline".
Not if the changes you want to suppress are actually also on the same
branch as the one whose mainline you are trying to see (which they
typically are, with the branch typically
the compiler to detect type
errors in PyArg_ParseTuple.
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
at would amount to not using named branches. But if you
> develop on a named feature-branch and merge into "default" when ready
> your local history is easy to filter-out without rebasing or
> collapsing.
Ah. We don't support this kind of development - no new named branch
Am 22.03.2011 03:43, schrieb Stephen J. Turnbull:
> "Martin v. Löwis" writes:
>
> > Not if the changes you want to suppress are actually also on the same
> > branch as the one whose mainline you are trying to see (which they
> > typically are, with t
xactly: hg incoming --patch could generate multiple
patches for the same file. The button tries to combine them into a
single patch per file (which turns out to be difficult).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
know about, just as you didn't know about
patches that may have circulated before. If people want you to know
about a clone, they have to tell you - one way of doing that is to
attach its link to a tracker issue.
> The Roundup interface is getting extraordinar
Don't worry about this. It will *not* normally generate the same file
twice, but notice that it already created it. It's just because the
same repository was added twice that you can get the same patch out of
it twice also.
Regards,
Martin
Am 23.03.2011 03:47, schrieb Terry Reedy:
> On 3/22/2011 9:51 PM, "Martin v. Löwis" wrote:
>>> Pressing that button seems to create a duplicate patch, which is not
>>> good. Given that there is no connection between the repository names
>>> (which seem to be
hanges to the license). If you
accepted contributions of others into the code, make sure they also
filed a contributor agreement.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
the ".pyc" and only
> then look for ".py" ?
If you then further reduce sys.path, and zip up the standard library
.pyc files, you get further reductions.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
> My main concern was that a freshly compiled Python attempts to open 168
> non-existent files before starting.
Please consider my proposals then.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
> I would like to replace %.100s because there are no more reason to
> truncate strings to an arbitrary length.
I agree with MAL. It protects against cases with ridiculously long
parameters - say, you have a string with 1GB. You *want* to truncate
bogus text.
Regards,
> Is there a bug somewhere, or do I misunderstood something important?
Module unloading is simply not implemented, and would be very difficult
to implement.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
Am 25.03.2011 11:14, schrieb Victor Stinner:
> Le vendredi 25 mars 2011 à 07:59 +0100, "Martin v. Löwis" a écrit :
>>> Is there a bug somewhere, or do I misunderstood something important?
>>
>> Module unloading is simply not implemented, and would be very difficul
Am 25.03.2011 10:24, schrieb Stefan Behnel:
> "Martin v. Löwis", 25.03.2011 07:59:
>>> Is there a bug somewhere, or do I misunderstood something important?
>>
>> Module unloading is simply not implemented, and would be very difficult
>> to implement.
o list, use “#” instead of
> “:” as a separator between repo URI and branch name; it’s standard
> Mercurial form and will allow people to copy-paste the whole thing to
> get a clone of the repo up to that branch.
Ok, committed.
Regards,
Martin
__
27;s idea,
which is really smart, which also allows me to drop the sourcebranch
information.
Let's see whether it is correct this time.
I also added quotes into the branch name, so hyphens should be allowed now.
Regards,
Martin
___
P
for i, c in enumerate(pattern):
>
> I would call thin 'Replace obsolete idiom in' rather than 'Refactor'.
> So are you criticizing the replacement or the mislabeling?
No - I believe he is critizing that a stylistic change is done
in a maintenance branch. It's
it-style diffs where the base file has been changed after the
diff was produced.
If you find that it doesn't work in cases not discussed above,
please report this to the meta-tracker.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
htt
n to fork it. Users with email readers that can't display UTF-8 at
all (even if the characters are all ASCII) will need to find a way of
coping with that.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
cklist was UTF-8, and the program
ran in a Latin-1 locale, it would have decoded the file name nicely
(without surrogates), but the blacklist check would still have failed.
He should have opened the file in the locale's encoding (i.e. giving no
encoding
proper blacklisting, you would likely
use substring searches, case-insensitivity, transliterations, and
perhaps even regular expressions and word stemming. If you consider all
these things, proper or alternative encodings of the same text are just
another issue to consider.
Regards,
Martin
_
> What's more, it lacks the most important: the issue title.
Notice that the issue title was always there, in your browser's title
bar (unless you have a web browser that doesn't display the page title).
Regards,
Martin
___
Pytho
I can give you access to
dinsdale.
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
their development environments will.
They can also patch the Python releases themselves, or use Ubuntu
packages that someone else made for them (they can probably just install
the old 2.4 packages just fine).
Regards,
Martin
___
Python-Dev mailing list
P
it released at some point.
So by refusing these changes, I hope to reduce the frustration for not
getting them released.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
o 2.5 documentation releases.
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
> And I don't see a problem with build fixes. It's not like we're adding
> language features. If it makes someone's life easier, then what's the harm?
It's extra work with no volunteer doing it.
Regards,
Martin
__
able tradeoff to this breakage is
that a security concern is resolved in return for the breakage.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
Am 01.04.2011 21:54, schrieb Eric Smith:
> On 4/1/2011 3:52 PM, "Martin v. Löwis" wrote:
>>> And I don't see a problem with build fixes. It's not like we're adding
>>> language features. If it makes someone's life easier, then what's th
> 1. Do nothing. This will break code that currently uses AST, but doesn't add
> any complexity to cpython.
I'm in favor of this approach as well. Notice that there is
ast.__version__ precisely so that applications can support multiple AST
versions.
(see "openssl ecparam -list_curves" for a list of valid names)
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-de
Python).
> If it's not feasible to release 3.3 from a 2010 build, when might we be
> able to make the change?
If we don't switch for 3.3, we'll definitely switch to VS 2012.
> I'm willing to do the work on this, but I just want to make sure it's a
&g
ive I can see is to freeze the AST structure, allowing
for extensions at best. I don't think any of the implementations are in
a state where such an approach is feasible.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
back then
that the AST will change over time (hence the module was originally
called _ast).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
Am 05.04.2011 00:21, schrieb Antoine Pitrou:
> On Mon, 04 Apr 2011 23:40:33 +0200
> "Martin v. Löwis" wrote:
>> - users have expressed concerns that they constantly need to upgrade
>> VS releases when developing for Python.
>
> Isn't that kind of a
y, but slightly (I hope).
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
hat we're sure we're
> ABI-conformant?
If it compiles with Py_LIMITED_API defined, and links successfully
on Windows, it should be ABI-conforming (unless you deliberately
bypass the test, e.g. by replicating struct definitions in your
own code).
Regards,
Martin
___
> Does this mean new versions of distutils let you build_ext with any C
> compiler, instead of enforcing the same compiler as it has done
> previously?
No, it doesn't. distutils was considered frozen, and changes to it to
better support the ABI where rejected.
R
Am 05.04.2011 22:43, schrieb Greg Ewing:
> Martin v. Löwis wrote:
>> Not if they use the stable ABI. There still might be issues if you
>> mix CRTs, but none related to the Python ABI - in particular, none
>> of those crashing conditions can arise from the stable ABI.
>
gt;
>> No, it doesn't. distutils was considered frozen, and changes to it to
>> better support the ABI where rejected.
>
> How about distutils2 then?
That certainly will be changed to support the ABI better.
Regards,
Martin
___
ython's repository,
and vice versa, except for a good reason.
Ultimately, it's up to Georg and Antoine to decide whether they want
to accept the load. One option would be to grant a Jython developer
control to account management - preferably a single person, wh
this_clone
cd this_clone
hg import ../patch
HTH,
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
the json package.
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
iverges.
> It may be that no-one is willing or able to serve as an effective maintainer
> of stdlib json, but assuming that Bob will continue to maintain and improve
> simplejson
Does it actually need improvement?
Regards,
Martin
___
Python-Dev
Am 16.04.2011 21:13, schrieb Vinay Sajip:
> Martin v. Löwis v.loewis.de> writes:
>
>> Does it actually need improvement?
>
> I can't actually say, but I assume it keeps changing for the better - albeit
> slowly. I wasn't thinking of specific improvemen
data on the receiving end.
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 course, people might find other workloads which show bigger disparity in
> performance, or might find something in my 3.x port of simplejson which
> invalidates my finding of a 2% difference.
Thanks a lot for doing this research, by the way.
Regard
lease,
Martin
Martin v. Loewis
mar...@v.loewis.de
Python Release Manager
(on behalf of the entire python-dev team)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
> I think the release date of 2.5.6c1 should be 17-Apr-2011, instead of
> 17-Apr-2010
> http://www.python.org/download/releases/2.5.6/NEWS.txt
Thanks, fixed.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
able to remove
the code eventually.
So please go ahead and add them to PEP 11.
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/p
do as well.
Or perhaps we could always use the #error if we can trust that compilers
will honor it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
I'd accept
them anyway - anybody interested in W2k would then have to provide
fixes before 3.3rc1.
So please go ahead and change PEP 11. While you are at it, also threaten
to remove support for systems where the COMSPEC points to command.com
(#2405).
Regards,
Martin
___
now that anybody else would). To view the source
code of the file, use
http://svn.python.org/view/python/trunk/Lib/heapq.py?view=co&content-type=text/plain
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
to support
> OpenVMS platform.
I guess the best first step would be to make it compile at all. Then try
to make it pass the test suite. This may well take several months to
complete.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.or
> How do I know which version of Python a PEP lands in?
You should look at the Python-Version header of the PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
> Is there code out there that is using this "list of int's" interface
Just in case this isn't clear yet: yes, certainly. Any non-trivial piece
of Python 3 code that has been written already (and there is some) will
have run into that
like "NNN bugs have been fixed, in MMM
modules; see NEWS for details", or some such.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
Am 18.05.2011 08:38, schrieb Amaury Forgeot d'Arc:
> 2011/5/18 "Martin v. Löwis" :
>>> How do I know which version of Python a PEP lands in?
>>
>> You should look at the Python-Version header of the PEP.
>
> But some PEPs don't have it: 341
if my_byte_string[i] == ord(b'x')
>From a readability point, it's in the same category as the first one,
but less twisted.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Am 18.05.2011 20:39, schrieb Hagen Fürstenau:
>> On behalf of the Python development team, I am pleased to announce the
>> first release candidate of Python 3.2.1.
>
> Shouldn't there be a tag "v3.2.1rc1" in the hg repo?
http://hg.python.org/releasing/3.2.1/
Am 18.05.2011 21:37, schrieb Hagen Fürstenau:
>> P.S. "Shouldn't" makes it sound as if there was a mistake.
>
> Well, I thought there was. When do these tags get merged into "cpython"
> then?
See PEP 101
Regards,
Martin
___
byte strings. Not sure
whether that, in turn, has undesirable consequences.
In addition, equality should be transitive, so b'A' == 65.0.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
on, equality should be transitive, so b'A' == 65.0.
>
> I'm not sure what you're getting at...
That it is counter-intuitive to have a bytes object compare equal
to a floating-point number.
Regards,
Martin
___
Python-Dev mailin
ress
(not sure what "track in place" means).
If you are asking for a named branch: no, that shouldn't be done.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
set this up, it could be done in no time.
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
API for that on Windows (i.e. call AccessCheck).
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
ounters
into a contiguous block of memory, unrelated reference counters will
live in the same cache line. Consequentially, changing one reference
counter on one CPU will invalidate the cached reference counters of
that cache line on other CPU, making your problem a) actually worse.
R
ssues, please see:
http://www.python.org/2.5.6
Highlights of the previous major Python releases are available from
the Python 2.5 page, at
http://www.python.org/2.5/highlights.html
Enjoy this release,
Martin
Martin v. Loewis
mar...@v.loewis.de
Python Release Manager
(on behalf of the entire p
oo - c65e1a422bc3
> Not to mention that features of the "class mysocket" can be had
> using a buffered socket.makefile() instead of writing custom code.
I find it actually appropriate in the context. It illustrates a
number of important points about sockets, namely that y
/www.python.org/download/releases/3.1.4/
>>http://www.python.org/download/releases/2.7.2/
>
> Wohaa. Martin, I think this is from your checkin?
Indeed... I have now fixed it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python
2901 - 3000 of 5755 matches
Mail list logo
