[Python-Dev] (no subject)

[Frank]

hi,
test mail list :)



致
礼！


Frank
[EMAIL PROTECTED]
　　2005-11-25
___
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

Re: [Python-Dev] Draft PEP 385: Migrating from svn to Mercurial

[Frank Wierzbicki]

At PyCon, we discussed moving Jython's svn repository to Python's with
Martin von Löwis.  I would think that Jython would live in Python's hg
repository in the same way as stackless and distutils.  Has the
parallel project strategy been determined?  Will they be separate
repositories, separate "forests", something else?

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?

-Frank
___
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

Re: [Python-Dev] Draft PEP 385: Migrating from svn to Mercurial

[Frank Wierzbicki]

On Mon, Jun 8, 2009 at 11:32 AM, Dirkjan Ochtman wrote:
> I'd say migrating to Python's svn doesn't make a whole lot of sense at
> this point, but I'll leave that to Martin (since he has to do the
> work). For the conversion, I can just as well take the Jython repo
> from your current server. I've started a svnsync job with your repo so
> I can run some test conversions. It's a relatively small repository,
> so it shouldn't be much of a problem.
Great!  Thanks for giving this a try!

For my part I'm fine either way (and I agree that Martin should decide
based on what is best  for him).

-Frank
___
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

[Python-Dev] Tweaking AST lineno and col_offset

[Frank Wierzbicki]

Hi all,

Off and on I have been directly comparing Jython's AST with Python's
AST and generally working towards making them as close to identical as
possible.  There are a couple of places where I haven't "fixed" Jython
because it looks to me like Jython has slightly better offsets.  One
example:

for a,b in c:
pass

The Tuple node "a,b" ends up with a col_offset of 0 (the position of
the "for") where Jython has the col_offset as 4 (the position of "a").
 Jython's result is more consistent with other Tuple node col_offset
results.

I have a local patch that changes the CPython col_offset to match
Jython's, but before I submit a patch I thought I'd ask here if there
is support for this sort of change and if I should continue to find
col_offset and lineno results that look fishy to me, or should I just
change Jython's results to match (one way or another, things will be
much easier for me to test if they match).

Also, would this be a change that would be considered a backwards
incompatibility?  In other words, would patches like this be allowed
in 2.6/3.1 or only in 2.7/3.2.

Regards,

-Frank
___
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

Re: [Python-Dev] Tweaking AST lineno and col_offset

[Frank Wierzbicki]

On Fri, Aug 14, 2009 at 12:16 PM, Benjamin Peterson wrote:

>> I have a local patch that changes the CPython col_offset to match
>> Jython's, but before I submit a patch I thought I'd ask here if there
>> is support for this sort of change and if I should continue to find
>> col_offset and lineno results that look fishy to me, or should I just
>> change Jython's results to match (one way or another, things will be
>> much easier for me to test if they match).
>
> Yes, please submit it.
Great, the patch is here: http://bugs.python.org/issue6704

 BTW - I would have added a test to test_ast.py, but above the test
data it notes:  EVERYTHING BELOW IS GENERATED # and I couldn't
find the tool used for the generation.  Does anyone know where that
is?

-Frank
___
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

Re: [Python-Dev] Tweaking AST lineno and col_offset

[Frank Wierzbicki]

On Fri, Aug 14, 2009 at 3:11 PM, Benjamin Peterson wrote:
> 2009/8/14 Frank Wierzbicki :
>> On Fri, Aug 14, 2009 at 12:16 PM, Benjamin Peterson 
>> wrote:
>>
>>>> I have a local patch that changes the CPython col_offset to match
>>>> Jython's, but before I submit a patch I thought I'd ask here if there
>>>> is support for this sort of change and if I should continue to find
>>>> col_offset and lineno results that look fishy to me, or should I just
>>>> change Jython's results to match (one way or another, things will be
>>>> much easier for me to test if they match).
>>>
>>> Yes, please submit it.
>> Great, the patch is here: http://bugs.python.org/issue6704
>
> I'll take a look.
>
>>
>>  BTW - I would have added a test to test_ast.py, but above the test
>> data it notes:  EVERYTHING BELOW IS GENERATED # and I couldn't
>> find the tool used for the generation.  Does anyone know where that
>> is?
>
> It's at the bottom of the test file. :) You can add a handwritten test
> above that, though.
Heh -- how did I miss that :) ? -- I'll resubmit the patch with tests.

-Frank
___
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

Re: [Python-Dev] Tweaking AST lineno and col_offset

[Frank Wierzbicki]

On Fri, Aug 14, 2009 at 3:41 PM, Frank Wierzbicki wrote:
>> It's at the bottom of the test file. :) You can add a handwritten test
>> above that, though.
> Heh -- how did I miss that :) ? -- I'll resubmit the patch with tests.
Resubmitted http://bugs.python.org/issue6704 with tests.

-Frank
___
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

Re: [Python-Dev] Tweaking AST lineno and col_offset

[Frank Wierzbicki]

On Fri, Aug 14, 2009 at 5:57 PM, Brett Cannon wrote:
> I like the improvement, but I disagree it should be considered for
> backporting as it changes semantics for something that could be considered a
> bug, but that feels like a stretch.
Just thought I'd ask -- I'm perfectly ok with the change being 2.7/3.2 only.

-Frank
___
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

[Python-Dev] Updating tests in branches

[Frank Wierzbicki]

I plan on updating the Python unit tests with tests from Jython that
turn out to be generic Python tests.  Should I be putting these tests
into trunk and 3k or should I also put them into the 2.6 and 3.1
maintenance branches as well?

Regards,

-Frank
___
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

Re: [Python-Dev] Updating tests in branches

[Frank Wierzbicki]

On Sun, Aug 16, 2009 at 11:45 AM, Benjamin Peterson wrote:
> 2009/8/16 Frank Wierzbicki :
> Usually, unless the test is for a bug we are backporting, new tests
> only go in the trunk and py3k.
Thanks! I'll do that from now on.

-Frank
___
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

[Python-Dev] Two laments about CPython's AST Nodes

[Frank Wierzbicki]

Before I start complaining, I want to mention what a huge help it has
been to be able to directly compare the AST exposed by ast.py in
making Jython a better Python.  Thanks for that!

Now on to the complaints: Though I recently added support for this in
Jython, I don't like that nodes can be defined without required
attributes, for example:

node = ast.Assign()

Is valid, even though it requires "node.targets" and "node.value" (I'm
less concerned about the required lineno and col_offset, as I can
understand holding off on these so that you can just use
fix_missing_locations to fill these in for you).

My other (bigger) gripe is that you can define these values with
arbitrary objects that will blow up at parse time.  So for example you
can write:

node = ast.Assign()
node.targets = "whatever"

Which, when you try to parse, blows up with "TypeError: Assign field
"targets" must be a list, not a str".  I'd be much happier if this
blew up right away when you try to make the assignment.  At the
moment, this is how it works in Jython (though I could support this
with some contorting).

BTW -- I *am* volunteering to attempt to implement these things in
CPython if there is support :)

-Frank
___
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

Re: [Python-Dev] Two laments about CPython's AST Nodes

[Frank Wierzbicki]

On Wed, Aug 19, 2009 at 5:00 PM, "Martin v. Löwis" wrote:
>> Now on to the complaints: Though I recently added support for this in
>> Jython, I don't like that nodes can be defined without required
>> attributes, for example:
>>
>> node = ast.Assign()
>
> I think we disagree in two points in our evaluation of this behavior:
>
> a) ast.Assign is *not* a node of the CPython AST. The CPython AST is
>   a set of C structures in Include/Python-ast.h. ast.Assign is merely
>   a mirror structure of that.
Ah -- that is different from Jython's current design (The nodes that
are constructed by ast.Assign() in Jython actually are the exact nodes
that are used in real parsing)

