Re: [Python-Dev] Multiline with statement line continuation

[Georg Brandl]

On 08/12/2014 06:57 PM, Armin Rigo wrote:
> Hi,
> 
> On 12 August 2014 01:08, Allen Li  wrote:
>> with (open('foo') as foo,
>>   open('bar') as bar,
>>   open('baz') as baz,
>>   open('spam') as spam,
>>   open('eggs') as eggs):
>> pass
> 
> +1.  It's exactly the same grammar extension as for "from import"
> statements, for the same reason.

Not the same: in import statements it unambiguously replaces a list
of (optionally as-renamed) identifiers.  Here, it would replace an
arbitrary expression, which I think would mean that we couldn't
differentiate between e.g.

   with (expr).meth():# a line break in "expr"
  # would make the parens useful

and

   with (expr1, expr2):

cheers,
Georg

___
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] Multiline with statement line continuation

[Georg Brandl]

On 08/15/2014 11:08 PM, Ethan Furman wrote:
> On 08/13/2014 10:32 AM, Steven D'Aprano wrote:
>>
>> (2) Also note that *this is already the case*, since tuples are made by
>> the commas, not the parentheses. E.g. this succeeds:
>>
>> # Not a tuple, actually two context managers.
>> with open("/tmp/foo"), open("/tmp/bar", "w"):
>> pass
> 
> Thanks for proving my point!  A comma, and yet we did *not* get a tuple from 
> it.

Clearly the rule is that the comma makes the tuple, except when it doesn't :)

Georg

___
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] [RELEASED] Python 3.2.6rc1, Python 3.3.6rc1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the release of Python 3.2.6rc1 and 3.3.6rc1.  Both are release candidates
for security-fix releases, which are provide source-only on python.org.

The list of security-related issues fixed in the releases is given in
the changelogs:

https://hg.python.org/cpython/raw-file/v3.2.6rc1/Misc/NEWS
https://hg.python.org/cpython/raw-file/v3.3.6rc1/Misc/NEWS

To download the pre-releases visit one of:

https://www.python.org/downloads/release/python-326rc1/
https://www.python.org/downloads/release/python-336rc1/

These are pre-releases, please report any bugs to

 http://bugs.python.org/

The final releases are scheduled one week from now.

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlQv9GsACgkQN9GcIYhpnLC93gCfVm74lhOysPYCO0fy9/l5LUfJ
bUYAn2u1EygfsPw2oa4CSoj5t0TYUJq7
=HnOK
-END PGP 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] Microsoft Visual C++ Compiler for Python 2.7

[Georg Brandl]

I just tried out the compiler and built wininst and wheel dists. Thanks!

distutils was *almost* fine using it, but for two snags:

* I had to set VS90COMNTOOLS

* distutils expects vcvarsall.bat in VC, while you have it in the parent dir

The first could be set by the installer of your package.  But if it is not
feasible to do so, setting an envvar is something that developers can surely
be expected to do with instruction.

The second is a little more inconvenient.  Wouldn't it be possible to put
the .bat file in the "right" folder, or if it has to be there, put *another*
one in "VC"?  (That is what I did.)

cheers,
Georg

On 09/27/2014 05:16 PM, Steve Dower wrote:
> Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but
> "update Python" is a big/impossible ask for a lot of people, whereas "update
> setuptools" is easy and also covers Python 2.6 and <3.3.
> 
> The compiler installer can't set the keys that distutils looks for without
> losing the per-user installation, and it may also corrupt actual installs of
> Visual Studio. A monkey patch via setuptools was the best way to handle this -
> covers pip and Cython and can be ported to other libraries that care but avoid
> setuptools.
> 
> Now that we have a patch, there's very limited value in fixing 2.7.9, IMO. But
> I'm willing to be convinced - we can always add a version check to the
> setuptools patch.
> 
> Cheers,
> Steve


___
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] bytes-like objects

[Georg Brandl]

On 10/05/2014 06:11 PM, R. David Murray wrote:
> Over the past while we've been cleaning up the docs in the area of "how
> do we refer to bytes, bytearray, memoryview, etc, etc?" in the APIs that
> deal with bytes.  As you may or may not remember, we settled on the term
> 'bytes-like object', and have changed the docs to (we hope) consistently
> use this term, which has a glossary entry most of the references to it
> link to.
> 
> I just committed (to 3.5) the final changes for issue 16518, the change
> to consistently using the term 'bytes-like object' for things that
> support the buffer interface.  This means that messages that previously
> read:
> 
> 'sometype' does not support the buffer interface
> 
> now read
> 
> a bytes-like object is required, not 'sometype'
> 
> The 'buffer interface' messages were rather confusing, since you have to
> dig to find out what the 'buffer interface' is.  It isn't any sort of
> python object, nor is there any object in python3 that has a name
> related to it.  'bytes-like object', on the other hand, is fairly
> intuitive[*], and if you look it up in the glossary it links to the
> explanation of the buffer interface.
> 
> We felt it was worth explicitly mentioning this patch on python-dev to point
> out to everyone that the docs and error messages now use a consistent
> terminology, instead of the mis-mash we had before, which should make it 
> easier
> to help people with issues where this comes up.
> 
> If there are objections to this change to the messages it is easy enough to
> back out, but personally I find the new error messages *much* clearer, and I'm
> an experienced dev.

I agree. Thanks for the effort you two!

Georg

___
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] bytes-like objects

[Georg Brandl]

On 10/06/2014 06:34 AM, Nick Coghlan wrote:

> 3. "buffer" is a completely new term for most users, and one that
> refers to an implementation detail of memoryview, moreso than
> something developers actually need to care about. Using it directly in
> error messages and documentation is to make the abstraction leak in a
> way that raises unnecessary barriers to entry.

Especially since buffer() is gone in Py3.

The only prominent mention of "buffer" in the docs is now the C API section
that explains the buffer protocol.  Since this is cross-referenced
from the "bytes-like object" glossary, it will lead people who want to
write such an object to the right place.

Georg

___
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] [RELEASED] Python 3.2.6, Python 3.3.6

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the release of Python 3.2.6 and 3.3.6.  Both are security-fix releases,
which are provided source-only on python.org.

The list of security-related issues fixed in the releases is given in
the changelogs:

https://hg.python.org/cpython/raw-file/v3.2.6/Misc/NEWS
https://hg.python.org/cpython/raw-file/v3.3.6/Misc/NEWS

To download the releases visit one of:

https://www.python.org/downloads/release/python-326/
https://www.python.org/downloads/release/python-336/

These are production versions, please report any bugs to

 http://bugs.python.org/

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlQ6L/cACgkQN9GcIYhpnLBxIwCeLqjXeIOxGA2vkjbkN5Ic6j2u
7WcAoKgFaB4drMX5ZOVUJ4VLyNTcfycN
=KLlw
-END PGP 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] https://docs.python.org/3/using/index.html not linking correctly

[Georg Brandl]

On 10/20/2014 10:01 PM, Terry Reedy wrote:
> If I go to https://docs.python.org/3/using/index.html and click on any 
> of the TOC entries, I get 'connecting' indefinitely.  This problem seems 
> unique to this file. I tried several other index files and clicking am 
> entry brings up the corresponding page almost immediately.

Sounds like a similar problem to this:
https://mail.python.org/pipermail/docs/2014-October/020440.html

(There, the OP reported that she saw a different result in different
browsers.)

Georg


___
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] Move selected documentation repos to PSF BitBucket account?

[Georg Brandl]

On 11/23/2014 05:55 PM, Brett Cannon wrote:

> I guess my question is who and what is going to be disrupted if we go with
> Guido's suggestion of switching to GitHub for code hosting? Contributors won't
> be disrupted at all since most people are more familiar with GitHub vs.
> Bitbucket (how many times have we all heard the fact someone has even learned
> Mercurial just to contribute to Python?). Core developers might be based on 
> some
> learned workflow, but I'm willing to bet we all know git at this point (and 
> for
> those of us who still don't like it, myself included, there are GUI apps to
> paper over it or hg-git for those that prefer a CLI). Our infrastructure will
> need to be updated, but how much of it is that hg-specific short of the 
> command
> to checkout out the repo? Obviously Bitbucket is much more minor by simply
> updating just a URL, but changing `hg clone` to `git clone` isn't crazy 
> either.
> Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald 
> or
> someone in the infrastructure committee.

Well, since "most people" already know git this part is probably not a big deal,
although we'd have to consider alienating core developers who are not git-savvy.

> Probably the biggest thing I can think of that would need updating is our 
> commit
> hooks. Once again Georg, Antoine, or Benjamin could say how difficult it would
> be to update those hooks.

There are two categories of hooks we use: hooks that run before a push is
accepted, and hooks that run afterwards.  The latter are not a concern, since
anything that GH/BB doesn't support can be run as a web service on python.org
infrastructure, which then gets POST requests from the hosting platforms.  These
are

* tracker update
* IRC notification
* sending email to python-checkins
* triggering buildbot

The more problematic category are pre-push hooks.  We use them for checking
and rejecting commits with

* disallowed branches
* non-conformant whitespace
* wrong EOL style
* multiple heads per named branch

As far as I know, neither GH nor BB support such hooks, since they are highly
project-specific.  However, they are only used in cpython and related
repositories, so that doesn't concern migration of doc-only repos.

Sure, you can let the CI run the checks, but that doesn't prohibit merging
and is circumvented by direct pushes to the repository that don't go through
the PR system.  (And please don't make me as a coredev open a PR for every
change.)

> From my perspective, swapping out Mercurial for git achieves exactly 
> nothing
> in terms of alleviating the review bottleneck (since the core developers
> that strongly prefer the git UI will already be using an adapter), and is 
> in
> fact likely to make it worse by putting the greatest burden in adapting to
> the change on the folks that are already under the greatest time pressure.
> 
> 
> That's not entirely true. If you are pushing a PR shift in our patch 
> acceptance
> workflow then Bitbucket vs. GitHub isn't fundamentally any different in terms 
> of
> benefit, and I would honestly argue that GitHub's PR experience is better. IOW
> either platform is of equal benefit.

In my opinion, scattering repos over github, bitbucket and hg.python.org is
even less friendly to contributors than a centralized place.  (We are already
approaching this, with pydotorg and infrastructure repos on github.)  So I'm
going to add some thoughts here about migrating the main CPython to git+hub.

We have to consider how well our branch workflow works with the PR
workflow.  There's no gain in the ability to easily merge a PR to one branch
via github when the subsequent merge of 3.x to default/master requires a local
pull/push cycle, as well as the 2.x backport.

As far as I know, you'd have to open a pull/merge request yourself and instantly
merge it, except if there are conflicts between branches, in which case you
are again forced to go local.  I don't need to mention that this doesn't work
well when someone makes a  concurrent commit to the source branch in the
meantime.

And I don't think you'd want to force people to submit 3 pull requests for
the individual branches.

The next point is that there is no easy way to change the target branch of
a pull request (on github or bitbucket).  People will usually make patches
against the master branch unless told differently explicitly, which means
that the pull request will also be against the master branch.  Which means,
close the PR, ask submitter to resubmit against 3.x branch, or do it
yourself.

> It's also worth keeping in mind that changing the underlying VCS means
> changing *all* the automation scripts, rather than just updating the
> configuration settings to reflect a new hosting URL.
> 
> 
> What are the automation scripts there are that would require updating? I would
> like to a list and to have the difficulty of moving them mentioned to know 
> what
> the impact would be.

Compiling t

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Georg Brandl]

On 11/23/2014 07:03 PM, Ryan wrote:
> I can agree with most of these points. Some more things to consider:
> 
> - Git is 20x faster than Hg (that's 99% of the reason I switched and hate 
> using
> Darcs)

You won't get much traction with this argument around here.  As long as there
aren't specific complaints about slowness (which probably could be fixed by a
discussion on mercurial-devel), Hg is "fast enough", just like Python is "fast
enough" compared to C.  (Otherwise, why bother.)

> - GitHub is much nicer than BitBucket. I usually look for a git mirror of a
> BitBucket repo since I hate browsing on BB

I agree, Github's UI is nicer than BB.  It is also true that most features
that are introduced on BB are "inspired" by GH.

> - Even Plan9Port moved from Hg to GitHub a few days ago

Projects move all the time.  Why is this one special?

> - Some Google devs even host their projects on GitHub (not Google Code)
> 
> Thank goodness no one has mentioned CodePlex.
> 
> BTW, I frown on projects that choose something largely inferior over a better
> choice just because "one is written in X language." Now, if python.org
>  was written in Ruby, that would just be sad, but certain
> things just don't matter. Like DVCS's.

You can read up PEP 374 for the reasons for Hg.  The main reasons against git
were lacking Windows support (which probably is good enough now) and developer
preference.

Georg


___
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] Move selected documentation repos to PSF BitBucket account?

[Georg Brandl]

On 11/23/2014 09:38 PM, Donald Stufft wrote:
> 
>> On Nov 23, 2014, at 3:03 PM, Georg Brandl  wrote:
>> 
>> The next point is that there is no easy way to change the target branch of
>> a pull request (on github or bitbucket).  People will usually make patches
>> against the master branch unless told differently explicitly, which means
>> that the pull request will also be against the master branch.  Which means,
>> close the PR, ask submitter to resubmit against 3.x branch, or do it
>> yourself.
> 
> This in particular is not really true on Github at least. By default PRs are
> made against whichever branch you have configured as the default branch in
> the Github UI. This does default to master but it doesn’t have to be, for
> instance pip has this configured for the develop branch. Although I think 
> this specific point is moot because if things were on Git it’d probably make
> the most sense to have the default integration branch be ``master`` just like
> for the Hg repos they use default.

Sure, although as is the majority of commits to CPython are bugfixes, which
normally go to 2.7, 3.4 and 3.5 (master).

> Even if someone makes a PR against the wrong branch, it “degrades” into
> essentially the same UX as you have now, you can turn a PR into a patch by
> adding a .patch or .diff to the end of the PR URL and then you have a patch
> file. In additional github makes it easy to check out PRs directly with only a
> minor bit of one time configuration in your local clone. I can checkout any PR
> by doing ``git checkout pr/1`` (replacing 1 with whatever the number is).
>
> Honestly the worst part about someone sending a PR to the wrong branch is it
> degrades into the same terrible UX that *every* patch has to go through on
> a hg.python.org repository right now.

I'm not saying it's worse, but most of the time it's no better for the
committer, especially since the branches have to be juggled in most cases.

Although, when it's the same amount of work for the committer, but nicer for
the contributor, that's a net win, I can see that.

What is absolutely essential though is a way to automatically open an issue
on bugs.python.org for each PR, otherwise we have to look for issues in two
different places.  (Sure, GH treats PRs like GH issues, but we wouldn't use
the GH issue tracker.)

Georg


___
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] Move selected documentation repos to PSF BitBucket account?

[Georg Brandl]

On 11/23/2014 09:42 PM, Brett Cannon wrote:

> The more problematic category are pre-push hooks.  We use them for 
> checking
> and rejecting commits with
> 
> * disallowed branches
> * non-conformant whitespace
> * wrong EOL style
> * multiple heads per named branch
> 
> As far as I know, neither GH nor BB support such hooks, since they are 
> highly
> project-specific.  However, they are only used in cpython and related
> repositories, so that doesn't concern migration of doc-only repos.
> 
> Sure, you can let the CI run the checks, but that doesn't prohibit merging
> and is circumvented by direct pushes to the repository that don't go 
> through
> the PR system.  (And please don't make me as a coredev open a PR for every
> change.)
> 
> 
> I'm not even going to touch the idea of requiring code review for all patches 
> in
> the middle of this discussion. =) 

As far as I can see, our Rietveld is very well used already.  *Requiring* code
review for *all* patches is detrimental in a volunteer project IMO.  (I'm saying
this especially because many of my changes are small to trivial doc fixes.)

> The next point is that there is no easy way to change the target branch of
> a pull request (on github or bitbucket).  People will usually make patches
> against the master branch unless told differently explicitly, which means
> that the pull request will also be against the master branch.  Which 
> means,
> close the PR, ask submitter to resubmit against 3.x branch, or do it
> yourself.
> 
> 
> How do other projects tend to manage their bugfix vs. in-dev branches? Is it a
> lot of cherrypicking? Probably our long development cycles doesn't help with
> this as it makes cross-branch merging difficult thanks to divergence, else 
> this
> could be automated somehow or simply not be an issue. Otherwise we would have 
> to
> do a merge from branch to branch locally as we do now and make sure people
> committed in the branch we wanted them to.

