Re: [Python-Dev] [issue6673] Py3.1 hangs in coroutine and eats up all memory

[Stefan Behnel]

Antoine Pitrou wrote:
> Stefan Behnel  behnel.de> writes:
>> IMHO, that's pretty far from obvious when you look at the code.
> 
> A "yield" wrapped in a list comprehension looks far from obvious IMO anyway,
> whether in 2.x or 3.x. It's this kind of "smart" writing tricks people find 
> that
> only makes code more difficult to read for others (à la Perl).

So, your vote is to make it a compiler error as well?

Stefan

___
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] Microsoft MSDN

[Christian Heimes]

Steve Holden wrote:

I sent fourteen requests for licenses in to Microsoft. I've asked them
to let me know which they grant (since they may choose to limit the
number) and will inform you all personally when I hear their decision.


I've received my MSDN subscription today. Everybody watch out for a 
message from MSDN! I almost confused the email with spam.


Thanks for your work and please forward my gratitude to James Rice.

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

Re: [Python-Dev] standard library mimetypes module pathologically broken?

[Georg Brandl]

Nick Coghlan schrieb:
> Nick Coghlan wrote:
>> Benjamin Peterson wrote:
>>> 
>>> If python-dev was more interested, we would have a policy for this. *cough*
>>> 
>> 
>> PEP 5 isn't enough? (I'll grant that PEP could probably do with
>> mentioning the use of warnings.warn(DeprecationWarning) explicitly, but
>> the policy itself seems fine)
> 
> Oops, I get it now :)
> 
> Cheers,
> Nick.
> 
> P.S. For anyone else that is slow like me, take a close look at PEP 387...

What should we see, other than that we have two PEPs on the same topic that
should be merged?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] request for comments - standardization of python's purelib and platlib

[Jan Matejek]

Hello,

I'm cross-posting this to distributi...@freedesktop and python-dev,
because the topic is relevant to both groups and should be solved in
cooperation.

The issue:

In Python's default configuration (on linux), both purelib (location for
pure python modules) and platlib (location for platform-dependent binary
extensions) point to $prefix/lib/pythonX.Y/site-packages.
That is no good for two main reasons.

One, python depends on the "lib" directory. (from distro's point of
view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
impossible to install python under /usr/lib64 without heavy patching.
Repeated attempts to bring python developers to acknowledge and rectify
the situation have all failed (common argument here is "that would mean
redesign of distutils and huge parts of whatnot").

Conversely, that also means that multiarch setup (/usr/lib or lib32 with
32bit python and /usr/lib64 with 64bit python) is not possible with
stock python.

Two, the default configuration makes purelib and platlib identical,
which somehow defeats the purpose of the distinction in the first place.
You either need to patch the default, or supply some alternate
configuration to take advantage of this feature.
And that's not the end of it - the next step is to make python aware of
two different locations on sys.path, one for purelib and one for
platlib, which is a different story altogether.

As distributors, we like to take advantage of purelib/platlib separation
to package pure python modules as platform-independent (noarch for
rpm-speakers). And that's not easy to do properly.

The proposal:

Let's put our heads together and choose good default locations for
purelib and platlib. Then add support to python for recognizing the
locations by default, and possibly leave note in FHS that "this is the
place".

This is IMO a good first step to making python multiarch-aware, and it
would also help a bit with LSB integration [1].

I've come up with three basic options for the configuration (substitute
"/usr" with "$prefix" if you're not a distributor). This list is by no
means comprehensive, it's just what looked reasonable at the time of
writing.

1 - the traditional way
purelib = /usr/lib/pythonX.Y/site-packages
platlib = /usr/lib(64)/pythonX.Y/site-packages

pros:
+ this is already the default for 32bit systems
+ major distributions (including Fedora, Mandriva and now finally
openSUSE too) do this
cons:
- 32bit systems have no separation, poor they!
- with multiarch setup, /usr/lib is "cluttered" by both
platform-dependent files for 32bit and platform-independent files shared
by the platforms. Also, 64bit python can pick up 32bit modules. That
doesn't cause problems in practice, but doesn't fell like a clean design.

2 - the sharedir way
purelib = /usr/share/python/X.Y
platlib = /usr/lib(64)/pythonX.Y/site-packages

pros:
+ clean separation of purelib - nice!
+ unheard of - a good place to start anew
cons:
- FHS states that /usr/share is for data. But OTOH, they don't say much
about platform-independent bytecode. We could probably get an exception
for this.
- unheard of - everyone will be surprised

3 - the perl way
purelib = /usr/lib/pythonX.Y
platlib = /usr/lib/pythonX.Y/lib-dynload-(platform-identifier)/site-packages

pros:
+ possibility of multiarch packages that would install pure python parts
into purelib and extensions or accelerators for more platforms at once -
and therefore, possibility to split large modules into
platform-dependent and platform-independent parts and save space on
installation media
+ "idea compatibility" with perl and ruby, one less install layout to learn
cons:
- completely different from what we have now - would require the most
work from both python developers and distributions

comments?

regards
jan matejek
python packager for SUSE Linux

[1] http://www.linuxfoundation.org/en/LsbPython

___
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] Microsoft MSDN

[David Bolen]

Christian Heimes  writes:

> Steve Holden wrote:
>> I sent fourteen requests for licenses in to Microsoft. I've asked them
>> to let me know which they grant (since they may choose to limit the
>> number) and will inform you all personally when I hear their decision.
>
> I've received my MSDN subscription today. Everybody watch out for a
> message from MSDN! I almost confused the email with spam.
>
> Thanks for your work and please forward my gratitude to James Rice.

Ditto from me (my subscription info arrived yesterday afternoon).  Many
thanks to all involved!

-- 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] request for comments - standardization of python's purelib and platlib