> b) it is, IMO, not reasonable to require users who create AST trees
>   out of nothing to have correct trees at all times. I.e. it must be
>   possible to represent incorrect trees.
That does seem reasonable.  Luckily it was easy to implement for me :)

> c) the AST is *not* part of the Python language or library. It may
>   change at any time without notice, and Jython is not required to
>   duplicate its behavior exactly.
Sure, I'm really just talking about ast.py (though for Jython ATM they
are the same thing).  So that I understand better: when this call is
made in Python:

x = compile("def foo():pass", "foo", "exec", _ast.PyCF_ONLY_AST)

Does x contain real AST nodes or does it contain mirror structures
(feel free to just tell me: don't be lazy, go read the code). If it
contains real nodes, this is where I have some implementation trouble.
 If a tree of real nodes is then manipulated so that you end up with a
mix, I don't want to walk the entire thing over again to find the
mirror objects (that might be incomplete) and replace them with real
nodes.  If this creates a tree of mirror nodes, then I may want to
consider doing the same thing on the Jython side (it makes sense, now
that I understand CPython better I realize that the cost I am
incurring is probably due to having the real and mirror AST as the
same beast).

> [so that's three items - as there should be in any good list of
> two items :-]
:)

> What precisely is it that makes this difficult to implement. If you
> would follow CPython's implementation strategy (i.e. generate glue
> code out of ASDL), I feel that it should be straight-forward to provide
> exactly the same behavior in Jython.
I do use the ASDL to generate this stuff, but again, the real and the
mirror nodes are not separated ATM, and that is what makes it
difficult.

>> BTW -- I *am* volunteering to attempt to implement these things in
>> CPython if there is support :)
>
> I'm not sure I can support such a change. Giving the child nodes at
> creation time, optionally, would be fine with me. Requiring the
> tree to conform to the grammar at all times is unreasonable, IMO
> (you can't simultaneously create all nodes in the tree and glue
> them together, so you have to create the tree in steps - which means
> that it will be intermittently incorrect).
That is quite reasonable, I'll withdraw gripe #1 -- in fact the reason
I have already implemented this in Jython is that there is already
real world use out there.  I still need to understand gripe #2 a
little better before I back down on that one.

-Frank
___
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

Re: [Python-Dev] Two laments about CPython's AST Nodes

[Frank Wierzbicki]

On Thu, Aug 20, 2009 at 6:11 PM, "Martin v. Löwis" wrote:
> Couldn't you just generate a check function for your tree that
> would be invoked before you try to process a tree that a
> script got access to?
That would be one way, though now that I understand CPython's AST
design better, I am tempted to follow the lead.  If I had a private
AST and and a public mirror for ast.py, the design could become much
simpler, and probably faster for normal parsing.

> If you are asking that a type check is made on assigning a value to
> these fields - I'm not quite sure whether you could implement that
> check reliably. Wouldn't it be possible to bypass it by filling a
> value directly into __dict__?
>
> If you can come up with a patch that checks in a reliable manner,
> I would be in favor of adding that (in 2.7 and 3.2), taking out
> the corresponding checks when converting to the internal AST.
Great, I may give it a try, but changing the AST impl  for Jython 2.6
will probably be my short term answer.

-Frank
___
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

Re: [Python-Dev] 3to2 0.1 alpha 1 released

[Frank Wierzbicki]

On Wed, Aug 26, 2009 at 3:29 PM, Joe Amenta wrote:
> Hello all,
>
> I have released the first alpha version of 3to2 after finishing it for my
> Google Summer of Code 2009(tm) project.

Wow, congratulations!

-Frank
___
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

Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations

[Frank Wierzbicki]

On Tue, Sep 22, 2009 at 5:55 PM, Dino Viehland  wrote:
> For IronPython we wrote a set of tests which go through and define
> the various operator methods in all sorts of combinations on both
> new-style and old-style classes as well as subclasses of those classes
> and then do the comparisons w/ logging.
We've talked about this before, but now I'm reminded again -- do you
happen to have a pointer to these tests just in case someone might
want to grab them :) ?

-Frank
___
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

Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations

[Frank Wierzbicki]

On Tue, Sep 22, 2009 at 11:43 PM,   wrote:
>
>    Dino> For IronPython we wrote a set of tests which go through and define
>    Dino> the various operator methods in all sorts of combinations on both
>    Dino> new-style and old-style classes as well as subclasses of those
>    Dino> classes and then do the comparisons w/ logging.
>
> It would be very nice if these complex corner cases had a set of test
> cases which could be run by all implementations (CPython, Jython,
> IronPython, PyPy, etc).  I don't know.  Maybe the CPython test suite serves
> that purpose, but it seems like it would be helpful if this sort of
> "validation suite" was maintained as a separate project all implementations
> could use and contribute to.
Talk has started up again on the stdlib-sig list about finding a core
stdlib + tests that can be shared by all implementations, potentially
living apart from CPython.  I have volunteered to put together a PEP
on the subject, with Jessie Noller and Brett Canon are helping me out.
 When I have something worth showing, I'll start the real PEP process.

-Frank
___
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

Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations

[Frank Wierzbicki]

On Tue, Sep 22, 2009 at 9:15 PM, Dino Viehland  wrote:
> And the latest version there is in:
>
> IronPython_Main\Src\Tests\compat
>
> Hopefully the infrastructure will just work on Jython because it also runs on
> CPython but there may be some Windows specific code in there (e.g. import nt,
> a general problem w/ our tests from the days before we always ran tests w/
> the CPython std lib present).
>
> If you run into any problems let me know and I'd be happy to fix it to make
> them more compatible.
Great, thanks!  I'll take a look (for real this time :)

-Frank
___
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

Re: [Python-Dev] PEP 370 and IronPython

[Frank Wierzbicki]

On Thu, Oct 8, 2009 at 7:17 AM, Christian Heimes  wrote:
> CPython:
>  ~/.local/lib/python2.6/site-packages
>  %APPDATA%/Python/Python26
>
> IronPython:
>  ~/.local/lib/ironpython2.6/site-packages
>  %APPDATA%/Python/IronPython26
>
> Jython:
>  ~/.local/lib/jython2.6/site-packages
>  %APPDATA%/Python/Jython26
I like this too!  Jython has yet to seriously start on 2.6, but when
we do, would it help if Jython's sys.version grew a "Jython" in a
similar place as IronPython?  It would look something like:

>>>sys.version
'2.6.0 (Jython trunk:6849M, Oct 9 2009, 14:19:04) \n[Java HotSpot(TM)
Client VM (Apple Inc.)]'

-Frank
___
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

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

[Frank Wierzbicki]

On Fri, Oct 9, 2009 at 8:42 PM, "Martin v. Löwis"  wrote:
> I think it is important to confirm in advance that all the
> implementations listed below agree to implement the PEP "soonish" after
> it's adopted. "Required" sounds like a strong term - however, if an
> implementation chooses not to implement the PEP, it can do whatever it
> wants, including omission of required fields.
Speaking for Jython, so far it looks like something we would adopt
soonish after it was accepted (it looks pretty useful to me).

> So I propose that the python.org version is identified as "python".
I'll add my voice to the group that likes "cpython" and "CPython" as
the identifier of the python.org implementation.  This version has a
long history, and "Classic Python" has a nice sound to it.  :) -- also
I hope (but won't hold my breath) that Python becomes more associated
with the abstract language in time.

-Frank
___
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

Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory

[Frank Wierzbicki]

On Fri, Oct 9, 2009 at 8:34 PM, "Martin v. Löwis"  wrote:
> Also, why is it the name of the JIT compiler, and not the name of the
> source language compiler?
>From the Jython side it is easier to get the VM name compared to the
source language compiler.  Although there is a property on
java.lang.System called "java.compiler" it is often empty.

-Frank
___
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

Re: [Python-Dev] First draft of "sysconfig"

[Frank Wierzbicki]

On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziadé  wrote:
> and for Linux and al, I am not sure but maybe a prefix for
> Jython/etc.. could be used
> for all paths.
>
> ~/.locale/lib/python/2.6/site-packages/...
> ~/.locale/jython/lib/python/2.6/site-packages/...
>
> (I didn't digg on how Jython organizes things yet, any hint would be
> appreciated)
Jython does not yet support user site-packages, but I think the above
looks like a fine structure for us when we get to implementing it.

-Frank
___
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

[Python-Dev] Mercurial move?

[Frank Wierzbicki]

An advantage of being at PyCon :)

