Re: [Python-Dev] Exception chaining and generator finalisation

[Greg Ewing]

Antoine Pitrou wrote:


It only happens if you call close() explicitly:


Well, that's only because the exception is being ignored and
you're not getting a traceback at all.

If you arrange to get a traceback, the same thing happens.

  import traceback as tb

  def g():
try:
  try:
yield 1
  finally:
raise ValueError("Hovercraft contains eels")
except Exception:
  tb.print_exc()

  gi = g()
  next(gi)
  del gi

--
Greg





def g():


...   try: yield 1
...   finally: 1/0
... 


gi = g()
next(gi)


1


del gi


Exception ZeroDivisionError: ZeroDivisionError('division by zero',) in
 ignored


gi = g()
next(gi)


1


next(gi)


Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in g
ZeroDivisionError: division by zero



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/greg.ewing%40canterbury.ac.nz


___
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] Exception chaining and generator finalisation

[Greg Ewing]

Nick Coghlan wrote:

A toy example,
that isn't obviously broken at first glance, but in fact fails when
close() is called:


Okay, you've convinced me. I'll consider it to be correct
behaviour and update my expected yield-from test results
accordingly.

--
Greg

___
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] No response to posts

[Mark Lawrence]

On 01/08/2010 02:00, Brian Curtin wrote:

On Sat, Jul 31, 2010 at 19:48, Mark Lawrencewrote:


Hi all,

I have been wading through outstanding issues today and have noticed that
there are several where there has been no response at all to the initial
post.  Failing that, the only response has been Terry Reedy back in May
2010, and that only updating the versions affected.

Would it be possible to get some code in place whereby if there is no
response to the initial post, this could be flagged up after (say) 24 hours?
  Surely any response back to the OP is better than a complete wall of
silence?

Kindest regards.

Mark Lawrence.



We could just add globally visible query which shows all issues with a
message count of 1. That query currently shows 372 issues, most of which
were entered within the last few months.


The query strikes me as KISS, let's try it and see how we go.  On this 
thread on c.l.py "500 tracker orphans; we need more reviewers" started 
by Terry Reedy it was quoted that there were 510 orphans as at Jun 19, 
3:37 am.  We're getting there.




24 hours seems too soon for any kind of notification. Who would receive this
notification?


I plucked this figure out of the air thinking that if an issue was going 
to drop under the radar, this would be the most likely time.  I was 
considering a worst case scenario where several core triage people are 
at a big Python event, others are on holiday [ shame on you :) ], some 
looking after the kids, yet more off sick etc.  Hum, perhaps 24 hours is 
too soon, what about a week, opinions anybody?  Notifications would go 
to the bugs mailing list and/or #python-dev.  But this is hypothetical 
anyway if the message count of 1 query works.  Only one way to find out, 
let's try it.


Kindest regards.

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

[Python-Dev] Yield-From Implementation Updated for Python 3

[Greg Ewing]

I have updated my prototype yield-from implementation
to work with Python 3.1.2.

I've also fixed a small bug that was affecting one of
the corner cases concerning exceptions thrown into
a subgenerator.

Interested parties can obtain it here:

http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/

--
Greg
___
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.2 alpha 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
first alpha preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
  support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For an extensive list of changes in 3.2, see Misc/NEWS in the Python
distribution.

To download Python 3.2 visit:

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

3.2 documentation can be found at:

 http://docs.python.org/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ
2N4An04q36lr47OA+bslqG/4Zj7ZwVOX
=iL8N
-END 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] No response to posts

[Nick Coghlan]

On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence  wrote:
> I plucked this figure out of the air thinking that if an issue was going to
> drop under the radar, this would be the most likely time.  I was considering
> a worst case scenario where several core triage people are at a big Python
> event, others are on holiday [ shame on you :) ], some looking after the
> kids, yet more off sick etc.  Hum, perhaps 24 hours is too soon, what about
> a week, opinions anybody?  Notifications would go to the bugs mailing list
> and/or #python-dev.  But this is hypothetical anyway if the message count of
> 1 query works.  Only one way to find out, let's try it.

Perhaps just another number to track in the weekly bug summary?

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] No response to posts

[Éric Araujo]

> Perhaps just another number to track in the weekly bug summary?

*puts bug person hat on* I made the same suggestion to Ezio, so +1

I’ve just created a public query named “Reports without replies”, you
should be able to add it to your queries list, or a tracker admin could
decide to add it to the queries that are always visible in the sidebar.

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

Re: [Python-Dev] Yield-From Implementation Updated for Python 3

[Kevin Jacobs]

On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing wrote:

> I have updated my prototype yield-from implementation
> to work with Python 3.1.2.
>
>
My work is primarily on the management and analysis of huge genomics
datasets.  I use Python generators extensively and intensively to perform
efficient computations and transformations on these datasets that avoid the
need to materialize them in main memory to the extent possible.   I've spent
a great deal of effort working around the lack of an efficient "yield from"
construct and would be very excited to see this feature added.  More so, now
that BioPython, NumPy, SciPy and other libraries that I depend on are well
on their way to supporting Python 3, the availability of this feature alone
would be incentive enough to update my code base to Python 3.

So in short:

+1

-Kevin
___
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] proto-pep: plugin proposal (for unittest)

[Ronald Oussoren]

On 31 Jul, 2010, at 13:57, Michael Foord wrote:

> On 31/07/2010 12:46, Michael Foord wrote:
>> [snip...]
>> If PEP 376 goes ahead then we could keep the user plugin 
> 
> I meant "keep the user config file".

Speaking of which... Your documentation says it's named ~/unittest.cfg, could 
you make this a file in the user base (that is, the prefix where 'setup.py 
install --user' will install files)?

Ronald

smime.p7s
Description: S/MIME cryptographic 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] proto-pep: plugin proposal (for unittest)

[Éric Araujo]

