[issue12961] unlabelled balls in boxes

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

Hello Mark,

This is a fair question.  Suppose that I have three boxes with capacity
limits of 3, 2, and 1, and that there are three balls in total.  Two of the
possible distributions are the following:

2, 0, 1
2, 1, 0

Capacity limits of the individual boxes must be observed when distributing
the balls.  Even though the second and third boxes have different
capacities, we must treat the above two distributions of balls as
equivalent.

Combinatorics problems involving boxes with capacity limits arise in such
application domains as physics and reliability.

Phillip

On Mon, Sep 12, 2011 at 5:13 AM, Mark Dickinson wrote:

>
> Mark Dickinson  added the comment:
>
> > "unlabelled balls in unlabelled boxes with capacity limits"
>
> What does this mean?  If the boxes are unlabelled, how can they have
> individual capacity limits?  Or do you mean just a single limit that applies
> to all boxes?
>
> --
> nosy: +mark.dickinson
>
> ___
> Python tracker 
> <http://bugs.python.org/issue12961>
> ___
>

--
nosy: +phillip.m.feld...@gmail.com
Added file: http://bugs.python.org/file23132/unnamed

___
Python tracker 
<http://bugs.python.org/issue12961>
___Hello Mark,This is a fair question.  Suppose that I have three boxes 
with capacity limits of 3, 2, and 1, and that there are three balls in total.  
Two of the possible distributions are the following:2, 0, 1
2, 1, 0Capacity limits of the individual boxes must be observed when 
distributing the balls.  Even though the second and third boxes have different 
capacities, we must treat the above two distributions of balls as 
equivalent.
Combinatorics problems involving boxes with capacity limits arise in such 
application domains as physics and reliability.PhillipOn Mon, Sep 12, 2011 at 5:13 AM, Mark Dickinson <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Mark Dickinson <mailto:dicki...@gmail.com";>dicki...@gmail.com> added the 
comment:

> "unlabelled balls in unlabelled boxes with capacity limits"

What does this mean?  If the boxes are unlabelled, how can they have 
individual capacity limits?  Or do you mean just a single limit that applies 
to all boxes?

--
nosy: +mark.dickinson

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue12961"; 
target="_blank">http://bugs.python.org/issue12961>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12961] unlabelled balls in boxes

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

Here's an example of a problem from an entirely different domain:

An error control coding scheme can correct up to 3 errors in the header of a
packet and up to one error in the body of a packet. A given message is
divided into four consecutive packets. Find all possible correctible
distributions of 6 errors among the four packets, treating the order of the
four packets as significant.

Phillip

On Mon, Sep 12, 2011 at 9:41 AM, Phillip M. Feldman
wrote:

>
> Phillip M. Feldman  added the comment:
>
> Hello Mark,
>
> This is a fair question.  Suppose that I have three boxes with capacity
> limits of 3, 2, and 1, and that there are three balls in total.  Two of the
> possible distributions are the following:
>
> 2, 0, 1
> 2, 1, 0
>
> Capacity limits of the individual boxes must be observed when distributing
> the balls.  Even though the second and third boxes have different
> capacities, we must treat the above two distributions of balls as
> equivalent.
>
> Combinatorics problems involving boxes with capacity limits arise in such
> application domains as physics and reliability.
>
> Phillip
>
> On Mon, Sep 12, 2011 at 5:13 AM, Mark Dickinson  >wrote:
>
> >
> > Mark Dickinson  added the comment:
> >
> > > "unlabelled balls in unlabelled boxes with capacity limits"
> >
> > What does this mean?  If the boxes are unlabelled, how can they have
> > individual capacity limits?  Or do you mean just a single limit that
> applies
> > to all boxes?
> >
> > --
> > nosy: +mark.dickinson
> >
> > ___
> > Python tracker 
> > <http://bugs.python.org/issue12961>
> > ___
> >
>
> --
> nosy: +phillip.m.feld...@gmail.com
> Added file: http://bugs.python.org/file23132/unnamed
>
> ___
> Python tracker 
> <http://bugs.python.org/issue12961>
> ___
>

--
Added file: http://bugs.python.org/file23134/unnamed