For smaller projects, it's not as much of an issue.  In Sphinx, there are two
branches (stable and default), and when there are pull requests to the default
branch that should go to stable, I cherry-pick them manually.  And as you said,
merging or transplanting between branches is much more likely to succeed
automatically.

> The "but it is much easier to contribute simple changes" argument is a bit
> simplified: for any nontrivial patch, the time spent on working out the 
> code
> should outweight time spent with "hg diff" or "click on pull request".  
> And
> while Travis CI is nice, running relevant tests locally is *much* quicker 
> than
> waiting for a full test suite run on a virtualized testing machine.
> 
> 
> Sure, but it's definitely easier to just wait for the Travis green on the PR
> than have to apply a patch and run the tests myself manually.

You'll likely have to run them manually anyway while merging to the other
branches.

> As for typo fixes, the world does not end when some typos aren't fixed.
> Anyway, for the docs we have an explicit offer to send anything, patch or
> just suggestion, to d...@python.org , and people 
> do
> make use of it.  No
> github account even required.
> 
> 
> Which is great, but I'm willing to bet clicking "Edit" in GitHub is easier 
> still
> than creating the patch and emailing it. I have contributed doc fixes to a 
> bunch
> of projects because of that "Edit" button (which is why I think Nick is so
> anxious to get it). If I had to do any checkout then I wouldn't have done 
> them.
> And even having to email a diff might be too much for some changes.

I did say "patch or just suggestion".  Most emails to d...@python.org come
without a patch, just a plain description of what's wrong, and that is just
fine.  I would also judge that >50% of the emails come from people who wouldn't
have a github account in any case (so that the big shiny Edit button isn't an
easy option).

> > And I'm still in support no matter what of breaking out the HOWTOs and 
> the
> > tutorial into their own repos for easier updating (having to update the 
> Python
> > porting HOWTO in three branches is a pain when it should be consistent 
> across
> > Python releases).
> 
> I see no problem with that, provided there's a cronjob that syncs the 
> version
> in Doc/ to the external version reasonably often.
> 
> 
> Would that really be necessary? At least for the HOWTOs how often are they
> edited simultaneously as some code in CPython? The Clinic HOWTO is probably 
> the
> only one that might get updated simultaneously. I'd also be curious to know 
> how
> often the tutorial is updated simultaneously as well.

I'd like the HOWTOs to stay part of Doc/, so changes in the external repo have
to be merged in there somehow, and not only at release time.

Georg


__

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Georg Brandl]

On 11/24/2014 12:21 AM, Brett Cannon wrote:
> 
> 
> On Sun Nov 23 2014 at 4:18:37 PM Georg Brandl  <mailto:g.bra...@gmx.net>> wrote:
> 
> On 11/23/2014 09:42 PM, Brett Cannon wrote:
> 
>  
> [SNIP] 
> 
> > > And I'm still in support no matter what of breaking out the HOWTOs
> and the
> > > tutorial into their own repos for easier updating (having to 
> update
> the Python
> > > porting HOWTO in three branches is a pain when it should be
> consistent across
> > > Python releases).
> >
> > I see no problem with that, provided there's a cronjob that syncs 
> the
> version
> > in Doc/ to the external version reasonably often.
> >
> >
> > Would that really be necessary? At least for the HOWTOs how often are 
> they
> > edited simultaneously as some code in CPython? The Clinic HOWTO is
> probably the
> > only one that might get updated simultaneously. I'd also be curious to
> know how
> > often the tutorial is updated simultaneously as well.
> 
> I'd like the HOWTOs to stay part of Doc/, so changes in the external repo 
> have
> to be merged in there somehow, and not only at release time.
> 
> 
> Right, I'm trying to understand *why* you want the HOWTOs to stay in Doc/. I
> dread having to update the porting HOWTO because it requires updating 2.7, 
> 3.4,
> and default. And if the process is automated to pull from an external repo 
> then
> what is the benefit of syncing the files and duplicating them across 4 repos?

That they are still part of the docs on docs.python.org and what people download
from there.  I don't like resources like that scattered about.  It makes sense
for the devguide, since that is really a different topic.

Georg

___
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] PEP 481 - Migrate Some Supporting Repositories to Git and Github

[Georg Brandl]

On 12/01/2014 01:05 PM, Matěj Cepl wrote:
> On 2014-12-01, 07:43 GMT, Donald Stufft wrote:
>>> I do not choose tools simply because they are written in
>>> Python -- I choose them because, being written in Python, I
>>> I can work on them if I need to:  I can enhance them, I can 
>>> fix them, I can learn from them.
>>
>> Git uses the idea of small individual commands that do small things,
>> so you can write your own commands that work on text streams to
>> extend git and you can even write those in Python.
> 
> I really really dislike this Mercurial propaganda for two 
> reasons:
> 
> a) obviously you are right ... git is a complete tool box for 
>building your own tools in the best UNIX™ traditions. Each of 
>has a ton of third-party (or our own) tools using git 
>plumbing. (Is there a Mercurial equivalent of 
>git-filter-branch?  Can 
>http://mercurial.selenic.com/wiki/ConvertExtension do the 
>same as git-filter-branch?)
> b) it completely ignores existence of three (3) independent 
>implementations of git format/protocol (also jgit and 
>libgit2). How does VisualStudio/Eclipse/NetBeans/etc. support 
>for hg works? Does it use a library or just runs hg binary in 
>a subprocess (a thing which by the hg authors is Mercurial 
>not designed to do)?

Please at least try to get your facts right.

"""
For the vast majority of third party code, the best approach is to use
Mercurial's published, documented, and stable API: the command line interface.
"""
http://mercurial.selenic.com/wiki/MercurialApi

Georg

___
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] C ABI and #ifndef Py_LIMITED_API

[Georg Brandl]

On 01/14/2015 08:32 AM, Ethan Furman wrote:
> In the CPython source code I see
> 
> #ifndef Py_LIMITED_API
> 
> Is there a section in the docs that explains the purpose?  If not, can
> someone give me the cliff notes version?

PEP 384, and in particular [1] should get you started.

cheers,
Georg

[1]
https://www.python.org/dev/peps/pep-0384/#header-files-and-preprocessor-definitions

___
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] Any grammar experts?

[Georg Brandl]

On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
> On Sat, 24 Jan 2015 21:10:51 -0500
> Neil Girdhar  wrote:
>> To finish PEP 448, I need to update the grammar for syntax such as
>> 
>> {**x for x in it}
> 
> Is this seriously allowed by the PEP? What does it mean exactly?

It appears to go a bit far.  Especially since you also would have to allow

{*x for x in it}

which is a set comprehension, while the other is a dict comprehension :)

Georg

___
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] Python bug tracker & Roundup

[Georg Brandl]

On 01/26/2015 09:25 PM, Ethan Furman wrote:
> Do we have our own mailing list for Roundup?
> 
> I'm trying to fix the Activity Date search bug (only returns issues where the
> *last* activity was on a date, not *any* activity on a date).

That would be tracker-discuss.

Georg

___
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] Any grammar experts?

[Georg Brandl]

On 01/26/2015 07:25 PM, Skip Montanaro wrote:
> On Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou  wrote:
>> I also think the multiple-starargs function calls are completely
>> overboard:
>>
>>   f(**someargs, **someotherargs)
>>
>> (I might add I've never felt any need for those)
> 
> This makes sense to me, but I wonder how you resolve the case of
> overlapping keys.
> 
> I will note that pylint complains about any use of *args or **kwds
> (calling it "magic"), which seems a bit overboard to me. There's
> nothing magic in the current implementation as far as I can see.

Yeah, that's one of the sillier on-by-default warnings that I always
disable immediately.

Georg

___
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] PEP 475 accepted

[Georg Brandl]

On 02/03/2015 04:25 PM, Larry Hastings wrote:
> 
> On 02/02/2015 12:58 PM, Victor Stinner wrote:
>> 2015-02-02 21:49 GMT+01:00 Guido van Rossum :
>>> W00t! Congratulations les Français!
>> We will celebrate this acceptance with a glass of red wine and cheese.
> 
> If it were me, I'd use separate glasses.

Don't worry.  It might have been runny enough to put in a glass,
but the cat's eaten it.

Georg

___
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] (no subject)

[Georg Brandl]

On 02/10/2015 10:33 AM, Paul Moore wrote:
> On 10 February 2015 at 00:29, Neil Girdhar  wrote:
>>> > function(**kw_arguments, **more_arguments)
>>> If the key "key1" is in both dictionaries, more_arguments wins, right?
>>
>>
>> There was some debate and it was decided that duplicate keyword arguments
>> would remain an error (for now at least).  If you want to merge the
>> dictionaries with overriding, then you can still do:
>>
>> function(**{**kw_arguments, **more_arguments})
>>
>> because **-unpacking in dicts overrides as you guessed.
> 
> Eww. Seriously, function(**{**kw_arguments, **more_arguments}) feels
> more like a Perl "executable line noise" construct than anything I'd
> ever want to see in Python. And taking something that doesn't work and
> saying you can make it work by wrapping **{...} round it just seems
> wrong.

I don't think people would want to write the above.

I like the "sequence and dict flattening" part of the PEP, mostly because it
is consistent and should be easy to understand, but the comprehension syntax
enhancements seem to be bad for readability and "comprehending" what the code
does.

The call syntax part is a mixed bag: on the one hand it is nice to be
consistent with the extended possibilities in literals (flattening),
but on the other hand there would be small but annoying inconsistencies
anyways (e.g. the duplicate kwarg case above).

Georg

___
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] subclassing builtin data structures

[Georg Brandl]

On 02/14/2015 07:26 PM, Alexander Belopolsky wrote:

> In the case of int, there is a good reason for this behavior - bool.  In 
> python,
> we want True + True == 2.  In numpy, where binary operations preserve
> subclasses, you have
> 
 import numpy
 numpy.bool_(1) + numpy.bool_(1)
> True

I don't think numpy.bool_ subclasses some class like numpy.int_.

Georg

___
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 far to go with user-friendliness

[Georg Brandl]

On 07/14/2015 02:39 PM, Nick Coghlan wrote:

> Drawing the line at only rejecting "assert_" *would* have been a
> reasonable alternative design choice, but it isn't the one Kushal and
> Michael made, and there isn't a compelling argument in favour of
> changing the implementation of the new guard to allow the typo'ed
> prefix.

I'd like to request installing "phyton" as a symlink to "python" in the
next version.

Georg

___
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] PEP: Collecting information about git

[Georg Brandl]

On 09/15/2015 08:02 PM, Oleg Broytman wrote:
> On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson 
>  wrote:
>> This looks like good information, but why is it a PEP? If anything, the
>> devguide was probably be more appropriate. But even that's strange
>> considering we don't use git at the moment.
> 
>Exactly because the core team doesn't use git the information doesn't
> belong to the current revision of Developer's Guide.

And if it doesn't propose to make the core team use git, why is it a PEP?

Georg

___
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] PEP: Collecting information about git

[Georg Brandl]

Fair enough. Still strange to read this PEP with the explicit caveat of
"The author of the PEP doesn't currently plan to write a Process PEP on
migration Python development from Mercurial to git."

Georg

On 09/15/2015 08:22 PM, Guido van Rossum wrote:
> For one, because *I* have been a (moderate) advocate for switching to git and
> GitHub.
> 
> On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl  <mailto:g.bra...@gmx.net>> wrote:
> 
> On 09/15/2015 08:02 PM, Oleg Broytman wrote:
> > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson 
> mailto:benja...@python.org>> wrote:
> >> This looks like good information, but why is it a PEP? If anything, the
> >> devguide was probably be more appropriate. But even that's strange
> >> considering we don't use git at the moment.
> >
> >Exactly because the core team doesn't use git the information doesn't
> > belong to the current revision of Developer's Guide.
> 
> And if it doesn't propose to make the core team use git, why is it a PEP?



___
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] doc tests failing

[Georg Brandl]

On 11/13/2015 04:12 PM, Ethan Furman wrote:
> What am I doing wrong?

Running "make doctest" in the first place. The doctests in the core docs
were not written to support that, and also never updated to do so.

Georg

> I have tried:
> 
> 
> hg update 3.5  # and hg update default
> make distclean && ./configure --with-pydebug && make -j2
> cd Doc
> make doctest
> 
> 
> and in both cases I get page after page of errors.  I have tried 
> installing python-sphinx and python3-sphinx; I have tried adding 
> PYTHON=../python and PYTHON=python3 to the `make doctest` line -- all to 
> no avail.
> 
> Here's a random sample of the errors:
> 
> **
> File "library/shlex.rst", line ?, in default
> Failed example:
>  remote_command
> Exception raised:
>  Traceback (most recent call last):
>File "/usr/lib/python2.7/doctest.py", line 1315, in __run
>  compileflags, 1) in test.globs
>File "", line 1, in 
>  remote_command
>  NameError: name 'remote_command' is not defined
> 
> **
> File "howto/sorting.rst", line ?, in default
> Failed example:
>  sorted([5, 2, 4, 1, 3], cmp=numeric_compare)
> Exception raised:
>  Traceback (most recent call last):
>File "/usr/lib/python2.7/doctest.py", line 1315, in __run
>  compileflags, 1) in test.globs
>File "", line 1, in 
>  sorted([5, 2, 4, 1, 3], cmp=numeric_compare)
>  NameError: name 'numeric_compare' is not defined
> 
> **
> File "library/ipaddress.rst", line ?, in default
> Failed example:
>  n2 = ip_network('192.0.2.1/32')
> Exception raised:
>  Traceback (most recent call last):
>File "/usr/lib/python2.7/doctest.py", line 1315, in __run
>  compileflags, 1) in test.globs
>File "", line 1, in 
>  n2 = ip_network('192.0.2.1/32')
>  NameError: name 'ip_network' is not defined
> 
> --
> ~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/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Georg Brandl]

On 01/17/2016 11:19 PM, Brett Cannon wrote:
> 
> 
> On Sun, 17 Jan 2016, 13:59 Ethan Furman  > wrote:
> 
> On 01/17/2016 11:10 AM, Brett Cannon wrote:
> 
> > https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the
> > curly braces is purely an aesthetic thing while leaving them out can
> > lead to actual bugs.
> 
> Not sure what that sentence actually says, but +1 on making them 
> mandatory.
> 
> 
> 
> Yeah, bad phrasing on my part. What I meant to say is leaving them off is an
> aesthetic thing while requiring them is a bug prevention thing. When it comes 
> to
> writing C code I always vote for practicality over aesthetics.

+1.

Out of curiosity, I made a quick script to see if we had any candidates for
bugs related to this. I didn't expect any bugs to be found, since with the
amount of static checkers that have been run they should have been found.
The only problem I found was in the S390 port of libffi (#ifdef-conditional
code which wouldn't even compile).

I also found (in ast.c) two instances of semantically correct code with the
wrong indent level which I fixed (see rev 1ececa34b748).

cheers,
Georg

___
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] Update PEP 7 to require curly braces in C

[Georg Brandl]

On 01/19/2016 01:18 AM, Terry Reedy wrote:

> Though I don't write C anymore, I occasionally read our C sources.  I 
> dislike mixed bracketing in a multiple clause if/else statement,  and 
> would strongly recommend against that.  On the other hand, to my 
> Python-trained eye, brackets for one line clauses are just noise.  +-0.
> 
> If coverity's scan does not flag the sort of misleading bug bait 
> formatting that at least partly prompted this thread
> 
> if (a):
> b;
> c;
> 
> then I think we should find or write something that does and run it over 
> existing code as well as patches.

I don't know if static checkers care about whitespace and indentation in C;
it might be a very obvious thing to do for Python programmers, but maybe not
for C static checker developers :)

And probably with good reason, since whitespace isn't a consideration except
for nicely readable code, which many people (not talking about CPython here)
apparently don't care about, you'd have tons of spurious checker messages.

In many cases (especially error handling ones like "goto fail"), I expect the
checker to flag the error anyway, but for semantic reasons, not because of
whitespace.

