5 and < 2.6
Perhaps. I think the Linux packaging formats uniformly use the comma.
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
pecify it properly (at least, it now says something that Tarek
said he didn't want). However, try coming up with wording that
says "~=A means >=A and < 'words to describe the proper upper bound'".
Regards,
Martin
> And IMO the choice of "~=" or "=~" for the range match should be
> avoided, since that looks like the regexp search operator in Perl, and
> there "~= 3" would match "3", "3.0.4", and "2.3.5". The next obvious
> interpretation is "fuzzy match", but that doesn't have an obvious,
> more specific me
stutils-sig, Tarek (eventually) agree, nobody else commented. Now
python-dev people neither like the syntax, nor the semantics. Saying
that distutils-sig has discussed that aspect would be incorrect,
though.
Regards,
Martin
___
Python-Dev mailing list
> I think Antoine's proposal is good (using the range when "2.5" is
> used, and using 2.5.0 when explicitely
> needed), and fixes Martin's concerns.
>
> So I would be in favor of removing ~= and using Antoine's rule;
So specifying 2.5 would be a
s-Python: 2.6.2 ==> only Python 2.6.2
No: >=2.6.2, <2.6.3 (of course, the only Python release in that range
was 2.6.2, since there was no 2.6.2.1).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
.5.2 < 3 > 3.1
-1. I would prefer if there is only a single syntax for specifying
version dependencies, independent of what metadata field they
appear in.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
ng?
I can agree it's shorter. I can't agree that it's simpler,
or less ambiguous.
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
fix bugs you have
> to look at the installed source and trace it back to the bug in the
> original source.
That's an issue indeed, but one that I would hope that can be fixed by
improved traceback printing. It would be good if such traceback printing
could make it into 2.7.
Regar
g to consider these (as an option).
> Seriously though, I find it hard to believe that this is a big
> problem. The 3.x source looks pretty similar to the 2.x source, and
> it's good to look at both if you're dealing with a 3.x issue.
That's my experience as well - the
t; (which is like forever) then adding Python 3 only makes development
> that much more complicated and much less fun, with no concrete
> benefits.
I doubt it will be *much* more complicated - only a little.
As for concrete benefits: there may be no benefits at this point,
> b) Does this fix seem like the sensible thing to do?
No. Linking in setup.py should use the same options as if the module
was built as *shared* through Modules/Setup, which, IIUC, should use
BLDLIBRARY.
Regards,
Martin
___
Python-Dev mailing l
uot;yes" regarding the OP's original question about releasing the
> GIL during regexp searches?
No, because the regex engine may also operate on buffers that start
moving around when you release the GIL.
Regards,
Martin
___
Python-Dev mailing
get mutated). Even if they stay in place -
if their contents changes, regex results may be confusing.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
tead process a file
> called ast.txt. Where does this file come from ? Is it generated from
> Python.asdl ?
astgen.py is not used to process asdl files; ast.txt lives right next to
astgen.py. Instead, the asdl file is processed by Parser/asdl_
ther I would consider a patch thread-safe
that released the GIL around matching under selected circumstances -
if I had the patch available. I don't see any obvious reason (assuming
Guido's list of conditions holds - i.e. you are holding references to
everything you access).
Regards,
Marti
> I've been wondering whether it's possible to release the GIL in the
> regex engine during matching.
Ok, here is another problem: SRE_OP_REPEAT uses PyObject_MALLOC,
which requires the GIL (it then also may call PyErr_NoMemory,
which also requires the GIL).
ome re-factoring
*/
PyBuffer_Release(&view);
Even if we do use the new API, and correctly, it still might be
confusing if the contents of the buffer changes underneath.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Python AST.
No - what actually happens in Python 3.x is this: both the compiler
package and Tools/compiler are removed.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
see
/etc/magic). Having a magic byte sequence for plain text to denote the
encoding is useful and helps reducing moji-bake. This is the reason it's
used on Windows: notepad would normally assume that text is in the ANSI
code page, and for compatibility, it can't stop doing that. So the
ncoding.
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
keep the backward compatibility?
Absolutely. And there is no need to produce a new option, but instead
use the existing options: define an encoding that auto-detects the
encoding from the family of BOMs. Maybe you call it encoding="sniff".
Regards,
Martin
_
process...
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
> I see. So if people want to analyze python code they have to use
> other tools (like rope?) ? or use reflection ?
Correct. One such tool might be the true Python compiler, along
with the _ast module.
Regards,
Martin
___
Python-Dev mailing list
ruly awful CP1252.
While I would support combining BOM detection in the case where a file
is opened for reading and no encoding is specified, I see two problems:
a) if a seek operations is performed before having looked at the BOM,
no determination would ha
t applications
won't be using it for another three years or so, since they'll have to
support older Python versions as well (unless it is integrated in the
case where no encoding is specified).
Regards,
Martin
___
Python-Dev mailing list
Python-D
ers to choose between two different
> autodetection
> strategies (encoding=None and another one) is a little insane IMO.
That wouldn't disturb me much. There are a lot of things in that area
that are a little insane, starting with Microsoft Windows :-)
Regards,
Martin
__
, or
only committed the new feature to the 3.x branch?
As for old branches: they *don't* live in the way you claim (i.e.
remain open with changes potentially just not released). Instead,
at some point, they are frozen to bug-fix only, then to security-fix
only, and
to parallel versions - "that must have taken
a lot of effort". So everybody will likely understand that enough is
enough.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
Neil Schemenauer wrote:
> On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
>> [...] would it still be ok if I closed a 2.x feature request as
>> "won't fix", or only committed the new feature to the 3.x branch?
>
> Yes. Non-bugfix d
houldn't say that, because it wouldn't be true.
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
available manpower and still providing quality software.
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
but by
Benjamin and his contributors :-).
I like the wording as it is (although I find the promise of five years
of bug fix releases a bit too strong).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
> But an autodetect feature is not a codec. Sure it should be reusable,
> but making it a codec seems to be a weird hack to me.
Well, the existing UTF-16 codec also is an autodetect feature (to
detect the endianness), and I don't consider it a weird hack.
Rega
27;t see that open(file, encoding='BOM') has any benefit over this,
Well, it would have the advantage that Walter pointed out: you can
implement it independent of the open() implementation, and even provide
it in older versions of Python.
Regards,
Martin
___
ive to not port
yet until they can drop support for anything before 2.7.
Inherently, 2.8 can't improve on 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
1 for putting it into the announcements.
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
Guido van Rossum wrote:
> +1 from me. (With the caveat that "time will tell" is definitely the
> ultimate answer. Plans may change unexpectedly, even though we don't
> expect them to.)
>
> PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
&
span of seven years, though.
Python had been supporting Windows 95 for more than 7 years (I think
rather 9 or 10), likewise Windows 3.1 before that. Python 2.7 will
likely still support Windows 2000, which then will be ten years old.
Solaris support will probably go back to Solaris 2.6, which will b
tutils (as
does Django itself), and it works fine.
That distribute had to redo it is only because setuptools *replaces*
the build_py command, as does the 2to3 support in distutils. So only
if you have a different build_py already, you can't use what is in
3.x.
No, that's incorrect. Suppose 2.7 is the last 2.x release, to be
released in 2010. Then, in 2015, it may be that everybody has migrated
to 2.7, which then is a common platform.
If you release 2.8 in 2012, then, in 2015, people will be split betw
as the five-for-one
deal).
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
", not
"64bit") is:
"""The binaries for AMD64 will also work on processors that implement
the Intel 64 architecture (formerly EM64T), i.e. the architecture that
Microsoft calls x64, and AMD called x86-64 before calling
o, and no. No: it's not an intermediate step, and no, supporting 3.x
does *not* require dropping 2.5.
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
t want us to use the term x86-64 anymore, but wants us
to use AMD64 instead. I think we should comply - they invented the
architecture, so they have the right to give it a name. Neither
Microsoft nor Intel have such a right.
Regards,
Martin
___
Python-Dev ma
a right.
>>
>
> I think we should use whatever is most informative and least confusing
> to our users - we owe our allegiance to them and not to a processor vendor.
And why do you think this is x86-64?
Regards,
Martin
___
to 2.8
only, and get that work with little effort, or whether they would port
to 2.5 and later, and put in more work, I don't know - I guess we would
have to ask these people. I would expect that they prefer if 2.x
died rather sooner than later, because th
naries" you are referring to most definitely don't run on Itanium,
even though that's an Intel chip.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
rely true. There are several places in the
APIs where Microsoft either allows or requires to call the architecture
AMD64 (e.g. architecture indication in MSI files).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
course, I don't know what Ralf uses it for.
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
Enjoy this release,
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:
when the next bug fix release will
be made, often in response to developers asking for one.
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
lues of S,
S == unicode(S) and hash(S) != hash(unicode(S))
That, in turn, *will* break dictionaries.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/
n the application, not in Python.
> I'll patch things to remove the isatty conditional if that's acceptable.
It will make your Python release incompatible with everybody else's,
and will probably lead to moji-bake. Otherwise, it's fine.
Regards,
Martin
__
files, which indeed defaults to the locale encoding (and CP_ACP
on Windows specifically - which may or may not be cp1252).
The default encoding (i.e. the one you could theoretically set
with sys.setdefaultencoding) in 3.x is UTF-8.
Regards,
Martin
___
Python-D
arget Python
2.7 if you wanted to, until beta 1. Having missed alpha 1 is no
really limitation. OTOH, I support the idea of not adding it to 2.7,
e.g. to reduce the maintenance effort, and not introduce a new risk
for the last 2.x release.
Regards,
Martin
___
> It's true that as Martin said, we can rebase our code to Py3K in a
> branch on python.org any time we like, the question is more "if we do
> the work, will the Python community accept it".
I've stated my personal preference already. Let me add an observation on
complete list, you'll need to perform a thorough code review.
For a few examples where some kind of default encoding is applied,
consider XML and the dbm interfaces.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
may be required to use the same C++ compiler throughout
the entire application. Building Python without JIT then might be the
best option.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
e app bundles using py2exe or py2app).
>
> When we link against LLVM as a shared library, LLVM will still all be
> loaded into memory, but it will be shared between all python
> processes.
Even if you don't, it will *still* be shared, since the operating system
will also share execu
> How large is the LLVM shared library? One surprising data point is that the
> binary is much larger than some of the memory footprint measurements given in
> the PEP.
Could it be that you need to strip the binary, or otherwise remove
unneeded debug information?
Regard
s" is a bit of an exaggeration, though. It embeds the byte
code into the executable. When loading the byte code, Python still has
to perform unmarshalling.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
mpile two binaries, 'python' which is
> smaller and doesn't contain the JIT, and jit-python, which is much
> larger and contains LLVM.
I wonder whether the JIT compiler could become a module, which, when
loaded, replaces a few function
go beyond freeze, and contain actual
machine code.
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
Reid Kleckner wrote:
> On Thu, Jan 21, 2010 at 4:34 PM, "Martin v. Löwis" wrote:
>>> How large is the LLVM shared library? One surprising data point is that the
>>> binary is much larger than some of the memory footprint measurements given
>>> in
>
sharing: much
of what lives in pyc files are actual Python objects, which need to
be reference-counted; doing this in a shared fashion is not feasible.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
me platforms and blow up or use the
> wrong encoding on other platforms.
Correct. Also, data output on some platform will be unreadable on some
other platform.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
nux has established one which at least the Intel
compiler complies with).
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
on systems with a global symbol space (and RTLD_GLOBAL
loading), symbols in shared libraries loaded from unrelated contexts
may conflict.
This is one of the motivations to rename the init functions in 3.x.
Regards,
Martin
___
Python-Dev mailing list
Python-De
urvives a reboot, and proceeds only if the system is
otherwise IDLE - so on an Itanium 1 system, it sometimes took about a
day until it caught up.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
of ambiguity: it is the
locale that the user (or his administrator) has selected, which
identifies the language that they speak and the character encoding
they use for text. So if Python also uses that encoding, it's not
really an ambiguous guess.
Regards,
Martin
__
n Windows, it's
code page 1252. Microsoft doesn't support changing it to UTF-8
(although they do support changing it to other values). To verify
that you are still using the vendor default, check out the regional
settings in control panel.
Regards,
Martin
__
or arbitrary text files which are normally meant for data exchange.
Hmm - what do you mean by "normally"? Normally, text files are meant
for human readers, not for exchange between programs.
Regards,
Martin
___
Python-Dev mailing list
Python-De
fortunate
if you were merely performing some simple text replacement.
So whatever the API - there's always tradeoffs.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
ose to text IO, and whether he then would
be able to conclude that cat(1) is really about binary IO).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
27;s complicated not because it's difficult to use, but because
you first need to grasp this entire unicode stuff. So if the easy
way wasn't the default, you are lost with the error message you
get, and the only word you recognize in it is "unicode", which is,
as far as you know,
ights 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 python-dev
to think about the bytes vs. text problem: we can't
> make that go away by playing whack-a-mole with the edge cases.
Many developers are completely unable to make that choice, as Python 2
has demonstrated.
Regards,
Martin
___
Python-Dev mailing
then linking with ld
results in an unresolved symbol __main.
Not sure whether U-S has any global C++ objects that need construction
(but I would be surprised if it didn't).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http
with either SunPRO or the
gcc release that happened to be installed on the system (Solaris
installation sometimes feature fairly odd g++ versions).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
ple embedding Python on such
systems. They have to adjust their build process as well.
(they probably will need to make adjustments for C++ even on ELF
systems, as you still need to run C++ as the linker when linking
libpythonxy.a, to get the C++ runtime linked)
Regards,
Martin
_
rs, e.g. for machine code, it would surely be desirable
to have them constructed with Py_Initialize and destroyed with
Py_Finalize (so that the user sees the memory being released). If they
are merely global flags of some kind, they don't matter much.
Regards,
Martin
__
ery clear semantics in this matter:
Any global object can be used in the translation unit where it is
defined after the point where it is defined. So if you arrange for all
accessors to a global object to occur after its definition, you don't
need to worry about initialization ord
tten by its proponents.
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, rather
than abusing the Python list for one.
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
.x and 3.x, as well as for features,
and branches with the clones for releases and maintenance (see the
PEP for details).
Anybody working on this should have good knowledge of the Python source
code, Mercurial, and either autoconf or Visual Studio (preferably both).
Regar
on module for 3.2, 3.3, 3.4, etc, with
or without U-S.
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
y changes allowed for 2.6 are bug fixes. That a change is backwards
compatible (in some sense) is not sufficient - there must also be a bug
that gets fixed by backporting this change.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
h
one of the Python versions is the "system python"
in Debian. This is the one who decides the official .pyc magic. The
other Python installations on the same system can either reuse the
existing .pyc files (if the magic matches), or not, in which case they
have to recompile (to memory) the Pyt
e back to writer/writer
races).
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
tion, we have run out of ideas
how to solve all related problems simultaneously without changing
Python, so let's look for options that do involve changing Python".
If you *really* want a list of all the simultaneous problems that
need to be solved, and an explanation of why each indivi
was actually what the first draft proposed. Try specifying it in
full detail, and you'll find out that
a) it is *really* complicated, and
b) locking is really tricky to achieve.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
er is updated.
It would actually be possible to drop the magic numbers 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
ou might import dom.minidom (assuming you put the xml folder into
sys.path). Then, a new pyc file would be created in the pyc folder for
the dom package.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
.pyr, either.
If a single pyc folder is used, I think an additional __source__
attribute would be needed to indicate what source file time stamp had
been checked (if any) to determine that the byte code file is current.
Regards,
Martin
___
Py
gt; versions of Python without getting an admin to compile the .py tree
> with the new compiler.
This is PEP 304, which has been withdrawn by its author. While there
is some relationship with PEP 3147, the two address orthogonal issues.
Regards,
Martin
___
spirit of making it a high quality PEP. If the motivation is
> "the Debian devs have concluded, after years of experimentation...",
> then I suppose that's what should go in the motivation section.
I guess Barry will have to explain what the problem with the current
scheme is.
Re
ry if you found a .py file earlier.
If that is the policy, then a __pycache__ directory in a zipfile would
have no effect (and rightly so). Instead, to run code from bytecode,
the byte code files should be on sys.path themselves (probably still
named the same way as they are named inside __py
on that they just read (and indeed, in the patch,
you claim that readers *are* unable to understand how command lines
work). I know that Raymond Hettinger is very much opposed to this style
of documentation. So I, whose native language is not English, cannot
approve/apply this patch. Tr
ment.
How do you write to a zipfile while others are reading 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
1301 - 1400 of 5755 matches
Mail list logo
