Re: [Python-Dev] PEP 410, 3rd revision, Decimal timestamp

[Steven D'Aprano]

Martin v. Löwis wrote:

 * Ruby (1.9.3), the `Time class `_
  supports picosecond (10\ :sup:`-12`)

We must do better than Ruby: support arbritrary precision! :-D


Seriously, I do consider that a necessary requirement for the PEP (which
the Decimal type actually meets). I don't want to deal with
this issue *again* in my lifetime (now being the second time),
so it's either arbitrary-precision, or highest-possible precision.
When I was in school, attoseconds (as) where the shortest named
second fraction. Today, it seems we should go for yoctoseconds (ys).
There is an absolute boundary, though: it seems there is no point in
going shorter than the Planck time (5.4 * 10**-44).



That is an implementation detail. Python implementations in other universes 
may not have that limitation.


Besides, if any of the speed of light c, gravitational constant G, Planck's 
constant h, or pi change, so will Planck time. Perhaps they should be 
environment variables?



Not-quite-sure-how-seriously-you-intend-supporting-yoctoseconds-ly y'rs,


--
Steven

___
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] folding cElementTree behind ElementTree in 3.3

[Eli Bendersky]

On Mon, Feb 20, 2012 at 01:12, "Martin v. Löwis"  wrote:

> > The change of backing ElementTree by cElementTree has already been
> > implemented in the default branch (3.3) by Florent Xicluna with careful
> > review from me and others. etree has an extensive (albeit a bit clumsy)
> > set of tests which keep passing successfully after the change.
>
> I just noticed an incompatible change: xml.etree.ElementTree.Element
> used to be a type, but is now a function.
>

Yes, this is a result of an incompatibility between the Python and C
implementations of ElementTree. Since these have now been merged by
default, one or the other had to be kept and the choice of cElementTree
appeared to be sensible since this is what most people are expected to use
in 2.7 and 3.2 anyway. I have an issue open for converting some function
constructors into classes. Perhaps Element should also have this fate.


>
> > In the past couple of years Florent has been the de-facto maintainer of
> > etree in the standard library, although I don't think he ever
> > "committed" to keep maintaining it for years to come. Neither can I make
> > this commitment, however I do declare that I will do my best to keep the
> > library functional, and I also plan to work on improving its
> > documentation and cleaning up some of the accumulated cruft in its
> > implementation. I also have all the intentions to take the blame if
> > something breaks.
>
> Would you mind adding yourself to
>
> http://docs.python.org/devguide/experts.html
>

Sure, I'll do that.

Eli
___
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] folding cElementTree behind ElementTree in 3.3

[Xavier Morel]

On 2012-02-20, at 12:36 , Eli Bendersky wrote:
> On Mon, Feb 20, 2012 at 01:12, "Martin v. Löwis"  wrote:
> 
>>> The change of backing ElementTree by cElementTree has already been
>>> implemented in the default branch (3.3) by Florent Xicluna with careful
>>> review from me and others. etree has an extensive (albeit a bit clumsy)
>>> set of tests which keep passing successfully after the change.
>> 
>> I just noticed an incompatible change: xml.etree.ElementTree.Element
>> used to be a type, but is now a function.
>> 
> 
> Yes, this is a result of an incompatibility between the Python and C
> implementations of ElementTree. Since these have now been merged by
> default, one or the other had to be kept and the choice of cElementTree
> appeared to be sensible since this is what most people are expected to use
> in 2.7 and 3.2 anyway. I have an issue open for converting some function
> constructors into classes. Perhaps Element should also have this fate.

I'm not sure that's much of an issue, Element (and most of the top-level
utility "constructors") are documented as being frontend interfaces with
no specific type of their own, and indeed they are simply functions in
lxml, just as they are in cElementTree.

Others will probably disagree, but as far as I am concerned these can stay
functions, avoid issues when switching to lxml or between ElementTree and
lxml (from one project to the next).
___
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] folding cElementTree behind ElementTree in 3.3

[Nick Coghlan]

On Mon, Feb 20, 2012 at 9:43 PM, Xavier Morel  wrote:
> I'm not sure that's much of an issue, Element (and most of the top-level
> utility "constructors") are documented as being frontend interfaces with
> no specific type of their own, and indeed they are simply functions in
> lxml, just as they are in cElementTree.
>
> Others will probably disagree, but as far as I am concerned these can stay
> functions, avoid issues when switching to lxml or between ElementTree and
> lxml (from one project to the next).

For a similar situation (only the other way around), we're probably
going to add a pure Python variant of functools.partial as a
staticmethod, while the C version is a callable extension type. (see
http://bugs.python.org/issue12428)

Basically, if something is just documented as being callable without
subclassing or instance checks being mentioned as supported in the
docs, it can be implemented as either a type or an ordinary function,
or pretty much any other kind of callable without being deemed an API
change (obviously that's not a free pass to go make such
implementation changes without a compelling reason, but C vs Python
often *is* such a reason).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Python in Native Client

[anatoly techtonik]

Hi,

People on NaCl list are asking about Python support for development of
native web applications in Python. Does anybody have experience compiling
Python for NaCl?

1.
https://groups.google.com/d/topic/native-client-discuss/ioY2jmw_OUQ/discussion
-- 
anatoly t.
___
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 410, 3rd revision, Decimal timestamp

[Victor Stinner]

>>> We must do better than Ruby: support arbritrary precision! :-D
>>
>> Seriously, I do consider that a necessary requirement for the PEP (which
>> the Decimal type actually meets). (...)
>
> (...)
> Not-quite-sure-how-seriously-you-intend-supporting-yoctoseconds-ly y'rs,

The point is not supporting yoctosecond resolution, but not having to
change the API each time that the resolution becomes better. The time
resolution already changed 3 times in UNIX/Linux history: 1 second, 1
ms, 1 us, 1 ns. So the C library has to maintain API for all these
resolution: time_t, timeb, timeval, timespec... ftime() and usleep()
are deperecated by POSIX 2008 for example.

http://news.bbc.co.uk/2/hi/technology/5099584.stm
"The prototype operates at speeds up to 500 gigahertz (GHz), more than
100 times faster than desktop PC chips."
"A decade ago we couldn't even envisage being able to run at these speeds."

500 Ghz means a theorical resolution of 2 picoseconds (10^-12). So
nanosecond might not be enough for next 10 years. This is theorical.

In practive, Linux does already use nanosecond timestamps and
shutil.copstat() has an issue with such timestamp (is unable to copy
such timestamp with no loss of precision).

Victor
___
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] PEP czar for PEP 3144?

