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

2015-02-23 Thread Serhiy Storchaka
See topic "Unrecognized backslash escapes in string literals" in Python 
list [1]. I agree that this is a problem, especially for novices (but 
even experience users can make a typo). May be emit SyntaxWarning on 
unrecognized backslash escapes? An exception is already raised on 
invalid octal or hexadecimal escapes. '\x' is syntax error, not two 
characters '\\' and 'x'.


[1] http://comments.gmane.org/gmane.comp.python.general/772455

___
Python-Dev mailing list
[email protected]
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?

2015-02-23 Thread Guido van Rossum
I think that's a bit too strong. This has been unquestionably valid,
correct Python -- it was an intentional feature from the start. It may not
have turned out great, but I think that before warning loudly about every
instance of this we should have a silent deprecation (which you can turn
into a visible warning with a command-line flag or a warnings filter). And
we should have agreement that we're eventually going to make it a syntax
error.

On Mon, Feb 23, 2015 at 1:57 AM, Serhiy Storchaka 
wrote:

> See topic "Unrecognized backslash escapes in string literals" in Python
> list [1]. I agree that this is a problem, especially for novices (but even
> experience users can make a typo). May be emit SyntaxWarning on
> unrecognized backslash escapes? An exception is already raised on invalid
> octal or hexadecimal escapes. '\x' is syntax error, not two characters '\\'
> and 'x'.
>
> [1] http://comments.gmane.org/gmane.comp.python.general/772455
>
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
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?

2015-02-23 Thread Chris Angelico
On Tue, Feb 24, 2015 at 2:44 AM, Guido van Rossum  wrote:
> I think that's a bit too strong. This has been unquestionably valid, correct
> Python -- it was an intentional feature from the start. It may not have
> turned out great, but I think that before warning loudly about every
> instance of this we should have a silent deprecation (which you can turn
> into a visible warning with a command-line flag or a warnings filter). And
> we should have agreement that we're eventually going to make it a syntax
> error.

Is it at all possible for this to be introduced in the 2.x line, or is
the entire concept of a deprecation period one that has to start with
a minor version?

If it's never going to happen in 2.x, I'll raise this as yet another
reason to get the course and all our students migrated to 3.x, but on
the flip side, it means that we absolutely can't get the benefit until
that jump is made.

ChrisA
___
Python-Dev mailing list
[email protected]
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?

2015-02-23 Thread Brett Cannon
On Mon Feb 23 2015 at 10:55:23 AM Chris Angelico  wrote:

> On Tue, Feb 24, 2015 at 2:44 AM, Guido van Rossum 
> wrote:
> > I think that's a bit too strong. This has been unquestionably valid,
> correct
> > Python -- it was an intentional feature from the start. It may not have
> > turned out great, but I think that before warning loudly about every
> > instance of this we should have a silent deprecation (which you can turn
> > into a visible warning with a command-line flag or a warnings filter).
> And
> > we should have agreement that we're eventually going to make it a syntax
> > error.
>
> Is it at all possible for this to be introduced in the 2.x line, or is
> the entire concept of a deprecation period one that has to start with
> a minor version?
>

Starts with a minor version.


>
> If it's never going to happen in 2.x, I'll raise this as yet another

reason to get the course and all our students migrated to 3.x, but on
> the flip side, it means that we absolutely can't get the benefit until
> that jump is made.
>

Never going to happen in 2.x..
___
Python-Dev mailing list
[email protected]
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?

2015-02-23 Thread Chris Angelico
On Tue, Feb 24, 2015 at 3:12 AM, Brett Cannon  wrote:
>
>
> On Mon Feb 23 2015 at 10:55:23 AM Chris Angelico  wrote:
>>
>> On Tue, Feb 24, 2015 at 2:44 AM, Guido van Rossum 
>> wrote:
>> > I think that's a bit too strong. This has been unquestionably valid,
>> > correct
>> > Python -- it was an intentional feature from the start. It may not have
>> > turned out great, but I think that before warning loudly about every
>> > instance of this we should have a silent deprecation (which you can turn
>> > into a visible warning with a command-line flag or a warnings filter).
>> > And
>> > we should have agreement that we're eventually going to make it a syntax
>> > error.
>>
>> Is it at all possible for this to be introduced in the 2.x line, or is
>> the entire concept of a deprecation period one that has to start with
>> a minor version?
>
>
> Starts with a minor version.
>
>>
>>
>> If it's never going to happen in 2.x, I'll raise this as yet another
>>
>> reason to get the course and all our students migrated to 3.x, but on
>> the flip side, it means that we absolutely can't get the benefit until
>> that jump is made.
>
>
> Never going to happen in 2.x..

