Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Chris Angelico]

On Wed, Feb 25, 2015 at 5:00 PM, Ben Finney  wrote:
> There is a wider context here, too: semantics of the backslash escape
> https://en.wikipedia.org/wiki/Backslash#Usage> commonly include
> “backslash followed by a character not otherwise mentioned will produce
> that character, verbatim”.
>
> Proposals to change that for Python's string literals must account for
> the fact this will make Python's rules for backslash escape surprisingly
> different in this regard from many other usages of backslash escape.

That's different from Python's rule, which is that "backslash followed
by a character not otherwise mentioned will produce *a backslash
followed by* that character, verbatim".

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

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Stephen J. Turnbull]

Nick Coghlan writes:

 > The linter developers don't have a decision making process that lets them
 > pursue things like this on their own.

I'm not suggesting that the linter developers do any such thing.  I'm
suggesting that users (specifically Chris) customize their preferred
linters (most permit that).

What bothers me is that the hardest to understand failures cannot
possibly be helped, because they are legal, meaningful syntax that
conflicts with syntax common in external contexts.  Replacing
mnemonics like '\t' with '\x09' (or even '\u0009' in Python 3) in
debugging output (including error messages) seems like a much better
idea to me.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] how to inspect if something includes a bound first param

[Terry Reedy]

On 2/24/2015 9:02 PM, Eric V. Smith wrote:


I'm not sure if it's correct, but deep in a library of mine I have:

elif type(fn) == types.MethodType:
 # bound method?
 if fn.im_self is None:
# no 'self'
 nskip = 0
 else:
# need to supply 'self'
 nskip = 1

This is also a 2.x library. No idea if it works with 3.x.


It will not.  3.x does not have 'unbound methods' in the above sense, 
and for bound methods, fn.im_self is now fn.__self__.


--
Terry Jan Reedy

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

Re: [Python-Dev] how to inspect if something includes a bound first param

[Terry Reedy]

On 2/24/2015 8:56 PM, Gregory P. Smith wrote:

inspect.getargspec(method) and inspect.signature(method) both include
the 'self' parameter but how are we to figure out from method itself
that it is actually bound and that its first parameter is expected to be
a bound instance?


This seems like a python-list question.


So far I've come up with:
/inspect.ismethod(method) or inspect.ismethoddescriptor(method)/

But that is still not quite right as it remains False in 3.4 for the
simple case of:

 >>> class A:
...  def x(self):
...pass
...
 >>> inspect.ismethod(A.x)
False
 >>> inspect.ismethoddescriptor(A.x)
False


These are correct.  A.x is the function resulting from execution of the 
def statement.


>>> type(A.x)


This is different from 2.x.  If you call the function as a function, 
there is no requirement on its argument, and no binding.


>>> A.x(3)  # returns None
>>>

--
Terry Jan Reedy

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

Re: [Python-Dev] how to inspect if something includes a bound first param

[Eric V. Smith]

On 2/24/2015 8:56 PM, Gregory P. Smith wrote:
> inspect.getargspec(method) and inspect.signature(method) both include
> the 'self' parameter but how are we to figure out from method itself
> that it is actually bound and that its first parameter is expected to be
> a bound instance?
> 
> So far I've come up with:
>  /inspect.ismethod(method) or inspect.ismethoddescriptor(method)/
> 
> But that is still not quite right as it remains False in 3.4 for the
> simple case of:
> 
 class A:
> ...  def x(self):
> ...pass
> ...
 inspect.ismethod(A.x)
> False
 inspect.ismethoddescriptor(A.x)
> False
 inspect.signature(A.x).parameters
> mappingproxy(OrderedDict([('self', )]))
 inspect.getargspec(A.x)
> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None)
> 
> The above works if use it on object.__init__, but not on a method of an
> uninstantiated class.  (it also works on the instantiated A().x)
> 
> Checking if /(inspect.isfunction(method) and method.__qualname__ !=
> method.__name__)/ perhaps but that seems questionably hacky. Is there a
> right way to do this via the inspect module that I've missed?
> 
> It seems like that'd be nice, but I don't feel like I know enough to
> write up a feature request for it yet.  (granted I hope nobody /wants/
> to write code that does this...)

I'm not sure if it's correct, but deep in a library of mine I have:

elif type(fn) == types.MethodType:
# bound method?
if fn.im_self is None:
# no 'self'
nskip = 0
else:
# need to supply 'self'
nskip = 1

This is also a 2.x library. No idea if it works with 3.x.

Eric.





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

[Python-Dev] how to inspect if something includes a bound first param

[Gregory P. Smith]

inspect.getargspec(method) and inspect.signature(method) both include the
'self' parameter but how are we to figure out from method itself that it is
actually bound and that its first parameter is expected to be a bound
instance?

So far I've come up with:
 *inspect.ismethod(method) or inspect.ismethoddescriptor(method)*

But that is still not quite right as it remains False in 3.4 for the simple
case of:

>>> class A:
...  def x(self):
...pass
...
>>> inspect.ismethod(A.x)
False
>>> inspect.ismethoddescriptor(A.x)
False
>>> inspect.signature(A.x).parameters
mappingproxy(OrderedDict([('self', )]))
>>> inspect.getargspec(A.x)
ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None)

The above works if use it on object.__init__, but not on a method of an
uninstantiated class.  (it also works on the instantiated A().x)

Checking if *(inspect.isfunction(method) and method.__qualname__ !=
method.__name__)* perhaps but that seems questionably hacky. Is there a
right way to do this via the inspect module that I've missed?

It seems like that'd be nice, but I don't feel like I know enough to write
up a feature request for it yet.  (granted I hope nobody *wants* to write
code that does this...)

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

Re: [Python-Dev] ?s re documentation of Python features

[Ryan Gonzalez]

Ask on python-list .
Also check out the FAQ  and the Help
page . Not sure what your problem is;
Python is EXTREMELY well documented.

On Tue, Feb 24, 2015 at 7:15 PM, GARRY M CRANE  wrote:

> I am trying to learn Python for use in computational biology.  I am using
> the interesting book: "*Computing for Biologists; Python Programming and
> Principles*" (by Ran Libeskind-Hadas and Eliot Bush).  It has an
> interesting and useful set of programming exercises at www.cs.hmc.edu/CFB.
> I am actually enjoying solving (doing) the example problems.  However, I
> find some of the instructions non-functional for me.  For example the *import
> *function does not work,  nor *f=open("filename.txt")*.  I have saved
> files per instructions in the programming exercise inside the Python34
> folder (I am using Python 3.4 in Windows 7).  But use of the *f=open()*
> command produces an error message that the requested file does not exist. I
> assume I have chosen a wrong location for the saved file within that
> Python34 folder, but trial and error has not led to a successful use of
> these functions.  *import* simply leaves a blank line .. no suggestion
> about the problem.
>
> Asking questions in Google and Ask about  where to save Python-related
> files that can be used subsequently have not led to answers - just details
> about structuring or formatting things to be written/saved/use of the \n at
> end of each line, etc.  Important details, but of no help.   I am finding
> Python to be very handy at many biologic things such as working with DNA
> strings, etc. but I find the documentation and indexing for finding how to
> use many Python features exasperating.  I am writing to you based on a READ
> ME file in my Python folder - generated when I installed Python.
>
> FYI, I asked a few questions of one of the authors of the interesting book
> - who politely replied he was too busy to answer right now - the book and
> problems were meant for a class ... though neither the book nor problems
> say so.  The professor hopes to get around to issues of use by non-students
> sometime - but not now.
>
> Another feature I have come across so far that does not work is
> importation of *matplotlib*.  I copy computed results (that otherwise
> would go to your plotting routine)  then go to Excel and with manipulation
> produce a usable chart there - but at a cost of time and energy.
>
> Your Python tool has many intriguing features - but some of the most
> basic functions do not work for me (even though many features do, e.g.,
> import random does work).  The failure of these features - so far as I can
> tell - is  because of lack of description (for the general non-expert
> public) about where/how to install various features.  Perhaps I need to
> reinstall from the ground up???  If so, just what should I do?  If there is
> a less drastic solution, can you tell me about it?
>
> Thank you for any help ... and if you could provide me a lead regarding
> WHERE to ask subsequent questions I would be most grateful.  Sometimes,
> Google or Ask or a U Tube tutorial does a good job - but if one does not
> know the 'proper' name or term for something, it often is frustrating or
> impossible to get an answer.  I have not heard about any comprehensive
> handbook for Python34 aimed at one who wants to use Python for creating
> programs (functions) that work - and is not an expert at back-room
> structure of files and folders have I simply missed it?  So far, I have
> not found a local Python expert to ask for help.  I am sure some are in the
> greater Seattle area where I live- but I don't know how to find even one at
> this time.
>
> Garry Crane
> gandkcr...@msn.com
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] ?s re documentation of Python features

[GARRY M CRANE]

I am trying to learn Python for use in computational biology.  I am using the 
interesting book: "Computing for Biologists; Python Programming and Principles" 
(by Ran Libeskind-Hadas and Eliot Bush).  It has an interesting and useful set 
of programming exercises at www.cs.hmc.edu/CFB.  I am actually enjoying solving 
(doing) the example problems.  However, I find some of the instructions 
non-functional for me.  For example the import function does not work,  nor 
f=open("filename.txt").  I have saved files per instructions in the programming 
exercise inside the Python34 folder (I am using Python 3.4 in Windows 7).  But 
use of the f=open() command produces an error message that the requested file 
does not exist. I assume I have chosen a wrong location for the saved file 
within that Python34 folder, but trial and error has not led to a successful 
use of these functions.  import simply leaves a blank line .. no suggestion 
about the problem. 
Asking questions in Google and Ask about  where to save Python-related files 
that can be used subsequently have not led to answers - just details about 
structuring or formatting things to be written/saved/use of the \n at end of 
each line, etc.  Important details, but of no help.   I am finding Python to be 
very handy at many biologic things such as working with DNA strings, etc. but I 
find the documentation and indexing for finding how to use many Python features 
exasperating.  I am writing to you based on a READ ME file in my Python folder 
- generated when I installed Python.
 
FYI, I asked a few questions of one of the authors of the interesting book - 
who politely replied he was too busy to answer right now - the book and 
problems were meant for a class ... though neither the book nor problems say 
so.  The professor hopes to get around to issues of use by non-students 
sometime - but not now.
 
Another feature I have come across so far that does not work is importation of 
matplotlib.  I copy computed results (that otherwise would go to your plotting 
routine)  then go to Excel and with manipulation produce a usable chart there - 
but at a cost of time and energy.
 
Your Python tool has many intriguing features - but some of the most basic 
functions do not work for me (even though many features do, e.g., import random 
does work).  The failure of these features - so far as I can tell - is  because 
of lack of description (for the general non-expert public) about where/how to 
install various features.  Perhaps I need to reinstall from the ground up???  
If so, just what should I do?  If there is a less drastic solution, can you 
tell me about it?
 
Thank you for any help ... and if you could provide me a lead regarding WHERE 
to ask subsequent questions I would be most grateful.  Sometimes, Google or Ask 
or a U Tube tutorial does a good job - but if one does not know the 'proper' 
name or term for something, it often is frustrating or impossible to get an 
answer.  I have not heard about any comprehensive handbook for Python34 aimed 
at one who wants to use Python for creating programs (functions) that work - 
and is not an expert at back-room structure of files and folders have I 
simply missed it?  So far, I have not found a local Python expert to ask for 
help.  I am sure some are in the greater Seattle area where I live- but I don't 
know how to find even one at this time.
 
Garry Crane
gandkcr...@msn.com
  ___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] easy_install ?

[Daniel Holth]

The other option might be to use http://bitbucket.org/dholth/setup-requires

It uses pip to install requirements into an isolated directory before
setup.py runs, with pip, doing exactly what you requested.
On Feb 24, 2015 5:44 PM, "Nick Coghlan"  wrote:

>
> On 25 Feb 2015 07:23, "Alexander Belopolsky" <
> alexander.belopol...@gmail.com> wrote:
> >
> >
> > On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth  wrote:
> > >
> > > > Is there a recommended way to invoke pip from setup.py?  When I
> specify
> > > > "tests_require=" and run "python setup.py test", the requirements get
> > > > installed using setuptools' easy_install function.
> > >
> > > The solution is to not do that. A substitute is to specify your test
> > > requirements in a [test] extra and install them with pip or to run
> > > tests with tox. This gives control of the installer back to the user
> > > instead of the setup.py author.
> >
> >
> > Isn't this a chicken and egg problem?  I currently have
> >
> > tests_require=['tox'],
> >
> > and this is exactly what tox recommends:
> >
> >
> https://testrun.org/tox/latest/example/basic.html#integration-with-setuptools-distribute-test-commands
> >
> >
> > Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6.
> This is still a very common server configuration.  What is the recommended
> way to bootstrap tox in such environment?
>
> If running in the system Python isn't absolutely essential, then the
> Python 2.7 collection from softwarecollections.org is the preferred way
> to get a newer Python 2 (including pip et al) on CentOS. You can also get
> access to Python 3 that way.
>
> Failing that, pip & virtualenv are also available from the EPEL 6 repos.
>
> Both of those approaches rely on the system package manager to do the
> bootstrapping of the Python specific tooling.
>
> If both softwarecollections.org and EPEL are considered unacceptable
> dependencies, then you're going to have to do your own bootstrapping for
> PyPI access on CentOS (which may include relying on easy_install to
> bootstrap pip and/or virtualenv)
>
> Regards,
> Nick.
>
> >
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
> >
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] getstatusoutput()'s behavior changed in 3.3.4 and 3.4

[Victor Stinner]

Hi,

It looks like new tests are required to check that the behaviour will not
change again.