Georg

___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Georg Brandl]

On 02/09/2016 10:57 AM, Joseph Martinot-Lagarde wrote:
> Victor Stinner  gmail.com> writes:
> 
>> 
>> Hi,
>> 
>> I changed the Python compiler to ignore any kind "constant
>> expressions", whereas it only ignored strings and integers before:
>> http://bugs.python.org/issue26204
>> 
>> The compiler now also emits a SyntaxWarning on such case. IMHO the
>> warning can help to detect bugs for developers who just learnt Python.
>> 
>> The warning is *not* emited for strings, since triple quoted strings
>> are a common syntax for multiline comments.
>> 
>> The warning is *not* emited neither for ellispis (...) since "f():
>> ..." is a legit syntax for abstract function.
>> 
> 
> I frequently use 1/0 as a quick break in a script or a program (it's even
> more useful with post-mortem debugging). Would it be considered as a
> constant and ignored instead of raising a ZeroDivisionError ?

At first, expressions involving operators are not seen as constant.  But
1/2 would be removed, since the peepholer will evaluate it to 0.5 (or 0)
and the constant-removal pass will recognize it as a constant (assuming
this ordering of the passes).

In the case of 1/0 the peepholer will try to evaluate it, but get an
exception and therefore not touch the expression further.

cheers,
Georg

___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

This came up in python-ideas, and has met mostly positive comments,
although the exact syntax rules are up for discussion.

cheers,
Georg



PEP: 515
Title: Underscores in Numeric Literals
Version: $Revision$
Last-Modified: $Date$
Author: Georg Brandl
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 10-Feb-2016
Python-Version: 3.6

Abstract and Rationale
==

This PEP proposes to extend Python's syntax so that underscores can be used in
integral and floating-point number literals.

This is a common feature of other modern languages, and can aid readability of
long literals, or literals whose value should clearly separate into parts, such
as bytes or words in hexadecimal notation.

Examples::

# grouping decimal numbers by thousands
amount = 10_000_000.0

# grouping hexadecimal addresses by words
addr = 0xDEAD_BEEF

# grouping bits into bytes in a binary literal
flags = 0b_0011__0100_1110


Specification
=

The current proposal is to allow underscores anywhere in numeric literals, with
these exceptions:

* Leading underscores cannot be allowed, since they already introduce
  identifiers.
* Trailing underscores are not allowed, because they look confusing and don't
  contribute much to readability.
* The number base prefixes ``0x``, ``0o``, and ``0b`` cannot be split up,
  because they are fixed strings and not logically part of the number.
* No underscore allowed after a sign in an exponent (``1e-_5``), because
  underscores can also not be used after the signs in front of the number
  (``-1e5``).
* No underscore allowed after a decimal point, because this leads to ambiguity
  with attribute access (the lexer cannot know that there is no number literal
  in ``foo._5``).

There appears to be no reason to restrict the use of underscores otherwise.

The production list for integer literals would therefore look like this::

   integer: decimalinteger | octinteger | hexinteger | bininteger
   decimalinteger: nonzerodigit [decimalrest] | "0" [("0" | "_")* "0"]
   nonzerodigit: "1"..."9"
   decimalrest: (digit | "_")* digit
   digit: "0"..."9"
   octinteger: "0" ("o" | "O") (octdigit | "_")* octdigit
   hexinteger: "0" ("x" | "X") (hexdigit | "_")* hexdigit
   bininteger: "0" ("b" | "B") (bindigit | "_")* bindigit
   octdigit: "0"..."7"
   hexdigit: digit | "a"..."f" | "A"..."F"
   bindigit: "0" | "1"

For floating-point literals::

   floatnumber: pointfloat | exponentfloat
   pointfloat: [intpart] fraction | intpart "."
   exponentfloat: (intpart | pointfloat) exponent
   intpart: digit (digit | "_")*
   fraction: "." intpart
   exponent: ("e" | "E") "_"* ["+" | "-"] digit [decimalrest]


Alternative Syntax
==

Underscore Placement Rules
--

Instead of the liberal rule specified above, the use of underscores could be
limited.  Common rules are (see the "other languages" section):

* Only one consecutive underscore allowed, and only between digits.
* Multiple consecutive underscore allowed, but only between digits.

Different Separators


A proposed alternate syntax was to use whitespace for grouping.  Although
strings are a precedent for combining adjoining literals, the behavior can lead
to unexpected effects which are not possible with underscores.  Also, no other
language is known to use this rule, except for languages that generally
disregard any whitespace.

C++14 introduces apostrophes for grouping, which is not considered due to the
conflict with Python's string literals. [1]_


Behavior in Other Languages
===

Those languages that do allow underscore grouping implement a large variety of
rules for allowed placement of underscores.  This is a listing placing the known
rules into three major groups.  In cases where the language spec contradicts the
actual behavior, the actual behavior is listed.

**Group 1: liberal (like this PEP)**

* D [2]_
* Perl 5 (although docs say it's more restricted) [3]_
* Rust [4]_
* Swift (although textual description says "between digits") [5]_

**Group 2: only between digits, multiple consecutive underscores**

* C# (open proposal for 7.0) [6]_
* Java [7]_

**Group 3: only between digits, only one underscore**

* Ada [8]_
* Julia (but not in the exponent part of floats) [9]_
* Ruby (docs say "anywhere", in reality only between digits) [10]_


Implementation
==

A preliminary patch that implements the specif

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/11/2016 02:16 AM, Martin Panter wrote:
> I have occasionally wondered about this missing feature.
> 
> On 10 February 2016 at 22:20, Georg Brandl  wrote:
>> Abstract and Rationale
>> ==
>>
>> This PEP proposes to extend Python's syntax so that underscores can be used 
>> in
>> integral and floating-point number literals.
> 
> This should extend complex or imaginary literals like 10_000j for consistency.

Yes, that was always the case, but I guess it should be explicit.

>> Specification
>> =
>>
>> * Trailing underscores are not allowed, because they look confusing and don't
>>   contribute much to readability.
>> * No underscore allowed after a sign in an exponent (``1e-_5``), because
>>   underscores can also not be used after the signs in front of the number
>>   (``-1e5``).
>> [. . .]
>>
>> The production list for integer literals would therefore look like this::
>>
>>integer: decimalinteger | octinteger | hexinteger | bininteger
>>decimalinteger: nonzerodigit [decimalrest] | "0" [("0" | "_")* "0"]
>>nonzerodigit: "1"..."9"
>>decimalrest: (digit | "_")* digit
>>digit: "0"..."9"
>>octinteger: "0" ("o" | "O") (octdigit | "_")* octdigit
>>hexinteger: "0" ("x" | "X") (hexdigit | "_")* hexdigit
>>bininteger: "0" ("b" | "B") (bindigit | "_")* bindigit
>>octdigit: "0"..."7"
>>hexdigit: digit | "a"..."f" | "A"..."F"
>>bindigit: "0" | "1"
>>
>> For floating-point literals::
>>
>>floatnumber: pointfloat | exponentfloat
>>pointfloat: [intpart] fraction | intpart "."
>>exponentfloat: (intpart | pointfloat) exponent
>>intpart: digit (digit | "_")*
> 
> This allows trailing underscores such as 1_.2, 1.2_, 1.2_e-5. Your
> bullet point above suggests at least some of these are not desired.

The middle one isn't, indeed.  I updated the grammar accordingly.

>>fraction: "." intpart
>>exponent: ("e" | "E") "_"* ["+" | "-"] digit [decimalrest]
> 
> This allows underscores in the exponent (1e-5_0), contradicting the
> other bullet point.

I clarified the bullet points.  An "immediately" was missing.

Thanks for the feedback!
Georg

___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/11/2016 12:45 AM, Andrew Barnert via Python-Dev wrote:
> On Feb 10, 2016, at 14:20, Georg Brandl  wrote:
> 
> First, general questions: should the PEP mention the Decimal constructor?
> What about int and float (I'd assume int(s) continues to work as always,
> while int(s, 0) gets the new behavior, but if that isn't obviously true, it
> may be worth saying explicitly).
> 
>> * Trailing underscores are not allowed, because they look confusing and
>> don't contribute much to readability.
> 
> Why is "123_456_" so ugly that we have to catch it, when "1___2_345__6"
> is just fine, or "123e__+456"? More to the point, if we really need an extra
> rule, and more complicated BNF, to outlaw this case, I don't think we want a
> liberal design at all.
> 
> Also, notice that Swift, Rust, and D all show examples with trailing
> underscores in their references, and they don't look particularly out of
> place with the other examples.

That's a point.  I'll look into the implementation.

>> There appears to be no reason to restrict the use of underscores
>> otherwise.
> 
> What other restrictions are there? I think the only place you've left that's
> not between digits is between the e and the sign.

There are other places left:

* between 0x and the digits
* between the digits and "j"
* before and after the decimal point

> A dead-simple rule like
> Swift's seems better than five separate rules that I have to learn and
> remember that make lexing more complicated and that ultimately amount to the
> conservative rule plus one other place I can put underscores where I'd never
> want to.

Not quite, see above.

>> **Group 1: liberal (like this PEP)**
>> 
>> * D [2]_ * Perl 5 (although docs say it's more restricted) [3]_ * Rust
>> [4]_ * Swift (although textual description says "between digits") [5]_
> 
> I don't think any of these are liberal like this PEP.
>
> For example, Swift's actual grammar rule allows underscores anywhere but
> leading in the "digits" part of int literals and all three potential digit
> parts of float literals. That's the whole rule. It's more conservative than
> this PEP in not allowing them outside of digit parts (like between E and +),
> more liberal in allowing them to be trailing, but I'm pretty sure the reason
> behind the design wasn't specifically about how liberal or conservative they
> wanted to be, but about being as simple as possible. Rust's rule seems to be
> equivalent to Swift's, except that they forgot to define exponents anywhere.
> I don't think either of them was trying to be more liberal or more
> conservative; rather, they were both trying to be as simple as possible.

I actually modelled this PEP closely on Rust.  It has restrictions as in this
PEP, except that trailing underscores are allowed, and that "1.0e_+5" is not
allowed (allowed by the PEP), and "1.0e+_5" is (not allowed by the PEP).

I don't think you can argue that it's simpler.

(If the PEP and our lexical reference were as loosely worded as Rust's, one
could probably say it's "simple", too.)

Also, both Swift and Rust don't have the baggage of allowing ".5" style
literals, which makes the grammar simpler in Swift's case.

> D does go out of its way to be as liberal as possible, e.g., allowing things
> like "0x_1_" that the others wouldn't (they'd treat the "_1_" as a digit
> part, which can't have leading underscores), but it's also more conservative
> than this spec in not allowing underscores between e and the sign.
> 
> I think Perl is the only language that allows them anywhere but in the digits
> part.

Thanks for the feedback!
Georg

___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/10/2016 11:35 PM, Brett Cannon wrote:

>> Examples::
>> 
>> # grouping decimal numbers by thousands
>> amount = 10_000_000.0
>> 
>> # grouping hexadecimal addresses by words
>> addr = 0xDEAD_BEEF
>> 
>> # grouping bits into bytes in a binary literal
>> flags = 0b_0011__0100_1110
>> 
> 
> I assume all of these examples are possible in either the liberal or 
> restrictive
> approaches?

The last one isn't for restrictive -- its first underscore isn't between digits.

>> 
>> Implementation
>> ==
>> 
>> A preliminary patch that implements the specification given above has 
>> been
>> posted to the issue tracker. [11]_
>> 
> 
> Is the implementation made easier or harder if we went with the Group 2 or 3
> approaches? Are there any reasonable examples that the Group 1 approach allows
> that Group 3 doesn't that people have used in other languages?

Group 3 is probably a little more work than group 2, since you have to make sure
only one consecutive underscore is present.  I don't see a point to that.

> I'm +1 on the idea, but which approach I prefer is going to be partially
> dependent on the difficulty of implementing (else I say Group 3 to make it
> easier to explain the rules).

Based on the feedback so far, I have an easier rule in mind that I will base
the next PEP revision on.  It's basically

"One ore more underscores allowed anywhere after a digit or a base specifier."

This preserves my preferred non-restrictive cases (0b__, 1.5_j) and
disallows more controversial versions like "1.5e_+_2".

cheers,
Georg





___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/10/2016 11:42 PM, Glenn Linderman wrote:
> On 2/10/2016 2:20 PM, Georg Brandl wrote:
>> This came up in python-ideas, and has met mostly positive comments,
>> although the exact syntax rules are up for discussion.
>>
>> cheers,
>> Georg
>>
>> 
>>
>> PEP: 515
>> Title: Underscores in Numeric Literals
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Georg Brandl
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 10-Feb-2016
>> Python-Version: 3.6
>>
>> Abstract and Rationale
>> ==
>>
>> This PEP proposes to extend Python's syntax so that underscores can be used 
>> in
>> integral and floating-point number literals.
>>
>> This is a common feature of other modern languages, and can aid readability 
>> of
>> long literals, or literals whose value should clearly separate into parts, 
>> such
>> as bytes or words in hexadecimal notation.
>>
>> Examples::
>>
>> # grouping decimal numbers by thousands
>> amount = 10_000_000.0
>>
>> # grouping hexadecimal addresses by words
>> addr = 0xDEAD_BEEF
>>
>> # grouping bits into bytes in a binary literal
>> flags = 0b_0011__0100_1110
> 
> +1
> 
> You don't mention potential restrictions that decimal numbers should permit 
> them
> only every three places, or hex ones only every 2 or 4, and your binary 
> example
> mentions grouping into bytes, but actually groups into nybbles.
> 
> But such restrictions would be annoying: if it is useful to the coder to use
> them, that is fine. But different situation may find other placements more
> useful... particularly in binary, as it might want to match widths of various
> bitfields.
> 
> Adding that as a rejected consideration, with justifications, would be 
> helpful.

I added a short paragraph.

Thanks for the feedback,
Georg



___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/11/2016 12:04 AM, Victor Stinner wrote:
> It looks like the implementation https://bugs.python.org/issue26331
> only changes the Python parser.
> 
> What about other functions converting strings to numbers at runtime
> like int(str) and float(str)? Paul also asked for Decimal(str).

I added these as "Open Questions" to the PEP.

For Decimal, it's probably a good idea.  For int(), it should only be
allowed with base argument = 0.  For float() and complex(), probably.

Georg

___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

Hey all,

based on the feedback so far, I revised the PEP.  There is now
a much simpler rule for allowed underscores, with no exceptions.
This made the grammar simpler as well.

---

PEP: 515
Title: Underscores in Numeric Literals
Version: $Revision$
Last-Modified: $Date$
Author: Georg Brandl
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 10-Feb-2016
Python-Version: 3.6

Abstract and Rationale
==

This PEP proposes to extend Python's syntax so that underscores can be used in
integral, floating-point and complex number literals.

This is a common feature of other modern languages, and can aid readability of
long literals, or literals whose value should clearly separate into parts, such
as bytes or words in hexadecimal notation.

Examples::

# grouping decimal numbers by thousands
amount = 10_000_000.0

# grouping hexadecimal addresses by words
addr = 0xDEAD_BEEF

# grouping bits into bytes in a binary literal
flags = 0b_0011__0100_1110

# making the literal suffix stand out more
imag = 1.247812376e-15_j


Specification
=

The current proposal is to allow one or more consecutive underscores following
digits and base specifiers in numeric literals.

The production list for integer literals would therefore look like this::

   integer: decimalinteger | octinteger | hexinteger | bininteger
   decimalinteger: nonzerodigit (digit | "_")* | "0" ("0" | "_")*
   nonzerodigit: "1"..."9"
   digit: "0"..."9"
   octinteger: "0" ("o" | "O") "_"* octdigit (octdigit | "_")*
   hexinteger: "0" ("x" | "X") "_"* hexdigit (hexdigit | "_")*
   bininteger: "0" ("b" | "B") "_"* bindigit (bindigit | "_")*
   octdigit: "0"..."7"
   hexdigit: digit | "a"..."f" | "A"..."F"
   bindigit: "0" | "1"

For floating-point and complex literals::

   floatnumber: pointfloat | exponentfloat
   pointfloat: [intpart] fraction | intpart "."
   exponentfloat: (intpart | pointfloat) exponent
   intpart: digit (digit | "_")*
   fraction: "." intpart
   exponent: ("e" | "E") ["+" | "-"] intpart
   imagnumber: (floatnumber | intpart) ("j" | "J")


Alternative Syntax
==

Underscore Placement Rules
--

Instead of the liberal rule specified above, the use of underscores could be
limited.  Common rules are (see the "other languages" section):

* Only one consecutive underscore allowed, and only between digits.
* Multiple consecutive underscore allowed, but only between digits.

A less common rule would be to allow underscores only every N digits (where N
could be 3 for decimal literals, or 4 for hexadecimal ones).  This is
unnecessarily restrictive, especially considering the separator placement is
different in different cultures.

Different Separators


A proposed alternate syntax was to use whitespace for grouping.  Although
strings are a precedent for combining adjoining literals, the behavior can lead
to unexpected effects which are not possible with underscores.  Also, no other
language is known to use this rule, except for languages that generally
disregard any whitespace.

C++14 introduces apostrophes for grouping, which is not considered due to the
conflict with Python's string literals. [1]_


Behavior in Other Languages
===

Those languages that do allow underscore grouping implement a large variety of
rules for allowed placement of underscores.  This is a listing placing the known
rules into three major groups.  In cases where the language spec contradicts the
actual behavior, the actual behavior is listed.

**Group 1: liberal**

This group is the least homogeneous: the rules vary slightly between languages.
All of them allow trailing underscores.  Some allow underscores after non-digits
like the ``e`` or the sign in exponents.

* D [2]_
* Perl 5 (underscores basically allowed anywhere, although docs say it's more
  restricted) [3]_
* Rust (allows between exponent sign and digits) [4]_
* Swift (although textual description says "between digits") [5]_

**Group 2: only between digits, multiple consecutive underscores**

* C# (open proposal for 7.0) [6]_
* Java [7]_

**Group 3: only between digits, only one underscore**

* Ada [8]_
* Julia (but not in the exponent part of floats) [9]_
* Ruby (docs say "anywhere", in reality only between digits) [10]_


Implementation
==

A preliminary patch that implements the specification given above has been
posted t

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/11/2016 10:10 AM, Paul Moore wrote:
> On 10 February 2016 at 23:14, Steven D'Aprano  wrote:
>> On Wed, Feb 10, 2016 at 10:53:09PM +, Paul Moore wrote:
>>> On 10 February 2016 at 22:20, Georg Brandl  wrote:
>>> > This came up in python-ideas, and has met mostly positive comments,
>>> > although the exact syntax rules are up for discussion.
>>>
>>> +1 on the PEP. Is there any value in allowing underscores in strings
>>> passed to the Decimal constructor as well? The same sorts of
>>> justifications would seem to apply. It's perfectly arguable that the
>>> change for Decimal would be so rarely used as to not be worth it,
>>> though, so I don't mind either way in practice.
>>
>> Let's delay making any change to string conversions for now, and that
>> includes Decimal. We can also do this:
>>
>> Decimal("123_456_789.0_12345_67890".replace("_", ""))
>>
>> for those who absolutely must include underscores in their numeric
>> strings. The big win is for numeric literals, not numeric string
>> conversions.
> 
> Good point. Maybe add this as an example in the PEP to explain why
> conversions are excluded. But I did only mean the Decimal constructor,
> which I think of more as a "decimal literal" - whereas int() and
> float() are (in my mind at least) conversion functions and as such
> should not be coupled to literal format (for example, 0x0001 notation
> isn't supported by int())

Actually, it is.  Just not without a base argument, because the default
base is 10.  But both with base 0 and base 16, '0x' prefixes are allowed.

That's why I'm leaning towards supporting the underscores.  In any case
I'm preparing the implementation.

Georg

___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/11/2016 11:17 AM, Serhiy Storchaka wrote:

>> **Group 3: only between digits, only one underscore**
>>
>> * Ada [8]_
>> * Julia (but not in the exponent part of floats) [9]_
>> * Ruby (docs say "anywhere", in reality only between digits) [10]_
> 
> C++ is in this group too.
> 
> The documentation of Perl explicitly says that Perl is in this group too 
> (23__500 is not legal). Perhaps there is a bug in Perl implementation. 
> And may be Swift is intended to be in this group.
> 
> I think we should follow the majority of languages and use simple rule: 
> "only between digits".
> 
> I have provided an implementation.

Thanks for the alternate patch.  I used the two-function approach you took
in ast.c for my latest revision.

I still think that some cases (like two of the examples in the PEP,
0b__ and 1.5_j) are worth having, and therefore a more relaxed
rule is preferable.

cheers,
Georg


___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/11/2016 05:52 PM, Steve Dower wrote:
> On 11Feb2016 0651, Barry Warsaw wrote:
>> On Feb 11, 2016, at 09:22 AM, Georg Brandl wrote:
>>
>>> based on the feedback so far, I revised the PEP.  There is now
>>> a much simpler rule for allowed underscores, with no exceptions.
>>> This made the grammar simpler as well.
>>
>> I'd be +1, but there's something missing from the PEP: what the underscores
>> *mean*.  You describe the syntax nicely, but not the semantics.
>>
>>  From reading the examples, I'd guess that the underscores are semantically
>> transparent, meaning that the resulting value is the same if you just removed
>> the underscores and interpreted the resulting literal.
>>
>> Right or wrong, could you please add a paragraph explaining the meaning of 
>> the
>> underscores?
> 
> Glad I kept reading the thread this far - just pretend I also wrote 
> exactly the same thing as Barry.

D'oh :)  I added (hopefully) clarifying wording.

Thanks,
Georg


___
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] Python 3.2.7 and 3.3.7

[Georg Brandl]

Hi all,

I'm planning to release 3.2.7 and 3.3.7 at the end of February.
There will be a release candidate on Feb 20, and the final on
Feb 27, if there is no holdup.

These are both security (source-only) releases.  3.2.7 will be the
last release from the 3.2 series.

If you know of any patches that should go in, make sure to commit
them in time or notify me.

Thanks,
Georg

___
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] PEP 515: Underscores in Numeric Literals

[Georg Brandl]

On 02/11/2016 06:19 PM, Serhiy Storchaka wrote:

>> Thanks for the alternate patch.  I used the two-function approach you took
>> in ast.c for my latest revision.
>>
>> I still think that some cases (like two of the examples in the PEP,
>> 0b__ and 1.5_j) are worth having, and therefore a more relaxed
>> rule is preferable.
> 
> Should I write an alternative PEP for strong rule?

That seems excessive for a minor point.  Let's collect feedback for
a few days, and we can also collect some informal votes.

In the end, I suspect that Guido will let us know about his preference for
one of the possibilities, and when he does, I will update the PEP accordingly.

cheers,
Georg

___
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] Py_SETREF again

[Georg Brandl]

On 02/12/2016 10:45 AM, Serhiy Storchaka wrote:
> Sorry to bringing this up again. I was hoping we were done with that.
> 
> When discussing the name of the Py_SETREF macro I was supposed to add a 
> pair of macros: for Py_DECREF and Py_XDECREF. But I got a lot of 
> opinions to be limited to only one macro.
>
> There was no (besides my) clearly expressed vote for two macros.

I would have voted in favor.

Spelling the SETREF out, as Nick proposes, kind of defies the purpose of
the macro: it's not strictly a convenience macro, it helps prevent
refcounting bugs.

> As a result I have replaced both Py_DECREF and Py_XDECREF with the macro 
> that always uses Py_XDECREF.

Can you roughly say which fraction of replacements changed DECREF to an
implicit XDECREF?

Georg

___
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] PEP 515: Underscores in Numeric Literals (revision 3)