We *may* be able to get on mercurial very fast -- since all of the
interested parties are here. I'm going to get an svndump now -- the
downside to this is whatever anyone checks in during this in between
stage would need to get re-checked in after we move.

I'll let you know how it goes.

-Frank
___
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

Re: [Python-Dev] Mercurial move?

[Frank Wierzbicki]

On Mon, Feb 22, 2010 at 5:45 PM, Frank Wierzbicki  wrote:
> An advantage of being at PyCon :)
>
> We *may* be able to get on mercurial very fast -- since all of the
> interested parties are here. I'm going to get an svndump now -- the
> downside to this is whatever anyone checks in during this in between
> stage would need to get re-checked in after we move.
>
> I'll let you know how it goes.
Sorry python-dev autocomplete fail -- I meant this to go to
jython-dev, sorry.  Please ignore.
___
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

Re: [Python-Dev] Mercurial move?

[Frank Wierzbicki]

On Mon, Feb 22, 2010 at 6:12 PM, Guido van Rossum  wrote:
> In that case congrats on beating us to the punch!
>
> Let us know how it goes.
Will, do, thanks!

-Frank
___
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

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

[Frank Wierzbicki]

On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski  wrote:
> Hello.
>
> I would like to have a feature on platform module (or sys or
> somewhere) that can tell distutils or distutils2 that this platform
> (be it PyPy or Jython) is not able to compile any C module. The
> purpose of this is to make distutils bail out in more reasonable
> manner than a compilation error in case this module is not going to
> work on anything but CPython.
FWIW this would be helpful for Jython too.

-Frank
___
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

[Python-Dev] Cheeseshop (was Re: Distutils2 scripts)

[Frank Lomax]

On Oct 08, 2010, at 03:40 PM, Brett Cannon wrote:

>Richard Jones is the authority on the story, but from what I can
>remember from the discussion it was decided that managers would have
>had issues with using a service called the Cheeseshop. So basically
>the idea of professional-sounding name won out. I still use
>cheeseshop.python.org to access the package index.

IOW, the Anti-Humor Subcommittee of the PSU (which emphatically does not
exist), a rough outfit which works to promote snakes over British comedy,
quashed the Happy Laughing Working Group and actively (even though they do not
exist) promotes the boring PHB name in all its propaganda.  The HLWG, having
been defunded and thrown out of office (if there was an office, which there
isn't), toils in exile and hopes to one day reclaim the right and one true
name.

Join the revolt to take back Pythonland!  May the Pythonistas defeat the
Pythoneers!  May the Pythoneers vanquish the Pythonistas!

Long live the Cheeseshop!

it's-very-runny-actual-ly y'rs,
-frank
___
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

Re: [Python-Dev] OT: World's oldest ritual discovered. Worshipped the python 70, 000 years ago

[Frank Lomax]

On Dec 2, 2006, at 8:02 AM, Georg Brandl wrote:

> Surely it is. The PSU once used the time machine to travel to Ancient
> Greece and gave the Delphi priestess her name, along with a schoolbook
> about ancient histo

The PSU does not, nor ever has existed.  Any statement implying  
otherwise is false and subversive.  There is no PSU and even if there  
is, it has no influence whatsoev

___
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

Re: [Python-Dev] Google Summer of Code 2007

[Frank Wierzbicki]

On 3/7/07, James Tauber <[EMAIL PROTECTED]> wrote:
> Google's Summer of Code is on again!
>
> I'm in the process of submitting the application for PSF to again be
> a mentoring organization.

> Because I would like core Python projects to be well represented, I
> particularly encourage python-devers to participate.
Just to be sure -- Jython is under the umbrella of the PSF for the
purposes of the SoC, right?

Thanks,

-Frank
___
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

Re: [Python-Dev] Google Summer of Code 2007

[Frank Wierzbicki]

On 3/7/07, James Tauber <[EMAIL PROTECTED]> wrote:
> I would *strongly* encourage the submission of some Jython projects
> under the PSF umbrella.
Great!  I'll do my best to get some submitted.

-Frank
___
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

[Python-Dev] Reserving an arg space for Jython

[Frank Wierzbicki]

Hi all,

I was wondering if it might be possible for Jython to get an "arg
space" for command line execution.  We try to deliver the same
switches that Python delivers (so for example -c means "program passed
in as string" on Python and Jython).  We have some need for arguments
that would be Jython-specific, for example we would like to be able to
pass arguments to the Java process that starts Jython.  I would just
make one up, but it would be best if it was future compatible with
Python (so -J would be great, but it would be annoying if -J started
to mean something in a future Python).

So what do guys say?  Can we hava -J?  I don't think it is being used yet...

-Frank
___
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

Re: [Python-Dev] Reserving an arg space for Jython

[Frank Wierzbicki]

On Fri, Apr 11, 2008 at 1:40 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Works for me. We should have a patch to CPython that looks for -J and
>  rejects it with "-J is reserved for Jython".
Great!  Knowing this crowd it is probably already implemented -- but
if not I'd love to dust off my C skills and upload a patch, I doubt I
would cause harm in this area of Python :)

-Frank
___
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

Re: [Python-Dev] Reserving an arg space for Jython

[Frank Wierzbicki]

Patch is here: http://bugs.python.org/issue2617

-Frank
___
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

Re: [Python-Dev] Reserving an arg space for Jython

[Frank Wierzbicki]

On Fri, Apr 11, 2008 at 2:51 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 11, 2008 at 7:40 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > Works for me. We should have a patch to CPython that looks for -J and
>  >  rejects it with "-J is reserved for Jython".
>  >
>
>  Do we want it to be Jython-specific, or should it be available to any
>  alternative VM? I don't know if the IronPython folks need anything for
>  .NET, but maybe they would like one?
-X was suggested on Jython's irc.  I kind of like -J, but -X would
work for us too.

-Frank
___
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

Re: [Python-Dev] Reserving an arg space for Jython

[Frank Wierzbicki]

On Fri, Apr 11, 2008 at 4:03 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I was also going to suggest a platform independent option.  I like
>  -Xwhat-follows-is-impl-dependent.
This would work just fine for us, and it makes sense to have it
available for all implementations.  If everyone likes this I will
change the patch for CPython accordingly.  How is

-X is reserved for non-standard arguments

-Frank
___
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

Re: [Python-Dev] Reserving an arg space for Jython

[Frank Wierzbicki]

On Sat, Apr 12, 2008 at 12:39 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
>
> >>  -X is reserved for non-standard arguments
>  >
>  > Fine by me.
>
>  And implemented in r62293 (trunk)
Great, thanks!  While I'd love to have *both* -X and -J, is that okay
with the other devs?

-Frank
___
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

Re: [Python-Dev] Optimization of Python ASTs: How should we deal with constant values?

[Frank Wierzbicki]

On Fri, May 2, 2008 at 10:21 AM, Thomas Lee <[EMAIL PROTECTED]> wrote:
> Any Jython folk care to weigh in on this? If there are no major objections I
> think I'm going to forge ahead with an independant Const() node.
I suspect that having a marker for non-int non-str constants could
also be used for some optimization of Jython bytecode emissions as
well, though of course it would depend on the details.  If the path
from raw AST to optimized AST isn't too crazy Jython can just grow the
same logic.  We have really good AST comparison tests these days, so I
bet it won't be a huge problem for us when the time comes.

-Frank
___
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

Re: [Python-Dev] Documentation for ability to execute zipfiles & directories

[Frank Wierzbicki]

On Tue, Mar 4, 2008 at 1:36 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 04, 2008 at 08:58:57AM -0500, Steve Holden wrote:
>> While I hesitate to suggest a change of such magnitude, there's
>> something to recommend the old IBM mainframe approach of separating out
>> "Principles of Operation" (which would be the reference manuals, in
>> Python's case the Language and Library refs) from "Users' Guide" which
>> contains the practical stuff you need to actually make use of a product.
>
> Good suggestion.  Using the debugger and profiler could also be
> covered in the User's Guide.
>
> Would splitting up the docs make them more useful for
> IronPython/Jython?  For example, Jython could eventually take the 2.6
> language docs as-is, but modify the library reference to remove
> unsupported modules and add Jython-specific ones.
Speaking for Jython, this would be extremely helpful for us.  Once we
get caught up, better docs will become one of our most important
priorities I think.

-Frank
___
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

Re: [Python-Dev] Assignment to None

[Frank Wierzbicki]

On Wed, Jun 11, 2008 at 5:27 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:
> If I recall correctly, Jython handles this by appending a trailing
> underscore to the imported name and there's no reason why we couldn't
> do something similar.
In truth the current implementation of Jython allows keywords in many
strange places, I expect this was done to allow for method names that
are not keywords in Java so, for example, if there is a method called
"print" in a Java class that we want to call (quite common) then it
can be called.  As far as I know appended underscores don't enter into
it.  Some poking around reveals that the current Jython is probably
too lax here, even keywords that are common to both Python and Java
can be method names (like "if").  I plan to continue to allow Python
keywords that are not Java keywords to behave this way at least for
the 2.x series, though I don't think I'm going to go through the
effort of allowing keywords common to both Java and Python like "if"
(The 2.5 version of Jython will have a new parser so I do actually
need to make these explicit choices right now).  I think changing this
behavior would hurt backwards compatibility too much.  Maybe I'll
rethink it in our 3.0 timeframe.  If a convention like a trailing
underscore is adopted we might move to that in the move to 3.0.

-Frank
___
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

Re: [Python-Dev] bug or a feature?

[Frank Wierzbicki]

On Wed, Jun 11, 2008 at 5:50 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> Implementations are also permitted to restrict namespace dictionaries to
> only accept string keys (I believe Jython does this for performance reasons
> - CPython just optimised the hell out of normal dictionaries that happen to
> only contain string keys instead).
Jython's current version (2.2) and back did indeed restrict these
dictionaries to accept string keys only, but future versions will
allow non-string keys (the trunk version already does).  Many
frameworks use non-string keys in these dictionaries.

-Frank
___
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

Re: [Python-Dev] Holding a Python Language Summit at PyCon

[Frank Wierzbicki]

On Wed, Dec 3, 2008 at 10:31 AM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> 14:00 - 15:30
> =
>
> Two tracks:
>
> Cross-implementation issues:
>
>  What do the various VMs want/need from CPython to help with their
>  implementations?
>
>  * Marking CPython-specific tests in the test suite?
>  * Getting an implementation agnostic test suite for the Python language?
>  * Separating the language tests and the pure Python part of the stdlib into
>a separate project?  (Or publish them as a separate package.)
>  * Transition plans for 3.0?
>
>  Champion needed.
I would like to champion this one.

-Frank
___
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

Re: [Python-Dev] Holding a Python Language Summit at PyCon

[Frank Wierzbicki]

On Thu, Dec 4, 2008 at 3:16 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 4, 2008 at 12:05, Frank Wierzbicki <[EMAIL PROTECTED]> wrote:
>> On Wed, Dec 3, 2008 at 10:31 AM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>>> 14:00 - 15:30
>>> =
>>>
>>> Two tracks:
>>>
>>> Cross-implementation issues:
>>>
>>>  What do the various VMs want/need from CPython to help with their
>>>  implementations?
>>>
>>>  * Marking CPython-specific tests in the test suite?
>>>  * Getting an implementation agnostic test suite for the Python language?
>>>  * Separating the language tests and the pure Python part of the stdlib into
>>>a separate project?  (Or publish them as a separate package.)
>>>  * Transition plans for 3.0?
>>>
>>>  Champion needed.
>> I would like to champion this one.
>>
>
> I told AMK this a while back, but might as well make it more public; I
> am up for chairing as well.
Brett,

Are you saying you've already called the cross-implementation champion
role?  If so I'm happy to defer or co-chair.

-Frank
___
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

Re: [Python-Dev] Holding a Python Language Summit at PyCon

[Frank Wierzbicki]

On Mon, Dec 8, 2008 at 10:31 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 18:53, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>> On Sat, Dec 06, 2008 at 02:42:38PM -0800, Brett Cannon wrote:
>>> No, I am saying I had told AMK I was interested in championing the
>>> session. He chose you, and that's that. One less thing for me to worry
>>> about. =)
>>
>> Brett, I actually think you'd be a good champion for the 11AM
>> transition-planning session.
>
> OK, so I guess I do have one more thing to worry about. =) I'd be
> happy to do that session.
Sounds good, and I'm still happy to do the other session even with all
of the heckling :)