[Nick Coghlan]

Does anyone object to me naming myself PEP czar for PEP 3144?

I've collated the objections to the original proposal on a few
different occasions throughout the (long!) PEP review process, and as
noted in the Background section, the latest version of the PEP [1] has
addressed the key concerns that were raised:

- the "strict" flag for Network objects is gone (instead, the
validation differences between IP Network and IP Interface definitions
are handled as different classes with otherwise similar interfaces)
- the factory function naming scheme follows PEP 8
- some properties have been given new names that make it clearer what
kind of object they produce
- the module itself has been given a new name (ipaddress) to avoid
clashing with the existing ipaddr module on PyPI

There's also basic-but-usable module documentation available
(http://code.google.com/p/ipaddr-py/wiki/Using3144).

So, unless there are any new objections, I'd like to:
- approve ipaddress for inclusion in Python 3.3
- grant Peter Moody push access as the module maintainer
- create a tracker issue to cover incorporating the new module into
the standard library, documentation and test suite

(There are still a few places in both the PEP and the preliminary
documentation that say "ipaddr" instead of "ipaddress", but those can
be cleaned up as the module gets integrated).

I don't personally think the module API needs the provisional
disclaimer as the core functionality has been tested for years in
ipaddr and the API changes in ipaddress are just cosmetic ones either
for PEP 8 conformance, or to make the API map more cleanly to the
underlying networking concepts. However, I'd be willing to include
that proviso if anyone else has lingering concerns.

Regards,
Nick.

[1] http://www.python.org/dev/peps/pep-3144/

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 czar for PEP 3144?

[Antoine Pitrou]

On Mon, 20 Feb 2012 23:23:13 +1000
Nick Coghlan  wrote:
> Does anyone object to me naming myself PEP czar for PEP 3144?

“Tsar is a title used to designate certain European Slavic monarchs or
supreme rulers.”

Is this our official word?

> There's also basic-but-usable module documentation available
> (http://code.google.com/p/ipaddr-py/wiki/Using3144).

Mmmh, some comments:
- a network can be "in" another network? Sounds strange. Compare with
  sets, which can be ordered, but not contained one within another.
  The idea of an address or network being "in" an interface sounds even
  stranger.
- iterhosts()? Why not simply hosts()?
- “A TypeError exception is raised if you try to compare objects of
  different versions or different types.”: I hope equality still works?

Regards

Antoine.


___
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] PEP 394

[anatoly techtonik]

On Mon, Feb 20, 2012 at 4:58 PM, Nick Coghlan  wrote:

> PEP 394
> was at the top of my list recently
>

I've tried to edit it to be a little bit shorter (perhaps cleaner) and
commented (up to revision 2) up to Migration Notes.
http://piratepad.net/pep-0394

The main points:
1. `python2.7` should be `python27`
2. until platform supports Python 2, `python` should link to python2 binary
3. python2 should always point to the latest version available on the
system (I didn't write that in comments)
-- 
anatoly t.
___
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 czar for PEP 3144?

[Nick Coghlan]

On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou  wrote:
> On Mon, 20 Feb 2012 23:23:13 +1000
> Nick Coghlan  wrote:
>> Does anyone object to me naming myself PEP czar for PEP 3144?
>
> “Tsar is a title used to designate certain European Slavic monarchs or
> supreme rulers.”
>
> Is this our official word?

PEP czar/tsar and BDFOP (Benevolent Dictator for One PEP) are the two
names I've seen for the role. I don't have a strong preference either
way (just a mild preference for 'czar').

>> There's also basic-but-usable module documentation available
>> (http://code.google.com/p/ipaddr-py/wiki/Using3144).
>
> Mmmh, some comments:
> - a network can be "in" another network? Sounds strange. Compare with
>  sets, which can be ordered, but not contained one within another.
>  The idea of an address or network being "in" an interface sounds even
>  stranger.

Ah, I'd missed that one. Yes, I think this a holdover from the main
ipaddr module which plays fast and loose with type correctness by
implicitly converting between networks and addresses in all sorts of
places. It doesn't have Network and Interface as separate types
(calling them both "Networks") and it appears the current incarnation
of the Interface API still retains a few too many Network-specific
behaviours.

I agree the "container" behaviour should be reserved for the actual
Network API, with Interface objects behaving more like Addresses in
that respect.

I also agree Network subset and superset checks should follow a
set-style API rather than overloading the containment checks.

There are actually a few other behaviours (like compare_networks()
that should probably be moved to the Network objects, and accessed via
the "network" property for Interface objects.

> - iterhosts()? Why not simply hosts()?

And I missed that one, too. Perhaps that provisional marker wouldn't
be such a bad idea after all...

One requirement for integration would be fleshing out the standard
library version of the documentation to include a full public API
reference for the module and public classes, which will also help
highlight any lingering naming problems, as well as areas where APIs
that currently return realised lists should probably be returning
iterators instead (there's currently iter_subnets() and subnet(),
which should just be a single subnets() iterator).

> - “A TypeError exception is raised if you try to compare objects of
>  different versions or different types.”: I hope equality still works?

It looks like it's supposed to (and does for Address objects), but
there's currently a bug in the _BaseInterface.__eq__ impl that makes
it return None instead of False (the method impl *should* be returning
NotImplemented, just as _BaseAddress does, with the interpreter than
reporting False if both sides return NotImplemented).

There's currently an implicit promotion of Address objects to
Interface objects, such that "network_or_interface == address" is the
same as "network_or_interface.ip == address".

So yes, with the appropriate boundaries between the different types of
objects still being a little blurred, I think a "provisional" marker
is definitely warranted. Some of the APIs that are currently available
directly on Interface objects should really be accessed via their
.network property instead.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 czar for PEP 3144?

[Dirkjan Ochtman]

On Mon, Feb 20, 2012 at 14:23, Nick Coghlan  wrote:
> I don't personally think the module API needs the provisional
> disclaimer as the core functionality has been tested for years in
> ipaddr and the API changes in ipaddress are just cosmetic ones either
> for PEP 8 conformance, or to make the API map more cleanly to the
> underlying networking concepts. However, I'd be willing to include
> that proviso if anyone else has lingering concerns.

Should it be net.ipaddress instead of just ipaddress?

Somewhat nested is better than fully flat.

Cheers,

Dirkjan
___
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 czar for PEP 3144?

[Antoine Pitrou]

On Mon, 20 Feb 2012 16:20:15 +0100
Dirkjan Ochtman  wrote:
> On Mon, Feb 20, 2012 at 14:23, Nick Coghlan  wrote:
> > I don't personally think the module API needs the provisional
> > disclaimer as the core functionality has been tested for years in
> > ipaddr and the API changes in ipaddress are just cosmetic ones either
> > for PEP 8 conformance, or to make the API map more cleanly to the
> > underlying networking concepts. However, I'd be willing to include
> > that proviso if anyone else has lingering concerns.
> 
> Should it be net.ipaddress instead of just ipaddress?
> 
> Somewhat nested is better than fully flat.

IMHO, nesting without a good, consistent, systematic categorization
leads to very unpleasant results (e.g. "from urllib.request import
urlopen").

Historically, our stdlib has been flat and I think it should stay so,
short of redoing the whole hierarchy.

(note this has nothing to do with the possible implementation of
modules as packages, such as unittest or importlib)

Regards

Antoine.


___
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 PEP 397 - Python launcher for Windows

[Mark Lawrence]

On 18/02/2012 05:24, Mark Hammond wrote:

I'm wondering what thoughts are on PEP 397, the Python launcher for
Windows. I've been using the implementation for a number of months now
and I find it incredibly useful.

To my mind, the specific steps would be:

* Have someone pronounce it as accepted (or suggest steps to be taken
before such a pronouncement). I can't recall the current process - does
Guido have to pronounce personally or formally delegate to a czar?

* Move the source into the Python tree and update the build process.

* Arrange for it to be installed with the next release of 3.2 and all
future versions - I'm happy to try and help with that, but will probably
need some help from Martin.

* Write some user-oriented docs.


The section in the docs "Using Python on Windows" would need to be 
updated, but would this have to happen for every current version of Python?


The docs here 
https://bitbucket.org/vinay.sajip/pylauncher/src/tip/Doc/launcher.rst 
are in my view possibly overkill, what do the rest of you think?


The ouput from py --help seems fine but nothing happens when pyw --help 
is entered, is this by accident or design?




Thoughts or comments?

Mark


A cracking bit of kit :)

--
Cheers.

Mark Lawrence.

___
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] folding cElementTree behind ElementTree in 3.3

[martin]

Basically, if something is just documented as being callable without
subclassing or instance checks being mentioned as supported in the
docs, it can be implemented as either a type or an ordinary function,
or pretty much any other kind of callable without being deemed an API
change


So what would be your evaluation of

http://docs.python.org/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element

in that respect?

Regards,
Martin


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

Re: [Python-Dev] PEP czar for PEP 3144?

[martin]

Does anyone object to me naming myself PEP czar for PEP 3144?


“Tsar is a title used to designate certain European Slavic monarchs or
supreme rulers.”

Is this our official word?


"supreme ruler" sounds good to me. I could go for "inquisitor" instead
of "czar" as well...

Regards,
Martin




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

Re: [Python-Dev] PEP czar for PEP 3144?

[Senthil Kumaran]

On Tue, Feb 21, 2012 at 12:07 AM,   wrote:
> "supreme ruler" sounds good to me. I could go for "inquisitor" instead
> of "czar" as well...

But that would be bad for developers from Spain as nobody would expect
a spanish inquisition.

:-)

-- 
Senthil
___
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 czar for PEP 3144?

[Mark Lawrence]

On 20/02/2012 16:28, Senthil Kumaran wrote:

On Tue, Feb 21, 2012 at 12:07 AM,  wrote:

"supreme ruler" sounds good to me. I could go for "inquisitor" instead
of "czar" as well...


But that would be bad for developers from Spain as nobody would expect
a spanish inquisition.

:-)



How about Big Brother then?  As anyone worked in room 101?

--
Cheers.

Mark Lawrence.

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

[Andrew Svetlov]

ArchLinux has used `python` as alias for `python3` while `python2` is
still supported.

On Mon, Feb 20, 2012 at 4:58 PM, anatoly techtonik  wrote:
> On Mon, Feb 20, 2012 at 4:58 PM, Nick Coghlan  wrote:
>>
>> PEP 394
>> was at the top of my list recently
>
>
> I've tried to edit it to be a little bit shorter (perhaps cleaner) and
> commented (up to revision 2) up to Migration Notes.
> http://piratepad.net/pep-0394
>
> The main points:
> 1. `python2.7` should be `python27`
> 2. until platform supports Python 2, `python` should link to python2 binary
> 3. python2 should always point to the latest version available on the system
> (I didn't write that in comments)
> --
> anatoly t.
>
> ___
> 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/andrew.svetlov%40gmail.com
>
___
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 czar for PEP 3144?

[Andrew Svetlov]

I like 'PEP czar'

On Mon, Feb 20, 2012 at 6:50 PM, Mark Lawrence  wrote:
> On 20/02/2012 16:28, Senthil Kumaran wrote:
>>
>> On Tue, Feb 21, 2012 at 12:07 AM,  wrote:
>>>
>>> "supreme ruler" sounds good to me. I could go for "inquisitor" instead
>>> of "czar" as well...
>>
>>
>> But that would be bad for developers from Spain as nobody would expect
>> a spanish inquisition.
>>
>> :-)
>>
>
> How about Big Brother then?  As anyone worked in room 101?
>
> --
> Cheers.
>
> Mark Lawrence.
>
>
> ___
> 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/andrew.svetlov%40gmail.com
___
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 czar for PEP 3144?

[Dirkjan Ochtman]

On Mon, Feb 20, 2012 at 16:27, Antoine Pitrou  wrote:
>> Should it be net.ipaddress instead of just ipaddress?
>>
>> Somewhat nested is better than fully flat.
>
> IMHO, nesting without a good, consistent, systematic categorization
> leads to very unpleasant results (e.g. "from urllib.request import
> urlopen").
>
> Historically, our stdlib has been flat and I think it should stay so,
> short of redoing the whole hierarchy.
>
> (note this has nothing to do with the possible implementation of
> modules as packages, such as unittest or importlib)

I thought Python 3 already came with a net package, but apparently
that plan has long been discarded. So I retract my suggestion.

Cheers,

Dirkjan
___
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] [Python-checkins] cpython: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

[Brett Cannon]

On Sun, Feb 19, 2012 at 22:15, Nick Coghlan  wrote:

> However, "very cool" on adding the caching in the default importers :)


