Re: [Python-Dev] PEP: Collecting information about git

[Oleg Broytman]

On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman  wrote:
> PEP: XXX
> Title: Collecting information about git

   HTMLized version: http://phdru.name/Software/Python/PEPs/pep-git.html
   git repo: http://git.phdru.name/?p=pep-git.git;a=summary

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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: Collecting information about git

[Oleg Broytman]

PEP: XXX
Title: Collecting information about git
Version: $Revision$
Last-Modified: $Date$
Author: Oleg Broytman 
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 01-Jun-2015
Post-History: 12-Sep-2015

Abstract


This Informational PEP collects information about git. There is, of
course, a lot of documentation for git, so the PEP concentrates on
more complex (and more related to Python development) issues,
scenarios and examples.

The plan is to extend the PEP in the future collecting information
about equivalence of Mercurial and git scenarios to help migrating
Python development from Mercurial to git.

The author of the PEP doesn't currently plan to write a Process PEP on
migration Python development from Mercurial to git.


Documentation
=

Git is accompanied with a lot of documentation, both online and
offline.


Documentation for starters
--

Git Tutorial: `part 1
`_,
`part 2
`_.

`Git User's manual
`_.
`Everyday GIT With 20 Commands Or So
`_.
`Git workflows
`_.


Advanced documentation
--

`Git Magic
`_,
with a number of translations.

`Pro Git `_. The Book about git. Buy it at
Amazon or download in PDF, mobi, or ePub form. It has translations to
many different languages. Download Russian translation from `GArik
`_.

`Git Wiki `_.


Offline documentation
-

Git has builtin help: run ``git help $TOPIC``. For example, run
``git help git`` or ``git help help``.


Quick start
===

Download and installation
-

Unix users: `download and install using your package manager
`_.

Microsoft Windows: download `git-for-windows
`_ or `msysGit
`_.

MacOS X: use git installed with `XCode
`_ or download from
`MacPorts `_ or
`git-osx-installer
`_ or
install git with `Homebrew `_: ``brew install git``.

`git-cola `_ is a Git GUI
written in Python and GPL licensed. Linux, Windows, MacOS X.

`TortoiseGit `_ is a Windows Shell Interface
to Git based on TortoiseSVN; open source.


Initial configuration
-

This simple code is often appears in documentation, but it is
important so let repeat it here. Git stores author and committer
names/emails in every commit, so configure your real name and
preferred email::

$ git config --global user.name "User Name"
$ git config --global user.email user.n...@example.org


Examples in this PEP


Examples of git commands in this PEP use the following approach. It is
supposed that you, the user, works with a local repository named
``python`` that has an upstream remote repo named ``origin``. Your
local repo has two branches ``v1`` and ``master``. For most examples
the currently checked out branch is ``master``. That is, it's assumed
you have done something like that::

$ git clone https://git.python.org/python.git
$ cd python
$ git branch v1 origin/v1

