headers
Greg Ewing | 1 Mar 2011 01:07
Picon
Picon
Favicon

Re: class ModuleNotFoundError(ImportError)

Nick Coghlan wrote:

> Perhaps it it worth revisiting the old "import x or y or z as
> whatever" syntax proposal for 3.3

+1, as the suggested idiom is getting rather long-winded. Also
it gets worse when there are more than two alternatives, since
you end up with another nesting level for each fallback.

> (although deciding what, if anything to do for "from" style
> imports is a hassle)

I don't think it would be too bad:

    from x or y or z import foo, spam, eggs

This would first try to find one of the listed modules, and
having found it, import it and attempt to bind the specified
names.

Failures during the binding phase should probably *not*
trigger a fallback to the next module, to avoid ending up
with a situation where some of the names are imported from
one module and some from another. Since the internals of
the modules are probably incompatible with each other,
that would be a bad thing.

--

-- 
Greg
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Ewing | 1 Mar 2011 01:18
Picon
Picon
Favicon

Re: class ModuleNotFoundError(ImportError)

cool-RR wrote:

> I think modules sometimes raise `ImportError` because of problematic 
> circular imports.

It might be more logical if the case where the module is found
but a requested name is not present in it raised AttributeError
or NameError instead of ImportError. I don't think I've ever had
a situation where conflating them both into ImportError was helpful.

ImportError itself would then have the meaning of the proposed
ModuleNotFoundError.

--

-- 
Greg
Permalink | Reply | 0 comments |
headers
Nick Coghlan | 1 Mar 2011 10:50
Picon
Gravatar

Re: New pattern-matching library (was: str.split with multiple individual split characters)

On Tue, Mar 1, 2011 at 9:19 AM, Mike Meyer <mwm@...> wrote:
> I disagree. Fully general string pattern matching has a few
> fundamental operations: sequence, alternation, and repetition.

I agree that the fundamental operations are simple in principle.

However, I still believe that the elaboration of those operations into
fully general pattern matching is a complex combinatorial operation
that is difficult to master. regex's certainly make it harder than it
needs to be, but anything with similar expressive power is still going
to be tricky to completely wrap your head around.

Cheers,
Nick.

P.S. I'm guessing this is the Icon based library you mentioned in the
original message:
http://www.wilmott.ca/python/patternmatching.html

Certainly an interesting read.

--

-- 
Nick Coghlan   |   ncoghlan@...   |   Brisbane, Australia
Permalink | Reply | 0 comments |
headers
Nick Coghlan | 1 Mar 2011 13:23
Picon
Gravatar

Re: class ModuleNotFoundError(ImportError)

On Tue, Mar 1, 2011 at 10:07 AM, Greg Ewing <greg.ewing@...> wrote:
> Nick Coghlan wrote:
>
>> Perhaps it it worth revisiting the old "import x or y or z as
>> whatever" syntax proposal for 3.3
>
> +1, as the suggested idiom is getting rather long-winded. Also
> it gets worse when there are more than two alternatives, since
> you end up with another nesting level for each fallback.
>
>> (although deciding what, if anything to do for "from" style
>> imports is a hassle)
>
> I don't think it would be too bad:
>
>   from x or y or z import foo, spam, eggs
>
> This would first try to find one of the listed modules, and
> having found it, import it and attempt to bind the specified
> names.

True, I guess it is really only the module naming that differs in
cases like ElementTree, which would be handled just fine by the simple
approach:

    import lxml.etree or element.ElementTree or xml.etree.ElementTree as etree
    from lxml.etree or element.ElementTree or xml.etree.ElementTree
import Element

If the internal APIs of the resolved modules differ to the point where
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Meyer | 1 Mar 2011 18:05
Face
Gravatar

Re: New pattern-matching library (was: str.split with multiple individual split characters)

On Tue, 1 Mar 2011 19:50:44 +1000
Nick Coghlan <ncoghlan@...> wrote:

> On Tue, Mar 1, 2011 at 9:19 AM, Mike Meyer <mwm@...> wrote:
> > I disagree. Fully general string pattern matching has a few
> > fundamental operations: sequence, alternation, and repetition.
> 
> I agree that the fundamental operations are simple in principle.
> 
> However, I still believe that the elaboration of those operations into
> fully general pattern matching is a complex combinatorial operation
> that is difficult to master. regex's certainly make it harder than it
> needs to be, but anything with similar expressive power is still going
> to be tricky to completely wrap your head around.

True. But I think that the problem - if properly expressed - is like
the game of Go: a few simple rules that combine to produce a complex
system that is difficult to master. With regexp notation, what we've
got is more like 3d chess: multiple complex (just slightly different)
sets of operations that do more to obscure the underlying simple rules
than to help master the system.

     <mike
--

-- 
Mike Meyer <mwm@...>		http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Permalink | Reply | 10 comments |
headers
Guido van Rossum | 1 Mar 2011 19:30
Favicon

Re: New pattern-matching library (was: str.split with multiple individual split characters)

On Tue, Mar 1, 2011 at 9:05 AM, Mike Meyer <mwm@...> wrote:
> On Tue, 1 Mar 2011 19:50:44 +1000
> Nick Coghlan <ncoghlan@...> wrote:
>
>> On Tue, Mar 1, 2011 at 9:19 AM, Mike Meyer <mwm@...> wrote:
>> > I disagree. Fully general string pattern matching has a few
>> > fundamental operations: sequence, alternation, and repetition.
>>
>> I agree that the fundamental operations are simple in principle.
>>
>> However, I still believe that the elaboration of those operations into
>> fully general pattern matching is a complex combinatorial operation
>> that is difficult to master. regex's certainly make it harder than it
>> needs to be, but anything with similar expressive power is still going
>> to be tricky to completely wrap your head around.
>
> True. But I think that the problem - if properly expressed - is like
> the game of Go: a few simple rules that combine to produce a complex
> system that is difficult to master. With regexp notation, what we've
> got is more like 3d chess: multiple complex (just slightly different)
> sets of operations that do more to obscure the underlying simple rules
> than to help master the system.

I'm not sure those are the right analogies (though they may not be all
that wrong either). If you ask me there are two problems with regexps:

(a) The notation is cryptic and error-prone, its use of \ conflicts
with Python strings (using r'...' helps but is yet another gotcha),
and the parser is primitive. Until your brain has learned to parse
regexps, it will have a hard time understanding examples, which are
(Continue reading)

Permalink | Reply | 9 comments |
headers
geremy condra | 1 Mar 2011 20:53
Picon
Gravatar

Re: New pattern-matching library (was: str.split with multiple individual split characters)

On Tue, Mar 1, 2011 at 10:30 AM, Guido van Rossum <guido@...> wrote:
> On Tue, Mar 1, 2011 at 9:05 AM, Mike Meyer <mwm@...> wrote:
>> On Tue, 1 Mar 2011 19:50:44 +1000
>> Nick Coghlan <ncoghlan@...> wrote:
>>
>>> On Tue, Mar 1, 2011 at 9:19 AM, Mike Meyer <mwm@...> wrote:
>>> > I disagree. Fully general string pattern matching has a few
>>> > fundamental operations: sequence, alternation, and repetition.
>>>
>>> I agree that the fundamental operations are simple in principle.
>>>
>>> However, I still believe that the elaboration of those operations into
>>> fully general pattern matching is a complex combinatorial operation
>>> that is difficult to master. regex's certainly make it harder than it
>>> needs to be, but anything with similar expressive power is still going
>>> to be tricky to completely wrap your head around.
>>
>> True. But I think that the problem - if properly expressed - is like
>> the game of Go: a few simple rules that combine to produce a complex
>> system that is difficult to master. With regexp notation, what we've
>> got is more like 3d chess: multiple complex (just slightly different)
>> sets of operations that do more to obscure the underlying simple rules
>> than to help master the system.
>
> I'm not sure those are the right analogies (though they may not be all
> that wrong either). If you ask me there are two problems with regexps:
>
> (a) The notation is cryptic and error-prone, its use of \ conflicts
> with Python strings (using r'...' helps but is yet another gotcha),
> and the parser is primitive. Until your brain has learned to parse
(Continue reading)