___
Python tracker 
<http://bugs.python.org/issue12961>
___Here's an example of a problem from an entirely different domain:An 
error control coding scheme can correct up to 3 errors in the header of a 
packet and up to one error in the body of a packet. A given message is divided 
into four consecutive packets. Find all possible correctible distributions of 6 
errors among the four packets, treating the order of the four packets as 
significant.
PhillipOn Mon, Sep 12, 2011 at 9:41 AM, 
Phillip M. Feldman <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Phillip M. Feldman <mailto:phillip.m.feld...@gmail.com";>phillip.m.feld...@gmail.com> 
added the comment:

Hello Mark,

This is a fair question.  Suppose that I have three boxes with capacity
limits of 3, 2, and 1, and that there are three balls in total.  Two of the
possible distributions are the following:

2, 0, 1
2, 1, 0

Capacity limits of the individual boxes must be observed when distributing
the balls.  Even though the second and third boxes have different
capacities, we must treat the above two distributions of balls as
equivalent.

Combinatorics problems involving boxes with capacity limits arise in such
application domains as physics and reliability.

Phillip

On Mon, Sep 12, 2011 at 5:13 AM, Mark Dickinson <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>wrote:

>
> Mark Dickinson <mailto:dicki...@gmail.com";>dicki...@gmail.com> added the 
comment:
>
> > "unlabelled balls in unlabelled boxes with capacity 
limits"
>
> What does this mean?  If the boxes are unlabelled, how can they have
> individual capacity limits?  Or do you mean just a single limit that 
applies
> to all boxes?
>
> --
> nosy: +mark.dickinson
>
> ___
> Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
> <http://bugs.python.org/issue12961"; 
target="_blank">http://bugs.python.org/issue12961>
> ___
>

--
nosy: +mailto:phillip.m.feld...@gmail.com";>phillip.m.feld...@gmail.com
Added file: http://bugs.python.org/file23132/unnamed"; 
target="_blank">http://bugs.python.org/file23132/unnamed

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue12961"; 
target="_blank">http://bugs.python.org/issue12961>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13185] Why does Python interpreter care about curvy quotes in comments?

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

Hello Martin,

This is a fine example of the so-called "is-ought" controversy.  The error
message is indeed telling me exactly what the problem is, but the underlying
problem is that this scheme was poorly thought out.  Clearly, the stripping
of comments and the source decoding should both be done in a single pass,
and the source decoding should not be applied to the comments.

Phillip

On Sat, Oct 15, 2011 at 4:26 AM, Martin v. Löwis wrote:

>
> Martin v. Löwis  added the comment:
>
> The error message told you exactly what the problem is. Your source file
> does not conform to PEP 263. The PEP also explains why this applies to
> comments as well: because the entire file gets decoded according to the
> source encoding, and parsing (including determining what comments are) only
> starts afterwards.
>
> Closing the report as invalid.
>
> --
> nosy: +loewis
> resolution:  -> invalid
> status: open -> closed
>
> ___
> Python tracker 
> <http://bugs.python.org/issue13185>
> ___
>

--
nosy: +phillip.m.feld...@gmail.com

___
Python tracker 
<http://bugs.python.org/issue13185>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13185] Why does Python interpreter care about curvy quotes in comments?

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

I'm beginning to understand the reasoning.  This is quite a bit more complex
than I initially thought, and I appreciate the explanations.

Phillip

On Sun, Oct 16, 2011 at 10:53 PM, Raymond Hettinger
wrote:

>
> Raymond Hettinger  added the comment:
>
> I concur with Martin and Ezio.
> This report was correctly closed as invalid.
>
> --
> nosy: +rhettinger
>
> ___
> Python tracker 
> <http://bugs.python.org/issue13185>
> ___
>

--

___
Python tracker 
<http://bugs.python.org/issue13185>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13584] argparse doesn't respect double quotes

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

Hello Steven,

I'm embarrassed to report that I can't reproduce the problem.  The
input line is parsed correctly if I enclose the string 'Demo IO' in
double quotes.  It is parsed incorrectly if I enclose it in single
quotes, but it looks as though this is the fault of the Windows shell,
and not Python.

My apologies.

Phillip

On Thu, Dec 15, 2011 at 2:22 AM, Steven Bethard  wrote:
>
> Steven Bethard  added the comment:
>
> Can you submit some example code that shows this? I can't reproduce this with:
>
> -- temp.py --
> import argparse
>
> parser = argparse.ArgumentParser()
> parser.add_argument("--ng", action="store_true")
> parser.add_argument("--INP")
> print(parser.parse_args())
> --
>
> $ python temp.py --ng --INP="Demo IO"
> Namespace(INP='Demo IO', ng=True)
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue13584>
> ___