Thanks to PJE for bringing the idea up again and Antoine discovering the
approach *independently* from PJE and myself and actually writing the code.

Now I *really* need to get that C hybrid for __import__() finished (in the
middle of implementing _gcd_import() in C) to see where the performance
ends up.
___
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 czar for PEP 3144?

[Matt Joiner]

On Mon, Feb 20, 2012 at 11:27 PM, Antoine Pitrou  wrote:
> IMHO, nesting without a good, consistent, systematic categorization
> leads to very unpleasant results (e.g. "from urllib.request import
> urlopen").
>
> Historically, our stdlib has been flat and I think it should stay so,
> short of redoing the whole hierarchy.

I concur. Arbitrary nesting should be avoided.
___
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 czar for PEP 3144?

[Terry Reedy]

On 2/20/2012 8:23 AM, Nick Coghlan wrote:

Does anyone object to me naming myself PEP czar for PEP 3144?


I think it great that you volunteer to be the PEP czar and hope Guido 
appoints you -- especially after your response to Antoine. Since this is 
a Python 3 module, let us start off with a modern Python 3 interface. 
That includes returning iterators instead of lists unless there is a 
really good reason.


I can see how an outside developer could have difficulty getting 
integrated into our collective PEP process ;-).


--
Terry Jan Reedy