Permalink | Reply | 8 comments |
headers
Tal Einat | 1 Mar 2011 21:25
Picon
Gravatar

Re: New pattern-matching library (was: str.split with multiple individual split characters)

On Tue, Mar 1, 2011 at 9:53 PM, geremy condra <debatem1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
It's unfortunate that there isn't a good way to do this kind of
long-range work within the auspices of Python. I can imagine a number
of projects like this that fail to attract interest due to low
perceived chances of success and a dearth of community feedback.

Once a good library had a solid foundation, it could plug itself into some widely used Python programs and gain publicity and support from there, before pushing for inclusion in the stdlib.

A good example is Django's URL mapping, which currently uses regexps. I think it would be possible to get Django to support an alternate pattern matching method, in addition to regexps, since this would make learning Django easier for developers who don't grok regexps.

- Tal Einat
_______________________________________________
Python-ideas mailing list
Python-ideas@...
http://mail.python.org/mailman/listinfo/python-ideas
Permalink | Reply | 7 comments |
headers
Guido van Rossum | 1 Mar 2011 22:23
Favicon

Re: New pattern-matching library (was: str.split with multiple individual split characters)

On Tue, Mar 1, 2011 at 12:25 PM, Tal Einat <taleinat@...> wrote:
> On Tue, Mar 1, 2011 at 9:53 PM, geremy condra <debatem1@...> wrote:
>>
>> It's unfortunate that there isn't a good way to do this kind of
>> long-range work within the auspices of Python. I can imagine a number
>> of projects like this that fail to attract interest due to low
>> perceived chances of success and a dearth of community feedback.
>
> Once a good library had a solid foundation, it could plug itself into some
> widely used Python programs and gain publicity and support from there,
> before pushing for inclusion in the stdlib.
>
> A good example is Django's URL mapping, which currently uses regexps. I
> think it would be possible to get Django to support an alternate pattern
> matching method, in addition to regexps, since this would make learning
> Django easier for developers who don't grok regexps.

Ah, but geremy is complaining about work that cannot be done as a
library, e.g. syntax changes. This is because I suggested a better
approach to matching would probably require syntax changes. I don't
have an answer -- it may be easier to create a whole new language and
experiment with matching syntax than it is to get a PEP approved for a
matching syntax extension to Python... That's just how it goes for
mature languages. Try getting new syntax added to C++, Java or
JavaScript... :-)

--

-- 
--Guido van Rossum (python.org/~guido)
Permalink | Reply | 6 comments |
headers
Greg Ewing | 1 Mar 2011 23:31
Picon
Picon
Favicon

Re: New pattern-matching library

Guido van Rossum wrote:

> It's been tried before without much success. I think it may have been
> a decade ago that Ka-Ping Yee created a pattern matching library that
> used function calls ... It didn't get much use.

That may largely be due to marketing issues. A potential
user would have to know that Ka-Ping's module existed, or
be sufficiently dissatisfied with the status quo to go
looking for something like it. Probably it has never even
occurred to many people familiar with REs from other contexts
that there might be another way.

Whereas if there were a set of constructor functions available
right at hand in the re module, prominently featured in the
examples and reference docs, I suspect they would be used
quite a lot. I know that *I* would use them all the time,
whereas I've never been motivated enough to pull in another
module to get this functionality.

Perhaps the best way to think of this is not as a complete
replacement for traditional RE syntax, but as a set of
convenience functions for building up REs out of smaller
REs. It's not entirely straightforward to do that correctly,
taking into account escaping, operator precedence, etc.,
so having some functions available for it makes a lot of
sense. They would make it much easier to write readable
code involving complicated REs. Since we're a community
of people who believe that "readability counts", there
shouldn't be any argument that this is a desirable goal.

> On the third hand, I could see this as an area where a pure
> library-based approach will always be doomed, and where a proposal to
> add new syntax would actually make sense.

I don't think new syntax is necessary -- functions are
quite adequate for the task. But they need to be available
right at your fingertips when you're working with REs.
Having to seek out and obtain a third party library is
too high a barrier to entry.

--

-- 
Greg
Permalink | Reply | 1 comment |

Gmane