Thanks, thought that'd be the case but figured I may as well ask.

ChrisA
___
Python-Dev mailing list
[email protected]
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

2015-02-23 Thread Thomas Wouters
On Mon, Feb 23, 2015 at 8:24 PM, Paul Moore  wrote:

> On 23 February 2015 at 19:01, Daniel Holth  wrote:
> > Sounds reasonable. It could be done by just reading the entire file
> > contents after the shebang and re-writing them with the necessary
> > offset all in RAM, truncating the file if necessary, without involving
> > the zipfile module very much; the shebang could have some amount of
> > padding by default; the file could just be re-compressed in memory
> > depending on your appetite for complexity.
>
> The biggest problem with that is finding the end of the prefix data.
> Frankly it's easier just to write a new prefix then use the zipfile
> module to rewrite all of the content. That's what the current code
> does writing to a new file.


I don't think you need to rewrite all of the contents, if you don't mind
poking into zipfile internals:

endrec = zipfile._EndRecData(f)
prefix_length = endrec[zipfile._ECD_LOCATION] - endrec[zipfile._ECD_SIZE] -
endrec[zipfile._ECD_OFFSET]

I do something similar to get at the prefix, although I need the zipfile
opened anyway, so I use:

endrec = zipfile._EndRecData(f) # pylint: disable=protected-access
zf = zipfile.ZipFile(f)
# endrec is None if reading it failed, but then ZipFile should have
# raised an exception...
assert endrec
prefix_len = zf.start_dir - endrec[zipfile._ECD_OFFSET]  # pylint:
disable=protected-access


Paul
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/thomas%40python.org
>



-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list
[email protected]
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

2015-02-23 Thread Serhiy Storchaka

On 23.02.15 21:22, Ethan Furman wrote:

This could be a completely stupid question, but how does the zip file know 
where the individual files are?  More to the
point, does the index work via relative or absolute offset?  If absolute, 
wouldn't the index have to be rewritten if the
zip portion of the file moves?


Absolute.


___
Python-Dev mailing list
[email protected]
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

2015-02-23 Thread Paul Moore
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 :-)

Paul
___
Python-Dev mailing list
[email protected]
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?

2015-02-23 Thread Antoine Pitrou
On Mon, 23 Feb 2015 16:58:29 -0300
"Joao S. O. Bueno"  wrote:
> On 23 February 2015 at 16:47, Antoine Pitrou  wrote:
> > On Mon, 23 Feb 2015 09:29:09 -0800
> > Guido van Rossum  wrote:
> >> On Mon, Feb 23, 2015 at 9:01 AM, Ethan Furman  wrote:
> >>
> >> > On 02/23/2015 08:12 AM, Brett Cannon wrote:
> >> > > On Mon Feb 23 2015 at 10:55:23 AM Chris Angelico wrote:
> >> >
> >> > >> Is it at all possible for this to be introduced in the 2.x line [...]
> >> > >
> >> > > Starts with a minor version.
> >> >
> >> > Isn't there a -3 switch or something like that in 2.7.x to trigger
> >> > warnings/errors to help port to 3.x?  Seems like this
> >> > kind of warning could go there.
> >> >
> >>
> >> If we agree it will be a syntax error in 3.x eventually.
> >
> > That sounds frankly like a pedantic change.
> 
> The real problem there, even motivating the request, seems to be new
> users in Windows platforms
> using "\" as file path separator.

Thanks. That sounds like a good reason indeed.

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
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

2015-02-23 Thread Paul Moore
On 23 February 2015 at 21:02, Brett Cannon  wrote:
>> The real problem with overwriting is if there's a failure during the
>> overwrite you lose the original file. My original API had overwrite as
>> the default, but I think the risk makes that a bad idea.
>
>
> Couldn't you catch the exception, write the original file back out, and then
> re-raise the exception?