> Speaking of which... Your documentation says it's named ~/unittest.cfg,
> could you make this a file in the user base (that is, the prefix where
> 'setup.py install --user' will install files)?

Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
other in the user home directory (or %APPDATA% on win32 and
what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
is not the right directory for configuration files, as pointed in
http://bugs.python.org/issue7175

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.

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

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

[R. David Murray]

On Sun, 01 Aug 2010 17:22:55 +0200,  wrote:
> > Speaking of which... Your documentation says it's named ~/unittest.cfg,
> > could you make this a file in the user base (that is, the prefix where
> > 'setup.py install --user' will install files)?
> 
> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
> other in the user home directory (or %APPDATA% on win32 and
> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
> is not the right directory for configuration files, as pointed in
> http://bugs.python.org/issue7175
> 
> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
> $XDG_CONFIG_HOME/python directory and put config files there.

+1

Certainly ~/unittest.cfg is the wrong name for unix (it doesn't start
with a '.'), and certainly the location is OS specific. 

Anyone who cares about config file locations should read issue 7175.

--
R. David Murray  www.bitdance.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] No response to posts

[R. David Murray]

On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlan  wrote:
> On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence  wrote:
> > I plucked this figure out of the air thinking that if an issue was going to
> > drop under the radar, this would be the most likely time. I was considering
> > a worst case scenario where several core triage people are at a big Python
> > event, others are on holiday [ shame on you :) ], some looking after the
> > kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what a bout
> > a week, opinions anybody? Notifications would go to the bugs mailing list
> > and/or #python-dev. But this is hypothetical anyway if the message count of
> > 1 query works. Only one way to find out, let's try it.
> 
> Perhaps just another number to track in the weekly bug summary?

Better, a table section giving the bugids, titles, and URL.  Ezio just
finished reworking the summary script to be more easily modified, so I
bet he would find this easy to add at this point.

--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] Yield-From Implementation Updated for Python 3

[P.J. Eby]

At 08:49 AM 8/1/2010 -0400, Kevin Jacobs  wrote:
On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing 
<greg.ew...@canterbury.ac.nz> wrote:

I have updated my prototype yield-from implementation
to work with Python 3.1.2.


My work is primarily on the management and analysis of huge genomics 
datasets.  I use Python generators extensively and intensively to 
perform efficient computations and transformations on these datasets 
that avoid the need to materialize them in main memory to the extent 
possible.   I've spent a great deal of effort working around the 
lack of an efficient "yield from" construct and would be very 
excited to see this feature added.


Just so you know, you don't need to wait for this to be added to 
Python in order to have such a construct; it just won't have the 
extra syntax sugar.  See the sample code I posted here using a 
"@From.container" decorator, and a "yield From()" call:


  http://mail.python.org/pipermail/python-dev/2010-July/102320.html

This code effectively reduces your generator nesting depth to a 
constant, no matter how deeply you nest sub-generator 
invocations.  It's not as efficient as the equivalent C 
implementation, but if you're actually being affected by nesting 
overhead now, it will nonetheless provide you with some immediate 
relief, if you backport it to 2.x code.  (It's not very 3.x-ish as it 
sits, really.)


___
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] proto-pep: plugin proposal (for unittest)

[Michael Foord]

On 01/08/2010 18:38, R. David Murray wrote:

On Sun, 01 Aug 2010 17:22:55 +0200,  wrote:
   

Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install files)?
   

Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
other in the user home directory (or %APPDATA% on win32 and
what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
is not the right directory for configuration files, as pointed in
http://bugs.python.org/issue7175

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.
 

+1

Certainly ~/unittest.cfg is the wrong name for unix (it doesn't start
with a '.'), and certainly the location is OS specific.

Anyone who cares about config file locations should read issue 7175.
   


I'm happy to choose a location / name based on consensus. There doesn't 
seem to be any consensus yet. As a (mainly ex) windows user I would hate 
to have user editable data in APPDATA as it is not a location the user 
ever expects to visit. The home directory, or a subdirectory thereof, 
for user editable app specific data is more usual and more friendly.


All the best,

Michael Foord


--
R. David Murray  www.bitdance.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/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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] proto-pep: plugin proposal (for unittest)

[Ronald Oussoren]

On 1 Aug, 2010, at 17:22, Éric Araujo wrote:

>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>> could you make this a file in the user base (that is, the prefix where
>> 'setup.py install --user' will install files)?
> 
> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
> other in the user home directory (or %APPDATA% on win32 and
> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
> is not the right directory for configuration files, as pointed in
> http://bugs.python.org/issue7175
> 
> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
> $XDG_CONFIG_HOME/python directory and put config files there.

~/Library/Python would be a good location on OSX, even if the 100% formally 
correct location would be ~/Preferences/Python (at least of framework builds, 
unix-style builds may want to follow the unix convention).

Ronald



smime.p7s
Description: S/MIME cryptographic 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] No response to posts

[Ezio Melotti]

 On 01/08/2010 20.43, R. David Murray wrote:

On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlan  wrote:

On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence  wrote:

I plucked this figure out of the air thinking that if an issue was going to
drop under the radar, this would be the most likely time. I was considering
a worst case scenario where several core triage people are at a big Python
event, others are on holiday [ shame on you :) ], some looking after the
kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what a bout
a week, opinions anybody? Notifications would go to the bugs mailing list
and/or #python-dev. But this is hypothetical anyway if the message count of
1 query works. Only one way to find out, let's try it.

Perhaps just another number to track in the weekly bug summary?

Better, a table section giving the bugids, titles, and URL.  Ezio just
finished reworking the summary script to be more easily modified, so I
bet he would find this easy to add at this point.

--David