___
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] Python in Native Client

[Terry Reedy]

On 2/20/2012 7:49 AM, anatoly techtonik wrote:


People on NaCl list are asking about Python support for development
of native web applications in Python. Does anybody have experience
compiling Python for NaCl?



https://groups.google.com/d/topic/native-client-discuss/ioY2jmw_OUQ/discussion


I suggest you ask this on python-list also.

--
Terry Jan Reedy

___
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 czar for PEP 3144?

[Guido van Rossum]

Approved. Nick is PEP czar for PEP 3144. Thanks Nick!

On Mon, Feb 20, 2012 at 11:13 AM, Terry Reedy  wrote:
> On 2/20/2012 8:23 AM, Nick Coghlan wrote:
>>
>> Does anyone object to me naming myself PEP czar for PEP 3144?
>
>
> I think it great that you volunteer to be the PEP czar and hope Guido
> appoints you -- especially after your response to Antoine. Since this is a
> Python 3 module, let us start off with a modern Python 3 interface. That
> includes returning iterators instead of lists unless there is a really good
> reason.
>
> I can see how an outside developer could have difficulty getting integrated
> into our collective PEP process ;-).
>
> --
> Terry Jan Reedy
>
>
> ___
> 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/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
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] [Python-checkins] cpython: Issue #13641: Decoding functions in the base64 module now accept ASCII-only

[Terry Reedy]

On 2/20/2012 1:33 PM, antoine.pitrou wrote:

http://hg.python.org/cpython/rev/c760bd844222
changeset:   75058:c760bd844222
user:Antoine Pitrou
date:Mon Feb 20 19:30:23 2012 +0100
summary:
   Issue #13641: Decoding functions in the base64 module now accept ASCII-only 
unicode strings.
Patch by Catalin Iacob.



+tests = {b"d3d3LnB5dGhvbi5vcmc=": b"www.python.org",
+ b'AA==': b'\x00',
+ b"YQ==": b"a",
+ b"YWI=": b"ab",
+ b"YWJj": b"abc",
+ b"YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXpBQkNE"
+ b"RUZHSElKS0xNTk9QUVJTVFVWV1hZWjAxMjM0\nNT"
+ b"Y3ODkhQCMwXiYqKCk7Ojw+LC4gW117fQ==":
+
+ b"abcdefghijklmnopqrstuvwxyz"
+ b"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
+ b"0123456789!@#0^&*();:<>,. []{}",
+ b'': b'',
+ }
+for data, res in tests.items():


I am a little puzzled why a constant sequence of pairs is being stored 
as a mapping instead of a tuple (or list) of 2-tuples (which is compiled 
more efficiently). As near as I can tell, 'tests' and similar constructs 
later in the file are never used as mappings. Am I missing something or 
is this just the way Catalin wrote it?


--
Terry Jan Reedy
___
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] folding cElementTree behind ElementTree in 3.3

[Nick Coghlan]

On Tue, Feb 21, 2012 at 1:55 AM,   wrote:
>> Basically, if something is just documented as being callable without
>> subclassing or instance checks being mentioned as supported in the
>> docs, it can be implemented as either a type or an ordinary function,
>> or pretty much any other kind of callable without being deemed an API
>> change
>
>
> So what would be your evaluation of
>
> http://docs.python.org/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element
>
> in that respect?

Completely different from the functools.partial case - with that, the
docs are very careful to *never* call functools.partial a class
(instead saying "returns a callable object").

The ElementTree docs unambiguously call Element a class (several
times), so a conforming implementation must provide it as a class
(i.e. supporting use in isinstance() checks. inheritance, etc) rather
than as just a callable. A factory function is not a backwards
compatible replacement (sorry Eli - given those docs, I'm definitely
with Martin on this one).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 394

[Nick Coghlan]

On Tue, Feb 21, 2012 at 12:58 AM, anatoly techtonik  wrote:
> On Mon, Feb 20, 2012 at 4:58 PM, Nick Coghlan  wrote:
>>
>> PEP 394
>> was at the top of my list recently
>
>
> I've tried to edit it to be a little bit shorter (perhaps cleaner) and
> commented (up to revision 2) up to Migration Notes.
> http://piratepad.net/pep-0394
>
> The main points:
> 1. `python2.7` should be `python27`