--
nosy: +phillip.m.feld...@gmail.com

___
Python tracker 
<http://bugs.python.org/issue13584>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1859] textwrap doesn't linebreak on "\n"

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

I would like to unsubscribe from this thread, but haven't been able to
figure out how to do it.

Phillip

On Mon, Nov 22, 2010 at 11:50 PM, Georg Brandl wrote:

>
> Georg Brandl  added the comment:
>
> Yes, please do apply.  You don't need to run a doc build for every small
> change; of course it is nice if you do, but errors will be caught by the
> daily build routine anyway and mailed to me.
>
> As for the two blank lines: you'll see that the original conversion from
> LaTeX produced two blank lines after each description (function, class,
> ...), and I find this to be a little more readable than only one blank line,
> especially when the descriptions are longer; for short descriptions leaving
> only one blank line saves space.  Syntactically, both are fully equivalent.
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue1859>
> ___
>

--
Added file: http://bugs.python.org/file19785/unnamed

___
Python tracker 
<http://bugs.python.org/issue1859>
___I would like to unsubscribe from this thread, but haven't been able to 
figure out how to do it.PhillipOn Mon, 
Nov 22, 2010 at 11:50 PM, Georg Brandl <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Georg Brandl <mailto:ge...@python.org";>ge...@python.org> 
added the comment:

Yes, please do apply.  You don't need to run a doc build for every small 
change; of course it is nice if you do, but errors will be caught by the daily 
build routine anyway and mailed to me.

As for the two blank lines: you'll see that the original conversion from 
LaTeX produced two blank lines after each description (function, class, ...), 
and I find this to be a little more readable than only one blank line, 
especially when the descriptions are longer; for short descriptions leaving 
only one blank line saves space.  Syntactically, both are fully equivalent.


--

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue1859"; 
target="_blank">http://bugs.python.org/issue1859>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10715] uninformative error message

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

I eventually determined that a call to `subprocess.Popen` was responsible
for the message, but could have determined this much more quickly if the
message had included the name of the file that could not be opened
(executed).

Phillip

On Mon, Dec 20, 2010 at 11:20 AM, Éric Araujo wrote:

>
> Changes by Éric Araujo :
>
>
> --
> components: +IO
> nosy: +eric.araujo
> versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
>
> ___
> Python tracker 
> <http://bugs.python.org/issue10715>
> ___
>

--
nosy: +phillip.m.feld...@gmail.com
Added file: http://bugs.python.org/file20125/unnamed

___
Python tracker 
<http://bugs.python.org/issue10715>
___I eventually determined that a call to `subprocess.Popen` was responsible for 
the message, but could have determined this much more quickly if the message 
had included the name of the file that could not be opened (executed).
PhillipOn Mon, Dec 20, 2010 at 11:20 AM, 
Éric Araujo <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Changes by Éric Araujo <mailto:mer...@netwok.org";>mer...@netwok.org>:


--
components: +IO
nosy: +eric.araujo
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue10715"; 
target="_blank">http://bugs.python.org/issue10715>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10715] uninformative error message

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

Why was this removed?

On Mon, Dec 20, 2010 at 8:30 PM, Alexander Belopolsky <
rep...@bugs.python.org> wrote:

>
> Changes by Alexander Belopolsky :
>
>
> Removed file: http://bugs.python.org/file20125/unnamed
>
> ___
> Python tracker 
> <http://bugs.python.org/issue10715>
> ___
>

--
Added file: http://bugs.python.org/file20126/unnamed

___
Python tracker 
<http://bugs.python.org/issue10715>
___Why was this removed?On Mon, Dec 20, 2010 at 
8:30 PM, Alexander Belopolsky <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Changes by Alexander Belopolsky <mailto:belopol...@users.sourceforge.net";>belopol...@users.sourceforge.net>:


Removed file: http://bugs.python.org/file20125/unnamed"; 
target="_blank">http://bugs.python.org/file20125/unnamed

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue10715"; 
target="_blank">http://bugs.python.org/issue10715>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41740] string concatenation via `sum`

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

I'm not sure whether this is a bug or a feature request, but it seems as though 
the following should produce the same result:

In [1]: 'a' + 'b' + 'c'
Out[1]: 'abc'

In [2]: sum(('a', 'b', 'c'))
TypeError Traceback (most recent call last)
in
> 1 sum(('a', 'b', 'c'))