Victor

Le mardi 24 février 2015, Gregory P. Smith  a écrit :

> While porting some code from 2.7 to 3.4 I discovered that
> command.getstatusoutput() (renamed to subprocess.getstatusoutput() in 3.x)
> had changed. Surprise!
>
> The code was working under an earlier version of 3.3 but broke when I ran
> it on 3.4.  Nowhere was this documented that I could find. Tracking down
> what changed, I discovered it was unintentional due to the meaning of the
> returned status int never being tested. http://bugs.python.org/issue23508
> filed...
>
> Given it has shipped in several stable 3.x releases and as part of some
> major Linux distros, reverting the behavior change seems wrong. The new
> behavior is nicer and more consistent with the rest of the subprocess
> module. I suggest just documenting it and moving on. It seems too late to
> fix this mistake without causing additional headaches. Anyone disagree?
>
> -gps
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Guido van Rossum]

Maybe just fail if the target name already exists?

On Tue, Feb 24, 2015 at 12:51 PM, Paul Moore  wrote:

> On 24 February 2015 at 20:32, Barry Warsaw  wrote:
> >>To modify an archive could be done using
> >>
> >>python -m zipapp old.pyz new.pyz [-p interpreter]
> >>
> >>Default is to strip the shebang (no -p option). There's no option to
> >>omit the target and do an inplace update because I feel the default
> >>action (strip the shebang from the existing file with no backup) is
> >>too dangerous.
> >
> > You have to be careful about the case where old.pyz == new.pyz (e.g.
> either
> > handling this case safely or complaining loudly) , but also you could
> handle
> > it by using a .tmp file and renaming.  E.g. old.pyz -> old.pyz.bak and
> > old.pyz.tmp -> old.pyz.
>
> There are a *lot* of obscure failure modes here. What if old and new
> are symlinks (or hard links) to the same file? What if a .tmp file
> already exists? What if the user hits Ctrl-C at a bad moment?
>
> On the principle of keeping it simple, I prefer just requiring a
> target, giving an error if the source name and target name are the
> same (which still leaves loopholes for the determined fool on case
> insensitive filesystems :-)) and just documenting that inplace
> modification isn't supported. The PEP clearly states that it's
> *minimal* tooling, after all...
>
> >
> >>3. What to call the "show the shebang line" option
> >
> > I don't know how useful this is, given that (on *nix at least) you can
> > effectively do the same with head(1).
>
> I don't think it's that useful, TBH (although will head not print
> binary junk if there is no shebang line?) I quite like Brett's
> suggestion of --info, and maybe be a bit verbose:
>
> $ python -m zipapp foo.pyz --info
> Interpreter: /usr/bin/python
> $ python -m zipapp bar.pyz --info
> Interpreter: 
>
> I can't see it being useful for scripting, and if it matters, there's
> always get_interpreter() then. It's mainly just as a diagnostic for
> people who are getting the wrong interpreter invoked.
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Nick Coghlan]

On 25 Feb 2015 06:52, "Paul Moore"  wrote:
>
> On 24 February 2015 at 20:32, Barry Warsaw  wrote:
> >>To modify an archive could be done using
> >>
> >>python -m zipapp old.pyz new.pyz [-p interpreter]
> >>
> >>Default is to strip the shebang (no -p option). There's no option to
> >>omit the target and do an inplace update because I feel the default
> >>action (strip the shebang from the existing file with no backup) is
> >>too dangerous.
> >
> > You have to be careful about the case where old.pyz == new.pyz (e.g.
either
> > handling this case safely or complaining loudly) , but also you could
handle
> > it by using a .tmp file and renaming.  E.g. old.pyz -> old.pyz.bak and
> > old.pyz.tmp -> old.pyz.
>
> There are a *lot* of obscure failure modes here. What if old and new
> are symlinks (or hard links) to the same file? What if a .tmp file
> already exists? What if the user hits Ctrl-C at a bad moment?
>
> On the principle of keeping it simple, I prefer just requiring a
> target, giving an error if the source name and target name are the
> same (which still leaves loopholes for the determined fool on case
> insensitive filesystems :-)) and just documenting that inplace
> modification isn't supported. The PEP clearly states that it's
> *minimal* tooling, after all...

https://docs.python.org/3/library/os.path.html#os.path.samefile covers this
check in a robust, cross-platform way.

> >>3. What to call the "show the shebang line" option
> >
> > I don't know how useful this is, given that (on *nix at least) you can
> > effectively do the same with head(1).
>
> I don't think it's that useful, TBH (although will head not print
> binary junk if there is no shebang line?) I quite like Brett's
> suggestion of --info, and maybe be a bit verbose:
>
> $ python -m zipapp foo.pyz --info
> Interpreter: /usr/bin/python
> $ python -m zipapp bar.pyz --info
> Interpreter: 
>
> I can't see it being useful for scripting, and if it matters, there's
> always get_interpreter() then. It's mainly just as a diagnostic for
> people who are getting the wrong interpreter invoked.

The corresponding CLI option for the inspect module is "--details":
https://docs.python.org/3/library/inspect.html#command-line-interface

(By default "python -m inspect " prints the module source code)

Cheers,
Nick.

>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Chris Angelico]

On Wed, Feb 25, 2015 at 6:54 AM, Greg Ewing  wrote:
> Chris Angelico wrote:
>>
>> Then he changed the code over to use his
>> own file instead of the provided sample, and at the same time,
>> switched from using open() to using csv.reader(open()), and moved all
>> the code into a function, and fixed three other bugs, and now it isn't
>> working. And he can't figure out why.
>
>
> There's probably a useful meta-lesson in there:
> test after making every change!

Of course! But when you're working with students remotely, you don't
necessarily even know that that's what's happened. All you get is "It
works with sample.txt, but it doesn't work with my file". You may or
may not even get to see the code at first.

Firm believer in "commit often" policy...

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

Re: [Python-Dev] easy_install ?

[Nick Coghlan]

On 25 Feb 2015 07:23, "Alexander Belopolsky" 
wrote:
>
>
> On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth  wrote:
> >
> > > Is there a recommended way to invoke pip from setup.py?  When I
specify
> > > "tests_require=" and run "python setup.py test", the requirements get
> > > installed using setuptools' easy_install function.
> >
> > The solution is to not do that. A substitute is to specify your test
> > requirements in a [test] extra and install them with pip or to run
> > tests with tox. This gives control of the installer back to the user
> > instead of the setup.py author.
>
>
> Isn't this a chicken and egg problem?  I currently have
>
> tests_require=['tox'],
>
> and this is exactly what tox recommends:
>
>
https://testrun.org/tox/latest/example/basic.html#integration-with-setuptools-distribute-test-commands
>
>
> Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6.
This is still a very common server configuration.  What is the recommended
way to bootstrap tox in such environment?

If running in the system Python isn't absolutely essential, then the Python
2.7 collection from softwarecollections.org is the preferred way to get a
newer Python 2 (including pip et al) on CentOS. You can also get access to
Python 3 that way.