[Georg Brandl]

Hi all,

after talking to Guido and Serhiy we present the next revision
of this PEP.  It is a compromise that we are all happy with,
and a relatively restricted rule that makes additions to PEP 8
basically unnecessary.

I think the discussion has shown that supporting underscores in
the from-string constructors is valuable, therefore this is now
added to the specification section.

The remaining open question is about the reverse direction: do
we want a string formatting modifier that adds underscores as
thousands separators?

cheers,
Georg

-

PEP: 515
Title: Underscores in Numeric Literals
Version: $Revision$
Last-Modified: $Date$
Author: Georg Brandl, Serhiy Storchaka
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 10-Feb-2016
Python-Version: 3.6
Post-History: 10-Feb-2016, 11-Feb-2016

Abstract and Rationale
==

This PEP proposes to extend Python's syntax and number-from-string
constructors so that underscores can be used as visual separators for
digit grouping purposes in integral, floating-point and complex number
literals.

This is a common feature of other modern languages, and can aid
readability of long literals, or literals whose value should clearly
separate into parts, such as bytes or words in hexadecimal notation.

Examples::

# grouping decimal numbers by thousands
amount = 10_000_000.0

# grouping hexadecimal addresses by words
addr = 0xDEAD_BEEF

# grouping bits into nibbles in a binary literal
flags = 0b_0011__0100_1110

# same, for string conversions
flags = int('0b__', 2)


Specification
=

The current proposal is to allow one underscore between digits, and
after base specifiers in numeric literals.  The underscores have no
semantic meaning, and literals are parsed as if the underscores were
absent.

Literal Grammar
---

The production list for integer literals would therefore look like
this::

   integer: decinteger | bininteger | octinteger | hexinteger
   decinteger: nonzerodigit (["_"] digit)* | "0" (["_"] "0")*
   bininteger: "0" ("b" | "B") (["_"] bindigit)+
   octinteger: "0" ("o" | "O") (["_"] octdigit)+
   hexinteger: "0" ("x" | "X") (["_"] hexdigit)+
   nonzerodigit: "1"..."9"
   digit: "0"..."9"
   bindigit: "0" | "1"
   octdigit: "0"..."7"
   hexdigit: digit | "a"..."f" | "A"..."F"

For floating-point and complex literals::

   floatnumber: pointfloat | exponentfloat
   pointfloat: [digitpart] fraction | digitpart "."
   exponentfloat: (digitpart | pointfloat) exponent
   digitpart: digit (["_"] digit)*
   fraction: "." digitpart
   exponent: ("e" | "E") ["+" | "-"] digitpart
   imagnumber: (floatnumber | digitpart) ("j" | "J")

Constructors


Following the same rules for placement, underscores will be allowed in
the following constructors:

- ``int()`` (with any base)
- ``float()``
- ``complex()``
- ``Decimal()``


Prior Art
=

Those languages that do allow underscore grouping implement a large
variety of rules for allowed placement of underscores.  In cases where
the language spec contradicts the actual behavior, the actual behavior
is listed.  ("single" or "multiple" refer to allowing runs of
consecutive underscores.)

* Ada: single, only between digits [8]_
* C# (open proposal for 7.0): multiple, only between digits [6]_
* C++14: single, between digits (different separator chosen) [1]_
* D: multiple, anywhere, including trailing [2]_
* Java: multiple, only between digits [7]_
* Julia: single, only between digits (but not in float exponent parts)
  [9]_
* Perl 5: multiple, basically anywhere, although docs say it's
  restricted to one underscore between digits [3]_
* Ruby: single, only between digits (although docs say "anywhere")
  [10]_
* Rust: multiple, anywhere, except for between exponent "e" and digits
  [4]_
* Swift: multiple, between digits and trailing (although textual
  description says only "between digits") [5]_


Alternative Syntax
==

Underscore Placement Rules
--

Instead of the relatively strict rule specified above, the use of
underscores could be limited.  As we seen from other languages, common
rules include:

* Only one consecutive underscore allowed, and only between digits.
* Multiple consecutive underscores allowed, but only between digits.
* Multiple consecutive underscores allowed, in most positions except
  for the start of the literal, or special positions like after a
  dec

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

[Georg Brandl]

On 02/13/2016 12:10 PM, Serhiy Storchaka wrote:
> On 13.02.16 10:48, Georg Brandl wrote:
>> Following the same rules for placement, underscores will be allowed in
>> the following constructors:
>>
>> - ``int()`` (with any base)
>> - ``float()``
>> - ``complex()``
>> - ``Decimal()``
> 
> What about float.fromhex()? Should underscores be allowed in it (I think 
> no)?

Good question.  It *does* accept a "0x" prefix, as does ``int(x, 16)``, so
there is some precedent for literal-like interpretation of the input here
as well.

Georg


___
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] Python 3.2.7 and 3.3.7

[Georg Brandl]

On 02/11/2016 06:34 PM, Georg Brandl wrote:
> Hi all,
> 
> I'm planning to release 3.2.7 and 3.3.7 at the end of February.
> There will be a release candidate on Feb 20, and the final on
> Feb 27, if there is no holdup.
> 
> These are both security (source-only) releases.  3.2.7 will be the
> last release from the 3.2 series.
> 
> If you know of any patches that should go in, make sure to commit
> them in time or notify me.

FYI, these releases are currently on hold waiting for patches for
a pending security issue (that we can't discuss publicly yet).

cheers,
Georg

___
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] Very old git mirror under github user "python-git"

[Georg Brandl]

On 02/27/2016 11:45 PM, Matthias Bussonnier wrote:
> Hi all, 
> 
> 
>> On Feb 27, 2016, at 14:21, Alexander Walters > > wrote:
>>
>> Can we even ask github to pull it down and reasonably expect them to comply?
>>  Their entire model is built on everyone forking everyone else.
> 
> Why the model is everyone forking, some of the help page of GitHub actually 
> tell
> you to contact GitHub support, like if you desire to "detach" a fork. 
> 
> Every reasonable requests I made to GitHub and the few interactions I had with
> the support always went well. 
> This did include asking GitHub to contact user as their pages were confusing,
> and might be misleading others.
> 
> So I would suggest 
> 
> 1) asking GitHub to contact author, potentially forwarding him/her a message
> from this list asking him/her to bring that down or transfer the control to 
> you.
> That should be easy to do as it will not force GitHub to provide anyone with 
> the
> emails of the the owner of python-git.
> 
> 2) in the case of no response from author ask politely GitHub that the repo is
> confusing for user, and ask what they can do about that.

These are both fine.  Although I don't see much confusion; there's bound to be
hundreds of forks of CPython, if not already, then definitely once we move to
GitHub.

> 3) If still nothing can be done make a DMCA request. You can likely argue that
> the logo/name are used without PSF content. 
> https://help.github.com/articles/dmca-takedown-policy/ 

Please no.  There is absolutely no call using such a blunt instrument, just for
a case of minor inconvenience.  It could also be blown up into a PR disaster,
probably rightly so.

cheers,
Georg

___
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] PEP 515: Underscores in Numeric Literals (revision 3)

[Georg Brandl]

I'll update the text so that the format() gets promoted from optional
to specified.

There was one point of discussion in the tracker issue that should be
resolved before acceptance: the Decimal constructor is listed as
getting updated to allow underscores, but its syntax is specified
in the Decimal spec: http://speleotrove.com/decimal/daconvs.html

Acccepting underscores would be an extension to the spec, which may
not be what we want to do as otherwise Decimal follows that spec
closely.

On the other hand, assuming decimal literals are introduced at some
point, they would almost definitely need to support underscores.
Of course, the decision whether to modify the Decimal constructor
can be postponed until that time.

cheers,
Georg