The first command clones remote repository into local directory
`python``, creates a new local branch master, sets
remotes/origin/master as its upstream remote-tracking branch and
checks it out into the working directory.

The last command creates a new local branch v1 and sets
remotes/origin/v1 as its upstream remote-tracking branch.

The same result can be achieved with commands::

$ git clone -b v1 https://git.python.org/python.git
$ cd python
$ git checkout --track origin/master

The last command creates a new local branch master, sets
remotes/origin/master as its upstream remote-tracking branch and
checks it out into the working directory.


Branches and branches
=

Git terminology can be a bit misleading. Take, for example, the term
"branch". In git it has two meanings. A branch is a directed line of
commits (possibly with merges). And a branch is a label or a pointer
assigned to a line of commits. It is important to distinguish when you
talk about commits and when about their labels. Lines of commits are
by itself unnamed and are usually only lengthening and merging.
Labels, on the other hand, can be created, moved, renamed and deleted
freely.

Re: [Python-Dev] PEP: Collecting information about git

[Brett Cannon]

I have not had a chance to read Oleg's PEP, but the devguide has the
reverse docs at https://docs.python.org/devguide/gitdevs.html so we have
the VCS docs down pat. :)

On Sat, Sep 12, 2015, 06:59 Oleg Broytman  wrote:

> PEP: XXX
> Title: Collecting information about git
> Version: $Revision$
> Last-Modified: $Date$
> Author: Oleg Broytman 
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 01-Jun-2015
> Post-History: 12-Sep-2015
>
> Abstract
> 
>
> This Informational PEP collects information about git. There is, of
> course, a lot of documentation for git, so the PEP concentrates on
> more complex (and more related to Python development) issues,
> scenarios and examples.
>
> The plan is to extend the PEP in the future collecting information
> about equivalence of Mercurial and git scenarios to help migrating
> Python development from Mercurial to git.
>
> The author of the PEP doesn't currently plan to write a Process PEP on
> migration Python development from Mercurial to git.
>
>
> Documentation
> =
>
> Git is accompanied with a lot of documentation, both online and
> offline.
>
>
> Documentation for starters
> --
>
> Git Tutorial: `part 1
> `_,
> `part 2
> `_.
>
> `Git User's manual
> `_.
> `Everyday GIT With 20 Commands Or So
> `_.
> `Git workflows
> `_.
>
>
> Advanced documentation
> --
>
> `Git Magic
> `_,
> with a number of translations.
>
> `Pro Git `_. The Book about git. Buy it at
> Amazon or download in PDF, mobi, or ePub form. It has translations to
> many different languages. Download Russian translation from `GArik
> `_.
>
> `Git Wiki `_.
>
>
> Offline documentation
> -
>
> Git has builtin help: run ``git help $TOPIC``. For example, run
> ``git help git`` or ``git help help``.
>
>
> Quick start
> ===
>
> Download and installation
> -
>
> Unix users: `download and install using your package manager
> `_.
>
> Microsoft Windows: download `git-for-windows
> `_ or `msysGit
> `_.
>
> MacOS X: use git installed with `XCode
> `_ or download from
> `MacPorts `_ or
> `git-osx-installer
> `_ or
> install git with `Homebrew `_: ``brew install git``.
>
> `git-cola `_ is a Git GUI
> written in Python and GPL licensed. Linux, Windows, MacOS X.
>
> `TortoiseGit `_ is a Windows Shell Interface
> to Git based on TortoiseSVN; open source.
>
>
> Initial configuration
> -
>
> This simple code is often appears in documentation, but it is
> important so let repeat it here. Git stores author and committer
> names/emails in every commit, so configure your real name and
> preferred email::
>
> $ git config --global user.name "User Name"
> $ git config --global user.email user.n...@example.org
>
>
> Examples in this PEP
> 
>
> Examples of git commands in this PEP use the following approach. It is
> supposed that you, the user, works with a local repository named
> ``python`` that has an upstream remote repo named ``origin``. Your
> local repo has two branches ``v1`` and ``master``. For most examples
> the currently checked out branch is ``master``. That is, it's assumed
> you have done something like that::
>
> $ git clone https://git.python.org/python.git
> $ cd python
> $ git branch v1 origin/v1
>
> The first command clones remote repository into local directory
> `python``, creates a new local branch master, sets
> remotes/origin/master as its upstream remote-tracking branch and
> checks it out into the working directory.
>
> The last command creates a new local branch v1 and sets
> remotes/origin/v1 as its upstream remote-tracking branch.
>
> The same result can be achieved with commands::
>
> $ git clone -b v1 https://git.python.org/python.git
> $ cd python
> $ git checkout --track origin/master
>
> The last command creates a new local branch master, sets
> remotes/origin/master as its upstream remote-tracking branch and
> checks it out into the working directory.
>
>
> Branches and branches
> =
>
> Git terminology ca

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

[Brett Cannon]

Someone else brought up warnings in Python 2.7 and my response was that you
already get the warning in Python 3 so why get it twice across different
versions?

On Fri, Sep 11, 2015, 22:48 Serhiy Storchaka  wrote:

> On 08.09.15 19:59, Brett Cannon wrote:
> > The approaches to module deprecation I have seen are:
> > 1. Nothing changes to the deprecation process; you deprecate a module
> > and remove it in one to two releases
> > 2. Deprecate the module but with no plans for removal until Python 2.7
> > reaches its EOL (I have been calling this Python 4)
> > 3. Document the deprecation but no actual code deprecation
>
> Of course #2 LGTM. What if at the same time add Py3k warning in next 2.7
> bugfix release?
>
>
> ___
> 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
>
___
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