FWIW this morning I added a new version of the roundup-summary script 
[0] that includes a "Recent issues with no replies" table with bugids, 
titles and URLs. (I hope Guido doesn't mind if I used the time machine ;)


[0]: http://psf.upfronthosting.co.za/roundup/meta/issue284
___
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 376 proposed changes for basic plugins support

[Tarek Ziadé]

Hello,

Here's a proposal to extend PEP 376 to support a basic plugins feature
-- you should read PEP 376 before reading this mail

It's basically Phillip's entry points, but with an activation flag,
and a per-user config file.

= adding a PLUGINS file =

A new file called 'PLUGINS' is added to the dist-info directory at
install time, and contains a list of plugins for the installed
distribution.

The file is a CSV file like the RECORD file, containing one plugin per
line. (see the RECORD file for details on the syntax)

A plugin is defined by :

- an application name : a string containing a name of a group of
plugins. It can be the name of the application that supports plugins,
  or any string. The recommended value is the distutils name of the
project, as it appears at PyPI.
  max length: 64, chars: [a-z0-9]

- a plugin type name: a string containing a name of a type of plugins.
It can be combined with the application name to create one class of
plugins
 for a given application. 64 chars [a-z0-9] -- default value 'plugin'

- a name: a string containing a name for the plugin. Combined with the
application name and plugin type, it defines this plugin. 64 chars
[a-z0-9]

- a description: a string describing the plugin. 256 chars.

- a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated

- a code link: a link to the plugin object (whether its a module,
class, object, etc). This link is the complete import path. For
example, a plugin class called
  "Foo" located in the "bar" module, located in the "baz" package, is
noted: "baz.bar.Foo"  (the project that uses plugins is responsible
for iteratting, picking and loading plugins)

= PLUGINS example =

Here's an example of a PLUGINS file for a 'UnittestPlugins' project
that implements 2 unitest2 plugins:

  unittest2;plugin;pep8;pep8 checker;1;unittestplugins.pep8
  unittest2;plugin;debugger,Cool debugger;1;unittestplugins.debug

= per-user plugins =

A plugin can be activated or disable globally, but a user should be
able to configure them differently.

A ini-like plugins.cfg file is added per-user (its location to be
defined -- its discussed in another thread) and
overrides the state of the installed plugin. It provides a value for
each app.type.name plugin.

  [plugins]
  unittest2.plugin.pep8 = 0
  distutils2.commands.funkycommand = 0

Notice that the user can have plugins provided by distributions
installed in his own per-user site packages.

= Implementation =

I don't want to go into great details here yet, until we get a
consensus on the PLUGINS file.

But basically we will add these features in pkgutil:

- browse plugins and get their info.
- activate/disable a plugin, by writing its state
- load a plugin and return it by importing the 'code link'

and in distutils2:

- let the user configure if plugins are automatically activated when
the project is installed
- provide a end-user script to browse plugins
- provide a way to define plugins statically in setup.cfg


Regards
Tarek

-- 
Tarek Ziadé | http://ziade.org
___
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 376 proposed changes for basic plugins support

[Nick Coghlan]

On Mon, Aug 2, 2010 at 6:37 AM, Tarek Ziadé  wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> = adding a PLUGINS file =
>
> A new file called 'PLUGINS' is added to the dist-info directory at
> install time, and contains a list of plugins for the installed
> distribution.
>
> The file is a CSV file like the RECORD file, containing one plugin per
> line. (see the RECORD file for details on the syntax)
>
> A plugin is defined by :
>
> - an application name : a string containing a name of a group of
> plugins. It can be the name of the application that supports plugins,
>  or any string. The recommended value is the distutils name of the
> project, as it appears at PyPI.
>  max length: 64, chars: [a-z0-9]
>
> - a plugin type name: a string containing a name of a type of plugins.
> It can be combined with the application name to create one class of
> plugins
>  for a given application. 64 chars [a-z0-9] -- default value 'plugin'
>
> - a name: a string containing a name for the plugin. Combined with the
> application name and plugin type, it defines this plugin. 64 chars
> [a-z0-9]
>
> - a description: a string describing the plugin. 256 chars.
>
> - a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated
>
> - a code link: a link to the plugin object (whether its a module,
> class, object, etc). This link is the complete import path. For
> example, a plugin class called
>  "Foo" located in the "bar" module, located in the "baz" package, is
> noted: "baz.bar.Foo"  (the project that uses plugins is responsible
> for iteratting, picking and loading plugins)

Is dealing with name conflicts left up to the application?

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] Metadata: charset (was: PEP 376 proposed changes for basic plugins support)

[Oleg Broytman]

On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote:
> The file is a CSV file

   In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314
and 376, but didn't encountered any mention of the words "encoding" or
"charset". Documentation for the "csv" module also doesn't provide any
clear indication of encoding/charset.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
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 376 proposed changes for basic plugins support

[Tarek Ziadé]

On Sun, Aug 1, 2010 at 11:55 PM, Nick Coghlan  wrote:
...
> Is dealing with name conflicts left up to the application?

When an application iterates on the plugins that are supposely built
for it, it will probably expect a single type of object. For instance
unitest2 will want classes that are overriding its Plugin base class.
So it should be able to drop objects that are not compliant with its
system.

Now, since the distutils id at PyPI is unique, using it for the
application name in the plugin like I proposed,
should also help preventing this issue.
___
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] Metadata: charset (was: PEP 376 proposed changes for basic plugins support)

[Tarek Ziadé]

On Sun, Aug 1, 2010 at 11:58 PM, Oleg Broytman  wrote:
> On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote:
>> The file is a CSV file
>
>   In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314
> and 376, but didn't encountered any mention of the words "encoding" or
> "charset". Documentation for the "csv" module also doesn't provide any
> clear indication of encoding/charset.

utf-8. I'll add this info in PEP 376 -- Thanks

>
> Oleg.
> --
>     Oleg Broytman            http://phd.pp.ru/            ...@phd.pp.ru
>           Programmers don't die, they just GOSUB without RETURN.
> ___
> 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/ziade.tarek%40gmail.com
>



-- 
Tarek Ziadé | http://ziade.org
___
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] Metadata: charset

[Oleg Broytman]

On Mon, Aug 02, 2010 at 12:11:06AM +0200, Tarek Ziad? wrote:
> On Sun, Aug 1, 2010 at 11:58 PM, Oleg Broytman  wrote:
> > On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote:
> >> The file is a CSV file
> >
> >   In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314
> > and 376, but didn't encountered any mention of the words "encoding" or
> > "charset". Documentation for the "csv" module also doesn't provide any
> > clear indication of encoding/charset.
> 
> utf-8. I'll add this info in PEP 376 -- Thanks

   Thank you for the clarification!

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
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 376 proposed changes for basic plugins support