No, it shouldn't. The default *nix links include the period (it's only
the Windows binaries that leave it out)

> 2. until platform supports Python 2, `python` should link to python2 binary

That's a distro decision - if their Python 2 code is all updated to
specifically use "python2", they can switch the default whenever they
want.

> 3. python2 should always point to the latest version available on the system

No, it should point to the distro installed version or wherever the
system admin decides to point it. So long as it points to *some*
flavour of Python 2, it's in line with the recommendation.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] [Python-checkins] cpython: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

[PJ Eby]

On Mon, Feb 20, 2012 at 1:20 PM, Brett Cannon  wrote:

> On Sun, Feb 19, 2012 at 22:15, Nick Coghlan  wrote:
>
>> However, "very cool" on adding the caching in the default importers :)
>
>
> Thanks to PJE for bringing the idea up again and Antoine discovering the
> approach *independently* from PJE and myself and actually writing the code.
>

Where is the code, btw?   (I looked at your sandbox and didn't see it.)
___
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] [Python-checkins] cpython: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

[Brett Cannon]

On Mon, Feb 20, 2012 at 17:29, PJ Eby  wrote:

> On Mon, Feb 20, 2012 at 1:20 PM, Brett Cannon  wrote:
>
>> On Sun, Feb 19, 2012 at 22:15, Nick Coghlan  wrote:
>>
>>> However, "very cool" on adding the caching in the default importers :)
>>
>>
>> Thanks to PJE for bringing the idea up again and Antoine discovering the
>> approach *independently* from PJE and myself and actually writing the code.
>>
>
> Where is the code, btw?   (I looked at your sandbox and didn't see it.)
>
>
It's not in the sandbox until I do a merge; Antoine committed the code to
default so it's already in Python 3.3.
___
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] [Python-checkins] cpython: Issue #13641: Decoding functions in the base64 module now accept ASCII-only

[Antoine Pitrou]

On Mon, 20 Feb 2012 16:31:13 -0500
Terry Reedy  wrote:
> 
> I am a little puzzled why a constant sequence of pairs is being stored 
> as a mapping instead of a tuple (or list) of 2-tuples (which is compiled 
> more efficiently). As near as I can tell, 'tests' and similar constructs 
> later in the file are never used as mappings. Am I missing something or 
> is this just the way Catalin wrote it?

This is just the way Catalin wrote it.  If the style bothers you, you
can always change it.  I don't think it makes much of a difference
either way.

(but if you really care about compilation efficiency in tests you are
probably the victim of premature optimization)

Regards

Antoine.


___
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 PEP 397 - Python launcher for Windows

[Mark Hammond]

On 21/02/2012 2:54 AM, Mark Lawrence wrote:

On 18/02/2012 05:24, Mark Hammond wrote:

...


* Write some user-oriented docs.


The section in the docs "Using Python on Windows" would need to be
updated, but would this have to happen for every current version of Python?


I'm not sure what docs you are referring to here?


The docs here
https://bitbucket.org/vinay.sajip/pylauncher/src/tip/Doc/launcher.rst
are in my view possibly overkill, what do the rest of you think?


Even though I had no input into those docs, I actually think they are 
fairly good and can't see what should be dropped.  It may make sense to 
split the docs so there is a separate "advanced" doc page.  Further, I 
think there is something that could be added to those docs - the use of 
PATHEXT and the fact that once the shebang line is in place, a 
command-prompt could do just "hello.py" rather than needing "py hello.py".



The ouput from py --help seems fine but nothing happens when pyw --help
is entered, is this by accident or design?


I guess "accident" - or more accurately, the lack of doing anything 
special.  It could be useful to have that display a message box with the 
usage - while that would break "pyw --help > out.txt", I doubt that 
really is useful for anyone.  Alternatively, instead of trying to 
display all the usage in "pyw --help", it could display a short message 
indicating what the program is for and refer to "py.exe --help" for more 
information.  Possibly a plain "pyw" (with no args) could do the same 
thing - nothing useful happens in that case either.



Thoughts or comments?

Mark


A cracking bit of kit :)


Thanks!  Vinay's implementation is great, I agree.

Thanks,

Mark


___
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 PEP 397 - Python launcher for Windows

[Mark Lawrence]

On 20/02/2012 23:48, Mark Hammond wrote:

On 21/02/2012 2:54 AM, Mark Lawrence wrote:

The section in the docs "Using Python on Windows" would need to be
updated, but would this have to happen for every current version of
Python?


I'm not sure what docs you are referring to here?



See http://docs.python.org/using/windows.html


Mark



--
Cheers.

Mark Lawrence.

___
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 czar for PEP 3144?

[Steven D'Aprano]

Nick Coghlan wrote:

On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou  wrote:

On Mon, 20 Feb 2012 23:23:13 +1000
Nick Coghlan  wrote:

Does anyone object to me naming myself PEP czar for PEP 3144?

“Tsar is a title used to designate certain European Slavic monarchs or
supreme rulers.”

Is this our official word?


PEP czar/tsar and BDFOP (Benevolent Dictator for One PEP) are the two
names I've seen for the role. I don't have a strong preference either
way (just a mild preference for 'czar').


Also, "Czar" is commonly used in US politics as an informal term for the top 
official responsible for an area. "Drug Czar" is only the most familiar:


http://en.wikipedia.org/wiki/List_of_U.S._executive_branch_%27czars%27



--
Steven
___
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 czar for PEP 3144?

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > Also, "Czar" is commonly used in US politics as an informal term for the top 
 > official responsible for an area.

I think here the most important connotation is that in US parlance a
"czar" does not report to a committee, and with the exception of a
case where Sybil is appointed czar, cannot bikeshed.  Decisions get
made (what a concept!)
___
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] accept string in a2b and base64?

[R. David Murray]

Two patches have been committed to 3.3 that I am very uncomfortable with.
See issue 13637 and issue 13641, respectively.