On 03/19/2016 01:02 AM, Guido van Rossum wrote:
> I'm happy to accept this PEP as is stands, assuming the authors are
> ready for this news. I recommend also implementing the option from
> footnote [11] (extend the number-to-string formatting language to
> allow ``_`` as a thousans separator).
> 
> On Thu, Mar 17, 2016 at 11:19 AM, Brett Cannon  wrote:
>> Where did this PEP leave off? Anything blocking its acceptance?
>>
>> On Sat, 13 Feb 2016 at 00:49 Georg Brandl  wrote:
>>>
>>> Hi all,
>>>
>>> after talking to Guido and Serhiy we present the next revision
>>> of this PEP.  It is a compromise that we are all happy with,
>>> and a relatively restricted rule that makes additions to PEP 8
>>> basically unnecessary.
>>>
>>> I think the discussion has shown that supporting underscores in
>>> the from-string constructors is valuable, therefore this is now
>>> added to the specification section.
>>>
>>> The remaining open question is about the reverse direction: do
>>> we want a string formatting modifier that adds underscores as
>>> thousands separators?
>>>
>>> cheers,
>>> Georg
>>>
>>> -
>>>
>>> PEP: 515
>>> Title: Underscores in Numeric Literals
>>> Version: $Revision$
>>> Last-Modified: $Date$
>>> Author: Georg Brandl, Serhiy Storchaka
>>> Status: Draft
>>> Type: Standards Track
>>> Content-Type: text/x-rst
>>> Created: 10-Feb-2016
>>> Python-Version: 3.6
>>> Post-History: 10-Feb-2016, 11-Feb-2016
>>>
>>> Abstract and Rationale
>>> ==
>>>
>>> This PEP proposes to extend Python's syntax and number-from-string
>>> constructors so that underscores can be used as visual separators for
>>> digit grouping purposes in integral, floating-point and complex number
>>> literals.
>>>
>>> This is a common feature of other modern languages, and can aid
>>> readability of long literals, or literals whose value should clearly
>>> separate into parts, such as bytes or words in hexadecimal notation.
>>>
>>> Examples::
>>>
>>> # grouping decimal numbers by thousands
>>> amount = 10_000_000.0
>>>
>>> # grouping hexadecimal addresses by words
>>> addr = 0xDEAD_BEEF
>>>
>>> # grouping bits into nibbles in a binary literal
>>> flags = 0b_0011__0100_1110
>>>
>>> # same, for string conversions
>>> flags = int('0b__', 2)
>>>
>>>
>>> Specification
>>> =
>>>
>>> The current proposal is to allow one underscore between digits, and
>>> after base specifiers in numeric literals.  The underscores have no
>>> semantic meaning, and literals are parsed as if the underscores were
>>> absent.
>>>
>>> Literal Grammar
>>> ---
>>>
>>> The production list for integer literals would therefore look like
>>> this::
>>>
>>>integer: decinteger | bininteger | octinteger | hexinteger
>>>decinteger: nonzerodigit (["_"] digit)* | "0" (["_"] "0")*
>>>bininteger: "0" ("b" | "B") (["_"] bindigit)+
>>>octinteger: "0" ("o" | "O") (["_"] octdigit)+
>>>hexinteger: "0" ("x" | "X") (["_"] hexdigit)+
>>>nonzerodigit: "1"..."9"
>>>digit: "0"..."9"
>>>bindigit: "0" | "1"
>>>octdigit: "0"..."7"
>>>hexdigit: 

Re: [Python-Dev] Defining a path protocol

[Georg Brandl]

On 04/06/2016 07:26 PM, Brett Cannon wrote:
> WIth Ethan volunteering to do the work to help make a path protocol a thing --
> and I'm willing to help along with propagating this through the stdlib where I
> think Serhiy might be interested in helping as well -- and a seeming consensus
> this is a good idea, it seems like this proposal has a chance of actually 
> coming
> to fruition.
> 
> Now we need clear details. :) Some open questions are:

Throwing in my 2 bikesheds here, not having read all subthreads:

>  1. Name: __path__, __fspath__, or something else?

__path__ is already taken as a module attribute, so I would avoid it.
__fspath__ is fine with me, although the more explicit variants are also
ok.  It's not like you need to read/write it constantly (that's the goal).

>  2. Method or attribute? (changes what kind of one-liner you might use in
> libraries, but I think historically all protocols have been methods and 
> the
> serialized string representation might be costly to build)

An attribute would be somewhat inconsistent with the special-method lookup rules
(looked up on the type, not the instance), so a method is probably a better
choice.

>  3. Built-in? (name is dependent on #1 if we add one)

I don't think it warrants a builtin.  I'd place it as a function in pathlib.

>  4. Add the method/attribute to str? (I assume so, much like __index__() is on
> int, but I have not seen it explicitly stated so I would rather clarify 
> it)

+1.

>  5. Expand the C API to have something like PyObject_Path()?

+1 (with _Py_ at first) since you're going to need it in a lot of C functions.

Georg


___
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] PEP 515: Underscores in Numeric Literals (revision 3)

[Georg Brandl]

I'm happy with the latest version.

Georg

On 05/11/2016 06:46 PM, Guido van Rossum wrote:
> If the authors are happy I'll accept it right away.
> 
> (I vaguely recall there's another PEP that's ready for pronouncement -- but
> which one?)
> 
> On Wed, May 11, 2016 at 9:34 AM, Brett Cannon  > wrote:
> 
> Is there anything holding up PEP 515 at this point in terms of acceptance 
> or
> implementation?
> 
> On Sat, 19 Mar 2016 at 11:56 Guido van Rossum  > wrote:
> 
> All that sounds fine!
> 
> On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah  > wrote:
> > Guido van Rossum  python.org > writes:
> >> So should the preprocessing step just be s.replace('_', ''), or 
> should
> >> it reject underscores that don't follow the rules from the PEP
> >> (perhaps augmented so they follow the spirit of the PEP and the 
> letter
> >> of the IBM spec)?
> >>
> >> Honestly I think it's also fine if specifying this exactly is left 
> out
> >> of the PEP, and handled by whoever adds this to Decimal. Having a 
> PEP
> >> to work from for the language spec and core builtins (int(), 
> float()
> >> complex()) is more important.
> >
> > I'd keep it simple for Decimal: Remove left and right whitespace 
> (we're
> > already doing this), then remove underscores from the remaining 
> string
> > (which must not contain any further whitespace), then use the IBM 
> grammar.
> >
> >
> > We could add a clause to the PEP that only those strings that follow
> > the spirit of the PEP are guaranteed to be accepted in the future.
> >
> >
> > One reason for keeping it simple is that I would not like to slow 
> down
> > string conversion, but thinking about two grammars is also a 
> problem --
> > part of the string conversion in libmpdec is modeled in ACL2, which
> > would be invalidated or at least complicated with two grammars.
> >
> >
> >
> > Stefan Krah
> >
> > ___
> > 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/brett%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] Removing the provisional label from pathlib

[Georg Brandl]

On 05/20/2016 09:15 PM, Victor Stinner wrote:
> 2016-05-20 18:56 GMT+02:00 Guido van Rossum :
>> Let's start in 3.6 with all this. I added path to 3.4 because I didn't
>> realize it was in security-mode only.
> 
> I also had to ask the question to myself about branches, that's why I
> wrote this table ;-)
> https://docs.python.org/devguide/#status-of-python-branches
> 
> By the way, is it still up to date? Python 3.2 end-of-line is
> documented as 2016-02-20, so its status should be end-of-life, no?
> 
> Georg Brandl scheduled a 3.2.7 release at the end of February 2016,
> but I don't see it on python.org and I don't recall its announcement.
> https://mail.python.org/pipermail/python-dev/2016-February/143300.html
> 
> Georg: any update on the Python 3.2 last release?

Still waiting for some last security update. I sent another mail to
python-dev that announced the delay, I think.

Georg



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] OS X 10.9 Mavericks -> 2.7.6/3.3.3 updates needed

[Georg Brandl]

Am 24.10.2013 11:11, schrieb Ned Deily:

> I don't know where any other potential 2.7.6 or 3.3.3 issues stand at this 
> point.  But I'd like Benjamin and Georg to propose an aggressive schedule so 
> we can get these fixes out there.
> 

We've basically agreed to do rc releases this weekend.  I don't have time the
weekend of Nov 2, so 3.3.3 final would be scheduled for Nov 9.  There are a
few "unlimited read" issues still open; I will have a look at porting their
patches tomorrow.

Georg

___
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] [RELEASED] Python 3.3.3 release candidate 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm quite happy to announce the
Python 3.3.3 release candidate 1.

Python 3.3.3 includes several security fixes and over 150 bug fixes compared to
the Python 3.3.2 release.

This release fully supports OS X 10.9 Mavericks.  In particular, this release
fixes an issue that could cause previous versions of Python to crash when typing
in interactive mode on OS X 10.9.

Python 3.3.3 also contains a new batteries-included feature for OS X users of
IDLE and other Tkinter-based programs.  The python.org Mac OS X 64-bit/32-bit
x86-64/i386 Installer for OS X 10.6+ now includes its own builtin version of
Tcl/Tk 8.5.  It is no longer necessary to install a third-party version of
Tcl/Tk 8.5 to workaround the problematic system versions.  See
http://www.python.org/download/mac/tcltk/ for more information.

Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.  In total, almost 500 API items are new or improved
in Python 3.3.  For a more extensive list of changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

and for the detailed changelog of 3.3.3, see

http://docs.python.org/3.3/whatsnew/changelog.html

To download Python 3.3.3 rc1 visit:

http://www.python.org/download/releases/3.3.3/

This is a preview release, please report any bugs to

 http://bugs.python.org/

The final version is scheduled to be released in two weeks' time, on or about
the 10th of November.

Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlJte8kACgkQN9GcIYhpnLDx8wCgqtabbC8DaoW+Vy03AYGWyLhw
sWcAoIK5jQeXDAxHayG+VWH/rRF1+qHC
=yOed
-END PGP 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] cpython: Issue #18408: Add a new PyFrame_FastToLocalsWithError() function to handle

[Georg Brandl]

Am 29.10.2013 01:19, schrieb victor.stinner:
> http://hg.python.org/cpython/rev/4ef4578db38a
> changeset:   86715:4ef4578db38a
> user:Victor Stinner 
> date:Tue Oct 29 01:19:37 2013 +0100
> summary:
>   Issue #18408: Add a new PyFrame_FastToLocalsWithError() function to handle
> exceptions when merging fast locals into f_locals of a frame.
> PyEval_GetLocals() now raises an exception and return NULL on failure.

You'll have to either make this private or document it.

Georg

___
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] cpython: Issue #18408: Fix PyUnicode_AsUTF8AndSize(), raise MemoryError exception on

[Georg Brandl]

Am 29.10.2013 01:46, schrieb victor.stinner:
> http://hg.python.org/cpython/rev/e1d51c42e5a1
> changeset:   86716:e1d51c42e5a1
> user:Victor Stinner 
> date:Tue Oct 29 01:28:23 2013 +0100
> summary:
>   Issue #18408: Fix PyUnicode_AsUTF8AndSize(), raise MemoryError exception on
> memory allocation failure
> 
> files:
>   Objects/unicodeobject.c |  1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
> --- a/Objects/unicodeobject.c
> +++ b/Objects/unicodeobject.c
> @@ -3766,6 +3766,7 @@
>  return NULL;
>  _PyUnicode_UTF8(unicode) = PyObject_MALLOC(PyBytes_GET_SIZE(bytes) + 
> 1);
>  if (_PyUnicode_UTF8(unicode) == NULL) {
> +PyErr_NoMemory();
>  Py_DECREF(bytes);
>  return NULL;
>  }

Shouldn't this (and related commits from #18408) have been committed to the 3.3
branch?

Georg

___
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] cpython: Issue #18408: Add a new PyFrame_FastToLocalsWithError() function to handle

[Georg Brandl]

> Gesendet: Dienstag, 29. Oktober 2013 um 10:38 Uhr
> Von: "Victor Stinner" 
> An: "Georg Brandl" 
> Cc: "Python Dev" 
> Betreff: Re: [Python-Dev] cpython: Issue #18408: Add a new 
> PyFrame_FastToLocalsWithError() function to handle
>
> 2013/10/29 Georg Brandl :
> > Am 29.10.2013 01:19, schrieb victor.stinner:
> >> http://hg.python.org/cpython/rev/4ef4578db38a
> >> changeset:   86715:4ef4578db38a
> >> user:Victor Stinner 
> >> date:Tue Oct 29 01:19:37 2013 +0100
> >> summary:
> >>   Issue #18408: Add a new PyFrame_FastToLocalsWithError() function to 
> >> handle
> >> exceptions when merging fast locals into f_locals of a frame.
> >> PyEval_GetLocals() now raises an exception and return NULL on failure.
> >
> > You'll have to either make this private or document it.
> >
> > Georg
> 
> I didn't find the documentation of PyFrame_FastToLocals(). Please open
> an issue if you consider that these functions must be documented.

I see you opened one already; thanks for that. In any case, our policy is that 
all public
API function (those without _Py prefixes) *should* be documented.

> IMO these functions should be private because very low-level, but it's
> too late: PyFrame_FastToLocals() is part of the stable ABI, even if
> it's not documented.

Thankfully not; all of frameobject.h is not part of the stable ABI.

cheers,
Georg
___
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] cpython: Issue #18408: Fix PyUnicode_AsUTF8AndSize(), raise MemoryError exception on

[Georg Brandl]

> Gesendet: Dienstag, 29. Oktober 2013 um 10:54 Uhr
> Von: "Victor Stinner" 
> An: "Georg Brandl" 
> Cc: "Python Dev" 
> Betreff: Re: [Python-Dev] cpython: Issue #18408: Fix 
> PyUnicode_AsUTF8AndSize(), raise MemoryError exception on
>
> 2013/10/29 Georg Brandl :
> >> diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
> >> --- a/Objects/unicodeobject.c
> >> +++ b/Objects/unicodeobject.c
> >> @@ -3766,6 +3766,7 @@
> >>  return NULL;
> >>  _PyUnicode_UTF8(unicode) = 
> >> PyObject_MALLOC(PyBytes_GET_SIZE(bytes) + 1);
> >>  if (_PyUnicode_UTF8(unicode) == NULL) {
> >> +PyErr_NoMemory();
> >>  Py_DECREF(bytes);
> >>  return NULL;
> >>  }
> >
> > Shouldn't this (and related commits from #18408) have been committed to the 
> > 3.3
> > branch?
> 
> All changes of #18408 "should" be backported, but I don't plan to
> backport them. It is not trivial to backport them. Nobody complained
> before (memory allocation failure are usually bad handled anyway, it
> will crash later if it does not crash here). And I'm not 100%
> confident that these changes would not break anything.

OK, that's a good enough reason, if it's "only" no-memory-related errors.

> Examples of possible regression:
> 
> - PyEval_GetLocals() now raises an exception in case of an error. This
> change "should" not break anything, because callers were already
> raising an exception when PyEval_GetLocals() returns NULL. The builtin
> locals() function was not raising an exception in case of error, but
> it's probably because it is very unlikely that the function is called
> without any frame (PyEval_GetFrame(); returns NULL).
> 
> - many functions now fail with an assertion error when they are called
> with an exception set (assert(!PyErr_Occurred());) because they may
> replace the exception without noticing the caller
> 
> - I tried to check reference counters, but I may have introduce a
> regression leak in the error handling code
> 
> If there is really a regression, I prefer to limit it to the new
> version, not to a stable version.
> 
> Note: I'm not saying that I'm 0% confident in my changes :-)

And I certainly think they have a better than 0% chance of being correct ;)

Georg
___
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] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run

[Georg Brandl]

Am 05.11.2013 00:43, schrieb Terry Reedy:
> On 11/4/2013 5:15 PM, Nick Coghlan wrote:
> 
>> - I actually have "--no-commit" configured as a standard option for hg
>> import in my .hgrc file so I never forget
> 
> On Windows, hg uses .ini files. Do you have any idea what the
> [section]
> option = value
> would look like? There is gui dialog for managing the .ini files, but it 
> does not have a page for import options.

It'll look like this:

[defaults]
import = --no-commit

>> - "hg pull --rebase" avoids having a merge in the history for push races
>> that involve only default branch changes
> 
> Can this be done routinely for all pulls? Does it hurt if here are 
> working directory changes in 2 or 3 branches?

It won't work with merge commits, so if you locally commit to 3.3 and merge
to default, pull --rebase will error out if there are remote changes.

cheers,
Georg

___
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] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run

[Georg Brandl]

Am 05.11.2013 08:31, schrieb Terry Reedy:
> On 11/5/2013 12:50 AM, Georg Brandl wrote:
> 
>> [defaults]
>> import = --no-commit
> 
> Thank you. A message in a patch is now ignored rather than 
> auto-committed.

Yes; that's why I'd prefer the commit-and-then-amend way.

Georg


___
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] [RELEASED] Python 3.3.3 release candidate 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm quite happy to announce the
Python 3.3.3 release candidate 2.

Python 3.3.3 includes several security fixes and over 150 bug fixes compared to
the Python 3.3.2 release.