Failing that, pip & virtualenv are also available from the EPEL 6 repos.

Both of those approaches rely on the system package manager to do the
bootstrapping of the Python specific tooling.

If both softwarecollections.org and EPEL are considered unacceptable
dependencies, then you're going to have to do your own bootstrapping for
PyPI access on CentOS (which may include relying on easy_install to
bootstrap pip and/or virtualenv)

Regards,
Nick.

>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] getstatusoutput()'s behavior changed in 3.3.4 and 3.4

[Nick Coghlan]

Documentation (and adding the missing test) sounds right to me.

We'd at least want a "versionchanged" note on the function itself, and an
entry in the porting section of the (3.3? 3.4?) what's new guide.

Is there anywhere else we might want to mention it?

Regards,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Ethan Furman]

On 02/24/2015 01:35 PM, Guido van Rossum wrote:

> Actually, I wasn't proposing to change repr() -- my sentiments are similar
> to Isaac Morland's. Only the error message for the most basic file open()
> call should be tweaked.

As are mine -- I just like to be thorough when discussing possibilities.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Paul Moore]

On 24 February 2015 at 21:09, Ethan Furman  wrote:
> Another way to support this is with subcommands.  Have the default [implicit] 
> command be to create the zip app, and then
> add any subcommands we need:
>
>   python -m zipapp [create] foo   #creates a foo.pyz from the foo directory
>
>   python -m zipapp info foo.pyz   # prints out shebang for foo.pyz
>
>   python -m zipapp info --all foo.pyz  # prints out shebang and directory 
> structure and files and 
>
> This easily leaves the door open to add new commands in the future if any are 
> still needed, and makes the current
> commands easy and simple to use.

I didn't know an implicit subcommand was allowed. That would work,
although it does mean that you can't build a pyz from a directory
"info" without explicitly using the create subcommand.

I think I'm going to go with "python -m zipapp foo.pyz --info" (And an
-o option for the target, mandatory when the source is a pyz file, and
--python for the interpreter). It's not set in stone yet, so if anyone
objects, there's still time to change my mind.

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

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Guido van Rossum]

[Adding back python-dev]

Actually, I wasn't proposing to change repr() -- my sentiments are similar
to Isaac Morland's. Only the error message for the most basic file open()
call should be tweaked.

No solution is perfect -- but it's probably common enough for someone to
create a file or folder named C:\test and being stumped by "cannot open
'C:\test'."

On Tue, Feb 24, 2015 at 1:25 PM, Glenn Linderman 
wrote:

>  On 2/24/2015 10:49 AM, Guido van Rossum wrote:
>
> I like the \x07 solution.
>
>
> The more I think about it, the more I think this is a sufficient
> solution.  People that use repr to get a Python-compatible string syntax
> for further program use get one. People that see them in an error message
> are much less likely to be fooled into thinking it is two characters,
> because they are thinking of it as two characters to start with.
>
> On the other hand, I have a directory full of "throw away" experimental
> source files named  x01, x02, x03, ...  :)
>
> And I suppose extensive use of certain characters in repr in intermediate
> or archived data could make such data grow in size.
>
> And while \t and \n are very commonly used escapes, maybe string repr
> could have a special function called
> .I_promise_not_to_report_issues_when_I_use_backslash_escapes_in_character_literals_and_get_confused()
> which would switch back from \x07 to \t and \x0a to \n, etc.  This would be
> callable only from __main__ :)
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] easy_install ?

[Alexander Belopolsky]

On Tue, Feb 24, 2015 at 4:24 PM, Daniel Holth  wrote:
>
> That might mostly do what you want, since tox could install any
> additional test requirements based on its configuration.


Does "that" refer to using tests_require=['tox'] as I described below? This
means using easy_install implicitly and being exposed to easy_install
bugs.  Note that my attempts to avoid easy_install so far led to dependency
hell starting from the need to install virtualenv.  Unlike setuptools, pip
does not seem to be able to install dependencies in a temporary directory.
It wants a full-blown venv tree.

>
>
> On Tue, Feb 24, 2015 at 4:21 PM, Alexander Belopolsky
>  wrote:
> >
> > On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth  wrote:
> >>
> >> > Is there a recommended way to invoke pip from setup.py?  When I
specify
> >> > "tests_require=" and run "python setup.py test", the requirements get
> >> > installed using setuptools' easy_install function.
> >>
> >> The solution is to not do that. A substitute is to specify your test
> >> requirements in a [test] extra and install them with pip or to run
> >> tests with tox. This gives control of the installer back to the user
> >> instead of the setup.py author.
> >
> >
> > Isn't this a chicken and egg problem?  I currently have
> >
> > tests_require=['tox'],
> >
> > and this is exactly what tox recommends:
> >
> >
https://testrun.org/tox/latest/example/basic.html#integration-with-setuptools-distribute-test-commands
> >
> >
> > Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6.
This
> > is still a very common server configuration.  What is the recommended
way to
> > bootstrap tox in such environment?
> >
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] easy_install ?

[Daniel Holth]

That might mostly do what you want, since tox could install any
additional test requirements based on its configuration.

On Tue, Feb 24, 2015 at 4:21 PM, Alexander Belopolsky
 wrote:
>
> On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth  wrote:
>>
>> > Is there a recommended way to invoke pip from setup.py?  When I specify
>> > "tests_require=" and run "python setup.py test", the requirements get
>> > installed using setuptools' easy_install function.
>>
>> The solution is to not do that. A substitute is to specify your test
>> requirements in a [test] extra and install them with pip or to run
>> tests with tox. This gives control of the installer back to the user
>> instead of the setup.py author.
>
>
> Isn't this a chicken and egg problem?  I currently have
>
> tests_require=['tox'],
>
> and this is exactly what tox recommends:
>
> https://testrun.org/tox/latest/example/basic.html#integration-with-setuptools-distribute-test-commands
>
>
> Note that my CI box is a CentOS 6.5 with Python 2.6.6, setuptools 0.6.  This
> is still a very common server configuration.  What is the recommended way to
> bootstrap tox in such environment?
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Isaac Morland]

On Tue, 24 Feb 2015, Ethan Furman wrote:


On 02/24/2015 10:49 AM, Guido van Rossum wrote:

On Tue, Feb 24, 2015 at 10:47 AM, Ethan Furman wrote:


I can attest from my impoverished Windows programming days that looking at

  --> os.listdir('c:\temp')
  SomeErrorMessage about syntax 'c:\temp'

is not very helpful.  There is zero visual indication that the \ and the t
are one character, not two.  Changing that error message to:

  SomeErrorMessage about syntax 'c:[\t]emp'

or

  SomeErrorMessage about syntax 'c:\x07emp'

or something that shouts out, "hey!  one character in this 
location!" would be a good thing.


I like the \x07 solution.