TypeError: unsupported operand type(s) for +: 'int' and 'str'

The error message is confusing (there is no integer).

--
components: Interpreter Core
messages: 376526
nosy: phillip.m.feld...@gmail.com
priority: normal
severity: normal
status: open
title: string concatenation via `sum`
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue41740>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41740] Improve error message for string concatenation via `sum`

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

I'd forgotten about ''.join; this is a good solution.  I withdraw my
comment.

On Mon, Sep 7, 2020 at 3:25 PM Steven D'Aprano 
wrote:

>
> Steven D'Aprano  added the comment:
>
> Marco, sum should be as fast as possible, so we don't want to type check
> every single element. But if it is easy enough, it might be worth checking
> the first element, and if it fails, report:
>
> cannot add 'type' to start value
>
> where 'type' is the type of the first element. If that is str, then
> concatenate
>
> (use ''.join(iterable) instead)
>
> to the error message.
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue41740>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue41740>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36266] Which module could not be found?

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

I have a module that contains an import statement that imports a large number 
of items.  This import was failing with the following error message:

ImportError: DLL load failed: The specified module could not be found.

The message would be so much more helpful if it named the offending DLL and 
module.

--
components: Interpreter Core
messages: 337698
nosy: phillip.m.feld...@gmail.com
priority: normal
severity: normal
status: open
title: Which module could not be found?
versions: Python 3.6

___
Python tracker 
<https://bugs.python.org/issue36266>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36266] Which module could not be found?

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

Hello Steve,

I'm buying only 50 percent of this.  The Python interpreter must know what
module it was trying to import, and can at least be able to report that.

Phillip

On Tue, Mar 12, 2019 at 8:42 AM Steve Dower  wrote:

>
> Steve Dower  added the comment:
>
> I agree. Unfortunately, the operating system does not provide this
> information.
>
> The best I can offer is to run Process Monitor [1] and watch its logs. It
> should show the paths it attempts to access.
>
> [1]: http://technet.microsoft.com/en-us/sysinternals/bb896645
>
> --
> resolution:  -> third party
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36266>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue36266>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36266] Which module could not be found?

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

'Should include "_ssl" somewhere in the message?'  Exactly so.  If a given
import statement imports 30 items, it would be helpful to know which one
caused the hickup.  Thanks!

On Wed, Mar 13, 2019 at 12:28 PM Steve Dower  wrote:

>
> Steve Dower  added the comment:
>
> You mean like this:
>
> >>> import _ssl
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: DLL load failed: The specified module could not be found.
>
> Should include "_ssl" somewhere in the message? That's easy enough, but
> it's never been what anyone else has meant when they've asked for this, so
> I assumed you wanted the more helpful message (where it tells you exactly
> which DLL is missing - libcrypto-1_1-x64.dll in this case - and *that's*
> the one we can't do).
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36266>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue36266>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34299] argparse description formatting

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

With `argparse`, I'm providing a triple-quoted string via the `description` 
argument of the constructor.  When I invoke the script with the -h or --help 
argument, all formatting in the triple-quoted string is lost, i.e., all 
paragraphs are run together into one giant paragraph, and the result is rather 
hard to read.

Phillip M. Feldman

--
components: Library (Lib)
messages: 322808
nosy: phillip.m.feld...@gmail.com
priority: normal
severity: normal
status: open
title: argparse description formatting
type: behavior
versions: Python 2.7

___
Python tracker 
<https://bugs.python.org/issue34299>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34299] argparse description formatting

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

That works.  Thanks!

I think that this boils down to a documentation issue.  The following says
that the default behavior is to line-wrap the help messages.  At least to
me, this doesn't imply that whitespace is getting eaten.

RawDescriptionHelpFormatter
<https://docs.python.org/3/library/argparse.html#argparse.RawDescriptionHelpFormatter>
and RawTextHelpFormatter
<https://docs.python.org/3/library/argparse.html#argparse.RawTextHelpFormatter>
give more control over how textual descriptions are displayed. By default,
ArgumentParser
<https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser>
objects line-wrap the description
<https://docs.python.org/3/library/argparse.html#description> and epilog
<https://docs.python.org/3/library/argparse.html#epilog> texts in
command-line help messages:

On Tue, Jul 31, 2018 at 12:43 PM, Zsolt Cserna 
wrote:

>
> Zsolt Cserna  added the comment:
>
> You would need to use the RawTextHelpFormatter as format_class for the
> constructor. In this case, argparse will apply no re-wrapping of the
> description.
>
> import argparse
>
> parser = argparse.ArgumentParser(description="""foo
> bar
> baz""", formatter_class=argparse.RawTextHelpFormatter)
>
> --
> nosy: +csernazs
>
> ___
> Python tracker 
> <https://bugs.python.org/issue34299>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue34299>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34417] imp.find_module reacts badly to iterator

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

`imp.find_module` goes down in flames if one tries to pass an iterator rather 
than a list of folders.  Firstly, the message that it produces is somewhat 
misleading:

   RuntimeError: sys.path must be a list of directory names

Secondly, it would be helpful if one could pass an iterator. I'm thinking in 
particular of the situation where one wants to import something from a large 
folder tree, and the module in question is likely to be found early in the 
search process, so that it is more efficient to explore the folder tree 
incrementally.

--
components: Library (Lib)
messages: 323623
nosy: phillip.m.feld...@gmail.com
priority: normal
severity: normal
status: open
title: imp.find_module reacts badly to iterator
type: behavior
versions: Python 2.7

___
Python tracker 
<https://bugs.python.org/issue34417>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34417] imp.find_module reacts badly to iterator

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

It appears that the `importlib` package has the same issue: One can't
provide an iterator for the path.  When searching a large folder tree for
an item that is likely to be found early in the search process (i.e., at a
high level in the folder tree), the available functionality is massively
inefficient.  So, I wrote my own wrapper for `imp.find_module` to do this
job, and will eventually modify this code to use `importlib` instead of
`imp`.

On Fri, Aug 17, 2018 at 9:05 AM Eric Snow  wrote:

>
> Eric Snow  added the comment:
>
> There are several issues at hand here, Phillip.  I'll enumerate them below.
>
> Thanks for taking the time to let us know about this.  However, I'm
> closing this issue since realistically the behavior of imp.find_module()
> isn't going to change, particularly in Python 2.7.  Even though the issue
> is closed, feel free to reply, particularly about how you are using
> imp.find_module() (we may be able to point you toward how to use importlib
> instead).
>
> Also, I've changed this issue's type to "enhancement".  imp.find_module()
> is working as designed, so what you are looking for is a feature request.
> Consequently there's a much higher bar for justifying a change.  Here are
> reasons why the requested change doesn't reach that bar:
>
> 1. Python 2.7 is closed to new features.
>
> So imp.find_module() is not going to change.
>
> 2. Python 2.7 is nearing EOL.
>
> We highly recommend that everyone move to Python 3 as soon as possible.
> Hopefully you are in a position to do so.  If you're stuck on Python 2.7
> then you miss the advantages of importlib, along with a ton of other
> benefits.
>
> If you are not going to be able to migrate before 2020 then send an email
> to python-l...@python.org asking for recommendations on what to do.
>
> 3. Starting in Python 3.4, using the imp module is discouraged/deprecated.
>
>   "Deprecated since version 3.4: The imp package is pending deprecation in
> favor of importlib." [1]
>
> The importlib package should have everything you need.  What are you using
> imp.find_module() for?  We should be able to demonstrate the equivalent
> using importlib.
>
> 4. The import machinery is designed around using a list (the builtin type,
> not the concept) for the "module search path".
>
> * imp.find_module(): "the list of directory names given by sys.path is
> searched" [2]
> * imp.find_module(): "Otherwise, path must be a list of directory names"
> [2]
> * importlib.find_loader() (deprecated): "optionally within the specified
> path" (which defaults to sys.path) [3]
> * importlib.util.find_spec(): doesn't even have a "path" parameter [4]
> * ModuleSpec.submodule_search_locations: "List of strings for where to
> find submodules" [5]
> * sys.path: "A list of strings that specifies the search path for modules.
> ... Only strings and bytes should be added to sys.path; all other data
> types are ignored during import." [6]
>
>
> [1] https://docs.python.org/3/library/imp.html#module-imp
> [2] https://docs.python.org/3/library/imp.html#imp.find_module
> [3] https://docs.python.org/3/library/importlib.html#importlib.find_loader
> [4]
> https://docs.python.org/3/library/importlib.html#importlib.util.find_spec
> [5]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.submodule_search_locations
> [6] https://docs.python.org/3/library/sys.html#sys.path
>
> --
> nosy: +brett.cannon, eric.snow
> resolution:  -> wont fix
> stage:  -> resolved
> status: open -> closed
> type: behavior -> enhancement
>
> ___
> Python tracker 
> <https://bugs.python.org/issue34417>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue34417>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34417] imp.find_module reacts badly to iterator

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

