Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

2012-12-09 Thread Andrew McNabb
On Fri, Dec 07, 2012 at 05:02:26PM -0500, PJ Eby wrote:
 If the packages have files in conflict, they won't be both installed.
 If they don't have files in conflict, there's nothing important to be
 informed of.  If one is installing pexpect-u, then one does not need
 to discover that it is a successor of pexpect.

In the specific case of pexpect and pexpect-u, the files don't actually
conflict.  The pexpect package includes a pexpect.py file, while
pexpect-u includes a pexpect/ directory.  These conflict, but not in
the easily detectable sense.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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

2012-02-22 Thread Andrew McNabb
On Wed, Feb 22, 2012 at 04:24:38AM +0200, Eli Bendersky wrote:
 
 Andrew, could you elaborate on your use case? Are you using cElementTree to
 do the parsing, or ElementTree (the Python implementation). Can you show a
 short code sample?

I'm mostly using ElementTree because several classes/functions that I
need are not in cElementTree or behave differently.  Specifically, the
program loads TreeBuilder, XMLParser, iterparse from ElementTree; the
only class from cElementTree that works is Element.  A shortened version
of the program is available here:

http://aml.cs.byu.edu/~amcnabb/gutenberg-short.py

By the way, this code is just one example of how one might rely on the
documented extensibility of ElementTree.  There are probably many other
examples out there that look nothing like mine.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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

2012-02-21 Thread Andrew McNabb
On Tue, Feb 21, 2012 at 10:47:43PM +0100, Martin v. Löwis wrote:
  I can't fathom why someone would do it though, since bar tiny
  differences (like this one) cET is just a faster ET and it's available
  practically everywhere with CPython. I mean, is it really important to
  be able to subclass ET.Element? What goal does it serve?
 
 Statements like this make me *extremely* worried. Please try to adopt
 a position of much higher caution, accepting that a change is
 incompatible if there is a remote possibility that someone might
 actually rely on the original behavior. Otherwise, I predict that you
 will get flooded with complaints that you broke ET for no good reason.

I'm happy to stand up as an example of someone who uses a custom Element
class.  My specific use case is loading the project Gutenberg database,
which is a 210MB XML file.  I created a custom Element class which I use
for the top-level element (a custom element_factory passed to
TreeBuilder distinguishes between the top-level element and all others).
The custom Element class doesn't add children, so it keeps ElementTree
from storing all of the elements its seen so far.  On a system with 1 GB
of RAM, there was no other way to get the file to load.

So, I would be one of those people who would flood in the complaints. :)

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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 3146: Merge Unladen Swallow into CPython

2010-01-20 Thread Andrew McNabb
On Wed, Jan 20, 2010 at 10:13:56PM -0500, Reid Kleckner wrote:
 2) As a command line option, you can pass -j never.  If you have a
 short-lived script, you can just stick this in your #! line and forget
 about it.  This has more overhead, since all of the JIT machinery is
 loaded into memory but never used.  Right now we record feedback that
 will never be used, but we could easily make that conditional on the
 jit control flag.

Shebang lines are much less useful than they appear because they only
split on the first space.  Consider the following script:

#!/usr/bin/env python -tt
print hello, world

Running it gives the error because env is given the single argument
(python -tt) instead of two arguments (python and -tt):

/usr/bin/env: python -tt: No such file or directory


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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] 2.7 Release? 2.7 == last of the 2.x line?

2009-11-03 Thread Andrew McNabb
On Tue, Nov 03, 2009 at 12:28:47PM -0500, Arc Riley wrote:
 
 The main thing holding back the community are lazy and/or obstinate package
 maintainers.  If they spent half the time they've put into complaining about
 Py3 into actually working to upgrade their code they'd be done now.

The main reason the package maintainers are so lazy and/or obstinate
is that Python 2 is much more available than Python 3.  For example,
work is being completed on a python3 RPM, but it will first appear in
Fedora 13, not Fedora 12.  RHEL is still using Python 2.4 and won't even
get Python 2.6 until RHEL 6 comes out.  I don't think it's worth
worrying about packages being upgraded to Python 3 when many or most
users still don't have access to Python 3.

