Re: [Python-Dev] Branch ancestry hiccup on the Mercurial repo

2013-01-01 Thread Senthil Kumaran 
On Mon, Dec 31, 2012 at 10:47 PM, Antoine Pitrou wrote:

>
> Chances are the problem won't be very annoying in practice, but just
> FYI.


I dont get this. I see 2.7 as a separate un-merged branch again (
http://hg.python.org/cpython/graph). Just curious, what happened next?



Thanks,
Senthil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Branch ancestry hiccup on the Mercurial repo

2013-01-01 Thread Georg Brandl 
On 01/01/2013 09:20 AM, Senthil Kumaran wrote:
> 
> 
> On Mon, Dec 31, 2012 at 10:47 PM, Antoine Pitrou  > wrote:
> 
> 
> Chances are the problem won't be very annoying in practice, but just
> FYI.
> 
> 
> I dont get this. I see 2.7 as a separate un-merged branch again
> (http://hg.python.org/cpython/graph). Just curious, what happened next?  

You can still see the merge near the bottom of the graph on that URL.
Nothing too bad happened, as we usually don't merge 2.7 into 3.x anyway,
it does not matter that Mercurial now considers all changes before that
accident as "merged".

Merry 2013,
Georg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] question about packaging

2013-01-01 Thread francis 



The current effort seems to be distlib, Vinay's project to gather the
"good parts" of packaging and distutils as a library API:
http://packages.python.org/distlib/
(there's an active bitbucket repo)

See

https://bitbucket.org/vinay.sajip/distlib/

for the latest code, which is periodically pushed to

http://hg.python.org/distlib/

The latest documentation is at

https://distlib.readthedocs.org/en/latest/


what about the actual packaging issues from the cypthon bugtracker? 
should we try to port the ones that apply to 
https://bitbucket.org/vinay.sajip/distlib/ ?


Thanks and Happy 2013!

francis

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PyTypeObject type names in Modules/

2013-01-01 Thread Eli Bendersky 
Hello and happy 2013,

Something I noticed earlier today is that some C versions of stdlib modules
define their name similarly to the Python version in their PyTypeObject.
Some examples: Decimal, xml.etree's Element. Others prepend an understore,
like _pickle.Pickler and many others.

What are the tradeoffs involved in this choice? Is there a "right" thing
for types that are supposed to be compatible (i.e. the C extension, where
available, replaces the Python implementation seamlessly)?

I can think of some meanings for pickling. Unpickling looks at the class
name to figure out how to unpickle a user-defined object, so this can
affect the pickle/unpickle compatibility between the C and Python versions.
What else?

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test___all__ polluting sys.modules?

2013-01-01 Thread Eli Bendersky 
On Mon, Dec 31, 2012 at 7:30 PM, Gregory P. Smith  wrote:

>
> On Sun, Dec 30, 2012 at 6:48 AM, R. David Murray wrote:
>
>> On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan 
>> wrote:
>> > On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky 
>> wrote:
>> > > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah 
>> wrote:
>> > >>
>> > >> Eli Bendersky  wrote:
>> > >> > Yes, this is the solution currently used in test_xml_etree.
>> However,
>> > >> > once
>> > >> > pickling tests are added things stop working. Pickle uses
>> __import__ to
>> > >> > import
>> > >> > the module a class belongs to, bypassing all such trickery. So if
>> > >> > test___all__
>> > >> > got _elementtree into sys.modules, pickle's __import__ finds it
>> even if
>> > >> > all the
>> > >> > tests in test_xml_etree manage to ignore it for the Python version
>> > >> > because they
>> > >> > use import_fresh_module.
>> > >>
>> > >> I ran into the same problem for test_decimal. The only thing that
>> appears
>> > >> to work is to set sys.modules['decimal'] explicitly before calling
>> > >> dumps()/loads(). See:
>> > >>
>> > >>PythonAPItests.test_pickle()
>> > >>ContextAPItests.test_pickle()
>> > >
>> > > Yes, this seems to have done the trick. Thanks for the suggestion.
>> >
>> > It may be worth offering a context manager/decorator equivalent to
>> > "import_fresh_module".
>>
>> I suggested making import_fresh_module a context manager in the issue
>> that Eli opened about test___all__.
>>
>> > > I'm still curious about the test-in-clean-env question though.
>> >
>> > As Stefan noted, the main advantage we get is that sometimes the
>> > failure to clean up properly is in the standard lib code rather than
>> > the tests, and with complete isolation we'd be less likely to notice
>> > the problem.
>> >
>> > Once you combine that with the fact that rearchitecting regrtest to
>> > work that way would be quite a bit of work, the motivation to make it
>> > happen goes way down.
>> >
>> > However, specifically spinning out the "import the world" tests like
>> > test_pydoc and test___all__ to a separate process might be worth the
>> > effort.
>>
>> Adding something to regertest (or unittest?) so that certain nominated
>> test modules are run in a subprocess has been discussed previously, but
>> so far no one has stepped up to implement it :)  (I think this came up
>> originally for test_site, but I don't remember for sure.)
>>
>
> test_subprocess and possibly a few others (things testing signal behavior,
> etc) already have some individual tests that do this.  its pretty easy.
>  subprocess.Popen of sys.executable typically with -E and the code either
> in a string via -c or else point at a second file or add an argument for
> main in the current file to detect.  making this simpler via something in
> test.support might make sense if there is a common need for it.
>
>
Thanks, and I agree that some tests have to be run separately. The patches
submitted by Arfrever to http://bugs.python.org/issue1674555 seem
interesting and relevant (pulling test_site into a separate
process/interpreter). I'll take a look at them once I have some time.

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-01 Thread Benjamin Peterson 
2013/1/1 Eli Bendersky :
> Hello and happy 2013,
>
> Something I noticed earlier today is that some C versions of stdlib modules
> define their name similarly to the Python version in their PyTypeObject.
> Some examples: Decimal, xml.etree's Element. Others prepend an understore,
> like _pickle.Pickler and many others.
>
> What are the tradeoffs involved in this choice? Is there a "right" thing for
> types that are supposed to be compatible (i.e. the C extension, where
> available, replaces the Python implementation seamlessly)?
>
> I can think of some meanings for pickling. Unpickling looks at the class
> name to figure out how to unpickle a user-defined object, so this can affect
> the pickle/unpickle compatibility between the C and Python versions. What
> else?

I don't it's terribly important except if the object from the C module
is directly exposed through the API it's nicer if it's __name__
doesn't have a leading underscore.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-01 Thread Eli Bendersky 
On Tue, Jan 1, 2013 at 8:15 AM, Benjamin Peterson wrote:

> 2013/1/1 Eli Bendersky :
> > Hello and happy 2013,
> >
> > Something I noticed earlier today is that some C versions of stdlib
> modules
> > define their name similarly to the Python version in their PyTypeObject.
> > Some examples: Decimal, xml.etree's Element. Others prepend an
> understore,
> > like _pickle.Pickler and many others.
> >
> > What are the tradeoffs involved in this choice? Is there a "right" thing
> for
> > types that are supposed to be compatible (i.e. the C extension, where
> > available, replaces the Python implementation seamlessly)?
> >
> > I can think of some meanings for pickling. Unpickling looks at the class
> > name to figure out how to unpickle a user-defined object, so this can
> affect
> > the pickle/unpickle compatibility between the C and Python versions. What
> > else?
>
> I don't it's terribly important except if the object from the C module
> is directly exposed through the API it's nicer if it's __name__
> doesn't have a leading underscore.
>

Hi Benjamin,

Can you elaborate - what you mean by "is directly exposed through the API"?

For example, Pickler in 3.x:

>>> import pickle
>>> pickle.Pickler.__name__
'Pickler'
>>> pickle.Pickler.__module__
'_pickle'
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-01 Thread Benjamin Peterson 
2013/1/1 Eli Bendersky :
>
>
>
> On Tue, Jan 1, 2013 at 8:15 AM, Benjamin Peterson 
> wrote:
>>
>> 2013/1/1 Eli Bendersky :
>> > Hello and happy 2013,
>> >
>> > Something I noticed earlier today is that some C versions of stdlib
>> > modules
>> > define their name similarly to the Python version in their PyTypeObject.
>> > Some examples: Decimal, xml.etree's Element. Others prepend an
>> > understore,
>> > like _pickle.Pickler and many others.
>> >
>> > What are the tradeoffs involved in this choice? Is there a "right" thing
>> > for
>> > types that are supposed to be compatible (i.e. the C extension, where
>> > available, replaces the Python implementation seamlessly)?
>> >
>> > I can think of some meanings for pickling. Unpickling looks at the class
>> > name to figure out how to unpickle a user-defined object, so this can
>> > affect
>> > the pickle/unpickle compatibility between the C and Python versions.
>> > What
>> > else?
>>
>> I don't it's terribly important except if the object from the C module
>> is directly exposed through the API it's nicer if it's __name__
>> doesn't have a leading underscore.
>
>
> Hi Benjamin,
>
> Can you elaborate - what you mean by "is directly exposed through the API"?
>
> For example, Pickler in 3.x:
>
 import pickle
 pickle.Pickler.__name__
> 'Pickler'
 pickle.Pickler.__module__
> '_pickle'

That's an example of what I meant.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.3): configparser: preserve section order when using `__setitem__` (issue #16820)

2013-01-01 Thread Antoine Pitrou 
On Tue,  1 Jan 2013 22:37:56 +0100 (CET)
lukasz.langa  wrote:
> http://hg.python.org/cpython/rev/f580342b63d8
> changeset:   81205:f580342b63d8
> branch:  3.3
> parent:  81203:b8b5303ac96f
> user:Łukasz Langa 
> date:Tue Jan 01 22:33:19 2013 +0100
> summary:
>   configparser: preserve section order when using `__setitem__` (issue #16820)

Would this deserve some NEWS entry?

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.3): configparser: preserve section order when using `__setitem__` (issue #16820)

2013-01-01 Thread Łukasz Langa 
Wiadomość napisana przez Antoine Pitrou  w dniu 1 sty 
2013, o godz. 22:48:

> On Tue,  1 Jan 2013 22:37:56 +0100 (CET)
> lukasz.langa  wrote:
>> http://hg.python.org/cpython/rev/f580342b63d8
>> changeset:   81205:f580342b63d8
>> branch:  3.3
>> parent:  81203:b8b5303ac96f
>> user:Łukasz Langa 
>> date:Tue Jan 01 22:33:19 2013 +0100
>> summary:
>>  configparser: preserve section order when using `__setitem__` (issue #16820)
> 
> Would this deserve some NEWS entry?

Indeed, I missed updating NEWS, sorry. Will do that now for all fixes I did in 
the past days.

-- 
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEPs in progress

2013-01-01 Thread Christian Heimes 
Good morning and happy new year!

I would like to let you know that I'm working on two new PEPs.

The first PEP addresses hash collision attacks as discussed in
http://bugs.python.org/issue14621. I'm planing to make the internal
string and bytes hash function more secure, pluggable and even faster.
DJB's SipHash is part of the plan as well. Users will be able to choose
an algorithm on startup and embedders will be able to provide their own
hash function, too.

The second PEP addresses key derivation functions for secure password
hashing. I like to add PBKDF2, bcrypt and scrypt facilities to the
standard library.

Regards,
Christian

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com