So final question is do we take the easy road and change the repr for 
str to always use hex or unicode escapes instead of simple 
backslash-escapes (and then run for our lives), or do we just hunt down 
and change the appropriate error messages for files (and possibly re) ?


Just a data point from a random programmer:

I like the \x07 solution for the error message as it draws attention to 
the character at issue, but I also like to see \n, \t etc. in the result 
of repr because it is more readable for the common cases.


Isaac Morland   CSCF Web Guru
DC 2619, x36650 WWW Software Specialist
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Ethan Furman]

On 02/24/2015 01:00 PM, Ethan Furman wrote:
> On 02/24/2015 12:51 PM, Paul Moore wrote:

>> $ python -m zipapp foo.pyz --info
>> Interpreter: /usr/bin/python
>> $ python -m zipapp bar.pyz --info
>> Interpreter: 

Another way to support this is with subcommands.  Have the default [implicit] 
command be to create the zip app, and then
add any subcommands we need:

  python -m zipapp [create] foo   #creates a foo.pyz from the foo directory

  python -m zipapp info foo.pyz   # prints out shebang for foo.pyz

  python -m zipapp info --all foo.pyz  # prints out shebang and directory 
structure and files and 

This easily leaves the door open to add new commands in the future if any are 
still needed, and makes the current
commands easy and simple to use.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Brett Cannon]

On Tue Feb 24 2015 at 3:21:30 PM Paul Moore  wrote:

> On 24 February 2015 at 18:58, Guido van Rossum  wrote:
> > Why no command-line equivalent for the other two methods?  I propose the
> > following interface: if there's only one positional argument, we're
> asking
> > to print its shebang line; if there are two and the input position is an
> > archive instead of a directory, we're copying.  (In the future people
> will
> > want an option to print more stuff, e.g. the main function or even a full
> > listing.)
>
> Thinking about this, there are 3 main uses:
>
> 1. Create an archive
> 2. Print the shebang
> 3. Change the shebang
>
> Of these, (1) is the crucial one.
>
> Basic usage should be
>
> python -m zipapp mydir [-o anothername.pyz] [-p interpreter] [-m
> entry:point]
>
> This zips up mydir to create an archive mydir.pyz. Options to change
> the target name, set a shebang line (side note: --python/-p or
> --interpreter/-i?) and set the entry point,
>
> I see this as pretty non-negotiable, this is the key use case that
> needs to be as simple as possible.
>
> To print the shebang, we could use
>
> python -m zipapp myapp.pyz --show
>
> This allows for future expansion by adding options, although most
> other things you might want to do (list the files, display
> __main__.py) can be done with a standard zip utility. I'm not keen on
> the option name --show, but I can't think of anything substantially
> better.
>
> To modify an archive could be done using
>
> python -m zipapp old.pyz new.pyz [-p interpreter]
>
> Default is to strip the shebang (no -p option). There's no option to
> omit the target and do an inplace update because I feel the default
> action (strip the shebang from the existing file with no backup) is
> too dangerous.
>
> To be explicit, "python -m zipapp app.pyz" will fail with a message
> "In-place editing of python zip applications is not supported".
>
> That seems to work.
>
> Open questions:
>
> 1. To create an archive, use -o target for an explicit target name, or
> just "target". The former is more conventional, the latter consistent
> with modification. Or we could make modification use a (mandatory) -o
> option.
>

EIBTI suggests requiring the -o. Pragmatic suggests just [in] [out] and use
context based on what kind of thing [in] points at as well as whether -p is
specified and whether it has an argument, which is the most minimal UX you
can have. Question is whether you can screw up by specifying the wrong
thing somehow (you might have to require that [out] doesn't already exist
to make it work).


> 2. -p/--python or -i/--interpreter for the shebang setting option
>

Since you are going to be using `python -m pyzip` then -i/--interpreter is
less redundant-looking on the command-line.


> 3. What to call the "show the shebang line" option


As suggested above, -p w/o an argument could do it, otherwise --show or
--info seems fine (I like --shebang, but that will probably be tough on
non-English speakers).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Barry Warsaw]

On Feb 24, 2015, at 08:20 PM, Paul Moore wrote:

>(side note: --python/-p or --interpreter/-i?) and set the entry point,

Both virtualenv and (I think) pex use --python/-p so that seems to be the
overwhelming trend .

>To modify an archive could be done using
>
>python -m zipapp old.pyz new.pyz [-p interpreter]
>
>Default is to strip the shebang (no -p option). There's no option to
>omit the target and do an inplace update because I feel the default
>action (strip the shebang from the existing file with no backup) is
>too dangerous.

You have to be careful about the case where old.pyz == new.pyz (e.g. either
handling this case safely or complaining loudly) , but also you could handle
it by using a .tmp file and renaming.  E.g. old.pyz -> old.pyz.bak and
old.pyz.tmp -> old.pyz.

>3. What to call the "show the shebang line" option

I don't know how useful this is, given that (on *nix at least) you can
effectively do the same with head(1).

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Terry Reedy]

On 2/24/2015 1:14 PM, Guido van Rossum wrote:


And I'd weigh the needs of users who know what they are doing somewhat
higher than educating newbies through error messages. While newbies are
most likely to try out open() with a string literal, in "real" programs
that is rare, and filenames are typically taken from the command line or
from some other source where the peculiarities of Python string literals
are irrelevant.


I have been thinking about proposing a new how-to: Understanding Error 
Messages, with a section on tracebacks followed by an alphabetical 
listing of Exceptions that gives people problems, with possible 
solutions for each.  The following begins my first draft.


FileNotFoundError:

Possible cause [Windows]: You used a normal string literal to create a 
filename, you used '\' as the path separator, and you forgot that Python 
(like most languages) treats '\' as a case-sensitive escape character. 
For example: "C:\Test" is 7 chars and works as a file name, while 
'C:\test' is 6 chars, one a literal tab character.  The latter does not 
work as a file name and will raise FileNotFoundError.


Possible solutions: 1. Use raw string literals for Windows path names 
(r'C:\test'). 2 (recommended). Use '/' as the path separator 
('C:/test'), just as one does on other systems. This always works when 
passing file names from Python to Windows, even though it sometimes does 
not work in Windows Command Prompt console.



--
Terry Jan Reedy

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

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Greg Ewing]

Thomas Wouters wrote:
Trying to make the 
error messages more similar, or more identifying, may be a good idea (as 
long as they aren't misleading when people *meant* to use escape 
sequences in a string)


It seems that Windows won't let you use control
characters in filenames, so there is room for a
more pointed error message from functions that
take pathnames on Windows.

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

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Greg Ewing]

Chris Angelico wrote:

Then he changed the code over to use his
own file instead of the provided sample, and at the same time,
switched from using open() to using csv.reader(open()), and moved all
the code into a function, and fixed three other bugs, and now it isn't
working. And he can't figure out why.


There's probably a useful meta-lesson in there:
test after making every change!

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

[Python-Dev] getstatusoutput()'s behavior changed in 3.3.4 and 3.4

[Gregory P. Smith]