[Michael Foord]

On 01/08/2010 21:37, Tarek Ziadé wrote:

Hello,

Here's a proposal to extend PEP 376 to support a basic plugins feature
-- you should read PEP 376 before reading this mail

It's basically Phillip's entry points, but with an activation flag,
and a per-user config file.

= adding a PLUGINS file =

A new file called 'PLUGINS' is added to the dist-info directory at
install time, and contains a list of plugins for the installed
distribution.

The file is a CSV file like the RECORD file, containing one plugin per
line. (see the RECORD file for details on the syntax)

A plugin is defined by :

- an application name : a string containing a name of a group of
plugins. It can be the name of the application that supports plugins,
   or any string. The recommended value is the distutils name of the
project, as it appears at PyPI.
   max length: 64, chars: [a-z0-9]

- a plugin type name: a string containing a name of a type of plugins.
It can be combined with the application name to create one class of
plugins
  for a given application. 64 chars [a-z0-9] -- default value 'plugin'

- a name: a string containing a name for the plugin. Combined with the
application name and plugin type, it defines this plugin. 64 chars
[a-z0-9]

- a description: a string describing the plugin. 256 chars.

- a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated

- a code link: a link to the plugin object (whether its a module,
class, object, etc). This link is the complete import path. For
example, a plugin class called
   "Foo" located in the "bar" module, located in the "baz" package, is
noted: "baz.bar.Foo"  (the project that uses plugins is responsible
for iteratting, picking and loading plugins)

= PLUGINS example =

Here's an example of a PLUGINS file for a 'UnittestPlugins' project
that implements 2 unitest2 plugins:

   unittest2;plugin;pep8;pep8 checker;1;unittestplugins.pep8
   unittest2;plugin;debugger,Cool debugger;1;unittestplugins.debug

   


This seems fine; I mean it isn't written directly by humans or intended 
to be read directly by humans I guess. :-)


(Users will specify plugins in the setup metadata and this will be 
written on install by distutils2 - right?.)



= per-user plugins =

A plugin can be activated or disable globally, but a user should be
able to configure them differently.

A ini-like plugins.cfg file is added per-user (its location to be
defined -- its discussed in another thread) and
overrides the state of the installed plugin. It provides a value for
each app.type.name plugin.

   [plugins]
   unittest2.plugin.pep8 = 0
   distutils2.commands.funkycommand = 0

Notice that the user can have plugins provided by distributions
installed in his own per-user site packages.

   


I don't think that unittest would use a distutils2 (or pkgutil) supplied 
API for activation. unittest needs *separate* per user and per project 
activation (a plugin active for a project may not be needed in other 
projects and so won't be enabled at the user level for example). 
unittest also needs plugin *configuration* and it makes sense to keep 
configuration and activation in the same place.


The interesting part of this proposal for unittest is the plugin discovery.

unittest will use the two config file solution (location of user config 
still to be determined) and probably a "plugins" subcommand (eventually) 
to manage the config file from the command line.


On the other hand the activation is likely to be wanted by other 
projects that use plugins and it certainly doesn't hurt unittest.



= Implementation =

I don't want to go into great details here yet, until we get a
consensus on the PLUGINS file.

But basically we will add these features in pkgutil:

- browse plugins and get their info.
   

Yes, great.


- activate/disable a plugin, by writing its state
- load a plugin and return it by importing the 'code link'

   

Also great.


and in distutils2:

- let the user configure if plugins are automatically activated when
the project is installed
- provide a end-user script to browse plugins
- provide a way to define plugins statically in setup.cfg

   

All sounds good to me.

Michael


Regards
Tarek

   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org

Re: [Python-Dev] No response to posts

[Terry Reedy]

On 8/1/2010 7:44 AM, Éric Araujo wrote:

+1 On a prebuilt search

This is not as easy as it seems.
A nosy count of 1 misses posts where someone added themself as nosy 
without saying anything, waiting for someone else to answer (and maybe 
no one ever did). A message count of 1 misses posts where a person 
follows up with a correction (because he cannot edit!) or addition.
nosy = 1 or message = 1 would be better, and one cannot do that from 
search form, which, ANDS things together. Can a custom sql query do an OR?



Perhaps just another number to track in the weekly bug summary?


*puts bug person hat on* I made the same suggestion to Ezio, so +1


If Friday report marked issues without responses, I would make a special 
effort to look at those.


--
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] Is it intentional that "sys.__debug__ = 1" isillegal in Python 2.7?

[Terry Reedy]

On 7/31/2010 5:02 PM, Guido van Rossum wrote:


But yes, the docs should clarify that *any* use of __*__ names, in
*any* context, that does not follow explicitly documented use, is
subject to breakage without warning.


http://bugs.python.org/issue9451
Strengthen __*__ system name warning

My suggested new version, incorporating Guido's sentence:

System-defined names. These names are defined by the interpreter and its 
implementation (including the standard library). Current system names 
are discussed in the Special method names section and elsewhere. More 
will likely be defined in future versions of Python. *Any* use of __*__ 
names, in any* context, that does not follow explicitly documented use, 
is subject to breakage without warning.


--
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] No response to posts

[Ron Adam]

On 08/01/2010 06:14 PM, Terry Reedy wrote:

On 8/1/2010 7:44 AM, Éric Araujo wrote:

+1 On a prebuilt search

This is not as easy as it seems.
A nosy count of 1 misses posts where someone added themself as nosy
without saying anything, waiting for someone else to answer (and maybe
no one ever did). A message count of 1 misses posts where a person
follows up with a correction (because he cannot edit!) or addition.
nosy = 1 or message = 1 would be better, and one cannot do that from
search form, which, ANDS things together. Can a custom sql query do an OR?


