cept and most
like contains issues with ssize_t -> long transitions. But it's working.
With the latest svn checkout all tests are passing for 2.4.5, 2.5.2 and
2.6.0 on my 64bit Ubuntu box. Somebody needs to test it on Windows,
32bit Linux
d 2.5. Jesse
is looking into it.
Christian
___
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
rsion including Windows binaries.
Christian
___
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
are waiting for Barry as well.
Maybe we should select an assistant release manager for the next
releases. It's lots of work to handle two releases at the same time. A
single RM is also a single point of failure. You never know when
personal affairs are more important than volunta
ish a rule that *all*
struct members must be initialized properly in the type's tp_new function.
Comments?
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
958,66984,66995-66996,67000,67030-67031
Christian
___
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
NULL for pointers, -1 or 0 for numbers etc.
Python uses malloc to allocate memory. Unless you are using debug builds
the memory block is not initialized. In both cases the block of memory
isn't zeroed. You all know the problems caused by uninitialized memory.
Alexandre Vassalotti wrote:
But what if PyType_GenericAlloc is used for tp_alloc? As far as I
know, the memory block allocated with PyType_GenericAlloc is zeroed.
Oh, you are right. The generic allocator uses memset to initialize the
block with \0.
Christian
64bit platforms. Without a tool like
http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious
to avoid and fix segfaults.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
n't want to use it for
anything critical to the core of Python. I like to keep that C code of
the core as readable as possible.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
, 3rd party tools or
admin privileges?
Christian
___
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
next minor release gets out
* .6 and further releases after 6 months when necessary
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
it's free as in beer. The commercial version has
many more features, but I don't think Python needs them.
The free edition is missing at least one important feature:
Merge Modules into your installation
Create self-contained MSI packages, by including and configuring the
requi
A while ago I contacted Jukka Laurila from the Nokia developer board
about IEEE 754 support on S60 phones. The information from Jukka may be
useful for future reference.
Christian
Original Message
Subject: Re: Python 2.6/3.0, IEEE 754 floating point semantics and S60
We&#x
rch/077424.html
applink.c is just a table of integer constants to function pointers. It
makes mixing of different CRTs secure. You'll get the idea after reading
the file, Martin. A similar approach could be useful for Python, too.
Christian
___
Pyt
at something should be done here. I suggest to add a
function to the imp module that does what you are trying to archive with
tail=True.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
implements exactly
the functionality that is required by Python's import system. Anything
else can be implemented on top of it. We simply prefer divide 'n conquer
over mingle 'n mix. :)
Christian
___
Python-Dev mailing list
P
n message would break existing doc tests.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Martin v. Löwis wrote:
Any objections?
+1
___
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
They are
then merged into release26-maint and py3k branches. Changes for Python
3.0 are merged via the py3k branch.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
oblem seems to be trunk -> py3k -> 3.0. I had no issues with py3k
-> 3.0.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
peedup are good candidates.
Christian
___
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
bout this:
http://bugs.python.org/issue4199
It should be ready for inclusion in 3.0.1.
I'm +0 for the patch. Given the nature of Python 3.0 I'm fine with
getting it right.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http:
Barry Warsaw wrote:
I'm personally okay with performance fixes in point releases, as long it
doesn't change API or add additional features.
Does your okay include or exclude new internal APIs like new helper
functions or a new C modules?
hether performance fixes can be considered
release-critical (which they shouldn't, IMO)?
Maybe I'm a confused person? :]
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
or now interpreter states are used for sub interpreters only.
http://www.python.org/dev/peps/pep-3121/
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
- people are still indoctrinated with the same philosophy ...
Christian
___
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
, many of
Do you really mean 2.5.1?
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Antoine Pitrou schrieb:
> Is anybody opposed to the principle of this proposal?
Is it reasonable to implement multiple policies so the user can switch
between them? Or is the new algorithm superior in all cases?
___
Python-Dev mailing list
Python-Dev@pyt
subinterpreter
has its own state and can see only its own objects.
Christian
___
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
;__eq__', '__format__',
> '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__',
> '__init__', '__iter__', '__le__', '__len__', '__lt__
he
> way PyThreadState_Swap or PyThreadState_DeleteCurrent are used. Those are
> the only two routines which appear to set it.
>
> Did this not happen with 2.5.2?
Wild guess: the bug might be related to
http://bugs.python.org/issue1683. From the top of my head it's the only
major change in the
gcc (I tested on Windows).
The patch makes use of a GCC feature where labels can be used as values:
http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html . I didn't know
about the feature and got confused by the unary && operator.
A happy new your to you all!
Christian
__
st in
http://bugs.python.org/issue4558. It adds a configure option
--with-stdc89 and adds some small fixes to various modules. The
--with-stdc89 is dedicated for our build bots. In the past non ANSI C89
conform pieces of code like 'inline' or '// C++' comments were
committed. The --w
David Cournapeau schrieb:
> Can't those errors be found simply using appropriate warning flags in
> the C compiler ? C has stopped being a subset of C++ a long time ago
Python's C code still follow the ANSI C89 standard. The fact puts 'long
time ago' in a different perspective. :)
___
ith
>
>#include
>
> mean that the needs to be included from then on, even if
> PyFile_FromString stops relying upon it?
stdio.h is included by the Python.h header file anyway. There is simply
on point in declaring fclose() a second time here.
Christian
GUI apps nor NT services have standard streams. You'll probably get it
right :)
Christian
___
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
Brett Cannon schrieb:
> Fine by me. People should be using the context manager for guaranteed
> file closure anyway IMO.
You make a very good point! Perhaps we should stop promising that files
get closed as soon as possible and encourage people in using the with
statement.
Chr
ime soon. As long as Microsoft Visual
Studio support is feasible, we will stick to VS. WINE support is not a
top priority for us.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
pamming the Python developer list with irrelevant, wrong,
confusing and sometimes offensive messages. To be perfectly honest it's
annoying.
If you want to propose a new feature then python-ideas is the right
mailing list. For everything else you should stick to the python-general
or capi-sig
one (eg: my need for shared libs, vs static).
>
> I hope this saves someone else a bit of time. :)
Thanks Patrick! Please open a ticket in our tracker and attach your
patch. Patches in mails tend to get lost.
Christian
___
Python-Dev mailing list
Pyt
some platforms?
How about creating an additional test library ctypes_test_cpp.cpp? This
way we can still run the ctypes tests on a platform without a C++
compiler. Of course you could add some preprocessor magic but that's
just another way to ask for trouble. A second test library should make
i
ad.
We could abuse the state of the ma_lookup function pointer to check the
dict for str only keys. But it would break for unicode keys thus making
from __future__ import unicode_literals useless.
Christian
___
Python-Dev mailing list
Python-Dev@python.or
nd unicode? Should we allow
all subclasses of basestring? Or just str and unicode? Or str only?
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
he 3.x string type, this is
> not a problem for 3.x ;-).
Well, it's always optimized for the str type - which happens to be
PyUnicodeObject in 3.x.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
.
How about clutch? A virtualenv is a clutch of Python eggs, all ready to
hatch. (Pun intended). :)
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
've already blogged about the Linux 3 topic two months ago. You are
welcome to use my posting as a reference.
http://lipyrary.blogspot.com/2011/09/python-and-linux-kernel-30-sysplatform.html
Christian
___
Python-Dev mailing list
Python-Dev@python.or
Am 29.12.2011 02:37, schrieb Jesse Noller:
> Back up link for the PDF:
> http://dl.dropbox.com/u/1374/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
>
> Ocert disclosure:
> http://www.ocert.org/advisories/ocert-2011-003.html
>From http://www.nruns.com/_downloads/advisory28122011.pdf
--
ns or choose to ignore the hash argument and calculate its own
hash of the key.
Christian
___
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
tor for all
possible objects including str, byte, int and so on. I like also Armin's
idea of an optional hash randomization.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
Am 29.12.2011 12:10, schrieb Antoine Pitrou:
>> I've been dealing with web stuff and security for almost a decade. I've
>> seen far worse attack vectors. This one can easily be solved with a
>> couple of lines of Python code. For example Application developers can
>> limit the maximum amount of POS
and several large
frameworks like Zope/Plone require 2.x.
Christian
___
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
altered. The
approach has also the benefit that all possible objects gain a
randomized hash.
> Also related: since this is a security related issue, would this be
> something that goes into Python 2? Does that affect how a fix would
> look like?
IMHO it d
ome vendors have limited to POST request to 1 MB or
the amount of keys to 10,000 to work around the issue. One paper also
states that attacks on Python with 64bit is just academical for now.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http
Am 29.12.2011 23:28, schrieb Terry Reedy:
> As I understood the talk (actually, the bit of Perl interpreter C code
> shown), the randomization is to change hash(s) to hash(salt+s) so that
> the salt is completely mixed into the hash from the beginning, rather
> than just tacked on at the end.
Y
Am 31.12.2011 03:31, schrieb Victor Stinner:
> Le 29/12/2011 14:19, Christian Heimes a écrit :
>> Perhaps the dict code is a better place for randomization.
>
> The problem is the creation of a dict with keys all having the same hash
> value. The current implementation of dict
as still in holiday mode
and it took me a while to figure out the math. Sorry for any confusion!
Christian
___
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
tographic hash functions are far too
slow for our use case. During my research I found another hash function
that claims to be fast and that may not be vulnerable to this kind of
attack: http://isthe.com/chongo/tech/comp/fnv/
Christian
___
Python-Dev mai
Am 31.12.2011 13:03, schrieb Stephen J. Turnbull:
> I don't know the implementation issues well enough to claim it is a
> solution, but this hasn't been mentioned before AFAICS:
>
> While the dictionary probe has to start with a hash for backward
> compatibility reasons, is there a reason the over
mization
IMHO the issue needs a PEP that explains the issue, shows all possible
solutions and describes how we have solved the issue. I'm willing to
start a PEP. Who likes to be the co-author?
Christian
___
Python-Dev mailing list
Python-Dev@
Am 31.12.2011 23:38, schrieb Terry Reedy:
> On 12/31/2011 4:43 PM, PJ Eby wrote:
>
>> Here's an idea. Suppose we add a sys.hash_seed or some such, that's
>> settable to an int, and defaults to whatever we're using now. Then
>> programs that want a fix can just set it to a random number,
>
> I d
ailable that works on Python 2.5 -- personally I do
> have a need for a 2.5 fix and if nobody creates one I will probably end
> up backporting the fix from 2.6 to 2.5.
+1
Should the randomization be disabled on 2.5 to 3.2 by default to reduce
backward compatibility issues?
Christian
(in a way that they are still compatible with each other).
>
> Do str and bytes still have to be compatible with each other in 3.x?
py3k has tests for hash("ascii") == hash(b"ascii"). Are you talking
about this invariant?
Christian
___
rieve lots of single
character hashes. The randomization shouldn't be used if we can prove
that it's not possible to create hash collisions for strings shorter
than X. For example 64bit FNV-1 has no collisions for 8 chars or less,
32bit FNV has no collisions for 4 or less cars.
Christian
Am 01.01.2012 17:09, schrieb Antoine Pitrou:
> On Sun, 01 Jan 2012 16:48:32 +0100
> Christian Heimes wrote:
>> The talkers claim and have shown that it's too easy to pre-calculate
>> collisions with hashing algorithms similar to DJBX33X / DJBX33A. It
>> might be a go
the algorithm. The
talk at the CCC conference in Berlin mentions that Ruby 1.9 is not
vulnerable to meet-in-the-middle attacks and Ruby 1.9 uses FNV. The C
code of FNV is more complex than our code, too.
Christian
___
Python-Dev mailing list
Python-
Am 01.01.2012 01:11, schrieb Guido van Rossum:
> FWIW I managed to build Python 2.6, and a trivial mutation of the
> string/unicode hash function (add 1 initially) made only three tests
> fail; test_symtable and test_json both have a dependency on dictionary
> order, test_ctypes I can't quite figur
r more hash slots on str/bytes/unicode instances.
Christian
PS: Something is wrong with your email client. Every of your replies
starts a new thread for me.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
But in fact it seems to be faster!
Pybench 10 rounds on my Core2 Duo 2.60:
py3k: 3.230 sec
randomahash: 3.182 sec
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
BDFL), Barry (their initial
security contact) and MvL (most prominent German core dev) in CC, as
they are the logical choice for me.
I'm willing to have a phone call with them once the contact has been
established. IMHO it's slightly easier to talk in native tongue --
Al
m_random()
void _Py_MT_GenRand_Init(_Py_MT_RandomState *state, unsigned long seed);
// init_genrand()
void _Py_MT_GenRand_InitArray(_Py_MT_RandomState *state, unsigned long
init_key[], unsigned long key_length); // init_by_array
I suggest Python/random.c as source file and Python/pyrandom.h a
the random module. New
developers and new ideas are well received.
Regards,
Christian
___
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 between Christmas and New Year. I don't
normally use MS as reference but this should give you a hint about the
severity.
Have you watched the talk yet? http://www.youtube.com/watch?v=R2Cq3CLI6H8
Christian
___
Python-Dev mailing list
Python-Dev@p
s a small and quick solution, so I stopped working on
it. However the arguments, worries and ideas in this enormous topic have
repeated over and over. We know from experience that a PEP is a great
way to explain the how, what and why of the change as well as the paths
we didn't take.
Christian
_
SON, a malicious PDF,
JPEG's EXIF metadata or any other data.
Oh, and somebody has to fix all 3rd party modules, too.
Christian
___
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
there's no reason why a patch for versions
> older than 2.6 couldn't be included on a python.org security
> page for reference in CVE or other security notifications.
> Distros that care about versions older than Python 2.6 will
> basically
is in effect.
This might not work as we have to special case empty strings and perhaps
\0 strings, too. Otherwise we would give away the random seed to an
attacker if an attacker can somehow get hold of hash('') or hash(n * '\0').
Christian
Am 06.01.2012 03:04, schrieb Benjamin Peterson:
> It's obscure because hash('') != 0 doesn't necessarily mean the hashes
> are randomized. A different hashing algorithm could be in effect.
Also in 1 of 2**32 or 2**64 tries hash('') is 0 althou
ner loop of the current algorithm is more tight.
> Admittedly, this may require some adaptation for the PEP393 unicode memory
> layout in order to produce identical hashes for all three representations
> if they represent the same content. So it
od(node, results)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/fixes/fix_operator.py",
line 89, in _check_method
method = getattr(self, "_" + results["method"][0].value.encode("ascii"))
TypeError: Can't convert 'bytes' o
This compensates for possible symlink attacks, too.
Christian
Shell session example of cp and install
===
$ echo "test1" > test1
$ echo "test2" > test2
$ ln test1 test_hardlink
now test_hardlink points to the same inodes as test1
$ cat tes
checker.py?rev=25177&view=auto
The importorder tool uses the tokenizer module to order import statements.
http://svn.zope.org/Zope3/trunk/utilities/importorder.py?rev=25177&view=auto
Both are written by Jim Fulton.
Christian
___
Python-Dev m
Am 06.02.2012 18:57, schrieb Brett Cannon:
> Ah, but does it run against Python 3? If so then this is something to
> suggest on python-mentor for someone to get their feet wet for contributing.
Probably not, the code was last modified seven years ago. The compiler
package has been removed from Py
bootstrap the hidden iterable types.
I even would like to propose a PEP:
Whenever stuff is turned into C, which was picklable when implemented
in Python, or something new is implemented that makes sense to
pickle, a pickle implementation should always be provided.
cheers -- chris
--
Christian
Parallels or Virtualbox quite often.
There the "wall clock" stuff notoriously does not work.
It would be good (but difficult?) if the supposed-to-be-accurate
clock could test itself, if it works at all, and replace itself
with a fallback.
In my case, this causes quite a few PyPy tests
s hardware where this api fails (virtual or
not?) Perhaps there is no real need to have a fallback mechanism, and it would
even be best to write such a mechanism inside the function itself, and just
return getsystemtimeasfiletime() instead.
K
-Original Message-----
From: Christian Tismer [
e call thos functions and where would the live?
pkg_resources has a similar API [1] that supports dotted names.
pkg_resources also does some caching for files that aren't stored on a
local file system (database, ZIP file, you name it). It should be
trivial to support both dotted
to the temporary directory the first time it's accessed.
The get_file() feature has a neat benefit. Since it transparently
extracts files from the loader, users can ship binary extensions and
shared libraries (dlls) in a ZIP file and use them without too much hassle.
Christian
, I just would like to understand why.
cheers -- chris
--
Christian Tismer :^)<mailto:tis...@stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam
On 27.04.12 02:39, Nick Coghlan wrote:
On Fri, Apr 27, 2012 at 7:30 AM, Christian Tismer wrote:
No big deal and easy to work around, I just would like to understand why.
I don't like it either and want to change it, but I'm also not going
to mess with it until the importlib bootst
On 27.04.12 22:00, Brett Cannon wrote:
On Fri, Apr 27, 2012 at 10:39, Christian Tismer <mailto:tis...@stackless.com>> wrote:
On 27.04.12 02:39, Nick Coghlan wrote:
On Fri, Apr 27, 2012 at 7:30 AM, Christian
Tismermailto:tis...@stackless.com>> wrote:
the real question I was after was "can os.chdir() be freely used?"
It would be great to get "yes" or "no", but the answer is right now "it
depends".
cheers - chris
--
Christian Tismer :^)<mailto:tis...@stackless.com>
tismerysoft
full path etc.
is deeply hidden in a C function as a side effect. Brr!
It would be much cleaner and easier if that stuff would be ignored
today and called a Python implementation, instead.
Is that in the plans to get rid of C for such stuff? I hope so :-)
cheers -- Chris
--
Christian
recent
versions of Debian (and Ubuntu), 64bit and 32bit libraries can coexist
on the same system.
What's the output of "dpkg-architecture -qDEB_HOST_MULTIARCH" on your
system? It should print out "x86_64-linux-gnu". setup.py supports
multiarch for some time, see PyBuildExt.a
Am 05.05.2012 15:39, schrieb Antoine Pitrou:
> On Sat, 05 May 2012 15:31:24 +0200
> Christian Heimes wrote:
>> Am 05.05.2012 12:36, schrieb Antoine Pitrou:
>>>
>>> Hello,
>>>
>>> On Fri, 04 May 2012 14:07:28 -0400
>>> "Edward C. J
ian based distro
return
if not find_executable('dpkg-architecture'):
print "Warning, Debian detected but no dpkg-architecture found.
Please run 'sudo apt-get install build-essential'.
return
Christian
___
Python-Dev mailing list
Py
the
best example for clean code that is consistent with the docs.
Is the usage of dir() correct in this context or is the doc right?
It would be nice to add a sentence of clarification if the use of
dir() is in fact the correct way to implement inspect.
cheers - chris
--
Christian Tismer
On 21.05.12 07:52, Stefano Taschini wrote:
On 21 May 2012 03:36, Guido van Rossum <mailto:gu...@python.org>> wrote:
[...]
I have to agree with Christian that inspect.py is full of hacks and
heuristics that would be fine in a module that's part of a user's a
and thus sets linux3 on
Kernel 3.0 and newer. You have fix it yourself as described in my blog
http://lipyrary.blogspot.de/2011/09/python-and-linux-kernel-30-sysplatform.html
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
ciate this effort very well, as we are heavily using virtualenv
in a project.
One urgent question: will this feature be backported to Python 2.7?
We still need 2.7 for certain reasons (PyPy is not ready for 3.x).
cheers - chris
--
Christian Tismer :^)<mailto:tis...@stackless.com
1001 - 1100 of 1220 matches
Mail list logo