While porting some code from 2.7 to 3.4 I discovered that
command.getstatusoutput() (renamed to subprocess.getstatusoutput() in 3.x)
had changed. Surprise!

The code was working under an earlier version of 3.3 but broke when I ran
it on 3.4.  Nowhere was this documented that I could find. Tracking down
what changed, I discovered it was unintentional due to the meaning of the
returned status int never being tested. http://bugs.python.org/issue23508
filed...

Given it has shipped in several stable 3.x releases and as part of some
major Linux distros, reverting the behavior change seems wrong. The new
behavior is nicer and more consistent with the rest of the subprocess
module. I suggest just documenting it and moving on. It seems too late to
fix this mistake without causing additional headaches. Anyone disagree?

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

Re: [Python-Dev] str(IntEnum)

[Demian Brecht]

> On Feb 24, 2015, at 10:56 AM, Guido van Rossum  wrote:
> It sure seems that way.

Thanks for the additional feedback Guido. I’d spent some further time thinking 
about what it was that I was looking for and determined it was bollocks. The 
proposal was a poor solution to a specific immediate problem without taking 
more general use cases into account. My apologies for the noise.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Guido van Rossum]

[Sorry, accidentally dropped the list from this message.]

Here's my review. I really like where this is going but I have a few
questions and suggestions (I can't help myself :-).

[I sneaked a peek at the update you sent to p...@python.org.]

"Currently, pyyzer [5] and pex [6] are two tools known to exist." -> "...
are two such tools."

It's not stated whether the archive names include the .pyz[w] extension or
not (though I'm guessing it's not -- this should be stated).

The naming of the functions feels inconsistent -- maybe pack(directory,
target) -> create_archive(directory, archive), and set_interpreter() ->
copy_archive(archive, new_archive)?

Why no command-line equivalent for the other two methods?  I propose the
following interface: if there's only one positional argument, we're asking
to print its shebang line; if there are two and the input position is an
archive instead of a directory, we're copying.  (In the future people will
want an option to print more stuff, e.g. the main function or even a full
listing.)

I've not seen the pkg.mod:fn notation before.  Where is this taken from?
Why can't it be pkg.mod.fn?

I'd specify that when the output argument is a file open for writing, it is
the caller's responsibility to close the file.  Also, can the file be a
pipe?  (I.e. are we using seek()/tell() or not?)  And what about the input
archive?  Can that be a file open for reading?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] easy_install ?

[Daniel Holth]

On Tue, Feb 24, 2015 at 1:31 PM, Alexander Belopolsky
 wrote:
>
> On Tue, Feb 24, 2015 at 11:44 AM, Paul Moore  wrote:
>>
>> And if pip won't work, it would be good to
>> know why.
>
>
> Is there a recommended way to invoke pip from setup.py?  When I specify
> "tests_require=" and run "python setup.py test", the requirements get
> installed using setuptools' easy_install function.

The solution is to not do that. A substitute is to specify your test
requirements in a [test] extra and install them with pip or to run
tests with tox. This gives control of the installer back to the user
instead of the setup.py author.

https://pythonhosted.org/setuptools/setuptools.html#declaring-extras-optional-features-with-their-
own-dependencies
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Guido van Rossum]

On Tue, Feb 24, 2015 at 10:50 AM, Paul Moore  wrote:

> On 24 February 2015 at 18:24, Guido van Rossum  wrote:
> > Here's my review. I really like where this is going but I have a few
> > questions and suggestions (I can't help myself :-).
>
> Thanks.
>
> > [I sneaked a peek at the update you sent to p...@python.org.]
> >
> > "Currently, pyyzer [5] and pex [6] are two tools known to exist." -> "...
> > are two such tools."
> >
> > It's not stated whether the archive names include the .pyz[w] extension
> or
> > not (though I'm guessing it's not -- this should be stated).
>
> No, I assumed that automatically adding extensions is not the norm. A
> lot of Windows tools do it, but I don't get the impression Unix tools
> do. I'll clarify the wording.
>
> > The naming of the functions feels inconsistent -- maybe pack(directory,
> > target) -> create_archive(directory, archive), and set_interpreter() ->
> > copy_archive(archive, new_archive)?
>
> I'm OK with create_archive. But not so sure about copy_archive - the
> purpose of that function is solely to change the shebang line on an
> existing archive. It does so by copying, sure, but that's incidental.
> I see get_interpreter/set_interpreter as complementary "helper" APIs,
> and create_archive as the main API.
>

To me, the name set_() so strongly evokes the idea of in-place
modification that I cannot live with it. (I also assume that your code
won't do the right thing if the output is the same as the input, right?)


> > Why no command-line equivalent for the other two methods?  I propose the
> > following interface: if there's only one positional argument, we're
> asking
> > to print its shebang line; if there are two and the input position is an
> > archive instead of a directory, we're copying.  (In the future people
> will
> > want an option to print more stuff, e.g. the main function or even a full
> > listing.)
>
> Mainly because I couldn't think of an API that didn't look muddled, or
> make the simple case of "I want to pack up a directory" look messy.
> But I'll think about your proposal - it sounds nice, I'll see how it
> fares when I try to implement it :-)
>
> > I've not seen the pkg.mod:fn notation before.  Where is this taken from?
> > Why can't it be pkg.mod.fn?
>
> It's common usage in setuptools and things like tat - it's the "entry
> point" syntax used in packaging. I don't know of any reason why
> all-dotted notation wouldn't work, though. I'll ask around if there's
> any reason I'm not aware of.
>

OK, no need to change this then.


> > I'd specify that when the output argument is a file open for writing, it
> is
> > the caller's responsibility to close the file.  Also, can the file be a
> > pipe?  (I.e. are we using seek()/tell() or not?)  And what about the
> input
> > archive?  Can that be a file open for reading?
>
> I'll clarify all of these points. They are mostly "it can be whatever
> the zipfile module accepts", though, which isn't explicitly stated
> itself :-(
>
> The input can't be a file object for pack/create_archive because it's
> a directory, not an archive, there. But it could be for
> set_interpreter. I just wasn't sure if it was worth adding. It's not
> hard to do, though.


I'm not sure what use case this is addressing anyway, but assuming there is
one, you might as well go all the way (except for directories, obviously).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str(IntEnum)

[Guido van Rossum]

On Sat, Feb 21, 2015 at 8:39 AM, Demian Brecht 
wrote:

> >
> > On Feb 20, 2015, at 7:03 PM, Ian Cordasco 
> wrote:
> > I hope this helps.
>
> It does, as do the other replies, thanks all. To be clear, my first gripe
> has stemmed into two related (but very minor) problems:
>
> 1. IntEnum.__str__. I understand the reasoning behind the current
> implementation. Personally I’d still prefer it to be consistent with int
> (and other types as shown above) and if I wanted to know where it came
> from, I could use repr(), but I understand that this /was/ previously
> thought out and is contrary to the decision made. I’m fine with being in
> the minority (or on my own as it seems in this case) and leaving it alone
> (with the only caveat being the next point).
>

You are indeed very much out of sync here. There is no requirement or even
convention that int subclasses have the same str() as plain ints -- in fact
a custom str() is a common reason. For example, it's one of the reasons why
I eventually caved in and added bool to the language. People want the
custom representation used when they say print(x), they don't want to have
to say print(repr(x)).


> 2. Consistency of __str__ semantics across the standard library and
> builtins. I believe that the value of __str__ is something that I, as a
> user, should be able to infer when using disparate types. Unfortunately,
> some represent the values while other represent the object themselves,
> nearly the same problem that __repr__ solves minus the requirement of being
> a valid Python expression where possible. In my mind, a clear separation
> between __str__ representing the value of an instance and __repr__
> representing the object, or where the value came from (and perhaps /not/
> having the auto-fallback) makes sense, but would only be one potential
> solution to promoting consistency.
>

Again, this is an area where you are on your own looking for consistency.
str() is what print() uses (by mutual definition) and print() should print
whatever is the most useful as the default for a given use case. There is
*no* rule that says a subclass cannot change the str().


> In any event, there are many larger problems to be solved (that is, if
> anyone else /does/ consider this a problem) and I very well may be on my
> own with this thinking.
>

It sure seems that way.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Ethan Furman]