There is an activity field which gets any issues with activity on a 
specific day.  I'm not sure how useful that is. 


Something that may be more useful, is a "no activity" search field with 
choices of day, week, month, year, etc... and make the output sortable on 
time without activity.


That not only would cover the short term cases of no response, but also the 
longer term items that slip though the cracks.


Ron


___
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 376 proposed changes for basic plugins support

[Tarek Ziadé]

On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord  wrote:
> This seems fine; I mean it isn't written directly by humans or intended to
> be read directly by humans I guess. :-)
>
> (Users will specify plugins in the setup metadata and this will be written
> on install by distutils2 - right?.)

Yes, exactly

>
>> = per-user plugins =
>>
>> A plugin can be activated or disable globally, but a user should be
>> able to configure them differently.
>>
>> A ini-like plugins.cfg file is added per-user (its location to be
>> defined -- its discussed in another thread) and
>> overrides the state of the installed plugin. It provides a value for
>> each app.type.name plugin.
>>
>>   [plugins]
>>   unittest2.plugin.pep8 = 0
>>   distutils2.commands.funkycommand = 0
>>
>> Notice that the user can have plugins provided by distributions
>> installed in his own per-user site packages.
>>
>>
>
> I don't think that unittest would use a distutils2 (or pkgutil) supplied API
> for activation.

But the discovery API you will use might just simply filter out
disabled plugins.

In any case, if unittest2 tries to bypass this activation flag I don't
see the point of having it there
since its purpose is to let the end-user deactivate a plugin that
might be used by several applications.


> unittest needs *separate* per user and per project
> activation (a plugin active for a project may not be needed in other
> projects and so won't be enabled at the user level for example).

And sharing plugins across apps is a use case too: Nose could use
unittest2 plugins and vice-versa.

Tarek
___
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 376 proposed changes for basic plugins support

[Michael Foord]

On 02/08/2010 00:46, Tarek Ziadé wrote:

[snip...]

I don't think that unittest would use a distutils2 (or pkgutil) supplied API
for activation.
 

But the discovery API you will use might just simply filter out
disabled plugins.
   


I did consider asking this but thought it was a silly question - there 
*must* be an API to get all plugins otherwise applications couldn't 
activate or deactivate them (or allow their users to do this) - and then 
how could users activate a non-active plugin? (I guess there could be 
private APIs that only distutils2 is supposed to use, or the script that 
you mentioned.)


On the other hand if the user has deactivated a plugin through 
distutils2 I have no problem with it not being available to unittest.



In any case, if unittest2 tries to bypass this activation flag I don't
see the point of having it there
since its purpose is to let the end-user deactivate a plugin that
might be used by several applications.

   


Right. As I explained, I don't think unittest *can* use this mechanism 
since it can have plugins active for one project but not for another. I 
would really have no problem with this machinery existing, but it 
wouldn't be useful/usable by unittest for plugins.


It sounds like it can fairly easily be bolted on as a new feature set 
later *anyway*, so dropping it for now simplifies the initial 
implementation.


Wouldn't that mean that distutils2 would still need its *own* system for 
telling whether or not installed plugins are active? So maybe you have 
to build it anyway.



unittest needs *separate* per user and per project
activation (a plugin active for a project may not be needed in other
projects and so won't be enabled at the user level for example).
 

And sharing plugins across apps is a use case too: Nose could use
unittest2 plugins and vice-versa.
   


Hehe, well - that's a different story...

Michael


Tarek
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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 376 proposed changes for basic plugins support

[Tarek Ziadé]

On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord  wrote:
> On 02/08/2010 00:46, Tarek Ziadé wrote:
>>
>> [snip...]
>>>
>>> I don't think that unittest would use a distutils2 (or pkgutil) supplied
>>> API
>>> for activation.
>>>
>>
>> But the discovery API you will use might just simply filter out
>> disabled plugins.
>>
>
> I did consider asking this but thought it was a silly question - there
> *must* be an API to get all plugins otherwise applications couldn't activate
> or deactivate them (or allow their users to do this) - and then how could
> users activate a non-active plugin? (I guess there could be private APIs
> that only distutils2 is supposed to use, or the script that you mentioned.)

yes, there will be a way to retrieve them all

...
> It sounds like it can fairly easily be bolted on as a new feature set later
> *anyway*, so dropping it for now simplifies the initial implementation.

but then we would be back to the problem mentioned about entry points:
installing projects can implicitly add a plugin and activate it, and break
existing applications that iterate over entry points without further
configuration. So being able to disable plugins from the beginning seems
important to me
___
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] pdb mini-sprint report and questions

[Ilya Sandler]

Hello,

I'm the submitter of the original patch and would like to help with it if I can.

> One issue that's not yet closed is #7245, which adds a (very nice IMO)
> feature: when you press Ctrl-C while the program being debugged runs,
> you will not get a traceback but execution is suspended, and you can
> debug from the current point of execution -- just like in gdb.
>
> However, there were apparently issues with some of the buildbots when
> the patch was applied for a short time.  I also don't know how and if
> it works on Windows, so I'd need some helpful people testing it.

For whatever it's worth, it worked for me with python trunk (2.x) on
Vista, when I tried it manually.  But I don't know how to implement
the unit test there (subprocess module doesn't support sending SIGINT
programmatically on windows either). So the test_pdb2 test does not
check signal behavior on Windows platforms.

Buildbot failures are still a total mystery for me ;-):  the failures
were happening elsewhere and seemed to be unrelated to test_pdb2. Is
there any other way to apply the patch and run the tests on failing
platforms?

Ilya

>
> Another question is about a feature of pdb++ that I personally would
> like, but imagine would make others unhappy:  one-letter abbreviations
> of commands such as c(ontinue) or l(ist) are also often-used variable
> names, so they are frequently typed without the required "!" or "print"
> that would distinguish them from the command, and the command is
> actually executed.  The feature in question would default to printing
> the variable in cases where one exists -- handy enough or too
> inconsistent?
>
> Also, are there any other features you would like to see?  One feature
> of pdb++ that is general enough and has no dependencies would be watch
> expressions...
>
> 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/ilya.sandler%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 376 proposed changes for basic plugins support