It seems to me that part of the point of the byte/string split (and the
lack of automatic coercion) is to make the programmer be explicit about
converting between unicode and bytes.  Having these functions, which
convert between binary formats (ASCII-only representations of binary data
and back) accept unicode strings is reintroducing automatic coercions,
and I think it will lead to the same kind of bugs that automatic string
coercions yielded in Python2: a program works fine until the input
turns out to have non-ASCII data in it, and then it blows up with an
unexpected UnicodeError.  You can see Antoine's counter arguments in the
issue, and I'm sure he'll chime in here.

If most people agree with Antoine I won't fight it, but it seems to me
that accepting unicode in the binascii and base64 APIs is a bad idea.

I'm on vacation this week so I may not be very responsive on this thread,
but unless other people agree with me (and will therefore advance the
relevant arguments) the thread can die and the patches can stay in.

--David
___
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] folding cElementTree behind ElementTree in 3.3

[Eli Bendersky]

On Tue, Feb 21, 2012 at 00:51, Nick Coghlan  wrote:

> On Tue, Feb 21, 2012 at 1:55 AM,   wrote:
> >> Basically, if something is just documented as being callable without
> >> subclassing or instance checks being mentioned as supported in the
> >> docs, it can be implemented as either a type or an ordinary function,
> >> or pretty much any other kind of callable without being deemed an API
> >> change
> >
> >
> > So what would be your evaluation of
> >
> >
> http://docs.python.org/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element
> >
> > in that respect?
>
> Completely different from the functools.partial case - with that, the
> docs are very careful to *never* call functools.partial a class
> (instead saying "returns a callable object").
>
> The ElementTree docs unambiguously call Element a class (several
> times), so a conforming implementation must provide it as a class
> (i.e. supporting use in isinstance() checks. inheritance, etc) rather
> than as just a callable. A factory function is not a backwards
> compatible replacement (sorry Eli - given those docs, I'm definitely
> with Martin on this one).
>

No need to be sorry :-) I don't think my view differs from Martin's here,
by the way. My point is just that this isn't a regression, since "use
cElementTree" is ubiquitous advice, and the C implementation has Element as
a factory function and not a class, so the documentation wasn't correct to
begin with. So the documentation isn't correct for previous versions any
way you look at it. There's a conflict in that it says Element is a class
and also that cElementTree implements the same API.

So the two choices here are either change the documentation or the C
implementation to actually make Element a class. The first is of course
simpler. However, someone somewhere may have written code that knowingly
forces the Python implementation to be used and subclasses Element. Such
code will break in 3.3, so it probably makes sense to invest in making
Element a class in the C implementation as well.

Eli
___
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 czar for PEP 3144?

[Nick Coghlan]

On Tue, Feb 21, 2012 at 7:09 AM, Guido van Rossum  wrote:
> Approved. Nick is PEP czar for PEP 3144. Thanks Nick!

In that case the addition of the "ipaddress" module is approved for
3.3, with a provisional caveat on the API details. I'm doing it that
way because I think those remaining details can be better flushed out
by the integration process (in particular, populating full module API
reference documentation) than they could by another round of updates
on the PEP and the ipaddr 3144 branch.

At the very least:
- the IP Interface API needs to move to a point where it more clearly
*is* an IP Address and *has* an associated IP Network (rather than
being the other way around)
- IP Network needs to behave more like an ordered set of sequential IP
Addresses (without sometimes behaving like an Address in its own
right)
- iterable APIs should consistently produce iterators (leaving users
free to wrap list() around the calls if they want the concrete
realisation)

Initial maintainers will be me (for the semantically cleaner
incarnation of the module API) and Peter (for the IPv4 and IPv6
correctness heavy lifting and ensuring any API updates only change the
spelling of particular operations, such as adding a ".network." to
some current operations on Interface objects, rather than reducing
overall module functionality).

This approach means we will still gain the key benefits of using the
PyPI-tested ipaddr as a base (i.e. correct IP address parsing and
generation, full coverage of the same set of supported operations)
while exposing a simpler semantic model for new users that first
encounter these concepts through the standard library module
documentation:

- IP Address as the core abstraction
- IP Network as a container for IP Addresses
- IP Interface as an IP Address with an associated IP Network

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] hash randomization in the 2.6 branch

[Barry Warsaw]

I've just committed a back port of issue 13703, the hash randomization patch,
to the Python 2.6 branch.  I have left the forward porting of this to Python
2.7 to Benjamin.

test_json will fail with randomization enabled since there is a sort order
dependency in the __init__.py doctest.  I'm not going to fix this (it can't be
fixed in the same way 2.7 can), but I'd gladly accept a patch if it's not too
nasty.  If not, then it doesn't bother me because we previously agreed that it
is not a showstopper for the tests to pass in Python 2.6 with randomization
enabled.

Please however, do test the Python 2.6 branch thoroughly, both with and
without randomization.  We'll be coordinating release candidates between all
affected branches fairly soon.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
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] accept string in a2b and base64?

[Antoine Pitrou]

On Mon, 20 Feb 2012 20:24:16 -0500
"R. David Murray"  wrote:
> 
> It seems to me that part of the point of the byte/string split (and the
> lack of automatic coercion) is to make the programmer be explicit about
> converting between unicode and bytes.  Having these functions, which
> convert between binary formats (ASCII-only representations of binary data
> and back) accept unicode strings is reintroducing automatic coercions,

Whether a baseXX representation is binary or text can probably be
argued endlessly. As a data point, hex() returns str, not bytes, so at
least base16 can be considered (potentially) text. And the point of
baseXX representations is generally to embed binary data safely into
text, which explains why you may commonly need to baseXX-decode some
chunk of text. This occurred to me when porting Twisted to py3k; I'm
sure other networking code would also benefit.

Really, I think there's no problem with coercions when they are
unambiguous and safe (which they are, in the committed patches). They
make writing and porting code easier.
For example, we already have:

>>> int("10")
10
>>> int(b"10")
10

Regards

Antoine.


___
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] cpython (2.6): - Issue #13703: oCERT-2011-003: add -R command-line option and PYTHONHASHSEED

[Antoine Pitrou]