In my opinion, the best place for current efforts is on infrastructure:

1) Python 3 packages for all Linux distributions (I've recently been
involved with bringing Python 3 to Fedora)

2) WSGI/mod_python, etc.: according to
http://wsgi.org/wsgi/Amendments_1.0 and various blog posts, the WSGI
standard isn't defined for Python 3 yet, and the modwsgi page at
http://code.google.com/p/modwsgi/ does not yet list a Python 3 release.

3) Numpy/scipy: as others have mentioned, numpy is essential for
scientific work, and apparently the project needs help to add support
for Python 3

Before basic infrastructure is available for Python 3, it's absurd to
expect package maintainers to flock to it.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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 389: argparse - new command line parsing module

2009-09-30 Thread Andrew McNabb
On Wed, Sep 30, 2009 at 02:22:53PM -0400, Barry Warsaw wrote:

 Right.  I've made it kind of work in Mailman 3, but it would be nice for 
 argparse to support this out of the box.  Note that I think you want two 
 forms:

 foo help subcommand
 foo subcommand --help

 to basically print the same help text.  This is the way bzr does it for 
 example and it works great.

In some commands, options as well as subcommands can change subsequent
parsing.  The iptables command is a good example of a command-line
program that follows this practice.  From the man page:

  after [a module name is specified], various extra command line options
  become available, depending on the specific module.  You can specify
  multiple extended match modules in one line, and you can use the -h or
  --help options after the module has been specified to receive help
  specific to that module.

In the case of iptables, module names are specified as options, not as
subcommands.

From my cursory reading of the documentation, it looks like argparse can
only add subparsers for subcommands.  Is there any way to add subparsers
based on options instead (as iptables does)?

Also, is it possible to add these subparsers dynamically?  For example,
you would want to be able to load a module immediately after parsing the
name instead of having to keep a predetermined list of all module names.
I'm pretty sure that bzr dynamically loads modules this way.  Can
argparse help with this?

Sorry for all of the questions.  I ask them because I have some
experience with adding the above features to optparse, and it was a lot
of work to get it right.  It also seems like there are a lot of programs
that need to load modules dynamically.  I would be really excited if
argparse made this easier than optparse did.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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 389: argparse - new command line parsing module

2009-09-30 Thread Andrew McNabb
On Wed, Sep 30, 2009 at 02:40:20PM -0700, Steven Bethard wrote:
 
  Also, is it possible to add these subparsers dynamically?  For example,
  you would want to be able to load a module immediately after parsing the
  name instead of having to keep a predetermined list of all module names.
  I'm pretty sure that bzr dynamically loads modules this way.  Can
  argparse help with this?
 
 You can probably already do this. I'm not 100% sure what you want to
 do, but it's certainly possible to define an argparse.Action that
 loads a module when it's invoked. It might look something like::
 
 class MyAction(argparse.Action):
 def __call__(self, parser, namespace, value, option_string=None):
 mod = __import__(value) # or whatever

This looks much easier than what I was able to do in optparse.  Cool.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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?

2009-07-31 Thread Andrew McNabb
On Fri, Jul 31, 2009 at 09:16:02PM +, Jacob Rus wrote:
 
   * The operation is crazy: It defines a MimeTypes class which 
 actually stores the type mappings, but this class is designed to 
 be a singleton. The way that such a design is enforced is 
 through the use of the module-global 'init' function, which 
 makes an instance of the class, and then maps all of the 
 functions in the module global namespace to instance methods. 
 But confusingly, all such functions are also defined 
 independently of the init function, with definitions such as:
   
 def guess_type(url, strict=True):
 if not inited:
 init()
 return guess_type(url, strict)

I can't speak for any of your other complaints, but I know that this
weird init stuff is fixed in trunk.