[Michael Foord]

On 02/08/2010 01:03, Tarek Ziadé wrote:

On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord  wrote:
   

On 02/08/2010 00:46, Tarek Ziadé wrote:
 

[snip...]
   

I don't think that unittest would use a distutils2 (or pkgutil) supplied
API
for activation.

 

But the discovery API you will use might just simply filter out
disabled plugins.

   

I did consider asking this but thought it was a silly question - there
*must* be an API to get all plugins otherwise applications couldn't activate
or deactivate them (or allow their users to do this) - and then how could
users activate a non-active plugin? (I guess there could be private APIs
that only distutils2 is supposed to use, or the script that you mentioned.)
 

yes, there will be a way to retrieve them all

...
   

It sounds like it can fairly easily be bolted on as a new feature set later
*anyway*, so dropping it for now simplifies the initial implementation.
 

but then we would be back to the problem mentioned about entry points:
installing projects can implicitly add a plugin and activate it, and break
existing applications that iterate over entry points without further
configuration. So being able to disable plugins from the beginning seems
important to me
   


I agree it sounds like an important feature - a point of control for the 
user or the system as you said on irc. I still don't think unittest 
*can* use it, but I'm quite happy with the fact that if a user 
deactivates a plugin through distutils2 then it is no longer *available* 
to unittest.


Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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 376 proposed changes for basic plugins support

[P.J. Eby]

At 02:03 AM 8/2/2010 +0200, Tarek Ziadé wrote:

but then we would be back to the problem mentioned about entry points:
installing projects can implicitly add a plugin and activate it, and break
existing applications that iterate over entry points without further
configuration. So being able to disable plugins from the beginning seems
important to me


So which are these apps that don't allow configuration, and which are 
the plugins that break them?  Have the issues been reported so that 
the authors can fix them?


ISTM that the issue can only arise in cases where you are installing 
plugins to a *global* environment, rather than to an environment 
specific to the application.


In the case of setuptools, for example, it's expected that a project 
will use 'setup_requires' to identify the plugins it wishes to use, 
apart from any that were intentionally installed globally.  (The 
requested plugins are then added to sys.path only for the duration of 
the setup script execution.)


Other applications have plugin directories where their plugins are to 
be installed, and still others have explicit configuration to enable 
named plugins.


Even in the worst-case scenario, where an app has no plugin 
configuration and no private plugin directory, you can still control 
plugin availability by installing plugins to the directory where the 
application's main script is located, or point PYTHONPATH to point to 
a directory you've chosen to hold the plugins of your choice.


So without specific examples of why this is a problem, it's hard to 
see why a special Python-specific set of configuration files is 
needed to resolve it, vs. say, encouraging application authors to use 
the available alternatives for doing plugin directories, config files, etc.


___
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] No response to posts

[Benjamin Peterson]

2010/7/31 Éric Araujo :
> Good call.
>
> Alternative idea: Have a new status “unread” to make searching easier
> for bug people. Or a predefined custom search for nosy_count == 1.

Please, let's stop messing with the tracker for everything. I think
the current set up works reasonably well, and we should focus on the
real problem: manpower



-- 
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] Is it intentional that "sys.__debug__ = 1" is illegal in Python 2.7?

[Benjamin Peterson]

2010/7/30 Barry Warsaw :
>
> It looks like Benjamin's change in r67171 was the relevant diff.

The reason behind this was to make __debug__ assignment consistent
with that of other reserved names. For example, x.None = 3 raised and
thus, so should x.__debug__ = 3.



-- 
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] [RELEASED] Python 3.2 alpha 1

[Benjamin Peterson]

Hey, Georg! Congrats on your first release!

2010/8/1 Georg Brandl :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On behalf of the Python development team, I'm happy to announce the
> first alpha preview release of Python 3.2.
>
> Python 3.2 is a continuation of the efforts to improve and stabilize the
> Python 3.x line.  Since the final release of Python 2.7, the 2.x line
> will only receive bugfixes, and new features are developed for 3.x only.
>
> Since PEP 3003, the Moratorium on Language Changes, is in effect, there
> are no changes in Python's syntax and built-in types in Python 3.2.
> Development efforts concentrated on the standard library and support for
> porting code to Python 3.  Highlights are:
>
> * numerous improvements to the unittest module
> * PEP 3147, support for .pyc repository directories
> * an overhauled GIL implementation that reduces contention
> * many consistency and behavior fixes for numeric operations
> * countless fixes regarding string/unicode issues; among them full
>  support for a bytes environment (filenames, environment variables)
> * a sysconfig module to access configuration information
> * a pure-Python implementation of the datetime module
> * additions to the shutil module, among them archive file support
> * improvements to pdb, the Python debugger
>
> For an extensive list of changes in 3.2, see Misc/NEWS in the Python
> distribution.
>
> To download Python 3.2 visit:
>
>     http://www.python.org/download/releases/3.2/
>
> 3.2 documentation can be found at:
>
>     http://docs.python.org/3.2/
>
> Please consider trying Python 3.2 with your code and reporting any bugs
> you may notice to:
>
>     http://bugs.python.org/
>
>
> Enjoy!
>
> - --
> Georg Brandl, Release Manager
> georg at python.org
> (on behalf of the entire python-dev team and 3.2's contributors)
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.16 (GNU/Linux)
>
> iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ
> 2N4An04q36lr47OA+bslqG/4Zj7ZwVOX
> =iL8N
> -END 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/benjamin%40python.org
>



-- 
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] Yield-From Implementation Updated for Python 3

[Guido van Rossum]