[Guido van Rossum]

I have only skimmed the first half but it looks really good.

On Sat, Sep 12, 2015 at 8:12 AM, Brett Cannon  wrote:

> I have not had a chance to read Oleg's PEP, but the devguide has the
> reverse docs at https://docs.python.org/devguide/gitdevs.html so we have
> the VCS docs down pat. :)
>
> On Sat, Sep 12, 2015, 06:59 Oleg Broytman  wrote:
>
>> PEP: XXX
>> Title: Collecting information about git
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Oleg Broytman 
>> Status: Draft
>> Type: Informational
>> Content-Type: text/x-rst
>> Created: 01-Jun-2015
>> Post-History: 12-Sep-2015
>>
>> Abstract
>> 
>>
>> This Informational PEP collects information about git. There is, of
>> course, a lot of documentation for git, so the PEP concentrates on
>> more complex (and more related to Python development) issues,
>> scenarios and examples.
>>
>> The plan is to extend the PEP in the future collecting information
>> about equivalence of Mercurial and git scenarios to help migrating
>> Python development from Mercurial to git.
>>
>> The author of the PEP doesn't currently plan to write a Process PEP on
>> migration Python development from Mercurial to git.
>>
>>
>> Documentation
>> =
>>
>> Git is accompanied with a lot of documentation, both online and
>> offline.
>>
>>
>> Documentation for starters
>> --
>>
>> Git Tutorial: `part 1
>> `_,
>> `part 2
>> `_.
>>
>> `Git User's manual
>> `_.
>> `Everyday GIT With 20 Commands Or So
>> `_.
>> `Git workflows
>> `_.
>>
>>
>> Advanced documentation
>> --
>>
>> `Git Magic
>> `_,
>> with a number of translations.
>>
>> `Pro Git `_. The Book about git. Buy it at
>> Amazon or download in PDF, mobi, or ePub form. It has translations to
>> many different languages. Download Russian translation from `GArik
>> `_.
>>
>> `Git Wiki `_.
>>
>>
>> Offline documentation
>> -
>>
>> Git has builtin help: run ``git help $TOPIC``. For example, run
>> ``git help git`` or ``git help help``.
>>
>>
>> Quick start
>> ===
>>
>> Download and installation
>> -
>>
>> Unix users: `download and install using your package manager
>> `_.
>>
>> Microsoft Windows: download `git-for-windows
>> `_ or `msysGit
>> `_.
>>
>> MacOS X: use git installed with `XCode
>> `_ or download from
>> `MacPorts `_ or
>> `git-osx-installer
>> `_ or
>> install git with `Homebrew `_: ``brew install git``.
>>
>> `git-cola `_ is a Git GUI
>> written in Python and GPL licensed. Linux, Windows, MacOS X.
>>
>> `TortoiseGit `_ is a Windows Shell Interface
>> to Git based on TortoiseSVN; open source.
>>
>>
>> Initial configuration
>> -
>>
>> This simple code is often appears in documentation, but it is
>> important so let repeat it here. Git stores author and committer
>> names/emails in every commit, so configure your real name and
>> preferred email::
>>
>> $ git config --global user.name "User Name"
>> $ git config --global user.email user.n...@example.org
>>
>>
>> Examples in this PEP
>> 
>>
>> Examples of git commands in this PEP use the following approach. It is
>> supposed that you, the user, works with a local repository named
>> ``python`` that has an upstream remote repo named ``origin``. Your
>> local repo has two branches ``v1`` and ``master``. For most examples
>> the currently checked out branch is ``master``. That is, it's assumed
>> you have done something like that::
>>
>> $ git clone https://git.python.org/python.git
>> $ cd python
>> $ git branch v1 origin/v1
>>
>> The first command clones remote repository into local directory
>> `python``, creates a new local branch master, sets
>> remotes/origin/master as its upstream remote-tracking branch and
>> checks it out into the working directory.
>>
>> The last command creates a new local branch v1 and sets
>> remotes/origin/v1 as its upstream remote-tracking branch.
>>
>> The same result can be achieved with commands::
>>
>> $ git clone -b v1 https://git.python.org/python.git
>> $ cd python
>> $ git checkout --t

Re: [Python-Dev] PEP: Collecting information about git

[Oleg Broytman]

Hi! I will add the URL with the following paragraph:

Python Developer's Guide also has a chapter `Mercurial for git
developers `_ that
documents a few differences between git and hg.

   Thanks!

On Sat, Sep 12, 2015 at 03:12:13PM +, Brett Cannon  wrote:
> I have not had a chance to read Oleg's PEP, but the devguide has the
> reverse docs at https://docs.python.org/devguide/gitdevs.html so we have
> the VCS docs down pat. :)
> 
> On Sat, Sep 12, 2015, 06:59 Oleg Broytman  wrote:
> > PEP: XXX
> > Title: Collecting information about git

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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

[Oleg Broytman]

On Sat, Sep 12, 2015 at 08:29:10AM -0700, Guido van Rossum  
wrote:
> I have only skimmed the first half but it looks really good.

   Thank you!

> On Sat, Sep 12, 2015 at 8:12 AM, Brett Cannon  wrote:
> 
> > I have not had a chance to read Oleg's PEP, but the devguide has the
> > reverse docs at https://docs.python.org/devguide/gitdevs.html so we have
> > the VCS docs down pat. :)
> >
> > On Sat, Sep 12, 2015, 06:59 Oleg Broytman  wrote:
> >
> >> PEP: XXX
> >> Title: Collecting information about git

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Alexander Belopolsky]

On Sat, Sep 12, 2015 at 1:20 AM, Terry Reedy  wrote:

>  A mathematician has no problem with 'a'+'b' != 'b'+'a'.


I doubt it.  A binary operation denoted + (and called addition) is almost
universally a commutative operation.  A non-commutative binary operation is
usually denoted * (and called multiplication).


>   After closure,


Do you refer to "set closure" operation [1] here?  I am not sure why it is
relevant nor why it is "basic."


> associativity is the most 'basic' operation, but non-associative
> operations are studied.
>

I think you have missed the words "property of" before "operation" above.
 "Closure", "commutativity", "associativity", etc. are properties of
operations, not operations.


>
> The equality relation, mapping pairs of members of a set to True or False
> is a different matter.  Being an equivalence relation is fundamental to
> both normal logic, algebraic proofs, and the definition of sets.


Agree, and we have a solution for PEP 495 which preserves == as and
equivalence (symmetric, reflexive and transitive) relationship.


>
> Datetime members, are rather unusual beasts. They are triples consisting
> of a member of a discrete sequence (with some odd gaps),


I assume you are using a word "member" to refer to class instances.  There
are no gaps in datetimes: there are instances that don't correspond to any
valid local time and (pre-PEP 495) there are local times that don't
correspond to any instances with a given tzinfo.  The unrepresentable times
can still be represented using a different tzinfo.   PEP 495 adds a way to
represent all times using instances with any tzinfo, but on the flip side
adds many more instances that are not "canonical" representations (e.g.
fold=1 instances for regular times.)


> a tz tag, and a 0/1 fold tag. The tz tags divide datetimes into
> equivalence classes.


That I don't understand.  Local t and u = t.astimezone(UTC) are equal (t ==
u evaluates to True), so u and t belong to the same equivalence class.


> The '-' operation is also unusual in being defined differently for pairs
> in the same or different equivalence classes.


I am not concerned about '-'.  My main concern is about order operations.
I am happy with the solution I have for ==, but I am still struggling with
the non-transitivity of <.

Comparison operations are special because they are used implicitly in other
operations.  The < operator is used implicitly in bisect.  If it does not
satisfy the (partial?) order properties, bisect may enter an infinite loop.

[1]: http://mathworld.wolfram.com/SetClosure.html
___
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

[PJ Eby]

On Sat, Sep 12, 2015 at 9:54 AM, Oleg Broytman  wrote:
> The plan is to extend the PEP in the future collecting information
> about equivalence of Mercurial and git scenarios to help migrating
> Python development from Mercurial to git.

I couldn't find any previous discussion about this, but I figure I
should mention:

If the motivation here is to get away from the often-awful bitbucket
to the friendlier and more-popular Github, then it might be useful to
know that hg-git works beautifully with Github.  I have over a dozen
open source projects on Github that I manage entirely using hg command
lines without having yet touched git at all.  Even the forks and pull
requests I've done of others' projects on Github worked just fine, so
long as I remember to use hg bookmarks instead of hg branches.

It's possible there are things you can't do with Mercurial on Github,
but I haven't encountered one thus far.
___
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

[Oleg Broytman]

On Sat, Sep 12, 2015 at 02:02:15PM -0400, PJ Eby  wrote:
> On Sat, Sep 12, 2015 at 9:54 AM, Oleg Broytman  wrote:
> > The plan is to extend the PEP in the future collecting information
> > about equivalence of Mercurial and git scenarios to help migrating
> > Python development from Mercurial to git.
> 
> I couldn't find any previous discussion about this, but I figure I
> should mention:
> 
> If the motivation here is to get away from the often-awful bitbucket
> to the friendlier and more-popular Github, then it might be useful to
> know that hg-git works beautifully with Github.  I have over a dozen
> open source projects on Github that I manage entirely using hg command
> lines without having yet touched git at all.  Even the forks and pull
> requests I've done of others' projects on Github worked just fine, so
> long as I remember to use hg bookmarks instead of hg branches.
> 
> It's possible there are things you can't do with Mercurial on Github,
> but I haven't encountered one thus far.

   My motivation is to help people switch from hg to git without caring
of any particular hosting. Actually I prefer Python development to use
self-hosting with Kalithea, pagure or gitlab at git.python.org (with
official, semi-official and unofficial mirrors all over the Net).

   There are too many things that I personally can do with git but can't
do with hg. Because of that I switched all my development from hg to git
and I am willing to help those who want to follow.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] Looking for a developer who will work with me for at least 6 months to fix NumPy's dtype system.

[Travis Oliphant]

Hi all,

Apologies for cross-posting, but I need to get the word out and twitter
doesn't provide enough explanation.

I've been working on a second edition of my "Guide to NumPy" book.   It's
been a time-pressured activity, but it's helped me put more meat around my
ideas for how to fix NumPy's dtype system -- which I've been contemplating
off an on for 8 years.

I'm pretty sure I know exactly how to do it --- in a way that fits more
cleanly into Python.  It will take 3-6 months and will have residual
efforts needed that will last another 6 months --- making more types
available with NumPy, improving calculations etc.

This work will be done completely in public view and allow for public
comment.   It will not solve *all* of NumPy's problems, but it will put
NumPy's dtype system on the footing it in retrospect should have been put
on in the first place (if I had known then what I know now).

It won't be a grandiose rewrite.   It will be a pretty surgical fix to a
few key places in the code. However, it will break the ABI and require
recompilation of NumPy extensions (and so would need to be called NumPy
2.0).   This is unavoidable, but I don't see any problem with breaking the
ABI today given how easy it is to get distributions of Python these days
from a variety of sources (including using conda --- but not only using
conda).

For those that remember what happened in Python dev land, the changes will
be similar to when Guido changed Python 1.5.2 to Python 2.0.

I can mentor and work closely with someone who will work on this and we
will invite full participation and feedback from whomever in the community
also wants to participate --- but I can't do it myself full time (and it
needs someone full time+).   Fortunately, I can pay someone to do it if
they are willing to commit at least 6 months (it is not required to work at
Continuum for this, but you can have a job at Continuum if you want one).

I'm only looking for people who have enough experience with C or preferably
the Python C-API. You also have to *want* to work on this.   You need to be
willing to work with me on the project directly and work to have a
mind-meld with my ideas which will undoubtedly give rise to additional
perspectives and ideas for later work for you.

When I wrote NumPy 1.0, I put in 80+ hour weeks for about 6 months or more
and then 60+ weeks for another year.  I was pretty obsessed with it.   This
won't need quite that effort, but it will need something like it. Being
able to move to Austin is a plus but not required.   I can sponsor a visa
for the right candidate as well (though it's not guaranteed you will get
one with the immigration policies what they are).

This is a labor of love for so many of us and my desire to help the dtype
situation in NumPy comes from the same space that my desire to work on
NumPy in the first place came.  I will be interviewing people to work
on this as not everyone who may want to will really be qualified to do it
--- especially with so many people writing Cython these days instead of
good-ole C-API code :-)

Feel free to spread the news to anyone you can.   I won't say more until
I've found someone to work with me on this --- because I won't have the
time to follow-up with any questions or comments.Even if I can't find
someone I will publish the ideas --- but that also takes time and effort
that is in short supply for me right now.

If there is someone willing to fund this work, please let me know as well
-- that could free up more of my time.

Best,

-Travis


-- 

*Travis Oliphant*
*Co-founder and CEO*


@teoliphant
512-222-5440
http://www.continuum.io
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Collecting information about git

[Tim Delaney]

On 13 September 2015 at 04:42, Oleg Broytman  wrote:

>There are too many things that I personally can do with git but can't
> do with hg. Because of that I switched all my development from hg to git
> and I am willing to help those who want to follow.
>

Slightly off-topic, but personally I'd love to know what those are. I've
yet to find anything in Git that I haven't been able to do at least as well
with Mercurial (or an extension), and there are things Mercurial
supports that I use extensively (in particular named branches and phases)
where the concept doesn't even exist in Git.

I switched all of my development to Mercurial, and use hg-git and
hgsubversion when I need to interact with those systems.

Tim Delaney
___
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

[Ryan Gonzalez]

On September 12, 2015 6:14:58 PM CDT, Tim Delaney  
wrote:
>On 13 September 2015 at 04:42, Oleg Broytman  wrote:
>
>>There are too many things that I personally can do with git but
>can't
>> do with hg. Because of that I switched all my development from hg to
>git
>> and I am willing to help those who want to follow.
>>
>
>Slightly off-topic, but personally I'd love to know what those are.
>I've
>yet to find anything in Git that I haven't been able to do at least as
>well
>with Mercurial (or an extension), and there are things Mercurial
>supports that I use extensively (in particular named branches and
>phases)
>where the concept doesn't even exist in Git.
>
>I switched all of my development to Mercurial, and use hg-git and
>hgsubversion when I need to interact with those systems.

...speed??

Seriously; just try pulling the entire CPython repo. Then try again with the 
GitHub mirror.

I love Mercurial's CLI. But, every time I use it, I end up feeling like I'm 
waiting forever.

Git's CLI is really weird, but it's surprisingly powerful and flexible once you 
get the hang of it (which admittedly might take a while!).

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

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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] The changes I am planning to NumPy I'd like to make only available on Python 3

[Travis Oliphant]

If it helps anyone in their interest level.   My intention would be to make
these changes to NumPy only available on Python 3 as a way to help continue
adoption of Python 3.

-Travis


-- 

*Travis Oliphant*
*Co-founder and CEO*


@teoliphant
512-222-5440
http://www.continuum.io
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

[Terry Reedy]

On 9/12/2015 1:04 PM, Alexander Belopolsky wrote:



On Sat, Sep 12, 2015 at 1:20 AM, Terry Reedy mailto:tjre...@udel.edu>> wrote:

  A mathematician has no problem with 'a'+'b' != 'b'+'a'.

I doubt it.  A binary operation denoted + (and called addition) is
almost universally a commutative operation.  A non-commutative binary
operation is usually denoted * (and called multiplication).


I am aware of the single-operation group theory convention, but the 
context was sequence concatenation and scalar multiplication, where '*' 
is repeated '+'.  But these details are not directly relevant to DateTimes.



   After closure,


I perhaps should have said 'completeness'.  In any case, I was referring 
to 'a op b' existing for all a and b in the set.



Agree, and we have a solution for PEP 495 which preserves == as and
equivalence (symmetric, reflexive and transitive) relationship.

Datetime members, are rather unusual beasts. They are triples
consisting of a member of a discrete sequence (with some odd gaps),


Your correction, summarized, is that there are no gaps, so the set is 
simpler than I thought. Skipping on to the heart of the matter.



I am not concerned about '-'.  My main concern is about order
operations.


Is not '<' defined, in the obvious way, in terms of '-' and the sign of 
the resul?



 I am happy with the solution I have for ==, but I am still
struggling with the non-transitivity of <.


I am guessing that the 'struggle' is at least partly this: "Is 
non-transitivity of < necessary given other constraints, including 
back-compatibility, or is there another solution possible that would 
also be <-transitive?"



Comparison operations are special because they are used implicitly in
other operations.  The < operator is used implicitly in bisect.  If it
does not satisfy the (partial?) order properties, bisect may enter an
infinite loop.


and, if we are stuck with <-intransitivity, what do we do? If 
back-compatibility allowed, I might suggest defining 'lt' or 'less' 
rather than '__lt__' so that sort and bisect don't work with DateTimes. 
Then document that the function is not transitive.


--
Terry Jan Reedy

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

Re: [Python-Dev] PEP: Collecting information about git

[Oleg Broytman]

Hi!

On Sun, Sep 13, 2015 at 09:14:58AM +1000, Tim Delaney 
 wrote:
> On 13 September 2015 at 04:42, Oleg Broytman  wrote:
> 
> >There are too many things that I personally can do with git but can't
> > do with hg. Because of that I switched all my development from hg to git
> > and I am willing to help those who want to follow.
> 
> Slightly off-topic, but personally I'd love to know what those are. I've
> yet to find anything in Git that I haven't been able to do at least as well
> with Mercurial (or an extension), and there are things Mercurial
> supports that I use extensively (in particular named branches and phases)
> where the concept doesn't even exist in Git.

   I started to learn Mercurial at the end of 2008 and made the first
commit at January of 2009. Global named branches was one of the
(mis)features that I disliked from the very beginning. One top-level
.hgignore file instead of proper per-directory ignore files. Two-commits
tagging -- the tag is committed in a different commit from the commit it
tags. Repositories to pull from and push to must be related -- they must
be (in)direct clones of one root repo. There were also things that I
wanted but didn't really understand what I wanted -- I switched to
Mercurial from CVS and SVN and didn't fully understand the real power of
distributed VCS.
   I was the only developer of the project, the project was not very
big:
   $ du -sh third-party .hg .
   2.4M  third-party
   2.2M  .hg
   6.2M  .
and didn't require intensive development so instead of named branches
I decided to go with two separate clones, old and new, and use ``hg
transplant`` to copy occasional commits from the old clone to the new
one.

   Somewhere at the end of 2011 my management moved me to a different
project. They use git for development so I started to learn git (i.e.,
Mercurial had 3 years start). I am a slow thinker so it took me about a
year to master git, another year to appreciate it and at the third year
I fell in love with it. The project is much bigger:
   $ du -sh libs/third-party third-party .git .
   24M   libs/third-party
   46M   third-party
   48M   .git
   20M   .
and development is much more intensive -- there are many developers,
many clones, many subprojects, many submodules, third-party libraries
and programs, many branches with merges.
   Git fixed all the problems I had with hg. Its branching model suits
my understanding of branches much better. With git we can have
per-directory .gitignore and .gitattributes. Lightweight and annotated
tags point exactly to the commits they tag. Ability to pull and push
between unrelated repos.
   I learned commit editing and found that it was the thing I wanted so
badly in hg. When I started Mercurial was at version 1.7 and there was
no commit editing at all; there was ``hg rollback`` but it only could
undo one transaction. Later Mercurial learned commit editing,
unwillingly perhaps, but git is still better at it: ``git add -p``
allows me to review and edit patches before commit while ``hg record``
commits immediately.
   Git is powerful. Even now, at version 3.1 ``hg help log`` lists about
a dozen of options; ``git help log`` gives me about 60 pages of
documentation. I do not use all of them but I very much like ``git log
--decorate``, ``--graph``, ``--grep=`` (and all related search options,
especially ``-G``), ``--pretty``, ``--oneline``, ``--encoding=`` (I
often use koi8-r instead of utf-8), ``--color`` and ``--word-diff``. I
like ``git grep``, especially in the form ``git grep -Ovim``. I don't
know what are the equivalent commands for ``git commit -c HEAD~`` or
``git diff --name-only``.
   Git has a lot of good documentation.

   A few months ago I converted those two clones from hg to git using
git-remote-hg, merged them into one repository as branches, did a
null-merge and from that point I have been using proper branches and
merges for development. I stopped using Mercurial and I think I will not
come back.

   As I stopped using Mercurial I do not understand what phases are.
they are phases of commit according to what? To the origin (let me
borrow the word from git terminology)?

   Mercurial, for sure, has some advantages. It is written in Python.
That's important. That's important for ideological reasons. That's also
important because hg runs natively under Windows, it even has code for
working with case-insensitive filesystems.
   There are Mercurial Queues.
   There are also small advantages like better polished command-line
interface and ability to shorten command names and options to a unique
prefix.

> Tim Delaney

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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