My apologies for the tone of my remark.  I am grateful to you and others
who donate their time to develop the code.

I'm attaching the wrapper code that I created to work around the problem.

Phillip

def expander(paths='./*'):
   """
   OVERVIEW

   This function is a generator, i.e., creates an iterator that recursively
   searches a list of folders in an incremental fashion.  This approach is
   advantageous when the folder tree(s) to be searched are large and the
item of
   interest is likely to be found early in the process.

   INPUTS

   `paths` must be either (a) a list of folder paths (each of which is a
string)
   or (b) a single string containing one or more folder paths separated by
the
   OS-specific path delimiter.

   Each path in `paths` must be either (a) an existing folder or (b) an
existing
   folder followed by '/*' or '\*'.  In case (a), the folder string is
copied
   from the input (`paths`) to the output result verbatim.  In case (b), the
   folder string is replaced by an expanded list that includes not only the
   base (the portion of the path that remains after the '/*' or '\*' has
been
   removed), but all subfolders as well.

   RETURN VALUES

   The returned value is an iterator.

   Invoking the `next` method of the iterator produces one folder path at a
   time.
   """

   if isinstance(paths, basestring):
  paths= paths.split(os.pathsep)

   elif not isinstance(paths, list):
  raise TypeError("`paths` must be either a string or a list of
strings.")

   found= set()

   for path in paths:
  if path.endswith('/*') or path.endswith('\*'):

 # A recursive search of subfolders is required:
 for item in os.walk(path[:-2]):
base= os.path.abspath(item[0])
new= [os.path.join(base, nested) for nested in item[1]]

for item in new:
   if not item in found:
  found.add(item)
  yield item

  else:

 # No recursive search is required:
 if not item in found:
found.add(item)
yield item

   # end for path in paths

def find_module(module_name, in_folders=[]):
   """
   This function finds a module and return the fully-qualified file name.
   Folders from `in_folders`, if specified, are search first, followed by
   folders in the global `import_path` list.

   If any folder name in `in_folders` or `import_path` ends with an
asterisk,
   indicating that a recursive search is required, `files.expander` is
   invoked to create iterators that return one folder at a time, and
   `imp.find_module` is invoked separately for each of these folders.

   EXPLICIT INPUTS

   `module_name` is the unqualified name of the module to be found.

   `in_folders` is an optional list of additional folders to be searched
before
   the folders in `import_path` are searched.

   IMPLICIT INPUTS

   `import_path` is obtained from the global namespace.

   RETURN VALUES

   If `find_module` is able to find the requested module, it returns the
same
   three return values (`f`, `filename`, and `description`) that
   `imp.find_module` would return.
   """

   if isinstance(in_folders, basestring):
  in_folders= [in_folders]
   elif not isinstance(in_folders, list):
  raise TypeError("If specified, `in_folders` must be either a string
or a "
"list of strings.  (A string is wrapped to produce a length-1
list).")

   if any([item.endswith('*') for item in in_folders ]) or \
  any([item.endswith('*') for item in import_path]):

  ex= None

  for folder in itertools.chain(
expander(in_folders), expander(import_path)):
 try:
return imp.find_module(module_name, in_folders + import_path)
 except Exception as ex:
pass

  if ex:
 raise ex

   else:
  return imp.find_module(module_name, in_folders + import_path)

On Tue, Aug 21, 2018 at 10:32 AM Brett Cannon 
wrote:

>
> Brett Cannon  added the comment:
>
> Saying "the available functionality is massively inefficient" is
> unnecessarily hostile towards those of us who actually wrote and maintain
> that code. Without diving into the code, chances are that requirement is
> there so that the C code can use macros to access the list as efficiently
> as possible.
>
> Now if you want to propose specific changes to importlib's code for it to
> work with iterables instead of just lists then we would be happy to review
> the pull request.
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue34417>
> ___
>

--

__

[issue6652] missing cmath functions

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

The online documentation describes functions cmath.phase and
cmath.polar, but when I try to import these, I get "cannot import name"
errors.

--
assignee: georg.brandl
components: Documentation
messages: 91330
nosy: georg.brandl, pfeld...@verizon.net
severity: normal
status: open
title: missing cmath functions
versions: Python 2.5

___
Python tracker 
<http://bugs.python.org/issue6652>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6663] re.findall does not always return a list of strings

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

As per the Python documentation, the following regular expression should
produce a list containing the strings '6.7', 7.33', and '9':

re.findall('(-?\d+[.]\d+)|(-?\d+[.]?)|(-?[.]\d+)', 'asdf6.77.33ff9')

Instead, it generates a list of tuples.  Either the documentation should
be changed to make it consistent with what re.findall is actually doing,
or, better yet, re.findall should be fixed.

--
components: Regular Expressions
messages: 91393
nosy: pfeld...@verizon.net
severity: normal
status: open
title: re.findall does not always return a list of strings
type: behavior
versions: Python 2.5

___
Python tracker 
<http://bugs.python.org/issue6663>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6663] re.findall does not always return a list of strings

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

You are right-- the documentation does say this, although it took me a 
while to understand what it means.  Thanks!

It seems as though there's a flaw in the design here, because there 
should be some mechanism for grouping elements of a regular expression 
without having findall treat these as groups for purposes of packaging 
the output.  If someone really wants to get lists of tuples out of 
findall, then it might make sense to input a tuple of strings instead of 
a single string.

Phillip

Alexey Shamrin wrote:
> Alexey Shamrin  added the comment:
>
> You've made three groups with parentheses. Just drop them:
>
>   
>>>> re.findall('-?\d+[.]\d+|-?\d+[.]?|-?[.]\d+', 'asdf6.77.33ff9')
>>>> 
> ['6.7', '7.33', '9']
>
> Everything is according to documentation: "If one or more groups are
> present in the pattern, return a list of groups; this will be a list of
> tuples if the pattern has more than one group."
>
> http://docs.python.org/library/re.html#re.findall
>
> I would suggest to close this bug.
>
> --
> nosy: +ash
>
> ___
> Python tracker 
> <http://bugs.python.org/issue6663>
> ___
>
>

--

___
Python tracker 
<http://bugs.python.org/issue6663>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3079] sys.exit() called from optparse - bad, bad, bad

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

The current behavior of optparse is contrary to how most of Python
works. optparse should throw a named exception that can be trapped and
identified by the calling program.  Doing a SystemExit is unacceptable.
 I can't believe that this is such a hard thing to fix.

--
nosy: +pfeld...@verizon.net

___
Python tracker 
<http://bugs.python.org/issue3079>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3079] sys.exit() called from optparse - bad, bad, bad

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

Thanks for the response!

I can indeed catch SystemExit, but I would like to be able to take one 
action (terminate the program) if the user supplied an unknown option, 
and another action (prompt for a new value) if the user supplied a bad 
value for an option.  I suspect that I can achieve this by subclassing, 
but I'm not yet at that level of Python sophistication.

Yours,

Phillip

R. David Murray wrote:
> R. David Murray  added the comment:
>
> There was recently a long discussion of this on python-dev (in the
> context of a proposal to add argparse to the stdlib; argparse does the
> same thing).  The conclusion was that the current behavior is the most
> useful behavior, and that if you don't want to exit you can either
> subclass or catch SystemExit.
>
> --
> nosy: +r.david.murray
> resolution:  -> wont fix
> stage:  -> committed/rejected
> status: open -> closed
>
> ___
> Python tracker 
> <http://bugs.python.org/issue3079>
> ___
>
>

--

___
Python tracker 
<http://bugs.python.org/issue3079>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1859] textwrap doesn't linebreak on "\n"

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

As a temporary workaround, you can use the `wrap` function in my strnum
module (http://pypi.python.org/pypi/strnum/2.4).

Phillip

--
nosy: +pfeld...@verizon.net

___
Python tracker 
<http://bugs.python.org/issue1859>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7411] allow import from file having name containing hyphen or blank

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

It appears that there is currently no way to import from a file whose
name contains a hyphen or blank.  This makes it difficult to encode a
version number or date in the file name.   The solution that I favor
would be to allow the name of the file to be specified via a quoted string.

--
components: Interpreter Core
messages: 95832
nosy: pfeld...@verizon.net
severity: normal
status: open
title: allow import from file having name containing hyphen or blank
type: behavior
versions: Python 2.5

___
Python tracker 
<http://bugs.python.org/issue7411>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com