This release fully supports OS X 10.9 Mavericks.  In particular, this release
fixes an issue that could cause previous versions of Python to crash when typing
in interactive mode on OS X 10.9.

Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.  In total, almost 500 API items are new or improved
in Python 3.3.  For a more extensive list of changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.3 rc2 visit:

http://www.python.org/download/releases/3.3.3/


This is a preview release, please report any bugs to

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlKB1G4ACgkQN9GcIYhpnLAu5gCfRkfpnEs+rmtZ9iTjaaZcHDx3
sNYAn180Q4cFZmKtwJdaG+g/3jHAVd97
=n/Tt
-END PGP 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] The pysandbox project is broken

[Georg Brandl]

Am 13.11.2013 00:49, schrieb Josiah Carlson:
> Python-dev is for the development of the Python core language, the CPython
> runtime, and libraries. Your sandbox, despite using and requiring deep 
> knowledge
> of the runtime, is not developing those things. If you had a series of 
> requests
> for the language or runtime that would make your job easier, then your thread
> would be on-topic.

Can we please exempt core committers from these misdemeanor notices?

Thanks,
Georg

___
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] [RELEASED] Python 3.3.3 final

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm very happy to announce
the release of Python 3.3.3.

Python 3.3.3 includes several security fixes and over 150 bug fixes
compared to the Python 3.3.2 release. Importantly, a security bug in
CGIHTTPServer was fixed [1]. Thank you to those who tested the 3.3.3
release candidate!

This release fully supports OS X 10.9 Mavericks.  In particular, this
release fixes an issue that could cause previous versions of Python to
crash when typing in interactive mode on OS X 10.9.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  In total, almost 500 API items
are new or improved in Python 3.3.  For a more extensive list of
changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.3 rc2 visit:

http://www.python.org/download/releases/3.3.3/


This is a production release, please report any bugs to

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)


[1] http://bugs.python.org/issue19435
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlKLDGYACgkQN9GcIYhpnLCjewCfQ+EJHpzGzIyTvYOrYmsRmnbv
n40AniVM0UuQWpPrlCu349fu7Edt+d4+
=WSIj
-END PGP 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] [RELEASED] Python 3.3.3 final

[Georg Brandl]

Am 19.11.2013 17:14, schrieb Mark Lawrence:
> On 19/11/2013 06:59, Georg Brandl wrote:
>>
>> To download Python 3.3.3 rc2 visit:
>>
>>  http://www.python.org/download/releases/3.3.3/
>>
> 
> Please make your mind up, final or rc2?
> 
> Thanks everybody for your efforts, much appreciated :)

It's my firm belief that every announce should have a small error
to appease the gods of regression. *ahem*

:)
Georg

___
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] PEP process entry point and ill fated initiatives

[Georg Brandl]

Am 29.11.2013 10:16, schrieb Kristján Valur Jónsson:
> Reading the defect, I find people being unnecessarily obstructive. 
> 
> Closing the ticket, twice, is a rude, and unnecessary action.  How about
> acknowledging that these waters are dark and murky and help making things 
> better?
> 
> Surely, documenting processes can only be an improvement?
> 
> A lot has changed in open source development in the last 10 years.  The
> processes we have are starting to have the air of cathedral around them.

First, please note that many of Anatoly's tickets are not closed out of hand,
because they represent a valid issue.

In this specific case, the fact is simply that the PEP process has hardly
anything at all to do with the peps repository, and therefore looking for
PEP process info in its README.txt is irrelevant.  Yes, documenting processes
is good, and that's what the devguide is for.

The PEP process is all about discussion.  New developers who propose a PEP
typically do not submit a PEP directly but are encouraged to discuss their
idea first on python-ideas or python-dev.  There is no "entry point" problem
at all since they are then pointed to mail their draft to p...@python.org.

This is also why it does not make sense to open pull requests against the
repository (this may be what you allude to with your changes in 10 years).
The PEP repo is handled by the PEP editors (and other core committers).
New PEPs are checked for format and readability by the editors.

In short, this issue tries to address a problem where none exists, and that
is why it was closed.  I cannot see why you would call that unnecessary,
because I hope you don't think that the more open issues are languishing
in the tracker the better :)

cheers,
Georg

___
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] cpython (3.3): Issue #17576: Deprecation warning emitted now when __int__() or __index__()

[Georg Brandl]

Am 12.12.2013 16:22, schrieb R. David Murray:
> On Thu, 12 Dec 2013 10:54:05 +0200, Serhiy Storchaka  
> wrote:
>> 12.12.13 00:24, Antoine Pitrou МапО�ав(ла):
>> > On Wed, 11 Dec 2013 20:28:19 +0100 (CET)
>> > serhiy.storchaka  wrote:
>> >> http://hg.python.org/cpython/rev/618cca51a27e
>> >> changeset:   87899:618cca51a27e
>> >> branch:  3.3
>> >> parent:  87896:46186736e91c
>> >> user:Serhiy Storchaka 
>> >> date:Wed Dec 11 21:07:54 2013 +0200
>> >> summary:
>> >>Issue #17576: Deprecation warning emitted now when __int__() or 
>> >> __index__()
>> >> return not int instance.  Introduced _PyLong_FromNbInt() and refactored
>> >> PyLong_As*() functions.
>> >
>> > Is it ok to add deprecation warnings in bugfix versions?
>> 
>> Some clarifications. This is a precursor of a bugfix. I split a patch on 
>> two parts for simplicity. First part doesn't change behavior besides 
>> introducing warnings. Second part is simple and will change behavior (I 
>> still doubt how many behavior it should change).
> 
> That doesn't address the question of why the deprecation is added
> to a bug-fix release.  Normal policy is deprecate in the current
> feature release and make the change in the next feature release.
> 
> Is there a reason why the normal deprecation process should not be
> followed in this case?  It being a not-likely-to-be-encountered
> in-the-real-world bug could be one such reason, if the release
> managers agree.

I don't think it's useful to add the warning (although it won't break
anything).  Deprecations should be treated like features: their status
should only change in a minor (3.x.0) release.

Now the second part (changing behavior) also sounds potentially
dangerous :)

Georg

___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Georg Brandl]

Am 06.01.2014 14:24, schrieb Victor Stinner:
> Hi,
> 
> bytes % args and bytes.format(args) are requested by Mercurial and
> Twisted projects. The issue #3982 was stuck because nobody proposed a
> complete definition of the "new" features. Here is a try as a PEP.

Very nice, thanks.  If I was to make a blasphemous suggestion I would
even target it for Python 3.4.  (No, seriously, this is a big issue
- see the recent discussion by Armin - and the big names involved show
that it is a major holdup of 3.x uptake.)  It would of course depend
a lot on how much code from unicode formatting can be retained or
adapted as opposed to a rewrite from scratch.

cheers,
Georg


___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Georg Brandl]

Am 07.01.2014 10:59, schrieb Paul Moore:
> On 7 January 2014 09:40, Georg Brandl  wrote:
>> Very nice, thanks.  If I was to make a blasphemous suggestion I would
>> even target it for Python 3.4.  (No, seriously, this is a big issue
>> - see the recent discussion by Armin - and the big names involved show
>> that it is a major holdup of 3.x uptake.)  It would of course depend
>> a lot on how much code from unicode formatting can be retained or
>> adapted as opposed to a rewrite from scratch.
> 
> Will the relevant projects actually support only 2.X and 3.4/5+? If
> they expect to or have to support 3.2 or 3.3, then this change isn't
> actually going to help them much. If they will only support versions
> of Python 3 containing this change, then it may well be worth
> considering the impact of delaying it till 3.5.

Yes, exactly.

Another, and probably better, proposal would be to make 3.5 the
"ultimate" viable porting target: we now know pretty well what the
major remaining roadblocks (real and perceived) are for our developers
and users.

The proposal would be to focus entirely on addressing these roadblocks
in the 3.5 version, and no other new features -- the release cycle
needn't be 18 months for this one.  This is similar to the moratorium
for 3.2, but that one came too early for 3.x porting to really profit.

In short, I am increasingly concerned that although we are going a
pretty good way (and Nick's FAQ list makes that much clearer than
anything else I've read), but it is not perceived as such, and could
be better.  We have brought Python 3 on the community, and as such
we need to make it very very clear that we are working with them, not
against them.  A minor release dedicated to that end should be a
very direct representation of that.

I know about the "release everything to PyPI" strategy, but it just
doesn't have the same impact.

It would be very cool to have multiple projects working together with
us for this, and at the release of 3.5 final, present (say) a Mercurial
that works on 2.5 and 3.5.

Mostly pipe-dreams though...
Georg



___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Georg Brandl]

Am 07.01.2014 12:16, schrieb Antoine Pitrou:
> On Tue, 07 Jan 2014 11:33:55 +0100
> Georg Brandl  wrote:
>> 
>> The proposal would be to focus entirely on addressing these roadblocks
>> in the 3.5 version, and no other new features -- the release cycle
>> needn't be 18 months for this one.  This is similar to the moratorium
>> for 3.2, but that one came too early for 3.x porting to really profit.
> 
> The moratorium was for alternate Python implementations IIRC, not for
> porting third-party libraries.

Yes, but this would be a similar moratorium with another purpose.

>> It would be very cool to have multiple projects working together with
>> us for this, and at the release of 3.5 final, present (say) a Mercurial
>> that works on 2.5 and 3.5.
> 
> You seem to be forgetting that we are only one part of the equation
> here. Unless you want to tackle Mercurial and Twisted porting yourself?
> Good luck with that.

No no, I did not forget :)  that's why I wrote "working together with
them".  It would need to be coordinated with the external projects, but
from what I've seen there are willing people.

Georg


___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Georg Brandl]

Am 10.01.2014 18:56, schrieb Eric V. Smith:
> On 1/10/2014 12:17 PM, Juraj Sukop wrote:
>> (Sorry if this messes-up the thread order, it is meant as a reply to the
>> original RFC.)
>> 
>> Dear list,
>> 
>> newbie here. After much hesitation I decided to put forward a use case
>> which bothers me about the current proposal. Disclaimer: I happen to
>> write a library which is directly influenced by this.
>> 
>> As you may know, PDF operates over bytes and an integer or
>> floating-point number is written down as-is, for example "100" or "1.23".
>> 
>> However, the proposal drops "%d", "%f" and "%x" formats and the
>> suggested workaround for writing down a number is to use
>> ".encode('ascii')", which I think has two problems:
>> 
>> One is that it needs to construct one additional object per formatting
>> as opposed to Python 2; it is not uncommon for a PDF file to contain
>> millions of numbers.
>> 
>> The second problem is that, in my eyes, it is very counter-intuitive to
>> require the use of str only to get formatting on bytes. Consider the
>> case where a large bytes object is created out of many smaller bytes
>> objects. If I wanted to format a part I had to use str instead. For example:
>> 
>> content = b''.join([
>> b'header',
>> b'some dictionary structure',
>> b'part 1 abc',
>> ('part 2 %.3f' % number).encode('ascii'),
>> b'trailer'])
> 
> I agree. I don't see any reason to exclude int and float. See Guido's
> messages http://bugs.python.org/issue3982#msg180423 and
> http://bugs.python.org/issue3982#msg180430 for some justification and
> discussion. Since converting int and float to strings generates a very
> small range of ASCII characters, ([0-9a-fx.-=], plus the uppercase
> versions), what problem is introduced by allowing int and float? The
> original str.format() work relied on this fact in its stringlib
> implementation.

I agree.

I would have needed bytes-formatting (with numbers) recently writing .rtf files.

Georg

___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Georg Brandl]

Am 11.01.2014 03:04, schrieb Antoine Pitrou:
> On Fri, 10 Jan 2014 20:53:09 -0500
> "Eric V. Smith"  wrote:
>> 
>> So, I'm -1 on the PEP. It doesn't address the cases laid out in issue
>> 3892. See for example http://bugs.python.org/issue3982#msg180432 .

I agree.

> Then we might as well not do anything, since any attempt to advance
> things is met by stubborn opposition in the name of "not far enough".
> 
> (I don't care much personally, I think the issue is quite overblown
> anyway)

So you wouldn't mind another overhaul of the PEP including a bit more
functionality again? :)  I really think that practicality beats purity
here.  (I'm not advocating free mixing bytes and str, mind you!)

Georg

___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Georg Brandl]

Am 11.01.2014 09:43, schrieb Nick Coghlan:
> On 11 January 2014 12:28, Ethan Furman  wrote:
>> On 01/10/2014 06:04 PM, Antoine Pitrou wrote:
>>>
>>> On Fri, 10 Jan 2014 20:53:09 -0500
>>> "Eric V. Smith"  wrote:


 So, I'm -1 on the PEP. It doesn't address the cases laid out in issue
 3892. See for example http://bugs.python.org/issue3982#msg180432 .
>>>
>>>
>>> Then we might as well not do anything, since any attempt to advance
>>> things is met by stubborn opposition in the name of "not far enough".
>>
>>
>> Heh, and here I thought it was stubborn opposition in the name of purity.
>> ;)
> 
> No, it's "the POSIX text model is completely broken and we're not
> letting people bring it back by stealth because they want to stuff
> their esoteric use case back into the builtin data types instead of
> writing their own dedicated type now that the builtin types don't
> handle it any more".
> 
> Yes, we know we changed the text model and knocked wire protocols off
> their favoured perch, and we're (thoroughly) aware of the fact that
> wire protocol developers don't like the fact that the default model
> now strongly favours the vastly more common case of application
> development.
> 
> However, until Benno volunteered to start experimenting with
> implementing an asciistr type yesterday, there have been *zero*
> meaningful attempts at trying to solve the issues with wire protocol
> manipulation outside the Python 3 core

Can we please also include pseudo-binary file formats?  It's not "just"
wire protocols.

Georg

___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Georg Brandl]

Am 11.01.2014 10:44, schrieb Stephen Hansen:

> I mean, its not like the "bytes" type lacks knowledge of the subset of bytes
> that happen to be 7-bit ascii-compatible and can't perform text-ish operations
> on them--
> 
>   Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit
> (Intel)] on win32
>   Type "help", "copyright", "credits" or "license" for more information.
>   >>> b"stephen hansen".title()
>   b'Stephen Hansen'
> 
> How is this not a practical recognition that yes, while bytes are byte streams
> and not text, a huge subset of bytes are text-y, and as long as we maintain 
> the
> barrier between higher characters and implicit conversion therein, we're fine?
> 
> I don't see the difference here. There is a very real, practical need to
> interpolate bytes. This very real, practical need includes the very real
> recognition that converting 12345 to b'12345' is not something weird, unusual,
> and subject to the thorny issues of Encodings. It is not violating the 
> doctrine
> of separation of powers between Text and Bytes.

This. Exactly. Thanks for putting it so nicely, Stephen.

Georg

___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Georg Brandl]

Am 11.01.2014 14:49, schrieb Georg Brandl:
> Am 11.01.2014 10:44, schrieb Stephen Hansen:
> 
>> I mean, its not like the "bytes" type lacks knowledge of the subset of bytes
>> that happen to be 7-bit ascii-compatible and can't perform text-ish 
>> operations
>> on them--
>> 
>>   Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 
>> bit
>> (Intel)] on win32
>>   Type "help", "copyright", "credits" or "license" for more information.
>>   >>> b"stephen hansen".title()
>>   b'Stephen Hansen'
>> 
>> How is this not a practical recognition that yes, while bytes are byte 
>> streams
>> and not text, a huge subset of bytes are text-y, and as long as we maintain 
>> the
>> barrier between higher characters and implicit conversion therein, we're 
>> fine?
>> 
>> I don't see the difference here. There is a very real, practical need to
>> interpolate bytes. This very real, practical need includes the very real
>> recognition that converting 12345 to b'12345' is not something weird, 
>> unusual,
>> and subject to the thorny issues of Encodings. It is not violating the 
>> doctrine
>> of separation of powers between Text and Bytes.
> 
> This. Exactly. Thanks for putting it so nicely, Stephen.

To elaborate: if the bytes type didn't have all this ASCII-aware functionality
already, I think we would have (and be using) a dedicated "asciistr" type right
now.  But it has the functionality, and it's way too late to remove it.

Georg


___
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] PEP 460: allowing %d and %f and NOT ALLOWING mojibake :)

[Georg Brandl]