But you don't *have* the original file. You read the source archive
entry-by-entry, not all at once.

Apart from the implementation difficulty, this is getting too complex,
and I think it's better to just give the user the tools to add
whatever robustness or exception handling they want on top.

Paul
___
Python-Dev mailing list
[email protected]
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?

2015-02-23 Thread Mark Lawrence

On 23/02/2015 21:27, Serhiy Storchaka wrote:

On 23.02.15 21:58, Joao S. O. Bueno wrote:

That happens all the time, and is this use case that should possibly
be addressed here - maybe
something as simple as adding a couple of paragraphs to different places
in the documentation could mitigate the issue. (in contrast to make a
tons of otherwise valid code
to become deprecated in a couple releases).


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.



Isn't this why users have help desks?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-Dev mailing list
[email protected]
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

2015-02-23 Thread Paul Moore
On 23 February 2015 at 21:18, Serhiy Storchaka  wrote:
> On 23.02.15 22:51, Paul Moore wrote:
>>
>> BTW, while I was looking at the API, I realised I don't like the order
>> of arguments in pack(). I'm tempted to make it pack(directory,
>> target=None, interpreter=None, main=None) where a target of None means
>> "use the name of the source directory with .pyz tacked on", exactly as
>> for the command line API.
>
>
> If the order of arguments is not obvious, make them keyword-only.

To be honest, I don't think it *is* that non-obvious. I just think I
got it wrong initially.

With the new API, you have

pack('myappdir')
pack('myappdir', 'named_target.pyz')

Seems obvious enough to me. It matches the "source, destination" order
of similar functions like shutil.copy. And you can use a named
argument if you're not sure. But I don't think it's worth forcing it.

Paul
___
Python-Dev mailing list
[email protected]
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?

2015-02-23 Thread Nick Coghlan
On 24 February 2015 at 08:40, Nick Coghlan  wrote:
> On 24 February 2015 at 07:39, Mark Lawrence  wrote:
>> On 23/02/2015 21:27, Serhiy Storchaka wrote:
>>>
>>> On 23.02.15 21:58, Joao S. O. Bueno wrote:

 That happens all the time, and is this use case that should possibly
 be addressed here - maybe
 something as simple as adding a couple of paragraphs to different places
 in the documentation could mitigate the issue. (in contrast to make a
 tons of otherwise valid code
 to become deprecated in a couple releases).
>>>
>>>
>>> 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.
>>
>> Isn't this why users have help desks?
>
> Most don't, and cases like "\n" or "\t" in a Windows path name being
> converted to whitespace are utterly impossible to look up in an
> internet search when they fail, so a user learning on their own gets
> left with a broken program and no particularly effective ways to ask
> for help figuring it out.
>
> Like Unicode encoding errors they may appear a long way from the
> source of the offending data value (in this case, likely to be a file
> name copy and pasted from elsewhere on their system), and they don't
> give a particularly helpful error message (especially when the escape
> sequences are for whitespace).
>
> While I originally disliked the idea, I think this is a genuine
> usability issue on Windows that would be worth addressing. However,
> it's a significant enough change that I believe it needs a PEP and a
> reasonably long transition period before anything actually breaks. For
> example:
>
> - pep8 and pylint warnings as soon as a patch can be accepted
> - Py3kWarning in Python 2.7.x
> - DeprecationWarning in Python 3.5
> - SyntaxWarning in Python 3.6
> - SyntaxError in Python 3.7

Another suggestion: we may want to turn this particular deprecation
warning on by default in the interactive interpreter, and recommend
that other interactive interpreter developers (such as the IPython
folks) consider doing the same.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
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?

2015-02-23 Thread Ethan Furman
On 02/23/2015 02:40 PM, Nick Coghlan wrote:

> - pep8 and pylint warnings as soon as a patch can be accepted
> - Py3kWarning in Python 2.7.x
> - DeprecationWarning in Python 3.5
> - SyntaxWarning in Python 3.6
> - SyntaxError in Python 3.7

+1

--
~Ethan~



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