[Brett Cannon]

On Thu, Aug 13, 2009 at 11:23, Jan Matejek  wrote:

> Hello,
>
> I'm cross-posting this to distributi...@freedesktop and python-dev,
> because the topic is relevant to both groups and should be solved in
> cooperation.
>
> The issue:
>
> In Python's default configuration (on linux), both purelib (location for
> pure python modules) and platlib (location for platform-dependent binary
> extensions) point to $prefix/lib/pythonX.Y/site-packages.
> That is no good for two main reasons.
>
> One, python depends on the "lib" directory. (from distro's point of
> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
> impossible to install python under /usr/lib64 without heavy patching.
> Repeated attempts to bring python developers to acknowledge and rectify
> the situation have all failed (common argument here is "that would mean
> redesign of distutils and huge parts of whatnot").
>

This is now Tarek's call, so this may or may not have changed in terms of
what the (now) distutils maintainer thinks.


>
> Conversely, that also means that multiarch setup (/usr/lib or lib32 with
> 32bit python and /usr/lib64 with 64bit python) is not possible with
> stock python.
>
> Two, the default configuration makes purelib and platlib identical,
> which somehow defeats the purpose of the distinction in the first place.
> You either need to patch the default, or supply some alternate
> configuration to take advantage of this feature.
> And that's not the end of it - the next step is to make python aware of
> two different locations on sys.path, one for purelib and one for
> platlib, which is a different story altogether.
>
> As distributors, we like to take advantage of purelib/platlib separation
> to package pure python modules as platform-independent (noarch for
> rpm-speakers). And that's not easy to do properly.
>
> The proposal:
>
> Let's put our heads together and choose good default locations for
> purelib and platlib. Then add support to python for recognizing the
> locations by default, and possibly leave note in FHS that "this is the
> place".
>
> This is IMO a good first step to making python multiarch-aware, and it
> would also help a bit with LSB integration [1].
>
> I've come up with three basic options for the configuration (substitute
> "/usr" with "$prefix" if you're not a distributor). This list is by no
> means comprehensive, it's just what looked reasonable at the time of
> writing.
>
> 1 - the traditional way
> purelib = /usr/lib/pythonX.Y/site-packages
> platlib = /usr/lib(64)/pythonX.Y/site-packages
>

Why can't pure libraries go into lib64 as well? There is nothing saying that
a pure Python package won't have a setup.py that installs different files
based on whether it is for a 32-bit or 64-bit CPython install.


>
> pros:
> + this is already the default for 32bit systems
> + major distributions (including Fedora, Mandriva and now finally
> openSUSE too) do this
> cons:
> - 32bit systems have no separation, poor they!
> - with multiarch setup, /usr/lib is "cluttered" by both
> platform-dependent files for 32bit and platform-independent files shared
> by the platforms. Also, 64bit python can pick up 32bit modules. That
> doesn't cause problems in practice, but doesn't fell like a clean design.
>
> 2 - the sharedir way
> purelib = /usr/share/python/X.Y
> platlib = /usr/lib(64)/pythonX.Y/site-packages


Now are you proposing that packages that have both Python source and
extensions be split based on the type of files, or that only pure Python
packages go to /usr/share/python and any packages that are mixed go into
lib(64)? If you are proposing the latter this is more reasonable as the
former will require using .pth files to get import to search both locations
for files in the same package and that just feels icky to me.


>
> pros:
> + clean separation of purelib - nice!
> + unheard of - a good place to start anew
> cons:
> - FHS states that /usr/share is for data. But OTOH, they don't say much
> about platform-independent bytecode. We could probably get an exception
> for this.
> - unheard of - everyone will be surprised


> 3 - the perl way
> purelib = /usr/lib/pythonX.Y
> platlib =
> /usr/lib/pythonX.Y/lib-dynload-(platform-identifier)/site-packages
>
> pros:
> + possibility of multiarch packages that would install pure python parts
> into purelib and extensions or accelerators for more platforms at once -
> and therefore, possibility to split large modules into
> platform-dependent and platform-independent parts and save space on
> installation media
> + "idea compatibility" with perl and ruby, one less install layout to learn
> cons:
> - completely different from what we have now - would require the most
> work from both python developers and distributions
>

I think that last con says what chances this approach has of winning. =)

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe

[Python-Dev] PyCon 2010: Call for Proposals

[Jesse Noller]

Yup! It's that time again, I'm encouraging anyone involved in core
development, or wanting to talk about core development - or
python-core internals to submit talk proposals. Lots of people have
expressed interest in such talks.
-jesse

Call for proposals -- PyCon 2010 -- 
===

Due date: October 1st, 2009

Want to showcase your skills as a Python Hacker? Want to have
hundreds of people see your talk on the subject of your choice? Have some
hot button issue you think the community needs to address, or have some
package, code or project you simply love talking about? Want to launch
your master plan to take over the world with python?

PyCon is your platform for getting the word out and teaching something
new to hundreds of people, face to face.

Previous PyCon conferences have had a broad range of presentations,
from reports on academic and commercial projects, tutorials on a broad
range of subjects and case studies. All conference speakers are volunteers
and come from a myriad of backgrounds. Some are new speakers, some
are old speakers. Everyone is welcome so bring your passion and your
code! We're looking to you to help us top the previous years of success
PyCon has had.

PyCon 2010 is looking for proposals to fill the formal presentation tracks.
The PyCon conference days will be February 19-22, 2010 in Atlanta,
Georgia, preceded by the tutorial days (February 17-18), and followed
by four days of development sprints (February 22-25).

Online proposal submission is open now! Proposals  will be accepted
through October 1st, with acceptance notifications coming out on
November 15th. For the detailed call for proposals, please see:

 

For videos of talks from previous years - check out:



We look forward to seeing you in Atlanta!
___
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] [RELEASED] Python 3.1.1 Release Candidate