Am 11.01.2014 18:41, schrieb Victor Stinner:
> Hi,
> 
> I'm in favor of adding support of formatting integer and floatting
> point numbers in the PEP 460: %d, %u, %o, %x, %f with padding and
> precision (%10d, %010d, %1.5f) and sign (%-i, %+i) but without
> alternate format ("{:#x}"). %s would also accept int and float for
> convenience.
> 
> int and float subclasses would not be handled differently, their
> __str__ and __format__ would be ignored.
> 
> Other int-like and float-like types (ex: defining __int__ or
> __index__) are not supported. Explicit cast would be required.
> 
> For %s, the choice between string and number is made using
> "(PyLong_Check() || PyFloat_Check())".
> 
> If you agree, I will modify the PEP. If Antoine disagree, I will fork
> the PEP 460 ;-)
> 
> ---
> 
> %s should not support precision (ex: %.100s), use Unicode for that.
> 
> ---
> 
> The PEP 460 should not reintroduce bytes+unicode, implicit decoding or
> implement encoding.
> 
> b'x=%s' % 10 is well defined, it's pure bytes. If you consider that
> bytes should not contain text, why does the bytes type have methods
> like isalpha() or upper()? And why binary files have a readline()
> method? A "line" doesn't mean anything in pure bytes.
> 
> It's an example of "practicality beats purity". Python 3 should not
> enforce Unicode if the developers *chose* to use bytes to handle mixed
> binary/text protocols like HTTP.
> 
> But I'm against of adding "%r" and "%a" because they use Unicode and
> would require an implicit encoding. type(ascii(obj)) is str, not
> bytes. If you really want to use repr() and ascii(), encode the result
> explicitly.

I agree. For non-ASCII characters what ascii() gives you is almost always
not what you want anyway.

Georg


___
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] PEP 460: allowing %d and %f and mojibake

[Georg Brandl]

Am 11.01.2014 20:22, schrieb Antoine Pitrou:
> On Sat, 11 Jan 2014 10:38:01 -0800
> Ethan Furman  wrote:
>> On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
>> > On Sat, 11 Jan 2014 18:41:49 +0100
>> > Victor Stinner  wrote:
>> >>
>> >> If you agree, I will modify the PEP. If Antoine disagree, I will fork
>> >> the PEP 460 ;-)
>> >
>> > Please fork it.
>> 
>> You've already stated you don't care that much and are willing to let the 
>> PEP as-is be rejected.  Why not remove your 
>> name and let Victor have it back?  Is he not the original author?  (If this 
>> is protocol just say so -- remember I'm 
>> still new to the ways of PyDev. :).
> 
> Because the PEP is IMO a much saner compromise than what you're
> trying to do (and would also stand a better chance of being accepted,
> if it weren't for your stupid maximalist opposition).

Can you please stop throwing personal insults around?  You don't have to
resort to that level.

Georg

___
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] PEP 460: allowing %d and %f and mojibake

[Georg Brandl]

Am 11.01.2014 22:01, schrieb Serhiy Storchaka:
> 11.01.14 21:40, Kristján Valur Jónsson написав(ла):
>> How about a compromise?
>> Personally, I think adding the full complement of integer/float formatting 
>> to bytes is a bit over the top.
>> How about just supporting two format specifiers?
>> %b : interpolate a bytes object.  If it doesn't have the buffer interface, 
>> error.
>> %s : interpolate a str object, encoded to ASCII using 'strict' conversion.
> 
> %b is not supported in Python 2.7. And compatibility with Python 2.7 is 
> only the purpose of this feature.

Not "only", but it is certainly an important one.

Georg

___
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] cpython (3.3): Update Sphinx toolchain.

[Georg Brandl]

Am 11.01.2014 21:11, schrieb Terry Reedy:
> On 1/11/2014 2:04 PM, georg.brandl wrote:
>> http://hg.python.org/cpython/rev/87bdee4d633a
>> changeset:   88413:87bdee4d633a
>> branch:  3.3
>> parent:  88410:05e84d3ecd1e
>> user:Georg Brandl 
>> date:Sat Jan 11 20:04:19 2014 +0100
>> summary:
>>Update Sphinx toolchain.
>>
>> files:
>>Doc/Makefile |  8 
>>1 files changed, 4 insertions(+), 4 deletions(-)
>>
>>
>> diff --git a/Doc/Makefile b/Doc/Makefile
>> --- a/Doc/Makefile
>> +++ b/Doc/Makefile
>> @@ -41,19 +41,19 @@
>>   checkout:
>>  @if [ ! -d tools/sphinx ]; then \
>>echo "Checking out Sphinx..."; \
>> -  svn checkout $(SVNROOT)/external/Sphinx-1.0.7/sphinx tools/sphinx; \
>> +  svn checkout $(SVNROOT)/external/Sphinx-1.2/sphinx tools/sphinx; \
>>  fi
> 
> Doc/make.bat needs to be similarly updated.

Indeed, thanks for the reminder.

Georg

___
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] cpython (3.3): Update Sphinx toolchain.

[Georg Brandl]

Planned :)

Georg

Am 12.01.2014 09:12, schrieb INADA Naoki:
> What about using venv and pip instead of svn?
> 
> 
> On Sun, Jan 12, 2014 at 4:12 PM, Georg Brandl  <mailto:g.bra...@gmx.net>> wrote:
> 
> Am 11.01.2014 21:11, schrieb Terry Reedy:
> > On 1/11/2014 2:04 PM, georg.brandl wrote:
> >> http://hg.python.org/cpython/rev/87bdee4d633a
> >> changeset:   88413:87bdee4d633a
> >> branch:  3.3
> >> parent:  88410:05e84d3ecd1e
> >> user:Georg Brandl mailto:ge...@python.org>>
> >> date:Sat Jan 11 20:04:19 2014 +0100
> >> summary:
> >>Update Sphinx toolchain.
> >>
> >> files:
> >>Doc/Makefile |  8 
> >>1 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >>
> >> diff --git a/Doc/Makefile b/Doc/Makefile
> >> --- a/Doc/Makefile
> >> +++ b/Doc/Makefile
> >> @@ -41,19 +41,19 @@
> >>   checkout:
> >>  @if [ ! -d tools/sphinx ]; then \
> >>echo "Checking out Sphinx..."; \
> >> -  svn checkout $(SVNROOT)/external/Sphinx-1.0.7/sphinx 
> tools/sphinx; \
> >> +  svn checkout $(SVNROOT)/external/Sphinx-1.2/sphinx 
> tools/sphinx; \
> >>  fi
> >
> > Doc/make.bat needs to be similarly updated.
> 
> Indeed, thanks for the reminder.
> 
> Georg
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org <mailto:Python-Dev@python.org>
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> 
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
> 
> 
> 
> 
> -- 
> INADA Naoki  mailto:songofaca...@gmail.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] PEP 460: allowing %d and %f and mojibake

[Georg Brandl]

Am 12.01.2014 09:57, schrieb Paul Moore:
> On 12 January 2014 01:01, Victor Stinner  wrote:
>> Supporting formating integers would allow to write b"Content-Length:
>> %s\r\n" % 123, which would work on Python 2 and Python 3.
> 
> I'm surprised that no-one is mentioning b"Content-Length: %s\r\n" %
> str(123) which works on Python 2 and 3, is explicit, and needs no
> special-casing of int in the format code.

Certainly doesn't work on Python 3 right now, and never should :)

Georg

___
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] cpython (3.3): Update Sphinx toolchain.

[Georg Brandl]

That's also planned, see https://bitbucket.org/birkenfeld/sphinx-new-make-mode/.

Georg

Am 12.01.2014 09:49, schrieb anatoly techtonik:
> And cross-platform automation tools in Python instead of make
> https://bitbucket.org/birkenfeld/sphinx/issue/456/makepy-command-script
> --
> anatoly t.
> 
> 
> On Sun, Jan 12, 2014 at 11:12 AM, INADA Naoki  wrote:
>> What about using venv and pip instead of svn?


___
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] PEP 460: allowing %d and %f and mojibake

[Georg Brandl]

Am 12.01.2014 20:30, schrieb Emile van Sebille:
> On 01/12/2014 09:26 AM, Paul Moore wrote:
>> Can you give an example of code that is *nearly* acceptable to you,
>> which works in Python 2 and 3 today, and explain what improvements you
>> would like to see to it in order to use it instead of waiting for a
>> core change?
> 
> 
> I'm not a developer, but I'm trying to understand how in v3 I accomplish 
> what in v2 is easy:
> 
> len(open('chars','wb').write("".join(map (chr,range(256.read())
> 
> What's the v3 equivalent?

That's actually very easy and shows a strength of the bytes type,
since there's no text involved:

open('chars', 'wb').write(bytes(range(256)))

Georg

___
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] PEP 460 reboot

[Georg Brandl]

Am 13.01.2014 18:38, schrieb Ethan Furman:
> On 01/13/2014 09:31 AM, Antoine Pitrou wrote:
>> On Mon, 13 Jan 2014 08:36:05 -0800 Ethan Furman wrote:
>>> 
>>> You mean crash all the time?  I'd be fine with that for both the str
>>> case and the bytes case.  But's probably too late to change the str case,
>>> and the bytes case should mirror what str does.
>> 
>> Let me add something else: str and bytes don't have to be symmetrical. In
>> Python 2, str and unicode were symmetrical, they allowed exactly the same
>> operations and were composable. In Python 3, str and bytes are different
>> beasts; they have different operations *and* different semantics (for
>> example, bytes interoperates with bytearray and memoryview, while str
>> doesn't).
> 
> This makes sense to me.
> 
> So I'm guess I'm fine with either the quoted ascii repr or the always blowing
> up method, with leaning towards the blowing up method.

+1.

Georg

___
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] cpython (3.3): Update Sphinx toolchain.

[Georg Brandl]

[If you want to continue this discussio, please move it from python-dev to
sphinx-users.  It is now completely offtopic for the former.]

Anyway, just as a short explanation, you missed the point of the change:
-M is not meant to be used directly but still via a (very short)
Makefile.  This isn't be a change meant to be visible to users.

Georg

Am 13.01.2014 20:56, schrieb anatoly techtonik:
> That's cool, but historical heritage makes the make argument
> somewhat confusing for new users. The immediate question I
> can sense is "What is the difference between build and make?"
> 
> To make (this word again) the critics constructive, let me pass
> some ideas about ideal user experience as I see it.
> 
> --[installation]--
> 1   I install Sphinx. Two scenarios.
>1.1   I am not a Python user - use installer
>   1.1.1   Installer should obviously install Python
>   1.1.2   And install sphinx command
>   1.1.3   And add sphinx to PATH
>1.2   I am a Python user - use pip
>   1.2.1   pip should not alter my PATH (for virtualenv)
> 
> --[usage]--
> 2   Two scenarios
>2.1   sphinx as a system command from PATH
>2.2   "python -m sphinx" for current virtualenv / test config
> 
> --[user experience]--
> 3   These two invocations are equal
>> sphinx
>> python -m sphinx
> 
> 4. They give the following ouput
>>
> Sphinx 1.2 Documentation Generator
> 
> Commands:
> 
>build   build documentation
>init start new project [also quickstart]
>make  helper for common build commands
> 
> Use "sphinx -h command" or "sphinx command --help" for details
> 
> 
> I am not using sphinx ATM otherwise I'd spent more time to
> design ideal command set to get rid of build/make duality, but
> it should work ok.
> 
> Actually "sphinx" is a new command, so you may rethink the
> syntax for "build" arguments to contain "html" instead of dir names,
> and move dir names into parameters, because it is how it is most
> often used.
> 
> --
> anatoly t.
> 
> 
> On Sun, Jan 12, 2014 at 4:53 PM, Georg Brandl  wrote:
>> That's also planned, see 
>> https://bitbucket.org/birkenfeld/sphinx-new-make-mode/.
>>
>> Georg
>>
>> Am 12.01.2014 09:49, schrieb anatoly techtonik:
>>> And cross-platform automation tools in Python instead of make
>>> https://bitbucket.org/birkenfeld/sphinx/issue/456/makepy-command-script
>>> --
>>> anatoly t.
>>>
>>>
>>> On Sun, Jan 12, 2014 at 11:12 AM, INADA Naoki  
>>> wrote:
>>>> What about using venv and pip instead of svn?
>>
>>
>> ___
>> 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/techtonik%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] Changing Clinic's output

[Georg Brandl]

Am 14.01.2014 21:22, schrieb Larry Hastings:
> 
> On 01/11/2014 07:35 PM, Larry Hastings wrote:
>>
>> On 01/08/2014 07:08 AM, Barry Warsaw wrote:
>>> How hard would it be to put together some sample branches that provide
>>> concrete examples of the various options?
>>>
>>> My own opinion could easily be influenced by having some hands-on time with
>>> actual code, and I suspect even Guido could be influenced if he could pull
>>> some things up in his editor and take a look around.
>>
>> I've uploaded a prototype here:
>>
>> https://bitbucket.org/larry/python-clinic-buffer
>>
> 
> 
> I have now received exactly zero feedback about the prototype, which suggests
> people aren't using it.  In an attempt to jump-start this conversation, I've
> created a new repository containing the "concrete examples of the various
> options" that Barry proposed above.  You may find it here:
> 
> https://bitbucket.org/larry/clinic-buffer-samples/src
> 
> In it I converted Modules/_pickle.c four different ways.  There's a README,
> please read it.
> 
> People who want to change how Clinic writes its output: this is your big
> chance.  Comment on these samples, or produce your own counterexamples, or
> something.  If you can enough people on your side maybe Clinic will change.  
> If
> there is no further debate on this topic, nothing will happen and Clinic will
> not change.

Having converted several modules to AC, I think I'm

-1 original
+0 sidefile
+1 multiple buffers
+0 buffer
-0 modified buffer

Georg

___
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] AC Derby and accepting None for optional positional arguments

[Georg Brandl]

Am 16.01.2014 05:35, schrieb Ryan Smith-Roberts:
> On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts  > wrote:
> 
> socket.getservbyname(servicename[, protocolname])
> ->
> socket.getservbyname(servicename, protocolname=None)
> 
> 
> Here is a more complicated example, since the above does technically have an
> alternative fix:
> 
> sockobj.sendmsg(buffers[, ancdata[, flags[, address]]])
> ->
> sockobj.sendmsg(buffers, ancdata=None, flags=0, address=None)

As far as I understand you should convert these with the "optional group" syntax
(i.e. brackets).

Georg

___
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] AC Derby and accepting None for optional positional arguments

[Georg Brandl]

Am 16.01.2014 12:39, schrieb Antoine Pitrou:
> On Thu, 16 Jan 2014 04:42:43 -0500
> Terry Reedy  wrote:
> 
>> On 1/16/2014 3:31 AM, Serhiy Storchaka wrote:
>> > 16.01.14 08:05, Guido van Rossum написав(ла):
>> >> In this specific case it's clear to me that the special-casing of
>> >> negative count is intentional -- presumably it emulates sequence
>> >> repetition, where e.g. 'a'*-1 == ''.
>> >
>> > In this specific case it's contrary to sequence repetition. Because
>> > repeat('a', -1) repeats 'a' forever.
>> 
>> 'Forever' only when the keyword is used and the value is -1.
>> In 3.4b2
>> 
>>  >>> itertools.repeat('a', -1)
>> repeat('a', 0)
>>  >>> itertools.repeat('a', times=-1)
>> repeat('a')
>>  >>> itertools.repeat('a', times=-2)
>> repeat('a', -2)
> 
> Looks like a horrible bug to me. Passing an argument by position should
> mean the same as passing it by keyword!

Indeed, that should be fixed regardless of AC.

Georg

___
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] python code in argument clinic annotations

[Georg Brandl]

Am 16.01.2014 20:46, schrieb Yury Selivanov:
> Guido,
> 
> On Thursday, January 16, 2014, Guido van Rossum  > wrote:
> 
> On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov
> > wrote:
> > The whole discussion of whether clinic should write its output
> > right in the source file (buffered or not), or in a separate sidefile,
> > started because we currently cannot run the clinic during the build
> > process, since it’s written in python.
> 
> But that's why the output is checked in. It's the same with the parser
> IIRC. (And yes, there's a bootstrap issue -- but that's solved by
> using an older Python version.)
> 
> > But what if, at some point, someone implements the Tools/clinic.py in
> > pure C, so that integrating it directly in the build process will be
> > possible?  In this case, the question is — should we use python code
> > in the argument clinic DSL?
> >
> > If we keep it strictly declarative, then, at least, we’ll have this
> > possibility in the future.
> 
> Sounds like a pretty unlikely scenario. Why would you implement clinic in 
> C?
> 
> 
> Unlikely, yes.