-Frank
___
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

Re: [Python-Dev] Status of the fix for the hash collision vulnerability

[Frank Sievertsen]

Am 13.01.2012 02:24, schrieb Victor Stinner:

My patch doesn't fix the DoS, it just make the attack more complex.
The attacker cannot pregenerate data for an attack: (s)he has first to
compute the hash secret, and then compute hash collisions using the
secret. The hash secret is a least 64 bits long (128 bits on a 64 bit
system). So I hope that computing collisions requires a lot of CPU
time (is slow) to make the attack ineffective with today computers.
Unfortunately it requires only a few seconds to compute enough 32bit 
collisions on one core with no precomputed data.  I'm sure it's possible 
to make this less than a second.


In fact, since hash(X) == hash(Y) is independent of the suffix [ hash(X) 
^ suffix == hash(Y) ^ suffix ], a lot of precomputation (from the tail) 
is possible.


So the question is: How difficult is it to guess the seed?

Frank
___
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

Re: [Python-Dev] Status of the fix for the hash collision vulnerability

[Frank Sievertsen]

Unfortunately it requires only a few seconds to compute enough 32bit
collisions on one core with no precomputed data.

Are you running the hash function "backward" to generate strings with
the same value, or you are more trying something like brute forcing?


If you try it brute force to hit a specific target, you'll only find 
only one good string every 4 billion tries. That's why you first blow up 
your target:


You start backward from an arbitrary target-value. You brute force for 3 
characters, for example, this will give you 16 million intermediate 
values from which you know that they'll end up in your target-value.


Those 16 million values are a huge target for now brute-forcing forward: 
Every 256 tries you'll hit one of these values.



And how do you get the hash secret? You need it to run an attack.


I don't know. This was meant as an answer to the quoted text "So I hope 
that computing collisions requires a lot of CPU time (is slow) to make 
the attack ineffective with today computers.".


What I wanted to say is: The security relies on the fact that the 
attacker can't guess the prefix, not that he can't precompute the values 
and it takes hours or days to compute the collisions. If the prefix 
leaks out of the application, then the rest is trivial and done in a few 
seconds. The suffix is not important for the collision-prevention, but 
it will probably make it much harder to guess the prefix.


I don't know an effective way to get the prefix either, (if the 
application doesn't leak full hash(X) values).


Frank
___
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

Re: [Python-Dev] Counting collisions for the win

[Frank Sievertsen]

The main issue with that approach is that it allows a new kind of attack.


Indeed, I posted another example: http://bugs.python.org/msg151677

This kind of fix can be used in a specific application or maybe in a
special-purpose framework, but not on the level of a general-purpose
language.

Frank
___
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

Re: [Python-Dev] Counting collisions for the win

[Frank Sievertsen]

No, that's not true.
Whenever a collision happens, other bits are mixed in very fast.

Frank