[Benjamin Peterson]

On behalf of the Python development team, I'm pleased to announce the first
release candidate of Python 3.1.1.

This bug fix release fixes many normal bugs and several critical ones including
potential data corruption in the io library.  The final version should be out
within the next week.

Python 3.1 focuses on the stabilization and optimization of the features and
changes that Python 3.0 introduced.  For example, the new I/O system has been
rewritten in C for speed.  File system APIs that use unicode strings now handle
paths with undecodable bytes in them. Other features include an ordered
dictionary implementation, a condensed syntax for nested with statements, and
support for ttk Tile in Tkinter.  For a more extensive list of changes in 3.1,
see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python
distribution.

To download Python 3.1.1 visit:

 http://www.python.org/download/releases/3.1/

The 3.1 documentation can be found at:

 http://docs.python.org/3.1

Bugs can always be reported to:

 http://bugs.python.org


Enjoy!

--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 3.1.1's contributors)
___
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] request for comments - standardization of python's purelib and platlib

[David Lyon]

Hi Jan,

It's not impossible, but you have some dependencies.

If you can patch distutils within Suse, then it mightn't be so
difficult. Distutils is not much more than a file copier.

Inside distutils, a lot of the paths that you are talking
about are hardcoded. 

> One, python depends on the "lib" directory. (from distro's point of
> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
> impossible to install python under /usr/lib64 without heavy patching.

correction - light patching. 

> Repeated attempts to bring python developers to acknowledge and rectify
> the situation have all failed (common argument here is "that would mean
> redesign of distutils and huge parts of whatnot").

Make it a zope/plone issue... and something might get done about it

haha

If it's a windows or linux issue... pour petrol on it and light a match..

seriously... it's not major refactoring.. it's just changing a few
conditional
constants.. within distutils..

> Let's put our heads together and choose good default locations for
> purelib and platlib. Then add support to python for recognizing the
> locations by default, and possibly leave note in FHS that "this is the
> place".

Sure - discuss away. But you might end up having to patch your own
distribution.

> 2 - the sharedir way
> purelib = /usr/share/python/X.Y
> platlib = /usr/lib(64)/pythonX.Y/site-packages
> 
> pros:
> + clean separation of purelib - nice!
> + unheard of - a good place to start anew
> cons:
> - FHS states that /usr/share is for data. But OTOH, they don't say much
> about platform-independent bytecode. We could probably get an exception
> for this.
> - unheard of - everyone will be surprised

+1

Go try...

David

http://sourceforge.net/projects/pythonpkgmgr/

___
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