On Tue, 21 Feb 2012 02:44:32 +0100
barry.warsaw  wrote:
> +   This is intended to provide protection against a denial-of-service caused 
> by
> +   carefully-chosen inputs that exploit the worst case performance of a dict
> +   insertion, O(n^2) complexity.  See
> +   http://www.ocert.org/advisories/ocert-2011-003.html for details.

The worst case performance of a dict insertion is O(n) (not counting
potential resizes, whose cost is amortized by the overallocation
heuristic). It's dict construction that has O(n**2) worst case
complexity.

> @@ -1232,9 +1233,9 @@
>  flags__doc__,   /* doc */
>  flags_fields,   /* fields */
>  #ifdef RISCOS
> +17
> +#else
>  16
> -#else
> -15
>  #endif

Changing the sequence size of sys.flags can break existing code (e.g.
tuple-unpacking).

Regards

Antoine.


___
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] folding cElementTree behind ElementTree in 3.3

[Nick Coghlan]

On Tue, Feb 21, 2012 at 11:39 AM, Eli Bendersky  wrote:
> So the two choices here are either change the documentation or the C
> implementation to actually make Element a class. The first is of course
> simpler. However, someone somewhere may have written code that knowingly
> forces the Python implementation to be used and subclasses Element. Such
> code will break in 3.3, so it probably makes sense to invest in making
> Element a class in the C implementation as well.

Yeah, that's my take as well (especially since, in 3.2 and earlier,
"forcing" use of the pure Python version was just a matter of
importing ElementTree instead of cElementTree).

While Xavier's point about lxml following cElementTree's lead and
using a factory function is an interesting one, I think in this case
the documented behaviour + pure Python implementation win out over the
C accelerator behaviour.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] cpython (2.6): - Issue #13703: oCERT-2011-003: add -R command-line option and PYTHONHASHSEED

[Benjamin Peterson]

2012/2/20 Benjamin Peterson :
> I told George

Sorry, Georg!



-- 
Regards,
Benjamin
___
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] cpython (2.6): - Issue #13703: oCERT-2011-003: add -R command-line option and PYTHONHASHSEED

[Benjamin Peterson]

2012/2/20 Antoine Pitrou :
> On Tue, 21 Feb 2012 02:44:32 +0100
> barry.warsaw  wrote:
>> +   This is intended to provide protection against a denial-of-service 
>> caused by
>> +   carefully-chosen inputs that exploit the worst case performance of a dict
>> +   insertion, O(n^2) complexity.  See
>> +   http://www.ocert.org/advisories/ocert-2011-003.html for details.
>
> The worst case performance of a dict insertion is O(n) (not counting
> potential resizes, whose cost is amortized by the overallocation
> heuristic). It's dict construction that has O(n**2) worst case
> complexity.
>
>> @@ -1232,9 +1233,9 @@
>>      flags__doc__,       /* doc */
>>      flags_fields,       /* fields */
>>  #ifdef RISCOS
>> +    17
>> +#else
>>      16
>> -#else
>> -    15
>>  #endif
>
> Changing the sequence size of sys.flags can break existing code (e.g.
> tuple-unpacking).

I told George I didn't think it was a major problem. How much code
have you seen trying to upack sys.flags? (Moreover, such code would
have been broken by previous minor releases.)


-- 
Regards,
Benjamin
___
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] accept string in a2b and base64?

[Nick Coghlan]

On Tue, Feb 21, 2012 at 11:24 AM, R. David Murray  wrote:
> If most people agree with Antoine I won't fight it, but it seems to me
> that accepting unicode in the binascii and base64 APIs is a bad idea.

I see it as essentially the same as the changes I made in
urllib.urlparse to support pure ASCII bytes->bytes in many of the APIs
(which work by doing an implicit ascii+strict decode at the beginning
of the function, and then reversing that at the end). For those, if
your byte sequence has non-ASCII data in it, they'll throw a
UnicodeDecodeError and it's up to you to figure out where those
non-ASCII bytes are coming from. Similarly, if one of these updated
APIs throws ValueError, then you'll have to figure out where the
non-ASCII code points are coming from.

Yes, it's a niggling irritation from a purist point of view, but it's
also an acknowledgement of the fact that whether a pure ASCII sequence
should be treated as a sequence of bytes or a sequence of code points
is going to be application and context depended. Sometimes it will
make more sense to treat it as binary data, other times as text.

The key point is that any multimode support that depends on implicit
type conversion from bytes->str (or vice-versa) really needs to be
limited to *strict* ASCII only (if no other information on the
encoding is available). If something is 7-bit ASCII pure, then odds
are very good that it really *is* ASCII text. As soon as that
high-order bit gets set though, all bets are off and we have to push
the text encoding problem back on the API caller to figure out.

The reason Python 2's implicit str<->unicode conversions are so
problematic isn't just because they're implicit: it's because they
effectively assume *latin-1* as the encoding on the 8-bit str side.
That means reliance on implicit decoding can silently corrupt
non-ASCII data instead of triggering exceptions at the point of
implicit conversion. If you're lucky, some *other* part of the
application will detect the corruption and you'll have at least a
vague hope of tracking it down. Otherwise, the corrupted data may
escape the application and you'll have an even *thornier* debugging
problem on your hands.

My one concern with the base64 patch is that it doesn't test that
mixing types triggers TypeError. While this shouldn't require any
extra code (the error should arise naturally from the method
implementation), it should still be tested explicitly to ensure type
mismatches fail as expected. Checking explicitly for mismatches in the
code would then just be a matter of wanting to emit nice error
messages explaining the problem rather than being needed for
correctness reasons (e.g. urlparse uses pre-checks in order to emit a
clear error message for type mismatches, but it has significantly
longer function signatures to deal with).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 czar for PEP 3144?

[Guido van Rossum]

On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull  wrote:
> Steven D'Aprano writes:
>
>  > Also, "Czar" is commonly used in US politics as an informal term for the 
> top
>  > official responsible for an area.
>
> I think here the most important connotation is that in US parlance a
> "czar" does not report to a committee, and with the exception of a
> case where Sybil is appointed czar, cannot bikeshed.  Decisions get
> made (what a concept!)