Am 20.01.2012 13:08, schrieb Victor Stinner:

I'm surprised we haven't seen bug reports about it from users
of 64-bit Pythons long ago

A Python dictionary only uses the lower bits of a hash value. If your
dictionary has less than 2**32 items, the dictionary order is exactly
the same on 32 and 64 bits system: hash32(str)&  mask == hash64(str)&
mask for mask<= 2**32-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

Re: [Python-Dev] Counting collisions for the win

[Frank Sievertsen]

Hello,

I still see at least two ways to create a DOS attack even with the
collison-counting-patch.

I assumed that it's possible to send ~500KB of payload to the
application.

1. It's fully deterministic which slots the dict will lookup.
Since we don't count slot-collisions, but only hash-value-collisions
this can be exploited easily by creating strings with the hash-values
along the lookup-way of an arbitrary (short) string.

So first we pick an arbitrary string. Then calculate which slots it will
visit on the way to the first empty slot. Then we create strings with
hash-values for these slots.

This attack first injects the strings to fill all the slots that the
one short string will want to visit. Then it adds THE SAME string
again and again. Since the entry is already there, nothing will be added
and no additional collisions happen, no exception raised.

$ ls -l super.txt
-rw-r--r-- 1 fx5 fx5 52 20. Jan 10:19 super.txt
$ tail -n3 super.txt
FX5
FX5
FX5
$ wc -l super.txt
9 super.txt
$ time python -c 'dict((unicode(l[:-1]), 0)  for l in open("super.txt"))'
real0m52.724s
user0m51.543s
sys0m0.028s

2. The second attack actually attacks that 1000 allowed string
comparisons are still a lot of work.
First I added 999 strings that collide with a one-byte string "a". In
some applications a zero-byte string might work even better. Then I
can add a many thousand of the "a"'s, just like the first attack.

$ ls -l 1000.txt
-rw-r--r-- 1 fx5 fx5 50 20. Jan 16:15 1000.txt
$ head -n 3 1000.txt
7hLci00
4wVFm10
_rZJU50
$ wc -l 1000.txt
247000 1000.txt
$ tail -n 3 1000.txt
a
a
a
$ time python -c 'dict((unicode(l[:-1]), 0)  for l in open("1000.txt"))'
real0m17.408s
user0m15.897s
sys0m0.008s

Of course the first attack is far more efficient. One could argue
that 16 seconds is not enough for an attack. But maybe it's possible
to send 1MB, have zero-bytes strings, and since for example django
does 5 lookups per query-string this will keep it busy for ~80 seconds on
my pc.

What to do now?
I think it's not smart to reduce the number of allowed collisions 
dramatically

AND count all slot-collisions at the same time.

Frank
___
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

Re: [Python-Dev] Counting collisions for the win

[Frank Sievertsen]