For the other stuff, you seem to have some very good points.  I'm sure a
patch would be welcome.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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] Ext4 data loss

2009-03-13 Thread Andrew McNabb
On Fri, Mar 13, 2009 at 07:31:21PM +0100, Martin v. Löwis wrote:
  Think about the security implications of a file name that is in advance
  known to an attacker as well as the fact that the said file will replace
  an *important* system file.
 
 You should always use O_EXCL in that case. Relying on random name will
 be a severe security threat to the application.

But mkstemp does open files with O_EXCL, so the two approaches really
aren't that different.  Using tempfile can be a little simpler because
it will eventually succeed.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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] What's New in 2.6 link wasn't what I expected

2008-09-18 Thread Andrew McNabb
On Fri, Sep 19, 2008 at 12:49:28AM +0200, Martin v. Löwis wrote:
  I clicked the link labelled What's new in Python 2.6rc2.  This didn't take
  me to the What's New page.  Instead it took me to:
  
  http://www.python.org/download/releases/2.6/NEWS.txt
  
  Seems a bit mislabelled if nothing else.
 
 How so? The first major heading in that file reads
 
 What's New in Python 2.6 release candidate 2?
 
  Am I missing something?
 
 Perhaps reading the file that was linked might have helped.

I ran into this, too (and I did read the file that was linked to).  I
had expected to find the What's New page describing what was new in
Python 2.6, and I would have expected a Release Notes link to point to
the NEWS.txt page.  That's how things were in the past, anyway:

http://www.python.org/download/releases/2.5.2/#what-s-new

It's a minor thing, but I did have to go hunt down the What's New file.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


pgp2b0NCOqYoh.pgp
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] Mini-Pep: Simplifying the Integral ABC

2008-06-05 Thread Andrew McNabb
On Thu, Jun 05, 2008 at 09:41:44AM -0700, Bill Janssen wrote:
  I think I agree with Raymond on the basic principle that simple ABC's
  are easier to use than simple ones.
 
 I don't think he was saying that.  He was saying that simple ABC's are
 easier to implement to.

Sorry; I used the wrong word.  I should have said implement to rather
than use. I agree with you.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


signature.asc
Description: Digital 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] Mini-Pep: Simplifying the Integral ABC

2008-06-04 Thread Andrew McNabb
On Wed, Jun 4, 2008 at 12:57 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:

 Not sure how to generate more discussion.  It seems self-evident
 that an abc with lots of abstract methods is inherently less usable
 and that bitwise operations go beyond the basic notion of integeriness.
 Requiring all those methods to be defined makes it harder to write
 a compliant class.

 Other than int/long, no currently existing type
 matches-up with Integral.  Does anyone care about this?

 Hopefully, some discussion gets generated.  But if no one cares, I'll
 happily drop it.

I'm just responding out of duty to add more discussion on the topic.

I think I agree with Raymond on the basic principle that simple ABC's
are easier to use than simple ones.  Anyway, it's hard to add anything
to the discussion when I haven't seen many applications of the Integral
ABC, but in principle, but if I had to vote I'd say that the bitwise
operators aren't particularly integery.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


signature.asc
Description: Digital 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] Addition of pyprocessing module to standard lib.

2008-05-14 Thread Andrew McNabb
On Wed, May 14, 2008 at 05:46:25PM +0200, M.-A. Lemburg wrote:

 What I'm missing with the processing module is a way to spawn processes
 on clusters (rather than just on a single machine).

 In the scientific world, MPI is the standard API of choice for doing
 parallel processing, so if we're after standards, supporting MPI
 would seem to be more attractive than the processing module.

Think of the processing module as an alternative to the threading
module, not as an alternative to MPI.  In Python, multi-threading can be
extremely slow.  The processing module gives you a way to convert from
using multiple threads to using multiple processes.

If it made people feel better, maybe it should be called threading2
instead of multiprocessing.  The word processing seems to make people
think of parallel processing and clusters, which is missing the point.