About as unlikely as switching the Python sources to C++ and using templates
to implement a Clinic-like DSL :)

Georg

___
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] Closing the Clinic output format debate (at least for now)

[Georg Brandl]

Am 16.01.2014 22:20, schrieb Larry Hastings:
> On 01/16/2014 12:13 PM, Larry Hastings wrote:
>>
>>
>> The current tally of votes, by order of popularity:
>>
>> Side file: +6
>> Buffer: +1.5
>> Multiple buffers, Modified buffer, Forward buffer: +1
>> Original: -5
>>
> 
> I should add, that's out of a total of eleven votes cast.  So the side file 
> was
> a clear winner but far from unanimous.
> 
> Since the votes were all public, the tally might as well be to.  Here it is in
> handy "CSV" format:
> 
> "Names", Original", "Side File", "Buffer", "Multiple Buffers", "Modified
> Buffer", "Forward Buffer"
> "Totals", -5, 6, 1.5, 1, 1, 1
>     "Brett Cannon", 0, 0, 1, 1, 0, 0
> "Antoine Pitrou", -0.5, 1, 0, 0, 0, 0
> "Raymond Hettinger", -1, 1, 0, 0, 0, 0
> "Zachary Ware", -1, 0, 1, 1, 0, 0
> "Georg Brandl", -1, 0, 0, 1, 0, 0
> "Serhiy Storchaka", -1, 1, 0, 0, 0, 0
> "Yury Selivanov", 0, 1, -1, -1, -1, 0
> "Ryan Smith-Roberts", 1, 0, 0, -1, 1, 1
> "Ethan Furman", 0, 0, 0.5, 0, 1, 0
> "Meador Inge", -0.5, 1, 0, 0, 0, 0
> "Stefan Krah", -1, 1, 0, 0, 0, 0

Although this is neglecting the difference between +0 and -0 :)

Georg


___
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] .clinic.c vs .c.clinic

[Georg Brandl]

Am 19.01.2014 11:19, schrieb Larry Hastings:
> On 01/18/2014 10:36 PM, Nick Coghlan wrote:
>> On 19 January 2014 10:44, Steve Dower  wrote:
>>> Visual Studio will try to compile them if they end with .c, though this can
>>> be disabled on a per-file basis in the project file. Files ending in .h
>>> won't be compiled, though changes should be detected and cause the .c files
>>> that include them to be recompiled.
>> That sounds like a rather good argument for .clinic.h over .clinic.c :)
>>
>> My assessment of the thread is that .clinic.h will give us the best
>> overall tool compatibility.
> 
> Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h".
> 
> But there's one onion in the ointment: what should "foo.h" generate?  The day
> may yet arrive when we have Argument Clinic code in foo.{ch}.
> 
> Not kidding, my best idea so far is "foo.clinic.h.h",

Why not always put clinic into its own directory?

Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h
Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h

At least that is consistent, allows easy exclusion in tools, and gets rid
of the additional "clinic" in the filename.

Georg

___
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] .clinic.c vs .c.clinic

[Georg Brandl]

Am 20.01.2014 09:05, schrieb Larry Hastings:
> 
> On 01/19/2014 08:29 AM, Ethan Furman wrote:
>> On 01/19/2014 03:32 AM, Georg Brandl wrote:
>>> Am 19.01.2014 11:19, schrieb Larry Hastings:
>>>> Not kidding, my best idea so far is "foo.clinic.h.h",
>>>
>>> Why not always put clinic into its own directory?
>>>
>>> Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h
>>> Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
>>>
>>> At least that is consistent, allows easy exclusion in tools, and gets rid
>>> of the additional "clinic" in the filename.
>>
>> +1
>>
>> If AC will work with both .c and .h files. I think a separate directory is 
>> the
>> way to go.
> 
> In theory, Argument Clinic works with any file for which it can iterate over 
> by
> lines and recognize comments.  It current supports C and Python files and
> automatically recognizes a bunch of extensions.
> 
> 
> 
> Okay, I'm taking a poll.  I will total your answers and take the result...
> strongly under advisement. ;-)
> 
> The rules:
> * The poll will be over in 48 hours, maybe sooner if a winner emerges early.
> * Please express your vote from -1 to +1.  -0 and +0 will only be 
> differentiated
> during a tiebreaker.
> * If you don't vote for a contestant, your vote will be assumed to be 0.
> * You may change your vote at any time while the poll is still running.
> * If you wish to nominate a new contestant, you may.  Please give the 
> contestant
> a name, and express how it would transform the filenames "foo.c" and "foo.h". 
>  I
> would strongly prefer that all transformations be expressable using
> str.format(transformation, filename="foo.c", basename="foo", extension=".c") .
> 
> 
> The contestants so far:
> 
> Contestant 1: "Add .clinic.h"
> 
> foo.c -> foo.c.clinic.h
> foo.h -> foo.h.clinic.h

-0.  (Clutters the directory.)

> Contestant 2: "Add .ac.h"
> 
> foo.c -> foo.c.ac.h
> foo.h -> foo.h.ac.h

-1.  (Autoconf...)

> Contestant 3: "Add .clinic"
> 
> foo.c -> foo.c.clinic
> foo.h -> foo.h.clinic

-1.  (Doesn't get included in global *.[ch] search, clutters the directory.)

> Contestant 4: "Put in clinic directory, add .h"
> 
> foo.c -> clinic/foo.c.h
> foo.h -> clinic/foo.h.h

+1.

> Contestant 5: "Put in __clinic__ directory, add .h"
> 
> foo.c -> __clinic__/foo.c.h
> foo.h -> __clinic__/foo.h.h

-1.  (Too complicated; this isn't Python packages we're talking about.)

Georg

___
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] .clinic.c vs .c.clinic

[Georg Brandl]

Am 20.01.2014 14:31, schrieb Serhiy Storchaka:
> 20.01.14 15:03, Nick Coghlan написав(ла):
>> On 20 January 2014 21:14, Serhiy Storchaka  wrote:
>>> 20.01.14 10:05, Larry Hastings написав(ла):
 Contestant 4: "Put in clinic directory, add .h"

  foo.c -> clinic/foo.c.h
  foo.h -> clinic/foo.h.h
>>>
>>>
>>> -1. (Generated files are located far from origins, directory name clutters
>>> the namespace of directory names).
>>
>> Larry's not talking about a top level directory here (at least I hope
>> he isn't). This proposal would mean using "Objects/clinic",
>> "Python/clinic", "Modules/clinic" as appropriate.
> 
> This means the appearance of directories with the common name "clinic" 
> in random places of the source tree. Some special name ("__clinic__", 
> ".clinic") looks slightly less confusing to me.

"clinic" shouldn't be such a common name in C soures :)

Georg

___
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] .clinic.c vs .c.clinic

[Georg Brandl]

Am 20.01.2014 21:05, schrieb Ethan Furman:
> On 01/20/2014 11:46 AM, Brett Cannon wrote:
>> On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote:
>>> On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
>>>
 Contestant 5: "Put in __clinic__ directory, add .h"

foo.c -> __clinic__/foo.c.h
foo.h -> __clinic__/foo.h.h
>>>
>>> This is cached output right?
>>
>> Yes, it's generated entirely based on data provided
>>  in original source file.
>>
>>> IOW, it can be regenerated if it's missing.  If so,
>>>  this seems like a nice parallel to __pycache__.
>>>  It's mostly hidden until you want to go looking for it.
>>
>> More-or-less. The key difference is you will most likely
>> look at the generated file *once* to copy-and-paste the
>> relevant macros to paste into your source file for use
>>  (e.g. the relevant MethodDef stuff). But it's a one-time
>> thing that never has to be done again as long as you don't
>>  rename a function or method.
> 
> Won't AC put those macros in the source file for you?

No, currently it wouldn't know where to look.  And that's a good thing
because AC never should modify anything not inbetween "clinic start
generated code" and "clinic end generated code".

But Larry has said that in the future the wohl PyMethodDef array might
be generated by AC in a separate block (that you have to indicate in
the file as well).

Georg



___
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] .clinic.c vs .c.clinic

[Georg Brandl]

Am 20.01.2014 22:47, schrieb Ethan Furman:

>>> Won't AC put those macros in the source file for you?
>>
>> No, currently it wouldn't know where to look.  And that's a good thing
>> because AC never should modify anything not inbetween "clinic start
>> generated code" and "clinic end generated code".
> 
> So, if I understand correctly, by moving into a sidefile approach, we will
> have go to a two-pass system?  Once to ACify the file and run Argument
> Clinic on it, and then again to add in the macros?

No. It is completely the same as in the current all-in-one-file approach.

> Is this basically the same as it was with the buffer approach?

It's the same as it always was.

Georg

___
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] .clinic.c vs .c.clinic

[Georg Brandl]

Am 20.01.2014 09:15, schrieb Georg Brandl:

>> Contestant 5: "Put in __clinic__ directory, add .h"
>> 
>> foo.c -> __clinic__/foo.c.h
>> foo.h -> __clinic__/foo.h.h
> 
> -1.  (Too complicated; this isn't Python packages we're talking about.)

Make that +0.

Georg

___
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] [Python-checkins] Cron /home/docs/build-devguide

[Georg Brandl]

Am 25.01.2014 05:49, schrieb Benjamin Peterson:
> On Fri, Jan 24, 2014, at 08:45 PM, Cron Daemon wrote:
>> Could not find platform independent libraries 
>> Could not find platform dependent libraries 
>> Consider setting $PYTHONHOME to [:]
>> 'import site' failed; use -v for traceback
>> Traceback (most recent call last):
>>   File "/data/hg/sphinx-env/bin/sphinx-build", line 5, in 
>> from pkg_resources import load_entry_point
>> ImportError: No module named pkg_resources
> 
> I recreated the sphinx virtualenv on dinsdale, so hopefully this will be
> fixed now.

Thanks, this somehow slipped by me.

Georg

___
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] version numbers mismatched in google search results.

[Georg Brandl]

Am 25.01.2014 17:12, schrieb Benjamin Peterson:
> On Sat, Jan 25, 2014, at 05:47 AM, Vincent Davis wrote:
>> When I do a google search the version numbers are mismatched with the
>> linked page (or redirected).
>> For example search for "python counter" I get the following results. (see
>> attachment)
>> It seems like the website is redirecting incorrectly.
> 
> Internal links with no version redirect to the Python 2 version for
> backwards compatibility reasons.

Yep, and the URLs without version never served Python 3 docs as far as I can
remember, so I don't know where Google has these s from.

Georg

___
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] [RELEASED] Python 3.3.4 release candidate 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm reasonably happy to announce the
Python 3.3.4 release candidate 1.

Python 3.3.4 includes several security fixes and over 120 bug fixes compared to
the Python 3.3.3 release.

This release fully supports OS X 10.9 Mavericks.  In particular, this release
fixes an issue that could cause previous versions of Python to crash when typing
in interactive mode on OS X 10.9.

Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.  In total, almost 500 API items are new or improved
in Python 3.3.  For a more extensive list of changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

and for the detailed changelog of 3.3.4, see

http://docs.python.org/3.3/whatsnew/changelog.html

To download Python 3.3.4 rc1 visit:

http://www.python.org/download/releases/3.3.4/

This is a preview release, please report any bugs to

 http://bugs.python.org/

The final version is scheduled to be released in two weeks' time, on or about
the 10th of February.

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlLmDI4ACgkQN9GcIYhpnLAr6wCePRbHF80k5goV4RUDBA5FfkwF
rLUAnRg0RpL/b6apv+Dt2/sgnUd3hTPA
=Z4Ss
-END PGP 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

[Georg Brandl]

Am 27.01.2014 13:12, schrieb Antoine Pitrou:
> On Mon, 27 Jan 2014 04:01:02 -0800
> Larry Hastings  wrote:
>> 
>> On 01/27/2014 01:39 AM, Antoine Pitrou wrote:
>> > On Sun, 26 Jan 2014 21:01:08 -0800
>> > Larry Hastings  wrote:
>> >> On 01/26/2014 08:40 PM, Alexander Belopolsky wrote:
>> >>> On Sun, Jan 26, 2014 at 11:26 PM, Vajrasky Kok
>> >>> mailto:sky@speaklikeaking.com>> wrote:
>> >>>
>> >>>  In case we are taking "not backporting anything at all" road, what 
>> >>> is
>> >>>  the best fix for the document?
>> >>>
>> >>>
>> >>> I would say no fix is needed for this doc because the signature
>> >>> suggests (correctly) that passing times by keyword is not supported.
>> >> Where does it do that?
>> > In the "[,times]" spelling, which is the spelling customarily used for
>> > positional-only arguments.
>> 
>> That's not my experience.
> 
> But it's mine :-) (try "help(str)" or "help(list)")

It's also the convention we've been using for the docs.

Georg


___
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] [RELEASED] Python 3.3.4 release candidate 1

[Georg Brandl]

Am 29.01.2014 20:12, schrieb Serhiy Storchaka:
> 29.01.14 18:55, Andrew Svetlov написав(ла):
>> Would you to accept fixes for http://bugs.python.org/issue20434 and
>> http://bugs.python.org/issue20437 before 3.3.4 final?
> 
> And http://bugs.python.org/issue20440.

No, sorry; these bugs are not regressions in 3.3.4 and have been there at
least the whole 3.3 line (I think), so their fixes might do more harm than
good if *they* are faulty.

They are fine for 3.3.5 which is not too far away anyway.

Georg

___
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] The docstring hack for signature information has to go

[Georg Brandl]

Am 04.02.2014 10:12, schrieb Larry Hastings:

> If you won't let me have a flag, can I at least have a more-clever marker?  
> How
> about this:
> 
> (...)\n \n
> 
> Yes, the last four characters are right-parenthesis, newline, space, and
> newline.  Benefits:
> 
>   * The odds of finding *that* in the wild seem remote.
>   * If this got displayed as help in 3.3 the user would never notice the 
> space.

Clever, but due to the "hidden" space it also increases the frustration factor
for people trying to find out "why is this accepted as a signature and not 
this".

I don't think a well-chosen visible separator is worse off, such as "--\n".

Georg

___
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] The docstring hack for signature information has to go

[Georg Brandl]

Am 04.02.2014 13:14, schrieb Antoine Pitrou:
> On Tue, 04 Feb 2014 02:21:51 -0800
> Larry Hastings  wrote:
>> On 02/04/2014 01:41 AM, Georg Brandl wrote:
>> > Clever, but due to the "hidden" space it also increases the frustration 
>> > factor
>> > for people trying to find out "why is this accepted as a signature and not 
>> > this".
>> >
>> > I don't think a well-chosen visible separator is worse off, such as "--\n".
>> 
>> I could live with that.  To be explicit: the signature would then be of 
>> the form
>> 
>> > 
>> The scanning function would look for "(" at the 
>> front.  If it found it it'd scan forwards in the docstring for 
>> ")\n--\n".  If it found *that*, then it would declare success.
> 
> This would have to be checked for layout regressions. If the docstring
> is formatted using a ReST-to-HTML converter, what will be the effect?

The "--" will be added after the signature in the same paragraph.

However, I don't think this is a valid concern: if you process signatures
as ReST you will already have to deal with lots of markup errors (e.g. due
to unpaired "*" and "**").

Tools that extract the docstrings and treat them specially (such as Sphinx)
will adapt anyway.

Georg

___
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] __doc__ regression

[Georg Brandl]

Am 04.02.2014 14:19, schrieb Victor Stinner:
> 2014-02-04 Larry Hastings :
>> Why couldn't these tools use inspect.Signature?
> 
> inspect.Signature was added in Python 3.3. Python 2 is still widely
> used, and some Linux distro only provide Python 3.2.

Well, Python 2 won't be able to introspect C modules written and
compiled for Python 3.x anyway.

And __text_signature__ can be used by any Python 3.x with no loss of
expressivity (handling strings in both cases).

Georg


___
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