On 02/24/2015 10:14 AM, Guido van Rossum wrote:

> This is about messages from failing file-open operations if the filename 
> contains an escaped character? I'd go slow
> there too: here are a lot of places where files are opened and messages are 
> printed, both in the C code and in the
> stdlib. I'm not sure I buy the argument that just echoing the repr() of the 
> name back doesn't help -- the escapes in
> there are actually useful in case a filename containing garbage chars (or 
> even a trailing space) was read from some
> other source.

I can attest from my impoverished Windows programming days that looking at

  --> os.listdir('c:\temp')
  SomeErrorMessage about syntax 'c:\temp'

is not very helpful.  There is zero visual indication that the \ and the t are 
one character, not two.  Changing that
error message to:

  SomeErrorMessage about syntax 'c:[\t]emp'

or

  SomeErrorMessage about syntax 'c:\x07emp'

or something that shouts out, "hey!  one character in this location!" would be 
a good thing.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Guido van Rossum]

I like the \x07 solution.

On Tue, Feb 24, 2015 at 10:47 AM, Ethan Furman  wrote:

> On 02/24/2015 10:14 AM, Guido van Rossum wrote:
>
> > This is about messages from failing file-open operations if the filename
> contains an escaped character? I'd go slow
> > there too: here are a lot of places where files are opened and messages
> are printed, both in the C code and in the
> > stdlib. I'm not sure I buy the argument that just echoing the repr() of
> the name back doesn't help -- the escapes in
> > there are actually useful in case a filename containing garbage chars
> (or even a trailing space) was read from some
> > other source.
>
> I can attest from my impoverished Windows programming days that looking at
>
>   --> os.listdir('c:\temp')
>   SomeErrorMessage about syntax 'c:\temp'
>
> is not very helpful.  There is zero visual indication that the \ and the t
> are one character, not two.  Changing that
> error message to:
>
>   SomeErrorMessage about syntax 'c:[\t]emp'
>
> or
>
>   SomeErrorMessage about syntax 'c:\x07emp'
>
> or something that shouts out, "hey!  one character in this location!"
> would be a good thing.
>
> --
> ~Ethan~
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Guido van Rossum]

On Tue, Feb 24, 2015 at 10:00 AM, Ethan Furman  wrote:

> On 02/24/2015 09:44 AM, Guido van Rossum wrote:
> >
> > TBH I think this will be a tough sell. I worry that an meme will emerge
> to make all
> > string literals use raw mode, or worse, to deprecate non-raw string
> literals. I'm
> > not sure how we'll get out of the whole conundrum, and I'm not in a
> hurry to see
> > this in 3.5.
>
> So should we move forward with just the better error messages?  It's a
> good first step, and even if it ends up being the
> only step it would be a huge improvement.
>

This is about messages from failing file-open operations if the filename
contains an escaped character? I'd go slow there too: here are a lot of
places where files are opened and messages are printed, both in the C code
and in the stdlib. I'm not sure I buy the argument that just echoing the
repr() of the name back doesn't help -- the escapes in there are actually
useful in case a filename containing garbage chars (or even a trailing
space) was read from some other source.

And I'd weigh the needs of users who know what they are doing somewhat
higher than educating newbies through error messages. While newbies are
most likely to try out open() with a string literal, in "real" programs
that is rare, and filenames are typically taken from the command line or
from some other source where the peculiarities of Python string literals
are irrelevant.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Ethan Furman]

On 02/24/2015 09:44 AM, Guido van Rossum wrote:
>
> TBH I think this will be a tough sell. I worry that an meme will emerge to 
> make all
> string literals use raw mode, or worse, to deprecate non-raw string literals. 
> I'm
> not sure how we'll get out of the whole conundrum, and I'm not in a hurry to 
> see
> this in 3.5.

So should we move forward with just the better error messages?  It's a good 
first step, and even if it ends up being the
only step it would be a huge improvement.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Paul Moore]

On 24 February 2015 at 17:46, Guido van Rossum  wrote:
> I can do it but I don't want to be reviewing and accepting a PEP that's
> still under discussion, and I don't have the bandwidth to follow the
> discussion here -- I can only read the PEP. I will start that now.

I'm just about to push an update based on Brett's comments, then it
should be done. Can you hold off for a short while?

Thanks.
Paul.

(Sorry, always the way - final comments appear as soon as you say
"it's done" :-))
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Ethan Furman]

On 02/24/2015 09:18 AM, Thomas Wouters wrote:
> On Tue, Feb 24, 2015 at 5:37 PM, Ethan Furman wrote:
>>
>>  - M.A.Lemburg's idea of changing the exception message in key places to 
>> make a successful
>>backslash replace obvious
>>(FileNotFoundError: [Errno 2] No such file or directory: 'c:[\t]est.txt' 
>> - warning: embedded escapes)
> 
> Any ideas on how this check could be implemented? How would it distinguish \t
> from an actual tab in the string literal, or "C:\x64-python" from 
> "C:\d-python"...?

--> 'a  tab'
'a\ttab'
--> 'a\ttab'
'a\ttab'

So the phrase "embedded escapes" may not always be accurate, but will be 
something to search on, and will help explain
what is being seen.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Guido van Rossum]

TBH I think this will be a tough sell. I worry that an meme will emerge to
make all string literals use raw mode, or worse, to deprecate non-raw
string literals. I'm not sure how we'll get out of the whole conundrum, and
I'm not in a hurry to see this in 3.5.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] easy_install ?

[Laura Creighton]