Anyway, I would love to see the processing module included in the
standard library.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


pgp42e26gDfkd.pgp
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] Addition of pyprocessing module to standard lib.

2008-05-14 Thread Andrew McNabb
On Wed, May 14, 2008 at 08:06:15AM -0400, Jesse Noller wrote:
 
 Overwhelmingly, many of the python programmers I spoke to are looking
 for a solution that does not require the alteration of a known
 programming paradigm (i.e: threads) to allow them to take advantage of
 systems which are not getting faster - instead, they are getting
 wider. Simply put due to the GIL - pure python applications can not
 take advantage of these machines which are now more common than not
 without switching to an alternative interpreter - which for many -
 myself included - is not an attractive option.

On Newegg, there are currently 15 single core processors listed, but
there are 57 dual core processors and 52 quad core processors.  By the
time Python 2.6 comes out, it will be hard to buy a new computer without
multiple cores.  In my opinion, the sooner Python has a nice simple
library for inter-process communication, the better.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


pgp4U92STA7VZ.pgp
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] Problems with the new super()

2008-05-01 Thread Andrew McNabb
On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote:
 
 I'm not proud of this, but I don't see a way around it. The
 alternative would be to make it a keyword, which seemed excessive
 (plus, it would be odd if super() were a keyword when self is not).
 There were long discussions about various possible ways to implement
 something like this, and they all had their downsides. (The PEP still
 isn't fixed to describe the status quo.)

I remember some brainstorms about treating more like self.  I'm not sure
if these were thought through all the way, but I remember seeing
something like:

class MyClass(Super1, Super2):
# This method requires super:
@requires_super
def __init__(self, super, **kwds):
super(**kwds)

# This method doesn't require super:
def some_method(self):
pass

I'm sure there are drawbacks, but it fits in my head.  Using super in
Python 2.0 is verbose but simple.  However, I'm a little scared of super
in Python 3.0.  I guess I'm probably just a wimp.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


signature.asc
Description: Digital 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] Improved thread switching

2008-03-20 Thread Andrew McNabb
On Thu, Mar 20, 2008 at 09:58:46AM -0400, Jesse Noller wrote:
 FYI: I shot an email to stdlib-sig about the fact I am proposing the
 inclusion of the pyProcessing module into the stdlib. Comments and
 thoughts regarding that would be welcome. I've got a rough outline of
 the PEP, but I need to spend more time with the code examples.

Since we officially encourage people to spawn processes instead of
threads, I think that this would be a great idea.  The processing module
has a similar API to threading.  It's easy to use, works well, and most
importantly, gives us some place to point people to when they complain
about the GIL.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


signature.asc
Description: Digital 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] trunk-math

2008-02-19 Thread Andrew McNabb
On Fri, Feb 15, 2008 at 10:53:14PM -0500, Mark Dickinson wrote:
* New float methods: is_finite, is_inf, is_integer and is_nan.
* New cmath functions: phase, polar and rect, isinf and isnan.
* New complex method: is_finite.

This may be a dumb question, but is there any particular reason that the
float methods are is_inf and is_nan but the cmath methods are
isinf and isnan?

Anyway, this all looks very useful.  Thanks.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


signature.asc
Description: Digital 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] \u and \U escapes in raw unicode string literals

2007-05-11 Thread Andrew McNabb
On Sat, May 12, 2007 at 01:30:52AM +0200, M.-A. Lemburg wrote:
 
 I wonder how we managed to survive all these years with
 the existing consistent and concise definition of the
 raw-unicode-escape codec ;-)
 
 There are two options:
 
  * no one really uses Unicode raw strings nowadays
 
  * none of the existing users has ever stumbled across the
problem case that triggered all this
 
 Both ways, we're discussing a non-issue.


Sure, it's a non-issue for Python 2.x.  However, when Python 3 comes
along, and all strings are Unicode, there will likely be a lot more
users stumbling into the problem case.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868


pgpBqD8o8hnO1.pgp
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