On Sun, Aug 1, 2010 at 11:16 AM, P.J. Eby  wrote:
> Just so you know, you don't need to wait for this to be added to Python in
> order to have such a construct; it just won't have the extra syntax sugar.
>  See the sample code I posted here using a "@From.container" decorator, and
> a "yield From()" call:
>
>  http://mail.python.org/pipermail/python-dev/2010-July/102320.html
>
> This code effectively reduces your generator nesting depth to a constant, no
> matter how deeply you nest sub-generator invocations.  It's not as efficient
> as the equivalent C implementation, but if you're actually being affected by
> nesting overhead now, it will nonetheless provide you with some immediate
> relief, if you backport it to 2.x code.  (It's not very 3.x-ish as it sits,
> really.)

Hi Phillip,

Your code is fiendishly clever (and I mean that as a compliment). Even
though only a few weeks ago I wrote a trampoline along these lines
(more similar to the one in PEP 342, example 3, but extended to
support async I/O), I don't understand all the details and corner
cases (e.g. the concatenation of stacks, which seems to have to do
with the special-casing of From objects in __new__) but I trust that
it works.

I am curious whether, if you need a trampoline for async I/O anyway,
there would be a swaying argument for integrating this functionality
into the general trampoline (as in the PEP 342 example), or whether it
would be better to separate the async I/O trampoline from the "From"
trampoline. The latter would in a sense be more future-proof because
once PEP 380 becomes a reality the From class can be dropped in favor
of yield-from syntax (and raise StopIteration(x) in favor of return
x). But it seems a bit of a waste to have two different trampolines,
especially since the trampoline itself is so hard to understand
(speaking for myself here :-). ISTM that the single combined
trampoline is easier to understand than the From class.

I am CC'ing Raymond so he can loop the author of Monocle (his
colleague) into this discussion -- I'd like to hear their opinion
(Monocle seems to require a decorator but it looks like it uses the
PEP 342 approach to simulate yield-from while avoiding stack buildup).

PS For Raymond and his colleague: I also still hope that Monocle will
change its mind about the proper convention for returning a value from
a coroutine -- I really think it should be raise StopIteration(value)
rather than yield value, since the latter (a) doesn't signal
sufficiently strongly (to the human reader) that the generator will
not be resumed ever again, and (b) could easily be confused with the
other uses of yield. (IOW I think yield is being overloaded too much
in Monocle.)

-- 
--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] proto-pep: plugin proposal (for unittest)

[Glyph Lefkowitz]

On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:

> 
> On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
> 
>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>> could you make this a file in the user base (that is, the prefix where
>>> 'setup.py install --user' will install files)?
>> 
>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>> other in the user home directory (or %APPDATA% on win32 and
>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>> is not the right directory for configuration files, as pointed in
>> http://bugs.python.org/issue7175
>> 
>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>> $XDG_CONFIG_HOME/python directory and put config files there.
> 
> ~/Library/Python would be a good location on OSX, even if the 100% formally 
> correct location would be ~/Preferences/Python (at least of framework builds, 
> unix-style builds may want to follow the unix convention).

"100% formally" speaking, MacOS behaves like UNIX in many ways.  


It's fine to have a mac-pathname-convention-following place for such data, but 
please _also_ respect the UNIX-y version on the Mac.  The only possible outcome 
of python on the Mac respect only Mac pathnames is to have automation scripts 
that work fine on BSD and Linux, but then break when you try to run them on a 
Mac.  There is really no benefit to intentionally avoiding honoring the UNIX 
conventions.  (For another example, note that although Python resides in 
/System/Library, on the mac, the thing that's in your $PATH when you're using a 
terminal is the symlink in /usr/bin/python.)

Also, no, "~/Preferences" isn't the right place for it either; there's no such 
thing.  You probably meant "~/Library/Preferences".  I'd say that since 
~/Library/Python is already used, there's no particular reason to add a new 
~/Library/Preferences/Python location.  After all, if you really care a lot 
about platform conventions, you should put it in 
~/Library/Preferences/org.python.distutils.plist, but I don't see what benefit 
that extra complexity would have for anyone.

___
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] Yield-From Implementation Updated for Python 3

[P.J. Eby]

At 09:24 PM 8/1/2010 -0700, Guido van Rossum wrote:

I don't understand all the details and corner
cases (e.g. the concatenation of stacks


It's just to ensure that you never have From's iterating over other 
From's, vs. just iterating whatever's at the top of the stack.




which seems to have to do with the special-casing of From objects in __new__)


It isn't connected, actually except that it's another place where I'm 
keeping From's flat, instead of nested.  (I hear that flat is better.  ;-) )




I am curious whether, if you need a trampoline for async I/O anyway,
there would be a swaying argument for integrating this functionality
into the general trampoline (as in the PEP 342 example),


Originally, that was why I wasn't very enthusiastic about PEP 380; it 
didn't seem to me to be adding any new value over what you could do 
with existing, widely-used libraries.  (Twisted's had its own *and* 
multiple third-party From-ish libraries supporting it for many years now.)


After I wrote From(), however (which was originally intended to show 
why I thought 380 was unnecessary), I realized that having One 
Obvious Way to implement generator-based pseudothreads independent of 
an event loop, is actually useful precisely *because* it separates 
the pseudothreadedness from what you're using the pseudothreadedness for.


Essentially, the PEP 380-ish bit is the hardest part of writing an 
actual pseudothread implementation; connecting that implementation to 
an I/O framework is actually the relatively simple part.  You just 
write code that steps into the generator, and uses the yielded object 
to initiate an I/O operation and register a callback.  (If you're 
using Twisted or something else that has "promise"-like deferred 
results, it's *really* easy, because you only have a couple of types 
of yielded objects to deal with, and a uniform callback signature.)


Indeed, if you're using an existing async I/O framework, you don't 
even really *have* a "trampoline" as such -- you just have a bit of 
code that registers callbacks to itself, and the app's main event 
loop just calls back to that wrapper when the I/O is done.


In effect, an I/O framework integration would just give you a single 
API like, "run(From(geniter))", which then performs one iteration, 
and then registers whatever callback it's told to by the yield, and 
the callback it registers would actually be a reinvocation of run() 
on the same From instance when the I/O is ready, but with a value to 
pass back into the send(), or an error to throw().  So, the I/O 
framework's event loop is half of the "trampoline", and the wrapper 
that sends or throws, then registers an I/O callback, is the other half.


