Hi Paul,
On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote:
>
> Can someone state what's currently unpalatable about 649? It seemed to
> address the forward-referencing issues, certainly all of the cases I was
> expecting to encounter.
Broadly speaking I think there are 3-4 issues to resolve as
On Tue, Apr 26, 2022 at 7:24 PM Greg Ewing
wrote:
> On 27/04/22 2:01 am, Chris Angelico wrote:
> > That would be the case if monkeypatching were illegal. Since it's not,
> > wherein lies the difference?
>
> The proposed feature is analogous to forward declaring a
> struct in C. Would you call wha
On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote:
> I also would like to hear more about the problem this is trying to solve,
> when th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too quickly into
esoteric details of implementation and synta
On Sun, Apr 24, 2022 at 10:20 AM Joao S. O. Bueno wrote:
>
> I am not worried about the bikeshed part of which syntax to use -
> and more worried with the possible breaking of a lot of stuff, unless
> we work with creation of a non-identical "forward object" that is
> rebound, as in plain name bin
Hi Larry,
On Sat, Apr 23, 2022 at 1:53 AM Larry Hastings wrote:
> But rather than speculate further, perhaps someone who works on one of the
> static type analysis checkers will join the discussion and render an informed
> opinion about how easy or hard it would be to support "forward class" an
Hi Malthe,
On Fri, Apr 8, 2022 at 12:04 PM Malthe wrote:
> Actually, to me the interesting idea is not so much lazy imports – I
> think they should not be lazy, at least that was my initial thought. I
> think they should be immediately resolved before anything else in that
> module:
I'm +0.25 on
Hi Barry,
On Fri, Apr 8, 2022 at 12:44 PM Barry Warsaw wrote:
>
> Start up overhead due to imports is a real problem for some class of
> applications, e.g. CLIs, and I’ve seen a lot of hacks implemented to get
> Python CLIs to be more responsive. E.g. getting from invocation to —help
> output
An interesting point in the lazy imports design space that I hadn't
previously considered could be:
- lazy imports are explicitly marked and usage of the imported name
within the module is transparent, but
- lazily imported names are _not_ visible in the module namespace;
they can't be accessed by
You only get the ease-of-implementation benefit if you are willing to
explicitly mark every _use_ of a lazy-imported name as special (and
give the fully qualified name at every usage site). This is rather
more cumbersome (assuming multiple uses in a module) than just
explicitly marking an import as
Hi Eric, just one note:
On Wed, Mar 9, 2022 at 7:13 PM Eric Snow wrote:
> > Maybe say “e.g. with Instagram's Cinder” – both the household name and
> > the project you can link to?
>
> +1
>
> Note that Instagram isn't exactly using Cinder.
This sounds like a misunderstanding somewhere. Instagram
On Thu, Dec 23, 2021 at 7:38 PM Barry Warsaw wrote:
>
> On Dec 23, 2021, at 17:09, Guido van Rossum wrote:
> >
> > Mark's proposal was
> > ```
> > @Callable
> > def func(params): pass
> > ```
> > My question is, why does it need `@Callable`? Lukasz proposed just using
> > any (undecorated) funct
On Thu, Oct 21, 2021 at 12:06 PM Jelle Zijlstra
wrote:
> I would want this for my type checker, pyanalyze. I'd want to get the raw
> annotation and turn it into a type. For example, if the annotation is
> `List[SomeType]` and `SomeType` is imported in `if TYPE_CHECKING`, I'd at
> least still b
On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
wrote:
> Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP
> 649?
>
> I think I've seen others mention this but as the code object isn't executed
> until inspected then if you are just using annotations for type hints it
> s
On Mon, Aug 9, 2021 at 9:31 PM Inada Naoki wrote:
> Currently, reference implementation of PEP 649 has been suspended.
> We need to revive it and measure performance/memory impact.
I volunteered to check performance impact in practice on the Instagram
codebase, which is almost fully annotated. Ho
On Sun, Apr 25, 2021 at 10:30 AM Brett Cannon wrote:
> I know I would be curious, especially if backwards compatibility can be
> solved reasonably (for those that haven't lived this, deferred execution
> historically messes up code relying on import side-effects and trackbacks are
> weird as th
Hi Larry,
This is a creative option, but I am optimistic (now that the SC
decision has removed the 3.10 deadline urgency) that we can find a
path forward that is workable for everyone and doesn't require a
permanent compiler feature flag and a language that is permanently
split-brained about annot
Hi Barry & Luciano,
Barry Warsaw wrote:
> Actually, I think it’s time for a comprehensive guide to type annotations.
> Just anecdotally, I was trying to annotate a library of mine and was having
> an impossible time of it, until a chat with Guido lead me to
> @typing.overload. That solved my
Hi Larry,
On 4/14/21, 1:56 PM, "Larry Hastings" wrote:
>My plan was to post it here and see what the response was first. Back in
> January, when I posted the first draft, I got some very useful feedback that
> resulted in some dramatic changes. This time around, so far, nobody has
> su
Hi Larry,
On 4/12/21, 6:57 PM, "Larry Hastings" wrote:
Again, by "works on PEP 563 semantics", you mean "doesn't raise an error".
But the code has an error. It's just that it has been hidden by PEP 563
semantics.
I don't agree that changing Python to automatically hide errors is an
On Thu, Apr 30, 2020 at 3:12 PM Raymond Hettinger
wrote:
> Thanks for the concrete example. AFAICT, it doesn't require (and probably
> shouldn't have) a lock to be held for the duration of the call. Would it be
> fair to say the 100% of your needs would be met if we just added this to the
> f
On Wed, Apr 29, 2020 at 9:36 PM Raymond Hettinger
wrote:
> Do you have some concrete examples we could look at? I'm having trouble
> visualizing any real use cases and none have been presented so far.
This pattern occurs not infrequently in our Django server codebase at
Instagram. A typical ca
On Sat, Apr 18, 2020 at 10:38 PM Guido van Rossum wrote:
>
> Note that, while there is indeed a docs page about 2to3, the only docs for
> lib2to3 in the standard library reference are a link to the source code and a
> single "Note: The lib2to3 API should be considered unstable and may change
>
The PEP is exciting and is very clearly presented, thank you all for
the hard work!
Considering the comments in the PEP about the new parser not
preserving a parse tree or CST, I have some questions about the future
options for Python language-services tooling which requires a CST in
order to roun
On 11/29/2017 05:02 PM, Guido van Rossum wrote:
> I tried to look up the discussion but didn't find much except that you
> flagged this as an issue. To repeat, your concern is that isdataclass()
> applies to *instances*, not classes, which is how Eric has designed it,
> but you worry that either th
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
> I've posted a new version of PEP 557, it should soon be available at
> https://www.python.org/dev/peps/pep-0557/.
>
> The only significant changes since the last version are:
>
> - changing the "compare" parameter to be "order", since that more
> acc
Hi Eric,
Really excited about this PEP, thanks for working on it. A couple minor
questions:
> If compare is True, then eq is ignored, and __eq__ and __ne__ will be
automatically generated.
IMO it's generally preferable to make nonsensical parameter combinations
an immediate error, rather than si
On 05/09/2017 10:28 AM, Guido van Rossum wrote:
> There's a proposal to change one detail of PEP 484. It currently says:
>
> An optional type is also automatically assumed when the default value is
> |None|, for example::
>
> |def handle_employee(e: Employee = None): ... |
>
> Th
On 08/10/2015 02:49 PM, Eric V. Smith wrote:
> On 08/10/2015 02:44 PM, Yury Selivanov wrote:
>>
>>
>> On 2015-08-10 2:37 PM, Eric V. Smith wrote:
Besides, any expression you have to calculate can go in a local that
will get
> interpolated. The same goes for any !r or other formatting
On 07/30/2015 09:03 PM, Nikolaus Rath wrote:
> Nick recently mentioned that the PSF might be able to help, but that the
> initiative for that needs to come from the core developers. So why don't
> you guys ask the PSF to e.g. sponsor some of the work that no one feels
> motivated to do in their spa
On 05/28/2015 11:52 AM, Paul Moore wrote:
[snip]
> Nevertheless, I would like to understand how Unix can manage to have a
> Python 3.4.3 binary at 4kb. Does that *really* have no external
> dependencies (other than the C library)? Are we really comparing like
> with like here?
I don't know what Do
Hi Lennart,
On 04/08/2015 09:18 AM, Lennart Regebro wrote:
> I wrote PEP-431 two years ago, and never got around to implement it.
> This year I got some renewed motivation after Berker Peksağ made an
> effort of implementing it.
> I'm planning to work more on this during the PyCon sprints, and als
On 04/25/2014 01:55 PM, Ethan Furman wrote:
> On 04/25/2014 12:45 PM, Florent wrote:
>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan:
>>>
>>> And if you're going to publish a tool to enforce your *personal* style
>>> guide and include your own custom rules that the "this is OK" examples
>>> in PEP 8 fai
Hi Ethan,
I haven't chimed into this discussion, but the direction it's headed
recently seems right to me. Thanks for putting together a PEP. Some
comments on it:
On 01/15/2014 05:13 PM, Ethan Furman wrote:
>
> Abstract
>
>
> This PEP proposes adding the % a
On 02/20/2013 03:35 PM, Greg Ewing wrote:
> Carl Meyer wrote:
>> An XML parser that follows the XML standard is never safe to expose to
>> untrusted input.
>
> Does the XML standard really mandate that a conforming parser
> must blindly download any DTD URL given to
On 02/20/2013 01:53 PM, Skip Montanaro wrote:
>> That's not very good. XML parsers are supposed to parse XML according
>> to standards. Is the goal to have them actually do that, or just
>> address DDOS issues?
>
> Having read through Christian's mail and several of his references, it
> seems to m
On 07/19/2012 10:26 AM, Andrew Svetlov wrote:
> virtualenv has virtualenv.csh and virtualenv.fish files.
> Is there any reason for restricting venv to bash/zsh only?
No. As far as I'm concerned, a patch to port the virtualenv csh and fish
activate scripts to pyvenv would be welcome (though I can't
Hi Stefan,
On 07/19/2012 06:28 AM, Stefan H. Holek wrote:
> While trying 3.3 beta I found that I cannot use my favorite
> virtualenv pattern with pyvenv:
>
> $ virtualenv . Installing.done.
>
> $ pyvenv . Error: Directory exists: /Users/stefan/sandbox/foo
>
> I appreciate that this behavior
Hi Alexis,
On 06/20/2012 10:57 AM, Alexis Métaireau wrote:
> Le mer. 20 juin 2012 18:45:23 CEST, Paul Moore a écrit :
>> Thanks - as you say, it's not so much the actual problem as the
>> principle of what the packaging API offers that matters here. Although
>> it does make a good point - to what
Hi Paul,
On 06/20/2012 09:29 AM, Paul Moore wrote:
> As a specific example, one thing I would like to do is to be able to
> set up a packaging.pypi client object that lets me query and download
> distributions. However, rather than just querying PyPI (the default)
> I'd like to be able to set up a
Hello Christian,
On 06/03/2012 03:56 PM, Éric Araujo wrote:
> Le 02/06/2012 12:59, Christian Tismer a écrit :
>> One urgent question: will this feature be backported to Python 2.7?
>
> Features are never backported to the stable versions. virtualenv still
> exists as a standalone project which i
On 05/28/2012 04:24 PM, Nick Coghlan wrote:
> It would have been better if the issue of script management on Windows
> had been raised in PEP 405 itself - I likely would have declared PEP
> 397 a dependency *before* accepting it (even if that meant the feature
> missed the alpha 4 deadline and firs
Hi Paul,
On 05/07/2012 04:16 PM, Paul Moore wrote:
On 7 May 2012 21:55, "Martin v. Löwis" wrote:
This sounds to me like a level of complexity unwarranted by the severity
of the problem, especially when considering the additional burden it
imposes on alternative Python implementations.
OTOH,
On 05/07/2012 03:52 AM, "Martin v. Löwis" wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right solution to me. PEP 405 specifies that
On 05/07/2012 04:26 AM, Ronald Oussoren wrote:
On 7 May, 2012, at 11:52, Martin v. Löwis wrote:
3) Symlink the interpreter rather than copying. I include this
here for the sake of completeness, but it's already been rejected
due to significant problems on older Windows' and OS X.
That sounds t
On 05/05/2012 12:41 AM, Nick Coghlan wrote:
On Sat, May 5, 2012 at 6:49 AM, Carl Meyer wrote:
1) Document it and provide a tool for easily upgrading a venv in this
situation. This may be adequate. In practice the situation is quite rare:
2.6.8/2.7.3 is the only actual example in the history of
On 05/05/2012 04:40 AM, Antoine Pitrou wrote:
On Fri, 04 May 2012 14:49:03 -0600
Carl Meyer wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
On 05/05/2012 02:38 AM, Vinay Sajip wrote:
Nick Coghlan gmail.com> writes:
Personally, I expect that "always update your virtual environment
binaries after updating the system Python to a new point release" will
itself become a recommended practice when using virtual environments.
Of course
Hi all,
The recent virtualenv breakage in Python 2.6.8 and 2.7.3 reveals an
issue that deserves to be explicitly addressed in PEP 405: what happens
when the system Python underlying a venv gets an in-place bugfix
upgrade. If the bugfix includes a simultaneous change to the interpreter
and sta
Hi all,
Are the download pages for older Python versions supposed to be kept up
to date at all? I just noticed that the 2.4.6 download page
(http://www.python.org/download/releases/2.4.6/) says things like
"Python 2.4 is now in security-fix-only mode" (whereas in fact it no
longer gets even s
On 04/27/2012 08:36 AM, Guido van Rossum wrote:
Someone should contact the Django folks. Alex Gaynor?
I committed the relevant code to Django (though I didn't write the
patch), and I've been following this thread. I have it on my todo list
to review this code again with Ezio's suggestions in
On 03/29/2012 11:39 AM, David Malcolm wrote:
>> jaraco@vdm-dev:~$ env/bin/python -c "import os; os.urandom()"
>> Traceback (most recent call last):
>> File "", line 1, in
>> AttributeError: 'module' object has no attribute 'urandom'
>
> It looks like this a symptom of the move of urandom to os.
Thanks Jason for raising this. I just assumed that this was virtualenv's
fault (which it is) and didn't consider raising it here, but a note in
the release notes for the affected Python versions will certainly reach
many more of the likely-to-be-affected users.
FTR, I confirmed that the issue also
Hi Jason,
On 03/28/2012 12:22 PM, Jason R. Coombs wrote:
> To reproduce, using virtualenv 1.7+ on Python 2.7.2 on Ubuntu, create a
> virtualenv. Move that virtualenv to a host with Python 2.7.3RC2 yields:
>
> jaraco@vdm-dev:~$ /usr/bin/python2.7 -V
>
> Python 2.7.3rc2
>
> jaraco@vdm-dev:~$ env/
On 03/23/2012 09:22 PM, PJ Eby wrote:
> On Mar 23, 2012 3:53 PM, "Carl Meyer" > On 03/23/2012 12:35 PM, PJ Eby wrote:
>> > AFAICT, virtualenvs are overkill for most development anyway. If you're
>> > not using distutils except to install dependencies, t
Hi PJ,
On 03/23/2012 12:35 PM, PJ Eby wrote:
> AFAICT, virtualenvs are overkill for most development anyway. If you're
> not using distutils except to install dependencies, then configure
> distutils to install scripts and libraries to the same directory, and
> then do all your development in tha
On 03/20/2012 12:19 PM, Paul Moore wrote:
> I also note that I'm assuming virtualenv will change to match whatever
> the Python version it's referencing does. I don't see how you can
> guarantee that, but if there are discrepancies between virtualenvs and
> installed Pythons, my level of objection
Hello Kristján,
On 03/19/2012 03:26 AM, Kristján Valur Jónsson wrote:
> Hi Carl. I'm very interested in this work. At CCP we work heavily
> with virtual environments. Except that we don't use virtualenv
> because it is just a pain in the neck. We like to be able to run
> virtual python environme
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
> * All executables and scripts go into the root of the Python install.
> This directory is largely empty now - it is mainly a container for other
> directories. This would solve the problem of needing 2 directories on
> the PATH and mean exist
Hi Van,
On 03/16/2012 08:08 AM, Lindberg, Van wrote:
>> Changing the directory name is in fact a new and different (and much
>> more invasive) special case, because distutils et al install scripts
>> there, and that directory name is part of the distutils install scheme.
>> Installers don't care w
On 03/15/2012 05:10 PM, Mark Hammond wrote:
> On 16/03/2012 10:48 AM, Carl Meyer wrote:
>> The implementation of virtualenv (and especially PEP 405 pyvenv) are
>> largely based around making sure that the internal layout of a
>> virtualenv is identical to the layout of an ins
On 03/15/2012 04:19 PM, Mark Hammond wrote:
> On 16/03/2012 8:57 AM, VanL wrote:
>> On 3/14/2012 6:30 PM, Mark Hammond wrote:
>>>
>>> So why not just standardize on that new layout for virtualenvs?
>>
>> That sounds like the worst of all worlds - keep all the existing special
>> cases, and add one.
On 03/15/2012 03:02 PM, Lindberg, Van wrote:
> FYI, the location of the tcl/tk libraries does not appear to be set in
> the virtualenv, even if tkinter is installed and working in the main
> Python installation. As a result, tk-based apps will not run from a
> virtualenv.
Thanks for the report!
A brief status update on PEP 405 (built-in virtualenv) and the open issues:
1. As mentioned in the updated version of the language summit notes,
Nick Coghlan has agreed to pronounce on the PEP.
2. Ned Deily discovered at the PyCon sprints that the current reference
implementation does not work wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Victor,
On 01/19/2012 05:48 PM, Victor Stinner wrote:
[snip]
> Using a randomized hash may
> also break (indirectly) real applications because the application
> output is also somehow "randomized". For example, in the Django test
> suite, the HTML
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/09/2011 07:45 AM, Lennart Regebro wrote:
> The slowness of running 2to3 during install time can be fixed by not
> doing so, but instead running it when the distribution is created,
> including both Python 2 and Python 3 code in the distribution.
On 12/09/2011 08:35 AM, Michael Foord wrote:
> On 9 Dec 2011, at 15:13, Barry Warsaw wrote:
>> Oh, I remember this one, because I think I reported and fixed it.
>> But I take it as a given that Python 2.6 is the minimal (sane)
>> version to target for one-codebase cross-Python code.
>>
>
> In moc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/10/2011 07:17 AM, Vinay Sajip wrote:
> Barry Warsaw python.org> writes:
>> On Nov 10, 2011, at 08:58 AM, Nick Coghlan wrote:
>>> Now you need to persuade Vinay to let you trade PEP numbers with the
>>> pyvenv PEP. Having an unrelease schedule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2011 05:43 PM, Nick Coghlan wrote:
> I'm actually finding I quite like the virtualenv scheme of having
> "sys.prefix" refer to the virtual environment and "sys.real_prefix"
> refer to the interpeter's default environment. If pyvenv used the sa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2011 09:57 PM, Stephen J. Turnbull wrote:
> That's fine, but either make sure it works with a POSIX-conformant
> /bin/sh, or make the shebang explicitly bash (bash is notoriously
> buggy in respect of being POSIX-compatible when named "sh").
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2011 10:28 AM, Paul Moore wrote:
> On 31 October 2011 16:08, Tres Seaver wrote:
>> On 10/31/2011 11:50 AM, Carl Meyer wrote:
>>
>>> I have no problem including the basic posix/nt activate scripts if
>>> n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 06:28 AM, Antoine Pitrou wrote:
> On Sun, 30 Oct 2011 12:10:18 + (UTC)
> Vinay Sajip wrote:
>>
>>> We already have Unix shell scripts and BAT files in the source tree. Is
>>> it really complicated to maintain these additional shell s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2011 09:35 AM, Vinay Sajip wrote:
> That's true, I hadn't thought of that. So then it sounds like the thing to do
> is
> make venv a package and have the code in venv/__init__.py, then have the
> scripts
> in a 'scripts' subdirectory below t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 04:47 PM, Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>> It would be even simpler not to process it at all, but install the
>> scripts as-is (without the execute bit) :)
> Sure, but such an approach makes it difficult to prov
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2011 05:10 PM, Chris McDonough wrote:
>> Why not modify sys.prefix?
>> - --
>>
>> As discussed above under `Backwards Compatibility`_, this PEP proposes
>> to add ``sys.site_prefix`` as "the prefix relative to which
>>
/vinay.sajip/pythonv/issues?status=new&status=open
PEP: XXX
Title: Python Virtual Environments
Version: $Revision$
Last-Modified: $Date$
Author: Carl Meyer
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 13-Jun-2011
Python-Version: 3.3
Post-History: 24-Oct-2011, 28-Oct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/2011 12:12 PM, Nick Coghlan wrote:
> sandbox is a bit close to Victor's pysandbox for restricted execution
> environments.
>
> 'nest' would probably work, although I don't recall the 'egg'
> nomenclature featuring heavily in the current zipim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Éric,
Vinay is more up to date than I am on the current status of the
implementation. I need to update the PEP draft we worked on last spring
and get it posted (the WIP is at
https://bitbucket.org/carljm/pythonv-pep but is out of date with the
late
On 06/13/2011 06:46 PM, Carl Meyer wrote:
> FWIW, historically pretty much every new Python version has broken
> virtualenv
I should clarify that this is because of the delicate stdlib
bootstrapping virtualenv currently has to do; the built-in virtualenv
eliminates this entirely and will r
On 06/13/2011 08:07 AM, Nick Coghlan wrote:
> On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip wrote:
>> You're right in terms of the current Python ecosystem and 3.x adoption,
>> because
>> of course this approach requires support from Python itself in terms of its
>> site.py code. However, virtual
On 06/13/2011 06:55 AM, Michael Foord wrote:
> There are two options:
>
> Bring the full functionality into the standard library so that Python
> supports virtual environments out of the box. As is the case with adding
> anything to the standard library it will then be impossible to add
> feature
On 05/29/2011 06:11 PM, Jack Diederich wrote:
> We don't, but many projects do
> release new features with bugfix version numbers - I'm looking at you,
> Django.
Really? Do you have an example of a new Django feature that was released
in a bugfix version number? Just curious, since that's certai
On 04/15/2011 08:53 AM, Michael Foord wrote:
>> If we treat django's failure to use super as a bug, you want the
>> Python language to work-around that bug so that:
>
> What you say (that this particular circumstance could be treated as a
> bug in django) is true,
Just as a side note: if there
Hi Georg,
On 03/23/2011 03:56 PM, Georg Brandl wrote:
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP. Please let me know if you plan any such changes,
> at any time. (If they aren't codified in PEP form, we should think about
> whether they should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Senthil,
On 03/21/2011 09:57 PM, Senthil Kumaran wrote:
> - In the above issue, why is two same bitbutket urls are provided. (It
> is redundant).
I updated the patch, and the second time around the "remote hg repo" box
was empty. I wasn't sure wha
84 matches
Mail list logo