In a message of Tue, 24 Feb 2015 16:44:20 +, Paul Moore writes:
>On 24 February 2015 at 16:30, Brett Cannon  wrote:
>> Tell people to use pip. Having ensurepip in Python 2.7 and 3.4 makes it as
>> official as anything will be as the recommended tool to install projects.
>> Otherwise easy_install has nothing to do directly with python-dev so I don't
>> think we can comment on a group as to what people should do in terms of
>> bugs, etc.
>
>Bug reports would go to the setuptools project, but I agree, "use pip"
>is a better suggestion. And if pip won't work, it would be good to
>know why.
>
>Paul

I want to recommend that people not use easy_install.  This has
been my personal preferred solution for many years now.  But I did
not want to say such a thing if there was a known use case, one that
I never have, that made easy_install better.

Ok. will go back to my personal integrity which matches what python-dev
recommends.  Thank you for answering.

Laura (answering questions in python-list and as webmaster)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] easy_install ?

[Ethan Furman]

On 02/24/2015 08:44 AM, Paul Moore wrote:
> On 24 February 2015 at 16:30, Brett Cannon wrote:
>>
>> Tell people to use pip. Having ensurepip in Python 2.7 and 3.4 makes it as
>> official as anything will be as the recommended tool to install projects.
>> Otherwise easy_install has nothing to do directly with python-dev so I don't
>> think we can comment on a group as to what people should do in terms of
>> bugs, etc.
> 
> Bug reports would go to the setuptools project, but I agree, "use pip"
> is a better suggestion. And if pip won't work, it would be good to
> know why.

And if/when pip doesn't work, a bug may need to be filed the project trying to 
be installed.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] easy_install ?

[Paul Moore]

On 24 February 2015 at 16:30, Brett Cannon  wrote:
> Tell people to use pip. Having ensurepip in Python 2.7 and 3.4 makes it as
> official as anything will be as the recommended tool to install projects.
> Otherwise easy_install has nothing to do directly with python-dev so I don't
> think we can comment on a group as to what people should do in terms of
> bugs, etc.

Bug reports would go to the setuptools project, but I agree, "use pip"
is a better suggestion. And if pip won't work, it would be good to
know why.

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

Re: [Python-Dev] easy_install ?

[Brett Cannon]

On Tue Feb 24 2015 at 10:54:14 AM Laura Creighton  wrote:

> Hello all,
> I wonder what the status of easy_install is.  I keep finding people
> who needed to install something 'path.py' is the latest, who needed to
> use pip, and couldn't get easy_install to work.  Should we tell people
> that easy_install is deprecated, or ask them  to file bugs when
> they could not get it to work, or ...
>

Tell people to use pip. Having ensurepip in Python 2.7 and 3.4 makes it as
official as anything will be as the recommended tool to install projects.
Otherwise easy_install has nothing to do directly with python-dev so I
don't think we can comment on a group as to what people should do in terms
of bugs, etc.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] easy_install ?

[Laura Creighton]

Hello all,
I wonder what the status of easy_install is.  I keep finding people
who needed to install something 'path.py' is the latest, who needed to
use pip, and couldn't get easy_install to work.  Should we tell people
that easy_install is deprecated, or ask them  to file bugs when
they could not get it to work, or ...

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

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Stephen J. Turnbull]

Chris Angelico writes:

 > I don't mind how long the deprecation period is, as long as there can
 > be an option to Python that makes a noisy warning.

If that's OK with you and for the use case you explicitly described,
though, a .bat file that runs a linter first might be the better
option since (a) you don't have to wait and (b) you can put any
bugaboo you like in there and (c) it can warn about syntacticly
correct strings that "just fail" and may be hard to find.

I think the Zen is right on, here:

Now is better than never.
Although never is often better than *right* now.

I don't have a good sense for which it is, though, partly because (a)
I don't program on Windows, but more importantly, (b) many of the
dangerous strings actually used won't generate warnings or errors ever.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Joao S. O. Bueno]

On 23 February 2015 at 18:39, Greg Ewing  wrote:
> Serhiy Storchaka wrote:
>>
>> The problem is that the user don't know that he should read the
>> documentation. It just find that his script works with "C:\sample.txt", but
>> doesn't work with "D:\test.txt". He has no ideas what happen.
>
>
> Even with the syntax error, there are filenames that
> will mysteriously fail, e.g. "C:\ninjamoves.txt".


That is the reason I urge folks to think about the root cause,
and check if this proposal is the best way to tackle it:
The failing cases are the ones that won't be affected by this change at all -
as they are valid escaped strings!

There will be no error for
c:\tmp\myfile.txt - it will ever be just "file not found" - unless the
warning comes to
using "\" as file path separator (and no, I don  think just doing that
would properly
address the issue as well).

Could we just use Guido's time machine and go back to the point in time where
some MS head decided to go with "\" instead of "/", and deliver a well
placed punch? :-)

Or maybe have IOError for "file not found" to get some fuzzy logic and
display a more verbose error message if there are "\n"s and "\t"s on
the filename
and platform is Windows?  I think that  could go along the proposal for
deprecating non-escaping "\" sequences .

By the way,  although I am writing to get the root issue covered, I think
deprecating them would be a good thing, yes. Despite my previous comment
on deprecating code that works, on a deeper though it _is_ worth the issue.

  js
 -><-



>
> --
> Greg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

[Chris Angelico]

On Tue, Feb 24, 2015 at 7:40 PM, M.-A. Lemburg  wrote:
> I think the easiest way would be to tweak the error message
> output to indicate the real problem.
>
> At the moment, you get:
>
 open('c:\test.txt')
> Traceback (most recent call last):
>   File "", line 1, in 
> FileNotFoundError: [Errno 2] No such file or directory: 'c:\test.txt'
>
> which isn't helpful.

The problem isn't the cases where the file can't be found. Those can
be dealt with fairly easily, one way or another. The problem is much,
much earlier, when the student was using "c:\sample.txt" and
everything was working fine. Then he changed the code over to use his
own file instead of the provided sample, and at the same time,
switched from using open() to using csv.reader(open()), and moved all
the code into a function, and fixed three other bugs, and now it isn't
working. And he can't figure out why.

That's why I'd like "c:\sample.txt" to raise a warning.

Should I start writing up a PEP? Is that the way forward with this?

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

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Nick Coghlan]

On 24 February 2015 at 06:32, Paul Moore  wrote:
> On 23 February 2015 at 19:47, Guido van Rossum  wrote:
>> So is the PEP ready for pronouncement or should there be more discussion?
>
> I think Brett's idea is worth incorporating, so let's thrash that out first.
>
>> Also, do you have a BDFL-delegate or do you want me to review it?
>
> No-one has stepped up as BDFL-delegate, and there's no obvious
> candidate, so I think you're it, sorry :-)

If Guido isn't keen, I'd be willing to cover it as the current runpy
module maintainer and the one that updated this part of the
interpreter startup sequence to handle the switch to importlib in 3.3.

The PEP itself doesn't actually touch any of that internal machinery
though, it just makes the capability a bit more discoverable and
user-friendly.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com