Something like:

def run(coroutine, value=None, exc_info=()):
if exc_info:
action = coroutine.throw(*exc_info)
else:
action = coroutine.send(value)
action.registerCallback(partial(run, coroutine))

Where 'action' is some I/O command object, and registerCallback() 
will call its argument back with a value or exc_info, after the I/O is done.


Of course, a real framework integration might actually dispatch on 
type here rather than using special command objects like this, and 
there might be more glue code to deal with exceptions, but really, 
the heart of the thing is just going to look like that.  (I just 
wrote it that way to show the basic structure.)


Really, it's just a few functions, maybe a utility routine or two, 
and maybe a big if-then or dictionary dispatch on types if you just 
want to be able to 'yield' existing I/O objects provided by the frameworks.


IOW, it's a *lot* simpler than actually rolling your own I/O or GUI 
framework like Twisted or Eventlet or wxPython or tk or some other such thing.




But it seems a bit of a waste to have two different trampolines,
especially since the trampoline itself is so hard to understand
(speaking for myself here :-). ISTM that the single combined
trampoline is easier to understand than the From class.


Well, the PEP 342 example was made to look simple, because it doesn't 
have to actually DO anything (like I/O!)  To work for real, it'd need 
some pluggability, and some things to help it interoperate with 
different GUI and I/O frameworks and event loops.  (Using your own 
event loop "for real" isn't very useful in a lot of non-trivial applications.)


Heck, after writing From(), it gave me an idea that I could just 
write a trampoline that *could* integrate with other event loops, 
with an idea to have it be a general-purpose companion to From.


But, after several wasted hours, I realized that yes, it *could* be 
written (I still have the draft), but it was mostly just something 
that would save a little boilerplate in bolting From()'s onto an 
existing async I/O framework, and not really anything to write home about.


So, I guess what I'm saying is, the benefit of separating the 
trampoline from control flow, is that people can then use

Re: [Python-Dev] [RELEASED] Python 3.2 alpha 1

[Georg Brandl]

Thanks, Benjamin!  I'd also like to thank Martin and Ronald for the prompt
binaries, and the folks of #python-dev for support.  RMing was a pleasant
experience so far.

Georg


Am 02.08.2010 05:01, schrieb Benjamin Peterson:
> Hey, Georg! Congrats on your first release!
> 
> 2010/8/1 Georg Brandl :
> On behalf of the Python development team, I'm happy to announce the
> first alpha preview release of Python 3.2.

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

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

[Ronald Oussoren]

On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:

> 
> On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
> 
>> 
>> On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
>> 
 Speaking of which... Your documentation says it's named ~/unittest.cfg,
 could you make this a file in the user base (that is, the prefix where
 'setup.py install --user' will install files)?
>>> 
>>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>>> other in the user home directory (or %APPDATA% on win32 and
>>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>>> is not the right directory for configuration files, as pointed in
>>> http://bugs.python.org/issue7175
>>> 
>>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>>> $XDG_CONFIG_HOME/python directory and put config files there.
>> 
>> ~/Library/Python would be a good location on OSX, even if the 100% formally 
>> correct location would be ~/Preferences/Python (at least of framework 
>> builds, unix-style builds may want to follow the unix convention).
> 
> "100% formally" speaking, MacOS behaves like UNIX in many ways.  
> 

Storing files in unix location will be confusing to many Mac users, Apple has 
an explicitly documented convention for where to store files and dot-files in 
the user's home directory aren't part of that convention.

An important reason for storing files in ~/Library/Python of 
~/Library/Preferences/Python is that these locations are both logical for mac 
users and can be navigated to from the Finder without resorting to typing the 
folder name in "Go -> Go to Folder".

> 
> It's fine to have a mac-pathname-convention-following place for such data, 
> but please _also_ respect the UNIX-y version on the Mac.  The only possible 
> outcome of python on the Mac respect only Mac pathnames is to have automation 
> scripts that work fine on BSD and Linux, but then break when you try to run 
> them on a Mac.  

The stdlib should have APIs for locating common directories, although I must 
admit that I haven't checked if it actually does have them.  That way you can 
write automation scripts that work anyware, not just on systems that look a lot 
like Linux.   

I've written a lot of scripts that had to follow platform conventions on a lot 
of unix platforms, and those tended to require small changes for every new unix 
flavor we encountered. Non-linux platforms also have filesystem hierarchy 
standards, even though they are often not as detailed as the Linux ones and 
most unix platforms don't have a user-base that is as vocal as the linux 
packagers when software doesn't follow the conventions.

> There is really no benefit to intentionally avoiding honoring the UNIX 
> conventions.  (For another example, note that although Python resides in 
> /System/Library, on the mac, the thing that's in your $PATH when you're using 
> a terminal is the symlink in /usr/bin/python.)
> 
> Also, no, "~/Preferences" isn't the right place for it either; there's no 
> such thing.  You probably meant "~/Library/Preferences".  I'd say that since 
> ~/Library/Python is already used, there's no particular reason to add a new 
> ~/Library/Preferences/Python location.  After all, if you really care a lot 
> about platform conventions, you should put it in 
> ~/Library/Preferences/org.python.distutils.plist, but I don't see what 
> benefit that extra complexity would have for anyone.

Your right, I meant ~/Library/Preferences, and I'd prefer ~/Library/Python for 
the reason you meant.   The actual format of the configuration files is not 
prescribed in any way, and I'd by -1 on storing the preferences in a plist on 
OSX because that is making live for programmers actively harder.


Ronald
> 



smime.p7s
Description: S/MIME cryptographic 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] proto-pep: plugin proposal (for unittest)

[Greg Ewing]

Glyph Lefkowitz wrote:


I'd say that since ~/Library/Python is already used, there's no
particular reason to add a new ~/Library/Preferences/Python location.


I think the reason for separating out Preferences is so
that you can install a new version of a library or application
without losing the user's preferences from the previous
version.

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