Am 20.01.2012 16:33, schrieb Guido van Rossum:
(I'm thinking that the original attack is trivial once the set of 
65000 colliding keys is public knowledge, which must be only a matter 
of time.



I think it's very likely that this will happen soon.

For ASP and PHP there is attack-payload publicly available.
PHP and ASP have patches to limit the number of query-variables.

We're very lucky that there's no public payload for python yet,
and all non-public software and payload I'm aware of is based
upon my software.

But this can change any moment. It's not really difficult to
write software to create 32bit-collisions.

Frank
___
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

Re: [Python-Dev] Counting collisions for the win

[Frank Sievertsen]

Hello,

I'd still prefer to see a randomized hash()-function (at least for 3.3).

But to protect against the attacks it would be sufficient to use
randomization for collision resolution in dicts (and sets).

What if we use a second (randomized) hash-function in case there
are many collisions in ONE lookup. This hash-function is used only
for collision resolution and is not cached.

The benefits:

* protection against the known attacks
* hash(X) stays stable and the same
* dict order is only changed when there are many collisions
* doctests will not break
* enhanced collision resolution
* RNG doesn't have to be initialized in smaller programs
* nearly no slowdown of most dicts
* second hash-function is only used for keys with higher collision-rate
* lower probability to leak secrets
* possibility to use different secrets for each dict

The drawback:

* need to add a second hash-function
* slower than using one hash-function only, when > 20 collisions
* need to add this to container-types? (if used for py3.3)
* need to expose this to the user? (if used for py3.3)
* works only for datatypes with this new function
* possible to implement without breaking ABI?

The following code is meant for explanation purpose only:

for(perturb = hash; ; perturb >>= 5) {
i = (i << 2) + i + perturb + 1;

if((collisions++) == 20) {
// perturb is already zero after 13 rounds.
// 20 collisions are rare.

// you can add && (ma_mask > 256) to make 100% sure
// that it's not used for smaller dicts.

if(Py_TYPE(key)->tp_flags & Py_TPFLAGS_HAVE_RANDOMIZED_HASH) {
// If type has a randomized hash, use this now for lookup
i = perturb = PyObject_RandomizedHash(key));
}
   .


If I got this right we could add a new function "tp_randomized_hash"
to 3.3 release. But can we also add functions in older releases, without
breaking ABI?

If not, can we implement this somehow using a flag?

FOR OLDER RELEASE < 3.3:

Py_hash_t
PyObject_RandomizedHash(PyVarObject *o) {
PyTypeObject *tp = Py_TYPE(v);
if(! (tp->tp_flags & Py_TPFLAGS_HAVE_RANDOMIZED_HASH))
return -1;

global_flags_somewhere->USE_RANDOMIZED_HASH = 1;
return (*tp->tp_hash)(v);
}

 and in unicodeobject.c: (and wherever we need randomization)

static Py_hash_t
unicode_hash(PyUnicodeObject *self)
{
Py_ssize_t len;
Py_UNICODE *p;
Py_hash_t x;
Py_hash_t prefix=0;
Py_hash_t suffix=0;

if(global_flags_somewhere->USE_RANDOMIZED_HASH) {
global_flags_somewhere->USE_RANDOMIZED_HASH = 0;
initialize_rng_if_not_already_done_and_return_seed(&prefix, 
&suffix);


. (and don't cache in this case) .


It's ugly, but if I understand this correctly, the GIL will
protect us against race-conditions, right?

Hello, internals experts: Would this work or is there a better way to do
this without breaking the ABI?

Frank
___
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

Re: [Python-Dev] Counting collisions for the win

[Frank Sievertsen]

On 23.01.2012 19:25, Glenn Linderman wrote:
So this sounds like SafeDict, but putting it under the covers and 
automatically converting from dict to SafeDict after a collision 
threshold has been reached.  Let's call it fallback-dict.


and costs:

* converting the dict from one hash to the other by rehashing all the 
keys.


That's not exactly what it does, it calls the randomized hash-function 
only for those
keys, that that didn't find a free slot after 20 collision. And it uses 
this value only for

the further collision resolution.

So the value of hash() is used for the first 20 slots, randomized_hash() 
is used

after that.

1st try: slot[i = perturb = hash];
2nd try: slot[i=i * 5 + 1 + (perturb >>= 5)]
3rd try: slot[i=i * 5 + 1 + (perturb >>= 5)]

20th try: slot[i= i * 5 + 1 + (perturb >>= 5)]
21th try: slot[i= perturb = randomized_hash(key)] < HERE
22th try: slot[i= i * 5 + 1 + (perturb >>= 5)]

This is also why there is no conversion needed. It's a
per-key/per-lookup rule.

Frank
___
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

Re: [Python-Dev] Counting collisions for the win

[Frank Sievertsen]

Interesting idea, and I see it would avoid conversions.  What happens 
if the data area also removed from the hash?  So you enter 20 
colliding keys, then 20 more that get randomized, then delete the 18 
of the first 20.  Can you still find the second 20 keys? Takes two 
sets of probes, somehow?



That's no problem, because the dict doesn't really free a slot, it
replaces the values with a dummy-values.

These places are later reused for new values or the whole dict is 
recreated and

resized.

Frank
___
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

Re: [Python-Dev] Hashing proposal: 64-bit hash

[Frank Sievertsen]

As already mentioned, the vulnerability of 64-bit Python rather theoretical and 
not practical. The size of the hash makes the attack is extremely unlikely.


Unfortunately this assumption is not correct. It works very good with
64bit-hashing.

It's much harder to create (efficiently) 64-bit hash-collisions.
But I managed to do so and created strings with
a length of 16 (6-bit)-characters (a-z,  A-Z, 0-9, _, .). Even
14 characters would have been enough.

You need less than twice as many characters for the same effect as in
the 32bit-world.

Frank



___
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

Re: [Python-Dev] Hashing proposal: 64-bit hash

[Frank Sievertsen]

The point is not the length of the string, but the size of string 
space for inspection. To search for a string with a specified 64-bit 
hash to iterate over 2 ** 64 strings. Spending on a single string scan 
1 nanosecond (a very optimistic estimate), it would take 2 ** 64 / 1e9 
/ (3600 * 24 * 365.25) = 585 years. For the attack we need to find 
1000 such strings -- more than half a million years. For 32-bit hash 
would need only an hour.




With meet-in-the-middle and some other tricks it's possible to generate 
25,000 64-bit-collisions per hour using an older desktop-cpu and 4gb ram.


H_dypmRNWgOxiaaG
A_ceO8B4Q2eKfabi
S_kpgdB3tUFJiaae
H_dypmRNWgOxiaaG
D_FYzdys3H8qbaba
0_pOwRq15h8vbabO
S_kpgdB3tUFJiaae
__mdKp1GvI_fcaaM
6_U3_B0pJT1UsaaW
4_1GnK9BmLj9naa5
__X7hMeAOpACdaaw
B_7pm.T62SiLlaai
I_HSdl0axd8tmaae
T_Dv3LwayACpdaaO

Frank
___
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

Re: [Python-Dev] Import semantics

[Frank Wierzbicki]

Sorry for the untrimmed conversation, but I've cc'ed jython-dev, my
comments are at the bottom.

On 6/12/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 6/12/06, Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> > Fabio Zadrozny wrote:
> > > Python and Jython import semantics differ on how sub-packages should be
> > > accessed after importing some module:
> > >
> > > Jython 2.1 on java1.5.0 (JIT: null)
> > > Type "copyright", "credits" or "license" for more information.
> > >  >>> import xml
> > >  >>> xml.dom
> > > 
> > >
> > > Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
> > > win32
> > > Type "help", "copyright", "credits" or "license" for more information.
> > >  >>> import xml
> > >  >>> xml.dom
> > > Traceback (most recent call last):
> > >   File "", line 1, in ?
> > > AttributeError: 'module' object has no attribute 'dom'
> > >  >>> from xml.dom import pulldom
> > >  >>> xml.dom
> > > 
> > >
> > > Note that in Jython importing a module makes all subpackages beneath it
> > > available, whereas in python, only the tokens available in __init__.py
> > > are accessible, but if you do load the module later even if not getting
> > > it directly into the namespace, it gets accessible too -- this seems
> > > more like something unexpected to me -- I would expect it to be
> > > available only if I did some "import xml.dom" at some point.
> > >
> > > My problem is that in Pydev, in static analysis, I would only get the
> > > tokens available for actually imported modules, but that's not true for
> > > Jython, and I'm not sure if the current behaviour in Python was expected.
> > >
> > > So... which would be the right semantics for this?
> >
> > the difference in Jython is deliberate. I think the reason was to mimic
> > more the Java style for this, in java fully qualified names always work.
> > In jython importing the top level packages is enough to get a similar
> > effect.
> >
> > This is unlikely to change for backward compatibility reasons, at least
> > from my POV.
>
> IMO it should do this only if the imported module is really a Java
> package. If it's a Python package it should stick to python semantics
> if possible.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)

This is a tough one since the BDFL and Samuele disagree here.  Perhaps
we should document the Java import behavior as permanent, but document
the Python imports in Jython as being deprecated but available until
some future release?  I believe we would keep it at least through
Jython 2.3.

-Frank
___
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

[Python-Dev] Cleanup of test harness for Python

[Frank Wierzbicki]

Hello all,

According to the thread that includes
http://mail.python.org/pipermail/python-dev/2006-June/065727.html
there will be some effort in 2.6 to make the tests in Python more
consistent.  I would like to help with that effort, partly to sneak in
some checks for CPython internal tests that should be excluded from
Jython, but mainly to understand the future implementation of Python
for which the tests provide the only real spec.  Which of the current
tests is closest to an "ideal" test, so I can use it as a model?

Thanks,

-Frank Wierzbicki
___
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

Re: [Python-Dev] Import semantics

[Frank Wierzbicki]

> In that case, why not post a news item saying this? The website is
> probably the first place people look...
>
I think any news other than "here is the beta -- follow this link to
download it" would be kind of a waste at this point.  And that will
come when I finish __slots__, subclassable "type", and figure out how
to put a release together, which will be "real soon now" -- but
really.

Thanks,

-Frank
___
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

Re: [Python-Dev] Import semantics

[Frank Wierzbicki]

On 7/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Hi Frank,
>
> Have you and/or the Jython community made up your mind about this? The
> thread seems to have disappeared after you posted (or perhaps it
> continued only on jython-dev, which I don't read?).
The thread pretty much stopped there.  I think a modification of the
import semantics won't really come up again until 2.3 is out, since
releases and reviving Jython take priority over backwards incompatible
features.  For my part I would like to think that a goal for Jython
should be:

Pure Python code developed first on Jython should run without change on CPython.

Which would mean we will eventually need to change the import
semantics for importing Python code (though I doubt we will change the
semantics for importing Java packages any time soon).  Whether that
can be done in 2.x, or if this change is so incompatible that we need
to think about it in a "Jython 3000" way, I don't really know.

>
> Also, I just realized that you're the new Jython maintainer. Is *that*
> official?
It is official, at least in the unofficial way that Jython appears to
work: Brian handed the baton to me after (I presume) Samuele Pedroni
had handed the baton to Brian.

Brian's email is here:
http://sourceforge.net/mailarchive/message.php?msg_id=13859029

That said, I still regard Samuele Pedroni as the ultimate authority on
Jython and give him pretty much full veto power.  He fortunately
continues to watch the checkins and prods me when I go in the wrong
direction.

> I'd like to offer you my congratulations, and, more
> importantly, any support you might need.
Thanks!

> I find Jython an important
> part for Python's long-term stategy.
That's good to know.

> I'm asked occasionally what the
> status of Jython is; people point out that the last release was 2.1
> many years ago and the website has no news since early 2005; they're
> afraid that Jython is dying and that it's not a viable choice for new
> projects.
> I'm very happy to be able to tell them that soon there will
> be a 2.3 release and yes there *is* continued support...
Perhaps for large values of "soon" -- but seriously, I am working hard
to polish the coming release, make it easier for new developers to
read the code, and when I have a chance, update the website.  Jython
is my first serious plunge into open source contributions (it is
really too bad that I couldn't have been a journeyman for another year
or so first, but circumstances did not allow that).  I have suffered
from some over-optimism when asked for release dates, so I'm really
afraid to give too sharp of a definition for "soon".  That said, I
believe a 2.2 version will be out sometime this summer, and a 2.3
should follow relatively quickly (maybe 6 months or so)

The 2.2->2.3 will (hopefully) be relatively quick because 2.2 is an
unfortunate but at this point unavoidable mix of 2.2 and 2.3 features,
with heavy favoring of 2.3 features.

Jython has had a history of having a very small number of developers,
and a history of too much off-list discussions so that new developers
have a very hard time catching up.  I'm trying hard to change that
culture.  There are 4 or 5 developers contributing patches lately --
so I'm actually spending more time trying to help them along instead
of concentrating 100% on a release -- I really think they are the most
important predictor of the future of Jython.  I have high hopes for
the project's future health.

Anyhow, this post is getting long, so to sum up:

Jython is alive, and we aren't going to let it die.

Regards,

-Frank
___
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

Re: [Python-Dev] Import semantics

[Frank Wierzbicki]

On 7/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Frank> That said, I still regard Samuele Pedroni as the ultimate
> Frank> authority on Jython and give him pretty much full veto power.  He
> Frank> fortunately continues to watch the checkins and prods me when I
> Frank> go in the wrong direction.
>
> Does that make Samele the DBPV (Dictator benevolo per vita)? ;-)
>
> Skip
>
I wonder if Samuele even wants that role?

Anyway, I believe Samuele has more experience with Jython as it is
currently implemented than anyone else, so I must take anything he
says about Jython very seriously.  However, when it comes to pure
*Python* matters (no C and no J) which includes half of Jython's
import semantics, I think it is still Guido's opinion that matters
most.  Without that, there is too much chaos.

-Frank
___
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

Re: [Python-Dev] AST branch is in?

[Frank Wierzbicki]

On 10/20/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
The Grammar is (was at one point at least) shared between Jython andwould allow more tools to be able to share infrastructure.  The ideais to eventually be able to have [JP]ython output the same AST totools.

Hello Python-dev,


My name is Frank Wierzbicki and I'm working on the Jython
project.  Does anyone on this list know more about the history of
this
Grammar sharing between the two projects?  I've heard about some
Grammar sharing between Jython and Python, and I've noticed that (most
of)
the jython code in /org/python/parser/ast is commented "Autogenerated
AST node".  I would definitely like to look at (eventually)
coordinating with this effort.

I've cross-posted to the Jython-dev list in case someone there has some insight.



Thanks,

Frank
___
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

Re: [Python-Dev] Jython and CPython

[Frank Wierzbicki]

>  > If the portability problem can be solved by checking things into Jython
>  > instead, I think I would prefer that.
I'm definitely interested in bringing ElementTree into Jython at some
point, though I probably won't have time to look into it until after
the next Jython release.  I'm quite sure that we can work something
out so that Jython-specific portability code can reside in Jython
only.  Though whenever it is cleanly do-able, I'd like to be able to
use the python libraries unchanged.  It sounds like this is a case
where it is not that clean to do...

-Frank
___
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

[Python-Dev] Cross compiling Python (for Android)

[Frank, Matthew I]

This email is about my experience getting CPython (3.4.1) to
cross-compile and run on x86 Android (4.4.2 with sdk 19 and ndk-r9).
I know that Android is not a supported architecture (and I won't
regale you with stories about the complete locale and mbstowcs support
I had to borrow from FreeBSD to get it working).  The purpose of this
email is that several things I found are arguably "bugs" in the Python
build system or code when it comes to cross-compiling that are exposed
by Android's poor Posix support.  I'd like some advice about what kind
of patch (if any) would be most suitable for fixing the problems on
the Python side.

Just to be complete:  I'm configuring with

 CPPFLAGS=-I../my-locale ../Python-3.4.1/configure --enable-shared
 --prefix=/path/to/install/dir --build=x86_64-linux-gnu
 --host=i686-linux-android --disable-ipv6 ac_cv_file__dev_ptmx=no
 ac_cv_file__dev_ptc=no ac_cv_little_endian_double=yes

(The CPPFLAGS addition is to get the headers for my locale fixes
instead of the default Android ones.  ac_cv_file__dev_ptmx=no and
ac_cv_file__dev_ptc=no are because I don't have /dev/whatever on my
build machine.  ac_cv_little_endian_double is because configure for
cross builds can't figure out the endianness of doubles on the host
(because it is running on the build machine not the host.)  (For ARM
it would be ac_cv_mixed_endian_double=yes.)

I've gotten to the point where `make; make install` succeeds up to the
point of building something that runs on my Android system (from the
command line) and `python -m test` runs 388 tests, with 321 ok, 24
test failures and 43 tests skipped (the skips mostly due, I think, to
me not yet having installed the right cross-building support for
things like bz2 and dbm.)

1. `make` succeeds but `make install` always fails at the end with
   something having to do with being unable to run "ensurepip"
   (presumably because ensurepip requires modules that only run on the
   host, not the build module.)  So it seems this should be wrapped in
   a test for cross compilation, but I haven't looked at exactly what
   yet.  The error is:

   /linux-python/bin/python3.4: Error while finding spec for
   'ensurepip.__main__' (:
   /build-directory/build/lib.linux-i686-3.4/time.cpython-34m.so:
   wrong ELF class: ELFCLASS32); 'ensurepip' is a package and cannot
   be directly executed make: *** [install] Error 1

2. setup.py is missing -lm flag for several modules.  On Linux this
   problem is hidden because libm is already loaded by the executable
   calling dlopen(), but Android's loader deals with unknown symbols
   differently (searches only the libs explicitly linked against the
   module being loaded.)  http://bugs.python.org/issue21668 reports
   the problem for selectmodule (can't find ceil()) and timemodule
   (fmod() and floor()).  But there are at least two more: audioop
   fails to load because it needs floor() and ctypes_test fails to
   load because it needs sqrt().  I'll happily update the patch in
   21668.

   Is there any fundamental objection to adding the -lm flag to the
   link step where it is necessary?

3. What is ossaudiodev?  It tries to include "sys/soundcard.h", which
   I don't have on my system.   (The rule in setup.py is
   wrapped in a test for host of Linux/FreeBSD/Darwin, but Android x86
   gets configured with --host=i686-linux-android so to turn it off
   requires an extra test for "and not cross_compiling".)

   Can I just turn off ossaudiodev for cross compiling or might
   someone want it in a different type of cross build?  (In which case
   I think I'll have to write some kind autoconf rule for it, which I
   don't quite know how to do yet.)

4. Module _decimal is failing to compile.  The problem is that it has
   a header called memory.h.  Android's libc has the problem that
   /usr/include/stdlib.h includes .  But the build system
   puts -I. on the include path before the system dirs (as it should)
   so when compiling _decimal, Modules/_decimal/libmpdec/memory.h gets
   found instead of /usr/include/memory.h.  Shiz has a patch here:
   https://github.com/rave-engine/python3-android/blob/master/mk/python/3.3.5/p\
ython-3.3.5-android-libmpdec.patch
   (which renames memory.h -> mpmemory.h) but I don't know

   a.  Is there a tracker for this yet?  and
   b.  Is Shiz's fix the desired one or should I be looking for
   another approach?  (Maybe modifying the -I flags for the build
   of just the build of _decimal or something?)

5. I'm not sure what test configure is actually doing for gethostby*()
   in a cross-compile environment.  In any case Android has a bug
   where gethostbyaddr_r() is declared in the headers, but not
   actually implemented in libc.  So I have to modify my pyconfig.h by
   hand to define HAVE_GETHOSTBYNAME and undef HAVE_GETHOSTBYNAME_R
   and HAVE_GETHOSTBYNAME_R_6_ARG.

   Is there a variable (like ac_cv_little_endian_double) that I can
   give to `configure` to make it set HAVE_GETHOSTB

Re: [Python-Dev] Undefined dlopen When Building Module On Android

[Frank, Matthew I]

Android's dlopen() works slightly differently than the normal Unix dlopen() in 
at least two different ways.  I haven't seen your particular problem, but 
that's probably because I'm cross-building CPython (building everything I need 
on a Linux machine, and then copying the install directory to the Android 
machine.)

(1) When building for Android you need to explicitly include the "-ldl" flag on 
the command line for the link step.  (In Linux the dlopen() routine is included 
in libc, so "-ldl" is not necessary).  I suspect that some part of your 
distutils was not linked correctly.  (Since I'm cross-building I've never run 
distutils on the Android side, which is probably why I've not seen this.)  Your 
best bet would be to run under a debugger and figure out which line of C code 
in which .so file is throwing the error.  Then going back to the build scripts 
and looking at how that .so file is getting linked.  (For an example of someone 
else having a similar problem see for example, 
http://stackoverflow.com/questions/25846927/git-built-on-android-throws-undefined-reference-to-dlopen-error).

(2) The other possibility has to do with a quirk in Android's dlopen() 
implementation.  On most legacy Unix systems (including Linux) when you 
dlopen() a library Z then all the already loaded libraries A, B, C, ... are 
searched for any dependences of Z (even if Z was not explicitly linked against 
any of A, B, C,...).  On Android (perhaps for security reasons) that's not 
true, if Z depends on A, then you need to have "-lA" when you link Z.  An 
example (and patch) for this problem is http://bugs.python.org/issue21668.

-Matt

> -Original Message-
> From: Cyd Haselton [mailto:chasel...@gmail.com]
> Sent: Friday, January 23, 2015 10:50 AM
> To: Brett Cannon
> Cc: Guido van Rossum; Python-Dev
> Subject: Re: [Python-Dev] Undefined dlopen When Building Module On Android
> 
> I guess I'll keep waiting...given the zero responses I've gotten from the 
> android side.
> :-(.
> 
> In the meantime...in case anyone is interested... since I have the working 
> binary, I
> executed it and went through each command in setup.py to see what throws the
> 'undefined reference to dlopen' error.
> Turns out that the distutils module is the culprit...specifically 
> distutils.core.
> 
> 
> On Thu, Jan 22, 2015 at 8:33 AM, Brett Cannon  wrote:
> > A mobile SIG is being formed, but it doesn't have a mailing list yet,
> > else that would be a good place to ask this question.
> >
> > On Wed Jan 21 2015 at 5:54:39 PM Guido van Rossum  wrote:
> >>
> >> Maybe try a list focused on Android development? Few people in the
> >> Python core development community have any Android experience. But
> >> the issues and context you offer seem to be related to the Android world, 
> >> not to
> Python.
> >> (dlopen is used by a lot of systems, not just Python.)
> >>
> >> On Wed, Jan 21, 2015 at 2:43 PM, Cyd Haselton  wrote:
> >>>
> >>> On Mon, Jan 19, 2015 at 5:23 PM, Cyd Haselton 
> >>> wrote:
> >>> > On Mon, Jan 19, 2015 at 8:51 AM, Cyd Haselton
> >>> > 
> >>> > wrote:
> >>> >> Hello,
> >>> >> I'm struggling with a build issue on Android; I've posted to the
> >>> >> general python list with no result, so I'm re-posting here in
> >>> >> hopes that someone can help.  If this is the wrong place feel
> >>> >> free to let me know.
> >>> >>
> >>> >> I'm attempting to build Python 2.7.8 on my Android device; I'm
> >>> >> using an environment that simulates a Linux filesystem within the
> >>> >> Android terminal using a port of fakechroot.  Within that
> >>> >> environment I've ported and/or bootstrapped a number of Linux
> >>> >> utilities (curl, git, openssl, gcc)
> >>> >>
> >>> >> I run ./configure, then make, and the executable and library are
> >>> >> built.  The problem occurs when build_ext is run; the newly built
> >>> >> python executable builds, then links _struct, and immediately
> >>> >> afterwards I get an 'undefined reference to dlopen' error.
> >>> >>
> >>> >> If I run ./python setup.py --verbose -library-dirs /path/to/lib
> >>> >> --libraries='c dl m' -f, the 'undefined reference to dlopen'
> >>> >> error is thrown again.
> >>> >>
> >>> >> If I run ./python setup.py --verbose -library-dirs /path/to/lib
> >>> >> --libraries='-lc -ldl -lm' -f the build continues past
> >>> >> _struct...even though ld throws the expected 'unable to find -l-lc' 
> >>> >> and other
> errors.
> >>> >>
> >>> >> Let me know if you need me to provide additional information.
> >>> >> Any help would be greatly appreciated.
> >>> >>
> >>> >> Cyd
> >>> >
> >>> >
> >>> > Additionally I took a strace of the error producing command. The
> >>> > following is (hopefully) a relevant portion minus the various 'no
> >>> > such file' lines before the correct lib is found (which it always
> >>> > is)
> >>> >
> >>> > 16513
> >>> > open("/data/data/jackpal.androidterm/kbox2/bld/python/Python-
> 2.7.8/Lib/distutils/unixccompiler.py",
> >>> > O_RDONLY|O_LARGEFILE) = 3

Re: [Python-Dev] Import Fails in setup.py On Android

[Frank, Matthew I]

There’s now (as of a couple days ago) a python mobile-sig 
(https://mail.python.org/mailman/listinfo/mobile-sig).  While that group is 
much smaller than python-dev and probably not as knowledgeable about the 
Cpython source base, that’s where you’re going to find folks who have a vested 
interest in getting Python working on mobile platforms like Android.  (And who 
would be interested in hearing about your experiences, no matter whether they 
can help you or not.)

What you are doing (trying to run the entire C compiler toolchain on an Android 
machine, instead of using the cross-compilers that come in Google’s Android NDK 
(native development kit)) is way outside the mainstream.  (I.e., you’re not 
going to find very many people trying to do this here or anywhere.)

Since you compiled all the libraries that you are linking against, there is 
some possibility (likelihood) that the problem is in one of those libraries, 
not anywhere in the CPython source.  (Some other library was compiled without 
the necessary –dl flag.)  The right way to track down this problem (no matter 
where it is) is to run under gdb and type “where” when the program crashes.

The reason I suspect that the problem is in one of the libraries you compiled 
before building Python, rather than a problem in the CPython sources or build 
scripts, is that I don’t have this problem when I cross-compile Python 3.4.2 on 
a Linux machine, then take the result and copy it over to the Android machine.  
I’ve posted instructions and patches for successfully performing this cross 
compilation (for Android KitKat running on an x86) here: 
https://github.com/wandering-logic/android_x86_python-3.4.

Best,
-Matt

From: Cyd Haselton [mailto:chasel...@gmail.com]
Sent: Monday, February 02, 2015 3:25 PM
To: Ryan Gonzalez
Cc: Python-Dev
Subject: Re: [Python-Dev] Import Fails in setup.py On Android

No traceback unfortunately...the fakechroot in the environment throws the error 
and setup.py fails.

I'll roll back that change...any idea where I could find info about the 
original method?
On February 2, 2015 3:17:54 PM CST, Ryan Gonzalez 
mailto:rym...@gmail.com>> wrote:
In reality, things just got broken even more. I don't know when that patch was 
created, but it's now very out of date: importlib._bootstrap has no load 
function. That's what the error you're getting is telling you. Since it isn't 
getting to load anything, the issue seems "solved". Not really.

What's the full traceback for the undefined reference exception?

On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton 
mailto:chasel...@gmail.com>> wrote:
Update: While waiting for replies I made the change referenced here: 
https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80

specifically changing
importlib. _bootstrap._SpecMethods(spec).load()
to
importlib._bootstrap.load(spec)

I no longer get a terminating 'undefined reference to dlopen' error, but I do 
get 'importing extensions failed' errors for each extension...like this:

*** WARNING: importing extension "_pickle" failed with : 'module' object has no attribute 'load'

On February 2, 2015 1:36:29 PM CST, Cyd Haselton 
mailto:chasel...@gmail.com>> wrote:
After fixing a segfault issue (many thanks Ryan) I'm back to the same issue I 
was having with Python 2.7.8; the newly built python throws an undefined 
reference to dlopen when running setup.py...specifically when 
importing just-built extensions

I've managed to narrow the problem down to the following line:

importlib._bootstrap._SpecMethods(spec).load()

Googling this brings up a few hits from bugs.python.org 
and not much else. I'm new to Python; any ideas what this does...or where I can 
read up on it for troubleshooting purposes?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com



--
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's 
becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was 
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. - srean
Check out my website: http://kirbyfan64.github.io/

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com