I'm curious how old that usage is. I first encountered it around '88
when I interned for a summer at DEC SRC (long since subsumed into HP
Labs); the person in charge of deciding a particular aspect of their
software or organization was called a czar, e.g. the documentation
czar.

-- 
--Guido van Rossum (python.org/~guido)
___
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 czar for PEP 3144?

[Terry Reedy]

On 2/20/2012 11:52 PM, Guido van Rossum wrote:

On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull  wrote:

Steven D'Aprano writes:

  >  Also, "Czar" is commonly used in US politics as an informal term for the 
top
  >  official responsible for an area.

I think here the most important connotation is that in US parlance a
"czar" does not report to a committee, and with the exception of a
case where Sybil is appointed czar, cannot bikeshed.  Decisions get
made (what a concept!)


I'm curious how old that usage is. I first encountered it around '88
when I interned for a summer at DEC SRC (long since subsumed into HP
Labs); the person in charge of deciding a particular aspect of their
software or organization was called a czar, e.g. the documentation
czar.


In US politics, the first I remember was the Drug Czar about that time. 
It really came into currently during Clinton's admin.


--
Terry Jan Reedy

___
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] [Python-checkins] cpython (merge 2.6 -> 2.7): merge 2.6 with hash randomization fix

[Gregory P. Smith]

On Mon, Feb 20, 2012 at 10:19 PM, Gregory P. Smith  wrote:
> Look at PCbuild/pythoncore.vcproj within this commit, it looks like
> you committed (or merged) a merge conflict marker in the file.
>
> -gps
>
> On Mon, Feb 20, 2012 at 6:49 PM, benjamin.peterson
>  wrote:
>> http://hg.python.org/cpython/rev/a0f43f4481e0
>> changeset:   75102:a0f43f4481e0
>> branch:      2.7

nevermind I see the follow up fixing commits now. :)
___
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] cpython (2.7): use set

[Georg Brandl]

Am 21.02.2012 05:13, schrieb benjamin.peterson:
> http://hg.python.org/cpython/rev/98732d20b6d1
> changeset:   75112:98732d20b6d1
> branch:  2.7
> user:Benjamin Peterson 
> date:Mon Feb 20 23:11:19 2012 -0500
> summary:
>   use set
> 
> files:
>   Lib/re.py |  5 +
>   1 files changed, 1 insertions(+), 4 deletions(-)
> 
> 
> diff --git a/Lib/re.py b/Lib/re.py
> --- a/Lib/re.py
> +++ b/Lib/re.py
> @@ -198,10 +198,7 @@
>  "Compile a template pattern, returning a pattern object"
>  return _compile(pattern, flags|T)
>  
> -_alphanum = {}
> -for c in 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890':
> -_alphanum[c] = 1
> -del c
> +_alphanum = 
> set('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890')

Seems the "0" is twice in that set. ;-)

Georg

___
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] cpython (2.6): - Issue #13703: oCERT-2011-003: add -R command-line option and PYTHONHASHSEED

[Éric Araujo]

Le 21/02/2012 03:04, Benjamin Peterson a écrit :
> 2012/2/20 Antoine Pitrou :
>> Changing the sequence size of sys.flags can break existing code (e.g.
>> tuple-unpacking).
> 
> I told George I didn't think it was a major problem. How much code
> have you seen trying to upack sys.flags? (Moreover, such code would
> have been broken by previous minor releases.)

If by “minor” you mean the Y in Python X.Y.Z, then I think the precedent
does not apply here: people expect to have to check their code when
going from X.Y to X.Y+1, but not when they update X.Y.Z to X.Y.Z+1.  But
I agree this is rather theoretical, as I don’t see why anyone would
iterate over sys.flags.

The important point IMO is having clear policies for us and our users
and sticking with them; here the decision was that adding a new flag in
a bugfix release was needed, so it’s fine.

Regards
___
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] A panel with Guido/python-dev on scientific uses and Python 3 at Google HQ, March 2nd

[Fernando Perez]

Hi all,

I wanted to point out to you folks, and invite any of you who could make 
it in person, to a panel discussion we'll be having on Friday March 2nd, 
at 3pm, during the PyData workshop that will take place at Google's 
headquarters in Mountain View:

http://pydataworkshop.eventbrite.com

The PyData workshop is organized by several developers coming from the 
numerical/scientific side of the Python world, and we thought this would 
be a good opportunity, both timing- and logistics-wise, for a discussion 
with as many Python developers as possible.  The upcoming Python 3.3 
release, the lifting of the language moratorium, the gradual (but slow) 
uptake of Python 3 in science, the continued and increasing growth of 
Python as a tool in scientific research and education, etc, are all good 
reasons for thinking this could be a productive discussion.

This is the thread on the Numpy mailing list where we've had some back-and-
forth about ideas:

http://mail.scipy.org/pipermail/numpy-discussion/2012-February/060437.html


Guido has already agreed to participate, and a number of developers for 
'core' scientific Python projects will be present at the panel, including:

- Travis Oliphant, Peter Wang, Mark Wiebe, Stefan van der Walt (Numpy, 
Scipy)
- John Hunter (Matplotlib)
- Fernando Perez, Brian Granger, Min Ragan-Kelley (IPython)
- Dag Sverre Seljebotn (Numpy, Cython)

It would be great if as many core Python developers for whom a Bay Area 
Friday afternoon drive to Mountain View is feasible could attend.  Those 
of you already at Google will hopefully all make it, of course :)

We hope this discussion will be a good start for interesting developments 
that require dialog between the 'science crowd' and python-dev.  Several 
of us will also be available at PyCon 2012, so if there's interest we can 
organize an informal follow-up/BoF on this topic the next week at PyCon.

Please forward this information to anyone you think might be interested 
(I'll be posting in a second to the Bay Piggies list).

If you are not a Googler nor already registered for PyData, but would like 
to attend, please let me know by emailing me at:

fernando.pe...@berkeley.edu

We have room for a few extra people (in addition to PyData attendees) for 
this particular meeting, and we'll do our best to accomodate you.  Please 
let me know if you're a core python committer in your message.

I'd like to thank Google for their hospitality in hosting us for PyData, 
and Guido for his willingness to take part in this discussion.  I hope it 
will be a productive one for all involved.

Best,

f

___
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