andir
Other than that:
+1 for adding scandir to the stdlib
-1 for windows_wildcard (it would be an attractive nuisance to write
windows-only code)
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo
. I think the best way to handle this is a
> .fullname or .full_name attribute as suggested elsewhere. Thoughts?
>
+1 for .fullname. The earlier suggestion to have __str__ return the name is
killed I think by the fact that .fullname could be bytes.
It would be nice if pathlib.Path obj
On 1 July 2014 08:38, Ethan Furman wrote:
> On 06/30/2014 03:07 PM, Tim Delaney wrote:
>
>> I'm torn between whether I'd prefer the stat fields to be populated
>> on Windows if ensure_lstat=False or not. There are good arguments each
>> way, but overa
x27;re
only dealing with directories, but symlinks work with files as well.
I work cross-platform, and have a mild preference for option #2 with
similar semantics on all platforms.
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
he other way around.
>
For most uses the most natural thing is to follow symlinks (e.g. opening a
symlink in a text editor should open the target). However, I think not
following symlinks by default is better approach for exactly the reason
Paul has noted above.
Tim Delaney
___
o a parent directory);
3. Symlinks to non-existent files/directories;
4. Symlink to an absolutely huge directory somewhere else (very annoying if
you just wanted to do a directory sizer ...).
If follow_symlinks=False by default, only those who opt-in
On 14 July 2014 12:17, Nick Coghlan wrote:
>
> I think os.walk() is a good source of inspiration here: call the flag
> "followlink" and default it to False.
>
Actually, that's "followlinks", and I'd forgotten that os.walk() defaulted
to not follow -
results. I imagine that there might be significant differences
between solid state drives, hard drives and network mounts.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://
On 6 November 2017 at 07:50, Peter Ludemann via Python-Dev <
python-dev@python.org> wrote:
> Isn't ordered dict also useful for **kwargs?
>
**kwargs is already specified as insertion ordered as of Python 3.6.
https://www.python.org/dev/peps/pep-0
nsertion order" are fairly simple
to explain, "dicts maintain insertion order up to the point that a key is
deleted" is less so.
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
< (3, 8):
with warnings.simplefilter('ignore', DeprecationWarning):
import module
The idea here is to prompt the developer to refactor to not use the
deprecated functionality early enough that users aren't impacted.
Tim Delaney
err,
which didn't exist and caused the program to hang.
However, I'm definitely +1 on enabling DeprecationWarning by default, but
with mechanisms or recommendations for the application developer to silence
them selectively for the current release.
Tim Delaney
__
On 29 March 2018 at 07:39, Eric V. Smith wrote:
> I’d vote #3 as well.
>
> > On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka
> wrote:
> >
> > There is a subtle semantic difference between str.format() and
> "equivalent" f-string.
> >
> >'{}{}'.format(a, b)
> >f'{a}{b}'
> >
> > In most cas
On 29 March 2018 at 08:09, Tim Delaney wrote:
> On 29 March 2018 at 07:39, Eric V. Smith wrote:
>
>> I’d vote #3 as well.
>>
>> > On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka
>> wrote:
>> >
>> > There is a subtle semantic differenc
e(): return 'very'
> ...
> >>> f'f-strings are {how_awesome()} awesome!'
> 'f-strings are very awesome!'
>
> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
>
I'd like to see an alternatives
pt 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/li
could be bypassed
if you temporarily cached the result of this stat call? And if so, when
should the cached value be cleared?
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
oticed (eventually) unless the attacker also
compromised all those other machines.
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
he current
user’s "application data" directory (i.e. the directory returned by
executing `echo %LOCALAPPDATA%` in a command window) and py.ini in the same
directory as the launcher.
%LOCALAPPDATA% should always contain the same value as would be returned
from SHGetFolderPath with CSIDL
On 29 November 2013 08:34, Glenn Linderman wrote:
> On 11/28/2013 1:04 PM, Tim Delaney wrote:
>
>
> %LOCALAPPDATA% should always contain the same value as would be returned
> from SHGetFolderPath with CSIDL_LOCAL_APPDATA.
>
> Except when it gets changed. Documentation shou
, folders and drives to see it in
Explorer (no matter what user you're logged in as).
If the py.ini location does become defined in terms of %LOCALAPPDATA% then
suggesting to use that value in the Explorer address bar would probably be
the easiest way for people to get to the correct dire
On 29 November 2013 13:17, Terry Reedy wrote:
> On 11/28/2013 7:06 PM, Tim Delaney wrote:
>
> By default in Win7 AppData is a hidden folder - you need to go to Tools
>>
>
> On my system, that is Control Panel, not Tools.
Sorry - was referring to the Explorer "Tool
I've just posted about PEP 460 and this discussion on the mercurial-devel
mailing list.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
n't think "then" is a good fit (even if
it didn't add a keyword).
Unfortunately, I can't come up with anything better ...
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyt
; This version might be more readable:
>
>value = lst[2] except "No value" if IndexError
>
+1 - it's readable, clear, and only uses existing keywords.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
always return a
boolean.
If exception expressions already existed in the language, I would think
there would be a strong argument for a library function hasattr(), but
probably not a builtin.
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
n the not to distant
future (Mercurial was rejected as a sponsor organisation - Giovanni
Gherdovich is liaising with the PSF about it).
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
maintains a string type that presents code points as indivisible
elements;
2. The performance consequences of using UTF-8 are documented, as well as
any optimisations, tricks, etc that are used to overcome those consequences
(and what impact if any they would have if code written for MicroPython was
ru
you have that, everything is
layered on top of it. How the code points themselves are implemented is
opaque and irrelevant other than the memory and performance consequences of
the implementation decisions (for example, a string could be indexable by
iterating from the start until you find the nth c
pt is dead simple.
If the MicroPython string type requires people *using* it to deal with
surrogates (i.e. indexing could return a value that is not a valid Unicode
code point) then it will have broken the conceptual simplicity of the
Python 3 string type (and most certainly can
on top of a dict, but if you do use any reordering
operations, it adds in the additional heavyweight structure required to
support that?
I'm pretty sure something similar has been considered before, but thought I
should bring it up in the context of this discussion (if only to have to
shot
#x27;s getting
beyond the scope of this discussion.
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
On Wed, 20 Mar 2019 at 00:29, Serhiy Storchaka wrote:
> 19.03.19 15:10, Tim Delaney пише:
> > Now Calibre is definitely in the wrong here - it should be able to
> > import regardless of the order of attributes. But the fact is that there
> > are a lot of tools out there that
do with code
> objects and bytecode (since we sometimes think of better ways to execute
> Python).
>
Perhaps "living API" analogous to "living document". Much more positive
connotations ...
Tim Delaney
___
Python-Dev mailing lis
sn't have an ordinal at all (except
by accident in the trivial case). That was when I decided to put it aside
for a while and see where the discussion went.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
ums int-based (and comparable with ints)
was because I read somewhere that Guido had said that any stdlib enum would
have to be an int subclass.
I have no problems with having int-like enums that:
1. Are not int subclasses;
2. Do not compare equal with ints unles
and all the hardlinks to the same file.
There's also a command-line version - ln <
http://schinagl.priv.at/nt/ln/ln.html>.
Highly recommended.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
one) or the type of the table in the existing dbf file.
>
I fall into:
1. int(), float(), str() etc should return that exact class (and
operator.index() should return exactly an int).
2. It could sometimes be useful for __int__() and __index__() to return a
subclass of int.
So, for
lass that implemented comparisons defined
based on iteration order. It makes sense not to have this in the base Enum
class (it would be confusing).
On a related note, I really would like to have the ordinal exposed if this
were added.
Tim Delaney
___
P
On 21 April 2013 04:10, Barry Warsaw wrote:
> On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
>
> >Just using definition order as the stable iteration order would do the
> >trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can
> >then override it
be unambiguous. If we have iteration in definition order, I'd say the
first defined name for a value should be the canonical name, and any other
name for the value should be considered an alias.
That would preclude the syntax above, but the following might be workable:
class Insect(Enum):
der being by sorted name by default, so long as
it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum
should probably iterate in value order.
For definition order, a 3.x-only metaclass could be provided:
class Days(enum.Enum, metaclass=enum.
On 22 April 2013 10:31, Barry Warsaw wrote:
> On Apr 22, 2013, at 09:31 AM, Tim Delaney wrote:
>
> >I'm fine with iteration order being by sorted name by default, so long as
> >it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum
> >shou
jected the auto-numbering syntax a while back. The only case
> in which auto-numbering occurs (per PEP 435) is the "convenience syntax":
>
> Animal = Enum('Animal', 'fox dog cat')
>
Actually, since Guido has pronounced that definition order will be the
e people (in the above that Color.red is not an
instance of MoreColor), or is going to result in a contravariance violation.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
st(TestAutoNumber))
print(TestAutoInt, list(TestAutoInt))
-- Run ----------
[, ,
]
[, ,
]
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
On 5 May 2013 10:49, Eli Bendersky wrote:
>
> On Sat, May 4, 2013 at 4:27 PM, Tim Delaney
> wrote:
>
>> Typo line 171:
>>
>>
> Fixed, thanks.
>
>
>
>> One thing I'd like to be clear in the PEP about is whether enum_type and
>> _En
ributor Form Received" field is "No" in user
details, there be a link to http://www.python.org/psf/contrib/.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
On 5 May 2013 11:22, Tim Delaney wrote:
> On 5 May 2013 10:49, Eli Bendersky wrote:
>
>>
>> On Sat, May 4, 2013 at 4:27 PM, Tim Delaney
>> wrote:
>>
>>> Typo line 171:
>>>
>>>
>> Fixed, thanks.
>>
>>
>>
>>&
On 5 May 2013 13:11, Tim Delaney wrote:
> @@ -142,6 +152,7 @@
> if obj_type in (object, Enum):
> enum_item = object.__new__(enum_class)
> else:
> +value = obj_type.__new__(obj_type, value)
>
On 5 May 2013 13:32, Ethan Furman wrote:
> On 05/04/2013 08:11 PM, Tim Delaney wrote:
>
>>
>> I've been able to achieve the auto-numbering without relying on the
>> internal implementation at all (with a
>> limitation), with a single change to enum_typ
TestAutoIntEnum(AutoIntEnum):
a = ...
b = 3
c = ...
class TestAutoIntEnum2(AutoIntEnum):
a = ...
b = ...
c = ...
print(TestAutoIntEnum, list(TestAutoIntEnum))
print(TestAutoIntEnum2, list(TestAutoIntEnum2))
------ Run ---
On 5 May 2013 16:17, Ethan Furman wrote:
> On 05/04/2013 10:59 PM, Ethan Furman wrote:
>
>> On 05/04/2013 08:50 PM, Tim Delaney wrote:
>>
>>> 2. Instead of directly setting the _name and _value of the enum_item, it
>>> lets the Enum class do it via Enum.__init
;Duplicate enum key '%s.%s' (overriding '%s')" %
(result.__name__, v.key, k
eys[v.key]))
AttributeError: Duplicate enum key 'MoreColor.red' (overriding 'Color.red')
>>>
So long as I can get one of the requirements documented to implement an
aut
On 6 May 2013 08:00, Guido van Rossum wrote:
> On Sun, May 5, 2013 at 2:55 PM, Tim Delaney
> wrote:
> > So long as I can get one of the requirements documented to implement an
> > auto-number syntax I'll be happy enough with stdlib enums I think.
>
> Specificall
order, so I think making it easily available to enum metaclass
subclasses as well just makes sense.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 5 May 2013 21:58, Tim Delaney wrote:
> On 5 May 2013 16:17, Ethan Furman wrote:
>
>> On 05/04/2013 10:59 PM, Ethan Furman wrote:
>>
>>> On 05/04/2013 08:50 PM, Tim Delaney wrote:
>>>
>>>> 2. Instead of directly setting the _name and _value of
On 7 May 2013 12:29, Ethan Furman wrote:
> On 05/05/2013 02:55 PM, Tim Delaney wrote:
>
>>
>> So long as I can get one of the requirements documented to implement an
>> auto-number syntax I'll be happy enough with
>> stdlib enums I think.
>>
On 7 May 2013 15:14, Tim Delaney wrote:
> D'oh! I had my default path being my forked repo ... so didn't see the
> changes. BTW I can't see how that exact implementation passes ... not
> enough parameters declared in AutoNumber.__new__ ...
>
Sorry - my fault again
On 7 May 2013 15:14, Tim Delaney wrote:
> Unfortunately, if you subclass AutoNumber from IntEnum it breaks.
>
> -- Run Python3 --
> Traceback (most recent call last):
> File "D:\home\repos\mercurial\ref435\ref435.py", line 346, in
> class Co
On 7 May 2013 14:54, Ethan Furman wrote:
> On 05/06/2013 07:58 PM, Tim Delaney wrote:
>
>>
>> Considering that doesn't actually work with the reference implementation
>> (AutoNumber.__new__ is never called) ... no.
>>
>
> Two points:
>
>
_merge.
I think it's a perfectly reasonable approach.
I expanded on it a little to make it more general (to choose which parent
to discard) in
http://stackoverflow.com/questions/14984793/mercurial-close-default-branch-and-replace-with-a-named-branch-as-new-default/14991454#149
med keys (I'd call them canonical keys). That
way there's no question about which key is stored - it's *always* the
transformed key.
In fact, I think this might get more traction if it were referred to as a
canonicalising dictionary (bikeshedding, I know).
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
On 13 September 2013 07:29, Tim Delaney wrote:
>
> In this case though, there are two pieces of information:
>
> 1. A canonical key (which may or may not equal the original key);
>
> 2. The original key.
>
> It seems to me then that TransformDict is a specialised case o
nicalDict, where the canonical key is defined to be the first key
inserted. It would in fact be possible (though inefficient) to implement
that using a canonicalising callable that maintained state - something like
(untested):
class OriginalKeys:
def __init__(self)::
ite
well for this - you can modify the resource constraints (CPU, memory, etc)
to simulate different scenarios.
I find that this tends to better promote the methodology of "make it right,
then make it fast (small, etc)", which I subscribe to. Optimising too
s considered a craft, with pride in what we produced.
However, I think I should probably reconsider my viewpoint in light of my
current employment ... I despair at some of the code I see ...
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
elopers having slow machines so they feel the pain ...
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
xceptions = []
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
try:
os.unlink('missing.txt')
except OSError as exc:
exceptions.append(exc)
for ex
entityHashMap
which may also need an ordered equivalent.
There is a repo for Jython 3.5 development:
https://github.com/jython/jython3 but it doesn't seem to be very active -
only 11 commits in the last year (OTOH that's also in the last 3 months).
Tim Delaney
t;
Are sets also ordered by default now? None of the PEPs appear to mention it.
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
On 9 September 2016 at 15:34, Benjamin Peterson wrote:
> On Thu, Sep 8, 2016, at 22:33, Tim Delaney wrote:
> > On 9 September 2016 at 07:45, Chris Angelico wrote:
> >
> > > On Fri, Sep 9, 2016 at 6:22 AM, Victor Stinner <
> victor.stin...@gmail.com>
> > &
n, but is that a valid assumption? Guess I can test it now
3.6.0b1 is out.
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
rom such
a dict implementation.
Personally I expect all Python 3.6 implementations will have
order-preserving dict as that's the easiest way to achieve the existing
guarantees. And that enough code will come to depend on an order-preserving
can definitely find cases in my current java codebase where I've used the
pattern (LinkedHashSet) and the order is important to the semantics of the
code.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
g branch in a local git repo, hg push to
that then force-push to Github. This wnew branch head.
So the workflow I use for working with Github is (after enabling hggit):
git clone .git
hg clone git+.git
cd .hg
...
cd .git
git branch -d
cd .hg
hg push
On 26 June 2017 at 08:20, Tim Delaney wrote:
>
> 2. Last I checked hggit can't force-push to a git repository after
> history-modifying actions (e.g. rebase) so after such actions it's
> necessary to delete any existing branch in a local git repo, hg push to
> that
p/__pycache__
__main__.py
foo.pyr/
foo.py32.pyc
foo.py33.pyc
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rticular task.
f. Easier to follow in the log/graphical log as everything was "tagged" with
what task it was against.
The only issue was that if a branch was abandoned, it would show up in "hg
branches" unless it was closed - but closing wasn't a problem since you can
always
On 2 July 2010 09:08, Tim Delaney wrote:
> On 2 July 2010 08:07, Barry Warsaw wrote:
>
>>
>> Other than that, while I sometimes review patches in email, I do not think
>> patches in a tracker are the best way to manage these. A dvcs's biggest
>> strength is
ure there was actual consensus on that, but I still stand behind
> this point.
>
> If development work was done in named branches, the hook could send one
email per branch that was delivered, and to be safe, one email per changeset
added to a main feature branch.
Tim Delaney
__
r most uses of dict.items(), this means there will not need
to be any code change.
I'm wondering if we might be going the wrong way about warning about
compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0
alpha had a 2.x compatibility mode co
ation - I know that iterators should throw exceptions in this case,
but I can't remember what (if anything) was decided for views.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
f, *p, **kw):
return super(*p, **kw)
So, I guess my question is whether the most common case of calling the base
class method with the same name is worth having some further syntactic sugar
to avoid repetition? I think it is, but that would be your call Guido.
Cheers,
Tim Delaney
rrently, it can mean
whatever you want it to.
class A(object):
@staticmethod
def f():
print super(A)
print super(A, A)
Cheers,
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Here is my modified version of PEP 367. The reference implementation in it
is pretty long, and should probably be split out to somewhere else (esp.
since it can't fully implement the semantics).
Cheers,
Tim Delaney
PEP: 367
Title: New Super
Version: $Revision$
Last-Modified: $Date$
A
Phillip J. Eby wrote:
> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>> Determining the class object to use
>> '''''''''''''''''''''''''''
Tim Delaney wrote:
> Phillip J. Eby wrote:
>> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>>> Determining the class object to use
>>> '''''''''''''''''''''&#x
Nick Coghlan wrote:
> Tim Delaney wrote:
>> So the question is, should the method store the class, or the name?
>> Looking up by name could pick up a totally unrelated class, but
>> storing the undecorated class could miss something important in the
>> decoration.
amed branch per task/issue). If you
only use anonymous branches, except for your feature branches (e.g. 3.2,
2.7) then you'd probably never close a branch.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
ifications - in either type of hook you can
inspect the changesets and determine what branch they are on.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
houldn't ever commit to it (including pushing) except through the "remote"
interfaces (where the remote hg is the one doing the actual commits).
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
sed,
> >> and/or not the same as "default".
> >
> > Problem is, you then have 1.5.2 released from the 2.x branch :)
>
> In that case, "legacy-trunk" would seem clearer.
+1
Exactly what I was about to suggest.
Tim Delaney
racked.
"hg status -i" will list all ignored files that are present in your working
directory. For other options, "hg help status".
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
team was working happily in about a week, and we really found no
reason to change how we used Mercurial once we started doing this. Yes - you
end up with a much branchier workflow, but I found that to be an advantage,
rather than a disadvantage, because I could easily isolate the changes that
compos
On 21 March 2011 08:16, Tim Delaney wrote:
>
> For the second and later merges:
>
> hg update 1234_merged_with_3.2
> hg merge 3.2
> hg commit -m "Merged 3.2 to 1234_merged_with_3.2"
> hg merge 1234
> hg commit -m "Merged 1234 to 1234_merged_with_3.2"
On 2011-03-22, Ben Finney wrote:
> That seems to me the ideal: preserve all revision history for those
> cases when some user will care about it, but *present* history cleanly
> by default.
>
> Whether adding support in Mercurial or Git for similar
> clean-presentation-by-default would obviate th
On 2011-03-22, Steven D'Aprano wrote:
> Tim Delaney wrote:
>
>> You'd end up using more horizontal space, but we all seem to have
>> widescreen monitors these days.
>
> Not even close to "we all".
Fair enough - that was a fairly stupid statement on m
e path - probably prefer two functions e.g.:
shutil.chown(path)
shutil.chown_many(iter)
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
using PyObject_Print ...
Cheers,
Tim Delaney
sqlite_cache.diff
Description: Binary data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
1 - 100 of 141 matches
Mail list logo
